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

VERIFIED FIXED in Firefox 57

Status

()

defect
P2
normal
VERIFIED FIXED
2 years ago
3 months ago

People

(Reporter: the_goodone1, Assigned: jwwang)

Tracking

(Regressed 1 bug, {regression})

57 Branch
mozilla58
Points:
---

Firefox Tracking Flags

(firefox-esr52 unaffected, firefox56 wontfix, firefox57 verified, firefox58 verified)

Details

Attachments

(4 attachments, 1 obsolete attachment)

Posted image 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)
Posted video Video link.mp4
Component: Untriaged → Audio/Video
Priority: -- → P1
Product: Firefox → Core
Priority: P1 → --
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.
I have this same issue. Very frustrating 
(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.
(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)
(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/
Component: Audio/Video → Audio/Video: Playback
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
Flags: needinfo?(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

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)"
}
(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)"
}
Flags: needinfo?(the_goodone1)
(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?
(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.
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.
Flags: needinfo?(the_goodone1)
Flags: needinfo?(the_goodone1)
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
Flags: needinfo?(jwwang)
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.
Keywords: regression
Assignee: nobody → jyavenard
[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.
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.
I think this issue should be resolved on YouTube's side.
Twitter uses waiting event to show spinner in bug 1402964.
Attachment #8914997 - Flags: review?(jwwang)
Youtube could consider re-buffering by checking if there are frames dropped.
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.
Flags: needinfo?(jwwang)
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.
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.
(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.
Flags: needinfo?(jwwang)
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).
Flags: needinfo?(jwwang)
(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.
Assignee: jyavenard → jwwang
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.
> "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.
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.
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.
Attachment #8916463 - Flags: review?(jyavenard)
Attachment #8916464 - Flags: review?(jyavenard)
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
Attachment #8916463 - Flags: review?(jyavenard) → review+
Comment on attachment 8916464 [details]
Bug 1405025. P2 - revert Bug 1390443 P1.

https://reviewboard.mozilla.org/r/187582/#review192642
Attachment #8916464 - Flags: review?(jyavenard) → review+
Thanks for the review!
https://hg.mozilla.org/mozilla-central/rev/a366fc57e78f
Status: UNCONFIRMED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla58
So is it really fixed? Nice work guys.  

IS there any way to have this fix on Firefox 57?
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.
It's working great for me on latest Nightly, love having a reliable buffer while doing lots of seeking.
It seems to be fixed on latest Nightly 58.

BTW, this bug also affects Firefox 56 not just 57 beta.
New regression in 57. Please request Beta approval on this ASAP.
Flags: needinfo?(jwwang)
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
Flags: needinfo?(jwwang)
Attachment #8916463 - Flags: approval-mozilla-beta?
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
Attachment #8916464 - Flags: approval-mozilla-beta?
Comment on attachment 8916463 [details]
Bug 1405025. P1 - ensure 'seeking' is fired before 'waiting'.

recent regression, Beta57+
Attachment #8916463 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Attachment #8916464 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Flags: qe-verify+
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?
(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
I retested everything using beta 57.0b9 on Windows 10x64, macOS 10.12 and Ubuntu 16.04X64 and the bug is not reproducing anymore.
Status: RESOLVED → VERIFIED
Flags: qe-verify+
(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.
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.
(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?
Max, 
Thanks for your finding. 
Can you open another bug to address the problem you find?
(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.
Attachment #8914997 - Attachment is obsolete: true
Depends on: 1472139
No longer depends on: 1472139
Regressions: 1472139
No longer regressions: 1472139
Regressions: 1472139
Regressions: 1543059
You need to log in before you can comment on or make changes to this bug.