[mythtv] [mythtv-commits] Ticket #6343: Problem with VDPAU and Temporal 2X deinterlacing

[Taylor Ralph]

--- On Fri, 3/13/09, Mark Kendall <mark.kendall at gmail.com> wrote:

> From: Mark Kendall <mark.kendall at gmail.com>
> Subject: Re: [mythtv] [mythtv-commits] Ticket #6343: Problem with VDPAU and Temporal 2X deinterlacing
> To: "Development of mythtv" <mythtv-dev at mythtv.org>
> Date: Friday, March 13, 2009, 11:20 PM
> 2009/3/13 Taylor Ralph <tralph11 at yahoo.com>:
> > The VDPAU driver seems to already provide
> auto-deinterlacing. IMO the player code should probably not
> auto-detect interlacing when using VDPAU for deinterlacing.
> 
> I'm not sure why you think the driver provides auto
> deinterlacing. If
> you have an interlaced field/frame, you need to tell the
> driver that
> it is interlaced and optionally provide some reference
> frames. The
> more advanced deinterlacers may not apply deinterlacing to
> static
> areas of an image but they are still deinterlacing - and
> hence eating
> GPU resources.

Sorry I got lost in the code and made a bad assumption about the driver.
 
> >The provided sample video shows major glitches in the
> video that I believe have more to do with us turning the
> deinterlacing on and off and clearing the reference frames
> in the VDPAU driver.
> 
> As an aside, I've not been able to download that clip. Any
> chance you
> can try uploading it again (or somewhere else)?

Oh, I was thinking you had already gotten it. Try this link instead: 

http://tinyurl.com/daqea9

Let me know if you still have trouble and I'll figure something out.

> 
> >This can be totally avoided by skipping the AutoDeint()
> funtion in NuppleVideoPlayer. I've been running with this
> change for a couple days now and everything I have plays
> back perfectly >now. It just seems the current method
> being used now is potentially unnecessary and is likely to
> cause problems as I'm already seeing. If we avoid
> AutoDeint() the manual user override >will still function
> properly so I don't see the harm in doing this. I could be
> totally off base here and if so then I'm sorry. Just my
> humble opinion. Thanks again for the great job so far. It
> >rocks!
> 
> OK - this is a broader issue than just vdpau, so I'll try
> and outline
> my thoughts on the subject.
> 
> Firstly, some baseline assumptions:-
> 
> - I think it's probably not unreasonable to assume that
> mythtv
> correctly detects interlaced/progressive content 99% of the
> time
> (certainly the vast majority) and handles it without
> issue.

Agreed. I've _never_ noticed any issues using software playback.

> - when content is genuinely progressive, we ideally do not
> want to
> waste memory and processor cycles (both CPU and GPU)
> running
> deinterlacers.
> - pure progressive material (in my experience) is correctly
> flagged as
> progressive.
> 
> So given those assumptions, how do we deal with the
> remaining 1%?
> 
> Of that 1%, a certain amount is genuinely mixed
> progressive/interlaced. In these cases we still seem to get
> the
> detection right but as you've experienced, there is a small
> glitch
> when transitioning between the 2 for certain (more
> advanced)
> deinterlacers. This is probably easy enough to fix by
> always buffering
> when we have mixed content but it is wasteful on pure
> progressive
> content. So a potential solution for mythtv would be to
> assume
> progressive from the start (it currently assumes
> interlaced), then
> create a deinterlacer when an interlaced sequence is seen
> and do no
> delete it thereafter so that it can buffer (in anticipation
> of more
> interlaced material). There would still be an initial
> glitch when the
> first interlaced content is seen and we would have to
> continue with
> the one frame temporal offset for the entire stream. There
> are
> additional complexities around fallback deinterlacers but
> probably not
> insurmountable. This obviously only applies to certain
> deinterlacers.

That sounds like a great approach and should give the same results that I had by avoiding the AutoDeint() function. I was just annoyed at the continuous glitching throughout an entire recording. :)

> 
> The balance of the 1% is genuinely interlaced material that
> has a mix
> of progressive and interlaced flags (I'm going to ignore
> for the time
> being telecined material). I have one dvb-t channel here
> that seems to
> flip between the 2 almost randomly. I know it's interlaced
> material
> (it's a news channel - the scrolling text is an easy
> giveaway) yet it
> sometimes flips 3 or 4 times a second and sometimes doesn't
> change for
> a couple of minutes. There is no hint in any of the other
> stream flags
> that I can see. Is this valid? I don't know. Clearly all
> televisions,
> set top boxes etc are happy with it because they display it
> properly.
> But are they just assuming its interlaced because they
> never expect
> standard definition progressive material? There are
> probably a number
> of ways to deal with this but I can't currently think of
> one that
> 'just works'.
> 
> I could go on - there is potentially endless detail and any
> number of
> special cases here - but in summary:-
> 
>  - it's not perfect!
>  - it's on my list of things to spend some time one.
>  - whatever solution may be implemented in the future, I
> doubt it's
> going to appease everyone.

Cool. I just wanted to flag the issue and get an understanding of the problem which I now have.

Thanks for the detailed response.

--
Taylor