Regarding the "minimumUpdatePeriod" parameter in the live stream, what is the processing mechanism of dash.js?

[zxyyyyyy512]

1. At the beginning, we set the parameters in the live streaming manifest as follows:
   minimumUpdatePeriod = "PT2.000S"
   t="191604481575" d="4000" r="5"
   Such parameter settings lead to a very slow playing start of the live stream, and it takes about 10 seconds to play the first frame of the video.
   We analyzed the reason for the slow playing start and found that the first fragment was downloaded after downloading 5 manifest files in a row, which caused the slow playing start of the live stream.
2. Then we modify the parameter "minimumUpdatePeriod" and fragment duration "d":
   minimumUpdatePeriod = "PT5.000S"
   t="191604481575" d="10000" r="5"
   In this case, I found that the start-up was very fast, it only took 2-3s. Also I observed that the first fragment downloaded immediately after downloading only one manifest file.

Could you tell me what is the reason for this behavior? What mechanism causes the first fragment to be downloaded after downloading 5 manifest files continuously in the first case? Thanks.

dash.js version : dash.js 4.6.0
manifest :

<?xml version='1.0' encoding='UTF-8'?>
<MPD xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" minimumUpdatePeriod="PT2.000S" profiles="urn:mpeg:dash:profile:isoff-live:2011,http://dashif.org/guidelines/dash-if-simple" minBufferTime="PT4.000S" availabilityStartTime="2017-02-22T16:00:00Z" publishTime="2023-03-21T07:28:43Z" xmlns="urn:mpeg:dash:schema:mpd:2011" xsi:schemaLocation="urn:mpeg:dash:schema:mpd:2011 http://standards.iso.org/ittf/PubliclyAvailableStandards/MPEG-DASH_schema_files/DASH-MPD.xsd" type="dynamic" timeShiftBufferDepth="PT24.000S">
  <Period start="PT0S" id="0">
    <AdaptationSet maxFrameRate="25" segmentAlignment="true" id="1" maxWidth="1920" maxHeight="1080">
      <SegmentTemplate timescale="1000" initialization="init-$RepresentationID$.mp4?JITPDRMType=2WYywfPOTiETZ6gzmgSLCw%3D%3D&amp;startNumber=47901125&amp;virtualDomain=001.live_hls.zte.com&amp;m4s_min=1&amp;filedura=4&amp;stbid=SmartTVTestInPC&amp;NeedJITP=1&amp;ztecid=ch00000090990000001012&amp;ispcode=2&amp;terminalflag=16&amp;JITPMediaType=DASH&amp;IASHttpSessionId=OTT000020230321152823546107&amp;AuthInfo=fZgzPe1euLZIbH4mhcFLxOxZR94Ocv6lTziqNpR7zyVfRiGTDJiVw2g5I91LQ%2BOD&amp;usersessionid=ZwXkmWJTCt9IiuQbQTyreiM134000151&amp;userid=33&amp;isjitp=0" media="fragment-$Time$-$RepresentationID$.m4s?JITPDRMType=2WYywfPOTiETZ6gzmgSLCw%3D%3D&amp;startNumber=47901125&amp;virtualDomain=001.live_hls.zte.com&amp;m4s_min=1&amp;filedura=4&amp;stbid=SmartTVTestInPC&amp;NeedJITP=1&amp;ztecid=ch00000090990000001012&amp;ispcode=2&amp;terminalflag=16&amp;JITPMediaType=DASH&amp;IASHttpSessionId=OTT000020230321152823546107&amp;AuthInfo=fZgzPe1euLZIbH4mhcFLxOxZR94Ocv6lTziqNpR7zyVfRiGTDJiVw2g5I91LQ%2BOD&amp;usersessionid=ZwXkmWJTCt9IiuQbQTyreiM134000151&amp;userid=33&amp;isjitp=0" startNumber="47901125">
        <SegmentTimeline>
          <S t="191604499746" d="4000" r="5" />
        </SegmentTimeline>
      </SegmentTemplate>
      <Representation frameRate="25" sar="1:1" id="v1-x3" startWithSAP="1" bandwidth="3742468" codecs="avc1.640028" mimeType="video/mp4" height="1080" width="1920" />
    </AdaptationSet>
    <AdaptationSet segmentAlignment="true" lang="en" label="English" id="2">
      <AudioChannelConfiguration schemeIdUri="urn:mpeg:dash:23003:3:audio_channel_configuration:2011" value="2" />
      <SegmentTemplate timescale="1000" initialization="init-$RepresentationID$.mp4?JITPDRMType=2WYywfPOTiETZ6gzmgSLCw%3D%3D&amp;startNumber=47901125&amp;virtualDomain=001.live_hls.zte.com&amp;m4s_min=1&amp;filedura=4&amp;stbid=SmartTVTestInPC&amp;NeedJITP=1&amp;ztecid=ch00000090990000001012&amp;ispcode=2&amp;terminalflag=16&amp;JITPMediaType=DASH&amp;IASHttpSessionId=OTT000020230321152823546107&amp;AuthInfo=fZgzPe1euLZIbH4mhcFLxOxZR94Ocv6lTziqNpR7zyVfRiGTDJiVw2g5I91LQ%2BOD&amp;usersessionid=ZwXkmWJTCt9IiuQbQTyreiM134000151&amp;userid=33&amp;isjitp=0" media="fragment-$Time$-$RepresentationID$.m4s?JITPDRMType=2WYywfPOTiETZ6gzmgSLCw%3D%3D&amp;startNumber=47901125&amp;virtualDomain=001.live_hls.zte.com&amp;m4s_min=1&amp;filedura=4&amp;stbid=SmartTVTestInPC&amp;NeedJITP=1&amp;ztecid=ch00000090990000001012&amp;ispcode=2&amp;terminalflag=16&amp;JITPMediaType=DASH&amp;IASHttpSessionId=OTT000020230321152823546107&amp;AuthInfo=fZgzPe1euLZIbH4mhcFLxOxZR94Ocv6lTziqNpR7zyVfRiGTDJiVw2g5I91LQ%2BOD&amp;usersessionid=ZwXkmWJTCt9IiuQbQTyreiM134000151&amp;userid=33&amp;isjitp=0" startNumber="47901125">
        <SegmentTimeline>
          <S t="191604499746" d="4000" r="5" />
        </SegmentTimeline>
      </SegmentTemplate>
      <Representation id="a1-x3" codecs="mp4a.40.2" startWithSAP="1" mimeType="audio/mp4" bandwidth="317375" audioSamplingRate="48000" />
    </AdaptationSet>
  </Period>
