> One solution is to write a suite of tiny apps that make various V4L > ioctls, and assume that the driver saves the states of these settings > across open/close. (v4lset -blah; cat) </dev/video0 | ... You are absolutely right about the lack of a 'what formats can I set' ioctl. > the video parameters on open so that things are at least consistent, but > this effectively makes it impossible to write a hardware-independent > read-based script. Interesting. Should V4L mark 2 document this, document the other behaviour which some apps rely on and/or provide an ioctl that resests ot defaults ? > The solution, IMHO, is to do something like "vidcat -d /dev/video0 -s > 352x288 -f jpeg | magicperlbits", and forget about read altogether. Do > you see any disadvantage to that? Read is the more of an easy to use API. > > convert_fromfmt_tofmt(from, to > Not to nitpick, but wouldn't this be better: > convert(src, srcformat, dest, destformat) Whichever.. > >
