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

[Tom Dexter]

On Mon, Apr 13, 2009 at 10:32 AM, Paul Gardiner <lists at glidos.net> wrote:
> Tom Dexter wrote:
>>
>> With the change as I have it now, bottom field first and top field
>> first interlaced frames would be treated just like they were, and
>> progressive frames would be treated as top field first.  Are you
>> saying that could cause a problem?
>
> Yeah, I think it might not work for a transmission that was mostly
> bottom-field-first frames, with a few progressive ones thrown in,
> because the progessive frames would be treated the opposite way to
> the rest, which is what gave you bad motion before your change.
>
>> I'll try your change when I get a chance.  Just to be clear...you're
>> change is forcing the parity parameter in filter_func (the parameter
>> that's fed by the 'field' variable in the trunk version) to one for
>> non-interlaced frames...correct?
>
> That's right. Setting the field variable to 1 causes the function
> to use the current frame rather than the previous, which is what
> I think we want for progressive frames.
>
>> That does sound interesting though...I'd think that leaving
>> progressive frames unaltered should be the ideal approach.
>
> Yeah, that's exactly what I'm thinking.
>
> Cheers,
>        Paul.
>

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.

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.

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.

Tom