Dash.js: play stalled and download the same fragment repeatedly

[genie88]

• [x] The MPD passes the DASH-IF Conformance Tool on https://conformance.dashif.org/
• [x] The stream has correct Access-Control-Allow-Origin headers (CORS)
• [x] There are no network errors such as 404s in the browser console when trying to play the stream
• [x] The issue observed is not mentioned on https://github.com/Dash-Industry-Forum/dash.js/wiki/FAQ
• [x] The issue occurs in the latest reference client on http://reference.dashif.org/dash.js/ and not just on my page
• Link to playable MPD file:https://testmpd.titan.mgtv.com/test0/DRM/video_mp4/7773A679FCACADB48188F8F8D3A76721.mpd
• Dash.js version: 3.0.0
• Browser name/version: Chrome 73.0.3683.86
• OS name/version: macOS Mojave 10.14.1 (18B75)

Steps to reproduce

1. press load button and it begin plays.
2. play is stalled at some point (31s or 1 min 06s)

Observed behaviour

playing is stalled and downloaded same fragment repeatedly

Console output

[8612189][PlaybackController] Requesting seek to time: 0.023219 
Debug.js:236 [8612217][PlaybackController] Native video element event: seeked 
Debug.js:236 [8612218][PlaybackController] Native video element event: playing 
Debug.js:236 [8612541][ScheduleController][video] OnFragmentLoadingCompleted - Url: https://testmpd.titan.mgtv.com/test0/DRM/video_mp4/AF868A99E3312D6C31EF0880292A6F46_10000_20000_1018_v02_mpd.m4s , Range: undefined 
Debug.js:236 [8612549][AbrController] AbrController (video) switching from throughput to buffer occupancy ABR rule (buffer: 28.293). 
Debug.js:236 [8612887][ScheduleController][video] OnFragmentLoadingCompleted - Url: https://testmpd.titan.mgtv.com/test0/DRM/video_mp4/C4A32AC3D4F0EC406273CF47A89B05B3_20000_30000_1018_v02_mpd.m4s , Range: undefined 
Debug.js:236 [8612955][ScheduleController][audio] OnFragmentLoadingCompleted - Url: https://testmpd.titan.mgtv.com/test0/DRM/video_mp4/60425BBAEFAAD78516D091878D2CAECE_10000_20000_128_v02_mpd.m4s , Range: undefined 
Debug.js:236 [8612957][AbrController] AbrController (audio) switching from throughput to buffer occupancy ABR rule (buffer: 21.645). 
Debug.js:236 [8613225][ScheduleController][audio] OnFragmentLoadingCompleted - Url: https://testmpd.titan.mgtv.com/test0/DRM/video_mp4/69F61825293A0F19D019E4975F18DC6C_20000_30000_128_v02_mpd.m4s , Range: undefined 
Debug.js:236 [8613594][ScheduleController][audio] OnFragmentLoadingCompleted - Url: https://testmpd.titan.mgtv.com/test0/DRM/video_mp4/0CE9B6051FCD283F5A574073B88BBB39_30000_40000_128_v02_mpd.m4s , Range: undefined 
Debug.js:236 [8623429][ScheduleController][video] OnFragmentLoadingCompleted - Url: https://testmpd.titan.mgtv.com/test0/DRM/video_mp4/DF4CAD1279540771AE50630130BB780D_30000_40000_1018_v02_mpd.m4s , Range: undefined 
Debug.js:236 [8624090][ScheduleController][audio] OnFragmentLoadingCompleted - Url: https://testmpd.titan.mgtv.com/test0/DRM/video_mp4/3041C112B130BFF54D77D6641949E8F1_40000_50000_128_v02_mpd.m4s , Range: undefined 
Debug.js:236 [8634226][ScheduleController][video] OnFragmentLoadingCompleted - Url: https://testmpd.titan.mgtv.com/test0/DRM/video_mp4/FD2E2ABB6E5AFE0B2643177834225638_40000_50000_1018_v02_mpd.m4s , Range: undefined 
Debug.js:236 [8635025][ScheduleController][audio] OnFragmentLoadingCompleted - Url: https://testmpd.titan.mgtv.com/test0/DRM/video_mp4/6740DF1D9A65666139F924B900FDE5DD_60000_70000_128_v02_mpd.m4s , Range: undefined 
Debug.js:236 [8635277][ScheduleController][audio] OnFragmentLoadingCompleted - Url: https://testmpd.titan.mgtv.com/test0/DRM/video_mp4/910489CBCE4605D73106EECF23BF008E_70000_80000_128_v02_mpd.m4s , Range: undefined 
Debug.js:236 [8635527][ScheduleController][audio] OnFragmentLoadingCompleted - Url: https://testmpd.titan.mgtv.com/test0/DRM/video_mp4/910489CBCE4605D73106EECF23BF008E_70000_80000_128_v02_mpd.m4s , Range: undefined 
Debug.js:236 [8635784][ScheduleController][audio] OnFragmentLoadingCompleted - Url: https://testmpd.titan.mgtv.com/test0/DRM/video_mp4/910489CBCE4605D73106EECF23BF008E_70000_80000_128_v02_mpd.m4s , Range: undefined 
Debug.js:236 [8636035][ScheduleController][audio] OnFragmentLoadingCompleted - Url: https://testmpd.titan.mgtv.com/test0/DRM/video_mp4/910489CBCE4605D73106EECF23BF008E_70000_80000_128_v02_mpd.m4s , Range: undefined 
Debug.js:236 [8636302][ScheduleController][audio] OnFragmentLoadingCompleted - Url: https://testmpd.titan.mgtv.com/test0/DRM/video_mp4/910489CBCE4605D73106EECF23BF008E_70000_80000_128_v02_mpd.m4s , Range: undefined 
Debug.js:236 [8636505][ScheduleController][audio] OnFragmentLoadingCompleted - Url: https://testmpd.titan.mgtv.com/test0/DRM/video_mp4/910489CBCE4605D73106EECF23BF008E_70000_80000_128_v02_mpd.m4s , Range: undefined 
Debug.js:236 [8636723][ScheduleController][audio] OnFragmentLoadingCompleted - Url: https://testmpd.titan.mgtv.com/test0/DRM/video_mp4/910489CBCE4605D73106EECF23BF008E_70000_80000_128_v02_mpd.m4s , Range: undefined 

