Hi Michael,
On Sat, 2002-10-12 at 07:08, Michael H. Schimek wrote:
> Over the past years v4l2 did not receive the attention by skilled people
> it deserves.
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. Don't get me wrong here, I'm not flaming
you down, I'm giving an idea of the status ('stable') v4l2 has had on
this list.
Now, on to the interlacing stuff.
On Sat, 2002-10-12 at 03:21, Michael H. Schimek wrote:
> Sequential, top first:
> /\ < top field
> / \ < top field
> \ / < top field
> / \ < bottom field
> \ / < bottom field
> \/ < bottom field
>
> Sequential, bottom first should be obvious. Alternating puts the top
> field in one buffer, bottom field in the next and so on. Or we start
> alternating with the bottom field, you get the point.
>
> Gerd says a flag only complicates things, so we have a rule top field
> always first. (No matter what I think, he's the maintainer, he gets the
> last word.)
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!), 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.
Ronald
