Billy Biggs wrote:
>
> When I see 'top field first', I mean that the top field was captured
> first. That is, it is temporal order. The top field is the even
> scanlines starting at 0, therefore calling it "top". So, I see spacial
> order completely determined by terminology in this case. *Except for
> sequential mode*, in which case we now have to deal with two fields
> sequentially in one buffer, in which case the whole
> top/bottom/first/second thing gets confusing.
A frame consist of two interleaved fields. The top field contains the
first line of the frame. The other one is the bottom field. That never
changes.
/\ < top field
/ \ < bottom field
/ \ < top field
\ / < bottom field
\ / < top field
\/ < bottom field
What changes is how you arrange them in a buffer. The image above is
interlaced, top field first stored. When you swap every pair of lines
you get interlaced, bottom first stored. Quite ugly for sure.
Top field only:
/\ < top field
/ \ < top field
\ / < top field
Bottom field only:
/ \ < bottom field
\ / < bottom field
\/ < bottom field
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.)
You know the fields captured by a video camera show a scene at different
time instants. That's how video is effectively 50/60 Hz and we get
motion artefacts in interlaced images. You may not be aware fields don't
inherently pair. The electron beam of a tv continuously paints top
lines, bottom lines, top lines, bottom lines and so on. There is no
frame start to speak of, you can combine the top and bottom lines of any
two successive fields. Naturally the top field always provides the first
line of a frame, regardless if you take fields T B or B T. But something
else changes. In the first case T is the older field, in the second B is
older - the motion runs backwards.
Another way to get this effect is moving one line down in an interlaced
image.
a) original b) copy
/\ < top field
/ \ < bottom field < top field
/ \ < top field < bottom field
\ / < bottom field < top field
\ / < top field < bottom field
\/ < bottom field < top field
*$@&"&! < bottom field
Let's assume b) is what an app got after a read() mishap. The result is
still correctly interlaced, top first, nothing changed. Except now the
apparent top field is really the bottom field and vice versa. Depending
on your point of view either the spatial or temporal order is reversed.
Another question arises. When the hardware captures a series of frames,
are they: T-B, T-B, T-B, T-B or B-T, B-T, B-T, B-T? The field sync
pulses in a video signal clearly identify a first and second field F1,
F2. For our entertainment M/NTSC and M/PAL transmit the bottom lines in
the first field, while all the other standards transmit the top lines
first.
We have no flags, so the "mishap" above is simply not permitted.
Assuming capturing a frame starts with F1 and nothing can change that,
the final rule is top/newer field first when system M, top/older field
first otherwise. Likely all drivers already work this way, it's just
codified for the first time.
> Oh, and
> let's make sure that the header file defines the top/bottom terminology
> conclusively write at the top. I'd be willing to write some text.
Don't bother. I thoughtless volunteered to review the existing spec,
that's why I'm proposing some improvements in the first place. All the
old and new wisdom will end up in a shiny new DocBook full of tables and
diagrams. I strongly advice against learning from the header. There is
much thought behind the api you just won't find there. See old spec at
http://www.thedirks.org/v4l2/v4l2.htm
Michael
