[Voyager]

Since VideoPlayer (on Windows), I'm unable to get smooth video playback any longer on certain video files. I don't know if it's a Windows-only problem...
I first suspected the media itself was 'bad', but when going back to Jarvis, the ones that are having problems on Krypton, do play perfectly smooth.

Here's my debug log:
http://xbmclogs.com/pvz8ys0ry - alternative: http://pastebin.com/hGv8QJTa

As of 10:29:25 you'll see a lot of these:

Code:

10:29:25 T:31936   DEBUG: CDVDClock::Discontinuity - CVideoPlayerAudio::OutputPacket - was:1162531.639240, should be:1140551.460436, error:-21980.178804
10:29:26 T:31936   DEBUG: CDVDClock::Discontinuity - CVideoPlayerAudio::OutputPacket - was:1790637.251736, should be:1748141.865272, error:-42495.386464
10:29:26 T:11120   DEBUG: CVideoPlayer::CheckContinuity - wrapback :1, prev:10293000.000000, curr:10283000.000000, diff:-10000.000000

Test video file uploaded:
https://www.dropbox.com/s/v0vngg4ie1goi5...t.mkv?dl=0

[FernetMenta]

I tried your sample and noticed no issues. No discontinuity msgs in the log:
http://pastebin.com/RTwdy5Bq

[Voyager]

Interesting. So it's Windows-specific (at least). If we compare between Jarvis and Krypton, (DXVAHD) rendering is the same on Windows and VideoPlayer likes my sample on Mac OSX. The only remaining thing I can think of is something with AE on Windows causing this synchronization mess... I tried both DirectSound and WASAPI - same result.

Any thoughts?

[FernetMenta]

Timestamps look strange in your log:
CVideoPlayer::CheckContinuity - wrapback :1, prev:10293000.000000, curr:10283000.000000

That is independent from platform and way before AE or dxva. Are you sure you have recompiled mingw libs (ffmpeg) after switching back from Jarvis? Also make sure to delete any prior downloads of ffmpeg. I can't find the git hash from your log. What version is this?

[Voyager]

This is my own build indeed with one additional library-related commit, nothing player-related at all.

I just tried with the current nightly from http://mirrors.kodi.tv/nightlies/win32/ and I'm not getting those messages either. So it must be my build then. I'm surprised because I correctly recompiled everything... I'll try cleaning up the prior downloads.

[Voyager]

wait a sec... In my previous post I tested on a different PC with the nightly. I just put the nightly on my DEV PC - same issue.
I also fully rebuilt and cleaned up ffmpeg.

See [edit : log from nightly]:
http://xbmclogs.com/p3ntgcz9t

Could it be a driver issue? It's weird that Jarvis is fine.

[Uukrul]

I also tried your sample with my fresh build from master and no problems here. IMHO, VideoPlayer is now pretty much rock solid, and with hardware decoding for DVDs on the platforms I use (Windows and Android) even better

[Voyager]

@Uukrul - I think it's probably rock solid on the platforms *you* use.

FYI I have Kodi running on 3 PCs, each one with a different AMD GPU. All machines are on Windows 10, and have the Crimson drivers (15.12).
- Core i7 1st gen / AMD R7 250 --> no stutter (that's where I quickly tested the nightly yesterday)
- Core i7 3rd gen / AMD HD7650 (Mobile) = my dev PC --> stutter issue
- AMD A4-5000 / AMD HD8330 (APU) - living room HTPC --> stutter issue

for comparison, Jarvis works great on each of them.

[FernetMenta]

wait a sec... In my previous post I tested on a different PC with the nightly. I just put the nightly on my DEV PC - same issue.
I also fully rebuilt and cleaned up ffmpeg.

See [edit : log from nightly]:
http://xbmclogs.com/p3ntgcz9t

Could it be a driver issue? It's weird that Jarvis is fine.

could you try with this https://github.com/xbmc/xbmc/pull/9017

[Uukrul]

@Voyager: did you try to run Kodi with a clean userdata or in portable mode with all settings set to default?

[Voyager]

could you try with this https://github.com/xbmc/xbmc/pull/9017

no change, unfortunately.

[Voyager]

@Voyager: did you try to run Kodi with a clean userdata or in portable mode with all settings set to default?

@Uukrul - thanks you are INDEED onto something here! I renamed my guisettings.xml file to guisettings-backup.xml to start with fresh settings. Et voilà!
Now the only thing left is finding the explanation! (and perhaps addressing the root cause of catching a legacy setting that causes this). I'm taking a look at the xml file right now and will report what I find out.

[FernetMenta]

Interesting. Waiting on your findings.

[Voyager]

ok - don't cheer too soon. The difference is the prefer default audio streams setting, causing the AC3 track to be selected instead of the DTS one. AC3 (1/2) is smooth while DTS track (2/2) is choppy.

[MrMC]

I've recently seen that 'CVideoPlayer::CheckContinuity - wrapback' on content that did not have them before. I suspect FFMpeg bumps but have not had time to investigate.