Michael Hunold wrote:
Hello Billy,
please be warned: I'm a strong v4l2 advocate. 8-)
I'm very interested in applications like yours, but unfortunately
most of the promising stuff is v4l-based, very bttv-dependend
or both.
I have written a v4l2 driver for video cards that are based
on the "saa7146" chipset. I decided to drop v4l completely,
because I spend most of the developing time to make my
driver "as bttv as possible" which is ridiculous for a device
driver.
I admit that there a not many non-bttv cards on the market, but
for example the "saa7146" can be found on many "professional"
cards, because it's more expensive.
I personally know my v4l2 driver, the driver for Winnov cards
and a v4l2 driver for the Matrox Meteor cards.
1) An accurate way of correllating /dev/vbi frames with the video, to
make my timecode decoder more useful. I could try and compare
lines 20/21 of the VBI, but that seems ridiculous. This problem
seems easily fixable in the API. Why not throw another int into
the vbi data saying which buffer the frame was filled into? Nasty
hack, but regardless it seems like we can trivially fix the API.
...
For a new application, I would say, go with v4l2. v4l2 should be in the
2.5 series kernel, and with Gerd's new patches, it is becomming easier
to set up a 2.4 kernel with v4l2 (http://www.bytesex.org - look at the
bttv0.8.x series).
v4l is horribly bttv specific, and practically worthless for serious
video capture applications.
v4l2 is designed from the ground up to be a completely generic, yet
flexible interface. It easily handles all the challenges of video
recording.
If you want a simple example of fully API compliant v4l and v4l2
capture, have a look at NVrec on http://www.ee.up.ac.za/~justin/v4l2.
Look out for all the comments in v4l1_core.c - you can easily see my
opinion of v4l there!
-justin
