Playback stalls after a few seconds

[taleteller]

Context

Please provide any relevant information about your setup

• Add-on Version: 7.0.2.2 unofficial
• Kodi Version: 20.2
• Kodi GUI Language: German
• Operating System: Batocera 38

---

Expected Behavior

Playing the whole video ;-)

---

Current Behavior

Some random videos play for just a few seconds. These start perfectly fine but after like 30-50 seconds they simply stall. Sometimes Kodi shows some "1% Buffering" never to increase and abort the playback process after a few more seconds. The affected videos dont seem to have anything in common.

The Issue seems perfectly consistent, when a video is affected to stall it always stalls at the exact same moment each time you try. If you try to skip the timestamp it will stall a few seconds later.

---

Steps to Reproduce

I attached the debug log from playing back an affected video. The link to the video on youtube is https://www.youtube.com/watch?v=zt7abnwNMAo and it plays perfectly fine in browser.

---

Log

kodi.zip

---

[MoojMidge]

The video starts playing an AV1 video stream and falls back to using a software decoder. A stream change occurs shortly after (not sure why) and a h264 stream starts to play, but it doesn't seem as if the new decoder is properly initialised (could be wrong about this but it is not mentioned in the logs) and you end up having a large amount of ffmpeg related decoding errors in your log.

In the Youtube plugin you can open Settings > MPEG-DASH > Use MPEG-DASH for videos > Stream features and deselect Enable AV1 video to see if that changes anything.

[taleteller]

Yes that changes things. If I disable AV1 the video keeps playing using h264. I also tried the opposite, disabling h264 while keeping AV1. There also the video keeps playing using "ff-libdav1d" as decoder. Remains the riddle why it changes codec while playback. AV1 typically has lower datarates than h264 I cant see why it would change to a worse one.

[MoojMidge]

The bitrate of the AV1 streams are typically lower than the same resolution h264 streams, with the exception of some premium high bitrate streams. The quaility of the AV1 streams are generally equivalent or better, apart from the premium streams, while requiring lower bandwidth to stream because of the lower bitrate.

The Youtube plugin ranks (somewhat arbitrarily) the different streams based on the relative bitrate - a h264 stream has to have 2x the bitrate of an AV1 stream and 1.5x the bitrate of a VP9 stream to be more preferred, while VP9 has to have 1.33x the bitrate of an AV1 video to be more preferred.

InputStream.Adaptive appears to rank streams based on the actual bitrate, higher bitrates being higher ranked, without making any assessment of stream quality, because that can be very subjective and will vary depending on encoding techniques/settings.

InputStream.Adaptive checks the ability to play a stream based on the available bandwidth and then chooses the best stream based on the resolution and bitrate. After the initial assessment based on InputStream.Adaptive settings it will automatically choose the stream based on the actual bandwidth (this can be disabled in the InputStream.Adaptive settings).

This is likely why the stream change occurs - the measured bandwidth is sufficient to play the higher bitrate h264 and so InputStream.Adaptive switches to it because it has a higher bitrate (around 1.6x higher) than the AV1 stream, even though it is a poorer quality stream.

The next issue is that when the stream change occurs, the new decoder does not appear to be properly initialised, which causes the issue in playback.

In the Youtube plugin different Representation elements (the AV1 and h264 streams) are combined in the same AdaptationSet (groups of streams) as long as they have the same mime type (video/mp4). Pretty sure this is allowed in the MPEG-DASH specification, but perhaps InputStream.Adaptive does not support this, and instead expects all the Representation elements in the same AdaptationSet to use the same decoder? I'll have to check the code to see what it actually does.

In comparison the VP9 streams are in a different AdaptationSet and the stream switching, from AV1/h264 to VP9 and vice versa, works properly. To workaround this problem I will try and split the AV1 and h264 streams into different AdaptationSet elements in the MPEG-DASH manifest for the next release of the Youtube plugin.

In the meantime, as both of the problems you have encounted appear to be issues with InputStream.Adaptive, suggest a bug report should be raised there as well.

[MoojMidge]

For the shortterm, suggest just disabling either h264 or AV1 in the Youtube plugin settings.

[neo-neo1]

I've had this same issue for ever but ONLY ON Live Premiere videos. Regular Live videos play fine. Can you confirm if your issue exist solely on Live or Live Premiere videos?

I think Premiere videos is the key here. This Addon doesn't work with them, not sure if it's a known issue.

[MoojMidge]

The issue identified by the OP is a very specific one, unrelated to live videos or premieres, and a fix will be available in the next release.

There is nothing really different between live videos and live premiere videos, nor regular videos and premieres. If you are having problems with them, a new issue with a debug log and a link to a problematic live premiere video (or ideally a channel that regularly creates theses videos) so it can be properly investigated.

[elektrikfisch]

Thank you so much for the incoming fix <3

I'm having (I think) the same issue, and since nobody else has chimed in I figured I'd drop my log and some context in here in case it helps should there be a regression in the future. I'm too tired to follow the log well enough to find a stream change, but it is flooded with the same ffmpeg error missing picture in access unit with size [value]

Usually when I get this issue, I can skip past the point where a video locks up and then it'll play the rest without any issues. Only in the last couple days is it refusing to play more than 30-45 seconds of any video regardless of whether I skip past the first minute. Not sure what's changed on my end. However, disabling AV1 in MPEG-DASH stream features seems to fix the issue entirely. EDIT: Also works when re-enabling AV1 and disabling H.264. Agree that AV1 seems to look better, at least on the particular video I'm using to test.

