Warning: Can't synchronize with the repository (/Volumes/XSR1/Users/admin/dvl/xbmc-svn does not appear to be a Subversion repository.)

Ticket #209 (new bug)

Opened 4 months ago

Last modified 2 months ago

Speed up video

Reported by: jeremymc7 Owned by:
Priority: major Milestone:
Component: Core Version: 0.5.0b8
Keywords: Cc:

Description

Having an issue with speed up and out of sync video.

This happens which changing chapters or oddly enough changing audio tracks.

After changing the chapter or audio track the video is speed up about 2 times, while the audio is normal. Over about 2-3 seconds the video slows back down to normal and comes back in to sync with the audio.

Buffer issue?

  • Mac Mini
  • 2 GHz Intel Core 2 Duo
  • 4GB Ram
  • 10.5.2
  • OSXBMC 0.50b1

Change History

Changed 4 months ago by iordonez

Log files?

Changed 3 months ago by iordonez

How does this look under .5b3?

Changed 3 months ago by jeremymc7

  • version changed from 0.5.0b1 to 0.5.0b5

Yes, still exists in 0.5.0b5

No change.

Changed 3 months ago by bmfrosty

I've seen this. It usually only lasts a moment while the video speeds up to match the point in the audio track where where the switch happens.

Anything after this point is speculation.

I think this is because (I think) the cache only contains the streams which are being played back. The switch happens at the newest point in the buffer, and happens immediately instead of waiting until the previous audio stream catches up. The easiest fix would probably involve playing back the original audio stream until the audio stream you're switching to catches up with the current point in the buffer, and then making the switch. Another way would be to dump the buffer, and start over again with the new audio stream (lets say at the next keyframe). There are a lot of tradeoffs with this method, it may require a rebuffer and cause the video to pause if your network is too slow. Another way to address this would be to split buffer into a large network cache, and a smaller playback cache. The larger buffer contains the entire data stream, and the smaller contains the demuxed streams that are being played back - maybe just a frame or two worth. This would probably involve a major rewrite.

Changed 3 months ago by bmfrosty

Ok.....

This doesn't seem to be a cache problem. My assumption was wrong. The problem persists even when cache is turned completely off (unless that setting is false?). I'm going to see if I can catch what's happening in the log, but I suspect that it will end up being something that has to be looked at a in a different way.

Changed 3 months ago by bmfrosty

Here's a pastebin that shows switching audio streams. It will take someone with a better knowledge than I of the process to determine why this is happening.

http://pastebin.com/f43df1d2d

Changed 3 months ago by iordonez

Does the new mkv skipping patch fix it?

Changed 2 months ago by jeremymc7

If the patch is part of 0.5.0b8 then so it still persists.

Changed 2 months ago by jeremymc7

  • version changed from 0.5.0b5 to 0.5.0b8

Testing in 0.5.0b9 this still happens but has gotten much better.

Changed 2 months ago by jimmypop

Is it possible that this change in b9 is responsible for ticket #288?

Note: See TracTickets for help on using tickets.