startNumber in dynamic manifests using SegmentTemplate

[Feenposhleen]

We use two different providers for live DASH playback, and they have chosen different strategies for segment templating. One has the template format index-$Number$-IDENTIFIER.mp4 where the identifier is unique for the encoder session and ensures no future segments share URI with a previous one. The other provider uses index-$Number$.mp4, but relies on the startNumber property in the SegmentTemplate as an identifier to make sure URIs are unique.

The second strategy is no longer working in Shaka. It seems like the startNumber is being ignored. Just to illustrate (pseudo):

var mpd1 = {
    availabilityStartTime: SIX_HUNDRED_SECONDS_AGO,
    segmentDuration: SIX_SECONDS,
    segmentTemplateStartNumber: 1,
    segmentTemplate: 'index-$Number$-IDENTIFIER.mp4'
};

// Expected and actual current segment: index-100-IDENTIFIER.mp4

var mpd2 = {
    availabilityStartTime: SIX_HUNDRED_SECONDS_AGO,
    segmentDuration: SIX_SECONDS,
    segmentTemplateStartNumber: 200,
    segmentTemplate: 'index-$Number$.mp4'
};

// Expected current segment: index-300.mp4
// Actual: index-100.mp4

Is this format unsupported or is this a bug? I can provide the actual manifests over a private channel if needed.

[joeyparrish]

Please do send me the manifests privately. If the content can also be made available, that is often helpful for debugging.

The names of the encoder vendors would also be helpful. There are many parts of the DASH spec in need of clarification, and some vendors have mutually incompatible interpretations of certain things.

[joeyparrish]

We believe that using startNumber as an offset in the way described above is not in keeping with the intent of the spec.

The first segment in a Period is segment number 1. The segment number is used to fill in $Number$ in templates.

The startNumber attribute tells us the number of the first segment in the manifest. For example, look at live streams with SegmentList. The list does not necessarily show all segments that have been broadcast, so startNumber lets you know what is there:

<!-- Just started broadcasting -->
<SegmentList startNumber=1 duration=10>
  <SegmentURL>001.mp4</SegmentURL><!-- calculated start time 0 -->
  <SegmentURL>002.mp4</SegmentURL><!-- calculated start time 10 -->
  <SegmentURL>003.mp4</SegmentURL><!-- calculated start time 20 -->
</SegmentList>

<!-- A little later -->
<SegmentList startNumber=5 duration=10>
  <SegmentURL>005.mp4</SegmentURL><!-- calculated start time 40 -->
  <SegmentURL>006.mp4</SegmentURL><!-- calculated start time 50 -->
  <SegmentURL>007.mp4</SegmentURL><!-- calculated start time 60 -->
</SegmentList>

The only way startNumber is consistent across live SegmentList, SegmentTemplate+SegmentTimeline, and SegmentTemplate+duration is if these are the equivalents for the two above examples:

<!-- Just started broadcasting -->
<SegmentTemplate startNumber=1 media="$Number%03d$.mp4">
  <SegmentTimeline>
    <S t=0 d=10 /><!-- start time 0, calculated URL 001.mp4 -->
    <S d=10 /><!-- start time 10, calculated URL 002.mp4 -->
    <S d=10 /><!-- start time 20, calculated URL 003.mp4 -->
  </SegmentTimeline>
</SegmentTemplate>

<!-- A little later -->
<SegmentTemplate startNumber=5 media="$Number%03d$.mp4">
  <SegmentTimeline>
    <S t=40 d=10 /><!-- start time 40, calculated URL 005.mp4 -->
    <S d=10 /><!-- start time 50, calculated URL 006.mp4 -->
    <S d=10 /><!-- start time 60, calculated URL 007.mp4 -->
  </SegmentTimeline>
</SegmentTemplate>

And for duration:

<!-- All segment information is known, no matter when we started broadcasting -->
<SegmentTemplate duration=10 media="$Number%03d$.mp4" />
<!-- Segment 1, calculated URL 001.mp4, calculated start time 0 -->
<!-- Segment 2, calculated URL 002.mp4, calculated start time 10 -->
<!-- Segment 3, calculated URL 003.mp4, calculated start time 20 -->
<!-- Segment 4, calculated URL 004.mp4, calculated start time 30 -->
<!-- Segment 5, calculated URL 005.mp4, calculated start time 40 -->
<!-- Segment 6, calculated URL 006.mp4, calculated start time 50 -->
<!-- Segment 7, calculated URL 007.mp4, calculated start time 60 -->

If startNumber influences $Number$ for SegmentTemplate+duration, we end up with different URLs for the same segments as described by the above SegmentTimeline and SegmentList. So in order for startNumber to be consistent in all three cases, startNumber can't have any impact on the URLs for SegmentTemplate+duration.

This is just one area in the DASH spec where the language needs to be clarified and concrete examples need to be given. As it stands, there is enough ambiguity and confusion that not all implementations are compatible with regard to startNumber. We believe the interpretation above is the only one that makes the spec self-consistent.

[tobbee]

Hi guys,

I don't think the DASH spec is underspecified, but it is quite complex. It seems to me, that there is indeed an issue in with dynamic MPDs and startNumber in shaka-player.

