Infinite loop on live content with discontinuities on Tizen

[jakubvojacek]

Have you read the FAQ and checked for duplicate open issues?
yes

If the problem is related to FairPlay, have you read the tutorial?
its not related

What version of Shaka Player are you using?
latest, 4.10.9

Can you reproduce the issue with our latest release version?
yes

Can you reproduce the issue with the latest code from main?
did not try

Are you using the demo app or your own custom app?
own app

If custom app, can you reproduce the issue using our demo app?
its a tizen application

What browser and OS are you using?
Tizen/WebOS

For embedded devices (smart TVs, etc.), what model and firmware version are you using?
Tizen 5.5 (year 2020) and WebOS 2021 but we experience this issue on newer Tizens too.

What are the manifest and license server URIs?
its a live content which changes periodically (we autorestart the live packaging every 20 minutes orso because we autodetect too many gaps in the MPD). In order to get the working MPD url, please use following cURL

curl 'https://mw.motv.eu/public/channel/getStreamUrlV3' \
  -H 'sec-ch-ua: "Not)A;Brand";v="99", "Google Chrome";v="127", "Chromium";v="127"' \
  -H 'language: Y3M=' \
  -H 'sec-ch-ua-platform: "macOS"' \
  -H 'sec-ch-ua-mobile: ?0' \
  -H 'Authorization: Bearer glf40bnmzmmwiw85glre6gqy8qjjvnhy99g90ul8' \
  -H 'User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/127.0.0.0 Safari/537.36' \
  -H 'Content-Type: text/plain;charset=UTF-8' \
  -H 'Referer;' \
  -H 'devicesType: d2ViIHBsYXllcg==' \
  -H 'profilesId: Mjc0NDgz' \
  --data-raw '{"data": {"channelsId":383,"devicesIdentification":"Mac OS 10.15.7 Chrome 127","devicesHash":"1689914173"}}'

and use response.url.

What configuration are you using? What is the output of player.getConfiguration()?

we used default configuration, just initialize shaka and played the MPD, no DRM or additional changes were done.

What did you do?

We sometimes get reports from our customers about infinite looping on live tv channels only on Samsung. We managed to track these issues to MPD gaps in the MPD manifest. Those gaps can be caused for example by bad weather (we receive some of the inputs via satellite) or whatever. I understand that its a source problem and without the gaps, the player would play perfectly fine. But the thing is that its only Tizen that loops, we use other platforms, such as shaka-player in web, shaka-player on LG (webOS), exoplayer on android, av player on ios - and all these survives the gaps very nicely.

Since both web player and LG survives the gaps and do not loop and they share the same codebase and shaka player version and everything, it must be related somehow to how Samsung plays the content. I could share URLs to the real MPDs but the problem ocurrs few times a week only and therefore its very hard to debug on real channels. To simulate it better, I took sintel trailer, used python to simulate 0.001% packet loss and now I am playing the TS file in a loop with ffmpeg and I am using shaka-packager to package it to live dash. I manage to reproduce the issue on tizen this way within seconds of testing.

What did you expect to happen?

I would like for the playback to not loop. If you test the content I provided above, on tizen, it should start looping immediatelly. On LG it usually plays quite fine (but sometimes it gets stuck too, but majority of times it plays quite well). The damage to the stream is extreme compared to the actual live channels but this way its testeable quite quickly without having to wait for hours/days.

What actually happened?

The content loops on Tizen, does not loop in web/LG. If you could please guide me what I could test in order to make the playback on tizen more robust so that it would behave the same as on LG/web.

Are you planning send a PR to fix it?

I unfortunately have no idea what to change.

[jakubvojacek]

I now got an idea of making a static VOD from the damaged sintel demo. It might be easier for you guys to test with static content instead of live. The MPD is available here https://edge1.motv.eu/s1/vods/28/sintel-gaps-7107/66ab7059f1383-2632-mp4-clear.mpd

I just tested on both Tizen and WebOS and it does not start playing Tizen at all and plays normally on WebOS.

Thank you

[avelad]

Log that appears in the browser:
Jumping forward 0.001057 seconds because of gap before start time of 0.001057

[avelad]

I now got an idea of making a static VOD from the damaged sintel demo. It might be easier for you guys to test with static content instead of live. The MPD is available here https://edge1.motv.eu/s1/vods/28/sintel-gaps-7107/66ab7059f1383-2632-mp4-clear.mpd

