Closed Bug 1513511 Opened 5 years ago Closed 5 years ago

Youtube stuttering in 64, fine in 63

Categories

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

64 Branch
defect

Tracking

()

VERIFIED FIXED
mozilla66
Tracking Status
firefox-esr60 --- unaffected
firefox64 + verified
firefox65 + verified
firefox66 + verified

People

(Reporter: ali.nz2005, Assigned: jya)

References

(Blocks 1 open bug)

Details

Attachments

(2 files)

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:63.0) Gecko/20100101 Firefox/63.0

Steps to reproduce:

Played VP9 YouTube videos in version 64 stable.

about:support details:
https://pastebin.com/mrvTN9hv

Specs:
i5 2400
8gb DDR3
GTX 970
Win 7


Actual results:

Micro stuttering occurred. It is especially noticeable during a slow panning shot. Stats for nerds show that no frames are being dropped.


Expected results:

No stuttering, as was the case in 63 and earlier.
Component: Untriaged → Audio/Video: Playback
Product: Firefox → Core
when using Firefox 63, were you using H264 by any chance?

Firefox 64 determine the capabilities of your machine and tell youtube that your machine can do VP9.

Are you manually selecting a resolution higher than the one set on "Auto" ?

Does it play better in Chrome?

When in youtube and you right click on the video, select "Stats for nerds" what codec is it using?
I noticed the same issue on my main rig (i7 2600K, 16 Gb DDR3, GeForce 970GTX) after updating Firefox from 63 to 64 yesterday. 
The problem appears even with the resolution set on "Auto". It does play better in Edge (I don't have Chrome installed ATM).
Codec is VP9 indeed.
Flags: needinfo?(ali.nz2005)
(In reply to Ge3k0s from comment #2)
> I noticed the same issue on my main rig (i7 2600K, 16 Gb DDR3, GeForce
> 970GTX) after updating Firefox from 63 to 64 yesterday. 
> The problem appears even with the resolution set on "Auto". It does play
> better in Edge (I don't have Chrome installed ATM).

VP9 is used even with edge?
Same problem same bug on Manjaro Linux (Arch Based) when I downgrade in 63 no more problems

AMD Ryzen 5
16 GB DDR4
GeForce GTX 970
(In reply to elrond94 from comment #4)
> Same problem same bug on Manjaro Linux (Arch Based) when I downgrade in 63
> no more problems
> 
> AMD Ryzen 5
> 16 GB DDR4
> GeForce GTX 970

that would be an entire issue to the earlier ones.

On Linux, VP9 was always enabled.

Please open a new bug.
(In reply to Jean-Yves Avenard [:jya] from comment #3)
> (In reply to Ge3k0s from comment #2)
> > I noticed the same issue on my main rig (i7 2600K, 16 Gb DDR3, GeForce
> > 970GTX) after updating Firefox from 63 to 64 yesterday. 
> > The problem appears even with the resolution set on "Auto". It does play
> > better in Edge (I don't have Chrome installed ATM).
> 
> VP9 is used even with edge?

No as a matter of fact I just checked and it seems Edge uses AVC1.
(In reply to elrond94 from comment #7)
> Is it a joke ???
> 
> That's the same bug caused by the new firefox 64, and I have to open another
> bug report.... Majority of users not reporting bugs. Don't cry about users
> quits Firefox to Chromium... It's unacceptable

It is not the same bug.

The other users are seeing the issues because in 63 they were served H264 content which is hardware accelerated when running Windows and in 64, we allow VP9 which YouTube will use by default when available.
So they see a regression because they go from using hardware accelerated content to software decoded one.

You on the other hand, are using Linux, which is never hardware accelerated and as such only using software decoder.
In 63 when watching YouTube you were being served VP9 content, now you moved to 64 and you are seeing a playback issue.

While it may think it's the same thing, I can guarantee you it is not and involve very different teams at Mozilla that could resolve this issue.

There's no much difference between 63 and 64 on Linux as far as media playback is concerned. So another type of regression as occurred.

The original users have provided us with an about:support giving us good information to act on.

You didn't, other than saying "me too", while you may have similar observable problems, the underlying cause will be entirely different.

As such, the best for you is to open a new bug, provide information such as your about:support output where we can see if you've modified any preferences and answer the follow-up questions that will surely come trying to help you resolve your issue.

"Me too" reports when your using a different OS, a different graphic card and a completely different code path internally, doesn't help us.

We're a small team, doing the best we can, and we certainly want to resolve the issue you're experiencing.
I forced with options hardware acceleration on linux.
(In reply to Ge3k0s from comment #6)
> > VP9 is used even with edge?
> 
> No as a matter of fact I just checked and it seems Edge uses AVC1.

So that's why edge is very smooth for you.

A work around would be to disable Media Capabilities , open about:config and set media.media-capabilities.enabled to false. Is it any better?

Also, please provide an about:support data.
(In reply to elrond94 from comment #9)
> I forced with options hardware acceleration on linux.

there's no hardware decoding support on linux. All you have done is enable composition with OpenGL.
media.media-capabilities.enabled is true on my linux

And no capabilities.... 

What about this ?

https://i.imgur.com/Qs9KCou.png

Anyway I have no probs with 63x versions and the same as other user with 64x...

Don't complain about the number of bugreporting users and after forced users to open 10000000 other bugs reports (duplicate) about a similar prob....
(In reply to elrond94 from comment #12)
> media.media-capabilities.enabled is true on my linux
> 
yes, it was turned to true in 64.
but it would make no difference for linux users, which has been using VP9 on YouTube since Firefox 42.

> And no capabilities.... 
> 
> What about this ?
> 
> https://i.imgur.com/Qs9KCou.png

Again, we do not support hardware decoder on linux (there's no web browser today with VDPAU support on linux, none)

For VDPAU support, see bug 1210729.
Okay but how do you explain I have the same issue with 64x as others and no issue with 63x....
Lots of linux users of my team HAS the same issue. I'm very angry about this and think about switch to chromium. Ahh, give you another info, with this plugin: https://addons.mozilla.org/fr/firefox/addon/h264ify/ , it solves the issue with 64x
(In reply to elrond94 from comment #14)
> Okay but how do you explain I have the same issue with 64x as others and no
> issue with 63x....
> Lots of linux users of my team HAS the same issue. I'm very angry about this
> and think about switch to chromium. Ahh, give you another info, with this
> plugin: https://addons.mozilla.org/fr/firefox/addon/h264ify/ , it solves the
> issue with 64x

I do not know, there are more than one reason for a car not to run. Hence why I asked you in comment 5 and again in comment 8, that you opened a new bug, provide all the information we will need, starting with the output of about:support and I'm sure there will be questions from us that will follow.

Select the product Core and the component Audio/Video: Playback , my guess is that it will be reallocated elsewhere.
(In reply to Jean-Yves Avenard [:jya] from comment #10)
> (In reply to Ge3k0s from comment #6)
> > > VP9 is used even with edge?
> > 
> > No as a matter of fact I just checked and it seems Edge uses AVC1.
> 
> So that's why edge is very smooth for you.
> 
> A work around would be to disable Media Capabilities , open about:config and
> set media.media-capabilities.enabled to false. Is it any better?

No, it doesn't look any better when I change the pref.

> Also, please provide an about:support data.

I can't right now. I will try later.
(In reply to Jean-Yves Avenard [:jya] from comment #1)
> when using Firefox 63, were you using H264 by any chance?
> 
> Firefox 64 determine the capabilities of your machine and tell youtube that
> your machine can do VP9.
> 
> Are you manually selecting a resolution higher than the one set on "Auto" ?
> 
> Does it play better in Chrome?
> 
> When in youtube and you right click on the video, select "Stats for nerds"
> what codec is it using?

Hi Jean-Yves,

Apologies in the delay getting back to you.

In 63 it's using VP9. The resolution automatically sets its self to 1080p which I left it on.

Yes, in Chrome it plays smoothly.

It is using VP9 in 64 as well.
Flags: needinfo?(ali.nz2005)
I have the same issue after upgrading to FF 64. My specs are similar:

i5 2500k
GTX 970
8 GB RAM
Win 10

Both FF and Chrome are using the VP9 codec, according to YouTubes "Stats for nerds": vp09.00.51.08.01.01.01.01 (303) / opus (251). But FF is now much more stuttery than Chrome when playing this video: https://www.youtube.com/watch?v=lG5LZNhfyGM

Even with Chrome that video has some small judders, but they are constant in FF 64 and much more noticeable.

about:support: https://hastebin.com/coyaraniqa.makefile
So far the most common denominator used appears to be windows, nvidia machines.
Machines powerful enough that it would have already been using vp9 with YouTube even earlier on.

We have a too called mozregression available at https://github.com/mozilla/mozregression/releases/download/gui-0.9.35/mozregression-gui.exe

You can specify a range that was good (version 63) and one that is bad (64). When you run it, it will download and perform a binary search attempting to determine which change caused the regression.

Anyone feeling lucky, we would extremely appreciate running this tool and help us determine what is causing the regression for you.

Thank you in advance.
Mark this one as P2 for now, feel free to change priority.
Priority: -- → P2
Also to be sure.

When watching YouTube this is just any YouTube videos or could it be that you're watching YouTube premium?

Could you also mention how many monitors you're using?
(In reply to Jean-Yves Avenard [:jya] from comment #22)
> Also to be sure.
> 
> When watching YouTube this is just any YouTube videos or could it be that
> you're watching YouTube premium?
> 
> Could you also mention how many monitors you're using?

It happens on any YouTube video (I don't have premium), but that 60fps scrolling test is an easy one to spot it with. I have two displays, but I don't use use extend or duplicate to use them at the same time. I use Win+P to switch between them, so they basically function as single displays.

I just tested the scrolling test with a portable version of 63.0.3 and it's just as smooth as Chrome and is using the VP9 codec (vp9 (303) / opus (251)).

How easy is mozregression to uninstall? Will it leave a bunch of **** in AppData or the registry somewhere or mess with my Firefox profile data? If it was portable I would have tried messing with it already...
I've tested with the mozregression tool and found the culprit! Very satisfying tool.

Here is the output:
https://pastebin.com/BUXbycqd

The bug is with all YouTube videos, I don't have premium.

I'm using just one monitor - Dell U2415.
I should also note that this was the video I tested with:
https://www.youtube.com/watch?v=lG5LZNhfyGM

Makes it very easy to notice.
(In reply to Ali from comment #24)
> I've tested with the mozregression tool and found the culprit! Very
> satisfying tool.
> 
> Here is the output:
> https://pastebin.com/BUXbycqd
> 
> The bug is with all YouTube videos, I don't have premium.
> 
> I'm using just one monitor - Dell U2415.

Cool, saves me some work!

Thanks!
So bug 1488065 seems to be the culprit.
(In reply to Ali from comment #24)
> Here is the output:
> https://pastebin.com/BUXbycqd
> 
> The bug is with all YouTube videos, I don't have premium.
> 
> I'm using just one monitor - Dell U2415.

excellent, thank you very much for this.

if in about:config you change media.ffvpx.enabled from true to false

Are things better?
Yes I can confirm it's perfect again with media.ffvpx.enabled set to false.
(In reply to Ali from comment #29)
> Yes I can confirm it's perfect again with media.ffvpx.enabled set to false.

well, i see stutter regardless of the version I use, and same effects on chrome.
It's very subtle, few frames dropped here and there.
(In reply to Ali from comment #29)
> Yes I can confirm it's perfect again with media.ffvpx.enabled set to false.

It doesn't seem to do the trick on my end. I still see frames missing.
(In reply to Ali from comment #29)
> Yes I can confirm it's perfect again with media.ffvpx.enabled set to false.

Works for me too.
(In reply to Jean-Yves Avenard [:jya] from comment #30)
> well, i see stutter regardless of the version I use, and same effects on
> chrome.
> It's very subtle, few frames dropped here and there.

With my system it's a constant stutter but YouTube reports no dropped frames. Perhaps unique to the GTX 970?
Assignee: nobody → jyavenard
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
In libavcodec 58 and later, the old avcodec_decode_video2 is broken and only return the first visible frame found after a VP9 super-frame.

This resulted in some YouTube videos for about 10% of the frames to never be returned.

Only the new API properly behaves so we upgrade our code to use it.
It's fixed for me with ffvpx enabled on the win64 build.

I appreciate the time you've spent solving the issue Jean-Yves, Thank you!
Yeah, thanks a lot Jean-Yves!
Attachment #9031701 - Attachment description: Bug 1513511 - Use new FFmpeg decode API with recent FFmpeg version. r?bryce → Bug 1513511 - P1. Use new FFmpeg decode API with recent FFmpeg version. r?bryce
vp9 streams contains superframes. Ensure they are all properly handled.

Depends on D14682
Blocks: 1514795
Pushed by jyavenard@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/cc808bf2a954
P1. Use new FFmpeg decode API with recent FFmpeg version. r=bryce
https://hg.mozilla.org/integration/autoland/rev/240e8dcfe721
P2. Ensure all frames are decoded. r=bryce
https://hg.mozilla.org/mozilla-central/rev/cc808bf2a954
https://hg.mozilla.org/mozilla-central/rev/240e8dcfe721
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla66
The fix is now available in Firefox latest Nightly : https://www.mozilla.org/en-US/firefox/channel/desktop/

Thank you for confirming that it works for you
Is this something we can safely consider uplifting to Beta?
Flags: needinfo?(jyavenard)
(In reply to Ryan VanderMeulen [:RyanVM] from comment #43)
> Is this something we can safely consider uplifting to Beta?

Yes, I had hoped to hear from people that things got better
Flags: needinfo?(jyavenard)
Comment on attachment 9031701 [details]
Bug 1513511 - P1. Use new FFmpeg decode API with recent FFmpeg version. r?bryce

[Beta/Release Uplift Approval Request]

Feature/Bug causing the regression: Bug 1488065

User impact if declined: Playing youtube videos will shows around 10% of frames dropped

Is this code covered by automated tests?: Yes

Has the fix been verified in Nightly?: Yes

Needs manual test from QE?: Yes

If yes, steps to reproduce: Please the YT vidéos mentioned in the comment, slow playback speed to 0.25X

With the fix, counting shouldn't pause and be smooth.

Without the fix, you can see regular small pauses as some frames aren't composited

List of other uplifts needed: None

Risk to taking this patch: Low

Why is the change risky/not risky? (and alternatives if risky): This is a new ffmpeg api, however the old one were using is a wrapper around that API

String changes made/needed: None
Attachment #9031701 - Flags: approval-mozilla-beta?
(In reply to Jean-Yves Avenard [:jya] from comment #41)
> The fix is now available in Firefox latest Nightly :
> https://www.mozilla.org/en-US/firefox/channel/desktop/
> 
> Thank you for confirming that it works for you

I cannot reproduce the bug anymore with the latest nightly on both of my linux machines.

Thank you very much.
Comment on attachment 9031701 [details]
Bug 1513511 - P1. Use new FFmpeg decode API with recent FFmpeg version. r?bryce

Fix confirmed by user report, let's uplift to beta 65.
Attachment #9031701 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Blocks: 1488065
Could this fix be considered for uplift for the next 64.0.X release ? It's quite an annoying bug to have since end of January.
Flags: qe-verify+
(In reply to Ge3k0s from comment #49)
> Could this fix be considered for uplift for the next 64.0.X release ? It's
> quite an annoying bug to have since end of January.

It will be considered for uplift for 64.0.1 after January 1st, 2019.

However may I suggest you use Firefox Nightly? If we had more users on this channel, bug such as this would have been identified earlier on and wouldn't have made it to release.
We need the help of people such as yourself to make Firefox even better.
Thank you.
(In reply to Jean-Yves Avenard [:jya] from comment #50)
> (In reply to Ge3k0s from comment #49)
> > Could this fix be considered for uplift for the next 64.0.X release ? It's
> > quite an annoying bug to have since end of January.
> 
> It will be considered for uplift for 64.0.1 after January 1st, 2019.
> 
> However may I suggest you use Firefox Nightly? If we had more users on this
> channel, bug such as this would have been identified earlier on and wouldn't
> have made it to release.
> We need the help of people such as yourself to make Firefox even better.
> Thank you.

Thanks for the fix. Nice to hear about the uplift. I used to have Firefox Nightly as my main browser and I tested it for years, but for stability concerns I now generally prefer to use released software.
I’ve managed to observe this issue, using the video  provided in comment 25 - https://www.youtube.com/watch?v=lG5LZNhfyGM, with Release 64.0 (20181206201918) on Windows 10 x64 and Ubuntu 18.04 x64. 
I’m no longer able to reproduce it on the latest Beta - 65.0b6 (20181220174318) / Nightly - 66.0a1 (20181223215209) builds on Windows 10 x64, macOS 10.13 and Ubuntu 18.04 x64.
Status: RESOLVED → VERIFIED
Flags: qe-verify+

Comment on attachment 9031701 [details]
Bug 1513511 - P1. Use new FFmpeg decode API with recent FFmpeg version. r?bryce

[Beta/Release Uplift Approval Request]

Feature/Bug causing the regression: Bug 1488065

User impact if declined: High number of frames while IN YouTube won't be decoded.

Is this code covered by automated tests?: Yes

Has the fix been verified in Nightly?: Yes

Needs manual test from QE?: No

If yes, steps to reproduce: In description and other messages

List of other uplifts needed: None

Risk to taking this patch: Medium

Why is the change risky/not risky? (and alternatives if risky): It's been going in beta and nightly for over a month

String changes made/needed: None

Attachment #9031701 - Flags: approval-mozilla-release?

Comment on attachment 9031701 [details]
Bug 1513511 - P1. Use new FFmpeg decode API with recent FFmpeg version. r?bryce

fix an issue on youtube, verified in 65/66, approved for 64.0.2

Attachment #9031701 - Flags: approval-mozilla-release? → approval-mozilla-release+
Flags: qe-verify+

I can confirm the fix also on Release 64.0.2 (20190108160530) with Windows 10 x64, Ubuntu 16 x86 and macOS 10.14.

Flags: qe-verify+

Mac OS 10.11.6 "El Capitan"
Firefox 64.0.2

2 PROBLEMS REMAIN:

YouTube video's progress area (showing the Pause button, Speaker icon, etc.) at the bottom of the video frame, flickers / stutters - when mouse arrow hovering over the video frame area - while the video is playing.

There is also an inital flickering / stuttering of the whole video frame area --- IF a video (motion) is playing in the whole video frame area --- for a period of roughly 3 seconds . . . when the video begins to play, and, whether or not the mouse arrow is hovering over the video frame area.

BUT, IF there is merely a stable image in the videa frame area, no apparent flickering / stuttering (because, no motion) except for the bottom portion - the video's progress area showing the Pause button, Speaker icon, etc.


Test: Aretha Franklin - Until You Come Back to Me:
https://www.youtube.com/watch?v=bJZwcaWResA

Stats for nerds:
Video ID / sCPN: bJZwcaWResA / MGHW 6C3R KD5X
Viewport: 707x530
Current / Optimal Res: 640x480@25 / 640x480@25
Volume / Normalized: 100% / 56% (content loudness 5.1dB)
Codecs: vp09.00.51.08.01.01.01.01 (244) / opus (251)
Host: r3--sn-n4v7knlz
Connection Speed: (it is a horizontal bar graph)
Network Activity: (it is a horizontal bar graph)
Buffer Health: (it is a horizontal bar graph)
Dropped Frames: 0/904 (when I took a screenshot - to be transcribed, herein)

Please file a separate bug for comment 57.

You need to log in before you can comment on or make changes to this bug.