On Mon, 2018-06-04 at 07:25 +0200, Krzysztof Hałasa wrote: > Steve Longerbeam <slongerbeam@xxxxxxxxx> writes: > > > I think we should return to enforcing field order to userspace that > > matches field order from the source, which is what I had implemented > > previously. I agree with you that we should put off allowing inverting > > field order. > > There is no any particular field order at the source, most of the time. > The odd field is followed by the even field, and so on, sure. But there > is no "first" and "second" field, any field can be the "first". There is no particular field order in the data itself. But for BT.656 there is a specific field order, defined by the F flag in the SAV/EAV codes. For PAL usually F=0 is the top field and F=1 is the bottom field. For NTSC it usually is the other way around. > The exception to this is a camera with a progressive sensor - both > "fields" are taken at the same time and transmitted one after the other, > so in this case the order is defined (by the camera, e.g. B-T on DV even > with PAL version). But this isn't exactly PAL/NTSC. That's why I'd like to make it obvious to the user when the field order is switched. Whoever selects seq-bt -> seq-tb or seq-tb -> seq-bt transformation for progressive sources can expect combing artifacts. regards Philipp
