Mailing List Archive

1 2 3  View All
Re: New deinterlacer for perfect image quality when using an interlaced display, mode that matches the source [ In reply to ]
Tom Dexter wrote:
> On Wed, Apr 8, 2009 at 5:30 AM, Paul Gardiner <lists@glidos.net> wrote:
>> Jean-Yves Avenard wrote:
>>> Hi
>>>
>>> 2009/4/8 Jean-Yves Avenard <jyavenard@gmail.com>:
>>>> Where can I find this field-order no-flicker patch ?
>>>>
>>> Ooops, I see that you submitted it with the 6391 ticket.
>>>
>>> Any chance that you will adapt those OSD fixes on your backport of Mark's
>>> patch
>> I believe You can take the backport of Mark's patch,
>> mythtv-0.21-field-order.6.patch, as is. The two things I fix in
>> mythtv-0.21-field-order-no-flicker.patch, Mark already fixed in what he
>> comitted to trunk. The no-flicker patch was just my playing catch up,
>> in case Tom continued to have problems with mythtv-0.21-field-order.6.patch.
>>
>> Cheers,
>> Paul.
>>
>
> Believe it or not, I have an episode of Medium (NBC) from Monday night
> that's not cooperating well with the deinterlacer (in this case the
> mythtv-0.21-field-order.6.patch version). It the same thing I saw on
> that ER episode. It's not so much tearing as odd, almost slightly
> jerky motion...almost like when a show intensionally uses special
> effects to create that sort of choppy/jumpy motion, but not that
> pronounced.

Why Medium?! If they are going to mess things up, at least pick some
rubbishy program that no one will care about!! I've recently discovered
Medium. Watching the first series and loving it.

> This time my wife was able to see it for sure this time. I can almost
> guarantee these issues are related to the manner in which NBC mixes
> progressive frames into their 1080i stuff. If that's the case, I have
> a feeling it will do the same with all versions of the
> deinterlacer...unless for some reason, it only occurs only with that
> OSD flicker fix. I saved the show and will try it with both other
> versions when I get a chance. I'm unclear as to why it on;y seems to
> happen with specific programs...perhaps it depends on the amount of
> progressive frames.

Could it be that the content is just hard enough to decode that MythTv
is dropping a few frames. Interlaced x2 will look awful if frames are
being dropped. You'll sometimes see motion taking backward steps. I
guess another possibility is that the content truly has bad motion,
and the better resolution you are getting with Interlaced x2 is making
the problem show more than Bob does. Next episode, you could try your
commercial decoder.

> It's an elusive issue though. You can see the odd motion plainly on
> part of a show, but jump back to the same place and have it work
> fine...really annoying. I also noticed that the show in general just
> doesn't look that good...not as good as my 720p recordings and nowhere
> near the 1080i stuff like, for example, PBS, which looks perfect.

That does sound like they've done a bad conversion.

Cheers,
Paul.

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
Re: New deinterlacer for perfect image quality when using an interlaced display, mode that matches the source [ In reply to ]
On Thu, Apr 9, 2009 at 6:24 AM, Paul Gardiner <lists@glidos.net> wrote:
> Tom Dexter wrote:
>>
>>
>> Believe it or not, I have an episode of Medium (NBC) from Monday night
>> that's not cooperating well with the deinterlacer (in this case the
>> mythtv-0.21-field-order.6.patch version).  It the same thing I saw on
>> that ER episode.  It's not so much tearing as odd, almost slightly
>> jerky motion...almost like when a show intensionally uses special
>> effects to create that sort of choppy/jumpy motion, but not that
>> pronounced.
>
> Why Medium?! If they are going to mess things up, at least pick some
> rubbishy program that no one will care about!! I've recently discovered
> Medium. Watching the first series and loving it.
>
>> This time my wife was able to see it for sure this time.  I can almost
>> guarantee these issues are related to the manner in which NBC mixes
>> progressive frames into their 1080i stuff.  If that's the case, I have
>> a feeling it will do the same with all versions of the
>> deinterlacer...unless for some reason, it only occurs only with that
>> OSD flicker fix.  I saved the show and will try it with both other
>> versions when I get a chance.  I'm unclear as to why it on;y seems to
>> happen with specific programs...perhaps it depends on the amount of
>> progressive frames.
>
> Could it be that the content is just hard enough to decode that MythTv
> is dropping a few frames. Interlaced x2 will look awful if frames are
> being dropped. You'll sometimes see motion taking backward steps. I
> guess another possibility is that the content truly has bad motion,
> and the better resolution you are getting with Interlaced x2 is making
> the problem show more than Bob does. Next episode, you could try your
> commercial decoder.
>
>> It's an elusive issue though.  You can see the odd motion plainly on
>> part of a show, but jump back to the same place and have it work
>> fine...really annoying.  I also noticed that the show in general just
>> doesn't look that good...not as good as my 720p recordings and nowhere
>> near the 1080i stuff like, for example, PBS, which looks perfect.
>
> That does sound like they've done a bad conversion.
>
> Cheers,
>        Paul.
>

