Open Bug 1684662 Opened 3 years ago Updated 6 months ago

WMF VP9 hardware decoding looks stuttery vs. software decoding

Categories

(Core :: Graphics, defect)

Product:
Core
Component:
Graphics
Version:
Firefox 85
Platform:
All
Windows 10
Type:
defect

Tracking

()

People

(Reporter: tempel.julian, Assigned: jrmuizel, NeedInfo)

References

(Blocks 1 open bug)

Details

(Whiteboard: [media-youtube])

Attachments

(3 files)

about:support data
32.70 KB, text/plain
Details
stutter.mkv
6.57 MB, application/octet-stream
Details
stutter slowed down.mkv
3.14 MB, application/octet-stream
Details
Attached file about:support data —

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

Steps to reproduce:

Set display to perfect 60Hz (e.g. custom resolution) and verify via www.vsynctester.com. It should measure something like 60.000xxHz.

Then play this exact 60fps video (no matter if 4k, 1440p, windowed or fullscreen):
https://www.youtube.com/watch?v=aqz-KE-bpKQ

Actual results:

Playback looks choppy, despite YouTube statistics not reporting any dropped frames. It really ruins the watching experience.

Happens with both 85.0b4 and recent 86 Nightly (and probably every previous version).

Expected results:

It should look smooth. It does so when setting media.wmf.vp9.enabled = false (or use VAAPI hardware decoding on Linux Xorg). It also looks smooth in Windows Movie App and Chrome/Edge. There is only one GPU active in the system which is the Radeon RX 5700 XT, it can decode VP9 fully in hardware.

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Component: Untriaged → Audio/Video: Playback
Product: Firefox → Core

Hi,
I can't reproduce this issue on my Dell XPS 15 Windows 10. Could you help me do following some testing to see what happen on 60fps video?
(1) Enable media.wmf.vp9.enabled and disable media.hardware-video-decoding.enabled
(2) Enable media.wmf.vp9.enabledand media.hardware-video-decoding.enabled, but disable media.rdd-process.enabled
(3) Enable media.wmf.vp9.enabled, media.hardware-video-decoding.enabled, media.rdd-process.enabled but disable media.gpu-process-decoder

In addition, could you help me use profiler to profile the process when the issue happens?

Thank you so much.

Severity: -- → S3
Flags: needinfo?(tempel.julian)
Whiteboard: [media-youtube]

(1) Does not stutter.
(2) and (3) stutter.

Profiling data with media and graphics presets:
https://share.firefox.dev/38iYIuc
https://share.firefox.dev/394SAVJ

Flags: needinfo?(tempel.julian)

Hi, Markus,
Would you mind to help me check the profile result in comment3 to see if there is any thing weird or suspicious in the graphic stack?
In media side, I saw that we pushed video constantly to the compositor (see MediaDecoderStateMachine thread and check the marker chart), which looks quite normal.
Thank you.

Flags: needinfo?(mstange.moz)

I wonder if this issue would happen on non-60fps video as well?
Thank you.

Flags: needinfo?(tempel.julian)

Yes, this 30fps video also shows constant stuttering with media.wmf.vp9.enabled = true, whereas = false is fine:
https://www.youtube.com/watch?v=onOEns_MnC4

Flags: needinfo?(tempel.julian)

Bryce (who will be back soon and know more about WMF than I), do you have any thought about this? So the stuttering would happen when the reporter turns on the hardware decoding, is that possible a graphic driver issue?
Thank you.

Flags: needinfo?(bvandyk)

Playback btw. is smooth when enforcing H.264 codec via h264ify extension. Video resolution then is limited to a maximum of 1080p though.

We've seen reports like this in the past, such as bug 1530083. We've been adding profiler markers to try and help identify what's going on in cases like this -- in some cases we see decoders being recreated which leads to issues, but that doesn't appear to be happening based on the profile here. So I'm not sure and will consider further diagnostics we can do.

Flags: needinfo?(bvandyk)
Priority: -- → P3
See Also: → 1530083

