MPD Anchor should be relative to the start of the first period

[aj-r]

Specifying #t=0 for live clips has no effect - it starts playing them at the live edge instead of from the beginning. It seems that dash.js is treating t as epoch time. However, according to ISO/IEC 23009-1:2014(E) section C.4, t is:

Time since the beginning of the period indicated by the period parameter.
If period parameter is not present, the default value is the ID of the Period with the earliest PeriodStart.

Essentially, t should be relative to the start of the first period, NOT relative to January 1, 1970.

Background / use case

I need to be able to play back DASH contents in a VOD type of use case. The catch is that I need to be able to play these contents while the segments are still being written, and update the player as segments are added. To accomplish this, I set MPD@type="dynamic" while segments are being written, and then change to MPD@type="static" once all segments have been written. By default, dashjs tries to load the live edge of the content, but I want to start from the beginning. Hence I tried adding #t=0 to the MPD URL, but this did not work because dashjs treats #t as epoch time, instead of relative to the period start time.

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:
  • http://irtdashreference-i.akamaihd.net/dash/live/901161/bfs/manifestARD.mpd
• Dash.js version: 2.6.4
• Browser name/version: Chrome 62.0.3202.94 (64-bit)
• OS name/version: Windows 8.1

Steps to reproduce

1. Add #t=0 to the end of an MPD URL for a dynamic/live MPD. Make that MPD@timeShiftBufferDepth is sufficiently large (e.g. P100Y).
2. Load the MPD

Unfortunately I can't provide you with my own MPD file because it's on a private network. I've linked to one of DASH-IF's sample files above, but any live sample can reproduce the issue. If timeShiftBufferDepth is too small, then #t=0 may not work, but you can still reproduce the issue by setting t to a larger number of seconds such that it is in range of timeShiftBufferDepth.

Observed behaviour

Player starts at the live edge. Expected it to start at the beginning (or whatever value was specified for t).

Console output

