1689433 - h264 video broken on win7 with sw-wr-d311 on gen4.5

Status: RESOLVED FIXED

(Core :: Graphics: WebRender, defect)

Description

[Dal]

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

Steps to reproduce:

Since Nightly 86 update 1/14/2021, continuing in built 87 to date 1/28/2021
Audio only in Videos listed as AVC1.4___ , with a whites out screen (on Youtube),
Other Codecs working
Twitter - Audio only on ALL embedded video
Other Sites using ACV produce same - Audio only

Issue does not manifest in Chrome, I.E. or Opera

Actual results:

Not a skilled Coder - so depending on the pros to correct.

System is Dell 1545 laptop
Windows 7

Comment 1

[Jon Bauman [:jbauman:]]

Can you use https://mozilla.github.io/mozregression/ to pinpoint at what version this issue started happening?

Comment 2

[Jon Bauman [:jbauman:]]

Also, a link to a specific video you're seeing this behavior with would help

Comment 3

[Dal]

Sorry, I tried to follow the Video for Regression but am having difficulty understanding most of the speakers direction due to low volume and unfamiliar accent.
I can confirm I update daily and the change happened about Jan. 14th on Nightly 86.
I grabbed a random Youtube video that produces audio only
https://www.youtube.com/watch?v=vTTt0BRAeiE&t=16s

*Works on other browsers

Comment 4

[Byron Campen [:bwc]]

