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

[Mark Kendall]

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.

>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)?

>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.
- 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.

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.

Regards

Mark