Hi Michael, Op zo 13-10-2002, om 01:44 schreef Michael H. Schimek: > > And *this* is where I'd love to see a sequential-bottom first as well as > > a sequential-top-first. simply because some applications use it (lavrec > > does!), > Why can't lavrec use one pointer for each field and just swap them? It could, but it doesn't, since the spec allows to do sequential JPEG, and that's what we want, so it's much easier to do it that way. The zr36060 JPEG encoder chipset actually stores two-field captures in this way, simply push the encoded data of two fields into the same buffer, sequentially. You can also save them separately (in two distinguished buffers), but sequentially basically makes the application easier, since I don't have to know that there's anything like 'fields', I just capture one frame, move data to file, and that's it. It's some sort of a personal preference thing... > So the driver can store > the top or bottom field, but must always store the _older_ field first > in memory. Right? > Possible I got the standards wrong that top and bottom field not always > coincide with older and newer field. Exactly! Topfield isn't by definition oldest. many people argue that in TV broadcasts (50 fields/sec), there *is* no first field, so you just pick the first field that comes in and determine it's odd/even'ness (don't ask me how ;-) ). > The driver could give all four > combinations in any case, and independent if the fields are interlaced, > sequentially stored, or alternate. Yup. And being able to use each of them would be a good thing, imho. Your point that you could do within alternate buffers is valid, it's just a personal preference of me to keep the fields sequential. Ronald -- - .-. - /V\ | Ronald Bultje <rbultje@xxxxxxxxxxxxxxxxxxx> - // \\ | Running: Linux-2.4.18-3 and OpenBSD 3.0 - /( )\ | http://ronald.bitfreak.net/ - ^^-^^
