Shaka 3.2 not handling transistion from Live to On Demand

[DavidRNogueiraResi]

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

What version of Shaka Player are you using?
3.2

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

Can you reproduce the issue with the latest code from master?
Yes

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

If custom app, can you reproduce the issue using our demo app?
Yes

What browser and OS are you using?
Chrome, MacOS

For embedded devices (smart TVs, etc.), what model and firmware version are you using?
N/A

What are the manifest and license server URIs?

https://resi.media/la1p-delete_me_2_ekt/d3ce2a76-1742-4444-8aa6-727f02f2fd0e/Manifest.mpd

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

{
   "drm":{
      "retryParameters":{
         "maxAttempts":2,
         "baseDelay":1000,
         "backoffFactor":2,
         "fuzzFactor":0.5,
         "timeout":0
      },
      "servers":{
         
      },
      "clearKeys":{
         
      },
      "advanced":{
         
      },
      "delayLicenseRequestUntilPlayed":false
   },
   "manifest":{
      "retryParameters":{
         "maxAttempts":2,
         "baseDelay":1000,
         "backoffFactor":2,
         "fuzzFactor":0.5,
         "timeout":0
      },
      "availabilityWindowOverride":null,
      "dash":{
         "clockSyncUri":"",
         "ignoreDrmInfo":false,
         "xlinkFailGracefully":false,
         "defaultPresentationDelay":10
      }
   },
   "streaming":{
      "retryParameters":{
         "maxAttempts":2,
         "baseDelay":1000,
         "backoffFactor":2,
         "fuzzFactor":0.5,
         "timeout":0
      },
      "rebufferingGoal":2,
      "bufferingGoal":10,
      "bufferBehind":30,
      "ignoreTextStreamFailures":false,
      "alwaysStreamText":false,
      "startAtSegmentBoundary":false,
      "smallGapLimit":0.5,
      "jumpLargeGaps":false,
      "durationBackoff":1,
      "forceTransmuxTS":false
   },
   "abr":{
      "enabled":true,
      "defaultBandwidthEstimate":500000,
      "switchInterval":8,
      "bandwidthUpgradeTarget":0.85,
      "bandwidthDowngradeTarget":0.95,
      "restrictions":{
         "minWidth":0,
         "maxWidth":null,
         "minHeight":0,
         "maxHeight":null,
         "minPixels":0,
         "maxPixels":null,
         "minBandwidth":0,
         "maxBandwidth":null
      }
   },
   "preferredAudioLanguage":"",
   "preferredTextLanguage":"",
   "preferredVariantRole":"",
   "preferredTextRole":"",
   "preferredAudioChannelCount":2,
   "restrictions":{
      "minWidth":0,
      "maxWidth":null,
      "minHeight":0,
      "maxHeight":null,
      "minPixels":0,
      "maxPixels":null,
      "minBandwidth":0,
      "maxBandwidth":null
   },
   "playRangeStart":0,
   "playRangeEnd":null
}

What did you do?

I started a live video from our application, and began watching the video with a Shaka 3.2 player (demo app works too). I then ended the live video from our application and continued to observe the player.

What did you expect to happen?
For the player to detect that the manifest has converted over to STATIC and to be able to tell me how much time we had left in the video. Then once it reached the end, to go into the paused state.

What actually happened?

The player went in to an infinite buffering state as soon as I ended the live video, and could only be resolved by refreshing the page.

This can be replicated in our own Player AND the Shaka Player demo app.

[joeyparrish]

Is this working in any earlier version of Shaka Player? You can easily browse them with https://index-dot-shaka-player-demo.appspot.com/

[defnull]

I can confirm this. There is an ended event which should be triggered as soon as the player reaches the end of a static manifest.

In v2.5.23 this works as expected, even if a manifest changes from type="dynamic" to type="static" while playing. As soon as the player picks up the static manifest, it switches from live to vod mode and triggers ended once the end is reached. We rely on this to quickly show a 'stream offline' image after a stream ends.

In v3.0.0, v3.1.2 and v3.2.0 this event is not triggered and the streams keeps buffering. I can see that the player downloads the static manifest and then stops updating it, so there is some internal state change. But the player never triggers ended or paused and keeps buffering without actually requesting any more data.

