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 tlenz@vorgon.com wrote:
From: Timothy D. Lenz tlenz@vorgon.com Subject: Re: [vdr] Deinterlace video To: "VDR Mailing List" vdr@linuxtv.org 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 Houghtonh@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 vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr