Kodi Community Forum
What is causing the momentary speedup of video after unpausing, a bug? - Printable Version

+- Kodi Community Forum (https://forum.kodi.tv)
+-- Forum: Support (https://forum.kodi.tv/forumdisplay.php?fid=33)
+--- Forum: General Support (https://forum.kodi.tv/forumdisplay.php?fid=111)
+---- Forum: OS independent / Other (https://forum.kodi.tv/forumdisplay.php?fid=228)
+---- Thread: What is causing the momentary speedup of video after unpausing, a bug? (/showthread.php?tid=81718)

Pages: 1 2 3 4


What is causing the momentary speedup of video after unpausing, a bug? - Harry Muscle - 2010-09-22

Just curious if any developers might know roughly what might be causing the slight speed up of video (but not audio) after you unpause. If anyone has any rough ideas where to start looking for this I might devote some time to actually fixing it.

Thanks,
Harry


- bossanova808 - 2010-09-24

This would be great- the unpause of xbmc is really inelegant at the moment. It would be lovely if it was all neat and instant and synced...


- gnif - 2010-09-24

inelegant? my goodness, you have no idea...

The speedup is due to av sync, when you pause, audio currently in your sound-cards buffer has to be dropped to stop the output, when you resume playback, the audio is slightly out, so video has to run fast to catch up to the audio. This is not an easy thing to correct... but I am attempting to in the new AudioEngine branch


- gnif - 2010-09-24

for normal audio the delay will be something like this, with a avg delay of 20ms.

48000 / 1000 = 48 frames per ms
48 * 20ms = 960 frames that will get dropped
960 * 2 = 1920 samples (2 channels)
1920 * 2 = 3840 bytes (16bit, 2 bytes per sample)

now lets do the math for AC3...

A single AC3 block has 256 samples in it... no more, no less
256 / 48000 = 5.3ms of audio per ac3 block

256 * 2 = 512 samples (2 channels)
512 * 2 = 1024 bytes (16bit, 2 bytes per sample)
1024 / 5.3ms = 193.2ms

so 20ms of audio lag, is the same as almost 200ms of compressed data.... so video has to catch up to the audio by ~200ms.


- Montellese - 2010-09-24

Is this the same reason why video is played very fast for a second or two right after changing the audio stream while watching a video?


- gnif - 2010-09-24

yes, its exactly why Smile


- Harry Muscle - 2010-09-24

gnif Wrote:inelegant? my goodness, you have no idea...

The speedup is due to av sync, when you pause, audio currently in your sound-cards buffer has to be dropped to stop the output, when you resume playback, the audio is slightly out, so video has to run fast to catch up to the audio. This is not an easy thing to correct... but I am attempting to in the new AudioEngine branch

I thought it was something like that ... but I guess if you're already working on fixing this in the AudioEngine branch, no point in duplicating work especially since it would have been for nothing once the AudioEngine gets accepted into the main SVN.

Thanks,
Harry


- elupus - 2010-09-24

changing audio stream is different actually.. It's due to it being changed at demux level, and that means the first audio sample is 4 to 8 seconds ahead of the video when it start to show up.

I'm pondering if we should attempt to do an accurate seek to the current video position when we change audio channels.


- StarChild - 2010-10-21

Is this the same reason why rewind sometimes play forward? Is there an audio sync when ff or rewind?

EDIT: Like this: http://www.megaupload.com/?d=GP4I8PW0
The sample is from a dvd iso in a uncompressed rar archive on a NAS server.


- Galefury - 2010-11-13

I see that elupus had made a change involving audio sync. That means the issue had been solved ?


Not for me - SoCol - 2010-11-21

Galefury Wrote:That means the issue had been solved ?

Well, it used to be A-OK in Dharma Beta, but RC1 broke it for me in a way I never expected - now the video freezes for at least a second after a pause, and then catches up in an instant.


- bobo1on1 - 2010-11-22

There's also a fix in r35340, which came in just too late for RC1.
That one affects linux and osx if you pause for more than 9 seconds, windows if you pause for more than 2,5 hours.


- SoCol - 2010-11-22

bobo1on1 Wrote:There's also a fix in r35340, which came in just too late for RC1.
That one affects linux and osx if you pause for more than 9 seconds, windows if you pause for more than 2,5 hours.

Well, it's a pity it didn't make it to the RC1. The whole affair makes me wonder, though, why did Beta 4 work perfectly, with not post-pause skips at all, on the same system? Could it be that a fix was applied there and then pulled bak for RC1 due to some reason?


- htpc guy - 2010-11-22

I'm running Ubuntu 10.4 and XBMC RC1 (hardware listed in signature).

I had this issue in Beta 4 and it is completely gone now in RC1. Now I have no idea what is going on. Why is mine working when its broken for others? I can't say I'm complaining though.


- SoCol - 2010-11-22

htpc guy Wrote:I'm running Ubuntu 10.4 and XBMC RC1

Same thing here, though I'm running it on Zotac ZBOX HD-ID11 ION 2 (2GB Ram).

htpc guy Wrote:I had this issue in Beta 4 and it is completely gone now in RC1. Now I have no idea what is going on. Why is mine working when its broken for others? I can't say I'm complaining though.
That just once again confirms the fact that bugs have mysterious ways Smile