Mailing List Archive: MythTV: Dev

DVD playback issues, patch

1 2

View All

Index | Next | Previous | View Threaded

davmac at davmac

Nov 13, 2009, 4:35 AM

Post #1 of 32 (3779 views)
Permalink

DVD playback issues, patch

Hi all,

Regarding the DVD playback issues I mentioned earlier. This is
(possibly) related to the following tickets:
http://svn.mythtv.org/trac/ticket/7067
http://svn.mythtv.org/trac/ticket/7349

Although I originally found that revision 22120 was causing the issue, I
no longer believe this is the case: that revision just altered the
timing which presented other problems. Basically the code in the AVSync
method in NuppelVideoPlayer.cpp (libs/mythtv/NuppelVideoPlayer.cpp) is
highly suspect and the code in vsync.cpp (same directory) is also
dubious. I posted some questions about this before but received no reply
so I'm assuming that the errors I saw really were errors. In any case,
altering the code as per the patch below fixes the problem for me.

Incidentally one of the problematic revisions seems to be 21665 by gigem:
http://svn.mythtv.org/trac/changeset/21665/trunk/mythtv/libs/libmythtv/NuppelVideoPlayer.cpp

This seems to max out the av sync adjustment to the refresh rate, which
frankly isn't enough as sometimes the per-frame sync drift is higher
than that. I've undone that change in the patch and also set the vsync
delay so that it always tries to exactly re-sync audio and video (well,
it uses avsync_avg which is a weighted average of the sync drift). I
can't think of any reason why it wasn't like that in the first place but
maybe someone can enlighten me. (Perhaps something to do with the fact
that vsync was accumulating the delay rather than using it as a one-off,
see my earlier post).

The other change in the patch takes all the smoothing logic out of
vsync.cpp and leaves it to do what it surely was meant to do:
synchronize to vertical refresh, nothing more, nothing less. In
particular it no longer accrues a large negative trigger delay (which
causes video to playback at a stupidly high speed for an extended period).

I don't know how things work here so if I should be sending this
somewhere else please let me know.

Davin

Attachments:

patch.txt (3.72 KB)

davmac at davmac

Nov 14, 2009, 6:31 AM

Post #2 of 32 (3672 views)
Permalink

Re: DVD playback issues, patch [In reply to]

Here's an updated patch. The main change is that it avoids advancing the
vsync trigger if a frame is dropped. Otherwise, WaitForFrame will
effectively wait for the frame anyway, so dropping it has no effect.
This caused problems on some media files I have.

Davin.

On 13/11/09 23:35, Davin McCall wrote:
> Hi all,
>
> Regarding the DVD playback issues I mentioned earlier. This is
> (possibly) related to the following tickets:
> http://svn.mythtv.org/trac/ticket/7067
> http://svn.mythtv.org/trac/ticket/7349
>

Attachments:

patch.txt (4.85 KB)

mythtv-dev at jstenback

Nov 14, 2009, 9:36 AM

Post #3 of 32 (3664 views)
Permalink

Re: DVD playback issues, patch [In reply to]

Hello David,

