Live playback fails to start in Chrome Canary (v43)

[davemevans]

Since Canary updated to 43.0.2312.0 this morning I have been unable to play any live streams with dash.js 1.3. These streams still play correctly in the latest version of Chrome (40.0.2214.115).

The live edge appears to be determined successfully but playback never commences. The console output is suspicious - the following is printed out constantly:

Getting the request for time: 0
Index for time 0 is -1

I have tried the following streams:
http://dash.bidi.int.bbc.co.uk/e/pseudolive/bbb/client_manifest.mpd (available internationally, delivered on a best-efforts basis)
http://vm2.dashif.org/livesim/testpic_2s/Manifest.mpd

This shows it is not just our streams, and not to do with the UTCTiming element 😌

It appears as if the video element's currentTime is not being seeked to the live edge, stays at 0 and that leads to no segments being downloaded, but I haven't looked in too much detail. I can only assume that there is some race condition, or perhaps appending the initialisation segments no longer updates seekable.

Is anyone else seeing this, or am I missing something?

[KozhinM]

got the same issue. Turned out that in Canary v.43 videoElement.currentTime cannot be set if MediaSource.duration has been set to Infinity (we do this in live streams). If I set some non-infinite value, e.g. 9999999999, then videoElement.currentTime can be set and video plays fine.
Looks like a browser bug to me.
@kirkshoop, @AkamaiDASH, @wilaw, how do you think guys, should we report this issue to Chrome team? If so, what is an appropriate place for it?

[davemevans]

Yes - I just tried Number.MAX_VALUE and that works as a work around, but the HTML5 spec is very clear that Infinity is the correct value to use when the duration is unknown [1]. So I agree this appears to be a browser bug.

I have just tested it in Firefox Nightly and the same workaround does not appear to fix the problem. I'll raise a bug against Firefox.

[1] http://www.w3.org/TR/html5/embedded-content-0.html#dom-media-duration

[dsparacio]

@bbcrddave would you mind also filing a bug against chromium on this subject?

[davemevans]

Sure - https://code.google.com/p/chromium/issues/detail?id=461733

[KozhinM]

@bbcrddave, thanks for taking care of this! I am closing the issue.

[arpu]

same problem on stable chrome 41.0.2272.76 (64-bit)

[arpu]

how can i use the workaround Number.MAX_VALUE ?

[dsparacio]

@arpu Line 263 of DashManifestExtensions.
mpdDuration = Number.MAX_VALUE;

[arpu]

@AkamaiDASH thx this works fine as workaround but
this is a regression too, same stream works in dash 1.2.0 reference client

[dsparacio]

@arpu I think if that is the case then Number.POSITIVE_INFINITY was not used in 1.2.0 an introduce in 1.3.0 were you patched.

[arpu]

@AkamaiDASH its used in 1.2 too
https://github.com/Dash-Industry-Forum/dash.js/blob/v1.2.0/app/js/dash/DashManifestExtensions.js#L425

[dsparacio]

I am going to push the MAX_VALUE workaround into dev branch. we can not wait for chrome to fix and leave live streaming broken.

[chcunningham]

I've updated the chromium bug. https://code.google.com/p/chromium/issues/detail?id=461733#c14

TLDR: I think chromium is behaving to spec. In those comments I suggest a workaround that should allow dash.js to avoid the infinite duration hack.

If you agree with my take, I'd like to re-open this bug on dash.js. @AkamaiDASH / @KozhinM what do you think?

[KozhinM]

@chcunningham, thanks for the update. Just looked up the chromium bug. According to the latest comment (#16) currentTime can be set before appending data. Let's wait a bit before re-opening the bug till we figure it out.

[ChiouTingHung]

I git the AkamaiDASH/dash.js of dash.js-development branch, still got problem in chrome

Uncaught TypeError: Cannot read property 'startTime' of null