I just tested on both Tizen and WebOS and it does not start playing Tizen at all and plays normally on WebOS.

Thank you

The bug could be somewhere in this function: https://github.com/shaka-project/shaka-player/blob/main/lib/media/gap_jumping_controller.js#L165, for example, can you investigate if the time is set correctly?

[jakubvojacek]

Hello @avelad

thank you for pointing me in some direction. I attempted to test it (it was tricky, first time compiling shaka player etc) and not very familiar with javascript actually.

I got some results, hopefully, you can point me further by looking at them. I added some logging

diff --git a/lib/media/gap_jumping_controller.js b/lib/media/gap_jumping_controller.js
index c2267f74a..8d47a37e3 100644
--- a/lib/media/gap_jumping_controller.js
+++ b/lib/media/gap_jumping_controller.js
@@ -202,6 +202,12 @@ shaka.media.GapJumpingController = class {
     const buffered = this.video_.buffered;
     const gapDetectionThreshold = this.config_.gapDetectionThreshold;
 
+    if (currentTime < 2) {
+      console.error(["myoutput",
+      currentTime, buffered, gapDetectionThreshold
+      ])
+    }
+
   

This is how it looked on LG (webos)

and this is Samsung (tizen)

(sorry for the pictures instead of plain text, TVs are a mess to debug, i just redirected console to div element to make debugging easier)

the main difference i see that on LG, there was some stall detected. That is a message that never appeared on tizen. In the source code, I read that stall detector could be disabled for some platforms, could be the case?

As you can see the tizen playback fails completely with 3016 error (media error = 3). I read on github that this could be related to negative DTS but the time is 0 and then 0.001, never negative.

[Iragne]

@avelad we are facing the same issue info it loop of the gap manager in period discontinuity due to possible gap and stall

Running an experimental build on o test it tomorrow

Hope it will help

[Iragne]

Look like we are flooding the video component of "Jumping forward" more than 20 call in less than 2 secondes

Jumping forward ...
Jumping forward ...
Jumping forward ...

[avelad]

@Iragne Can you put the values ​​between which it jumps, maybe it is a rounding problem? (similar to 5b6e340 )

[Iragne]

I apply the same patch Plus a pause play action to the seek

[Iragne]

I had been able to narrow down the issue.

• Too much call to the skeek trigger by onSegmentAppended() and by this.eventManager_.listen(video, 'waiting, because the player is not able to jump gap, it stay in a block state and the event waiting is trigger each time we seek.
• after a period of time the stall manager is trigger but he is unable to unstall because of the number of call trigger by the GAP manager
• I'm still check how we can jump the GAP properly without all my workaround.
• the solution here fix: Xbox - round gap jumping values #6695 is not solving the issue.

The idea would be the following

• limit the call to waiting by using a temporary flag
• Jumping the GAP with the same approach of the stall manager

[avelad]

@Iragne do you want implement it?

[Iragne]

I'm currently testing it. I can propose something as soon as it's working properly

Juste sharing info in case you are again faster ^^

[Iragne]

I had been able to go more in deep in the issue. look like the jumpTo = buffered.start(gapIndex) is not working.
if we add a padding of 2 it's fine and working well. i'm quite surprise of this and not sure it can be productize. I will still continue to investigate but if you have any idea @avelad i'm happy to take it

But let say that now our tizen is working perfectly.

[avelad]

I had been able to go more in deep in the issue. look like the jumpTo = buffered.start(gapIndex) is not working. if we add a padding of 2 it's fine and working well. i'm quite surprise of this and not sure it can be productize. I will still continue to investigate but if you have any idea @avelad i'm happy to take it

But let say that now our tizen is working perfectly.

I can think of making that parameter configurable and having Tizen's value be 2 and the rest 0, what do you think?

[Iragne]

yep

[Iragne]

Btw i had the same issue on the stall manager i had to do it with a play and pause

[Iragne]

#7331

[jakubvojacek]

I can confirm that this fixes the issue for our live content. I had to increase gapPadding to 8 to jump some of the gaps but that's because the test content I created is really messy, the production one wont be as bad.

Thank you very much @Iragne for help

[jakubvojacek]

@avelad any idea when there will be a new release? Would love to send this to our customers but our pipeline currently requires downloads via npm

Thank you a lot 🙏

[avelad]

In the next release cycle, between today and tomorrow I will release them.