Re: Deinterlace video

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxx> wrote:

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


      

_______________________________________________
vdr mailing list
vdr@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr



[Index of Archives]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Util Linux NG]     [Xfree86]     [Big List of Linux Books]     [Fedora Users]     [Fedora Women]     [ALSA Devel]     [Linux USB]

  Powered by Linux