Dash.js: Playback does not enter 3rd period of v8-MultiContent on Chrome and Edge

[sandersaares]

Environment

• [ ] The MPD passes the DASH-IF Conformance Tool on http://dashif.org/conformance.html
• [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://media.axprod.net/TestVectors/v8-MultiContent/Clear/Manifest.mpd
• Dash.js version: nightly
• Browser name/version: Chrome 62, Chrome Canary, Edge 40
• OS name/version: Windows 10 v1703

MPD does not validate due to https://github.com/Dash-Industry-Forum/Conformance-Software/issues/218 but I believe the presentation is valid and IOP-conforming.

Steps to reproduce

1. Start playback
2. Seek to near 12:00 minute mark to skip content of first period (ends near 12:10)
3. Wait for 1st period to end
4. Wait for 2nd period to end

Observed behaviour

At the point where playback is supposed to switch from the 2nd into the 3rd period, one of the following happens (seemingly randomly):

• The last second (approximately) of content from period 2 plays in an infinite loop.
• Playback stops.

The control bar shows this to be at around 12:43.

Console keeps looping the same log lines forever.

In Firefox 56, playback successfully enters the 3rd period.

Console output

This is from "playback stops" outcome in Chrome 56.

Debug.js:127 [200790] ThroughputRule requesting switch to index:  0 type:  audio Average throughput 11499 kbps 
Debug.js:127 [200792] AbrController (audio) stay on 0/0 (buffer: 0.512) 
Debug.js:127 [200793] ScheduleController audio- getNextFragment 
Debug.js:127 [200795] Getting the request for audio time : 765.824 
Debug.js:127 [200796] Index for audio time 765.824 is 7 
Debug.js:127 [200797] SegmentTemplate: 27.775999999999954 / 30.123 
Debug.js:127 [200799] Getting the next request at index: 55 
Debug.js:127 [200800] isMediaFinished - no segment found 
Debug.js:127 [200801] getNextFragment audio- Playing at the bleeding live edge and frag is not available yet 
Debug.js:127 [201085] Switch to index 0; buffer is empty. 
Debug.js:127 [201087] AbrController (video) stay on 0/6 (buffer: 0.389) 
Debug.js:127 [201088] ScheduleController video- getNextFragment 
Debug.js:127 [201089] Getting the request for video time : 766.08 
Debug.js:127 [201091] Index for video time 766.08 is 7 
Debug.js:127 [201092] SegmentTemplate: 28 / 30.123 
Debug.js:127 [201094] Getting the next request at index: 55 
Debug.js:127 [201095] isMediaFinished - no segment found 
Debug.js:127 [201096] getNextFragment video- Playing at the bleeding live edge and frag is not available yet 
Debug.js:127 [201303] ThroughputRule requesting switch to index:  0 type:  audio Average throughput 11499 kbps 
Debug.js:127 [201305] AbrController (audio) stay on 0/0 (buffer: 0.512) 
Debug.js:127 [201307] ScheduleController audio- getNextFragment 
Debug.js:127 [201308] Getting the request for audio time : 765.824 
Debug.js:127 [201310] Index for audio time 765.824 is 7 
Debug.js:127 [201311] SegmentTemplate: 27.775999999999954 / 30.123 
Debug.js:127 [201313] Getting the next request at index: 56 
Debug.js:127 [201314] isMediaFinished - no segment found 
Debug.js:127 [201316] getNextFragment audio- Playing at the bleeding live edge and frag is not available yet 

This is from "playback stops" outcome in Edge 40:

dash.all.debug.js (14831,13)
[115929] ScheduleController video- getNextFragment 
dash.all.debug.js (14831,13)
[115929] ScheduleController video- quality has changed, get init request 
dash.all.debug.js (14831,13)
[115984] Init fragment finished loading saving to video's init cache 
dash.all.debug.js (14831,13)
[115985] Buffered Range for type: video : 734.08  -  764.08 
dash.all.debug.js (14831,13)
[115993] AbrController (video) stay on 4/6 (buffer: 19.54) 
dash.all.debug.js (14831,13)
[115993] ScheduleController video- getNextFragment 
dash.all.debug.js (14831,13)
[115993] Getting the request for video time : 764.1944376 
dash.all.debug.js (14831,13)
[115993] Index for video time 764.1944376 is 7 
dash.all.debug.js (14831,13)
[115994] SegmentTemplate: 28 / 30.123 
dash.all.debug.js (14831,13)
[115994] Getting the next request at index: 8 
dash.all.debug.js (14831,13)
[115995] Signal complete. 
dash.all.debug.js (14831,13)
[115995] ScheduleController video- getNextFragment - request is null 
dash.all.debug.js (14831,13)
[115995] Schedule controller stopping for video 
dash.all.debug.js (14831,13)
[115995] Stream is complete 
dash.all.debug.js (14831,13)
[125557] AbrController (video) switching from buffer occupancy to throughput ABR rule (buffer: 9.971). 
dash.all.debug.js (14831,13)
[125810] AbrController (audio) switching from buffer occupancy to throughput ABR rule (buffer: 9.844). 
dash.all.debug.js (14831,13)
[132240] ThroughputRule requesting switch to index:  0 type:  audio Average throughput 842 kbps 
dash.all.debug.js (14831,13)
[132244] AbrController (audio) stay on 0/0 (buffer: 3.467) 
dash.all.debug.js (14831,13)
[132245] ScheduleController audio- getNextFragment 
dash.all.debug.js (14831,13)
[132245] Getting the request for audio time : 765.824 
dash.all.debug.js (14831,13)
[132246] Index for audio time 765.824 is 7 
dash.all.debug.js (14831,13)
[132246] SegmentTemplate: 27.775999999999953 / 30.123 
dash.all.debug.js (14831,13)
[132247] Getting the next request at index: 8 
dash.all.debug.js (14831,13)
[132247] Signal complete. 
dash.all.debug.js (14831,13)
[132248] ScheduleController audio- getNextFragment - request is null 
dash.all.debug.js (14831,13)
[132248] Schedule controller stopping for audio 
dash.all.debug.js (14831,13)
[132249] Stream is complete 
dash.all.debug.js (14831,13)

[epiclabsDASH]

Thanks for catching this one. Issue could be related with latest changes related with multiperiod management and the algorithm for detecting the end of the stream. I have tested this stream with previous versions and it neither worked although the effect is different (not looping, just next stream doesn't load).

I am going to keep the release thought for today (v2.6.3) on hold until we clarify this point. There were some last minute fixes related with multiperiod and we need to be sure there is no regression.

[nicosang]

Hi @epiclabsDASH and @sandersaares ,

i found the origin of the issue : startTime of the third period is 764.2030000000001 instead of 764.203.
I fix it and add a PR.....

Nico

[nicosang]

@sandersaares could you, please, take a look at PR #2281 ?

Thanks,
Nico

[epiclabsDASH]

It worked here, @nicosang.

Issue was there before this version and is not related with any of its changes so I will go ahead with the release scheduled for today without pushing PR #2281.

In the release notes of this version I will add a note describing this issue so anyone is aware.

[sandersaares]

The PR seems to have fixed it for me in Chrome but in Edge, I still see the issue. Actually, Edge now even fails to play from the 1st into the 2nd period for me.

[nicosang]

So, it means you have the infinite loop in Edge between 2nd and 3rd period or randomly the play between periods fails without infinite loop.

[sandersaares]

In my current tests with the code from the PR, I encountered a playback stop when entering 2nd period. If I manually seeked into 2nd period, I also encountered a playback stop when entering 3rd period. I did not notice any infinite loop playback in my today's testing.

[nicosang]

@sandersaares, according to me, this is another issue that you describe. It refers to issue #2129. Currently, in order to detect the end of a stream, onPlaybackTimeUpdated of StreamController test the time to end value. If the value is less than 0.5 second, PLAYBACK_ENDED is triggered with a little delay. It's quite dangerous because, like in your sample, the last timeUpdate event could be sent when time to end is more than 0.5 : no end of stream is detected.
I suggest you to take a look at PR #2220. The main difference is that the end detection is based on STREAM_BUFFERING_COMPLETED. I 've just added a commit to trigger this specific event only when audio and video buffers have triggered BUFFERING_COMPLETED event : no need to wait text buffer state. Could you, please, test your stream on this branch too specially the play between 1st and 2nd period? Unfortunately, the infinite loop between 2nd and 3rd period will still occur...

[sandersaares]

Could you, please, test your stream on this branch too specially the play between 1st and 2nd period?

I tried it a couple of times on #2220 and did not notice any glitches when playing into the 2nd period.

[nicosang]

good news....So, after the merge of both PR, it should be ok for multiperiod streams....I hope! :-)
There is also an issue on subtitles with your stream : the default track is not shown...I look at it.

[sandersaares]

Reposting comment from #2220 for better visibility here:

On Firefox 56, the player from PR now sometimes skips the 2nd period of https://media.axprod.net/TestVectors/v8-MultiContent/Clear/Manifest.mpd playing from the 1st straight into the 3rd period.

Does not happen 100% of the time but seems to happen most of the time. Have not noticed on other browsers.

However, there seems to be some issue actually using this video for some people, as Nicolas mentioned he cannot get it to play in Firefox due to:

Video Element Error: MEDIA_ERR_DECODE (NS_ERROR_DOM_MEDIA_FATAL_ERR (0x806e0005) - error creating audio decoder)

Note sure what that is about...

[nicosang]

FYI @sandersaares , the PR #2287 has been created to solve subtitles issues on this stream.

[nicosang]

@sandersaares
I updated my firefox browser to 57.0.1 (64 bits) version. The error message has been updated : Can't decode H.264 stream because its resolution is out of the maximum limitation
It seems that the representation 7 of first period is the origin of the issue : <Representation id="7" mimeType="video/mp4" codecs="avc1.640034" width="4860" height="2160" frameRate="24" sar="1:1" startWithSAP="1" bandwidth="4670638"></Representation>
Do you still not have this issue?

[sandersaares]

Also writing here to confirm I see that with FF 57. Created https://github.com/Dash-Industry-Forum/dash.js/issues/2323 for tracking the Firefox error.

[davemevans]

Max horizontal resolution at Level 5.2 is 4096, no? Surely that makes the video invalid and the firefox behaviour correct?

[sandersaares]

Aha, good catch! I will attempt to track why it is marked with too low a level.

[nicosang]

Hi @sandersaares,

could we close this issue?

Nico

[sandersaares]

I think so, yes. I will open a new issue if I notice any problems remaining.