1405025 - A fully buffered YouTube video will buffer again if you click ahead or go backwards in the progress bar.

Status: VERIFIED FIXED

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

Description

[the_goodone1]

Attachment: exolain.png

User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:57.0) Gecko/20100101 Firefox/57.0
Build ID: 20170925150345

Steps to reproduce:

steps to reproduce:

1- Open any YouTube video (long or short). for example: https://www.youtube.com/watch?v=YIywpvHewc0 

2- choose any high quality(720p for example) then leave the video until it loads(buffers) completely.

3- While the video is playing click ahead in the progress bar to a spot that has already been buffered and also try going backwards and forward few times.


Actual results:

What happened:

Sometimes the video starts to load/buffer again despite being fully loaded before and this happens without any change of the video quality.

I also tried to load the videos in safe mode and had the same results.

https://streamable.com/l4dhu


Expected results:

expected results:

I expect the video to load and play properly without buffering again as it is already fully loaded and I have bandwidth cap so when I watch long YouTube video and skip some parts I can't afford it to reload again eating my bandwidth.

I haven't experienced this behavior with other browsers(Chrome, Edge, Opera)

Firefox 57 beta 3 on Windows 10 64x (15063.632)

Comment 1

[the_goodone1]

Attachment: Video link.mp4

Comment 2

[Jean-Yves Avenard [:jya]]

Youtube controls the buffer behaviour as they are using MSE.

Any issues you see need to be reported to them, it's outside our control.

Comment 3

[SeriousHoax]

I have this same issue. Very frustrating 

Comment 4

[the_goodone1]

