Ok, I noticed Michael's post. :)
Michael H. Schimek (mschimek@xxxxxx):
> Gerd Knorr wrote:
> >
> > * new field handling, the current v4l2 spec a bit confusing about
> > this. There is now:
> >
> > enum v4l2_field {
> > V4L2_FIELD_ANY = 0, /* driver can choose from none,
> > top, bottom, interlaced
> > depending on whatever it thinks
> > is approximate ... */
> > V4L2_FIELD_NONE = 1, /* this device has no fields ... */
> > V4L2_FIELD_TOP = 2, /* top field only */
> > V4L2_FIELD_BOTTOM = 3, /* bottom field only */
> > V4L2_FIELD_INTERLACED = 4, /* both fields interlaced */
> > V4L2_FIELD_SEQUENTIAL = 5, /* both fields sequential into one
> > buffer */
> > V4L2_FIELD_ALTERNATE = 6, /* both fields alternating into
> > separate buffers */
> > };
>
> > This is not complete. V4L2_FIELD_INTERLACED means what?
> > top-field-first? bottom-field-first? I'd rather see one extra flag
> > being added, V4L2_FIELD_INTERLACED_TOP_FIELD_FIRST and
> > _BOTTOM_FIELD_FIRST, or whatever... For quite some devices (such as
> > the ones supported by the zoran driver), the field order is
> > programmable, and applications can use this.
>
> Guess what, we discussed that. Here's an addendum.
>
> There are two aspects, spatial and temporal order. Spatial order
> matters to correctly combine the fields into a frame. One field goes
> "on top" of the other, hence the talk of top and bottom fields.
> Temporal order determines which field has been transmitted/captured
> first, this is important for motion analysis in deinterlacers and
> codecs.
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.
> We can have flags to indicate field order, or as Gerd suggested, the
> spec requires a particular order. So interlaced and sequential mode
> must store top first and newest first when NTSC-M; top first and
> oldest first otherwise. Applications in need of this information will
> have to check the current video standard. Alternating mode must store
> fields in transmitted/captured order. To determine the spatial order
> v4l2_buffer already flags the field parity. Cropping will be
> restricted to frame lines mod 2 because moving down one line swaps
> fields, i.e. temporal order.
The problem with having the spec require and order is that it makes it
confusing to application authors: it's easy for us to get it wrong. If
there's a field you have to check, then while this might increase the
code slightly, it makes it a little more robust. Looking at your
statement above, I'm already confused. I'm top field first and newest
in one mode, but oldest in another? Am I bottom field first in
interlaced mode in PAL, but maybe not in sequential? Why would that
make any sense? I'd rather just have some flags and be done with it,
having a special flag for the sequential mode storage order. 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.
I don't mind restricting cropping to scanlines mod 2. Sounds
completely reasonable.
--
Billy Biggs
vektor@xxxxxxxxxxxx