Thanks for digging in here. I haven't been able to test your patch on my
primary system where I use VDPAU for playback yet, but I did test using
software decoding and software rendering and it does not seem like your
patch fixes the problem I'm seeing, and in a way it seems to make it
worse :(

Without your patch, if I fast forward for just a second after starting
DVD playback, the audio/video speeds sync up and remains in sync from
then on, but with your patch I can't seem to get audio and video to ever
be in sync, it's always off by what looks like ~2x.

I wish I could help more here, but I don't know this code at all and I'm
unable to spend any serious time on this in the foreseeable future.

Davin McCall wrote:
> Here's an updated patch. The main change is that it avoids advancing the
> vsync trigger if a frame is dropped. Otherwise, WaitForFrame will
> effectively wait for the frame anyway, so dropping it has no effect.
> This caused problems on some media files I have.
>
> Davin.
>
>
> On 13/11/09 23:35, Davin McCall wrote:
>> Hi all,
>>
>> Regarding the DVD playback issues I mentioned earlier. This is
>> (possibly) related to the following tickets:
>> http://svn.mythtv.org/trac/ticket/7067
>> http://svn.mythtv.org/trac/ticket/7349
>>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev [at] mythtv
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

warpme at o2

Nov 14, 2009, 10:20 AM

Post #4 of 32 (3670 views)
Permalink

Re: DVD playback issues, patch [In reply to]

Davin,

I tested little last version of Your patch (on 0.22-fixes 22804).
Well -I would say is solves issue partially.

Without patch:
In my case since beginning of my swtich to 0.22 (I switch at 22512
level) I constantly have problem with playback speed in some of my DVDs.
Problem is: playback is to fast (10sec playback plays 14-15sec of movie).
I all cases however I'm able to return to proper by changing speed from
x1.0 to any else value and return back. After this DVD is playing OK.

With Your patch:
Playback start with roughly correct speed - but I can clearly notice
that speed is circulating around x1.0 with period of approx half sec.
Overall averaged speed is 1.0, but speed circulation is clearly noticeable.
But changing speed from x1.0 to any else value and return back causes
tha all starts to be OK (speed is OK, movements are fluent).

All this suggest me that issue is maybe result of playback speed
variable initialization issue or something similar...

br

Attachments:

warpme.vcf (83 B)

davmac at davmac

Nov 14, 2009, 3:15 PM

Post #5 of 32 (3667 views)
Permalink

Re: DVD playback issues, patch [In reply to]

Hi,

What do you mean by "off by 2x" ... 2x what? Do you mean video is
playing twice as fast as audio (or the other way around)?
Or, does video lag audio by a consistent amount (2 frames, 2 seconds?)
or the other way around?

Thanks,

Davin

On 15/11/09 04:36, Johnny Stenback wrote:
> Hello David,
>
> Thanks for digging in here. I haven't been able to test your patch on
> my primary system where I use VDPAU for playback yet, but I did test
> using software decoding and software rendering and it does not seem
> like your patch fixes the problem I'm seeing, and in a way it seems to
> make it worse :(
>
> Without your patch, if I fast forward for just a second after starting
> DVD playback, the audio/video speeds sync up and remains in sync from
> then on, but with your patch I can't seem to get audio and video to
> ever be in sync, it's always off by what looks like ~2x.
>
> I wish I could help more here, but I don't know this code at all and
> I'm unable to spend any serious time on this in the foreseeable future.
>
> Davin McCall wrote:
>> Here's an updated patch. The main change is that it avoids advancing the
>> vsync trigger if a frame is dropped. Otherwise, WaitForFrame will
>> effectively wait for the frame anyway, so dropping it has no effect.
>> This caused problems on some media files I have.
>>
>> Davin.
>>
>>
>> On 13/11/09 23:35, Davin McCall wrote:
>>> Hi all,
>>>
>>> Regarding the DVD playback issues I mentioned earlier. This is
>>> (possibly) related to the following tickets:
>>> http://svn.mythtv.org/trac/ticket/7067
>>> http://svn.mythtv.org/trac/ticket/7349
>>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> mythtv-dev mailing list
>> mythtv-dev [at] mythtv
>> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev [at] mythtv
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
>

_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

davmac at davmac

Nov 14, 2009, 8:44 PM

Post #6 of 32 (3648 views)
Permalink

Re: DVD playback issues, patch [In reply to]

Hi,

> Playback start with roughly correct speed - but I can clearly notice
> that speed is circulating around x1.0 with period of approx half sec.

you mean that the speed is varying between about 0.5x and 1.5x, right?

I've checked, there's no problem with lack of initialisation. More
likely the re-syncing is now too agressive and is casuing the video to
bounce between being too fast and too slow.

You could try changing this line in NuppelVideoPlayer.cpp:
avsync_avg = (avsync_delay + (avsync_avg * 3)) / 4;
To something like:
avsync_avg = (avsync_delay + (avsync_avg * 7)) / 8;

If that doesn't help: If I sent you a modified NuppelVideoPlayer.cpp
would you be able to run it for me and give me the log?

Also, what video output are you using - Xv, OpenGL, vdpau, .. ??

Thanks

Davin

On 15/11/09 05:20, Warpme wrote:
> Davin,
>
> I tested little last version of Your patch (on 0.22-fixes 22804).
> Well -I would say is solves issue partially.
>
> Without patch:
> In my case since beginning of my swtich to 0.22 (I switch at 22512
> level) I constantly have problem with playback speed in some of my DVDs.
> Problem is: playback is to fast (10sec playback plays 14-15sec of movie).
> I all cases however I'm able to return to proper by changing speed
> from x1.0 to any else value and return back. After this DVD is playing
> OK.
>
> With Your patch:
> Playback start with roughly correct speed - but I can clearly notice
> that speed is circulating around x1.0 with period of approx half sec.
> Overall averaged speed is 1.0, but speed circulation is clearly
> noticeable.
> But changing speed from x1.0 to any else value and return back causes
> tha all starts to be OK (speed is OK, movements are fluent).
>
> All this suggest me that issue is maybe result of playback speed
> variable initialization issue or something similar...
>
> br
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev [at] mythtv
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
>

_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

mythtv-dev at jstenback

Nov 14, 2009, 9:52 PM

Post #7 of 32 (3653 views)
Permalink

Re: DVD playback issues, patch [In reply to]

Davin McCall wrote:
> Hi,
>
> What do you mean by "off by 2x" ... 2x what? Do you mean video is
> playing twice as fast as audio (or the other way around)?
> Or, does video lag audio by a consistent amount (2 frames, 2 seconds?)
> or the other way around?

Sorry for not clarifying that, what I see is that the video playback
speed is ~2x of the audio speed. Audio plays at normal speed as far as I
can tell, but video is ~2x too fast.

> Thanks,
>
> Davin
>
>
> On 15/11/09 04:36, Johnny Stenback wrote:
>> Hello David,
>>
>> Thanks for digging in here. I haven't been able to test your patch on
>> my primary system where I use VDPAU for playback yet, but I did test
>> using software decoding and software rendering and it does not seem
>> like your patch fixes the problem I'm seeing, and in a way it seems to
>> make it worse :(
>>
>> Without your patch, if I fast forward for just a second after starting
>> DVD playback, the audio/video speeds sync up and remains in sync from
>> then on, but with your patch I can't seem to get audio and video to
>> ever be in sync, it's always off by what looks like ~2x.
>>
>> I wish I could help more here, but I don't know this code at all and
>> I'm unable to spend any serious time on this in the foreseeable future.
>>
>> Davin McCall wrote:
>>> Here's an updated patch. The main change is that it avoids advancing the
>>> vsync trigger if a frame is dropped. Otherwise, WaitForFrame will
>>> effectively wait for the frame anyway, so dropping it has no effect.
>>> This caused problems on some media files I have.
>>>
>>> Davin.
>>>
>>>
>>> On 13/11/09 23:35, Davin McCall wrote:
>>>> Hi all,
>>>>
>>>> Regarding the DVD playback issues I mentioned earlier. This is
>>>> (possibly) related to the following tickets:
>>>> http://svn.mythtv.org/trac/ticket/7067
>>>> http://svn.mythtv.org/trac/ticket/7349
>>>>
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> mythtv-dev mailing list
>>> mythtv-dev [at] mythtv
>>> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
>> _______________________________________________
>> mythtv-dev mailing list
>> mythtv-dev [at] mythtv
>> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
>>
>
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev [at] mythtv
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
>
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

davmac at davmac

Nov 14, 2009, 10:34 PM

Post #8 of 32 (3638 views)
Permalink

Re: DVD playback issues, patch [In reply to]

That's odd, it sounds almost like the exact problem that the patch is
meant to (and does, for me) fix. Basically, I was seeing video run at
about 2x at the start (occasionally it would flatten out to normal speed
after a few seconds, but the audio would then always lag the video).

Essentially the patch *should* make what you're seeing impossible. That
is, if video gets ahead of audio then it gets slowed down, pretty much
straight away, until they are in sync. So, I have no idea what's going
wrong, it may be a decoder issue (wrong timestamps in the audio or
video) or a media issue. What version of Myth did you apply the patch to
(trunk, hopefully?)
Do you see the problem behaviour that you described on all DVDs?
And, if I sent you an updated version (with some debugs thrown in) would
you be able to get the frontend log to me?

Davin

On 15/11/09 16:52, Johnny Stenback wrote:
> Davin McCall wrote:
>> Hi,
>>
>> What do you mean by "off by 2x" ... 2x what? Do you mean video is
>> playing twice as fast as audio (or the other way around)?
>> Or, does video lag audio by a consistent amount (2 frames, 2 seconds?)
>> or the other way around?
>
> Sorry for not clarifying that, what I see is that the video playback
> speed is ~2x of the audio speed. Audio plays at normal speed as far as
> I can tell, but video is ~2x too fast.
>
>> Thanks,
>>
>> Davin
>>
>>
>> On 15/11/09 04:36, Johnny Stenback wrote:
>>> Hello David,
>>>
>>> Thanks for digging in here. I haven't been able to test your patch on
>>> my primary system where I use VDPAU for playback yet, but I did test
>>> using software decoding and software rendering and it does not seem
>>> like your patch fixes the problem I'm seeing, and in a way it seems to
>>> make it worse :(
>>>
>>> Without your patch, if I fast forward for just a second after starting
>>> DVD playback, the audio/video speeds sync up and remains in sync from
>>> then on, but with your patch I can't seem to get audio and video to
>>> ever be in sync, it's always off by what looks like ~2x.
>>>
>>> I wish I could help more here, but I don't know this code at all and
>>> I'm unable to spend any serious time on this in the foreseeable future.
>>>
>>> Davin McCall wrote:
>>>> Here's an updated patch. The main change is that it avoids
>>>> advancing the
>>>> vsync trigger if a frame is dropped. Otherwise, WaitForFrame will
>>>> effectively wait for the frame anyway, so dropping it has no effect.
>>>> This caused problems on some media files I have.
>>>>
>>>> Davin.
>>>>
>>>>
>>>> On 13/11/09 23:35, Davin McCall wrote:
>>>>> Hi all,
>>>>>
>>>>> Regarding the DVD playback issues I mentioned earlier. This is
>>>>> (possibly) related to the following tickets:
>>>>> http://svn.mythtv.org/trac/ticket/7067
>>>>> http://svn.mythtv.org/trac/ticket/7349
>>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>>
>>>> _______________________________________________
>>>> mythtv-dev mailing list
>>>> mythtv-dev [at] mythtv
>>>> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
>>> _______________________________________________
>>> mythtv-dev mailing list
>>> mythtv-dev [at] mythtv
>>> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
>>>
>>
>> _______________________________________________
>> mythtv-dev mailing list
>> mythtv-dev [at] mythtv
>> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
>>
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev [at] mythtv
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
>

_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

davmac at davmac

Nov 14, 2009, 11:43 PM

Post #9 of 32 (3646 views)
Permalink

Re: DVD playback issues, patch [In reply to]

It would also be worth trying to change the line to:

avsync_avg = avsync_delay;

... i.e get rid of the smoothing function altogether, seeing as that's
what might be causing the speed oscillation.

Davin

On 15/11/09 15:44, Davin McCall wrote:
>
> You could try changing this line in NuppelVideoPlayer.cpp:
> avsync_avg = (avsync_delay + (avsync_avg * 3)) / 4;
> To something like:
> avsync_avg = (avsync_delay + (avsync_avg * 7)) / 8;
>

_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

warpme at o2

Nov 15, 2009, 6:18 AM

Post #10 of 32 (3626 views)
Permalink

Re: DVD playback issues, patch [In reply to]

Davin,

>You could try changing this line in NuppelVideoPlayer.cpp:
>avsync_avg = (avsync_delay + (avsync_avg * 3)) / 4;
>To something like:
>avsync_avg = (avsync_delay + (avsync_avg * 7)) / 8;

After this change speed is still circulating but is slightly different
way. I would describe it as:

-0.8-0.8-1.4-0.8-0.8-1.4- with period of 0.5sec.
Avg playback speed is 1.0.
A/V sync also seems to be OK (1h tests)

Changing playback speed from 1.0 to 0.95 and back to 1.0 causes all
issues go away and playback become fluent.

>If that doesn't help: If I sent you a modified NuppelVideoPlayer.cpp
>would you be able to run it for me and give me the log?

Sure !
Pls forward it to PM.

br

Attachments:

warpme.vcf (83 B)

warpme at o2

Nov 15, 2009, 8:37 AM

Post #11 of 32 (3620 views)
Permalink

Re: DVD playback issues, patch [In reply to]

>It would also be worth trying to change the line to:
>
>avsync_avg = avsync_delay;
>
>... i.e get rid of the smoothing function altogether, seeing as that's
>what might be causing the speed oscillation.

Davin,

With this change, 2 DVDs which I'm using to verify (they are playing
bad), now are playing good.
Maybe finally we have solution ?
I will try to test some more DVDs (as time allows).

br

Attachments:

warpme.vcf (83 B)

mythtv-dev at jstenback

Nov 15, 2009, 11:54 AM

Post #12 of 32 (3611 views)
Permalink

Re: DVD playback issues, patch [In reply to]

Hello Davin,

Davin McCall wrote:
> That's odd, it sounds almost like the exact problem that the patch is
> meant to (and does, for me) fix. Basically, I was seeing video run at
> about 2x at the start (occasionally it would flatten out to normal speed
> after a few seconds, but the audio would then always lag the video).
>
> Essentially the patch *should* make what you're seeing impossible. That
> is, if video gets ahead of audio then it gets slowed down, pretty much
> straight away, until they are in sync. So, I have no idea what's going
> wrong, it may be a decoder issue (wrong timestamps in the audio or
> video) or a media issue. What version of Myth did you apply the patch to
> (trunk, hopefully?)

0.22-fixes, but read on...

> Do you see the problem behaviour that you described on all DVDs?
> And, if I sent you an updated version (with some debugs thrown in) would
> you be able to get the frontend log to me?

So I was able to test your patch with the latest suggested change you
mentioned on my real installation (where I actually have audio to
compare against :) and there it seems like your patch fixes the problem!
This system uses VDPAU for playback, also 0.22-fixes from last week
sometime.

On my test system however, which is just a linux box that I vnc into,
and there's no audio support on that box at all, what I see with your
patch is that not only does the problem not go away, but with your patch
the video seems to constantly play too fast. Without your patch, I see
the fast playback as well when I start, but changing the playback speed
(fastforward for a second or two) and then back to normal (i.e. hitting
play again), resets the video speed to what *looks* normal, and it seems
to stay normal from then on. Since there's no audio to compare to it's
hard to say whether it's right or not, but it looks like a 2x speed when
starting playback of a DVD, and normal (1x) after fastforwarding. So
with your patch the re-sync after fastforwarding does not seem to happen
at all.

So essentially I think there's still a problem, but your patch does make
DVD playback work much better in a real environment where there's actual
audio to sync with and so on.

And yeah, I can generate logs and what not if you need them, but I think
you could probably reproduce this yourself in a vnc session w/o any
audio support as well if you're interested in digging in there as well.
Let me know what logs you'd be interested in, if any. And there's a log
from my test system in ticket 7067 w/o your patch if that's of any use.

Thanks again for digging in here!
Johnny

> Davin
>
>
> On 15/11/09 16:52, Johnny Stenback wrote:
>> Davin McCall wrote:
>>> Hi,
>>>
>>> What do you mean by "off by 2x" ... 2x what? Do you mean video is
>>> playing twice as fast as audio (or the other way around)?
>>> Or, does video lag audio by a consistent amount (2 frames, 2 seconds?)
>>> or the other way around?
>>
>> Sorry for not clarifying that, what I see is that the video playback
>> speed is ~2x of the audio speed. Audio plays at normal speed as far as
>> I can tell, but video is ~2x too fast.
>>
>>> Thanks,
>>>
>>> Davin
>>>
>>>
>>> On 15/11/09 04:36, Johnny Stenback wrote:
>>>> Hello David,
>>>>
>>>> Thanks for digging in here. I haven't been able to test your patch on
>>>> my primary system where I use VDPAU for playback yet, but I did test
>>>> using software decoding and software rendering and it does not seem
>>>> like your patch fixes the problem I'm seeing, and in a way it seems to
>>>> make it worse :(
>>>>
>>>> Without your patch, if I fast forward for just a second after starting
>>>> DVD playback, the audio/video speeds sync up and remains in sync from
>>>> then on, but with your patch I can't seem to get audio and video to
>>>> ever be in sync, it's always off by what looks like ~2x.
>>>>
>>>> I wish I could help more here, but I don't know this code at all and
>>>> I'm unable to spend any serious time on this in the foreseeable future.
>>>>
>>>> Davin McCall wrote:
>>>>> Here's an updated patch. The main change is that it avoids
>>>>> advancing the
>>>>> vsync trigger if a frame is dropped. Otherwise, WaitForFrame will
>>>>> effectively wait for the frame anyway, so dropping it has no effect.
>>>>> This caused problems on some media files I have.
>>>>>
>>>>> Davin.
>>>>>
>>>>>
>>>>> On 13/11/09 23:35, Davin McCall wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> Regarding the DVD playback issues I mentioned earlier. This is
>>>>>> (possibly) related to the following tickets:
>>>>>> http://svn.mythtv.org/trac/ticket/7067
>>>>>> http://svn.mythtv.org/trac/ticket/7349
>>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> mythtv-dev mailing list
>>>>> mythtv-dev [at] mythtv
>>>>> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
>>>> _______________________________________________
>>>> mythtv-dev mailing list
>>>> mythtv-dev [at] mythtv
>>>> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
>>>>
>>>
>>> _______________________________________________
>>> mythtv-dev mailing list
>>> mythtv-dev [at] mythtv
>>> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
>>>
>> _______________________________________________
>> mythtv-dev mailing list
>> mythtv-dev [at] mythtv
>> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
>>
>
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev [at] mythtv
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
>
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

mark at digivation

Nov 15, 2009, 12:55 PM

Post #13 of 32 (3607 views)
Permalink

Re: DVD playback issues, patch [In reply to]

> >It would also be worth trying to change the line to:
> >
> >avsync_avg = avsync_delay;
> >
> >... i.e get rid of the smoothing function altogether, seeing as that's
> >what might be causing the speed oscillation.

a big problem is that the initial value of avsync_avg is 0 which is not
correct.
somehow it should be set to avsync_delay if it hasnt been set before.
with this it may be possible to increase the time constant as described
earlier without impacting things.
also on dvd pts change, avsync_delay should be set to avsync_avg so that
there is no discontinuity in avsync_avg
determination.

mark

_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

davmac at davmac

Nov 15, 2009, 2:49 PM

Post #14 of 32 (3602 views)
Permalink

Re: DVD playback issues, patch [In reply to]

On 16/11/09 07:55, Mark Spieth wrote:
> also on dvd pts change, avsync_delay should be set to avsync_avg so
> that there is no discontinuity in avsync_avg
> determination.

I'm not sure if I understand what you mean by pts change. The following
line:

if (! (avsync_delay > 2000000 && player_ctx->buffer->isDVD()))
avsync_avg = (avsync_delay + (avsync_avg * 3)) / 4;

... changes avsync_avg only if there is no large discontinuity in the
video timecode. Doesn't that have the same effect? (Or were you
referring to something else altogether? - when does pts change?)

Also:
> a big problem is that the initial value of avsync_avg is 0 which is
> not correct.
> somehow it should be set to avsync_delay if it hasnt been set before.

That would certainly be possible but I think the real problem is the
av_delay calculation doesn't take the previous delay into account. That
is, instead of (in pseudo code):

avsync_delay = video.timecode - audio.timecode

It should be:

avsync_delay = video.timecode - audio.timecode + avsync_adjustment

(With some details omitted. For instance, avsync_adjustment has already
been reset to 0 so we need to move that reset until after the
calculation of avsync_delay)

Anyway it looks like we are getting closer to a real solution. I intend
to post another patch soon.

Davin

_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

davmac at davmac

Nov 15, 2009, 2:52 PM

Post #15 of 32 (3594 views)
Permalink

Re: DVD playback issues, patch [In reply to]

On 16/11/09 03:37, Warpme wrote:
>
> With this change, 2 DVDs which I'm using to verify (they are playing
> bad), now are playing good.
> Maybe finally we have solution ?

I think we're getting there, but setting avsync_delay = avsync_avg isn't
really a great thing to do. It will cause problems is the current audio
timestamp can't be read accurately for instance. However, we're
definitely getting close to a real solution and I will post another
patch soon, hopefully you will be willing to test it too.

Davin

_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

davmac at davmac

Nov 15, 2009, 2:55 PM

Post #16 of 32 (3608 views)
Permalink

Re: DVD playback issues, patch [In reply to]

Hi Johny,

> 0.22-fixes, but read on...

Yes that's fine of course.

> So I was able to test your patch with the latest suggested change you
> mentioned on my real installation (where I actually have audio to
> compare against :) and there it seems like your patch fixes the
> problem! This system uses VDPAU for playback, also 0.22-fixes from
> last week sometime.
>

Excellent. I think I fully understand the problem now. That last
suggested change was something of a hack though, I will try to develop a
real solution.

> On my test system however, which is just a linux box that I vnc into,
> and there's no audio support on that box at all, what I see with your
> patch is that not only does the problem not go away, but with your
> patch the video seems to constantly play too fast.

That's not too surprising, as I've been concentrating on the case where
there is audio to sync to. But I'll have a look at the other code paths
as well. Thanks,

Davin.

_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

mark at digivation

Nov 15, 2009, 4:10 PM

Post #17 of 32 (3597 views)
Permalink

Re: DVD playback issues, patch [In reply to]

>> also on dvd pts change, avsync_delay should be set to avsync_avg so that
>> there is no discontinuity in avsync_avg
>> determination.
>
>I'm not sure if I understand what you mean by pts change. The following
>line:
>
> if (! (avsync_delay > 2000000 && player_ctx->buffer->isDVD()))
> avsync_avg = (avsync_delay + (avsync_avg * 3)) / 4;
>
>... changes avsync_avg only if there is no large discontinuity in the video
>timecode. Doesn't that have the same effect? (Or were you referring to
>something else altogether? - when does pts change?)

it probably should be something like this

if (avsync_avg == MAXINT)
avsync_avg = avsync_delay;
// prevents major jitter when pts resets during dvd title
if (labs(avsync_delay) > 2000000 && player_ctx->buffer->isDVD())
avsync_delay = avsync_avg;
#define AVSYNC_TC 8
avsync_avg = (avsync_delay + (avsync_avg * (AVSYNC_TC-1))) /
AVSYNC_TC;

and in the constructor
set avsync_avg to MAXINT.
alternatively use a bool to indicate avsync_avg has not been set.

also notice the labs for dvd check. I think that is also important though
its only a guess.
however is 2 seconds enough for dvd?
I like the idea to smooth avg a bit more. would require some experimentation
to determine good values.

>Also:
>> a big problem is that the initial value of avsync_avg is 0 which is not
>> correct.
>> somehow it should be set to avsync_delay if it hasnt been set before.
>
>That would certainly be possible but I think the real problem is the
>av_delay calculation doesn't take the previous delay into account. That is,
>instead of (in pseudo code):
>
> avsync_delay = video.timecode - audio.timecode
>
>It should be:
>
> avsync_delay = video.timecode - audio.timecode + avsync_adjustment

no as avsync_adjustment is for realigning, not measuring and is based on the
refresh rate not the delivered rate.
avsync_delay is the instantaneous estimation of avsync.
avsync_avg is smoothed so that any minor variations dont cause excessive
frame double/skip jerkiness.

avsync_adjustment is not part of the delay estimation algo and shouldnt be.

I do see some jerkiness currently watching say motor racing at 1.8. or 1.75.
if the delived rate is not a close multiple of the refresh rate you notice a
bit more jerkiness. not that it's too noticable though.

cheers
mark

_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

davmac at davmac

Nov 15, 2009, 5:55 PM

Post #18 of 32 (3582 views)
Permalink

Re: DVD playback issues, patch [In reply to]

>
> it probably should be something like this
>

... (snipped)

yep, that looks good to me too

> also notice the labs for dvd check. I think that is also important though
> its only a guess.
> however is 2 seconds enough for dvd?

I don't know. That line of code was in there before I touched anything.

>
> no as avsync_adjustment is for realigning, not measuring and is based on
> the
> refresh rate not the delivered rate.

In vsync.cpp, "AdvanceTrigger()" advances the trigger by the frame
interval, not the refresh interval. The avsync_delay gets added to the
trigger value in WaitForFrame(). It is totally about keeping the video
frames in sync with the audio. It is calculated based on the current
difference between the audio and video timecode. I don't know what you
mean by "based on the refresh rate".

(Admittedly, this is only what I understand from looking at the code. I
asked questions on this list previously about how things were meant to
work, but no-one answered then. In any case, my patches are based on these
assumptions, and they happen to fix real problems).

Just to make it clear, here's my understanding of what goes on:
- video and audio are played. The vsync implementation is used to delay
between video frames.
- avsync_delay is the delay between video and audio
- if video and audio are perfectly in sync then avsync_delay should be 0
or very close to it
- as you say avsync_avg is a smoothed-out version of avsync_delay
- there does however tend to be a constant drift, either positive or
negative, in sync. That is video is either slightly faster or slightly
slower than it should be.
- also, sometimes the video and audio get out of sync by quite a bit and
this requires a large correction to be made
- avsync_adjustment is used to alter video frame rate by slowing down or
speeding up the display of the next frame

And yes, avsync_adjustment is used for realigning, but it's added to the
standard trigger delay (i.e. the frame interval, in vsync.cpp) so it
should be taken into account when calculating avsync_delay. (or otherwise,
avsync_adjustment shouldn't be reset to 0 every frame like it is
currently. Perhaps that's really the better answer).

Before my patch, it's true that avsync_adjustment was limited to a refresh
interval (or even half of one - can't quite remember). But that never made
sense. What if the AV sync was way out (particularly, if the video was way
ahead) and a large adjustment was needed? This was, incidentally, the
exact problem I was seeing.

> avsync_delay is the instantaneous estimation of avsync.
> avsync_avg is smoothed so that any minor variations dont cause excessive
> frame double/skip jerkiness.

Yes, I understood that already.

>
> avsync_adjustment is not part of the delay estimation algo and shouldnt
> be.

Then it should be maintained as a cumulative and not reset to 0 every
frame. Otherwise you bounce in and out of sync, because the sync drift
tends to be constant.

Davin

_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

mark at digivation

Nov 15, 2009, 6:32 PM

Post #19 of 32 (3562 views)
Permalink

Re: DVD playback issues, patch [In reply to]

>>
>> no as avsync_adjustment is for realigning, not measuring and is based on
>> the
>> refresh rate not the delivered rate.
>
>In vsync.cpp, "AdvanceTrigger()" advances the trigger by the frame
>interval, not the refresh interval. The avsync_delay gets added to the
>trigger value in WaitForFrame(). It is totally about keeping the video
>frames in sync with the audio. It is calculated based on the current
>difference between the audio and video timecode. I don't know what you
>mean by "based on the refresh rate".
>
>(Admittedly, this is only what I understand from looking at the code. I
>asked questions on this list previously about how things were meant to
>work, but no-one answered then. In any case, my patches are based on these
>assumptions, and they happen to fix real problems).
>
>Just to make it clear, here's my understanding of what goes on:
>- video and audio are played. The vsync implementation is used to delay
>between video frames.
>- avsync_delay is the delay between video and audio
>- if video and audio are perfectly in sync then avsync_delay should be 0
>or very close to it
>- as you say avsync_avg is a smoothed-out version of avsync_delay
>- there does however tend to be a constant drift, either positive or
>negative, in sync. That is video is either slightly faster or slightly
>slower than it should be.
>- also, sometimes the video and audio get out of sync by quite a bit and
>this requires a large correction to be made
>- avsync_adjustment is used to alter video frame rate by slowing down or
>speeding up the display of the next frame
>
>And yes, avsync_adjustment is used for realigning, but it's added to the
>standard trigger delay (i.e. the frame interval, in vsync.cpp) so it
>should be taken into account when calculating avsync_delay. (or otherwise,
>avsync_adjustment shouldn't be reset to 0 every frame like it is
>currently. Perhaps that's really the better answer).
>
>Before my patch, it's true that avsync_adjustment was limited to a refresh
>interval (or even half of one - can't quite remember). But that never made
>sense. What if the AV sync was way out (particularly, if the video was way
>ahead) and a large adjustment was needed? This was, incidentally, the
>exact problem I was seeing.
>
>> avsync_delay is the instantaneous estimation of avsync.
>> avsync_avg is smoothed so that any minor variations dont cause excessive
>> frame double/skip jerkiness.
>
>Yes, I understood that already.
>
>>
>> avsync_adjustment is not part of the delay estimation algo and shouldnt
>> be.
>
>Then it should be maintained as a cumulative and not reset to 0 every
>frame. Otherwise you bounce in and out of sync, because the sync drift
>tends to be constant.

avsync_adjustment is used to advance or retard video the next time through
the loop (the call to AVSync()).
it is 0 as only if the measured avdelay is too big does it get set
otherwise.
it is always in integral # of frames at the rate being displayed, i.e. the
refresh rate.
avsync_adjustment is calculated by the avsync_delay. if this delay is 1.5
frames ahead or behind, set avsync_adjustment such that the next time
through, a frame is doubled or skipped.

now this could be changed by doing the avsync_avg calc before the frame
tweek is done in the same loop so that its done earlier. but after diverge
is calculated I think. I would have to analyse the flow more to get a better
picture in my head. just initial thoughts.

also if you want to handle bigger # frames simultaneously, then
avsync_adjustment would need to be multiples of the output frame rate and be
handled apropriately. all possible. ATM only 1 frame per pass thorugh AVSync
is allowed. thus double speed or 1/2 speed until in sync.

HTH
mark

_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

davmac at davmac

Nov 16, 2009, 4:15 PM

Post #20 of 32 (3497 views)
Permalink

Re: DVD playback issues, patch [In reply to]

On 16/11/09 13:32, Mark Spieth wrote:
>
> avsync_adjustment is used to advance or retard video the next time
> through the loop (the call to AVSync()).
> it is 0 as only if the measured avdelay is too big does it get set
> otherwise.
> it is always in integral # of frames at the rate being displayed, i.e.
> the refresh rate.
> avsync_adjustment is calculated by the avsync_delay. if this delay is
> 1.5 frames ahead or behind, set avsync_adjustment such that the next
> time through, a frame is doubled or skipped.
>

Thanks - Actually that does help. I'm starting to understand the old
code - I hadn't really considered keeping in phase with the refresh and
my current patch (probably) breaks that.

The whole piece of code in AVSync seems way more complicated than it
needs to be. But I need to reconsider in light of the information you've
provided.

To anyone who's following this, I'll provide another patch when I can.

Davin

_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

davmac at davmac

Nov 22, 2009, 5:10 PM

Post #21 of 32 (2988 views)
Permalink

Re: DVD playback issues, patch [In reply to]

Slow reply, but...

On 16/11/09 13:32, Mark Spieth wrote:
>
> avsync_adjustment is used to advance or retard video the next time
> through the loop (the call to AVSync()).
> it is 0 as only if the measured avdelay is too big does it get set
> otherwise.
> it is always in integral # of frames at the rate being displayed, i.e.
> the refresh rate.

Having looked at the code for quite a while now, I still can't
understand why the avdelay needs to be an integral number of refresh
intervals. The videosync object will make sure the frame is displayed
during vertical retrace, regardless of what avdelay you feed it.

> avsync_adjustment is calculated by the avsync_delay. if this delay is
> 1.5 frames ahead or behind, set avsync_adjustment such that the next
> time through, a frame is doubled or skipped.

I understand what it's doing, I just don't understand:
- why it waits to be 1.5 frames ahead or behind before it adjusts
- why it adjusts by only one refresh interval

refresh interval != frame interval!!

> also if you want to handle bigger # frames simultaneously, then
> avsync_adjustment would need to be multiples of the output frame rate
> and be handled apropriately. all possible. ATM only 1 frame per pass
> thorugh AVSync is allowed. thus double speed or 1/2 speed until in sync.

But why does avsync_adjustment need to be multiples of the refresh rate??

Davin

_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

mark at digivation

Nov 22, 2009, 10:20 PM

Post #22 of 32 (2955 views)
Permalink

Re: DVD playback issues, patch [In reply to]

>Slow reply, but...
>
>On 16/11/09 13:32, Mark Spieth wrote:
>>
>> avsync_adjustment is used to advance or retard video the next time
>> through the loop (the call to AVSync()).
>> it is 0 as only if the measured avdelay is too big does it get set
>> otherwise.
>> it is always in integral # of frames at the rate being displayed, i.e.
>> the refresh rate.
>
>Having looked at the code for quite a while now, I still can't understand
>why the avdelay needs to be an integral number of refresh intervals. The
>videosync object will make sure the frame is displayed during vertical
>retrace, regardless of what avdelay you feed it.
>
>> avsync_adjustment is calculated by the avsync_delay. if this delay is 1.5
>> frames ahead or behind, set avsync_adjustment such that the next time
>> through, a frame is doubled or skipped.
>
>I understand what it's doing, I just don't understand:
>- why it waits to be 1.5 frames ahead or behind before it adjusts
>- why it adjusts by only one refresh interval

note: I dont really know too much other than the small tweeks I too have
made personally. so YMMV

there are a few output sync methods.
1 is the timer method which has no hardware basis
2 is the various h/w sync methods, of which I use opengl_sync

to my thinking, it doesnt matter as both have the same underlying
quantization of output presentation.

>
>refresh interval != frame interval!!

that is correct. audio timestamps vary more finely than video ones which are
always quantized to frame interval. this is modified by the playback speed
(timestretch).

output rate is always at the refresh interval.
so we have 2 problems here. massaging the frame rate to coincide with the
refresh/output rate and keeping the avsync in check.

what we see is at the refresh rate but we have no direct knowledge of which
frame is actually displayed. we also need to know which frame is shown next.
this the output vtimestamp (based on refresh rate) is adjusted to keep the
atimestamp within bounds. but since the video is a more coarsely quantised
system, we modify our knowledge of the vtimestamp by the amount that the
output system would change it. i.e. at the refresh rate.
we cant change when a frame is displayed as that is controlled by the output
hardware and is always at the frame rate. better we control dropping, dups
than the hardware anyway.

we are talking about a control system with estimated variables.
the better the estimation, the better the result.
note: the current audio timestamp is also estimated.

>
>> also if you want to handle bigger # frames simultaneously, then
>> avsync_adjustment would need to be multiples of the output frame rate and
>> be handled apropriately. all possible. ATM only 1 frame per pass thorugh
>> AVSync is allowed. thus double speed or 1/2 speed until in sync.
>
>But why does avsync_adjustment need to be multiples of the refresh rate??

hope Ive answered this adequately.

regards
mark

_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

davmac at davmac

Nov 23, 2009, 9:23 PM

Post #23 of 32 (2854 views)
Permalink

Re: DVD playback issues, patch [In reply to]

On 23/11/09 17:20, Mark Spieth wrote:
>
> there are a few output sync methods.
> 1 is the timer method which has no hardware basis
> 2 is the various h/w sync methods, of which I use opengl_sync
>
> to my thinking, it doesnt matter as both have the same underlying
> quantization of output presentation.
>

Ok, I think I know what you mean.

>>
>> refresh interval != frame interval!!
>
> that is correct. audio timestamps vary more finely than video ones
> which are always quantized to frame interval. this is modified by the
> playback speed (timestretch).
>
> output rate is always at the refresh interval.
> so we have 2 problems here. massaging the frame rate to coincide with
> the refresh/output rate and keeping the avsync in check.

Yes, understood (already).

>
> what we see is at the refresh rate but we have no direct knowledge of
> which frame is actually displayed. we also need to know which frame is
> shown next. this the output vtimestamp (based on refresh rate) is
> adjusted to keep the atimestamp within bounds. but since the video is
> a more coarsely quantised system, we modify our knowledge of the
> vtimestamp by the amount that the output system would change it. i.e.
> at the refresh rate.

Sure, but avsync_delay has nothing to do with knowledge of the
vtimestamp. It's just a value that's passed to the VideoSync object. The
V.S. object uses it to calculate how many refresh intervals to wait
between frames (or, if the software mechanism is used, it just uses it
to determine exactly how long to sleep for). Also, it's cumulative in
the V.S. object. So if you pass in 1/3 of a refresh interval each time,
then after three frames it would delay an additional refresh interval.

With the hardware mechanisms (I used DRM but OpenGL works the same way)
then the mechanism always aligns to the refresh interval anyway so it
doesn't matter if avsync_delay is not a multiple of the refresh
interval. With the software (timer) mechanism there's no point trying to
align to refresh intervals since we have no idea when refresh happens
anyway.

So, I still don't understand why avsync_delay must be a multiple of the
refresh interval.

> we cant change when a frame is displayed as that is controlled by the
> output hardware and is always at the frame rate.

No, it is always at the *refresh* rate. And we *can* change when a frame
is displayed, to the quantization level determined by the refresh rate.

> better we control dropping, dups than the hardware anyway.

Sure.

>
> we are talking about a control system with estimated variables.
> the better the estimation, the better the result.

But avsync_delay is not an estimation of anything. Other than, perhaps,
how far ahead/behind the video is from the audio. And in that case the
best estimation is one that *hasn't* been quantized to the refresh interval.

> hope Ive answered this adequately.

Sorry but no!

Thanks for responding,

Davin

_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

jppoet at gmail

Nov 24, 2009, 5:36 PM

Post #24 of 32 (2788 views)
Permalink

Re: DVD playback issues, patch [In reply to]

On Mon, Nov 23, 2009 at 10:23 PM, Davin McCall <davmac [at] davmac> wrote:
> On 23/11/09 17:20, Mark Spieth wrote:
>>
>> there are a few output sync methods.
>> 1 is the timer method which has no hardware basis
>> 2 is the various h/w sync methods, of which I use opengl_sync
>>
>> to my thinking, it doesnt matter as both have the same underlying
>> quantization of output presentation.
>>
>
> Ok, I think I know what you mean.
>
>>>
>>> refresh interval != frame interval!!
>>
>> that is correct. audio timestamps vary more finely than video ones which
>> are always quantized to frame interval. this is modified by the playback
>> speed (timestretch).
>>
>> output rate is always at the refresh interval.
>> so we have 2 problems here. massaging the frame rate to coincide with the
>> refresh/output rate and keeping the avsync in check.
>
> Yes, understood (already).
>
>>
>> what we see is at the refresh rate but we have no direct knowledge of
>> which frame is actually displayed. we also need to know which frame is shown
>> next. this the output vtimestamp (based on refresh rate) is adjusted to keep
>> the atimestamp within bounds. but since the video is a more coarsely
>> quantised system, we modify our knowledge of the vtimestamp by the amount
>> that the output system would change it. i.e. at the refresh rate.
>
> Sure, but avsync_delay has nothing to do with knowledge of the vtimestamp.
> It's just a value that's passed to the VideoSync object. The V.S. object
> uses it to calculate how many refresh intervals to wait between frames (or,
> if the software mechanism is used, it just uses it to determine exactly how
> long to sleep for). Also, it's cumulative in the V.S. object. So if you pass
> in 1/3 of a refresh interval each time, then after three frames it would
> delay an additional refresh interval.
>
> With the hardware mechanisms (I used DRM but OpenGL works the same way) then
> the mechanism always aligns to the refresh interval anyway so it doesn't
> matter if avsync_delay is not a multiple of the refresh interval. With the
> software (timer) mechanism there's no point trying to align to refresh
> intervals since we have no idea when refresh happens anyway.
>
> So, I still don't understand why avsync_delay must be a multiple of the
> refresh interval.
>
>> we cant change when a frame is displayed as that is controlled by the
>> output hardware and is always at the frame rate.
>
> No, it is always at the *refresh* rate. And we *can* change when a frame is
> displayed, to the quantization level determined by the refresh rate.
>
>> better we control dropping, dups than the hardware anyway.
>
> Sure.
>
>>
>> we are talking about a control system with estimated variables.
>> the better the estimation, the better the result.
>
> But avsync_delay is not an estimation of anything. Other than, perhaps, how
> far ahead/behind the video is from the audio. And in that case the best
> estimation is one that *hasn't* been quantized to the refresh interval.
>
>> hope Ive answered this adequately.
>
> Sorry but no!
>
> Thanks for responding,
>
> Davin

I am finding this conversation interesting.

I have been wondering why timestretch playback is not smoother than it
is. My system (using software decoder) can playback anything I throw
at it, including 1080i H.264 material with yadif (2x) deinterlacing.
As soon as I bump up the speed even one notch (1.05x), my log file
starts filling up with:

NVP(0): Video is 3.67133 frames behind audio (too slow), dropping
frame to catch up.

...and that happens even when doing this with "simple" 720p mpeg2. My
system should be able to decode 100 frames per second pretty easily.

So, the video being +3 frames behind the audio does not make sense.
There is no excuse for my system no being able to "keep up", unless it
is not being allowed to. I assume the problem is that there can only
be one-frame-per-refresh, and the refresh is 60Hz. I don't know what
the solution is, but I would love it if Davin or Mark could come up
with it ;-)

John
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

david at istwok

Nov 24, 2009, 6:57 PM

Post #25 of 32 (2772 views)
Permalink

Re: DVD playback issues, patch [In reply to]

On Tue, Nov 24, 2009 at 06:36:21PM -0700, John P Poet wrote:
> ...and that happens even when doing this with "simple" 720p mpeg2. My
> system should be able to decode 100 frames per second pretty easily.
>
> So, the video being +3 frames behind the audio does not make sense.
> There is no excuse for my system no being able to "keep up", unless it
> is not being allowed to. I assume the problem is that there can only
> be one-frame-per-refresh, and the refresh is 60Hz. I don't know what
> the solution is, but I would love it if Davin or Mark could come up
> with it ;-)

I haven't followed any of this thread until this message. Please
pardon the interruption if I'm way off base.

John, I believe you've touched on the reason I have my HD-PVR attached
STBs set to 1080i instead of 720p -- interlaced content stretches much
more smoothly than progressive. With the fallback deinerlacing
options limited to 1x, you never have more deinterlaced frames than
refresh intervals (60, in my case) so you never have to drop any
frames. With progressive content, you always have more frames than
refresh intervals so you always have to drop frames and the result is
jerky.

I have an idea that might remedy this. We detect when we have more
video frames than refresh intervals similarly to how we detect when to
use the fallback deinterlacers. When we detect this condition, what
if we discard every other video frame? In a sense, we fallback to a
"0.5x deinterlacer." Since we discard frames at a regular rate
instead of somewhat randomly as currently done, the result might be as
smooth current the stretching of interlaced content.

David
--
David Engel
david [at] istwok
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

1 2

View All

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads