[Voyager]

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.

I don't think it's ffmpeg - we're using the same version between Jarvis and Krypton master (2.8.5-Jarvis-rc1)

[FernetMenta]

I suspect mkvmerge having an issue writing the second audio track in sync.
@Voyager can you post a Jarvis log after playing the DTS track?

[FernetMenta]

https://github.com/xbmc/xbmc/pull/9028 should cure the symptoms a bit.
That does not change the fact that timestamps of the video are messed up by mkvmerge. Jarvis calculated the average error over a period of 2 seconds that does further smooth out the error.

I don't know if its worth to work around errors introduced by a version of mkvmerge that is 3 years old (v6.3.0). One way to do so would be to switch to a less picky mode when we detect such discontinuities in timestamps.

[Voyager]

I'll try this today and will let you know. The theory sounds plausible, because I had other examples with DTS tracks that I was able to "fix" by remuxing. That said, I don't fancy remuxing a lot of material that played well on a previous version of Kodi - I don't think anyone would.
I like the idea of a less picky fallback position in case these discontinuities get detected...

[Voyager]

@FernetMenta - quick update
- here's the requested Jarvis (RC2) debug log. http://xbmclogs.com/p8nngfo1t - you'll notice that the same log entries are there... I didn't know this, as there is nothing noticeable in playback.
- I have also tried the latest Krypton master with PR 9028 included, I didn't notice a significant improvement, maybe a little...
Note that there is also another way to "test" this with Krypton, and that's to turn on "Sync Playback to Display" (which causes audio resampling). The sound gets really ugly as the pitch goes up and down constantly. However, video is smooth :-). Sync Playback to Display is fine on Jarvis.

If you have a spot where I can experiment with smoothing the error (as you suggested), please let me know.

[FernetMenta]

https://github.com/xbmc/xbmc/blob/master....cpp#L2323

interval for average error is 1000ms. try 2000ms or 3000ms

[Voyager]

I just tried the following combinations of int timeout = (stream->m_syncState != CAESyncInfo::AESyncState::SYNC_INSYNC) ? XXXX : YYYY;

- 100 : 2000 - some improvement of the example
- 100 : 3000 - not really better than 100: 2000
- 2000 : 2000 - i.e. constant timeout regardless of sync status: seems to be the best - no glitches anymore
- 2000 : 3000 - no difference with 2000:2000

it's all a bit unscientific, but I have a feeling that a constant timeout could be better if the muxing error is "fluctuating".

[FernetMenta]

The first parameter has no influence here. It is used until the stream is in-sync. The interval should be that long that jumps of pts to both directions are smoothed out.
Try: https://github.com/FernetMenta/xbmc/comm...f3c25d4b85
Check the log. After interval is set to 5022ms, playback is smooth.

[Voyager]

hi - just quickly tested before work... indeed as you say, nice work! I also tested three other cases in the same situation that went up to 3005, 4040 and even 6000 ms. All good.

The remaining issue is only when you turn on 'sync playback to display'. For correctly muxed mkv's it's fine, but these messy examples sound horrible. I'm ok leaving as is, it doesn't look like a priority thing to solve...

[Voyager]

forgot to mention : you need to #include <atomic> in ActiveAEStream.h to fix compile error.

[FernetMenta]

here is an update: https://github.com/FernetMenta/xbmc/comm...0a8f96987c

Adjusted calculation of resample ration to observe the error calculation period.

[Voyager]

thanks @FernetMenta I've tested and resampling is good now as well! Great stuff...

I think I'm going back to Krypton now ;-)

[afedchin]

@Voyager
so rendering part in Krypton works just as well as in Jarvis?

[Voyager]

so rendering part in Krypton works just as well as in Jarvis?

as far as I can tell ATM, yes