Hey, I've spent the past few weeks attempting to write a high quality video recording application using v4l, and being mostly successful. My (unfinished) source is available at: http://www.sf.net/projects/reetpvr/ I wrote a simple huffyuv-style codec so I get about 50%-60% lossless compression on my frames. I want to reliably capture full 720x240/59.94 or 720x288/50 for recompression to MPEG-2 (so storing 4:2:0 is ok). I'm pretty much there. I've also written a very accurate 3:2 pulldown inverter, and a reliable method of ensuring audio sync accuracy over long recording periods (with some thoughts on handling deviations in video framerate for dealing with VCRs etc). I record closed-captions as well (using diz' decoder) and I wrote a timecode decoder for kicks (kinda neat!). My recorder threads run SCHED_FIFO and fills an mlockall()'d buffer. I usually use my bttv with gbuffers=8. 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 v4l docs are confusing and vague). There's also the FIELDNR ioctl for bttv, but this doesn't seem to be as reliable as using the number from /dev/vbi. There seems to be an inconsistency in the numbers when I start recording and before I've started. So, I'm doing ok, but I'm missing: 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. 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. 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. 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. 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 I'm sure none of my users could figure it out. Thoughts? Advice? How can I help? -- Billy Biggs vektor@xxxxxxxxxxxx