An update on my ongoing testing. Since it takes me over an hour to
compile, and the fact that I can't do it during evening TV watching
time :D, I'm a little limited as to when i can do this sort of stuff.

First of all, I noticed the same motion issues with my recording of
Law and Order: SVU from Tuesday...so I have more content to test with.

This morning I compiled with your original patch (the one without the
OSD flicker fix). Believe it or not, both shows look fine with
that...no problems at all. I even watched a good portion of Medium
over again to make sure.

Tomorrow morning I'm going to try again with the version of the
original patch that has to OSD flicker fix just to see if for some
reason that's related. I don't know if this means anything, but I
noticed something interesting. For me the OSD flickering (without the
fix for it) seems to primarily be an issue with content that has those
progressive frames mixed in...the same sort of content that tends to
cause the motion issues. Tonight my wife is watching Survivor, which
is in 1080i on CBS...but those sorts of shows (unlike dramas on NBC
and CBS) never have the progressive frames from what I've seen.
Interestingly, while watching that there's almost no noticeable OSD
flicker, even in the playback menu. That's still using the original
patch.

In any case this all would seem to rule out decoding or dropped frame
issues, as that's all been the same in both tests so far.

I'll post back tomorrow after more testing.

Tom
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
Re: New deinterlacer for perfect image quality when using an interlaced display, mode that matches the source [ In reply to ]
Tom Dexter wrote:
> An update on my ongoing testing. Since it takes me over an hour to
> compile, and the fact that I can't do it during evening TV watching
> time :D, I'm a little limited as to when i can do this sort of stuff.
>
> First of all, I noticed the same motion issues with my recording of
> Law and Order: SVU from Tuesday...so I have more content to test with.
>
> This morning I compiled with your original patch (the one without the
> OSD flicker fix). Believe it or not, both shows look fine with
> that...no problems at all. I even watched a good portion of Medium
> over again to make sure.

That's good news. If nothing else, at least this means you have a
solution. It also has to be very useful information for getting
to understand the problem.

> Tomorrow morning I'm going to try again with the version of the
> original patch that has to OSD flicker fix just to see if for some
> reason that's related.

Yeah, that would be a good test. I'd expect the problem to return
with that patch because, as far as I can tell, it does the same job
as Mark's verion. If the problem does return, one more change worth
trying is to change - in function "filter_func" - the inner condition
from

((y ^ tff) & 1) == 0

to

y & tff


The no-flicker patch actually has two alterations, one to remove the
flicker and the other to deal with bottom-field-first content. The
change I suggest above will retain the flicker fix, but revert the
bottom-field-first fix.

> I don't know if this means anything, but I
> noticed something interesting. For me the OSD flickering (without the
> fix for it) seems to primarily be an issue with content that has those
> progressive frames mixed in...the same sort of content that tends to
> cause the motion issues. Tonight my wife is watching Survivor, which
> is in 1080i on CBS...but those sorts of shows (unlike dramas on NBC
> and CBS) never have the progressive frames from what I've seen.
> Interestingly, while watching that there's almost no noticeable OSD
> flicker, even in the playback menu. That's still using the original
> patch.

That's interesting. That again may tell us a lot.

I find it hard to see the flicker problem sometimes. I wondered
whether it shows only when some movement in the picture causes your eyes
to scan the screen.

> In any case this all would seem to rule out decoding or dropped frame
> issues, as that's all been the same in both tests so far.

I guess it's still possible but unlikely: there's a small possibility
that the difference in efficiency of the two versions might be just
enough to cause frame dropping. Come to think of it, both Mark's and
my flicker fixed versions do 50% more memcpys than the non fixed one.

> I'll post back tomorrow after more testing.

Great. Hopefully we can get this sorted eventually.

