Closed Bug 1136050 Opened 8 years ago Closed 7 years ago

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

Categories

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

defect
Not set
normal

Tracking

()

RESOLVED INVALID
Tracking Status
firefox41 --- affected
firefox42 --- affected

People

(Reporter: u514836, Assigned: jya)

References

Details

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).
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
...
Status: UNCONFIRMED → NEW
Component: Audio/Video → Audio/Video: Playback
Ever confirmed: true
Flags: needinfo?(jyavenard)
OS: Windows 7 → All
Hardware: x86_64 → All
Summary: MSE live playback not working - fails to seek to live edge? → dash.js MSE live playback not working - fails to seek to live edge?
Assignee: nobody → jyavenard
Flags: needinfo?(jyavenard)
Flags: needinfo?(jyavenard)
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
Status: NEW → RESOLVED
Closed: 7 years ago
Flags: needinfo?(jyavenard)
Resolution: --- → INVALID
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.
You need to log in before you can comment on or make changes to this bug.