Enable seamless period cutting with simple addressing (SegmentTemplate@duration)

[sandersaares]

This is a topic we discussed at F2F19 but I see we have no GitHub issue for it, so I write it down here.

We have a problem: the simple addressing mode (SegmentTemplate@duration) does not allow you to offset the start of segment 1 from PeriodStart. Therefore, if you cut a period in half within a segment, the timing logic of DASH will cause a timing offset.

Assume we have this:

Now I want to make a new period at t=19s into this sequence, like this:

If this were explicit addressing, I could just have the 2nd <S> element be present in the timeline of both period 1 and period 2 – the appropriate clipping would occur and everything would be fine.

But simple addressing does not let me do this. What are the tools I have available?

• SegmentTemplate with $time$ or $number$
• SegmentTemplate@startNumber
• SegmentTemplate@presentationTimeOffset
• SegmentTemplate@duration

Notably, what is lacking from this toolkit is the equivalent of S@t in explicit addressing – I cannot state that the first segment (the duplicate) actually starts 9 seconds before the period.

That is, with SegmentTemplate@duration, the first segment always starts at the perion start time. PTO just says what sample timestamp to expect at this point but there is no mechanism to offset the segment itself.

So if I just consider the overlapping segment to be included in the 2nd period, a client will have to assume it starts with the 2nd period and as a result all data in period 2 is offset by 90% of a segment (plus whatever “native” offset already existed inside the segment).

At present, this makes using simple addressing impractical with period cutting.

Proposed solution

Ask MPEG to define a way to define the EPT of the first segment when using simple addressing. This allows a portion of the first segment to be offset from period start.

What would this look like?

• SegmentTemplate@earliestPresentationTime is the new attribute
• Used only in combination with ST@duration
• The 50% inaccuracy is still allowed even if EPT is signaled

The last point is perhaps most interesting. One might think that if you’re signaling it you might as well signal it accurately but this is not so. In the addressing usecase, this is needed for aligning the segment nominal durations with PeriodStart. The packager logic that does this is not guaranteed to have access to accurate sample times (e.g. during period splitting – all it has is the MPD, so it cannot add accuracy where there was none before).

How does this affect backward compatibility? Well, there might be some migration pain but it's not like seamless period cutting really works right now anyway, so it cannot get much worse.

[irajs]

In the case of segment timeline doesn't S@t need to be negative in this case? if so, since @t is unsignedLong @earliestPresentationTime is also needed for segment timeline.

[sandersaares]

I guess my description above was a bit misleadingly concise. I try to clarify.

S elements use the sample timeline, so they are not 0-aligned with the period start. The zero point is always in the past (either at the start of the segment or even further).

PresentationTimeOffset indicates the alignment with the sample timeline and the MPD timeline, allowing the period start to be aligned with a specific point within a segment.

[irajs]

Yup, you are right. I take it back. S@t is in sample time.

[sandersaares]

I recall a proposal to MPEG was made. What came of it? @haudiobe @irajs are you up to date and can you share?

[sandersaares]

@eptDelta is now in DASH 4th edition. There is some very quick and dirty statement in the timing model chapter about it but we need to improve this text to more clearly outline the situation.

[sandersaares]

Here's my reading on @eptDelta:

• We expect the value to be negative in typical cases. In case of the example in the OP, it would be -9 seconds to indicate that the first segment starts 9 seconds in advance of the period.
• The value may be positive if the start of the period timeline is expired (beyond time shift buffer).
• Clients that have no knowledge of @eptDelta would experience difficulties in playback because they'll have unexpected deviation. That's fine because that is the status quo - nothing gets worse by implementing @eptDelta support in either service or client.
• @eptDelta does not affect the DASH concept of "MPD start time"! Hrm, that's... nice because it does not change $time but needs careful attention in timing model text.

Seems straighforward enough. I will integrate into the timing model text.

Hmm, the problem is only solved in partial scope of course. If we allow the simple addressing inaccuracy into the picture, there still remain period cutting problems because we cannot do anything to ensure that the segment that "should" contain the period start/end point really does. DASH clients will often expect that to be the case. But this is not avoidable, I think, so what we have here is likely the best achievable.

We need test vectors for this. @waqarz do we have any? I was unable to find any by searching for eptDelta in the test vector database but maybe I don't know how to search there properly. What do we need to get some test vectors made?

[sandersaares]

Hmm, the relationship with $time$ has additional implications that surprise me.

The definition of "MPD start time" in DASH does not account for @eptDelta as far as I can tell. Accordingly, $time$ does not actually account for the "real" start of the segment but actually to the "MPD start time" which is inaccurate.

This means that when making segments using $time$, you need to name them not according to their contents but according to how they are represented in the MPD, as the name depends on the offset into the segments that the period starts from (PTO) and not the actual start of the segment (PTO + eptDelta).

This means that if you want to change the period start by a noninteger amount of segments (e.g. move period start point up by 3.5 segments) you have to rename all the segments.

@haudiobe do I understand this right?

[sandersaares]

This feature is now integrated into timing model, so closing this issue.