Michael Hunold ([EMAIL PROTECTED]): > > It sounds like the driver is giving bottom-field-first frames > > instead of top-field-first. > > To be honest: it's undefined, if you specify V4L2_FIELD_INTERLACED or > V4L2_FIELD_ANY. But it's possible that I screwed up somewhere within > my capture engine.
Well, why don't we define it, or define a way to specify it. If V4L2 supports an interlaced mode, but no way to indicate temporal order, then that interlaced mode is useless in any application. One thing we could have is just a control that you query and it tells you the order. ? > TOP and BOTTOM are useless for you, because the other field is lost. > When using interlaced, the field order is undefined. Do you mean that you don't know? > Please have a look at http://bytesex.org/v4l/spec/x3565.html. This is the document that says: Images contain both fields, interleaved line by line. The temporal order of the fields (whether the top or bottom field is first transmitted) depends on the current video standard. M/NTSC transmits the bottom field first, all other standards the top field first. Which to me is completely broken. There's no good reason why it should have anything to do with norm. > I think that capturing fields into separate buffers with > V4L2_FIELD_ALTERNATE is the best for you, is it? Yes it is ideal for my application, but it means another week of coding time still, since it means rewriting or reorganizing my main loop (It means supporting this new clock mode, and I have to make sure everything deals with stride correctly - it should already, but I expect there may be bugs). I'd much rather wait on supporting that until a later release, as my time is short near the end of the school term, and there are too many new features in this release as it is. -Billy -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
