1182884 - (MSE) Video seek and playback fail

Status: RESOLVED WORKSFORME

(Core :: Audio/Video, defect)

Description

[CoolCmd]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Firefox/38.0
Build ID: 20150525141253

Steps to reproduce:

This bug about <video> and Media Source Extensions API implementation in Firefox 38 and 41.

On the most Twitch.tv videos (first converted from TS to MP4) it is impossible to change video.currentTime.
See example: http://coolcmd.tk/tmp/seek/seek.html?1a
In this example:
1. add segment to the "middle" of timeline
2. seek to beginning of buffered range
3. start playback


Actual results:

Seek never ended. Playback not begin.


Expected results:

Playback must begin.
Chrome 43 plays this video.

Comment 1

[CoolCmd]

This bug can be partially avoided by adding segment to beginning of timeline.
Example here: http://coolcmd.tk/tmp/seek/seek.html?1b
But if stream contain "holes" that lead to multiple buffered ranges (videoTag.buffered.length > 1), playback will be stopped becouse of Firefox unable to seek to beginning of next range.

Workaround: turn off hardware acceleration. But CPU usage and overall Firefox performance without acceleration are unaccaptable.
My configuration: windows 7 x64, nvidia GTX770, driver 350.12

Comment 2

[CoolCmd]

http://coolcmd.tk/tmp/seek/seek.html?1b
This tons of unnecessary 'durationchange' events... videoTag.duretion always equals to Infinity. I think this is a bug!

Comment 3

[Jean-Yves Avenard [:jya]]

(In reply to CoolCmd from comment #1)
> This bug can be partially avoided by adding segment to beginning of timeline.
> Example here: http://coolcmd.tk/tmp/seek/seek.html?1b
> But if stream contain "holes" that lead to multiple buffered ranges
> (videoTag.buffered.length > 1), playback will be stopped becouse of Firefox
> unable to seek to beginning of next range.

Are you sure this is the right link?

You do a single appendBuffer, which contains [0, 2.002377) of video data.

You will get a stall after 2s. As your init segment doesn't contain any duration, as per spec, mediasource.duration (and as such video.duration) will be +infinity
http://w3c.github.io/media-source/index.html#sourcebuffer-init-segment-received

If the initialization segment contains a duration:
 [...]
Otherwise:
    Run the duration change algorithm with new duration set to positive Infinity.

FWIW, all browsers (Chrome, IE, Safari, Firefox) exhibit the same behaviour with that video.

Firefox explicitly show that playback has stalled once it reaches 2s and will show the spinner. This is the proper behaviour has your video has a duration set to infinity. The player as such is waiting for more data, which the spinner indicates.

If you issued an endOfStream() on your source buffer, playback would stop at 2s and no spinner will appear.

Comment 4

[Jean-Yves Avenard [:jya]]

(In reply to CoolCmd from comment #0)
> User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101
> Firefox/38.0
> Build ID: 20150525141253
> 
> Steps to reproduce:
> 
> This bug about <video> and Media Source Extensions API implementation in
> Firefox 38 and 41.
> 
> On the most Twitch.tv videos (first converted from TS to MP4) it is
> impossible to change video.currentTime.
> See example: http://coolcmd.tk/tmp/seek/seek.html?1a
> In this example:
> 1. add segment to the "middle" of timeline
> 2. seek to beginning of buffered range
> 3. start playback
> 
> 
> Actual results:
> 
> Seek never ended. Playback not begin.
> 
> 
> Expected results:
> 
> Playback must begin.
> Chrome 43 plays this video.

You do a single appendBuffer with video data [2423.219, 2425.221377) (in seconds, that is 40 minutes 23s).
You then do a seek to position 2423.219s

It seeks to that position and continue.

I see the behaviour you are expecting in 41, nightly, and identical behaviour in Safari and Chrome (IE 11 playback on windows 8 doesn't start).

Firefox 38 and 39 only have official support for YouTube.

Comment 5

[CoolCmd]

(In reply to Jean-Yves Avenard [:jya] from comment #4)
> I see the behaviour you are expecting in 41, nightly
You have nvideo videocard, windows 7/8 and turned on hardware acceleration? See last note in commant #1. I tested in FF 41 DevEd.

Comment 6

[CoolCmd]

(In reply to Jean-Yves Avenard [:jya] from comment #3)
You are inattentive. In comment #2 I complain about unnecessary events, not about value of 'duration' property.

Comment 7

[Jean-Yves Avenard [:jya]]

(In reply to CoolCmd from comment #6)
> (In reply to Jean-Yves Avenard [:jya] from comment #3)
> You are inattentive. In comment #2 I complain about unnecessary events, not
> about value of 'duration' property.

If you properly read what I wrote, you would have seen that I was only explaining the current behaviour and describe what is happening: e.g. after 2s of playback the video will stall rather than ends. And this is due to the duration being +infinity.

Remember that we are here to help, taking an aggressive attitude towards us will get you nowhere.

Comment 8

[CoolCmd]

(In reply to Jean-Yves Avenard [:jya] from comment #7)
> Remember that we are here to help, taking an aggressive attitude towards us
> will get you nowhere.
Who "we"? File a bug helps. Bug fix helps. You only write that you see in Ctrl+Shift+S & Ctrl+Shift+K. And this info (stall, duration) not related to bug. This is not aggression. I only say, that you read bug description inattentive (невнимательно).

Comment 9

[Jean-Yves Avenard [:jya]]

What I'm saying is that the behaviour of firefox is exactly per spec for the video you are loading.

You load 2s of video, it plays, and then stall once it reaches the end of the video.