Hey Michael, I know about interlaced images. One of my apps is a realtime video deinterlacer for linux. See http://www.sf.net/projects/tvtime/ As such, I have a bit of an interest in making sure I can get accurate information about field parity from V4L devices. :) So, here's what I said: > > 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. If you give me an interlaced frame, and it's a complete frame (or one cropped to scanlines mod 2), 'top field first' tells me temporal order and is sufficient. However, if you give me a sequential mode frame, I'd like to know two things. Whether the first field in the buffer is a top field or a bottom field, and then, which was captured first, top or bottom. That's it. You then give a lecture: Michael H. Schimek (mschimek@xxxxxx): > 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. Glad to hear it. > /\ < 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. Swap every pair of lines? That is useless and would never be done. That was my point. All we need is temporal order. > 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. Well if it's obvious then fine. > 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. I know that frames don't inherently pair. If they did then we wouldn't be having this discussion. > Another way to get this effect is moving one line down in an > interlaced image. Right, but we already decided that V4L won't ever do this. > 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. How is this another question? Are you talking about interlaced frames now? My point for having a flag is so that I can have some code independent of PAL or NTSC, and help driver writers whos cards don't give them the benefit of whether we're in F1 or F2. See the VirtualDub deinterlacing plugins that try to detect whether the frames received are top or bottom field first... Let's avoid that... > 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. I'm just saying I'd rather the flag. > > 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 I've read it. I still find that people are confused. I'll probably write something and contribute it somewhere anyway. -- Billy Biggs vektor@xxxxxxxxxxxx
