Does dash.js support setting a positive (or negative) eptDelta value on SegmentBase (indexed addressing)?

[gldraphael]

Would something like this work?

<SegmentBase indexRange="867-2110" timescale="15360" presentationTimeOffset="1843200" eptDelta="15360">

For some more context, section § 18.2.1 of the TimeModel guidelines states:

For representations that use indexed addressing, perform the following adjustments to set a new period start point:

• Update SegmentBase@presentationTimeOffset to indicate the desired start point on the sample timeline.
• Update Period@duration to match the new duration.

However, this does not work if SegmentBase@presentationTimeOffset causes the start time to start from a non-IDR frame (i.e. if the period has a first partial-segment).
I'm hoping setting a eptDelta on the SegmentBase will make this work. (but eptDelta does not work)

My question -- am I doing something wrong, or does dash.js not support this yet?

[dsilhavy]

This is how we use ´presentationTimeOffset` in dash.js:

SourceBuffer@timestampOffset = Period@start - @presentationTimeOffset
Position of the segment in the buffer = earliestPresentationTime + SourceBuffer@timestampOffet

We are not using @eptDelta from the manifest. It is implicitly known for SegmentTimeline as it is defined as the difference between the EPT and the @presentationTimeOffset.

A problem for MSE based players is a negative @eptDelta as it creates an overlap with the previous period. Since we use the appendWindow attribute of the SourceBuffer and align this with the period boundaries it can create gaps in the timeline. I wrote about this in more detail here: https://websites.fraunhofer.de/video-dev/mse-a-story-of-append-windows-presentation-timestamps-and-video-buffers/

From your snippet above I would expect a gap at the beginning of the period as you signal a positive @eptDelta. The player should jump over this gap though.

[gldraphael]

You're right, this is exactly what I'm seeing. dash.js (and shaka-player) drops the frames and jumps the gap over to the next frame.

Your blog post (thanks for writing it!) mentions:

MSE-based DASH clients like dash.js and Shaka player use the appendWindowStart and appendWindowEnd attributes of the SourceBuffer object to define an append range. Coded frames with presentation timestamps within this append range are allowed to be appended to the SourceBuffer, while coded frames outside this range are filtered out.

Does this mean, it should be possible (in theory at least) to change the appendWindowStart to align with the start of the segment as opposed to the start of the period but have the video play from the start of the period?

[dsilhavy]

I think there are some limitations to this:

• The buffer can only start at 0. If your period starts at 0 as well then you would shift the segment into a negative buffer which is not possible from my understanding. I haven't tested that though.
• For a multiperiod MPD the proposed behavior would prevent the player from prebuffering segments of the upcoming period. Since Segment#1 in your diagram overlaps into the previous period it would overwrite any segment at the end of Period#0

[gldraphael]

Thanks dsilhavy, if I find something I will definitely report back.

It feels like the only way to truly support partial segments that do not start with an IDR frame would be to add support to the MSE implementations. Everything else, it seems, will only be a workaround.