(In reply to Dal from comment #3)

Sorry, I tried to follow the Video for Regression but am having difficulty understanding most of the speakers direction due to low volume and unfamiliar accent.
I can confirm I update daily and the change happened about Jan. 14th on Nightly 86.
I grabbed a random Youtube video that produces audio only
https://www.youtube.com/watch?v=vTTt0BRAeiE&t=16s

*Works on other browsers

No luck reproducing on my Windows machine. I'm guessing a copy of about:support from the reporter would be useful?

Comment 5

[Byron Campen [:bwc]]

I should note that mozregression GUI is currently unusable on Windows due to bug 1647533. We at least have a rough date range here, should we try to walk the reporter through using mozregression on the command-line?

Comment 6

[Dal]

Attachment: About Support report

About:Support

Comment 7

[Dal]

Attachment: Raw Data

About:Support

Comment 8

[Bryce Seager van Dyk [:bryce] (he/him) - Not reading bugmail]

Since this is H264 failing (AVC1), it means something is going wrong with using the Windows decoders, as that's the only path on Windows. Since this did work, but now does not, it suggests codecs are present on the system and this is not a Windows N issue. Dal, can you confirm you're not running a Windows N version of Windows?

Since Microsoft no longer supports Windows 7, it is not receiving codec updates that supported versions are. We've seen issues where sites are encoding media that is no longer compatible with Windows 7's decoders. Chrome works around this by shipping ffmpegs decoders, but we cannot do that here due to licensing issues.

I'm going to create a test page to help see if that's the issue. I'll report back later today when I have it ready.

---

For devs

Here's a fairly wide set of landings around the time of issue if you want to trawl.

Comment 9

[Bryce Seager van Dyk [:bryce] (he/him) - Not reading bugmail]

I would have expected the youtube video linked above to still work on Windows 7. To test further, Dal, could you open this test page I've created https://singingtree.github.io/h264-profile-level-testpage/ and set the profile to 'high' and then try the different levels and let me know which play and which do not?

---

For devs see also bug 1479203.

Comment 10

[Dal]

About:Support

(In reply to Bryce Seager van Dyk (:bryce) from comment #8)

Since this is H264 failing (AVC1), it means something is going wrong with using the Windows decoders, as that's the only path on Windows. Since this did work, but now does not, it suggests codecs are present on the system and this is not a Windows N issue. Dal, can you confirm you're not running a Windows N version of Windows?

Since Microsoft no longer supports Windows 7, it is not receiving codec updates that supported versions are. We've seen issues where sites are encoding media that is no longer compatible with Windows 7's decoders. Chrome works around this by shipping ffmpegs decoders, but we cannot do that here due to licensing issues.

I'm going to create a test page to help see if that's the issue. I'll report back later today when I have it ready.

---

For devs

Here's a fairly wide set of landings around the time of issue if you want to trawl.

System is Windows 7 Ultimate SP1 64bit
Again, this happened mid month during a Nightly Update, so the Codec should not be the issue, but rather some change in Nightly.
Noticed on YT AV01 is working as well as other codecs.

Checking on Opera YT Video running AVC1.4d4014 plays perfect - Same Video as on Chrome, but Fails on Nightly
https://www.youtube.com/watch?v=z2xj_flhUIo

Comment 11

[Dal]

(In reply to Bryce Seager van Dyk (:bryce) from comment #9)

I would have expected the youtube video linked above to still work on Windows 7. To test further, Dal, could you open this test page I've created https://singingtree.github.io/h264-profile-level-testpage/ and set the profile to 'high' and then try the different levels and let me know which play and which do not?

---

For devs see also bug 1479203.

Bryce, the Video counter runs 5 seconds at all levels with a White screen.
Assuming no Audio as speaker is struck through.
*I also tried a few other profiles with no success.

Comment 12

[Bryce Seager van Dyk [:bryce] (he/him) - Not reading bugmail]

Can you navigate to about:config and try setting the following prefs to the listed values, restarting Firefox, and seeing if that affects the issue?

• gfx.webrender.force-disabled to true
• media.hardware-video-decoding.enabled to false

If it does help, could you try then setting them one by one and seeing if it's one or the other the helps.

If it doesn't help, they can be set back to their original values.

Comment 13

[Dal]

(In reply to Bryce Seager van Dyk (:bryce) from comment #12)

Can you navigate to about:config and try setting the following prefs to the listed values, restarting Firefox, and seeing if that affects the issue?

• gfx.webrender.force-disabled to true
• media.hardware-video-decoding.enabled to false

If it does help, could you try then setting them one by one and seeing if it's one or the other the helps.

If it doesn't help, they can be set back to their original values.

Followed instructions.
•

• Renders Video functional

Testing SINGLE changes
gfx.webrender.force-disabled <False>
This seems to be the trigger and causes Video Failure

Currently leaving at:
gfx.webrender.force-disabled to <true>
media.hardware-video-decoding.enabled <True>

Comment 14

[Bryce Seager van Dyk [:bryce] (he/him) - Not reading bugmail]

Changing components as comment 13 indicates a render issue.

Comment 15

[Sotaro Ikeda [:sotaro]]

It might be a problem of WebRender (Software D3D11).

I tested WebRender (Software D3D11) on 2 Win7 PCs, but I could not reproduce the problem. It might be a hardware specific problem.

Comment 16

[Sotaro Ikeda [:sotaro]]

I wonder if Bug 1684170 might trigger the problem. It seemed to enable WebRender Software usage on some PCs.

Comment 17

[Sotaro Ikeda [:sotaro]]

Dal, can you check if the problem happens with the follwoing prefs?

• gfx.webrender.force-disabled : false
• gfx.webrender.software.d3d11 : false
• media.hardware-video-decoding.enabled : true

and can you upload about:support when gfx.webrender.force-disabled==true?

Comment 18

[Sotaro Ikeda [:sotaro]]

Dal, can you check if Graphics section of about:support has "Failure Log" after the problem happens? Thank you.

Comment 19

[Dal]

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

Dal, can you check if Graphics section of about:support has "Failure Log" after the problem happens? Thank you.

Not seeing any Failure Logs, just some Crash reports that are not viewable. (All have been submitted)
Have not had time to test your suggestions yet. will advise once completed.

Comment 20

[Dal]

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

Dal, can you check if the problem happens with the follwoing prefs?

• gfx.webrender.force-disabled : false
• gfx.webrender.software.d3d11 : false
• media.hardware-video-decoding.enabled : true

and can you upload about:support when gfx.webrender.force-disabled==true?

This Works!
Performance is Far better:
Faster loading
Smoother Frame rate
Auto Resolution Function back on YT
Auto Play Back on YT

*Also attaching a Pic of a portion of about:config that I do not understand

Comment 21

[Dal]

Attachment: Unknown trash?

Found these 2, in Bold with a Trash Can, while making recommended changes to test Bug.

Comment 22

[Dzmitry Malyshau [:kvark]]

Marking S3 - already in gfx-triage

Comment 23

[Sotaro Ikeda [:sotaro]]

(In reply to Dal from comment #20)

This Works!
Performance is Far better:
Faster loading
Smoother Frame rate
Auto Resolution Function back on YT
Auto Play Back on YT

*Also attaching a Pic of a portion of about:config that I do not understand

Thank you for the confirmation!

:mattwoodrow, do you have an idea about what is going on?

Comment 24

[Matt Woodrow (:mattwoodrow)]

I don't have any ideas sorry!

The 14th of Jan doesn't match up with when we enabled WebRender Software, or the D3D11 compositor by default, so it seems like the user should have been on this configuration before the regression too.

I can't see any changes in the regression range that look to be likely to affect video only, and for some drivers.

What configs did you try when reproducing this?

Comment 25

[Jeff Muizelaar [:jrmuizel]]

I'll try to reproduce this locally.

Comment 26

[Jeff Muizelaar [:jrmuizel]]

I can reproduce this.

Comment 27

[Jeff Muizelaar [:jrmuizel]]

Disabling sw-wr d3d11 fixes the problem.

Comment 28

[Jeff Muizelaar [:jrmuizel]]

Matt, what's the best way to find out if we're using DXVA 9 vs 11? Can we add that info to about:support?

Comment 29

[Matt Woodrow (:mattwoodrow)]

If it's win7, then we're definitely using DXVA 9 - https://searchfox.org/mozilla-central/rev/7bb1cc6abf6634b2a20f71935e1e519e73402b63/dom/media/platforms/wmf/WMFVideoMFTManager.cpp#209

Adding this to about:support seems a bit tricky, since it's a runtime decision, and a D3D11 failure will fall back into D3D9. We could load a test video and query the runtime object, but that's not ideal.

It might also be ok to just remove the fallback path, and unconditionally use 11 on win8+.

Comment 30

[Jeff Muizelaar [:jrmuizel]]

Out of curiosity, do you know why we don't use DXVA 11 on Win7?

Comment 31

[Matt Woodrow (:mattwoodrow)]

I believe the API only exists on Win8+ - https://docs.microsoft.com/en-us/windows/win32/api/d3d11/nn-d3d11-id3d11videocontext#requirements

Comment 32

[Jeff Muizelaar [:jrmuizel]]

Can you reproduce the problem if you force DXVA 9?

Comment 33

[Matt Woodrow (:mattwoodrow)]

I can't, seems to work fine for me on Windows 10, even with DXVA 9 (and if I disable nv12 surfaces).

Comment 34

[Jeff Muizelaar [:jrmuizel]]

This seems to be broken even with hardware accelerated video turned off which is weird.

Comment 35

[Matt Woodrow (:mattwoodrow)]

Disabling the GPU process on Windows 10 still isn't sufficient to reproduce this.

One interesting thing to note is that the path to upload vp9 software decoded frames into a texture from the RDD process has a Win8+ guard [1], whereas the H264 path does not.

I haven't found any reason why we wouldn't this bug wouldn't happen with normal Layers+CompositorD3D11 though.

[1] https://searchfox.org/mozilla-central/rev/6f8f3d0e9022b6f0405da26ec940a89455416202/dom/media/MediaData.cpp#336
[2] https://searchfox.org/mozilla-central/rev/6f8f3d0e9022b6f0405da26ec940a89455416202/dom/media/platforms/wmf/WMFVideoMFTManager.cpp#637

Comment 36

[Jeff Muizelaar [:jrmuizel]]

Yeah, I can't reproduce on my gen6 Intel win7 with the GPU process disabled either.

Comment 37

[Matt Woodrow (:mattwoodrow)]

It seems plausible that something like D3D11Checks::DoesTextureSharingWork is supposed to be blocking texture uploads from RDD, but I can't find any path that would cause SW-WR+D3D11 to skip this where Layers+D3D11 doesn't.

Comment 38

[Jeff Muizelaar [:jrmuizel]]

I was able to get a debugging setup working. I'll dig into this more as I have time.

Comment 39

[Jeff Muizelaar [:jrmuizel]]

I confirmed that removing the Win8 guard cause vp9 software decoded frames to break. It looks like HandleExternalImage is not being called to do the drawing: https://searchfox.org/mozilla-central/source/gfx/webrender_bindings/RenderCompositorD3D11SWGL.cpp#84

Comment 40

[Jeff Muizelaar [:jrmuizel]]

Looks like this is caused by us requiring ANGLE even with SW-WR:
https://searchfox.org/mozilla-central/source/gfx/layers/d3d11/TextureD3D11.cpp#1277

Comment 41

[Sotaro Ikeda [:sotaro]]

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

Looks like this is caused by us requiring ANGLE even with SW-WR:
https://searchfox.org/mozilla-central/source/gfx/layers/d3d11/TextureD3D11.cpp#1277

It was added by Bug 1422288. At that time, we did not expected SW-WR.

Comment 42

[Sotaro Ikeda [:sotaro]]

If we want to check SW-WR, it could be checked by "aResources.GetBackendType() == WebRenderBackend::SOFTWARE".

• https://searchfox.org/mozilla-central/rev/26330a08b1f9d06938faa0aa5e0f8c7a58064aa2/gfx/layers/d3d11/TextureD3D11.cpp#1292

Comment 43

[Jeff Muizelaar [:jrmuizel]]

Attachment: Bug 1689433. Remove ineffective D3D11 ANGLE blocklist entry.

D3D11 was made the default in Firefox 60 through:
https://hg.mozilla.org/mozilla-central/rev/8ee92682ad1f#l490.39
and so we've been using D3D11 on this hardware since then.

This has the added advantage of allowing hardware WebRender to run
on these devices and fixing h264 video with SW-WR.

Comment 44

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/2fa5bd2e3ff8
Remove ineffective D3D11 ANGLE blocklist entry. r=jgilbert

Comment 45

[Bogdan Tara[:bogdan_tara | bogdant]]

https://hg.mozilla.org/mozilla-central/rev/2fa5bd2e3ff8

Comment 46

[Jeff Muizelaar [:jrmuizel]]

Dal, can you confirm that this works for you now?

Comment 47

[Jeff Muizelaar [:jrmuizel]]

Note, nightly updates have currently been disabled so you may need to wait a little while yet.

Comment 48

[Dal]

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

Dal, can you confirm that this works for you now?

*After making initial about:config changes,
I have made no changes since the group started a Deep dive on the issue.
If Update to Release to 88.0a1 Reset the Config settings, everything is now working.
If the settings were not changed back to defaults during the Revision change I would assume I will need to manually change and test.

Please advise.

Comment 49

[Jeff Muizelaar [:jrmuizel]]

I'm only interested in confirming that it works with the default settings. It sounds like it does which is great.

Comment 50

[Dal]

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

I'm only interested in confirming that it works with the default settings. It sounds like it does which is great.

So am I to assume the 88.0a1 update reset About:Config to Defaults?
This is not what we had as a work around so I could continue use while waiting for a correction.

Comment 51

[Jeff Muizelaar [:jrmuizel]]

No, you'll need to reset the about:config defaults yourself:
media.hardware-video-decoding.enabled=true
gfx.webrender.force-disabled=false
gfx.webrender.software.d3d11=true

Comment 52

[Dal]

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

No, you'll need to reset the about:config defaults yourself:
media.hardware-video-decoding.enabled=true
gfx.webrender.force-disabled=false
gfx.webrender.software.d3d11=true

Only Change Required = gfx.webrender.software.d3d11=true
Tested several Videos
Bug Fix seems to have resolved the issue

Thanks to you and the rest of the team!