(In reply to Jean-Yves Avenard [:jya] from comment #2)
> Youtube controls the buffer behaviour as they are using MSE.
> 
> Any issues you see need to be reported to them, it's outside our control.

It's clearly a Firefox Issue, this behavior doesn't happen with other browsers(Chrome, Edge, Opera), It doesn't happen with Windows 10 YouTube apps Like MyTube, And the most important it doesn't happen with older version of Firefox like Firefox 50(I just tested it)

So it's indeed an issue with the new versions of Firefox.

Comment 5

[Jean-Yves Avenard [:jya]]

(In reply to the_goodone1 from comment #4)
> (In reply to Jean-Yves Avenard [:jya] from comment #2)
> > Youtube controls the buffer behaviour as they are using MSE.
> > 
> > Any issues you see need to be reported to them, it's outside our control.
> 
> It's clearly a Firefox Issue, this behavior doesn't happen with other
> browsers(Chrome, Edge, Opera), It doesn't happen with Windows 10 YouTube
> apps Like MyTube, And the most important it doesn't happen with older
> version of Firefox like Firefox 50(I just tested it)
> 
> So it's indeed an issue with the new versions of Firefox.

And it could be that Youtube sniff the user agent and have different behaviour with Firefox.

When using MSE, how much data is buffered, when things are buffered and so on, is entirely controlled by youtube.

See if changing your user-agent to report being Chrome makes a difference.

The only thing that could make a difference is the size of the buffers allowed, and if they have been changed from their default (a copy of about:support would show that)

Comment 6

[the_goodone1]

(In reply to Jean-Yves Avenard [:jya] from comment #5)
> (In reply to the_goodone1 from comment #4)
> > (In reply to Jean-Yves Avenard [:jya] from comment #2)
> > > Youtube controls the buffer behaviour as they are using MSE.
> > > 
> > > Any issues you see need to be reported to them, it's outside our control.
> > 
> > It's clearly a Firefox Issue, this behavior doesn't happen with other
> > browsers(Chrome, Edge, Opera), It doesn't happen with Windows 10 YouTube
> > apps Like MyTube, And the most important it doesn't happen with older
> > version of Firefox like Firefox 50(I just tested it)
> > 
> > So it's indeed an issue with the new versions of Firefox.
> 
> And it could be that Youtube sniff the user agent and have different
> behaviour with Firefox.
> 
> When using MSE, how much data is buffered, when things are buffered and so
> on, is entirely controlled by youtube.
> 
> See if changing your user-agent to report being Chrome makes a difference.
> 
> The only thing that could make a difference is the size of the buffers
> allowed, and if they have been changed from their default (a copy of
> about:support would show that)

The weird thing is that Firefox 50 works fine but from version 53 to 57beta it has this issue with YouTube.

the YouTube videos buffers fine, the problem is when I try going backwards and forward few times in the video, the video starts to load/buffer again despite being fully loaded before and this happens without any change of the video quality.

maybe it has something to do with the cached files?

I also made a thread on reddit about this issue and clearly it affects some people. https://www.reddit.com/r/firefox/comments/73uf4j/firefox_issue_with_youtube_a_fully_buffered/

Comment 7

[Jean-Yves Avenard [:jya]]

When the issue occurs, right click on the video window and select "copy debug info"

Copy the output here.. We can get someone at YouTube to comment on this.

Thanks

Comment 8

[SeriousHoax]

(In reply to Jean-Yves Avenard [:jya] from comment #7)
> When the issue occurs, right click on the video window and select "copy
> debug info"
> 
> Copy the output here.. We can get someone at YouTube to comment on this.
> 
> Thanks

Not sure if I did it at the right moment. I hope I did. Maybe u can check/verify.

{
  "ns": "yt",
  "el": "detailpage",
  "cpn": "mQ3YTGdZkg4K3kYR",
  "docid": "6-_TS0Q2O8Y",
  "ver": 2,
  "referrer": "https://www.youtube.com/user/teamcoco/videos",
  "cmt": "95.361",
  "plid": "AAVap5C9bi_EnRUz",
  "ei": "ecTTWduLHIbqoAOU2YPYAQ",
  "fmt": "136",
  "fs": "0",
  "rt": "336.166",
  "of": "croVTnsthRGZQ3vWojv7UA",
  "euri": "",
  "lact": 1,
  "cl": "170750331",
  "mos": 0,
  "state": "8",
  "vm": "CAEQARgE",
  "volume": 100,
  "subscribed": "1",
  "c": "WEB",
  "cver": "2.20171002",
  "cplayer": "UNIPLAYER",
  "cbr": "Firefox",
  "cbrver": "57.0",
  "cos": "Windows",
  "cosver": "10.0",
  "hl": "en_US",
  "cr": "US",
  "len": "277.841",
  "fexp": "23700451,23702322,23702700,23704248,23705739,23706129,9422596,9431754,9449243,9463829,9467503,9471235,9474594,9476026,9476327,9480475,9484344,9485000,9488038",
  "feature": "c4-videos-u",
  "afmt": "251",
  "vct": "95.361",
  "vd": "277.841",
  "vpl": "0.000-277.841,",
  "vbu": "90.757-97.121,",
  "vpa": "false",
  "vsk": "false",
  "ven": "false",
  "vpr": "1",
  "vrs": "3",
  "vns": "2",
  "vec": "null",
  "vvol": "1",
  "creationTime": 337067.91000000003,
  "totalVideoFrames": 8482,
  "droppedVideoFrames": 0,
  "corruptedVideoFrames": 0,
  "lct": "95.280",
  "lsk": false,
  "lmf": true,
  "lbw": "373267.600",
  "lhd": "0.211",
  "lst": "633.411",
  "laa": "itag=251,seg=9,range=1605748-1671283,time=93.7-97.4,off=65536,len=65536",
  "lva": "itag=136,seg=18,range=5569475-5672370,time=96.1-97.8,off=0,len=102896",
  "lar": "itag=251,seg=9,range=1671284-1716253,time=97.4-100.0,off=131072,len=44970,end=1",
  "lvr": "itag=136,seg=18,range=5672371-5847337,time=97.8-100.7,off=102896,len=174967",
  "lvh": "r2---sn-pjjoxu-q5je",
  "lab": "90.001-97.121,",
  "lvb": "90.757-97.297,",
  "ismb": 7550000,
  "relative_loudness": "-6.059",
  "optimal_format": "480p",
  "user_qual": "large",
  "debug_videoId": "6-_TS0Q2O8Y",
  "0sz": false,
  "op": "1",
  "yof": false,
  "dis": "",
  "gpu": "ANGLE_(Intel(R)_HD_Graphics_5500_Direct3D11_vs_5_0_ps_5_0)",
  "cgr": true,
  "debug_playbackQuality": "hd720",
  "debug_date": "Tue Oct 03 2017 23:15:54 GMT+0600 (Bangladesh Standard Time)"
}

Comment 9

[the_goodone1]

(In reply to Jean-Yves Avenard [:jya] from comment #7)
> When the issue occurs, right click on the video window and select "copy
> debug info"
> 
> Copy the output here.. We can get someone at YouTube to comment on this.
> 
> Thanks

Sure, but I still have a feeling this issue has something to do with how Firefox handles the video's cache files, It looks like Firefox can't read the parts of the video that were already buffered and starts loading it again.



Here's the debug info for a test video:

{
  "ns": "yt",
  "el": "detailpage",
  "cpn": "2R7ZYqu7ZXkTQPjX",
  "docid": "RC3h0F4e0kw",
  "ver": 2,
  "referrer": "https://www.youtube.com/results?q=illustrator+tutorial+pen+tool&sp=CAMSAggFUBQ%253D",
  "cmt": "360.444",
  "plid": "AAVaqIcux8pJkxdF",
  "ei": "oNTTWYakFIfAV-q4htAI",
  "fmt": "247",
  "fs": "0",
  "rt": "264.599",
  "of": "r5XL3IoXMdho3ANusHLOHA",
  "euri": "",
  "lact": 1,
  "cl": "170750331",
  "mos": 0,
  "state": "8",
  "vm": "CAEQABgE",
  "volume": 100,
  "c": "WEB",
  "cver": "1.20171002",
  "cplayer": "UNIPLAYER",
  "cbr": "Firefox",
  "cbrver": "57.0",
  "cos": "Windows",
  "cosver": "10.0",
  "hl": "en_US",
  "cr": "US",
  "len": "533.061",
  "fexp": "23700451,23702322,23702700,23702730,23703174,23704248,23704745,23705257,23705597,23705739,23706129,23706451,9406004,9422596,9431754,9440167,9449243,9463829,9467503,9468342,9468867,9471239,9475670,9476026,9476327,9480475,9483485,9485000,9488038",
  "afmt": "251",
  "vct": "360.444",
  "vd": "533.061",
  "vpl": "0.000-2.412,2.612-4.850,140.956-141.466,352.230-352.862,360.136-360.444,485.801-486.311,",
  "vbu": "357.333-362.499,",
  "vpa": "false",
  "vsk": "false",
  "ven": "false",
  "vpr": "1",
  "vrs": "3",
  "vns": "2",
  "vec": "null",
  "vvol": "1",
  "creationTime": 265048.325,
  "totalVideoFrames": 206,
  "droppedVideoFrames": 0,
  "corruptedVideoFrames": 0,
  "lct": "360.403",
  "lsk": false,
  "lmf": true,
  "lbw": "362339.659",
  "lhd": "0.525",
  "lst": "2108.028",
  "laa": "itag=251,seg=36,range=5825913-5891448,time=360.0-363.9,off=0,len=65536",
  "lva": "itag=247,seg=67,range=8841475-8986142,time=357.3-362.2,off=0,len=144668",
  "lar": "itag=251,seg=36,range=5825913-5891448,time=360.0-363.9,off=0,len=65536",
  "lvr": "itag=247,seg=68,range=8999523-9130810,time=362.7-367.5,off=0,len=131288",
  "lvh": "r2---sn-hpa7zn76",
  "lab": "350.001-363.961,",
  "lvb": "357.333-362.499,",
  "ismb": 890000,
  "relative_loudness": "-6.189",
  "optimal_format": "720p",
  "user_qual": "hd720",
  "debug_videoId": "RC3h0F4e0kw",
  "0sz": false,
  "op": "",
  "yof": false,
  "dis": "",
  "gpu": "ANGLE_(AMD_Radeon_HD_7900_Series_Direct3D9Ex_vs_3_0_ps_3_0)",
  "cgr": true,
  "debug_playbackQuality": "hd720",
  "debug_date": "Tue Oct 03 2017 20:23:35 GMT+0200 (Egypt Standard Time)"
}

Comment 10

[Jean-Yves Avenard [:jya]]

(In reply to the_goodone1 from comment #9)
> (In reply to Jean-Yves Avenard [:jya] from comment #7)
> > When the issue occurs, right click on the video window and select "copy
> > debug info"
> > 
> > Copy the output here.. We can get someone at YouTube to comment on this.
> > 
> > Thanks
> 
> Sure, but I still have a feeling this issue has something to do with how
> Firefox handles the video's cache files, It looks like Firefox can't read
> the parts of the video that were already buffered and starts loading it
> again.
>

Media Source Extension doesn't work that way. Firefox doesn't buffer or cache anything. It doesn't decide what is to be kept or loaded. 

The website itself decide that. 

Did you try changing the user-agent?

Comment 11

[the_goodone1]

(In reply to Jean-Yves Avenard [:jya] from comment #10)
> (In reply to the_goodone1 from comment #9)
> > (In reply to Jean-Yves Avenard [:jya] from comment #7)
> > > When the issue occurs, right click on the video window and select "copy
> > > debug info"
> > > 
> > > Copy the output here.. We can get someone at YouTube to comment on this.
> > > 
> > > Thanks
> > 
> > Sure, but I still have a feeling this issue has something to do with how
> > Firefox handles the video's cache files, It looks like Firefox can't read
> > the parts of the video that were already buffered and starts loading it
> > again.
> >
> 
> Media Source Extension doesn't work that way. Firefox doesn't buffer or
> cache anything. It doesn't decide what is to be kept or loaded. 
> 
> The website itself decide that. 
> 
> Did you try changing the user-agent?

okay, it's midnight now so tomorrow I'll change the user-agent and create virtual machine so I could do additional tests, and I'll report it here.

Thanks for your help.

Comment 12

[Jean-Yves Avenard [:jya]]

FWIW, I can't reproduce the issue you describe. 
While the UI makes it appears that it is re-buffering, looking at the internal logs, we can see that the content is already buffered, and no eviction ever occurs.

Can you provide the output of about:support to see if you have changed any default settings.

Comment 13

[Jean-Yves Avenard [:jya]]

JW, looking at the issue, the problem occurs due to the order of which evens are fired.


[LocalMediaElement] 38.089s: element=2 Set currentTime=10.292872289156627  base.js:97:85
[LocalMediaElement] 38.109s: element=2 Play  base.js:97:85
[VideoPlayer #1] 38.164s: video element event play  base.js:97:85
[VideoPlayer #1] 38.168s: video element event playing  base.js:97:85
[LocalMediaElement] 38.179s: element=2 Play  base.js:97:85
[VideoPlayer #1] 38.223s: video element event waiting  base.js:97:85
[VideoPlayer #1] 38.231s: video element event seeking  base.js:97:85
[VideoPlayer #1] 38.239s: video element event playing  base.js:97:85
[LocalMediaElement] 38.248s: element=2 Play  base.js:97:85
[VideoPlayer #1] 38.256s: video element event seeked  base.js:97:85
[LocalMediaElement] 39.800s: element=2 Pause  base.js:97:85
[VideoPlayer #1] 39.819s: video element event pause  base.js:97:85
[LocalMediaElement] 655.670s: element=2 Set currentTime=36.2377156626506  base.js:97:85
[VideoPlayer #1] 655.759s: video element event seeking  base.js:97:85
[VideoPlayer #1] 655.820s: video element event seeked

so here we see that YouTube set the currentTime to the seek position. Immediately however, they call play() so the play even is fired.

What is surprising however, is that the seeking event isn't fired until well after play() has been called.

Per spec, the seeking event should have been fired right after currentTime was changed

Comment 14

[Jean-Yves Avenard [:jya]]

Per spec:
https://html.spec.whatwg.org/multipage/media.html#seeking

"10. Queue a task to fire an event named seeking at the element."

so seeking should be queued immediately.

Instead here, we wait for the MDSM to start the seek operation to fire the seeking event.

the issue with YouTube here is that it receives the waiting event before receiving the seeking event (due to the call to play()) it assumes that the system needs re-buffering and will clear the sourcebuffer.

This rebuffering will not happen if YouTube has detected that we're seeking. However, as the seeking event is fired too late, this exception isn't taken into account. 
And the whole content of the source buffer is dropped.

Comment 15

[Jean-Yves Avenard [:jya]]

Attachment: Bug 1405025: queue seeking event immediately after seeking.

Per spec, the seeking event is to be queued when the seek operation is starting:
reference: https://www.w3.org/TR/2011/WD-html5-20110113/video.html#seeking
"9. Queue a task to fire a simple event named seeking at the element."

We also immediately queue a timeupdate event as per spec.

Review commit: https://reviewboard.mozilla.org/r/186262/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/186262/

Comment 16

[Jean-Yves Avenard [:jya]]

Comment on attachment 8914997 [details]
Bug 1405025: queue seeking event immediately after seeking.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/186262/diff/1-2/

Comment 17

[Jean-Yves Avenard [:jya]]

[Tracking Requested - why for this release]: while not a firefox problem on itself, the way youtube expects events make it rebuffer all content when seeking. This causes unnecessary network usage.

Comment 18

[Jean-Yves Avenard [:jya]]

On second thought:
https://html.spec.whatwg.org/multipage/media.html#seeking

    5. If the seek was in response to a DOM method call or setting of an IDL attribute, then continue the script. The remainder of these steps must be run in parallel. With the exception of the steps marked with ⌛, they could be aborted at any time by another instance of this algorithm being invoked

So the steps being run in parallel, it's perfectly in the spec that the seeking event isn't fired right away. If you called play() right after changing currentTime it is entirely possible play() is fired prior the seeking event , and as such, as the seeking process may not have started yet, playing could start at the current position.

Comment 19

[Jean-Yves Avenard [:jya]]

I think this issue should be resolved on YouTube's side.

Comment 20

[Blake Wu [:bwu][:blakewu]]

Twitter uses waiting event to show spinner in bug 1402964.

Comment 21

[Blake Wu [:bwu][:blakewu]]

Youtube could consider re-buffering by checking if there are frames dropped.

Comment 22

[JW Wang [:jwwang] [:jw_wang]]

I think Youtube expects the user agent not to fire the 'waiting' event if the seek target is withing the buffered ranges. However, Firefox always fires 'waiting' events for seek will change the readyState to HAVE_METADATA [1].

[1] http://searchfox.org/mozilla-central/rev/e62604a97286f49993eb29c493672c17c7398da9/dom/html/HTMLMediaElement.cpp#5751-5755

Below is the spec. text about firing 'waiting' events during seek.
"If the media element was potentially playing immediately before it started seeking, but seeking caused its readyState attribute to change to a value lower than HAVE_FUTURE_DATA, then a waiting event will be fired at the element."

Firefox does exactly what the spec. says by changing readyState to HAVE_METADATA because there is no "current" frame to display until seek is done.

Comment 23

[Jean-Yves Avenard [:jya]]

This is not the real issue....
YouTube will ignore the waiting event if it finds that it's in the middle of a seek operation.

however, the seeking event isn't fired in the same order as what chrome does.

if seeking had been fired prior the waiting event it would have been fine.

I believe the solution for YouTube here is to either detect that a seek has started differently, or not call play() until the seeked event has been received.

Comment 24

[kalviskajaks]

So every single other browser is implementing the spec wrong? Comment 4 says Chrome, Edge, Opera and windows 10 youtube app dont have the problem. And i just checked IE 11 and it didn't have the problem either.

Comment 25

[Jean-Yves Avenard [:jya]]

(In reply to JW Wang [:jwwang] [:jw_wang] from comment #22)
> I think Youtube expects the user agent not to fire the 'waiting' event if
> the seek target is withing the buffered ranges. However, Firefox always
> fires 'waiting' events for seek will change the readyState to HAVE_METADATA
> [1].
> 
> [1]
> http://searchfox.org/mozilla-central/rev/
> e62604a97286f49993eb29c493672c17c7398da9/dom/html/HTMLMediaElement.cpp#5751-
> 5755
> 
> Below is the spec. text about firing 'waiting' events during seek.
> "If the media element was potentially playing immediately before it started
> seeking, but seeking caused its readyState attribute to change to a value
> lower than HAVE_FUTURE_DATA, then a waiting event will be fired at the
> element."
> 
> Firefox does exactly what the spec. says by changing readyState to
> HAVE_METADATA because there is no "current" frame to display until seek is
> done.

the issue however is that per those spec:
https://html.spec.whatwg.org/multipage/media.html#seeking

what you describe should have occurred *after* the seeking event having been queued. However here, we can see that waiting was fired prior seeking.

It only seems to occur if play() was called right after seeking. But you could argue that the readyState had no reason to occur prior the seeking event being queued.

Comment 26

[JW Wang [:jwwang] [:jw_wang]]

I agree with your point.

Since this note
"If the media element was potentially playing immediately before it started seeking, but seeking caused its readyState attribute to change to a value lower than HAVE_FUTURE_DATA, then a waiting event will be fired at the element."

is a note of step 11. It is a potential consequence of step 11 which must happen after step 10 (queuing a seeking event).

Comment 27

[Jean-Yves Avenard [:jya]]

(In reply to kalviskajaks from comment #24)
> So every single other browser is implementing the spec wrong? Comment 4 says
> Chrome, Edge, Opera and windows 10 youtube app dont have the problem. And i
> just checked IE 11 and it didn't have the problem either.

It's a YouTube issue, they will fix it on their end.

Comment 28

[the_goodone1]

I made more tests yesterday:

1- I could reproduce this issue with a fresh install of Firefox 57 on a new virtual machine.

2- this issue doesn't happen with (240 or 360) quality.

3- this issue doesn't happen with IE 11 so Firefox is still the only browser that has this issue.

Comment 29

[khagaroth]

> "If the media element was potentially playing immediately before it started
> seeking, but seeking caused its readyState attribute to change to a value
> lower than HAVE_FUTURE_DATA, then a waiting event will be fired at the
> element."
Sorry, but the way I read this is that if you have future data, ie. are seeking
within a buffered range, then you shouldn't fire a waiting event.

Comment 30

[Jean-Yves Avenard [:jya]]

Note that this description makes no reference to the buffered range. The buffered range indicates if you have data at a specific time that won't require to fetch new data.
As such, seeking within a buffered range, doesn't mean you have an image ready to be displayed instantly.
when you seek, temporarily you move readyState back to HAVE_METADATA as you don't immediately have a picture to be displayed at the seek point.
As you decode the frame at the seeking point, readyState becomes HAVE_CURRENT_DATA, and as more of the video queue is filled, then readyState can move to HAVE_FUTURE_DATA.

It takes a little while for seek to complete and data to be decoded.

When you seek, the waiting event is to be fired.

The issue at hand is that the waiting event is fired prior the seeking event.

YouTube logic relies on having the seeking event fired prior waiting, otherwise it considers the waiting event as an indication that the computer is struggling to display the content at the current resolution. When it believes that the content can't be decoded fast enough, it will flush the content and feed new ones...

My understanding was that this behaviour was chosen because Chrome fires the waiting event when it can't decode fast enough the current content.

Comment 31

[JW Wang [:jwwang] [:jw_wang]]

Btw, my test shows that Chrome doesn't fire 'waiting' when seeking within buffered ranges.

However, according to the spec. https://html.spec.whatwg.org/multipage/media.html#ready-states

HAVE_CURRENT_DATA (numeric value 2)

    Data for the immediate current playback position is available, but either not enough data is available that the user agent could successfully advance the current playback position in the direction of playback at all without immediately reverting to the HAVE_METADATA state, 

"Data" here should be interpreted as "decoded data" instead of "buffered data" since we can't advance current playback position without "decoded data". So Firefox is spec. conformant in this sense.

Comment 32

[JW Wang [:jwwang] [:jw_wang]]

Attachment: Bug 1405025. P1 - ensure 'seeking' is fired before 'waiting'.

Use MediaEventSource instead of state-mirroring to notify nextFrameStatus
changes so we have more control over the order of events.

Review commit: https://reviewboard.mozilla.org/r/187580/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/187580/

Comment 33

[JW Wang [:jwwang] [:jw_wang]]

Attachment: Bug 1405025. P2 - revert Bug 1390443 P1.

Since we don't use state-mirroring to dispatch nextFrameStatus changes, we
can now revert the workaround of bug 1390443 P1. See bug 1390443 comment 0
for more details.

Review commit: https://reviewboard.mozilla.org/r/187582/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/187582/

Comment 34

[Jean-Yves Avenard [:jya]]

Comment on attachment 8916463 [details]
Bug 1405025. P1 - ensure 'seeking' is fired before 'waiting'.

https://reviewboard.mozilla.org/r/187580/#review192640

::: dom/media/MediaDecoderStateMachine.h:255
(Diff revision 1)
>    OnPlaybackErrorEvent() { return mOnPlaybackErrorEvent; }
>  
>    MediaEventSource<DecoderDoctorEvent>&
>    OnDecoderDoctorEvent() { return mOnDecoderDoctorEvent; }
>  
> +  MediaEventSource<NextFrameStatus>& OnNextFrameStatus()

can you use the same style as the few functions above?

MediaEventSource<Type>&
FunctionName() { return blah; }

for consistency sake

Comment 35

[Jean-Yves Avenard [:jya]]

Comment on attachment 8916464 [details]
Bug 1405025. P2 - revert Bug 1390443 P1.

https://reviewboard.mozilla.org/r/187582/#review192642

Comment 36

[JW Wang [:jwwang] [:jw_wang]]

Comment on attachment 8916463 [details]
Bug 1405025. P1 - ensure 'seeking' is fired before 'waiting'.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/187580/diff/1-2/

Comment 37

[JW Wang [:jwwang] [:jw_wang]]

Comment on attachment 8916464 [details]
Bug 1405025. P2 - revert Bug 1390443 P1.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/187582/diff/1-2/

Comment 38

[JW Wang [:jwwang] [:jw_wang]]

Thanks for the review!

Comment 39

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/a366fc57e78f
P1 - ensure 'seeking' is fired before 'waiting'. r=jya
https://hg.mozilla.org/integration/autoland/rev/b7429873f639
P2 - revert Bug 1390443 P1. r=jya

Comment 40

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/mozilla-central/rev/a366fc57e78f

Comment 41

[the_goodone1]

So is it really fixed? Nice work guys.  

IS there any way to have this fix on Firefox 57?

Comment 42

[JW Wang [:jwwang] [:jw_wang]]

Can you try Nightly(58) to see if the fix works for you?

Since 57 is a major release, we want to cook the fix in 58 for a while before we feel confident to uplift the fix to 57.

Comment 43

[Kestrel]

It's working great for me on latest Nightly, love having a reliable buffer while doing lots of seeking.

Comment 44

[the_goodone1]

It seems to be fixed on latest Nightly 58.

BTW, this bug also affects Firefox 56 not just 57 beta.

Comment 45

[Ryan VanderMeulen [:RyanVM]]

New regression in 57. Please request Beta approval on this ASAP.

Comment 46

[JW Wang [:jwwang] [:jw_wang]]

Comment on attachment 8916463 [details]
Bug 1405025. P1 - ensure 'seeking' is fired before 'waiting'.

Approval Request Comment
[Feature/Bug causing the regression]:1314219
[User impact if declined]:long seek latency in Youtube
[Is this code covered by automated tests?]:no
[Has the fix been verified in Nightly?]:yes
[Needs manual test from QE? If yes, steps to reproduce]: no
[List of other uplifts needed for the feature/fix]:none
[Is the change risky?]:low
[Why is the change risky/not risky?]:This fix changes the order of events which are ignored by most sites.
[String changes made/needed]:none

Comment 47

[JW Wang [:jwwang] [:jw_wang]]

Comment on attachment 8916464 [details]
Bug 1405025. P2 - revert Bug 1390443 P1.

Approval Request Comment
[Feature/Bug causing the regression]:1314219
[User impact if declined]:long seek latency in Youtube
[Is this code covered by automated tests?]:no
[Has the fix been verified in Nightly?]:yes
[Needs manual test from QE? If yes, steps to reproduce]: no
[List of other uplifts needed for the feature/fix]:none
[Is the change risky?]:low
[Why is the change risky/not risky?]:This fix changes the order of events which are ignored by most sites.
[String changes made/needed]:none

Comment 48

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Comment on attachment 8916463 [details]
Bug 1405025. P1 - ensure 'seeking' is fired before 'waiting'.

recent regression, Beta57+

Comment 49

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-beta/rev/57c10a793a80
https://hg.mozilla.org/releases/mozilla-beta/rev/4dd7832a9238

Comment 50

[Oana Botisan, Desktop QA]

I managed to reproduce the bug using an older version of Nightly (2017-09-21) on Mac OS X 10.11, Windows 10x64 and Ubuntu 16.04x64. 

I retested everything using the latest Nightly 58 on the same platforms and the bug is not reproducing anymore. 

On the other hand... the bug is still reproducing on beta 57.0b8. After a few clicks on the progress bar, the video looks like it's loading again and sometimes it even starts to buffer. Could this be due to the fact that the fix hasn't been uplifted to 57 yet?

Comment 51

[the_goodone1]

(In reply to Oana Botisan from comment #50)
> I managed to reproduce the bug using an older version of Nightly
> (2017-09-21) on Mac OS X 10.11, Windows 10x64 and Ubuntu 16.04x64. 
> 
> I retested everything using the latest Nightly 58 on the same platforms and
> the bug is not reproducing anymore. 
> 
> On the other hand... the bug is still reproducing on beta 57.0b8. After a
> few clicks on the progress bar, the video looks like it's loading again and
> sometimes it even starts to buffer. Could this be due to the fact that the
> fix hasn't been uplifted to 57 yet?

to my knowledge, this bug will be fixed with Firefox beta 9

Comment 52

[Oana Botisan, Desktop QA]

I retested everything using beta 57.0b9 on Windows 10x64, macOS 10.12 and Ubuntu 16.04X64 and the bug is not reproducing anymore.

Comment 53

[Max Emerson]

(In reply to JW Wang [:jwwang] [:jw_wang] from comment #47)
> Comment on attachment 8916464 [details]
> Bug 1405025. P2 - revert Bug 1390443 P1.
> 
> Approval Request Comment
> [Feature/Bug causing the regression]:1314219
> [User impact if declined]:long seek latency in Youtube
> [Is this code covered by automated tests?]:no
> [Has the fix been verified in Nightly?]:yes
> [Needs manual test from QE? If yes, steps to reproduce]: no
> [List of other uplifts needed for the feature/fix]:none
> [Is the change risky?]:low
> [Why is the change risky/not risky?]:This fix changes the order of events
> which are ignored by most sites.
> [String changes made/needed]:none

I want to ask about something. since Firefox 57 beta 9 update(the one with the fix) and latest nightly I see more CPU usage while clicking ahead in the progress bar or going backwards. CPU usage is like 3 times more than what it used to be.

So technically, could this be related somehow to this fix? or it's just because of another thing? I'm just trying to narrow down the causes of this sudden high CPU usage.

Comment 54

[JW Wang [:jwwang] [:jw_wang]]

Which site is causing this CPU issue? Is MSE enabled?

It would be very helpful to provide a test page to demo the issue mentioned above.

Comment 55

[Max Emerson]

(In reply to JW Wang [:jwwang] [:jw_wang] from comment #54)
> Which site is causing this CPU issue? Is MSE enabled?
> 
> It would be very helpful to provide a test page to demo the issue mentioned
> above.

I notice this CPU issue with YouTube after latest beta 9 and latest nightly, haven't really tested it with other video sites.

STR:

1- Create fresh profile with default settings.

2- play YouTube video with high quality(1080p, 60fps)

3- while clicking on the progress bar, I notice higher CPU usage than before, if I click faster on the progress bar CPU usage could rise to 90%

Expected results:

With chrome and Firefox 57 first betas(before the buffering fix) I see way lower CPU usage when clicking ahead in the progress bar or going backwards.



So, could somehow the new fix that changes the order of events cause this CPU issue or it's not relevant?

Comment 56

[Blake Wu [:bwu][:blakewu]]

Max, 
Thanks for your finding. 
Can you open another bug to address the problem you find?

Comment 57

[Jean-Yves Avenard [:jya]]

(In reply to Max Emerson from comment #55)
> (In reply to JW Wang [:jwwang] [:jw_wang] from comment #54)
> > Which site is causing this CPU issue? Is MSE enabled?
> > 
> > It would be very helpful to provide a test page to demo the issue mentioned
> > above.
> 
> I notice this CPU issue with YouTube after latest beta 9 and latest nightly,
> haven't really tested it with other video sites.
> 
> STR:
> 
> 1- Create fresh profile with default settings.
> 
> 2- play YouTube video with high quality(1080p, 60fps)
> 
> 3- while clicking on the progress bar, I notice higher CPU usage than
> before, if I click faster on the progress bar CPU usage could rise to 90%
> 
> Expected results:
> 
> With chrome and Firefox 57 first betas(before the buffering fix) I see way
> lower CPU usage when clicking ahead in the progress bar or going backwards.
> 
> 
> 
> So, could somehow the new fix that changes the order of events cause this
> CPU issue or it's not relevant?

Unlikely to the extreme that this is related.
However, you may now be getting VP9 while you used to get H264 and your machine can't do VP9 in hardware. 


Right click on the video player, and select stats for nerds. Does it show VP9 in there?


You can always disable webm/VP9 to get H264 instead.