[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[libcvd-members] Semantics of frame_pending?

From: Edward Rosten
Subject: [libcvd-members] Semantics of frame_pending?
Date: Thu, 28 Aug 2008 12:39:04 -0600 (MDT)

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:

        //Burn frames

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())



reply via email to

[Prev in Thread] Current Thread [Next in Thread]