[mythtv-users] New deinterlacer for perfect image quality when using an interlaced display, mode that matches the source

[Paul Gardiner]

Tom Dexter wrote:
> On Wed, Apr 15, 2009 at 5:24 AM, Paul Gardiner <lists at glidos.net> wrote:
>> Tom Dexter wrote:
>>> OK...I've tested that new change with the 'parity' parameter
>>> defaulting to 1 for non-interlaces frames and everything looks great.
>>> That definitely seems to be the way to go.
>> Great news. I think we can go with that version. One of us should
>> upload a patch. Shall I, or do you want to?
> 
> I just uploaded new versions of both patches with that change.

Yeah, saw those go up. Looks great.

>>> One small cosmetic thing I've noticed, and I believe it's been the
>>> case with all versions:  When I have OSD fade enabled and there's any
>>> situation where more than one thing displays via the OSD at a time,
>>> the fade caused some video stuttering.  One place I tend to see it is
>>> if I save my place in the recording...that displays the message saying
>>> the position has been saved in addition to displaying the progress
>>> bar.  When those fade it tends to stutter a bit.  I also get a CPU
>>> spike when that happens.  This never occurs with any single OSD
>>> overlay, and also doesn't happen if I disable fading.
>>>
>>> Very minor for sure.  I see that it doesn't happen with bob x2.
>> That's probably not surprising. I think with bob the OSD is rendered
>> to Bob's halfheight buffer. Everything's a lot cheaper with bob.
>> You might find the same stutter with yadif. There is some room for
>> speeding up field order using faster memcpy. Perhaps should look at
>> that sometime.
>>
> 
> Yea, from what I'm seeing I think that multiple OSD layers trying to
> fade is simply maxing out the CPU momentarily.  Not surprising.  I'd
> never even heard of using a faster memcpy.  I'm running under Gentoo
> specifically compiled for P4...I'm not sure if there's any such thing
> available or not.  Is that generally a change to glibc or something?

If you have a look at yadif, you can see it's use of aclib, although
from what I can see it's disabled by a final assignment to standard
memcpy. Because it looked disabled, I didn't dare try using it in
the field order deinterlacer.

>>> By the way, I took the time to do some comparisons between this
>>> deinterlacer and bob x2 that I was using before.  Wow...the difference
>>> is _not_ subtle at all.  This thing has definitely cured the one major
>>> flaw I've lived with since I built the system two years ago.  Great
>>> stuff.
>> I'm still sometimes seeing slight strangeness in motion. And sometimes
>> I think I prefer yadif. Certainly rolling text credits show that field
>> order is doing exactly what it should, but I wonder whether there are
>> periods in normal playback where the mpeg decode is complex, which
>> leads to the sync changing rappidly. yadif may cope with that better.
>> The other possibility I can think of is that the slight blurring due
>> to yadif is sometimes beneficial.
>>
>> Cheers,
>>        Paul.
>>
> 
> It's been much better than anything I've used.  From what I remember,
> I don't think my frontend will run yadif.  It's a 3Ghz P4.

The few oddities I am seeing may be down to the deinterlacer in my TV.
Although it's a CRT TV, it's 100Hz capable, and from what I can tell
deinterlaces and reintlaces even when told to do normal scan. I think
a bit of motion blur can help it out sometimes.

P.