Ronald Bultje wrote: > > v4l2 was thought of to be ready to be inserted in 2.5.x. It's not so > much a lack of attention, it's rather a 'don't change a stable API'. > That's not for me specifically, but probably for the experts on this > list too.... The fact that you looked at it doesn't mean that the > experts on this list didn't. When there are so blatant flaws as the one you point out, how could an expert examine v4l2 and still think it's ready to become the future v4l api? Once the issue is on the table of course everyone knew better all the time. But how many people take the initiative and fix it. > 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? > and in case of JPEG with two sequential fields in a buffer, you > can't tell where in the buffer the second field starts, since the length > of the field is unknown to the application! So Gerd, please consider > adding a bottom-first-sequential too. Bottom-first-interlaved isn't > useful, but bottom-first-sequential is, imho. bottom-first-sequential in > our driver simply means that the bottom field arrived (in time) before > the top field to the encoder, so the JPEG-encoded fields have a > bottom-first-sequential order. I hope I'm clear here. The point is: it'd > be useful to allow bottom-first sequential too. Please clarify this for us pre-schoolers. You're talking about compressed data of variable length, and the application must process the _older_ field (possibly stored second in memory) first. Processing in reversed order or scanning forward is no option. 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. The driver could give all four combinations in any case, and independent if the fields are interlaced, sequentially stored, or alternate. Michael