Cheers,
Paul.

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
Re: New deinterlacer for perfect image quality when using an interlaced display, mode that matches the source [ In reply to ]
On Fri, Apr 10, 2009 at 6:50 AM, Paul Gardiner <lists@glidos.net> wrote:
> Tom Dexter wrote:
>>
>> An update on my ongoing testing.  Since it takes me over an hour to
>> compile, and the fact that I can't do it during evening TV watching
>> time :D, I'm a little limited as to when i can do this sort of stuff.
>>
>> First of all, I noticed the same motion issues with my recording of
>> Law and Order: SVU from Tuesday...so I have more content to test with.
>>
>> This morning I compiled with your original patch (the one without the
>> OSD flicker fix).  Believe it or not, both shows look fine with
>> that...no problems at all.  I even watched a good portion of Medium
>> over again to make sure.
>
> That's good news. If nothing else, at least this means you have a
> solution. It also has to be very useful information for getting
> to understand the problem.
>
>> Tomorrow morning I'm going to try again with the version of the
>> original patch that has to OSD flicker fix just to see if for some
>> reason that's related.
>
> Yeah, that would be a good test. I'd expect the problem to return
> with that patch because, as far as I can tell, it does the same job
> as Mark's verion. If the problem does return, one more change worth
> trying is to change - in function "filter_func" - the inner condition
> from
>
> ((y ^ tff) & 1) == 0
>
> to
>
> y & tff
>
>
> The no-flicker patch actually has two alterations, one to remove the
> flicker and the other to deal with bottom-field-first content. The
> change I suggest above will retain the flicker fix, but revert the
> bottom-field-first fix.
>

Yup...it looks as though the bottom-field-first fix is causing it.

My first test today was using the version of the original patch with
both the OSD flicker and bottom-field-first fixes. The problem was
there for sure. One of the clear signs of this issue shows up not
necessarily with significant motion (the kind where you'd notice
tearing), but for example, with people talking...not an audio/video
sync problem, but rather an almost animated look when people are
talking...extremely unnerving and unnatural looking when it happens.

However with the bottom-field-first fix removed as per your above
change, everything's fine.

So it appears that that fix, in conjunction with some 1080i content
that has progressive frames mixed in (NBC stuff specifically) is
causing this.

Interestingly though, I've yet to have any similar problems with CBS
shows, and they tend to do the same...though possibly less. One
difference between NBC dramas and CBS though is that NBC also uses
different frame rates for commercials. That's what causes the issue
where the OSD will show a one hour show was, say, 51 minutes...because
myth is assuming a constant frame rate when calculating the length. I
wonder if that's in any way related.

Tom
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
Re: New deinterlacer for perfect image quality when using an interlaced display, mode that matches the source [ In reply to ]
On Sun, Mar 29, 2009 at 2:58 PM, Paul Gardiner <lists@glidos.net> wrote:

> I think I've just sussed what is causing this. The deinterlacer gets
> given each frame twice. Each time it overwrites the bottom field,
> but leaves the top field unchanged. After each call the OSD will
> be rendered over the frame. The fact that I don't update the
> top field in the second call to the deinterlacer means the OSD gets
> rendered over the top of a previous rendering. That doesn't matter
> for a solid OSD, but if translucent the top field will be
> darker than the bottom.
>
> Should be easy to fix:
>
> Change
>
>   if (y & tff)
>   {
>       if(parity)
>       {
>           /* Second call: put back the second field to its previous state */
>           memcpy(dst + dst_offsets[i] + y*dst_stride[i],
> &p->ref[nr_c][i][y*refs], w);
>       }
>       else
>       {
>           /* First call: replace second field by that of the previous frame
> */
>           memcpy(dst + dst_offsets[i] + y*dst_stride[i],
> &p->ref[nr_p][i][y*refs], w);
>       }
>   }
>
> to
>   if(parity)
>   {
>       /* Second call: put back the whole frame to its previous state.
>        * Although we have not altered first field, we need to overwrite
>        * it because the OSD will have been rendered to the copy passed
>        * in. */
>       memcpy(dst + dst_offsets[i] + y*dst_stride[i],
> &p->ref[nr_c][i][y*refs], w);
>   }
>   else
>   {
>       /* First call: replace second field by that of the previous frame */
>       if (y & tff)
>       {
>           memcpy(dst + dst_offsets[i] + y*dst_stride[i],
> &p->ref[nr_p][i][y*refs], w);
>       }
>   }
>