(In reply to walmartguy from comment #3)

Profiling data with media and graphics presets:
https://share.firefox.dev/38iYIuc
https://share.firefox.dev/394SAVJ

This is puzzling. The profiles make it look like everything is perfectly smooth all the time: https://share.firefox.dev/3i9YjO0
The composites on the renderer thread are also really quick.

I'm really not sure what could be happening. Maybe we're getting confused about what's in the video frame? E.g. we might be displaying frame 45 but it already has content from frame 46, because something gets confused with decoding buffer management in the hardware decoding path?

Flags: needinfo?(mstange.moz)
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Unspecified → Windows 10
Hardware: Unspecified → All

Could you get another profile with "Screenshots" enabled? Pick the Custom preset, go to Edit Settings, and find the checkbox.
Maybe this will let us see whether the problem is before compositing or after compositing.

Flags: needinfo?(tempel.julian)

https://share.firefox.dev/3qjp6uu
No idea if it makes a difference for the data, but this was with 85Hz display. Despite of the mismatch of 60fps video and 85Hz display, the issue is still very recognizable while watching the video.

Flags: needinfo?(tempel.julian)

Sorry to ask again, but could you capture another profile with a different video? For example https://www.youtube.com/watch?v=YI3tsmFsrOg
In the Big Buck Bunny movie the motions in the beginning sequence are very subtle and I'm having a hard time being sure whether the frame that we put on the screen has updated or not. For example, in this range: https://share.firefox.dev/38Hsucg the frame number advances by 20 frames but what's on the screen looks like it doesn't change at all.

Flags: needinfo?(tempel.julian)

That video is offered only as AV1.
I gave this one (VP9) a try, should be optimal to spot any irregular video frame presentation:
https://www.youtube.com/watch?v=_gBBz7IMz1Y

https://share.firefox.dev/3oHNEwK

Flags: needinfo?(tempel.julian)

Perfect, thanks! That's indeed a much better video to test with.

It looks like the video frame updates as expected. The line moves every time we think it should have moved. This throws my earlier hypothesis of a broken decoder buffer management out of the window.
So then this means that the problem happens somewhere after our compositing. Maybe we're submitting frames at a time at which it's hard for the window manager to hit the vsync deadline consistently?

(To see the video frame update properly, I had to fix the hover screenshot position in the profiler with the rule .timelineTrackScreenshotHover { left: 200px !important; }, because otherwise the horizontal motion in the video is hard to see in a horizontally-moving screenshot preview.)

(In reply to walmartguy from comment #12)

Despite of the mismatch of 60fps video and 85Hz display, the issue is still very recognizable while watching the video.

Could you clarify what you mean by this? There's naturally going to be stutter when there's a mismatch. Are you seeing skipped frames?

I tried reproducing this on my Windows machine but I don't think I'm getting hardware decoding. (Edit: It's because my GPU, an AMD Radeon R9 390, doesn't support VP9 decoding.)

(In reply to Markus Stange [:mstange] from comment #15)

Could you clarify what you mean by this? There's naturally going to be stutter when there's a mismatch. Are you seeing skipped frames?

Well, I'm aware that there are naturally repeated frames when playing a 60fps video with 85Hz. However, the VP9 hardware decoding playback looks so bad that I can easily notice the weird stutter that is also present with 60Hz. When playing the 60fps video at 85Hz without hardware decoding, it looks better than the playback of 60fps @60Hz with hardware decoding. :( (whereas 60fps @60Hz without hardware decoding were perfect).
I was just wondering if the 85Hz also have implications for the screenshot option of the profiler.

Ah, I see, thanks.

From the media's perspective, the profiled result in comment looks also pretty good to me, we didn't drop any frame and as Markus said in comment 15, the actual problem might happen after the composition.

Therefore, I will move this bug to gfx to raise more attention from them, to see if anyone from gfx team can help move this bug forward.

Component: Audio/Video: Playback → Graphics

The component has been changed since the backlog priority was decided, so we're resetting it.
For more information, please visit auto_nag documentation.

Priority: P3 → --

Issue is unchanged with 86 b1 and AMD driver 21.1.1. When I capture Firefox' window content via obs-studio, the stutter is clearly visible in the captured video (played locally), whereas it's smooth when Firefox uses software decoding.

For what it's worth, this also happens with nVidia Ampere GPUs and current drivers on Windows 10.

Hi,
I have the same issue, my GPU is RX 6900 XT. What I want to add is that this stuttering affects not only the video, but the entire browser. It is visible while scrolling etc, can easily confirm by going to https://testufo.com/ while playing back the VP9 YouTube video in other tab (doesn't have to be visible). This happens even with 1080p VP9 videos (albeit sturreting is less apparent), doesn't happen with h264 videos and/or with hardware decoding disabled.

Any update on this? The stutter is so bad, it surely would make more sense to disable VP9 hardware decoding for many systems instead of having stutter everywhere.

The issue has not disappeared by itself with Windows 11, it's still as bad as ever.

Since the initial profile run involving this, we've added further data collection to the profiler. Capturing and sharing another Firefox profiler run (using the 'Media' preset) would be useful to see if the new information helps shed any extra light on what's going on with this.

At a closer look, the original issue actually seems to have vanished. Playback of Big Buck Bunny 4k 60fps on YouTube VP9 is now smooth with 60Hz in 94b9, as long as the Nvidia driver is set to maximum performance (i.e. doesn't clock below minimal boost clock). I've found this out by chance, as Edgium showed the same issue, which was odd, though to a lesser extent.

This is not what this issue originally was about. Maybe it was a WMF bug all along, who knows. I'll try to test with an Intel GPU that should be fast enough to ensure stutter free playback.

FYI, here on Windows 11 Firefox 93 with an AMD GPU issue still occurs. I think originally the issue was also reported with an AMD GPU? Considering the issue doesn't occur with an NVIDIA GPU, it's possible the issue is specific to AMD GPUs (or even only AMD RDNA GPUs).

Indeed I initially had an RDNA2 GPU and didn't re-check right away with GPU maximum performance power profile when I first installed the Nvidia GPU. There (sadly) is no such toggle in the Radeon Windows driver, but I tried whether it makes a difference when I keep the GPU at constantly higher clocks via some mild 3D/compute load in the background. Well, it didn't.
Thanks for re-checking with Radeon!

Funny thing is with Nvidia default GPU power saving enabled, the YT 4k 60fps VP9 judder test video doesn't show stutter, but Big Buck Bunny 4k does. Maybe the lower bitrate or less screen regions updated are the reasons why the judder test video doesn't trigger it. Highly intricate...

Fresh capture using profiler "Media" preset: https://share.firefox.dev/3CxBHAC
during playback of this 4k 60fps VP9 video: https://www.youtube.com/watch?v=LXb3EKWsInQ
stutter is visible all the time.

SW: Nightly 95.0a1 20211031095403, Windows 11 22000.282, Radeon 21.10.4
HW: AMD R9 5950x, AMD RX 6900 XT, 4K 120 Hz display

By checking the profiled result in comment31, the media part looks no problem. For a 60fps video, one frame takes 1/60~=0.166(s)=16.66(ms) and the decoding performed really fast on the reporter's computer. You can check RequestDecode:V:1440<h<=2160:hw,vp9, on the MediaSupervisor thread and most decoding tasks took under 1ms (a lots are around 200~300 us). Also, on the MediaDecoderStateMachine thread, I didn't see any drop frame markers, and the video sink played video smoothly and correctly.

However, I also didn't see the drop frames marker on the compositor side. I would like to ask gfx folks for a further investigation. In addition, on the Compositor thread, I saw a lot of skippedComposite markers. Not sure if that is related.

Blocks: gfx-triage

On that 4k 60fps video you mentioned on comment31, how many frames drop you could see via youtube's Stats for Nerds?
Thank you.

Flags: needinfo?(mail)

I agree, the profile does not indicate a performance issue. So it could be a "bug" issue.

Comment 15 still has my latest thoughts on this:

(In reply to Markus Stange [:mstange] from comment #15)

[...] This throws my earlier hypothesis of a broken decoder buffer management out of the window.
So then this means that the problem happens somewhere after our compositing. Maybe we're submitting frames at a time at which it's hard for the window manager to hit the vsync deadline consistently?

Jeff, do you have a machine that reproduces this?

Flags: needinfo?(jmuizelaar)
Attached file stutter.mkv —

example of stutter during VP9 video playback

example of stutter during VP9 video playback (slowed down)

(In reply to Alastor Wu [:alwu] from comment #33)

On that 4k 60fps video you mentioned on comment31, how many frames drop you could see via youtube's Stats for Nerds?
Thank you.

Amount of dropped frames is very low, 1~10 of 10000+

If this would be of any use to further illustrate the issue, I've recorded a short 480fps clip of website testufo.com during the playback, see https://bugzilla.mozilla.org/attachment.cgi?id=9248924
and slowed down 16 times https://bugzilla.mozilla.org/attachment.cgi?id=9248925

Looks like some frames are basically skipped? Curiously the website doesn't detect the vsync timing issue.

Flags: needinfo?(mail)

(In reply to Bartosz Nowak from comment #38)

Looks like some frames are basically skipped? Curiously the website doesn't detect the vsync timing issue.

Very interesting. The website probably can't detect the issue for the same reason that the profiler can't detect it - on the Firefox side, everything is looking good, and the problem happens somewhere further down the stack, after Firefox has submitted the frame to the GPU.

I'm not sure testufo.com is actually comparable, since it's not video playback (afaik) and the VP9 video stutter issue is gone without hardware decoding. So in case of testufo.com, it might just be GPU not clocking up aggressively enough.

I used testufo.com to better illustrate this issue - VP9 video is playing in a second window. The main issue here is that the entire browser is stuttering, in all windows/tabs, not just the video.

I don't have AMD hardware that can decode VP9

It would be very interesting if someone could capture a gpuview trace of the stuttering happening. See https://github.com/servo/webrender/wiki/Debugging-WebRender#gpuview for instructions. If you're not comfortable with posting a link to the trace publicly you can email it to me at jmuizelaar@mozilla.com.

Flags: needinfo?(jmuizelaar)

(In reply to Jeff Muizelaar [:jrmuizel] from comment #42)

I don't have AMD hardware that can decode VP9

It would be very interesting if someone could capture a gpuview trace of the stuttering happening. See https://github.com/servo/webrender/wiki/Debugging-WebRender#gpuview for instructions. If you're not comfortable with posting a link to the trace publicly you can email it to me at jmuizelaar@mozilla.com.

Collected and uploaded gpuview trace here https://mega.nz/file/eJJQkLRQ#JZS0BftSJmZ4AIXQftlUod7NJXjKPU48ZpDKny0mOTA

Let me know if you need more info.

(In reply to Bartosz Nowak from comment #43)

(In reply to Jeff Muizelaar [:jrmuizel] from comment #42)

I don't have AMD hardware that can decode VP9

It would be very interesting if someone could capture a gpuview trace of the stuttering happening. See https://github.com/servo/webrender/wiki/Debugging-WebRender#gpuview for instructions. If you're not comfortable with posting a link to the trace publicly you can email it to me at jmuizelaar@mozilla.com.

Collected and uploaded gpuview trace here https://mega.nz/file/eJJQkLRQ#JZS0BftSJmZ4AIXQftlUod7NJXjKPU48ZpDKny0mOTA

Let me know if you need more info.

That's great. Was this trace recorded with a VP9 video and testufo.com running? What video were you playing and at what frame rate?

Can you also get a gpuview trace of Chrome doing the same thing?

Flags: needinfo?(mail)

Also, it looks like you're running at 120Hz. Is the stutter reduced/eliminated if you run at 60Hz?

(In reply to Jeff Muizelaar [:jrmuizel] from comment #44)

(In reply to Bartosz Nowak from comment #43)

(In reply to Jeff Muizelaar [:jrmuizel] from comment #42)

I don't have AMD hardware that can decode VP9

It would be very interesting if someone could capture a gpuview trace of the stuttering happening. See https://github.com/servo/webrender/wiki/Debugging-WebRender#gpuview for instructions. If you're not comfortable with posting a link to the trace publicly you can email it to me at jmuizelaar@mozilla.com.

Collected and uploaded gpuview trace here https://mega.nz/file/eJJQkLRQ#JZS0BftSJmZ4AIXQftlUod7NJXjKPU48ZpDKny0mOTA

Let me know if you need more info.

That's great. Was this trace recorded with a VP9 video and testufo.com running? What video were you playing and at what frame rate?

I collected the trace with only a single FF window with playback of this video from around 1:04 to 1:34 https://www.youtube.com/watch?v=LXb3EKWsInQ at 4k 60fps VP9. This trace is without testufo.com, I only used it earlier to confirm the stutters visually, as it's more apparent with the constant panning on that website, sorry if that part got a bit confusing.

Can you also get a gpuview trace of Chrome doing the same thing?

gpuview trace on Chromium Version 97.0.4690.0 (Developer Build) (64-bit) - confirmed GPU video decoding with Task Manager, no stutters: https://mega.nz/file/rUpEwSrT#yWo57n6q3fLl5s5YhnNhTPNAs0bDsQDD1mrs93FHjrA

Also, it looks like you're running at 120Hz. Is the stutter reduced/eliminated if you run at 60Hz?

Tried with a single display connected at 60Hz and I'd say stutter is the same. Here's gpuview trace just in case: https://mega.nz/file/nEpikQpI#JXMDN3JO2cplVfk137Mjl7xOYon6GGVAaGFfhGUi_oE

All traces collected during the same scenario.

Flags: needinfo?(mail)

Bartosz, do you see stutter on the same video at lower resolutions?

Flags: needinfo?(mail)

(In reply to Jeff Muizelaar [:jrmuizel] from comment #47)

Bartosz, do you see stutter on the same video at lower resolutions?

1440p60/1080p60: way less stutter, barely visible, mostly during autoscrolling back and forth
720p60: no stutter, full smoothess
Every quality is VP9 + GPU video decoding in Task Manager

Flags: needinfo?(mail)

That was also my experience when I still had the RX 6800 installed, it was much worse with 4k video than with lower resolution video.

I can definitely see the stutter when comparing gpuview logs between Chrome and Firefox. Chrome is much more consistent in presenting frames. I'll try to figure out why.

One of the noticeable differences between Chrome and Firefox is that Chrome queues up two frames for decode every 33ms vs Firefox one frame every 16ms.

It could be that Chrome has a deeper pipeline and so can handle frames that take a long time to decode better than we can.

Here is my gpuview trace which is captured while I was playing vp9 60fps video for 30s (1:14:-1:44). I'm using Intel(R) UHD Graphics 630 for hw decoding and the video can be played smoothly without any stuttering. Hope this trace can be used as a comparison view to help to identify the problem.

Assignee: nobody → jmuizelaar
No longer blocks: gfx-triage

I had what I assume is the same or similar issue.

At 1080p 60fps or higher youtube playback, AV01 or VP9 (easier to see at 1440p and 2160p, doesn't appear at 720p) the frame pacing is inconsistent, appears as a jumping; easiest to see in panning shots, I've been using this scene from this video to test with: https://www.youtube.com/watch?v=zCLOJ9j1k2Y&t=242s

Trying to find a fix for this annoying stutter in high resolution 60fps Youtube videos, so I read this whole bug thread (and quite a few others), and tried some of the settings... only reliable fix was to disable hardware acceleration, and decode on the CPU... but it made no sense as the same video, played in Edge was working smoothly... My system is AMD 5800X3D with RX 6900 XT on Win 10 x64...

Found a thread (https://community.amd.com/t5/graphics/6900-xt-stuttering-with-youtube-4k60-videos/m-p/547930/highlight/true#M89178) on AMD forum where a user mentioned a setting: media.wmf.media-engine.enabled

I toggled this on, restarted Firefox and boom - no more jank

So for anyone struggling with this issue: try toggling media.wmf.media-engine.enabled to true

FYI that media.wmf.media-engine.enabled is still an experimental feature which will be used for DRM video on Windows in the future. Right now we're testing that by allowing using that in unencrypted video as well. But it's still not stable and might have many bugs.

Thank you Alastor, yes media.wmf.media-engine.enabled causes many issues; a green flash at start of playback on youtube videos, also starting playback and sometimes seeking is often highly delayed, the first second or more of video just doesn't display. Also many in-website videos that are NOT on youtube just don't work at all, or are totally scaled wrong, or play several minutes in one second then stop etc...

That said EVEN with those issues it's nice to enable (just when I'm on Youtube) - so I can enjoy smooth playback, hopefully the teams can find a way to make the normal video playback engine work as smoothly.

I trust there is enough information on this and related bugs to reproduce the issues with playback, if not I'm happy to contribute whatever I can.

BTW the green frame at the start of playback has been fixed in bug 1795507, we recently also fix other issues for the media engine playback. If you still see other issues while using the media engine, feel free to file bugs and set it block to bug 1752052, or NI me. Thank you so much.

In addition, for the normal video playback, would you mind help to capture a profile? Steps like following,

  1. Go to about:logging or about:networking#logging (if your Firefox hasn’t supported the former one)
  2. Type timestamp,PlatformDecoderModule:5,MediaFormatReader:5,MediaDecoder:5 in the second blank
  3. Click “Set Log Modules” (then you should see those modules’ name displaying below “Current Log Modules”)
  4. Go to https://profiler.firefox.com/
  5. Select “media” preset in the profiler's drop down menu
  6. Click “start recording” in the profiler's drop down menu
  7. Go to the site where you can reproduce the issue
  8. After issue happens, click “Capture” to end recording
  9. In the profiled result page, click “Upload Local Profile” which is on the top left
  10. Ensure all clicked boxes are clicked, and click “Upload”
  11. Paste the permanent link to bugzilla

Thank you so much!

Flags: needinfo?(gaspard.leon)

(In reply to Alastor Wu [:alwu] from comment #56)

BTW the green frame at the start of playback has been fixed in bug 1795507, we recently also fix other issues for the media engine playback. If you still see other issues while using the media engine, feel free to file bugs and set it block to bug 1752052, or NI me. Thank you so much.

Thanks for this, I might install the beta and give it a try.

In addition, for the normal video playback, would you mind help to capture a profile? Steps like following,

snip

I recorded a profiler trace with judder in a 4k 60fps video on youtube (https://www.youtube.com/watch?v=_gBBz7IMz1Y)
https://share.firefox.dev/3Px16lm

(my PC is Win 10x64, AMD 5800 X3D, 32GB RAM, 6900 XT video card with 22.11.2 drivers)

Flags: needinfo?(gaspard.leon)

How serious is the stuttering when you watch that video? Would you mind to do a screen recording as well? Because by looking your profiled result, I didn't see any suspicious points... Decoding was pretty fast, no any frames got dropped and the compositor also updated frames correctly.
Thank you!

Flags: needinfo?(gaspard.leon)

Hmm how long is a piece of string...

I think this is the real issue with this bug or similar... "how bad is it"... it's not terrible at first glance, you just "Feel it" over time when everything you watch is a bit jumpy.

If you hardly ever watch videos, or you have a 30hz screen, maybe it's not that bad.

It's just that with software rendering, or with hardware rendering in Edge it is perfectly glass smooth...

It's very hard to capture, I can try to make a good screen recording... ideally I would be able to run the smooth video, and the stuttery video on the same screen left and right so you can really compare them... I'll see what I can do

I suspect this will be the end of it, and it will remain "good enough" and never be improved.
Luckily I have upgraded my CPU in the computer so I can just use software rendering, and forget about this bug for the time being.
Sorry to waste your time.

So I spent some time with Radeon ReLive capturing and tried out a few different videos, I think I got a pretty good example: https://www.youtube.com/watch?v=uD_P76gDrOY

Edge is on the left, and plays first, then Firefox on the right plays next

Note that Firefox can play the video perfectly smooth if I change it to software rendering.

Flags: needinfo?(gaspard.leon)

Note:

I occasionally toggle hardware encoding back on for testing via the main settings screen "Use recommended performance settings" for my computer.

However I just did this in my normal profile (not the blank testing profile) and I tried a video, and it wasn't showing any GPU usage ... so I went hunting in about:config and only found one setting: media.hardware-video-decoding.failed which was set to true.

If I toggle the setting media.hardware-video-decoding.failed to false and restart the video, it does show GPU usage, and the video is again stuttery.

So if I set:
Hardware off in the main settings ("Use recommended performance settings" un-ticked and "Use hardware acceleration when available" un-ticked)
Then I have software decoding AND the rest of Firefox is not accelerated, so not ideal.

Hardware ON in the main settings, but media.hardware-video-decoding.failed set to true
Then I can have hardware accelerated Firefox with software video decoding which is smooth.. "best of both worlds" (for now)

From the video in comment 60, I can see Firefox playback is definitely not smooth enough comparing with Edge. If this situation is similar with the profiled result you captured in the comment 57, which means the media pipeline doesn't drop any frames, then the problem might be in the compositor/render side.

Therefore, when switching to the media engine playback On Firefox, the reporter can find hardware decoding being used and no stuttering can be observed, which means the graphic card and driver seems no problem.

Jeff, do you have any thought about this? Thank you.

Flags: needinfo?(jmuizelaar)

I have a Radeon 6800 XT reference GPU and have been having hardware decoding stutter problems in both Linux and Windows and both Firefox and Chromium-based browsers for a long time. However, it seems that at least on Windows 11 and Chromium-based browsers, this is fixed (at least for 4k60 video and lower) as of AMD Software v23.3.1. The stutter on Firefox with 4k60 still remains, unfortunately.

With HWiNFO, I have been watching GPU Video Decode usage and found an interesting difference: When playing a 4k60 VP9 video in e.g. Edge, the "GPU Video Decode 2 Usage" hovers between 60% to 70%. Clearly some headroom left. When I play the same video in Firefox, the usage is almost 100% and it's stutter city... It's when I downgrade the video to 1440p when I get 60% to 70% usage in Firefox.

Clearly Firefox is somehow utilizing the harware decode in a less optimal & more taxing manner for the GPU/hw decoder as compared to other browsers.

As for now (and for the last year or so), I still have to have "media.wmf.dxva.d3d11.enabled" set to false to get smooth playback of all videos - this allows h264 hw decode (although 1080p h264 isn't exactly taxing for a CPU to decode anyway), but most other complex codecs are forced to sw decode.

I don't really mind that much on my desktop computer, but it really sucks on laptops and battery-powered devices...

(In reply to Jan Klos [:drujd] from comment #63)

Clearly Firefox is somehow utilizing the harware decode in a less optimal & more taxing manner for the GPU/hw decoder as compared to other browsers.

As for now (and for the last year or so), I still have to have "media.wmf.dxva.d3d11.enabled" set to false to get smooth playback of all videos - this allows h264 hw decode (although 1080p h264 isn't exactly taxing for a CPU to decode anyway), but most other complex codecs are forced to sw decode.

Thanks for that setting... now I can have HW decoding on the RARE H264 video at least. :)

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

Attachment

General

Creator:
Created:
Updated:
Size: