how should interpret MPD@timeShiftBufferDepth

[zgzong]

In ISO/IEC 23009-1, MPD@timeShiftBufferDepth specifies the duration of the smallest time shifting buffer for any Representation in the MPD that is guaranteed to be available for a Media Presentation with type 'dynamic'.

From the latest Guidelines-TimingModel "The time shift buffer is a time span on the MPD timeline that defines the set of media segments that a client is allowed to present at the current moment in time according to the wall clock (now)."

How should we interpret this MPD attribute "timeShiftBufferDepth", especially when the stream is start over stream?

[RufaelDev]

Hi @zgzong DVB-DASH has some more details on this in https://dvb.org/wp-content/uploads/2022/07/A168r6_MPEG-DASH-Profile-for-Transport-of-ISO-BMFF-Based-DVB-Services_Interim-Draft-ts_103-285-v141_October_2022.pdf basically when the stream is just starting the timeShiftBufferDepth is preferably kept constant, in this case the presentable segments are depending on what is signalled in the segment timeline (the minimum of the presentable segments in SegmentTimeline versus TimeShiftBufferDepth). We have seen that changing the TimeShiftBufferDepth often causes issues on players. I am trying to convince DASH_IF IOP to also consider this approach from DVB.

[zgzong]

@RufaelDev the DVB doc has clear description for this attribute. Client Player could use this as seekable range.

At moment, some encoder provider use MPD@timeShiftBufferDepth to indicate that server rolling buffer duration; how far the media segment can shift back to. This seems conflict with ISO/IEC 23009-1 the duration of the smallest time shifting buffer for any representation.

Could any author of the DASH-IF IOP to clarify this attribute, please?

[amtins]

Yes, it would be interesting to have a clarification on this property. We had a case today which leads me to believe that it's a packaging issue:

<MPD ... type="dynamic"
  publishTime="2023-07-14T08:33:51Z"
  minimumUpdatePeriod="PT0S" 
  timeShiftBufferDepth="PT1H58M57S"
  availabilityStartTime="2023-07-14T07:26:23Z" 
  minBufferTime="PT3S">

  ...

  <SegmentTemplate 
    timescale="10000000" 
    presentationTimeOffset="1745547806874556"
    media="..."
    initialization="...">
    <SegmentTimeline>
      <S t="1745547807681778" d="20000000" r="2023" />
    </SegmentTimeline>
  </SegmentTemplate>

The problem is that the specification doesn't allow me to position myself clearly. Should the fix be made on the packaging side or on the player side? Which would potentially have an impact on the following PR https://github.com/videojs/videojs-contrib-dash/pull/382

To draw a parallel with dash.js, as a developer I'd expect the getDVRWindowSize function to return a correct value. But I could also say that I expect timeShiftBufferDepth to return the current value and not the expected value, especially when there's a big difference between the two.

[RufaelDev]

So the DVR window should be the min of timeShiftBufferDepth and the duration of the segment timeline. When using segmentTemplate and @duration you can derive the start and end of the representation from endNumber and eptDelta (however this is often not used).

The problem is that many legacy players will not take a changing timeShiftBufferDepth, so updating the packager to support this will result in backward compatiblity issues. So I would say this would be a solution at the player side, as in my pointer this is deployed in DVB the player soution is explained and I expect this will also go in the next version DASH-IF IOP as it is an important practical interop consideration.

I am happy to hear if there are other considerations.