I believe the issue with this flag is understandable when you consider the very simple nature of most set-top boxes decoding broadcast digital TV. It will always send video to the TV interlaced regardless of the content. So it does not care about de-interlacing. However it does need to know how to convert the decoded frame colour space and for this the interlace flag I suspect can be relied upon.
If the content is flagged as interlaced, separate the decoded YUV frame into separate YUV fields then convert to RGB. If the flag is clear convert the decoded YUV frame to RGB. For all material send to the TV interlaced at the appropriate resolution. This will also be important if the applicatgion is ever likely to display video media other than broadcast TV where it is flagged as progressive. If however you wish to de-interlace the picture you will need sophisticated pulldown detection which will disable the deinterlacer when progressive content is detected. To detect 2:2 pulldown for example (typical progressive source material broadcast in the UK) you would need to detect combing artefacts within successive decoded frames. No combing/mouse teeth for several consecutive frames would then cause the de-interlacer to be disabled. 3:2 pulldown is a little easier to detect because there are flags to indicate fields must be repeated. However reconstruction and display of 3:2 video is more complicated. --- On Wed, 19/1/11, Timothy D. Lenz <tl...@vorgon.com> wrote: > From: Timothy D. Lenz <tl...@vorgon.com> > Subject: Re: [vdr] Deinterlace video > To: "VDR Mailing List" <email@example.com> > Date: Wednesday, 19 January, 2011, 19:25 > Is it possible to figure out if the > stream is interlaced or not by looking at the stream? Seems > like it should be able to figure out within a frame or two > (.033ms) and then just ignore the useless flags? Needs to be > done with epg data. I think the Insignia boxes just try to > read data regardless of flags because they are able to find > data when atscepg won't. > > On 1/19/2011 8:55 AM, VDR User wrote: > > On Wed, Jan 19, 2011 at 5:47 AM, Tony Houghton<h...@realh.co.uk> > wrote: > >> I thought there was supposed to be a flag in MPEG > meta data which > >> indicates whether pairs of fields are interlaced > or progressive so > >> decoders can determine how to combine them without > doing any complicated > >> picture analysis. Are broadcasters not using the > flag properly, or xine > >> not reading it? xine-ui's preferences dialog has > an option to disable > >> interlacing for progressive material, have you set > that in whichever > >> front-end you're using? > > > > There is. Unfortunately I can't begin to count > the number of times > > I've seen the flag set incorrectly, essentially making > it useless. > > > > _______________________________________________ > > vdr mailing list > > firstname.lastname@example.org > > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr > > > > _______________________________________________ > vdr mailing list > email@example.com > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr > _______________________________________________ vdr mailing list firstname.lastname@example.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr