Youtube stuttering in 64, fine in 63
Categories
(Core :: Audio/Video: Playback, defect, P2)
Tracking
()
People
(Reporter: ali.nz2005, Assigned: jya)
References
(Blocks 1 open bug)
Details
Attachments
(2 files)
47 bytes,
text/x-phabricator-request
|
lizzard
:
approval-mozilla-beta+
jcristau
:
approval-mozilla-release+
|
Details | Review |
47 bytes,
text/x-phabricator-request
|
Details | Review |
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.
Updated•5 years ago
|
Assignee | ||
Comment 1•5 years ago
|
||
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.
Assignee | ||
Updated•5 years ago
|
Assignee | ||
Comment 3•5 years ago
|
||
(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
Assignee | ||
Comment 5•5 years ago
|
||
(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.
Assignee | ||
Comment 8•5 years ago
|
||
(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.
Assignee | ||
Comment 10•5 years ago
|
||
(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.
Assignee | ||
Comment 11•5 years ago
|
||
(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.
Comment 12•5 years ago
|
||
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....
Assignee | ||
Comment 13•5 years ago
|
||
(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.
Comment 14•5 years ago
|
||
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
Assignee | ||
Comment 15•5 years ago
|
||
(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.
Comment 17•5 years ago
|
||
(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.
Reporter | ||
Comment 18•5 years ago
|
||
(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.
Comment 19•5 years ago
|
||
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
Assignee | ||
Comment 20•5 years ago
|
||
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.
Comment 21•5 years ago
|
||
Mark this one as P2 for now, feel free to change priority.
Assignee | ||
Comment 22•5 years ago
|
||
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?
Comment 23•5 years ago
|
||
(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...
Reporter | ||
Comment 24•5 years ago
|
||
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.
Reporter | ||
Comment 25•5 years ago
|
||
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.
Comment 26•5 years ago
|
||
(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!
Comment 27•5 years ago
|
||
So bug 1488065 seems to be the culprit.
Assignee | ||
Comment 28•5 years ago
|
||
(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?
Reporter | ||
Comment 29•5 years ago
|
||
Yes I can confirm it's perfect again with media.ffvpx.enabled set to false.
Assignee | ||
Comment 30•5 years ago
|
||
(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.
Comment 31•5 years ago
|
||
(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.
Comment 32•5 years ago
|
||
(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.
Reporter | ||
Comment 33•5 years ago
|
||
(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 | ||
Updated•5 years ago
|
Updated•5 years ago
|
Assignee | ||
Comment 34•5 years ago
|
||
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.
Assignee | ||
Comment 35•5 years ago
|
||
Could anyone try those build with the proposed fix: macos: https://queue.taskcluster.net/v1/task/P5AIOvtcRtSKcz2oh7dMNg/runs/0/artifacts/public/build/target.dmg win32: https://queue.taskcluster.net/v1/task/ZKFtnzXyTVKQh2evURaJyQ/runs/0/artifacts/public/build/install/sea/target.installer.exe win64: https://queue.taskcluster.net/v1/task/L3zcDtc4REuI0DR_PBD0qw/runs/0/artifacts/public/build/install/sea/target.installer.exe linux64: https://queue.taskcluster.net/v1/task/FnE3zI2VQZew06Zke9LPZA/runs/0/artifacts/public/build/target.tar.bz2 It will not override your existing Firefox installation.
Reporter | ||
Comment 36•5 years ago
|
||
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!
Comment 37•5 years ago
|
||
Yeah, thanks a lot Jean-Yves!
Updated•5 years ago
|
Assignee | ||
Comment 38•5 years ago
|
||
vp9 streams contains superframes. Ensure they are all properly handled. Depends on D14682
Updated•5 years ago
|
Comment 39•5 years ago
|
||
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
Comment 40•5 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/cc808bf2a954 https://hg.mozilla.org/mozilla-central/rev/240e8dcfe721
Assignee | ||
Comment 41•5 years ago
|
||
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
Comment 43•5 years ago
|
||
Is this something we can safely consider uplifting to Beta?
Assignee | ||
Comment 44•5 years ago
|
||
(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
Assignee | ||
Comment 45•5 years ago
|
||
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
Comment 46•5 years ago
|
||
(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 47•5 years ago
|
||
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.
Updated•5 years ago
|
Updated•5 years ago
|
Comment 48•5 years ago
|
||
bugherder uplift |
https://hg.mozilla.org/releases/mozilla-beta/rev/c94560ceb417 https://hg.mozilla.org/releases/mozilla-beta/rev/a475f96d7472
Comment 49•5 years ago
|
||
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.
Updated•5 years ago
|
Assignee | ||
Comment 50•5 years ago
|
||
(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.
Comment 51•5 years ago
|
||
(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.
Comment 52•5 years ago
|
||
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.
Assignee | ||
Comment 53•5 years ago
|
||
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
Comment 54•5 years ago
|
||
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
Comment 55•5 years ago
|
||
bugherder uplift |
Updated•5 years ago
|
Comment 56•5 years ago
|
||
I can confirm the fix also on Release 64.0.2 (20190108160530) with Windows 10 x64, Ubuntu 16 x86 and macOS 10.14.
Comment 57•5 years ago
|
||
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)
Comment 58•5 years ago
|
||
Please file a separate bug for comment 57.
Description
•