[mythtv-users] New deinterlacer for perfect image quality when using an interlaced display, mode that matches the source
lists at glidos.net
Mon Apr 13 09:16:07 UTC 2009
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
>> 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"
> 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, frame->buf, frame->offsets, frame->pitches,
> frame->width, frame->height, dirty, frame->top_field_first |
> ...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, frame->buf, frame->offsets, frame->pitches,
frame->width, frame->height, 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).
More information about the mythtv-users