My personal opinion, R. Lamberts (R.Lamberts@xxxxxxxxxxxxxxxxxxxxx): > I'm completely new to v4l but hope to use it for an app that needs > low-latency, field rate video capture. [...] > > What do you think would be the right API to choose in this case, v4l > or v4l2? The app could of course be ported at some point from v4l to > v4l2, but I don't oversee the problems this might present... I think it depends on your specific needs. For my application, I needed low-latency field-rate capture, but I also needed to have it work for users who are not able or willing to patch their kernel or move to the 2.5 kernel series. So, supporting v4l was my only option. I see that I am missing two features: a) v4l2 would give me easier access to information about whether I've dropped a frame, and which ones I've dropped. Since my application is built for realtime use this isn't much of an issue, since some simple gettimeofday logic will tell me everything I need to know. b) v4l2 would give me field buffers at field rate while v4l gives me interlaced frames at frame rate. This is a pain, since I have to have sleep logic to simulate field-rate input, but the system I have works. (also, last I heard the v4l2 bttv driver didn't support field-rate capture, but this is probably fixed by now) Of course, when a stable kernel is released with v4l2, then I will add support in my app (and it will clean up my app a bit), but until then, in order to release an application that will be usable by most linux users, and luckily since I have workarounds for all issues I have with it, I support v4l. My code is available at http://tvtime.sourceforge.net if you want to look at my 'workarounds'. -- Billy Biggs vektor@xxxxxxxxxxxx
