Brian J. Murrell (v4l@xxxxxxxxxxxxxxx): > > One thing I wrote is a simple prediction-based codec. It's fast > > enough for lossless realtime encoding, but the files it writes are > > massive > > What's the storage rate in terms of bytes/sec.? I get on average 50-60% compression from raw Y'CbCr images. So, say you downsample to 4:2:0, and you're capturing 525/59.94-style video. Each frame uncompressed is (720*480*12/8) == 518400 bytes. So, I compress down to about 260000 bytes on average per frame. I also downsample the chroma from 4:2:2 myself since the bttv driver's chroma downsampling is busted (only takes data from one field). Something to keep in mind if you're writing a recorder. Ugh. The advantage to this compression method is that it is dirt cheap. Doing any DCT-based compression scheme is going to take up like at least 10ms per frame (full resolution), and since you only have like 30ms to play with, it doesn't leave alot of time for, say, displaying the output to the screen or writing to disk. > One thing that I think could be useful for both the OpenPVR project as > well as for V4L in general is a V4L loopback device. The ability to > (re-)capture through the V4L API the contents of a fie which is an > already captured stream would be useful for a) people to play with V4L > that don't have actual hardware (yet) and b) for doing comparisons of > codecs and encoding parameters. Yeah, well, the v4l api sucks. Doing what you request should be pretty trivial, but it seems like a waste to me. The linux scene could benefit more from a userspace video capture library that can also do things like colourspace conversion and chroma resampling for webcams and stuff (and also for live capture). I'd rather work towards that. > I find it very difficult to evaluate the results of differing capture > programs/parameters when the source data is different. Having a few sample clips in a lossless format (like my codec) would be useful then. I can see about posting up some of the samples I use, but it sucks since they're all in about the 1-gig size range. I have some really evil 3:2 pulldown inversion stress tests that I've been meaning to put up anyway. Is that what you meant? -- Billy Biggs vektor@xxxxxxxxxxxx
