Defer setting currentTIme until something is in buffer

[nickdesaulniers]

STR:

1. in FF Nightly 41 goto: http://shaka-player-demo.appspot.com/
2. load manifest: http://www.bok.net/dash/tears_of_steel/cleartext/stream.mpd

expected: playback

actual: console error: Player Error InvalidStateError

will try posting more info with a downloaded, debug build

[nickdesaulniers]

More info logged to the console from a local build of v1.3.0-debug:

EME not available. mediakeys.js:55:5
+ audio/mp4; codecs="mp4a.40.2" is supported player.js:178:3
+ video/mp4; codecs="avc1.42E01E" is supported player.js:178:3
+ audio/mp4; codecs="mp4a.40.2" is supported player.js:178:3
+ video/mp4; codecs="avc1.42E01E" is supported player.js:178:3
Initial seek range Array [ 0, 61.318 ] dash_video_source.js:159:1
Starting each stream from 0 stream_video_source.js:1112:3
 stream_video_source.js:863:1

Player error error { target: null, isTrusted: false, detail: InvalidStateError, eventPhase: 0, bubbles: true, cancelable: false, defaultPrevented: false, timeStamp: 1434139288126345, NONE: 0, CAPTURING_PHASE: 1, AT_TARGET: 2 } app.js:892:3

[nickdesaulniers]

The call stack looks like:
app.onPlayerError_ app.js:892
shaka.util.FakeEventTarget.prototype.recursiveDispatch_ fake_event_target.js:145
shaka.util.FakeEventTarget.prototype.dispatchEvent fake_event_target.js:123
shaka.player.Player.prototype.load player.js:313

setting a breakpoint at app.onPlayerError_ app.js:892, stepping up the call stack to shaka.player.Player.prototype.load player.js:313:

error.message is "An attempt was made to use an object that is not, or is no longer, usable"
error.filename is "http://localhost:8002/lib/player/stream_video_source.js"
error.lineNumber is 1113

lib/player/stream_video_source.js:1113 is this.video.currentTime = streamStartTime;.

setting a break point there, streamStartTime is 0 and this.video.currentTime is also 0, and triggers the exception in Firefox.

This is equivalent to document.createElement('video').currentTime = 0 in Firefox (also triggers an invalid state error).

[joeyparrish]

Interesting. Thanks for investigating, Nick!

I'm confused about one point. Is the problem that we're setting currentTime too early (while the HTMLVideoElement is in the wrong state) or that we're setting currentTime to the exact same value that it already has?

I ask because in your PR, the subject is "defer assigning", but it seems to be checking the value instead of changing the timing.

[nickdesaulniers]

Is the problem that we're setting currentTime too early (while the HTMLVideoElement is in the wrong state)

This seems to be the case, but I work in blissful ignorance a few levels up from the media stack so I'm not really sure why this is considered an error in Firefox. Maybe "defer" is not the right term, feel free to reword the commit message manually. Also, I'm not sure if this breaks seeking; I would guess not, since that conditional predicate should be true.

It would be better to have the predicate be if state is ready then assign time to zero, but I'm not sure how to check the state of a media element to see. There's probably some constant on the MediaElement prototype that VideoElements inherit from, but didn't see any likely candidates to check in my admittedly brief look through the attributes.

[joeyparrish]

Yeah, I'm concerned #103 isn't the right fix. If it's a state issue, then some aspect of that state should be involved in the fix.

#103 only really fixes the problem if it's a matter of Firefox not permitting you to set currentTime to the same value it already has, which sounds like wacky behavior to me. I tend to think Firefox's implementation is smarter than that.

There are some streams which do not start at 0. I don't have a sample off-hand, but if you try something like this:

this.video.currentTime = streamStartTime + 1;

And it still throws an error, it's definitely a state problem and #103 isn't the right fix. If that does somehow fix it, we just need to reword the commit message in #103 and merge it.

[joeyparrish]

Ah, I just ran across something that may be relevant. See the change in stream_video_source.js in blinkbox/shaka-player@79a80f0. It may be that Firefox and IE11 both dislike how/when we set currentTime. You may want to try the same tweak in stream_video_source.js that Blinkbox is using for IE.

@jonoward: Can you offer us any insight on this? Is IE's behavior similar to the Firefox behavior described in this issue?

[jonoward]

Ah yes we had this exact issue in IE - it doesn't like certain operations being called before the video has metadata (calling msSetMediaKeys had the same issue).

Our change was to set currentTime within a handler for loadedmetadata. But to be really robust, you could first check if videoElement.readyState is > 0, if so, set current time immediately, else defer to loadedmetadata. Hope that helps!

[nickdesaulniers]

if state is ready then assign time to zero, but I'm not sure how to check the state of a media element to see.

you could first check if videoElement.readyState is > 0

heh, funny I missed that.

I'll rewrite my patch.

[nickdesaulniers]

Instead of > 0, there's const enums:

HTMLMediaElement.HAVE_NOTHING
HTMLMediaElement.HAVE_METADATA
HTMLMediaElement.HAVE_CURRENT_DATA
HTMLMediaElement.HAVE_FUTURE_DATA
HTMLMediaElement.HAVE_ENOUGH_DATA

so I think videoElement.readyState > HTMLMediaElement.HAVE_NOTHING is the way to go.