Segment numbers off by factor 2 for live stream with presentationTimeOffset

[TobbeEdgeware]

Have you read the FAQ and checked for duplicate open issues?:

• Yes

What version of Shaka Player are you using?:

• Latest from master

Can you reproduce the issue with our latest release version?:

• Yes

Can you reproduce the issue with the latest code from master?:

• Yes

Are you using the demo app or your own custom app?:

• Demo app

If custom app, can you reproduce the issue using our demo app?:

• NA

What browser and OS are you using?:

• Chrome on Mac OS/Linux

What are the manifest and license server URIs?:

A non-working stream is:

• https://vm2.dashif.org/livesim/periods_1/testpic_2s/Manifest.mpd

The exact same segments, but with a period that starts at availabilityStartTime works:

• https://vm2.dashif.org/livesim/testpic_2s/Manifest.mpd

What did you do?
I tried to play the content in the demo player

What did you expect to happen?
The content should play and the time should be synchronised with wall-clock as for the working stream

What actually happened?
The player requested segment numbers which were twice as big as they should be.
The server responded with 404 and the player showed error message

Some more background
The asset plays without problem in dash.js.

The use case we are after is "start over" of a live channel, where the URL is defining a "start time". The segments should be the same as for the linear channel which has availabilityStartTime="1970-01-01", but the availabilityStartTime/Period@start of the "start over" asset is defined by the "start time".

On the manifest level (for SegmentTemplate with $Number$) this translates to

• availabilityStartTime = "start time"
• Period@start = "PT0S"
• startNumber = "start time" / duration
• presentationTimeOffset = "start time" (this must match the media time inside the first segment in the media. These have a time relative to 1970)

The example URL is one option to the DASH-IF dash-live-source simulator. The periods_1 part of the URL tells the simulator to start 1 new period every hour. Except at the hour boundary, the manifest has properties like the table above except that availabilityStartTime ="1970-01-01", and period@start = "latest hour", but since it is the sum of availabilityStartTime and Period@start that is used as reference, the erroneous behaviour is exactly the same as for our non-public URL.

Looking at the code, it is correctly stated that the presentationTime should start from zero at the start of a period. However, this is the default value, and if the time in the media does not start from zero, the presentationTimeOffset must be taken into account it that gives the offset of the time in the media at the start of the period. This does not seem to be the case.

This is a bit related to issue #237.

[sandersaares]

Duplicate of #1232 I believe

[TobbeEdgeware]

Hi @sandersaares, seems that you're correct about #1232 referring to the same issue. At least, I'm contributing with a new asset and some more arguments that there is indeed a bug in the code.

[TheModMaker]

Closing as duplicate of #1232.