> Here is my take on S_FMT vs STREAMON locking:
> S_FMT - only need memory for two capture resources.
Don't think this is a big plus. Given you need plenty of
memory for the video frames anyway...
> - better defined capture states in capture engine.
Why?
> - no way of releasing resources without closing the open.
That's IMHO a major reason against S_FMT locking.
> - allows "feedback" so the app can determine which resources are
> currently available.
Ha! I have this on my page too (at the bottom). A flag for S_FMT which
allows a app to specify if the driver should check against device
capabilities or against the currently available ressources might work
with STREAMON locking.
> (Gerd, could you please repost the URL for the multiple opens draft? I
> accidentally nuked that one.)
http://www.strusel007.de/linux/bttv/multiple-opens.html
Gerd
--
Protecting the children is a good way to get a lot of adults who cant
stand up for themselves. -- seen in some sig on /.
_______________________________________________
Video4linux-list mailing list
[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/video4linux-list