</MPD>

[dsilhavy]

This is probably related to what is in the MPD and what is defined as live delay. dash.js will look for the right segment to be fetched at start. If your live delay is small and there is no corresponding segment in the MPD then dash.js will refresh the MPD until a suitable segment for the initial start time is found.

In your second MPD the initial live delay is probably higher than in 1).

If there is no live delay specified by the app and no suggestedPresentationDelay or ServiceDescription.Latency in the MPD then we use 4*segmentDuration

[zxyyyyyy512]

Thank you for your reply.
As you can see above in the MPD, there is no "suggestedPresentationDelay" or "ServiceDescription.Latency" in the MPD, and I have not set the "liveDelayFragmentCount" or "liveDelay" parameters of dash.js, so it can be determined that the live delay uses the default 4*segmentDuration.
You mentioned that dash.js will look for the right segment to be fetched at start. My question is how to understand "right segment"? In the first case, segmentDuration=4s, r=5, so one MPD describes a total duration of 4*5=20s, and the live delay is only 4*segmentDuration = 16s, so I think the first MPD should contain the first fragment, why does it keep downloading other MPDs?
In addition, I just changed the value of "minimumUpdatePeriod" and fragment duration "d" in the same live stream, why does it change the live Delay?
Thank you very much.

[dsilhavy]

Your MPD should contain the right segments to start playback unless the signaled segments have availabilityStartTimes that lie in the future. Can't really tell without looking at the player and a hosted version of the MPD.

I assume the live delay is changed because d is increased. Therefore the segment duration is increased. Also note that

• 60 seconds of segments signaled: d="10000" r="5"
• 24 seconds of segments signaled: d="4000" r="5" : Corresponds to your timeShiftBufferDepth

Do you have a hosted version of the content? (MPD and segments)

[zxyyyyyy512]

Thank you for your support, sorry I don't have a hosted version at the moment.
But I have a new discovery that may be related to this problem:
I found that the "dvrInfo.range" acquired by dash.js is inconsistent with the duration described in the first downloaded MPD,
For example the MPD is:

<S t="191779041639" d="4000" r="5" />

Represents a time frame of 191779041639 - 191779065639
But "dvrInfo.range" is

{"start":191779046.353,"end":191779070.353}

It can be found that the start time of "dvrInfo.range" is 5 seconds longer than the start time described in MPD, and the value is not fixed every time it is played, but what is certain is that the value of "dvrInfo.range.start" is relatively large every time.
In fact, the first "right segment" of the live stream is calculated based on "dvrInfo.range.end - livedelay", so I guess this problem may be related to the "dvrInfo.range" obtained by dash.js, so I want to know where "dvrInfo.range" comes from? Why is the obtained time inconsistent with the time in MPD?
Could you please help me out?
Thanks.

[dsilhavy]

You can find more details about timing calculations in DASH and consequently also dash.js here: https://dashif-documents.azurewebsites.net/Guidelines-TimingModel/master/Guidelines-TimingModel.html#timing-timeshift . Basically:

The time shift buffer extends from now - MPD@timeShiftBufferDepth to now.