Playback issues (skips in the video) of some streams

[michaelarnauts]

Some streams run in a loop, or are having other issues.

This issue can be used to keep track of those streams, so we know which one to test, and to come up with a solution.

A few examples, although almost every video is affected multiple times:

• De Dag, episode 3, at 18:56.
• De Dag, episode 3, at 38:24
• De Mol, season 7, episode 1, at the very start
• Hotel Romantiek...

[dagwieers]

This issue has been documented already for Retrospect (retrospect-addon/plugin.video.retrospect#1089) and in Kodi (xbmc/xbmc#16003).

[dagwieers]

On Kodi 18 and older, and Raspberry Pi 3 and older, you can workaround this problem by enabling Allow hardware acceleration » OMXPlayer in the settings at Settings » Player » Videos » Processing. This will not fix all issues, but it makes watching the streams more enjoyable.

[dagwieers]

The OMXPlayer workaround is implemented in the add-on. So this ought to work better out of the box on Raspberry Pi 3 and older, using Kodi v18 (Leia).

[michaelarnauts]

Okay, maybe this is all nothing new, but I'll document it here for completeness :)

I've used http:https://inspectstream.theoplayer.com/ to check the HLS stream of the first episode of De Mol, season 7.

-> https://stream2-vod.cdn1.sbs.prd.telenet-ops.be/non-geo/vier/demol/2019/volledigeafleveringen/d1eea4f39e378e362fd814bda32b948a3c8aa262/E01/E01.m3u8

This list of things that are wrong is extensive, but what rings a bell is:

Video and audio are out of sync for: 7.776 seconds.https://stream2-vod.cdn1.sbs.prd.telenet-ops.be/non-geo/vier/demol/2019/volledigeafleveringen/d1eea4f39e378e362fd814bda32b948a3c8aa262/E01/Output400/segment248.ts
Video and audio are out of sync for: 5.216 seconds.https://stream2-vod.cdn1.sbs.prd.telenet-ops.be/non-geo/vier/demol/2019/volledigeafleveringen/d1eea4f39e378e362fd814bda32b948a3c8aa262/E01/Output800/segment247.ts
Video and audio are out of sync for: 1.016 seconds.https://stream2-vod.cdn1.sbs.prd.telenet-ops.be/non-geo/vier/demol/2019/volledigeafleveringen/d1eea4f39e378e362fd814bda32b948a3c8aa262/E01/Output400/segment1.ts
Video and audio are out of sync for: 5.216 seconds.https://stream2-vod.cdn1.sbs.prd.telenet-ops.be/non-geo/vier/demol/2019/volledigeafleveringen/d1eea4f39e378e362fd814bda32b948a3c8aa262/E01/Output1200/segment245.ts
Video and audio are out of sync for: 9.696 seconds.https://stream2-vod.cdn1.sbs.prd.telenet-ops.be/non-geo/vier/demol/2019/volledigeafleveringen/d1eea4f39e378e362fd814bda32b948a3c8aa262/E01/Output800/segment1.ts
Video and audio are out of sync for: 9.536 seconds.https://stream2-vod.cdn1.sbs.prd.telenet-ops.be/non-geo/vier/demol/2019/volledigeafleveringen/d1eea4f39e378e362fd814bda32b948a3c8aa262/E01/Output1200/segment1.ts
Video and audio are out of sync for: 9.536 seconds.https://stream2-vod.cdn1.sbs.prd.telenet-ops.be/non-geo/vier/demol/2019/volledigeafleveringen/d1eea4f39e378e362fd814bda32b948a3c8aa262/E01/Output1600/segment1.ts

I've remember reading somewhere that Kodi had only a buffer of 8 seconds. That's not enough for this.

[dagwieers]

@michaelarnauts That is a great find! It would also mean that selecting the 400kbps stream would not have issues, while the others do have issues. And lo and behold, if I select a maximum bitrate of 500kbps (in Retrospect), it plays without delays. As soon as I move it to max 1Mbps, the issue starts to appear again.

Using OMXPlayer I have no issues with this episode! So I currently see no issues on the VIER-VIJF-ZES add-on because it enables OMXPlayer by default. So we should look into why OMXPlayer works fine (just like the web player) and how Kodi can handle this issue better. It is possible.

[mediaminister]

@michaelarnauts I am convinced that you have found the cause of this problem. So, I can confirm that the problem is related to a crappy HLS encoder/segmenter that outputs segments with large delays between the video and the audio streams.

Kodi VideoPlayer has indeed only a time buffer of 8 seconds, so Kodi cannot play HLS-segments with an audio stream that is shifted more than 8 seconds from the video stream.

I investigated this problem using a small script and found out that increasing the VideoPlayer queue to 10 seconds can already solve this problem for De Dag, episode 3. I didn't investigate other programs yet.

Here is a list with possible timecodes where this problem should occur for De Dag, episode 3:

00:03:16.269 -> segment15.ts is 8.731 seconds out of sync
00:14:24.627 -> segment66.ts is 8.373 seconds out of sync
00:19:21.235 -> segment89.ts is 8.765 seconds out of sync
00:21:18.592 -> segment98.ts is 9.408 seconds out of sync
00:22:11.789 -> segment102.ts is 8.211 seconds out of sync
00:22:44.397 -> segment104.ts is 8.603 seconds out of sync
00:24:18.349 -> segment111.ts is 9.651 seconds out of sync
00:25:00.141 -> segment114.ts is 9.859 seconds out of sync
00:26:21.109 -> segment120.ts is 9.891 seconds out of sync
00:26:41.307 -> segment121.ts is 8.693 seconds out of sync
00:36:01.200 -> segment166.ts is 8.800 seconds out of sync
00:37:01.669 -> segment171.ts is 9.331 seconds out of sync
00:38:26.429 -> segment177.ts is 8.571 seconds out of sync
00:39:37.709 -> segment182.ts is 8.291 seconds out of sync
00:40:27.704 -> segment185.ts is 8.296 seconds out of sync
00:45:03.890 -> segment206.ts is 8.110 seconds out of sync
00:47:11.595 -> segment216.ts is 8.405 seconds out of sync

Please report if all timecodes are correct.

[michaelarnauts]

Okay, long text, but bear with me in this one.

TLDR: There are two issues, one with the 8 second buffer that isn't large enough in some cases, and one with the HLS processing that causes Kodi to jump around trying to fix itself.

I'm using De Mol S07E01 as example, since the issue there happens already in the first segment, segment0.ts.

URLs that are currently valid, but I don't know for how long. I guess they don't expire that fast.

• segment0.ts: https://stream2-vod.cdn1.sbs.prd.telenet-ops.be/non-geo/vier/demol/2019/volledigeafleveringen/d1eea4f39e378e362fd814bda32b948a3c8aa262/E01/Output1600/segment0.ts
• segment1.ts: https://stream2-vod.cdn1.sbs.prd.telenet-ops.be/non-geo/vier/demol/2019/volledigeafleveringen/d1eea4f39e378e362fd814bda32b948a3c8aa262/E01/Output1600/segment1.ts

The first segment contains the video for the first 19 seconds and audio for the first 10 seconds. The audio for the last 9 seconds of video in segment0.ts is actually in segment1.ts, so we need segment1.ts also in the buffer to fully play segment0.ts.

I think there is also a problem that Kodi doesn't process the 2nd segment until it's finished with the current segment, but only in a HLS context.

When playing trough the addon, after the first 10 seconds, Kodi notices that there is no audio in the buffer to be seen, and tries to fix things, I guess by seeking to some known point (maybe the next keyframe?). This point happens to be exactly the start of the next segment, so maybe it just skips the current segment when this happens.

Okay, now when I only play segment0.ts, trough the file browser, Kodi plays it fine untill the end (19 seconds), although of course, the audio drops out at 10 seconds. This seems to indicate that the video player can actually continue without sound.

Next thing, I just concatinate the two files (cat segment0.ts segment1.ts > combined.ts). Since .ts files have no header, this works fine. When I play this in Kodi, there is indeed an audio issue at 10 seconds, no sound for about 1.5 second, but the playback continues fine.

This 1.5 seconds is the time needed for additional audio frames to enter the buffer (8 seconds kodi buffer + 1.5 seconds = 9.5 seconds a/v out of sync). The math adds up, and I'm also quite certain that increasing the 8 seconds buffer is a valid fix in this case.

But one thing still doesn't make sense. When playing this combined file, Kodi continues normally, with the 1.5 second silence, but it doesn't start seeking. This seem to indicate that there is code that is only executed during HLS processing, that causes the stream to fix.

This code is also an issue. If it wouldn't start jumping around, this 1.5 second of sound mute is not so much of an issue (I mean, it is, but at least you can watch the program).

I hope this all makes sense, and it might help somebody else out who knows more about the Kodi internals on this.

Note: When you combine the ts files with ffmpeg (ffmpeg -i concat:segment0.ts\|segment1.ts -vcodec copy -acodec copy combined2.ts), you get a different file with no problems at all, since ffmpeg will rearrange the frames so the a/v async issue is gone.

[michaelarnauts]

(Renamed the title since it's not limited to ARM devices)

[mediaminister]

Next thing, I just concatenate the two files (cat segment0.ts segment1.ts > combined.ts). Since .ts files have no header, this works fine. When I play this in Kodi, there is indeed an audio issue at 10 seconds, no sound for about 1.5 second, but the playback continues fine.

I just did the same test. The silence gap of 1.5 seconds is caused by the empty time buffer. I compiled Kodi 19 with an increased VideoPlayer queue of 10 seconds and the concatenated .ts file just plays flawlessly.

[dagwieers]

I proposed our fix upstream to Kodi here: xbmc/xbmc#17646

[rottweilerken]

I understand this issue is not related to the plugin as such, but I've always had this issue and now still on matrix. It's sooo annoying on everything I play from goplay..
I wonder is there any workaround available?
(I'm running libreelec Kodi 10 on x86_64 nuc i7 with 16g ram and SSD..)
I've tried Openwizard but doesn't seem to help much..

[dagwieers]

Yes, the workaround is in here: xbmc/xbmc#17646

There is a solution described that needs implementing to get fixed.

[rottweilerken]

Thanks for the reference (and all your efforts btw), i can see your proposed solution to increase the cache, but what is the workaround exactly except having to compile it with those changes

[dagwieers]

@rottweilerken The discussion that followed tries to explain what is needed to have my change merged, but it appears that more people are confused about what exactly is needed.

That may be Kodi's biggest problem. It needs better documented or refactored code in order to get more people involved.

[wardwygaerts]

Does everyone has these issues with all programs? Because I only notice these issues during 'De Mol': video stops, but audio keeps going, after some seconds video is back ok. We also watch 'Container Cup' and 'Blind Gekocht', these episodes are playing perfect, without any issues. I'm running Kodi on a Pi3B+

[CharlieMK]

Yes, I’m also having these issues since a very long time. It’s worse than you describe since sometimes the playback jumps all the way back to the beginning (happened 3 times during the last episode of ‘de mol’ for example). I sincerely hoped Matrix would solve it, but it did not. Anyway, I think you’re doing great work and I understand from the discussions it’s not up to you to fix it.

By the way, I think we also have these issues with other programs such as ‘blind getrouwd’ but I must admit I’m not sure. I’ll try to pay attention.

I’m running Matrix (libreelec) on RPI 4b.

[timschuerewegen]

CVideoPlayerVideo
=> the proposed SetMaxTimeSize(10.0) change still caused a playback glitch on Auwch_ season 1 episode 7 somewhere between 20:00 and 21:00, so I increased it to 11.0, and the glitch was gone

CVideoPlayerAudio
=> the proposed SetMaxTimeSize(10.0) change is not necessary

[keiem]

Same problem here on Libreelec 10 for pineH64 during "De Slimste Mens S16-Afl.1". I will try to recompile LE with the kodi patch from @peak3d.