Behaviour of streaming capture, read() capture and overlay video

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



Hello all,

with the 2.5.x version of Video4Linux2, some problems concerning the
behaviour of streaming capture, read() capture and overlay video arise.

I've discussed this in private with Gerd Knorr, but we haven't come to a
definite solution.

Because all opens on the device have equal rights, there is a need to
specify some sort of importance or "order" of the different things.

First of all, we have to define what the different things are:
- overlay video: clear.
- streaming capture: full fps capture via REQBUFS, STREAMON, QBUF,
DQBUF, STREAMOFF
- read() capture: capture via read() system call.

First question: should capture via read() be able to deliver all frames
(ie 25fps for PAL) by definition?

I think we all agree on the fact, that one application should not be
able to "steal" capture frames from another application that is already
capturing.

But what about overlay <=> capture?

Ok, the first attempt for a definition may be:

"All opens have equal rights and all uses have equal rights"

This would mean overlay and capture cannot be interrupted by each other.
If one application does overlay video (ie. xawtv) another application
(ie. motion detection) cannot do any capture of any sort. Both
applications need to sync each other, so that the first one can do a
"overlay off", before the other one can grab frames.

For driver authors, this is very easy to implement.

Second attempt:

"Capture is always more important than overlay (Regardless of streaming
capture or capture via read())".

This would mean that one application can "steal" the "focus" of an
application that is currently doing overlay video completely. Is this
desirable?

Third attempt:

"Streaming capture can only be activated if no other capture/overlay is
running. But you can capture single frames via read() if overlay is
running."

This is tricky for driver authors. Most of the time, read() and
streaming capture are very similar, so it's possible to steal all frames
from the overlay application via read() by simply calling it endlessly.

To avoid this, the driver has to do some sort of fair queueing. (Not
very elegant and very driver dependend -- not the way we want it, I assume)

Another problem for driver authors: if there is an overlay from
application A and application B wants to capture a frame via read(),
then the driver needs to reprogram the capture engine, then capture the
frame. After that, it needs to reprogram the engine to do overlay video
again, but, most likely, the needed informations are saved in a per-open
  structure for open A, which is not accessible in the read() call by
application B...

One solution would be to save the state of the capture engine, do the
capture, then reprogram it with the old state. But in this case, it
would be almost impossible to get all fps for read() capture because of
the reprogramming overhead.

------------

bttv/saa7134 currently do solution 3) implicitly, with the problem that
other applications can completely steal all frames from the overlay
application by using read(). bttv uses a hack to save the overlay status
before activating the capture, so it can be reprogrammed afterwards.
saa7134 has two independent video tasks, so it's no problem there.

But for other, mostly inferiour hardware this is perhaps a real problem.

So how do we solve these problems? Any ideas are really appreciated.

CU
Michael.






[Index of Archives]     [Linux DVB]     [Video Disk Recorder]     [Asterisk]     [Photo]     [DCCP]     [Netdev]     [Xorg]     [Util Linux NG]     [Xfree86]     [Free Photo Albums]     [Fedora Users]     [Fedora Women]     [ALSA Users]     [ALSA Devel]     [Linux USB]

Powered by Linux