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 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
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
