Reddit post:

https://www.reddit.com/r/firefox/comments/wwnxtu/youtube_videos_freezing_since_updating_to_1040/

appears to be the result of recent video performance changes. A workaround exists (setting media.wmf.zero-copy-nv12-texture and gfx.direct3d11.reuse-decoder-device to false), but this needs to be addressed quickly.

I've asked a couple of people for their about:support info

Bug 1780138 seems a good candidate for being the cause

One user (oomcommander) is on NVIDIA GeForce RTX 2070 with 30.0.14.7141

appears to be the result of recent video performance changes. A workaround exists (setting media.wmf.zero-copy-nv12-texture and gfx.direct3d11.reuse-decoder-device to false), but this needs to be addressed quickly.

If gfx.direct3d11.reuse-decoder-device is false, "zero copy hardware decoded video" is also disabled. Then the problem seems to be triggered by "reuse decoder device".

• https://searchfox.org/mozilla-central/rev/3b3339b3a56c5434dfbbc250c8e8fc5cd43d07ca/dom/media/platforms/wmf/WMFVideoMFTManager.cpp#337
• https://searchfox.org/mozilla-central/rev/3b3339b3a56c5434dfbbc250c8e8fc5cd43d07ca/dom/media/platforms/wmf/DXVA2Manager.cpp#663

On AMD, reuse decoder device is used long time since Firefox 52 by Bug 1313883. Then if the problem happens since 104, it might be mainly related to NVIDIA GPUs.

On chromium, DXVAVideoDecodeAccelerator reuses d3d11 device(ANGLE Device) when "zero copy hardware decoded video" is enabled.

https://github.com/sotaroikeda/chromium-diagrams/blob/master/media_DXVAVideoDecodeAccelerator.pdf

• DXVAVideoDecodeAccelerator::DXVAVideoDecodeAccelerator()
• XVAVideoDecodeAccelerator::D3D11Device()
• DXVAVideoDecodeAccelerator::ShouldUseANGLEDevice()

On some GPUs, "zero copy video" is blocked in gpu_driver_bug_list.json

• https://source.chromium.org/search?q=disable_dxgi_zero_copy_video%5C%22&ss=chromium%2Fchromium%2Fsrc

On gecko, "zero copy video" is blocked on some GPUs based on the gpu_driver_bug_list.json.

• https://searchfox.org/mozilla-central/rev/3b3339b3a56c5434dfbbc250c8e8fc5cd43d07ca/widget/windows/GfxInfo.cpp#1761

It might be better to apply same block list also to FEATURE_REUSE_DECODER_DEVICE.

There was a comment that forcing mp4 addressed the problem. From it, vp9 hardware decoding might not work with "zero copy video" or "reuse decoder device".

https://www.reddit.com/r/firefox/comments/wwnxtu/youtube_videos_freezing_since_updating_to_1040/

On current chromium, D3D11VideoDecoder is used as default hardware video decoder on Windows than DXVAVideoDecodeAccelerator. Then blocklist of "disable_dxgi_zero_copy_video" in gpu_driver_bug_list.json might not be enough.

https://github.com/sotaroikeda/chromium-diagrams/blob/master/media_D3D11VideoDecoder.pdf

• CreatePlatformVideoDecoder()
• ShouldUseD3D11VideoDecoder()

D3D11VideoDecoder is blocked on some GPUs. In this case, DXVAVideoDecodeAccelerator is used instead.

• https://source.chromium.org/search?q=disable_d3d11_video_decoder%5C%22&ss=chromium

