low Latency DASH with Multi-Period : Freezes at each Period Boundary

[patgendron]

Environment

• The MPD passes the DASH-IF Conformance Tool on https://conformance.dashif.org/
• The stream has correct Access-Control-Allow-Origin headers (CORS)
• There are no network errors such as 404s in the browser console when trying to play the stream
• The issue observed is not mentioned on https://github.com/Dash-Industry-Forum/dash.js/wiki/FAQ
• 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://cdn-vos-ppp-01.vos360.video/Content/DASH_DASH/Live/channel(DAITestLowLat)/master.mpd
• Dash.js version: 5.0.3
• Browser name/version: Chrome
• OS name/version: windows 11

Steps to reproduce

We have a multi-period Low latency DASH stream with the following main configurations :

• Segment duration = 1.6s

• Chunks = 100ms

• Target latency in Service Description is set to 7s ( but configuring the player not to follow this and giving a larger latency target doesn't change the behavior)

• DVR window = 20 minutes

• new period created every (around)1 minute

(other configurations can be deduced from the Live mpd URL attached)
manifest-multiperiod.mpd.xml

Observed behavior

player stalls at each period boundary.
looking at buffer level we can see that on both video and audio, the buffer is going down at each period change until it is completely empty then the buffer level goes up again (while it is quite stable during the period).

we also observe that at period boundaries, the player request several time the manifest (following the request period (1s here)) and we can see the manifest adding new segments in the timeline but these segments are not requested until the buffer is empty

Console output

filtering on ''stalling'':

[74188314][StreamProcessor][video] Buffer is empty! Stalling!
Debug.js:169 [74188314][StreamProcessor][audio] Buffer is empty! Stalling!

Expected behavior

no stalling at period boundaries

[dsilhavy]

I was not able to reproduce the issue when playing the content over 5 periods in the nightly build

I did not encounter an empty buffer at any point. However, I saw that there are some slight misalignments with the media segments from time to time, e.g.

[396206][StreamProcessor][audio] Adjusting buffering time 83835.6351227 because of gap in the manifest. Adjusting time by 0.051666700004716404

Shaka player throws a similar error, e.g.

log.js:140 Possible encoding problem detected! 

Unexpected buffered range for reference {startTime: 83904.583456, endTime: 83906.183456, trueEndTime: 83906.183456, startByte: 0, getUrisInner: ƒ, …} 
from URIs ['https://cdn-vos-ppp-01.vos360.video/Content/DASH_D…1761151684973item-07item_Segment-839045501226.m4a'] should be {start: 83904.583456, end: 83906.183456} but got {start: 83904.583455, end: 83907.719455}

Right now I assume there are gaps in the content between the periods which is why there might be no prebuffering. In addition, dash.js will need to jump over any gaps which can cause a short delay. However, this is just an assumption as I wasn't able to reproduce an empty buffer yet.

[patgendron]

I agree that Gaps may not help for sure but I do reproduce the issue using the nighly build . See the full URL I use (same as yours but with the hosted player):
https://reference.dashif.org/dash.js/nightly/samples/dash-if-reference-player/index.html?mpd=https%3A%2F%2Fcdn-vos-ppp-01.vos360.video%2FContent%2FDASH_DASH%2FLive%2Fchannel(DAITestLowLat)%2Fmaster.mpd+&debug.logLevel=5&streaming.capabilities.supportedEssentialProperties.0.schemeIdUri=urn%3Advb%3Adash%3Afontdownload%3A2014&streaming.capabilities.supportedEssentialProperties.1.schemeIdUri=urn%3Ampeg%3AmpegB%3Acicp%3AColourPrimaries&streaming.capabilities.supportedEssentialProperties.2.schemeIdUri=urn%3Ampeg%3Adash%3Aurlparam%3A2014&streaming.capabilities.supportedEssentialProperties.3.schemeIdUri=urn%3Ampeg%3Adash%3Aurlparam%3A2016&streaming.capabilities.supportedEssentialProperties.4.schemeIdUri=urn%3Ampeg%3AmpegB%3Acicp%3AMatrixCoefficients&streaming.capabilities.supportedEssentialProperties.5.schemeIdUri=urn%3Ampeg%3AmpegB%3Acicp%3ATransferCharacteristics&streaming.capabilities.supportedEssentialProperties.6.schemeIdUri=urn%3Ampeg%3Adash%3Assr%3A2023&streaming.capabilities.supportedEssentialProperties.7.schemeIdUri=http%3A%2F%2Fdashif.org%2Fthumbnail_tile&streaming.capabilities.supportedEssentialProperties.8.schemeIdUri=http%3A%2F%2Fdashif.org%2Fguidelines%2Fthumbnail_tile&streaming.delay.liveDelayFragmentCount=NaN&streaming.delay.liveDelay=NaN&streaming.buffer.initialBufferLevel=NaN&streaming.liveCatchup.maxDrift=NaN&streaming.liveCatchup.playbackRate.min=NaN&streaming.liveCatchup.playbackRate.max=NaN

[enricovittorini]

@dsilhavy I can reproduce it 100% of the time using https://reference.dashif.org/dash.js/nightly/samples/dash-if-reference-player/index.html

For Easy of view In console i set

player.on(dashjs.MediaPlayer.events.PERIOD_SWITCH_STARTED, function (event) {
    console.log('------------------------ PERIOD_SWITCH_STARTED:', event);
});

player.on(dashjs.MediaPlayer.events.PERIOD_SWITCH_COMPLETED, function (event) {
    console.log('------------------------ PERIOD_SWITCH_COMPLETED:', event);
})

they apply a filter
/period|stall/

[patgendron]

Let me give you a bit more information :
at the period boundary, I can see that the player makes several requests on the manifest (every update period (1second). The manifest adds new segments as they are available but there is no requests on these new segments until (to my understanding) the buffer is dried. Then the player requests the ini files and the media segments, ...
it looks like the player considers that after the end of the period, there is no new period until it re-initialize

.

I can also add something that may help troubleshooting on the way the segments are added in the manifest at the end of a period .

• the trigger to create a new period is mad though scte messages ( as you can see in the manifest ). This makes the last segment of a period ( and also the first of the next period) not having the nominal duration
• When we start producing the last segment of the period (and therefore announce it in the manifest before it is fully available (for LL ), we announce it in the manifest with the nominal duration.
• Then once this last segment is fully computed and available in the Origin, we update its duration in the manifest
• Then we create the new period where the first segment of this new period is described .
• ....
  Can it be the last segment duration change in the manifest that cause the player behavior ?

[enricovittorini]

Hello @dsilhavy have you been able to reproduce the issue? thanks for your feedback!

[dsilhavy]

Hello @dsilhavy have you been able to reproduce the issue? thanks for your feedback!

I haven't had the chance to check this as I need to finalize some changes for v5.1.0. I will assign this to the v5.1.1 release.

[dsilhavy]

@patgendron @enricovittorini Thanks for the additional info. Can you please do another test against the latest version (nightly branch): Link

Didn't see any stalls when doing a quick test:

I also see dash.js preloading the upcoming periods:

[enricovittorini]

@dsilhavy Did a quick test, it seems even worst now..... After the Ad-break the player stalls and does not recover at all. It is systematic...

cc: @patgendron

[dsilhavy]

@dsilhavy Did a quick test, it seems even worst now..... After the Ad-break the player stalls and does not recover at all. It is systematic...

cc: [@patgendron](https://github.com/patgendron)

Thanks for checking, this is odd. I am not able to reproduce this, as you can see from my logs in the previous post. Can you confirm that you tested with commit id 02d8e63dcf26e40091f1b3bf06cfbe6425367f7f in the ref client? Simply following my link from the previous post?

I am testing on Mac OSX Chrome Version 142.0.7444.60

[enricovittorini]

@dsilhavy
thanks for your answer.
yes, I followed your link.
I am testing on Win11 and Chrome 42.0.7444.60 (Official Build) (64-bit)

Note: I am testing another stream than the one provided by @patgendron. Let me talk with him on Monday and will update you.