Fix url anchor time

[bbert]

This PR is fixing anchor time management in case of multiple periods
Anchor time shall be relative to 1st period but currently anchor time is computed as being relative to targeted (from anchor time) period start time

[bbert]

Before going ahead we need to agree on specs and use cases.
For static streams:

• #t : time shall be relative to 0 (or 1st period start? Can we have a 1st period that does not start from 0?)

For dynamic streams:

• #t : time relative to DVR window start ?
• #t=posix : UTC time

[dsilhavy]

My thoughts + relevant part of the MPEG spec:

• t: signifies the time since the beginning of the period indicated by the period parameter. If period parameter is not present, the default Period is the first period of the presentation.

• In my opinion a static MPD can have a period@start greater than 0 which is then offset by the presentationTimeOffset.

• For dynamic streams I would expect the same behavior, #t relative to period@start (using the period with the earliest start time). We should make sure that the target time is included in the DVR window. On the other hand, this requires the application to know the current first period in the MPD. Might make more sense to use the AST instead of the first period if no period id is given?

[bbert]

My thoughts + relevant part of the MPEG spec:

• t: signifies the time since the beginning of the period indicated by the period parameter. If period parameter is not present, the default Period is the first period of the presentation.
• In my opinion a static MPD can have a period@start greater than 0 which is then offset by the presentationTimeOffset.

OK, but while thinking to use cases, that would be more relevant to consider #t as the absolute time from 0.
For example, one use case is for playback replay/resume of a content you previously watched. Thus the application could store the reached position, in order to restart playback from this position.

• For dynamic streams I would expect the same behavior, #t relative to period@start (using the period with the earliest start time). We should make sure that the target time is included in the DVR window. On the other hand, this requires the application to know the current first period in the MPD. Might make more sense to use the AST instead of the first period if no period id is given?

But you don't know more about AST than period start time at application level.
#t should be relative to period@start

[dsilhavy]

My thoughts + relevant part of the MPEG spec:

• t: signifies the time since the beginning of the period indicated by the period parameter. If period parameter is not present, the default Period is the first period of the presentation.
• In my opinion a static MPD can have a period@start greater than 0 which is then offset by the presentationTimeOffset.

OK, but while thinking to use cases, that would be more relevant to consider #t as the absolute time from 0.
For example, one use case is for playback replay/resume of a content you previously watched. Thus the application could store the reached position, in order to restart playback from this position.

But this should also be possible if Period@start is greater than zero. I simply save the current playback position and add that as an offset to the start. If we use Period@start as an anchor this also covers the case in which period@start is 0.

• For dynamic streams I would expect the same behavior, #t relative to period@start (using the period with the earliest start time). We should make sure that the target time is included in the DVR window. On the other hand, this requires the application to know the current first period in the MPD. Might make more sense to use the AST instead of the first period if no period id is given?

But you don't know more about AST than period start time at application level.
#t should be relative to period@start

Not sure I agree on this. The AST does not change, but periods disappear over time. There might even be outdated periods in the MPD. Or a period is removed by the time the application is initializing the player. However, the spec clearly states that the first/earliest period should be used if no period attribute is specified in the MPD anchor:

Period: Value of a Period parameter Period@id. If period parameter is not present, the default value of the @id attribute value of the Period with the earliest PeriodStart.

So I think we should stick to the behavior you described.