(In reply to Sotaro Ikeda [:sotaro] from comment #7)

On current chromium, D3D11VideoDecoder is used as default hardware video decoder than DXVAVideoDecodeAccelerator. Then blocklist of "disable_dxgi_zero_copy_video" in gpu_driver_bug_list.json might not be enough.

One user (oomcommander) is on NVIDIA GeForce RTX 2070 with 30.0.14.7141

The above seems not blocked by "disable_dxgi_zero_copy_video" in gpu_driver_bug_list.json.

oomcomander had no recent crashes in about:crashes which suggests they're not obviously running into bug 1313883.

I just noticed that oomcomander doesn't have DirectComposition because of mixed refresh rate (144/60).

From Chris Peterson (for reference):

Here's a Reddit post about Facebook and ESPN videos not working in 104 on Windows 10 (but YouTube works for them):
https://www.reddit.com/r/firefox/comments/wycu2p/viedos_on_fb_and_espn_not_playing_yt_works/

I tried reproducing this on GTX 1650 with the 30.0.14.7141 driver and couldn't. But it may be intermittent. I've asked the reporter to update their drivers and see if they can still reproduce.

(In reply to Bob Hood [:bhood] from comment #11)

From Chris Peterson (for reference):

Here's a Reddit post about Facebook and ESPN videos not working in 104 on Windows 10 (but YouTube works for them):
https://www.reddit.com/r/firefox/comments/wycu2p/viedos_on_fb_and_espn_not_playing_yt_works/

The reporter's problem was addressed by https://support.mozilla.org/en-US/kb/fix-video-audio-problems-firefox-windows. Then it seems like a different problem.

https://www.reddit.com/r/firefox/comments/wzoyyz/after_recent_update_videos_are_playing_in_frames/

The above used "AMD Radeon(TM) Vega 8 Mobile Graphics". And the problem was addressed by a way of comment 0.

On AMD, "reuse decoder device" is always enabled. Then the problem should be caused by "zero copy hardware decoded video" on the PC.

• https://searchfox.org/mozilla-central/rev/fc65556c84472fa6addd11d9369056d7bc0d3f3a/gfx/thebes/DeviceManagerDx.cpp#898

From the symptoms(frame drops), the problem might happen by not enough of video buffers. Some video decoders might not allocate enough number of video buffers. "10 + 1 " out put buffers are requested in WMFVideoMFTManager::InitInternal().

With current gecko's architecture, allocated video buffers are released by RemoteDecoderManagerParent::RecvDeallocateSurfaceDescriptorGPUVideo(). It is requested from content process via GPUVideoTextureData::Deallocate(). Release request from content process is not responsive. Then RemoteDecoderManagerParent::mImageMap and RemoteDecoderManagerParent::mTextureMap hold at most around 10 buffers.

https://github.com/sotaroikeda/firefox-diagrams/blob/master/media/dom_media_WMFVideoMFTManager_97.pdf

I wonder if we allocate more buffers at WMFVideoMFTManager::InitInternal(), the problem might be addressed. Though it is not clear yet, if the decoders could actually allocate the buffers as requested.

The following build increases video buffers to "15 + 1 ".

https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/Z-avP7lPQgSJJ5pTZbU7iA/runs/0/artifacts/public%2Fbuild%2Ftarget.zip
https://treeherder.mozilla.org/jobs?repo=try&revision=d45e40f8d8e9f3e0fd574c737949fd2eafbfe268

(In reply to Sotaro Ikeda [:sotaro] from comment #16)

With current gecko's architecture, allocated video buffers are released by RemoteDecoderManagerParent::RecvDeallocateSurfaceDescriptorGPUVideo(). It is requested from content process via GPUVideoTextureData::Deallocate(). Release request from content process is not responsive. Then RemoteDecoderManagerParent::mImageMap and RemoteDecoderManagerParent::mTextureMap hold at most around 10 buffers.

It seems not simple to reduce the above.

Set release status flags based on info from the regressing bug 1780138

I re-think about this bug. I have come to think that it seems better to backout bug 1780138 and address Comment 18. Then re-try re-enabling it on release.

:jrmuizel, how do you think about it?

Comment on attachment 9292007 [details]
Bug 1787293 - Revert Bug 1780138

Beta/Release Uplift Approval Request

• User impact if declined: Some users video has freezes/bad playback
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): This basically reverts the enabling of the zero copy feature.
• String changes made/needed:
• Is Android affected?: Yes

Comment on attachment 9292007 [details]
Bug 1787293 - Revert Bug 1780138

Beta/Release Uplift Approval Request

• User impact if declined: Some users video has freezes/bad playback
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): This basically reverts the enabling of the zero copy feature.
• String changes made/needed:
• Is Android affected?: Yes

Comment on attachment 9292007 [details]
Bug 1787293 - Revert Bug 1780138

Approved for 104.0.1

Comment on attachment 9292007 [details]
Bug 1787293 - Revert Bug 1780138

Approved for 105.0b5

https://hg.mozilla.org/releases/mozilla-beta/rev/4ff9a2af4dd0

https://hg.mozilla.org/releases/mozilla-release/rev/c20b718fb69a

https://hg.mozilla.org/mozilla-central/rev/5b6038b541f5

From Bug 1785149 comment 10, this case seemed to be caused by Windows.

We've got a report that this is a Windows issue:

EDIT: it is indeed a Windows 11 issue for those who are running Windows 11, both preview and beta versions. The updates 22621.586 and 22622.586 fix this.

Hello,
We were unable to reproduce the issue on Firefox 104.
We tested on both Windows 11 and Windows 10, by using Intel 530 GPU, Nvidia GTX 1050 and Nvidia GTX 1650.