[mcassagnes]

Have you found a solution? I am sometimes running into this issue as well.

[nicosang]

Hi @genie88 ,

it seems that your stream does not fulfil conformance tool successfully. I don't know if this is the origin of the issue but it's better to solve this point.

Nico

[nicosang]

@genie88 , according to the parsing done by dash.js video segments list is defined like this :

segment 0 : start 0 - end 10.48
segment 1 : start 10.48 - end 20.96
segment 2 : start 20.96 - end 31.44

the first weird point is that after the segment 0 has been pushed, the video buffer is equal to 0 - 14.44....not 0 - 10.48

Nico

[enzious]

I'm experiencing this same issue. It seems to occur most often on Firefox, might be my imagination.

Here is something else I'm seeing:

[758468][NextFragmentRequestRule] Prior to making a request for time, NextFragmentRequestRule is aligning index handler's currentTime with bufferedRange.end for audio . 378.0207029478458 was changed to 366.991224

Maybe this is to do with how I'm converting it. Does this look okay for creating the mpd?

let mut cmd = Command::new("ffmpeg");
// in
cmd.args(&["-i", &path])
    // video
    .args(&[
        "-c:v",
        "libx264",
        "-x264opts",
        "keyint=30:min-keyint=30:scenecut=-1",
        "-pix_fmt",
        "yuv420p",
        "-profile:v",
        "baseline",
        "-level",
        "3",
    ])
    // audio
    .args(&["-c:a", "aac", "-b:a", "192k", "-ar", "44100", "-ac", "2"])
    // out
    .args(&[
        "-f",
        "dash",
        "-use_template",
        "1",
        "-use_timeline",
        "1",
        "-seg_duration",
        "10",
        "-init_seg_name",
        "$RepresentationID$-init.m4s",
        "-media_seg_name",
        "$RepresentationID$-$Number$.m4s",
        &format!("{}/index.mpd", &outdir),
    ]);
cmd.stderr(Stdio::piped());

[enzious]

[enzious]

Issue does not occur at the same segment. It's arbitrary. Making me believe that it is not the MPD/segments.

When I start seeing two Buffered Ranges the issue starts:

[enzious]

I think that it's caused by this line:
https://github.com/Dash-Industry-Forum/dash.js/blob/development/src/streaming/rules/scheduling/NextFragmentRequestRule.js#L76

If you have ranges like this... (I don't know how these are generated but it happened to me)
|RangeA(FragB.end)|( >0.1s gap )|RangeA+1(FragB+1.start)|

...it will delete Range2 indefinitely due to this strange gap.

The limit in the gap is set here:
https://github.com/Dash-Industry-Forum/dash.js/blob/development/src/streaming/SourceBufferSink.js#L39

And the function that finds this gap and triggers the delete is here:
https://github.com/Dash-Industry-Forum/dash.js/blob/development/src/streaming/SourceBufferSink.js#L148

I've changed the MAX_ALLOWED_DISCONTINUITY variable to .99s and I'll see if that helps for me:
https://github.com/enzious/dash.js/commit/4773a1eee28c44502566ebef4976330c280a1d4f

I don't have a lot of experience here. Thoughts?

[enzious]

So far the issue has gone away. Used to happen every time I watched a long video, no longer occurring.

[adamtal3]

@epiclabsDASH - Why was this closed considering @enzious was only able to fix the issue by creating a fork and changing the value of MAX_ALLOWED_DISCONTINUITY to 990 msecs?

I'm experiencing the same issue (#3113).