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

[Paul Gardiner]

Tom Dexter wrote:
> On Sun, Apr 12, 2009 at 8:33 AM, Paul Gardiner <lists at glidos.net> wrote:
>> Tom Dexter wrote:
>>> That bottom-field-first change, for whatever reason, really was
>>> causing problems with those NBC shows.
>> Thanks. That's useful to know. Not sure of the solution. Theoretically
>> the bottom-field-first change is an improvement, and certain types
>> of content would not display correctly without it. Funny isn't it?!
>> I used the test "y & tff" in my version by mistake. I always intended
>> Mark's logic. Lucky mistake in this instance!
>>
>> One more version worth trying if you at some stage have the time:
>>
>> where you replaced
>>
>>   ((y ^ tff) & 1) == 0
>>
>> by
>>
>>   y & tff
>>
>> could you try
>>
>>   (y & 1) != 0
>>
>> ?
>>
>>
>> First version is "apply algorithm correctly for all frame types"
>>
>> Second is "apply algorithm only for top-field-first frames"
>>
>> Third is "always apply algorithm, but assume top-field-first
>> even if flag says otherwise"
>>
>> Cheers,
>>        Paul.
>>
> 
> OK...now I think we're getting somewhere.  I tried your change above
> and everything looked good.  That got me thinking this:  Perhaps the
> top_field_first is just defaulting to 0 for those progressive frames
> NBC is mixing into the content.  Am I correct that that property
> doesn't really even apply to interlaced frames?  In any case, it
> occurred to me that those may need to be treated like top field first
> interlaced frames to look correct.
> 
> To test that I took the newest 0.21 modified version of Marks patch
> (mythtv-0.21-field-order.6.patch), and simply changed the tff field
> being passed to filter_func to this:
> 
>     filter_func(
>         filter, frame->buf, frame->offsets, frame->pitches,
>         frame->width, frame->height, dirty, frame->top_field_first |
> !frame->interlaced_frame,
>         dirty);
> 
> ...and so far, everything looks flawless.  I'm not sure that this is
> always the desired behavior or not, as I really don't understand
> anything about the ramifications of progressive frames in interlaced
> content.  However, if your broadcasters never mixes progressive frames
> into interlaced content, this change will have no affect at all.
> 
> Let me know what you think.  I'll leave that version installed and see
> how things go, but so far it seems great.

That's brilliant. It gives us a fix that work with Mark's correction.
The one potential problem is it might not work with a mixture of
bottom-field-first, interlaced frames and progressive frames. It might
be worth trying

     filter_func(
         filter, frame->buf, frame->offsets, frame->pitches,
         frame->width, frame->height, dirty |
!frame->interlaced_frame, frame->top_field_first,
         dirty);

instead. That will cause progressive frames to be unaltered, the
only process of them being that needed to overwrite the OSD in
the dirty case (assuming I have my reasoning correct).

Cheers,
	Paul.