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

Tom Dexter digitalaudiorock at gmail.com
Mon Apr 13 13:18:33 UTC 2009


On Mon, Apr 13, 2009 at 5:16 AM, Paul Gardiner <lists at glidos.net> wrote:
> 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.

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?

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 does sound interesting though...I'd think that leaving
progressive frames unaltered should be the ideal approach.

Tom


More information about the mythtv-users mailing list