Paul...a quick question about this OSD flicker fix. Can you think of
any reason that this fix could affect overall clarity of 1080i in any
way? I'm probably just getting cross-eyed from all this testing :D,
but I almost thought the version without this fix may have been
slightly clearer. It's too bad I have no way to test one right after
the other...I can only switch after a one hour re-compile.

Just curious. If there is in fact any difference it's extremely
subtle, and may be only with those NBC shows.

Tom
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
Re: New deinterlacer for perfect image quality when using an interlaced display, mode that matches the source [ In reply to ]
On Fri, Apr 10, 2009 at 1:52 PM, Tom Dexter <digitalaudiorock@gmail.com> wrote:
> On Sun, Mar 29, 2009 at 2:58 PM, Paul Gardiner <lists@glidos.net> wrote:
>
>> I think I've just sussed what is causing this. The deinterlacer gets
>> given each frame twice. Each time it overwrites the bottom field,
>> but leaves the top field unchanged. After each call the OSD will
>> be rendered over the frame. The fact that I don't update the
>> top field in the second call to the deinterlacer means the OSD gets
>> rendered over the top of a previous rendering. That doesn't matter
>> for a solid OSD, but if translucent the top field will be
>> darker than the bottom.
>>
>> Should be easy to fix:
>>
>> Change
>>
>>   if (y & tff)
>>   {
>>       if(parity)
>>       {
>>           /* Second call: put back the second field to its previous state */
>>           memcpy(dst + dst_offsets[i] + y*dst_stride[i],
>> &p->ref[nr_c][i][y*refs], w);
>>       }
>>       else
>>       {
>>           /* First call: replace second field by that of the previous frame
>> */
>>           memcpy(dst + dst_offsets[i] + y*dst_stride[i],
>> &p->ref[nr_p][i][y*refs], w);
>>       }
>>   }
>>
>> to
>>   if(parity)
>>   {
>>       /* Second call: put back the whole frame to its previous state.
>>        * Although we have not altered first field, we need to overwrite
>>        * it because the OSD will have been rendered to the copy passed
>>        * in. */
>>       memcpy(dst + dst_offsets[i] + y*dst_stride[i],
>> &p->ref[nr_c][i][y*refs], w);
>>   }
>>   else
>>   {
>>       /* First call: replace second field by that of the previous frame */
>>       if (y & tff)
>>       {
>>           memcpy(dst + dst_offsets[i] + y*dst_stride[i],
>> &p->ref[nr_p][i][y*refs], w);
>>       }
>>   }
>>
>
> Paul...a quick question about this OSD flicker fix.  Can you think of
> any reason that this fix could affect overall clarity of 1080i in any
> way?  I'm probably just getting cross-eyed from all this testing :D,
> but I almost thought the version without this fix may have been
> slightly clearer.  It's too bad I have no way to test one right after
> the other...I can only switch after a one hour re-compile.
>
> Just curious.  If there is in fact any difference it's extremely
> subtle, and may be only with those NBC shows.
>
> Tom
>

Never mind on that one. After watching several shows in proper
lighting etc (using the original patch with the OSD flicker fix but
not the bottom-field-first fix), everything looks really
spectacular...even the Law and Order SVU that was one of the problem
recordings.

That bottom-field-first change, for whatever reason, really was
causing problems with those NBC shows.

