Ragga Muffin wrote: > > Hello all, > > Could someone briefly explain (or point to up-to-date info) what is > the status of the v4l and v4l2 apis, as well as the > bttv/bttv2 driver ? > > Background: > Last year I wrote a small and simple video capture to disk program > using the v4l api. (bt848 board, NTSC) > Now however, the app needs to be rewritten for *much* better > performance (frame rate etc..) and configurability (capture depth and size > etc..). > > Can someone recommend me a way to go api and driverwise ? > > Many TIA for any insights, > > Ragga 1) bttv has been around a lot longer, and is pretty heavily tested - it is likely to have less problems than bttv2. 2) bttv2 has completely rewritten capture core that gets rid of a lot of historical cruft that bttv has/had (NOTE: I have not had an in depth look at bttv for a long time. When I first started bttv2, bttv had a number of very bad races and lockups). 3) From a capture point of view, the v4l2 API has the following advantages over v4l (in my opinion): - Multi-buffering: You can choose how many capture buffers you want (for short captures you can do a ramdisk type thing, where you allocate enough buffers for your capture, capture to these buffers and write to disk later). In normal use, this also allows you to absorb a lot of I/O latency. - Timestamped capture. Each buffer is timestamped and sequence numbered, as it is captured. This allows you to detect drops, and also synchronise audio capture. 4) In terms of configurability, v4l and v4l2 are basically the same, except that v4l2 allows you to do field capture as well. I'm not sure if there are any disadvantages (except for the fact that bttv2 is relatively untested). Also, take note that I/O bandwidth can often be the determining factor for frame rate. v4l2 does allow you to use a lot of buffers, so you can get closer to the average throughput of your I/O device, but it cannot (obviously) increase your I/O bandwidth. -justin