I've been working a lot with how to do live streaming correctly in DASH, and made the the DASH-IF live simulator that can be used as a reference (for MPDs using SegmentTemplate with $Number$ this far.
A bit reason I started working on it was that it was really hard to get live streaming including timing correct for DASH. There is some info about it at https://github.com/Dash-Industry-Forum/dash-live-source-simulator/wiki.

In particular, it is possible to choose the startNumber in the MPD and the two MPDs
http://vm2.dashif.org/livesim/snr_0/testpic_2s/Manifest.mpd
http://vm2.dashif.org/livesim/snr_100000/testpic_2s/Manifest.mpd
differ only in startNumber.

Both have availabilityStartTime 1970-01-01-00:00:00, but the first one has startNumber 0 and the second 100000. The media segments are generated depending on the path to the MPD and their timing and content is shifted appropriately to make the content be the same at the same live instance independent of the startNumber. Thus, if you use two parallel players running the two different MPDs the playout should be in sync, irrespective of the value of the startNumber.

That is also the case if you play them with the dash.js reference player: http://dashif.org/reference/players/javascript/v1.5.1/samples/dash-if-reference-player/index.html
but I don't see this behavior in the latest version of shaka-player. (I haven't back-tracked to see if if was the case before).

Some more details:

For MPDs with type dynamic, it is important to look at the combo "availabilityStartTime + period@start" (AST + PST) and "startNumber" and the current time.

startNumber refers to the segment that is available one segmentDuration after the period start (at the period start, only the init segments are available),

For dynamic MPDs, you shall "never" start to play with startNumber, but the latest available segment is LSN = floor( (now - (availabilityStartTime+PST))/segmentDuration + startNumber- 1).

It is also important to align the mediaTimeLine (based on baseMediaDecodeTime) so that it starts at 0 at the beginning of the period.

In any case, you're not allowed to change the availabilityStartTime at any point, so a later manifest can only have additional periods (and old one removed), or updates to the SegmentTimeline.

DASH-IF has had a lot of discussions on these topics so there are more complete descriptions and applications in their interoperability guide lines.The latest is V3.1 with improved live available at http://dashif.org/guidelines/

I hope that the MPD URLs provided above can help in testing the timing behavior of the dhaka-player. If you want to have other test-cases implemented in live-simulator, please add an issue to the Github project.

[joeyparrish]

@tobbee Thanks for the information. I stand corrected.

Can you clarify a few points for us? Some things are still unclear to me.

If startNumber refers to the segment that is available one segmentDuration after the period start (at the period start, only the init segments are available), does that mean that the live SegmentList examples I gave are not spec-compliant? We've seen dynamic manifests like this, in which SegmentList shows the most recent handful of segments, and uses startNumber to indicate the number of the first segment in the list, rather than the first segment in the Period.

What about the SegmentTimeline examples above? Is it valid for SegmentTimeline to update in a dynamic manifest? Is it valid for startNumber to indicate the number of the first segment in the timeline, rather than the first segment in the Period?

[TobbeMobiTV]

@joeyparrish
I wrote specifically about the SegmenteTemplate which is the alternative I've been working with in depth for years and for which I really have good test sources. In this case, the available segments correspond to a sliding time-shift window of time range [max(AST, now-timeShiftBufferDepth), now] (a bit sloppy). Right at start, it is shorter, but one timeShiftBufferDepth after AST, it reaches its full duration.

I have not worked with explicit SegmentLists, but it clearly says in the standard that startNumber (optional) refers to the first segment in the period. Thus, it cannot be changed until there is a new period. On the other hand, in this case it is easy to have an explicit list of segments, and that list can be changed with an update of the MPD (keeping AST and Period start unchanged) to give a time-shift window.

I've recently started to implement some test streams for live SegmentTimeLine with $Time$ template. In this case, there is a list of templates corresponding to the timeShift window. Often, the minimumUpdatePeriod=0 which means that the player should ask for a new MPD file for each segment. The new MPD will then typically have the oldest segment dropped and the newest added.
In DASH-IF, the discussions have concluded that we should not mix $Number$ template with SegmentTimeLine, but keep to $Time$ template. I'll post the URL once it becomes available (next week, probably).

I don't have the full context of the original content discussed by @Feenposhleen, but it seems that the AST was updated with the MPD which is not allowed. Inserting a new period with a new startNumber is allowed though, and I have links that do that like;
http://vm2.dashif.org/livesim/periods_20/testpic_2s/Manifest.mpd
(a new period every 3 minutes and a miniumumUpdatePeriod=90s).
In this case you need to keep as many periods as your time-shift-buffer says.

I think DASH is to generous in its options about combining MPD segment schemes. One of the goals of DASH-IF is to reduce the used alternatives, which is especially important for live (dynamic MPDs).
In any case, your general principle that the URLs to specific segments should not be changed after MPD updates should always hold true.

[joeyparrish]

Okay, so for now, we will change SegmentTemplate w/ duration to treat startNumber specially compared to SegmentList and SegmentTimeline.

[joeyparrish]

@tobbee @Feenposhleen Please take a look and reopen if you have any further issues. The fix will be in release v1.6.2.

[priyajeet]

@joeyparrish Will this change also impact #232

[joeyparrish]

@priyajeet, this most recent fix supercedes earlier changes such as that for 232. If you have find any bugs in the latest code on master, please let us know.