1136050 - dash.js MSE live playback not working - fails to seek to live edge?

Status: RESOLVED INVALID

(Core :: Audio/Video: Playback, defect)

Description

[u514836]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.115 Safari/537.36

Steps to reproduce:

Using Nightly 39.0a1 (2015-02-23)

1. Navigate to http://dashif.org/reference/players/javascript/1.3.0/samples/dash-if-reference-player/index.html?mpd=http://vm2.dashif.org/livesim/testpic_2s/Manifest.mpd


Actual results:

No media is played.


Expected results:

Video and audio should be seeked to live edge (by the application) and played - colour bars with burnt-in timecode.

The video plays correctly in the current versions of Chrome (v40) and IE11.

Alternative stream for test: http://dash.bidi.int.bbc.co.uk/e/pseudolive/bbb/client_manifest.mpd (available internationally, delivered on a best efforts basis).

Comment 1

[Chris Peterson [:cpeterson]]

Jean-Yves, this dash.js stream plays correctly in IE11 and MS Edge, but does not play for me in Nightly 42 or Chrome 44.

The player endlessly logs about time 0:

Index for time 0 is -1 Debug.js:76:17
Getting the request for time: 0 Debug.js:76:17
Index for time 0 is -1 Debug.js:76:17
Getting the request for time: 0 Debug.js:76:17
Index for time 0 is -1 Debug.js:76:17
...

Comment 2

[Jean-Yves Avenard [:jya]]

timestamp of audio added starts at -97952876798462

As per spec; if an audio sample isn't within sourcebuffer Append Window ([appendWindowStart, appendWindowEnd) the sample is to be ignored)
http://w3c.github.io/media-source/index.html#append-window
"A presentation timestamp range used to filter out coded frames while appending. The append window represents a single continuous time range with a single start time and end time. Coded frames with presentation timestamp within this range are allowed to be appended to the SourceBuffer while coded frames outside this range are filtered out."

A way around this would be to use the sourcebuffer timestampOffset attribute. Here it is not modified and as such set to the default of 0

Comment 3

[Jean-Yves Avenard [:jya]]

I should add:
the video timestamp starts at 4529034778145.

So even if audio timestamp weren't positive ; if audio isn't within 125ms of video start time playback would stall regardless.

125ms is a leeway that we allow in timestamp discrepancy, there's nothing in the spec allowing such difference.

(we used 125ms to do the same as chrome), but there handling of timestamps is completely out of spec.