Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarify timestamp handling in dynamic->static transition #56

Open
sandersaares opened this issue Jul 16, 2020 · 3 comments
Open

Clarify timestamp handling in dynamic->static transition #56

sandersaares opened this issue Jul 16, 2020 · 3 comments

Comments

@sandersaares
Copy link
Member

sandersaares commented Jul 16, 2020

See shaka-project/shaka-player#2581

A dynamic MPD may be anchored at Unix epoch. At some point it is transformed to a static MPD - but this is anchored at the start of the actual content, not at the start of the MPD timeline in the dynamic MPD.

What is the right way for the player to know where the playhead now lies in the static MPD?

Alternative phrasing: what does the dynamic MPD timeline position equivalent to "now" on the wall clock map to in the static MPD?

@sandersaares
Copy link
Member Author

sandersaares commented Jul 16, 2020

First thoughts:

  1. MPDs must contain a period overlapping "now" (DASH-IF 1).
  2. Content within time shift buffer (in fact slightly beyond, considering availability, as well) is not permitted to be removed by MPD updates, therefore the period containing "now" must also exist in static MPD (DASH-IF 2).
  3. Period IDs must remain consistent after MPD updates, so the player can identify this period by ID (DASH 5.4.1).
  4. Even though the MPD timeline may transform during dynamic->static transition (as AvailabilityTimeStart is removed from calculations), the sample timeline remains consistent (i.e. the contents of segments do not change).
  5. The MPD must accurately reflect the actual sample timeline used in the segments (DASH-IF 3).
  6. Therefore, the player can calculate the equivalent MPD timeline position in the same period by working backwards from the sample timeline.

@TobbeEdgeware
Copy link

The following "startover URL" from DASH-IF live simulator should have the right behaviour, and be compatible with the text above:

https://livesim.dashif.org/livesim/startrel_-20/stoprel_20/timeoffset_0/testpic_2s/Manifest.mpd

It will redirect to a URL with absolute time interval corresponding to the live time interval [now - 20s, now + 20s], and the MPD will become static approximately 20s after the initial call. At the transition the segments will stay the same, but AST will go away.

@stevemayhew
Copy link

First thoughts:
@sandersaares I'm working this issue with a couple of different origin vendors as well as our own origin in order to properly support SoCu.

  1. MPDs must contain a period overlapping "now" (DASH-IF 1).
  2. Content within time shift buffer (in fact slightly beyond, considering availability, as well) is not permitted to be removed by MPD updates, therefore the period containing "now" must also exist in static MPD (DASH-IF 2).
  3. Period IDs must remain consistent after MPD updates, so the player can identify this period by ID (DASH 5.4.1).

Are you proposing the former live period would convert to fixed duration with non change to the Period@startTime (as required by the MPD Updates section?

  1. The MPD must accurately reflect the actual sample timeline used in the segments (DASH-IF 3).
  2. Therefore, the player can calculate the equivalent MPD timeline position in the same period by working backwards from the sample timeline.

So this would require changing the Period@startTime to 0 potentially and updating the presentationTimeOffset in order to have the position be equivalent?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants