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. Everybody will tell you that you have to maintain binary compatiblity. Breaking the API and existing applications has to be avoided by all means. > 2) An accurate timestamp on the video frames could help. Having this > for all soundcard drivers would be ideal too though, so at this > point I'm not too worried since I need a statistical model anyways. But why don't you use v4l2? v4l2 features timestamping by the driver for both video- and vbi-frames at no extra cost (something which is completly missing with v4l). Correllating frames then is trivial. > 3) Confirmation that how I'm using /dev/vbi will work with other > VBI-supporting capture cards, and/or a method of getting the field > count number for cards which don't. > To detect when I've dropped a video frame (which _should_ never > happen), I'm currently using the /dev/vbi device, which places the field > number in the last 4 bytes of the VBI data (is that even documented > anywhere? The vbi-stuff in v4l is mostly bttv-dependend and documented "only in the source". As you said by yourself: > The v4l docs are confusing and vague) In contrast to that, the v4l2 docs are excellent. The user parts are mostly complete and there is also a drivers' writer guide. So you can be mostly sure that every driver behaves as describes. > There's also the > FIELDNR ioctl for bttv, but this doesn't seem to be as reliable as using Again a bttv-only extension of the api. > Seems again like we could trivially improve the v4l API by adding a > performance ioctl to return the field number and maybe a small list > of timestamps for the last n frames captured (or synced). This > could also be compared to a timestamp in the VBI for correlation. There shouldn't be too much "intelligence" in the driver itself. Most of the stuff can be done in user space. > I don't want to support two APIs, and it seems silly for me to switch > to v4l-2 since it's a pain to get working (at least it was for me) and Unfortunately I don't use a bttv card at all, so someone else has to help you out here. But I don't agree that it's that difficult: for my driver, you simply have to install the latest "videodevX" package (http://www.the-dirks.org/v4l2/) which encapsulates both v4l and v4l2. Then simply install my driver and you're gone. > I'm sure none of my users could figure it out. Any body who is really interested in serios video capture should be able to do this. If not, he or she can learn it. Many times I have read a question like "I'm using kernel 2.4.x and can't get my xyz card to work with bttv" in the mailing list. Most of the time, the first answer was "Upgrade your bttv driver, use the newest version from Gerd Knorr's website". So people need to upgrade / patch / whatever there installation anyway. > Thoughts? Advice? How can I help? I can send you some programming examples, which show the basic usage of v4l2's capture facilities if you are interested. CU Michael.