Tom
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
Re: New deinterlacer for perfect image quality when using an interlaced display, mode that matches the source [ In reply to ]
Tom Dexter wrote:
> On Fri, Apr 10, 2009 at 1:52 PM, Tom Dexter <digitalaudiorock@gmail.com> wrote:
>> On Sun, Mar 29, 2009 at 2:58 PM, Paul Gardiner <lists@glidos.net> wrote:
>>
>>> I think I've just sussed what is causing this. The deinterlacer gets
>>> given each frame twice. Each time it overwrites the bottom field,
>>> but leaves the top field unchanged. After each call the OSD will
>>> be rendered over the frame. The fact that I don't update the
>>> top field in the second call to the deinterlacer means the OSD gets
>>> rendered over the top of a previous rendering. That doesn't matter
>>> for a solid OSD, but if translucent the top field will be
>>> darker than the bottom.
>>>
>>> Should be easy to fix:
>>>
>>> Change
>>>
>>> if (y & tff)
>>> {
>>> if(parity)
>>> {
>>> /* Second call: put back the second field to its previous state */
>>> memcpy(dst + dst_offsets[i] + y*dst_stride[i],
>>> &p->ref[nr_c][i][y*refs], w);
>>> }
>>> else
>>> {
>>> /* First call: replace second field by that of the previous frame
>>> */
>>> memcpy(dst + dst_offsets[i] + y*dst_stride[i],
>>> &p->ref[nr_p][i][y*refs], w);
>>> }
>>> }
>>>
>>> to
>>> if(parity)
>>> {
>>> /* Second call: put back the whole frame to its previous state.
>>> * Although we have not altered first field, we need to overwrite
>>> * it because the OSD will have been rendered to the copy passed
>>> * in. */
>>> memcpy(dst + dst_offsets[i] + y*dst_stride[i],
>>> &p->ref[nr_c][i][y*refs], w);
>>> }
>>> else
>>> {
>>> /* First call: replace second field by that of the previous frame */
>>> if (y & tff)
>>> {
>>> memcpy(dst + dst_offsets[i] + y*dst_stride[i],
>>> &p->ref[nr_p][i][y*refs], w);
>>> }
>>> }
>>>
>> Paul...a quick question about this OSD flicker fix. Can you think of
>> any reason that this fix could affect overall clarity of 1080i in any
>> way? I'm probably just getting cross-eyed from all this testing :D,
>> but I almost thought the version without this fix may have been
>> slightly clearer. It's too bad I have no way to test one right after
>> the other...I can only switch after a one hour re-compile.
>>
>> Just curious. If there is in fact any difference it's extremely
>> subtle, and may be only with those NBC shows.
>>
>> Tom
>>
>
> Never mind on that one. After watching several shows in proper
> lighting etc (using the original patch with the OSD flicker fix but
> not the bottom-field-first fix), everything looks really
> spectacular...even the Law and Order SVU that was one of the problem
> recordings.
>
> 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.

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
Re: New deinterlacer for perfect image quality when using an interlaced display, mode that matches the source [ In reply to ]
On Sun, Apr 12, 2009 at 8:33 AM, Paul Gardiner <lists@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.

Tom
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
Re: New deinterlacer for perfect image quality when using an interlaced display, mode that matches the source [ In reply to ]
Tom Dexter wrote:
> On Sun, Apr 12, 2009 at 8:33 AM, Paul Gardiner <lists@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.

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
Re: New deinterlacer for perfect image quality when using an interlaced display, mode that matches the source [ In reply to ]
On Mon, Apr 13, 2009 at 5:16 AM, Paul Gardiner <lists@glidos.net> wrote:
> Tom Dexter wrote:
>>
>> On Sun, Apr 12, 2009 at 8:33 AM, Paul Gardiner <lists@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
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
Re: New deinterlacer for perfect image quality when using an interlaced display, mode that matches the source [ In reply to ]
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.

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
Re: New deinterlacer for perfect image quality when using an interlaced display, mode that matches the source [ In reply to ]
On Mon, Apr 13, 2009 at 10:32 AM, Paul Gardiner <lists@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
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
Re: New deinterlacer for perfect image quality when using an interlaced display, mode that matches the source [ In reply to ]
Pardon my ignorance on this...

Is this at all useful if I have a 1080p display and am using hdmi?

I am assuming that this will not work with VDPAU, is this correct?

Cheers

Phil
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
Re: New deinterlacer for perfect image quality when using an interlaced display, mode that matches the source [ In reply to ]
Phil Wild wrote:
> Pardon my ignorance on this...
>
> Is this at all useful if I have a 1080p display and am using hdmi?
>
> I am assuming that this will not work with VDPAU, is this correct?

It is possibly useful if your 1080p display will accept 1080i and
has it's own high quality deinterlacer. But as you say it wont work
with VDPAU (as far as I know), and hence even if you did get a slight
improvement in image quality, it may not be worth it for the CPU
usage. And you would get an improvement only if the displays
deinterlacer is better than the VDPAU ones.

For people using a 1080i capable display but not using VDPAU, yes
worth a try.

Cheers,
Paul.

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
Re: New deinterlacer for perfect image quality when using an interlaced display, mode that matches the source [ In reply to ]
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?

> 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.

> 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.

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
Re: New deinterlacer for perfect image quality when using an interlaced display, mode that matches the source [ In reply to ]
On Wed, Apr 15, 2009 at 5:24 AM, Paul Gardiner <lists@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.