[16719] Playback Initialized 
17:08:43.861 Debug.js:127 [16756] Parsing complete: ( xml2json: 3.17ms, objectiron: 0.500ms, total: 0.00367s) 
17:08:43.865 Debug.js:127 [16760] Matching default timing source protocol to manifest protocol:  http://time.akamai.com/?iso 
17:08:43.867 Debug.js:127 [16762] Manifest has been refreshed at Thu Dec 07 2017 17:08:43 GMT-0500 (Eastern Standard Time)[1512684523.861]  
17:08:43.900 Debug.js:127 [16795] Local time:      Thu Dec 07 2017 17:08:43 GMT-0500 (Eastern Standard Time) 
17:08:43.900 Debug.js:127 [16795] Server time:     Thu Dec 07 2017 17:08:43 GMT-0500 (Eastern Standard Time) 
17:08:43.901 Debug.js:127 [16796] Difference (ms): -900 
17:08:43.904 Debug.js:127 [16799] MediaSource attached to element.  Waiting on open... 
17:08:43.908 Debug.js:127 [16803] MediaSource is open! 
17:08:43.908 Debug.js:127 [16803] Duration successfully set to: 9007199254740991 
17:08:43.910 Debug.js:127 [16805] Added 0 inline events 
17:08:43.911 Debug.js:127 [16806] video codec: video/mp4;codecs="avc1.4D401F" 
17:08:43.924 Debug.js:127 [16819] audio codec: audio/mp4;codecs="mp4a.40.5" 
17:08:43.927 Debug.js:127 [16822] No text data. 
17:08:43.927 Debug.js:127 [16822] No fragmentedText data. 
17:08:43.927 Debug.js:127 [16822] No embeddedText data. 
17:08:43.928 Debug.js:127 [16823] No muxed data. 
17:08:43.929 Debug.js:127 [16824] Getting the request for video time : 1512684513.011 
17:08:43.930 Debug.js:127 [16825] Index for video time 1512684513.011 is 755586669 
17:08:43.931 Debug.js:127 [16826] Schedule controller starting for video 
17:08:43.931 Debug.js:127 [16826] Getting the request for audio time : 1512684512.786 
17:08:43.931 Debug.js:127 [16826] Index for audio time 1512684512.786 is 738615484 
17:08:43.931 Debug.js:127 [16826] Schedule controller starting for audio 
17:08:43.932 Debug.js:127 [16827] Start Event Controller 
17:08:43.932 Debug.js:127 [16827] Native video element event: play 
17:08:43.933 Debug.js:127 [16828] Refresh manifest in 10 seconds. 
17:08:43.937 Debug.js:127 [16831] ScheduleController video- getNextFragment 
17:08:43.937 Debug.js:127 [16832] ScheduleController video- switch track has been asked, get init request for video with representationid = 1_1 
17:08:43.939 Debug.js:127 [16834] ScheduleController audio- getNextFragment 
17:08:43.939 Debug.js:127 [16834] ScheduleController audio- switch track has been asked, get init request for audio with representationid = 2_1 
17:08:43.969 Debug.js:127 [16864] Init fragment finished loading saving to video's init cache 
17:08:43.973 Debug.js:127 [16868] Top quality video index has changed from undefined to 0 
17:08:43.975 Debug.js:127 [16870] AbrController (video) stay on 0/0 (buffer: 0) 
17:08:43.975 Debug.js:127 [16870] ScheduleController video- getNextFragment 
17:08:43.976 Debug.js:127 [16871] Getting the request for video time : 1512684511.338 
17:08:43.976 Debug.js:127 [16871] Index for video time 1512684511.338 is 755586668 
17:08:43.976 Debug.js:127 [16871] SegmentTemplate: 1512684509.336 / Infinity 
17:08:43.976 Debug.js:127 [16871] ScheduleController video- getNextFragment - request is http://<private server>/proxy/DASH_2/track1_video_755586669.m4s 
17:08:43.977 Debug.js:127 [16872] Init fragment finished loading saving to audio's init cache 
17:08:43.979 Debug.js:127 [16873] Native video element event: loadedmetadata 
17:08:43.980 Debug.js:127 [16875] Top quality audio index has changed from undefined to 0 
17:08:43.980 Debug.js:127 [16875] AbrController (audio) stay on 0/0 (buffer: 0) 
17:08:43.980 Debug.js:127 [16875] ScheduleController audio- getNextFragment 
17:08:43.980 Debug.js:127 [16875] Getting the request for audio time : 1512684511.232 
17:08:43.981 Debug.js:127 [16875] Index for audio time 1512684511.232 is 738615483 
17:08:43.981 Debug.js:127 [16876] SegmentTemplate: 1512684509.184 / Infinity 
17:08:43.982 Debug.js:127 [16877] ScheduleController audio- getNextFragment - request is http://<private server>/proxy/DASH_2/track2_audio_738615484.m4s 
17:08:47.062 main.js:235 download : undefined
(anonymous) @ main.js:235
(anonymous) @ EventBus.js:88
trigger @ EventBus.js:88
downloadError @ ErrorHandler.js:63
onloadend @ XHRLoader.js:126
XMLHttpRequest.send (async)
internalLoad @ XHRLoader.js:231
(anonymous) @ XHRLoader.js:122
setTimeout (async)
onloadend @ XHRLoader.js:121
XMLHttpRequest.send (async)
internalLoad @ XHRLoader.js:231
(anonymous) @ XHRLoader.js:122
setTimeout (async)
onloadend @ XHRLoader.js:121
XMLHttpRequest.send (async)
internalLoad @ XHRLoader.js:231
(anonymous) @ XHRLoader.js:122
setTimeout (async)
onloadend @ XHRLoader.js:121
XMLHttpRequest.send (async)
internalLoad @ XHRLoader.js:231
load @ XHRLoader.js:266
load @ FragmentLoader.js:98
loadCurrentFragment @ FragmentModel.js:190
executeRequest @ FragmentModel.js:178
getNextFragment @ ScheduleController.js:212
schedule @ ScheduleController.js:227
setTimeout (async)
startScheduleTimer @ ScheduleController.js:262
onBytesAppended @ ScheduleController.js:422
(anonymous) @ EventBus.js:88
trigger @ EventBus.js:88
onAppended @ BufferController.js:228
(anonymous) @ EventBus.js:88
trigger @ EventBus.js:88
(anonymous) @ SourceBufferController.js:307
updateEndHandler @ SourceBufferController.js:383
17:08:47.063 Debug.js:127 [19958] No audio bytes to push or stream is inactive. 
17:08:47.065 Debug.js:127 [19961] ScheduleController audio- getNextFragment 
17:08:47.066 Debug.js:127 [19961] Getting the request for audio time : 1512684510.208 
17:08:47.066 Debug.js:127 [19962] Index for audio time 1512684510.208 is 738615483 
17:08:47.067 Debug.js:127 [19962] [ScheduleController][video] Request http://<private server>/proxy/DASH_2/track1_video_755586669.m4s has been aborted 
17:08:47.067 Debug.js:127 [19963] Schedule controller stopping for video 
17:08:47.068 Debug.js:127 [19963] Schedule controller stopping for audio 
17:08:47.068 Debug.js:127 [19964] getNextFragment audio- Playing at the bleeding live edge and frag is not available yet 
17:08:47.569 Debug.js:127 [20464] ScheduleController audio- schedule stop! 

[epiclabsDASH]

There was a discussion regarding this in #2232 and #1361.

@dsparacio, do you remind why t parameter was decided to be used as an absolute time?

Thanks

[aj-r]

@epiclabsDASH @dsparacio any update as to why #t is in absolute time?

I think it would make sense to have #t in relative time (relative to the beginning of the clip) and #s in absolute time. That way, the people who need absolute time can still use #s.

Alternatively, if you really don't want to use relative time (e.g. to avoid breaking things for people who are already using #t in live mode), you could add a new URL parameter (#r?), or even a new optional parameter to mediaPlayer.initialize() and mediaPlayer.attachSource() that lets you specify a relative start time. e.g. mediaPlayer.initialize(view, source, autoPlay, startTime).

[aj-r]

I've also noticed that I can never start at the very beginning of a live clip - at best, I can start 1 second into the clip, then seek back to the beginning after the player loads. For example, if the availabilityStartTime is 2018-01-04T21:46:46Z, and I use #t=1515102407, the player fails to load. But if I use #t=1515102408, the player will load 1 second into the clip, and I need to manually seek backward one second to get to the beginning.

Should we create a separate issue for this?

[epiclabsDASH]

@aj-r, sorry for the late response. Let me bring this topic to today coordination call. I prefer to don't change the meaning of #t parameter (there are users that presumably are using it as it is defined today) but are totally open to changes. I will get back to you as soon as possible regarding this.

I've also noticed that I can never start at the very beginning of a live clip
Regarding this, yes, please, create a separate issue for tracking this issue.

Many thanks!

[mmarciel]

@aj-r, we added a PR (#2403) that adds parameter 'r' to be a relative time. Could you take a look and tell us if it works for you?

Thanks

[aj-r]

Great! I won't be able to look at it today, but maybe Tuesday or Wednesday.

[aj-r]

Works great :)