[DavidRNogueiraResi]

@joeyparrish Yes, this issue does not exist with 3.1.2. The player handles the transition well for me.

[DavidRNogueiraResi]

I can confirm this. There is an ended event which should be triggered as soon as the player reaches the end of a static manifest.

In v2.5.23 this works as expected, even if a manifest changes from type="dynamic" to type="static" while playing. As soon as the player picks up the static manifest, it switches from live to vod mode and triggers ended once the end is reached. We rely on this to quickly show a 'stream offline' image after a stream ends.

In v3.0.0, v3.1.2 and v3.2.0 this event is not triggered and the streams keeps buffering. I can see that the player downloads the static manifest and then stops updating it, so there is some internal state change. But the player never triggers ended or paused and keeps buffering without actually requesting any more data.

We have not ran into this issue with 3.1.2. Could you maybe provide an example?

[defnull]

The following script creates a simple 30 second test livestream with ffmpeg and serves it via http://localhost:8000/dash.mpd with proper CORS headers, so it can be tested with the demo players.

#!/bin/bash
trap "exit" INT TERM
trap "kill 0" EXIT

mkdir -p data
cd data
rm init-*.m4s chunk-*.m4s dash.mpd *.m3u8

python3 <<'EOF' &
#!/usr/bin/env python3
from http.server import HTTPServer, SimpleHTTPRequestHandler, test

class CORSRequestHandler(SimpleHTTPRequestHandler):
    def end_headers(self):
        self.send_header('Access-Control-Allow-Origin', '*')
        super().end_headers()

test(CORSRequestHandler, HTTPServer, bind='127.0.0.1', port=8000)
EOF

ffmpeg -hide_banner \
  -f lavfi -re -i testsrc=duration=30:size=1280x720:rate=30 \
  -c:v libx264 -x264opts keyint=60:min-keyint=60:no-scenecut -r 30 -g 60 -pix_fmt:v yuv420p -preset:v veryfast \
  -f dash -use_template 1 -use_timeline 1 -seg_duration 2 -frag_duration 2 -window_size 5 -extra_window_size 5 -hls_playlist 1 dash.mpd
sleep 30

Start it, wait 4-5 seconds (until dash.mpd is created), then try to reload and play the stream with the demo player.

https://v3-2-0-dot-shaka-player-demo.appspot.com/demo/#asset=http://localhost:8000/dash.mpd;panel=CUSTOM%20CONTENT;build=debug_compiled
https://v3-1-2-dot-shaka-player-demo.appspot.com/demo/#asset=http://localhost:8000/dash.mpd;panel=CUSTOM%20CONTENT;build=debug_compiled
https://v3-0-13-dot-shaka-player-demo.appspot.com/demo/#asset=http://localhost:8000/dash.mpd;panel=CUSTOM%20CONTENT;build=debug_compiled

All three behave more or less the same: Video plays and stays at -00:03 or -00:06 the whole time (which is odd, but that's a different issue). Around 23 seconds into the video, the mode switches from live to vod, but the total length of the video is now an absurd high number (displays as 00:00:06 / 1193046:28:16). 25 or 27 seconds into the video, the player starts buffering but does not try to download any more content. This never stops. The player is totally lost at this point, stuck in buffering state forever.

https://v2-5-23-dot-shaka-player-demo.appspot.com/demo/#asset=http://localhost:8000/dash.mpd;panel=CUSTOM%20CONTENT;build=debug_compiled

This version also displays -00:03 (instead of live, which is annoying but all versions do that) but otherwise works as expected. The video plays until about 23 seconds in, then switches from live to vod mode. It correctly displays 00:22 / 00:30 and continues until the end, then stops and shows 00:30 / 00:30. ffmpeg starts counting from zero, so the last frame shows a 29. This is correct.

Hope that helps.

[joeyparrish]

Wonderful! Thank you for the detailed steps.

[DavidRNogueiraResi]

I would like to add that I tested this in every version from 3.0.14 to 3.0.5 and it seems to me that 3.0.13 is the one that introduced this issue. This PR seems suspicious.

#3497