>
>> 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?

>> 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.

Tom
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
Re: New deinterlacer for perfect image quality when using an interlaced display, mode that matches the source [ In reply to ]
Tom Dexter wrote:
> On Wed, Apr 15, 2009 at 5:24 AM, Paul Gardiner <lists@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.

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
Re: New deinterlacer for perfect image quality when using an interlaced display, mode that matches the source [ In reply to ]
On Thu, Mar 26, 2009 at 8:26 AM, Paul Gardiner <lists@glidos.net> wrote:
> I've just created a patch that provides a deinterlacer for perfect image
> quality and motion smoothness when using an interlaced display mode that
> exactly matches the video source. See Ticket #6391. The deinterlacer comes
> up in the menus as "Interlaced x2". It is also known as field order.
>
>
> Preconditions of use
> ~~~~~~~~~~~~~~~~~~~~
> You need a graphics chip that can output interlaced display modes correctly.
>
> The display mode must be interlaced exactly matching the video source.
>
> No scaling can be used: don't use scaling to reduce overscan.
>
> Video playback must be full speed, not sped up or slowed down.
>
> The deinterlacer is a doublerate one, so you may need the patch from
> Ticket #2903 before MythTv will allow you to use it.
>

I discovered today that the 0.21-fixes version of the bug 2903 patch
didn't work correctly, as I've explained in the additional comments.
My refresh rate of 30.0267 was failing that test and thus not getting
doubled when I used this version of the patch.

However here's what really confuses me: When I attempted to watch
recorded 1080i content, it was rejected the fieldorder deinterlacer
(as you'd expect with the above check) and therefor using none.
However...when I watched 1080i LiveTV, for some reason it was allowing
the fieldorder deinterlacer, but was completely whacked out. I think
perhaps it may have been trying to use it without treating it as line
doubling deinterlacer, though there's a lot going on there I'm not
familiar with at all. In any case, that was the cause of the
nightmare I went through trying to upgrade to a newer rev of fixes as
described here:

http://www.gossamer-threads.com/lists/mythtv/users/381923

I didn't realize when I posted that that pre-recorded 1080i was using
no deinterlacing at all, which was why it didn't encounter those
errors. With LiveTV it never thought the video had caught up.

Again, I'm very unclear on exactly what that did...but LiveTV was
allowing the fieldorder deinterlacer even when the 2903 patch wasn't
correctly doubling the rate, and the results were pretty ugly.

Once I got that patch corrected, rev 20500 is working perfectly for me.

Tom
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
Re: New deinterlacer for perfect image quality when using an interlaced display, mode that matches the source [ In reply to ]
Hi

2009/5/12 Tom Dexter <digitalaudiorock@gmail.com>:
> I discovered today that the 0.21-fixes version of the bug 2903 patch
> didn't work correctly, as I've explained in the additional comments.
> My refresh rate of 30.0267 was failing that test and thus not getting
> doubled when I used this version of the patch.

Note that the patches found in my ubuntu packages are using a patch
that do work.
It's similar to yours.

I had posted it on my site a while ago.

The previous patch would only work with exactly 50Hz or 60Hz no 50.02
for example which can happen

> http://www.gossamer-threads.com/lists/mythtv/users/381923

Jean-Yves
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
Re: New deinterlacer for perfect image quality when using an interlaced display, mode that matches the source [ In reply to ]
Tom Dexter wrote:
> I discovered today that the 0.21-fixes version of the bug 2903 patch
> didn't work correctly, as I've explained in the additional comments.
> My refresh rate of 30.0267 was failing that test and thus not getting
> doubled when I used this version of the patch.
>
> However here's what really confuses me: When I attempted to watch
> recorded 1080i content, it was rejected the fieldorder deinterlacer
> (as you'd expect with the above check) and therefor using none.
> However...when I watched 1080i LiveTV, for some reason it was allowing
> the fieldorder deinterlacer, but was completely whacked out. I think
> perhaps it may have been trying to use it without treating it as line
> doubling deinterlacer, though there's a lot going on there I'm not
> familiar with at all.

Yes I've seen that too. If a rate-doubling deinterlacer is rejected on
the basis of insufficient display framerate then it is properly rejected for
the playback of recordings. But for playback of live TV, the
deinterlacer still gets used in a way that makes playback unwatchably
jerky; my guess is that, although the deinterlacer is used, the
framerate isn't doubled.

P.

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

1 2 3  View All