Correct usage of Resync elements?

[wilaw]

The dynamic manifest snippet below shows the use of resync elements. Are these applied correctly and are they adding value?

<?xml version="1.0" encoding="utf-8"?>
<MPD xmlns="urn:mpeg:dash:schema:mpd:2011" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:mpeg:DASH:schema:MPD:2011 DASH-MPD.xsd" type="dynamic" profiles="urn:mpeg:dash:profile:isoff-live:2011" minBufferTime="PT4S" minimumUpdatePeriod="PT8M20S" availabilityStartTime="2022-01-10T06:39:27Z" suggestedPresentationDelay="PT4S" timeShiftBufferDepth="PT10S" publishTime="2022-01-18T03:53:45Z">
  <UTCTiming schemeIdUri="urn:mpeg:dash:utc:http-xsdate:2014" value="https://live-orisa-edge.play.kakao.com/time?iso&amp;ms"></UTCTiming>
  <ServiceDescription id="0">
    <Latency target="4000"></Latency>
  </ServiceDescription>
  <Period id="0" start="PT0.0S">
    <AdaptationSet id="0" contentType="video" segmentAlignment="true" bitstreamSwitching="true">
      <Role schemeIdUri="urn:mpeg:dash:role:2011" value="main"/>
      <Resync dT="400000" type="0"></Resync>
      <Representation id="video_2" mimeType="video/mp4" codecs="avc1.4d401e" bandwidth="500000" width="640" height="360">
        <ProducerReferenceTime id="video_2" type="encoder" wallclockTime="2022-01-18T02:57:27.474Z" presentationTime="677880000000">
          <UTCTiming schemeIdUri="urn:mpeg:dash:utc:http-xsdate:2014" value="https://live-orisa-edge.play.kakao.com/time?iso&amp;ms"></UTCTiming>
        </ProducerReferenceTime>
        <Resync dT="2000000" type="1"></Resync>
        <SegmentTemplate timescale="1000000" presentationTimeOffset="0" duration="2000000" initialization="video_2/104231_init.m4s" media="video_2/104231_$Number%06d$.m4s" startNumber="0" availabilityTimeOffset="1.6"></SegmentTemplate>
      </Representation>
      <Representation id="video_5" mimeType="video/mp4" codecs="avc1.4d401f" bandwidth="2000000" width="1280" height="720">
        <ProducerReferenceTime id="video_5" type="encoder" wallclockTime="2022-01-18T02:57:27.474Z" presentationTime="677880000000">
          <UTCTiming schemeIdUri="urn:mpeg:dash:utc:http-xsdate:2014" value="https://live-orisa-edge.play.kakao.com/time?iso&amp;ms"></UTCTiming>
        </ProducerReferenceTime>
        <Resync dT="2000000" type="1"></Resync>
        <SegmentTemplate timescale="1000000" presentationTimeOffset="0" duration="2000000" initialization="video_5/104231_init.m4s" media="video_5/104231_$Number%06d$.m4s" startNumber="0" availabilityTimeOffset="1.6"></SegmentTemplate>
      </Representation>
      <Representation id="video_9" mimeType="video/mp4" codecs="avc1.4d402a" bandwidth="7980000" width="1920" height="1080">
        <ProducerReferenceTime id="video_9" type="encoder" wallclockTime="2022-01-18T02:57:27.474Z" presentationTime="677880016000">
          <UTCTiming schemeIdUri="urn:mpeg:dash:utc:http-xsdate:2014" value="https://live-orisa-edge.play.kakao.com/time?iso&amp;ms"></UTCTiming>
        </ProducerReferenceTime>
        <Resync dT="2000000" type="1"></Resync>
        <SegmentTemplate timescale="1000000" presentationTimeOffset="0" duration="2000000" initialization="video_9/104231_init.m4s" media="video_9/104231_$Number%06d$.m4s" startNumber="0" availabilityTimeOffset="1.6"></SegmentTemplate>
      </Representation>
    </AdaptationSet>

[wilaw]

At the DASH IF Q&A today, Thomas answered:

Yes. The first entry <Resync dT="400000" type="0"></Resync> is applied at the adaptation set level. Conceptually, you can think of this as saying "anything applied at the adaptation set level can be applied to every representation within that adaptation". Therefore the resync element adopts the timebase of the representations, which is 1000000. So this resync entry is telling the player that "chunks" exist in the segments with a maximum duration of 400ms.

We also notice that a second resync entry <Resync dT="2000000" type="1"></Resync> is set manually at each representation. This entry is complementary to the first. It is saying that every 2s there exists an IDR within the segment that can be used for stream access. While technically correct, this is redundant information, as the segments are only 2s in duration, and the DASH packaging requirements require that each segment start with a SAP or rtype 1 or 2. If however, the segments were 4s or 6s in duration, then this would be useful information, as it would tell the player that there are intermediate access points available within each segment, which could be used for fast join or fast switch.