Re: [libcvd-members] Semantics of frame_pending?

[Gerhard Reitmayr]

Hi Ed,

sounds like a good suggestion. Would do away with some of the ifdef code
I have sometimes :)

why have the live flag? the flushable seems to be the part of the
semantics we want to capture.

cheers,
  Gerhard

Edward Rosten wrote:
> Anyone want to weigh in on the semantics of frame_pending()?
> 
> 
> frame_pending was originally used to indicate if there was still a frame
> waiting in the kernel's buffer for V4L2 video capture devices. It
> extended well to DV buffer.
> 
> It is sometimes used in the following way:
> 
> while(buffer.frame_pending())
> {
>     //Burn frames
>         buffer.put_frame(buffer.get_frame());
> }
> 
> to reduce latency on live feeds. This doesn't work with the new
> ServerPushJpegBuffer, snice it can't tell if there is a frame available.
> Flushing code will simply keep on flushing forver. Note that flushing
> code also breaks on recorded video. It also gets very strange when
> DiskBuffer or VideoFileBuffer have the unset_pending flag set.
> 
> Note that ReadAheadVideoBuffer makes the frame_pending() flag work
> properly when used with ServerPushJpegBuffer.
> 
> 
> My thoughts so far are to add two new flags, live and flushable.
> 
> Flushable implies live, but not the reverse. If flushable is true, then
> the above flushing code will work. If flushable is not true, then
> frame_pending will always be 1. A ReadAheadBuffer then will
> automatically turn a live, nonflushable stream in to a live flishable
> stream.
> 
> So the code would become:
> 
> while(buffer.flushable() && buffer.frame_pending())
>    ...
> 
> 
> Thoughts?
> 
> -Ed
> 
> 
> 
> 
> 
> 
> _______________________________________________
> libcvd-members mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/libcvd-members


-- 
Gerhard Reitmayr
MIL, Engineering Department, Cambridge University
http://www.eng.cam.ac.uk/~gr281/
tel: +44 1223 765150