MPD Anchors (#t) broken in 2.6 for live streams

[davemevans]

Environment

• The MPD passes the DASH-IF Conformance Tool on http://dashif.org/conformance.html
• The stream has correct Access-Control-Allow-Origin headers (CORS)
• There are no network errors such as 404s in the browser console when trying to play the stream
• The issue observed is not mentioned on https://github.com/Dash-Industry-Forum/dash.js/wiki/FAQ
• The issue occurs in the latest reference client on http://reference.dashif.org/dash.js/ and not just on my page

• Link to playable MPD file: https://vm2.dashif.org/livesim/testpic_2s/Manifest.mpd
• Dash.js version: 2.6.x
• Browser name/version: Chrome 61
• OS name/version: Win7

Steps to reproduce

Add a #t=<seconds since start of period> anchor to end of of dynamic manifest URL and load.

I built two simple examples which include an MPD anchor set roughly two minutes behind the live edge. The 2.5.0 example works correctly and the stream starts at the anchor time. The 2.6.0 example does not work correctly, starting at the live edge.

• 2.5.0: https://codepen.io/anon/pen/BwqvYR
• 2.6.0: https://codepen.io/anon/pen/zEmyLb

Observed behaviour

Player starts at live edge rather than at time specified by anchor.

Note that static MPDs appear to play correctly (eg http://rdmedia.bbc.co.uk/dash/ondemand/testcard/1/client_manifest-events.mpd#t=30)

It looks like #2194 ought to make this work, but it's not doing the trick in this case.

[nicosang]

Hi @bbcrddave ,

it's indeed a regression. could you, please, tell me what is the number 1262304000 in PlaybackController in getStreamStartTimeOffset?

Thanks,
Nico

[davemevans]

It's Unix time for 00:00 01/01/2010. I have no idea why it's there!

(Edit: introduced in f66c904)

[epiclabsDASH]

Seems it is assuming that for live streams t and s should always contain an absolute time.

Looking at spec (http://www.w3.org/TR/media-frags/) I don't see any reference indicating that should be the right behavior. The only thing I found in the spec that could be related to this is the following:

...with the begin time defaulting to 0 seconds and the end time defaulting to the duration of the source media...

In some way it indicates t parameter should be provided as time relative to the start and end (duration) of the stream. I am excluding s parameter here because that one is not part of specification. s parameter is a proposal coming from Akamai.

(Don't want to start the conversation about the implementation of t parameter, that should be much more complex than current one. Currently it is used just for defining playback start time but it was designed to create more complex clips).

[davemevans]

See #1361 for discussion when this was implemented.

[dsparacio]

I think was magic number value was a marker in time to check UTC time validity for live streaming thinking it would not be older than X years. It can be removed...

[nicosang]

Hi @bbcrddave ,

could you, please, take a look to my PR?

Thanks,
Nico

[davemevans]

Closed via 0dd4539.