kodi.log

Raspberry Pi 4
LibreElec 11.0.3 (Kodi 20.2)

Looking forward to the next release. Thanks again!

[MoojMidge]

Yes its the same issue with InputStream.Adaptive. Selection and initialisation of AV1 (codec_id: 32797) decoder at start of video:

2023-12-04 19:39:03.568 T:970     debug <general>: AddOnLog: inputstream.adaptive: [Repr. chooser] Stream selection conditions
                                                   Screen resolution: 1920x1080 (may be limited by settings)
                                                   Initial bandwidth: 4000000 bit/s
2023-12-04 19:39:03.568 T:970     debug <general>: AddOnLog: inputstream.adaptive: [Repr. chooser] Current average bandwidth: 4000000 bit/s (filtered to 3600000 bit/s)
2023-12-04 19:39:03.568 T:970     debug <general>: AddOnLog: inputstream.adaptive: [Repr. chooser] Selected representation
                                                   ID 399 (Bandwidth: 1965431 bit/s, Resolution: 1440x1080)
2023-12-04 19:39:03.568 T:970     debug <general>: AddOnLog: inputstream.adaptive: GetCapabilities()
2023-12-04 19:39:03.568 T:970      info <general>: Creating Demuxer
2023-12-04 19:39:03.568 T:970     debug <general>: AddOnLog: inputstream.adaptive: GetStreamIds()
2023-12-04 19:39:03.568 T:970     debug <general>: AddOnLog: inputstream.adaptive: GetStream(1001)
2023-12-04 19:39:03.569 T:970     debug <general>: AddOnLog: inputstream.adaptive: GetStream(1002)
2023-12-04 19:39:03.569 T:970     debug <general>: CDVDDemuxClient::RequestStream(): added/updated stream 1001 with codec_id 32797
2023-12-04 19:39:03.569 T:970     debug <general>: CDVDDemuxClient::RequestStream(): added/updated stream 1002 with codec_id 86076
2023-12-04 19:39:03.569 T:970      info <general>: Opening stream: 1001 source: 256
2023-12-04 19:39:03.569 T:970     debug <general>: AddOnLog: inputstream.adaptive: OpenStream(1001)

and then a little later selecting but failing to initialise the H.264 (codec_id: 27) decoder:

2023-12-04 19:39:30.277 T:3514    debug <general>: AddOnLog: inputstream.adaptive: [Repr. chooser] Current average bandwidth: 75421120 bit/s (filtered to 67879008 bit/s)
2023-12-04 19:39:30.279 T:972     debug <general>: CurlFile::Open - <...>
2023-12-04 19:39:30.320 T:970     debug <general>: AddOnLog: inputstream.adaptive: DEMUX_SPECIALID_STREAMCHANGE
2023-12-04 19:39:30.320 T:970     debug <general>: AddOnLog: inputstream.adaptive: GetStreamIds()
2023-12-04 19:39:30.320 T:970     debug <general>: AddOnLog: inputstream.adaptive: GetStream(1001)
2023-12-04 19:39:30.320 T:970     debug <general>: AddOnLog: inputstream.adaptive: GetStream(1002)
2023-12-04 19:39:30.321 T:970     debug <general>: CDVDDemuxClient::RequestStream(): added/updated stream 1001 with codec_id 27
2023-12-04 19:39:30.321 T:970     debug <general>: CDVDDemuxClient::RequestStream(): added/updated stream 1002 with codec_id 86076
2023-12-04 19:39:30.327 T:970     error <general>: ffmpeg[0x36c69c8]: [h264] missing picture in access unit with size 49470

Also works when re-enabling AV1 and disabling H.264. Agree that AV1 seems to look better, at least on the particular video I'm using to test.

Yeah, except for premium streams, or some old videos that I guess were encoded with better quality and not re-encoded, AV1 seems noticeably better than the H.264 streams to me. VP9 streams seem to vary in comparison to the AV1 streams, but generally appear the same or better than the H.264 streams, but require lower bandwidth.

[elektrikfisch]

Thanks for breaking that down for me!

Are there any cases where one stream is available while the other is not? Or, to put it another way, will disabling one stream or the other result in being unable to play some videos?

[MoojMidge]

While there are quite a few videos where there are no AV1 streams, I have yet to see any video without H.264 or AV1 streams and also VP9 streams. There might be some, but I have not come across any.

Recommend enabling AV1 and VP9 for best quality, H.264 and VP9 for lower powered devices. After the workaround is released, can enable all three.

[onlytanmoy]

Recommend enabling AV1 and VP9 for best quality, H.264 and VP9 for lower powered devices. After the workaround is released, can enable all three.

I think my problem is probably related to this, so I am using the addon in Kodi in my Shield TV and while playing any 4k videos if I fast forward the video then there is a lag between audio and video, so the audio goes on but the video can only catch-up after some time, they are not in sync, I am using 500mbps fibre broadband. Any settings I need to do to fix that please?

[MoojMidge]

@onlytanmoy - The location of the setting is in the second post of this issue, but your issue is unrelated, and is probably a duplicate of #537

[onlytanmoy]

@onlytanmoy - The location of the setting is in the second post of this issue, but your issue is unrelated, and is probably a duplicate of #537

Yeah right, I found that post after I commented here haha, thanks.