Random microstuttering on YouTube videos
Categories
(Core :: Graphics, defect)
Tracking
()
People
(Reporter: sworddragon2, Unassigned)
References
(Blocks 1 open bug)
Details
Steps to reproduce:
- Go to https://www.youtube.com/watch?v=FYCjJHhxONc .
- On the video player set the video quality manually to the best quality.
- Watch the video and/or repeat watching on smooth animations (e.g. repeating a few times from ~1:56 to ~2:01 works for me well).
Actual results:
Every few seconds microstuttering appears that lasts for roughly 0.5-2 seconds.
Expected results:
The videos should play smoothly.
Additional details:
- A Phenom II X6 1045T as CPU and a GeForce GTX 1650 as GPU (driver version 516.59) on Windows 10 version 21H2 (64 bit) are being used.
- On looking through about:support I see 2 entries that might be releated to this issue:
VIDEO_OVERLAY blocked by default: Blocklisted by gfxInfo
HW_DECODED_VIDEO_ZERO_COPY blocked by default: Blocklisted by gfxInfo - This issue is pretty much the same as bug #1614083 which got fixed by changing the rate the bias gets updated from the rate of VSync to the frame rate of the video.
The reason I found the very same issue again was because I noticed microstuttering while scrolling with the mousewheel (with smooth scrolling enabled) but I'm not sure if this issue is new or if it always existed and I just didn't notice the stuttering until now (this is also harder to reproduce). Out of curiosity I did test then if videos run smooth and just figured out the old issue from 2 years ago pretty much reproduces again as if the fix for it got straightforward reverted. Getting down to the issue in the old bug report was very horrible and I'm not sure if I would do this again here. My hope is that the 2 blocked video features are actually the culprit here (but unfortunately I do not know which settings enforce to enable them for testing) and I'm also a bit curious why they are blocked on my current setup (maybe just a significant bug was discovered in the most recent NVIDIA driver or such). Otherwise I'm even thinking about to just ignore this bug and sitting the issue out until it possibly fixes randomly in eventually ~1-2 years.
|
||
Comment 1•2 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Graphics' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
|
Reporter | |
Comment 2•2 years ago
|
||
Well, since the old bug has the target milestone set to version 80 and I did confirm the old bug being fixed after testing it in the past already I just did now a bisect via mozregression-gui by setting the target release to version 80 and 102. This is what I got:
Bisecting on mozilla-central [2020-07-27 - 2022-05-30]
Tested mozilla-central build: 2021-06-28 (verdict: b)
Tested mozilla-central build: 2021-01-11 (verdict: b)
Tested mozilla-central build: 2020-10-19 (verdict: b)
Tested mozilla-central build: 2020-09-07 (verdict: b)
Tested mozilla-central build: 2020-08-17 (verdict: b)
Tested mozilla-central build: 2020-08-07 (verdict: b)
Tested mozilla-central build: 2020-08-02 (verdict: g)
Tested mozilla-central build: 2020-08-05 (verdict: b)
Tested mozilla-central build: 2020-08-04 (verdict: g)
When I repeated the video every few seconds via the STR from comment #0 I observed something interesting on every build that has being flagged as bad here: Within the ~first minute the video did run mostly smooth, then single stutters appeared that I would normally classify as bug #1652540 and then a few seconds after this a series of microstuttering happened all the time and the issue looked like bug #1614083. That those builds did run fine within the first minute made me uncertain if I should flag them as good or bad. But when I encountered a good build I did test it a few minutes longer to make sure it was indeed fine. The 2 good builds listed above did run very smooth with just a few very rare single stutters that I would count towards bug #1652540 so this seems fine.
So the last good build is 2020-08-04 and the first bad build is 2020-08-05 (mozregression-gui could no bisect further). What is quite interesting is when I switched back to the productive version (release 102.1) with my current profile the series of microstuttering is significantly worse than in all the bad builds. There is no safety-minute at all where it runs smooth and the series of microstuttering happens on every try - they are pretty much constantly omnipresent.
|
|
Reporter | |
Comment 3•2 years ago
|
||
I also did now test on a new profile on Firefox version 102.0.1 to see if this has any effect: The stuttering still appears all the time and there is no safety-minute but it looked slightly better than with my used profile. But the difference would be not so big so this is actually difficult to tell but overall it can be sayed the issue appears with a new profile as well.
But when I was in about:support on a new profile I noticed something strange: The sample rate for the audio was set to 48000 Hz while on my used profile it is 44100 Hz. This is quite suspicious since all listed output devces have a default sample rate of 48000 Hz and they also only support 48000 Hz. My first thought was if privacy.resistFingerprinting=true causes this issue but it would not make much sense and probably be even dangerous to spoof values in Firefox's own internal windows. But setting privacy.resistFingerprinting=false did indeed cause the sample rate to change back to 48000 Hz. Maybe privacy.resistFingerprinting does not just spoof the value here and changes it instead. But I assume this issue might have a low chance to be related somehow to the stuttering but I didn't want to let it unmentioned.
|
||
Comment 4•2 years ago
|
||
Is there more output or logging from mozregression? It might look something like https://hg.mozilla.org/mozilla-central/rev/2d291a99004d or 2d291a99004d
|
||
Updated•2 years ago
|
|
|
Reporter | |
Comment 5•2 years ago
|
||
Unfortunately I already closed mozregression-gui and cleaned up its folder it placed somewhere around or in %appdata% . But if mozregression-gui did only check one build for 2020-08-05 and 2020-08-04 and refused then to go further (due to claiming about missing builds that could get a closer commit-range) shouldn't it be possible to just check the server what commit these two dated builds point to?
But even if so I assume the commit-range would be to big if mozregression-gui has a resolution of ~1 day for too old builds (wasn't there a 1 year limit ot such? I vaguely remember something like that from another bugreport some years ago - but correct me if I'm wrong).
|
|
||
Comment 6•2 years ago
|
||
There are two builds for every day. So without knowing which build mozregression used I can narrow it down using the widest possible range for those two build dates.
|
|
Reporter | |
Comment 7•2 years ago
|
||
(In reply to Timothy Nikkel (:tnikkel) from comment #6)
There are two builds for every day.
Which means when mozregression-gui could determine the last known good build as 2020-08-04 and the first bad build as 2020-08-05 without being able to narrow it down further due to missing builds it can only be the last build of 2020-08-04 and the first build of 2020-08-05 as otherwise we would see for both either 2020-08-04 or 2020-08-05.
But yes I could have been more thoughtful and instead of simply copying the output of the main window also checking the verbose output in the pane below it if it would contain some useful information as well - sorry if I caused some troubles here. But also having an identifier in each listed tested entry like the commit hash could have been useful here - but that would be a feature request for mozregression-gui.
|
|
||
Comment 8•2 years ago
|
||
You didn't cause any problems here. If my words are terse it's just because I'm saying the minimum words to get a message across, apologies.
(In reply to sworddragon2 from comment #7)
(In reply to Timothy Nikkel (:tnikkel) from comment #6)
There are two builds for every day.
Which means when mozregression-gui could determine the last known good build as 2020-08-04 and the first bad build as 2020-08-05 without being able to narrow it down further due to missing builds it can only be the last build of 2020-08-04 and the first build of 2020-08-05 as otherwise we would see for both either 2020-08-04 or 2020-08-05.
I'm not sure we can conclude that. I don't know mozregression internals but sometimes it surprises me. Since mozregression only tested one build per day that would mean it picked the early build for one day and the late build for the other. That would seem surprising. I would expect it to pick either consistently the early or late build each day until it had it narrowed down enough to pick otherwise, but I don't know for sure.
But yes I could have been more thoughtful and instead of simply copying the output of the main window also checking the verbose output in the pane below it if it would contain some useful information as well - sorry if I caused some troubles here. But also having an identifier in each listed tested entry like the commit hash could have been useful here - but that would be a feature request for mozregression-gui.
It's not on you at all, I was simply asking if you had it as it would help things here. I've had this problem with mozregression before and I would like it if it produced this output by default.
|
||
Comment 9•2 years ago
|
||
(In reply to sworddragon2 from comment #3)
I also did now test on a new profile on Firefox version 102.0.1 to see if this has any effect: The stuttering still appears all the time and there is no safety-minute but it looked slightly better than with my used profile. But the difference would be not so big so this is actually difficult to tell but overall it can be sayed the issue appears with a new profile as well.
But when I was in about:support on a new profile I noticed something strange: The sample rate for the audio was set to 48000 Hz while on my used profile it is 44100 Hz. This is quite suspicious since all listed output devces have a default sample rate of 48000 Hz and they also only support 48000 Hz. My first thought was if privacy.resistFingerprinting=true causes this issue but it would not make much sense and probably be even dangerous to spoof values in Firefox's own internal windows. But setting privacy.resistFingerprinting=false did indeed cause the sample rate to change back to 48000 Hz. Maybe privacy.resistFingerprinting does not just spoof the value here and changes it instead. But I assume this issue might have a low chance to be related somehow to the stuttering but I didn't want to let it unmentioned.
Does privacy.resistFingerprinting=false fix the stuttering? Or change it at all?
|
|
Reporter | |
Comment 10•2 years ago
|
||
When testing with a new profile except for maximizing the window geometry I have not changed any settings so yes, the issue does still appear then.
|
|
||
Comment 11•2 years ago
|
||
The severity field is not set for this bug.
:aosmond, could you have a look please?
For more information, please visit auto_nag documentation.
|
|
||
Comment 12•2 years ago
|
||
@sworddragon2:
Can you attach an copy of your about:support?
I don't see this locally, so definitely sounds like something about your machine configuration, since you mentioned it still happens with a fresh profile.
about:support might shed some light on things, we can hope!
There is also an about:config override for enabling hardware overlays that you can try: gfx.webrender.dcomp-video-overlay-win-force-enabled
|
|
Reporter | |
Comment 13•2 years ago
|
||
I fear I have to pass on that one and give up this ticket.
Digging down to the cause will very likely require a lot amount of effort while I'm very busy all the time and can't afford this anymore sadly. Also I sort of expect even if this issue will be solved likely another regression will be introduced some months after so there is probably not too much point doing something here. This is kind of also true as long as more basic things are still unfixed ( for example bug #1652540 ) but it is very unlikely that this will change in the near- or mid-future, eventually this is also true for the far-future.
Still, thanks for trying to help solving this issue but feel free to close it - I just accept that Firefox on my system just won't run fine on video decoding/rendering.
Description
•