<a class="header-button" href="https://bugzilla.mozilla.org/home" title="Go to home page"> Bugzilla

Reporter

Comment 2

•

1 year ago

I did some additional investigation.

I said earlier that I observed X calls to function, but that's wrong, it's X samples in the profiler.

After performing burn-in on youtube I can reproduce the issue with the video on https://bitmovin.com/demos/av1 (av1) and the vp9 video on https://base-n.de/webm/VP9%20Sample.html. The vp8 video on that page is unaffected, as is h264. I think this is because vp8 and h264 don't use dx11?

I attempted to perform 'burn in' with https://bitmovin.com/demos/av1. After reloading the page 20 times I can see some slowness in the profiler, but it's nowhere near the slowness caused by youtube burn-in. On this website, 'fresh' firefox requires avg 6 samples of CContext::SubmitDecoderBuffers per seek. After 20 reloads, average of 17 samples. After burn-in with 20 video recommendations on youtube, 174 samples. I think all av1/vp9 video's result in slowdowns, but following video recommendations on youtube is by far the fastest way to burn in.

The vp9 test site is useful for testing because the video has only one I-frame, seeking to the end of the video always results in 248 processed frames. In the profiler it's easy to see processing each single frame becomes slower after burn-in because CContext::SubmitDecoderBuffers takes more time or is called more often.

Reporter

Comment 3

•

1 year ago

I can also reproduce this by entering/exiting fullscreen many times at https://base-n.de/webm/VP9%20Sample.html (vp9). 500 trials is about the same slowdown as 20 youtube recommendations. I plotted the number of trials (fullscreen enter/leave or youtube recommendations) and the time the various GPU threads are busy handling a seek, the relationship is very linear.

Alice0775 White

Updated

•

1 year ago

Comment 4

•

1 year ago

Killing the GPU process reliably restores performance back to normal. Increase layers.gpu-process.max_restarts and layers.gpu-process.max_restarts_with_decoder to prevent a fallback to software video decoding.

about:memory doesn't show any obvious signs of leakage. Whatever is causing the problem is leaking less than 1MB of memory in either the GPU or main thread.

I cannot reproduce with software decoder. Seems to be D3D11 only.

Reporter

Comment 5

•

1 year ago

More investigation. I'd appreciate it if anyone can try to follow the new steps to reproduce, I'm particularly interested in hearing whether this is reproducible with an AMD IGP on windows.

New minimum steps to reproduce:

Go to https://base-n.de/webm/VP9%20Sample.html
- Do not play the video during any of these steps.
- Start the profiler with the media preset. Seek to the end of the vp9 video and stop the profiler.
- In the profiler window, select all MediaPDecoder threads in the GPU process.
- In the marker table, search for the string "DecodeFrame". You will find about 200 markers, write down the duration of one of the markers in the middle, this is the time to decode a single frame. Alternatively search for "Thread CPU use".
Seek to a random location in the video, repeat this 20 times. You don't need to wait between seeks. If you accidentally play the video during this step, close the browser and start over.
Repeat step 1.

On my computer, decoding a single frame takes 90μs plus 11μs for every seek performed in step 2. Total cpu time needed to seek to the end is 44ms, after 20 seeks 110ms.

The following actions do NOT result in slowdowns:

Seeking while the video is playing.
Toggling fullscreen many times.
Playing the video in loop mode for several minutes.
Rapidly pausing and unpausing the video.
Interacting with non-accelerated video (vp8, or vp9/av1 with hw accel disabled).

The following does result in slowdowns (rate of slowdown per frame per action in parenthesis):

Seeking in paused video (11.5μs).
Playing/pausing the video, then waiting 6 seconds for the threads to unload (11.5μs).
Reloading the page (6.5μs).
Reloading https://bitmovin.com/demos/av1 (6.5μs)
Following youtube recommendations (46μs)

The slowdown seems to be directly proportional to the number of Media Foundations video contexts created (WMFDecoderModule::CreateVideoDecoder). Slowdown is approx 6μs per VP9 context and 3μs per AV1 context. Some of the actions you would assume to only need one context create two, the first context is discarded without doing any work, must be a bug.

All the extra time is spent in Microsoft Media Foundations (msvp9dec_store.dll) and/or intel GPU driver (igd11dxva64.dll) code. I verified that the GPU isn't doing more work and firefox sends exactly the same frames to the Media Foundations transform before and after burn-in. I think the issue is either an intel GPU driver bug preventing resources from being properly freed, or a Media Foundations resource handing bug in firefox.

There are definitely no memory leaks in the GPU process related to this issue, at least not in any memory allocations that are tracked by the profiler.

Comment 6

•

1 year ago

Thank you for the detailed investigation.

Stefan, do you have a feel for whether this is a recent behavior change?

Alastor, do you have any suggestions, for pref changes or otherwise, to further narrow down the source of the problem here?

Status: UNCONFIRMED → NEW

Ever confirmed: true

Flags: needinfo?(alwu)

Summary: poor Youtube video performance when browser stays open for long time → poor Youtube video performance when browser stays open for long time. CPU in CDecodeContext::SubmitBuffers

Reporter

Comment 7

•

1 year ago

The behavior started when I got a new computer recently. My old machine doesn't support D3D11 video acceleration and I cannot reproduce this issue there.

Reporter

Comment 8

•

1 year ago

I played around with mozregression and found several performance regressions related to seeking:

2021-12-14 (06c7b4e2d14be1ee8050d6c1eb1ab1bab19ac3c2) to 2021-12-15 (66b5b425d27f9880ebde030e4c0a5e433da569ee)
Before this change, no matter how many times I seek in a video I observed no slowdowns. After the change slowdown of about 4us per decoded frame per seek.
The regression was introduced somewhere between these commits.

2022-03-17 (2e19a408b79003d908c35bd733a2a63e58a07ec2) to 2022-03-18 (63e3e58c38ba175ae6d1ab68e482be74be93f723).
Between these commits a change was made that increased the slowdown per frame per seek from 4us to 8us.
It is very obvious in the profiler what caused this regression, before this change only one decoder was created per seek, after this change two are created, the first is discarded immediately without decoding any frames. Commits ea0660396ced and e66787ae5c56, authored by :karlt, touched relevant code. There may be more.

Creating a D3D11 decoder is a very expensive operation, on my machine 100-150ms. It seems unnecessary to create two decoders for a single seek. Loading a single youtube video creates 19-33(!) decoders which takes multiple seconds, most of these decoders are discarded without ever decoding a single frame.

2022-04-27 (23768574eb6d1c1191228316adbc082aaf3a7fd5) to 2022-04-28 (6d8eefa220596a138aceee2b8e93529128c98451).
Between these commits a change was made that increased the slowdown per frame per seek from 8us to 11us.
The only commit that changed any video decoding code is fe0e4a38498c. I don't see anything interesting in this commit, maybe I'm missing something?

No additional regressions have been introduced since then.

I will continue investigation into the first and third regression this weekend. The second regression is probably best handled by someone else.

Updated

•

1 year ago

Severity: -- → S2

Comment 9

•

1 year ago

(In reply to stefan.dessens from comment #8)

2021-12-14 (06c7b4e2d14be1ee8050d6c1eb1ab1bab19ac3c2) to 2021-12-15 (66b5b425d27f9880ebde030e4c0a5e433da569ee)
Before this change, no matter how many times I seek in a video I observed no slowdowns. After the change slowdown of about 4us per decoded frame per seek.
The regression was introduced somewhere between these commits.

https://hg.mozilla.org/mozilla-central/rev/a87211c8eedd
changed gfx.direct3d11.reuse-decoder-device

https://hg.mozilla.org/mozilla-central/rev/1ddf68e26a4a
changed some gfx.webrender.dcomp-video-overlay-win pref code. It looks like a no-op, unless there timing differences at start-up.

2022-03-17 (2e19a408b79003d908c35bd733a2a63e58a07ec2) to 2022-03-18 (63e3e58c38ba175ae6d1ab68e482be74be93f723).
Between these commits a change was made that increased the slowdown per frame per seek from 4us to 8us.
It is very obvious in the profiler what caused this regression, before this change only one decoder was created per seek, after this change two are created, the first is discarded immediately without decoding any frames.

https://hg.mozilla.org/mozilla-central/rev/90c92f9077fa
changed the way that MFT decoders are created.

https://hg.mozilla.org/mozilla-central/rev/a7ab49506ec3
added initialization of a dummy decoder for MediaCapabilities.

https://hg.mozilla.org/mozilla-central/rev/6ba9cadf045f
moved some video scaling to VideoProcessor.
gfx.webrender.dcomp-video-vp-scaling-win controls some things in that change.

Commits ea0660396ced and e66787ae5c56, authored by :karlt, touched relevant code.

Those commits relate to media streams from getUserMedia() rather than decoded video playback.

2022-04-27 (23768574eb6d1c1191228316adbc082aaf3a7fd5) to 2022-04-28 (6d8eefa220596a138aceee2b8e93529128c98451).
Between these commits a change was made that increased the slowdown per frame per seek from 8us to 11us.
The only commit that changed any video decoding code is fe0e4a38498c. I don't see anything interesting in this commit, maybe I'm missing something?

Yes, https://hg.mozilla.org/mozilla-central/rev/fe0e4a38498c is the only change that I found in that range. I also don't see why it might have this effect.

ni?Zaggy1024 in case of any ideas.

(In reply to stefan.dessens from comment #5)

I'd appreciate it if anyone can try to follow the new steps to reproduce, I'm particularly interested in hearing whether this is reproducible with an AMD IGP on windows.

I think the issue is either an intel GPU driver bug preventing resources from being properly freed, or a Media Foundations resource handing bug in firefox.

Yes to all that.

Flags: needinfo?(Zaggy1024)

Comment 10

•

1 year ago

Thanks Stefan for the extensive diagnostic and regression range! I think I'm seeing something similar on the Web Codecs side of things, that is using the same code than playback, and I'm planning to work on that in a week or so.

The Web Codecs test case performs transcoding from one codec (that can be decoded in hardware) to another codec (that is encoded in software), and so we're able to reproduce the leak fairly quickly, since it runs through so many video frames in a short period (much faster than real-time).

This is being investigated in bug 1887554.

Updated

•

1 year ago

Assignee: nobody → padenot

Reporter

Comment 11

•

1 year ago

I managed to track down the third regression (which was, indeed, in fe0e4a38498c), the slowdown is caused by ID3D11VideoDevice::CreateVideoDecoder().

Adding these lines in D3D11DXVA2Manager::CreateDecoder() makes the slowdown accumulate much faster:

// NOTE: D3D11_VIDEO_DECODER_DESC desc = {DXVA2_ModeVP9_VLD_Profile0, ?, ?, DXGI_FORMAT_NV12};
ID3D11VideoDecoder *dummy;
hr = videoDevice->CreateVideoDecoder(&aDesc, &config, &dummy);
dummy->Release();
hr = videoDevice->CreateVideoDecoder(&aDesc, &config, &dummy);
dummy->Release();
hr = videoDevice->CreateVideoDecoder(&aDesc, &config, &dummy);
dummy->Release();

This suggests the graphics driver is leaking resources. Does Mozilla have a contact at intel (or Microsoft?) that can look at this issue?

Comment 12

•

1 year ago

We do have contacts, yes, but it's possible that we can diagnose ourselves. Alastor, you should have the hardware to repro this, mind taking a look?

Comment 13

•

1 year ago

Changing assignee because I don't have the necessary hardware on my workstation to repro this as of now.

Assignee: padenot → alwu

Updated

•

1 year ago

Comment 14

•

1 year ago

(In reply to stefan.dessens from comment #11)

I managed to track down the third regression (which was, indeed, in fe0e4a38498c), the slowdown is caused by ID3D11VideoDevice::CreateVideoDecoder().

Adding these lines in D3D11DXVA2Manager::CreateDecoder() makes the slowdown accumulate much faster:
// NOTE: D3D11_VIDEO_DECODER_DESC desc = {DXVA2_ModeVP9_VLD_Profile0, ?, ?, DXGI_FORMAT_NV12};
ID3D11VideoDecoder *dummy;
hr = videoDevice->CreateVideoDecoder(&aDesc, &config, &dummy);
dummy->Release();
hr = videoDevice->CreateVideoDecoder(&aDesc, &config, &dummy);
dummy->Release();
hr = videoDevice->CreateVideoDecoder(&aDesc, &config, &dummy);
dummy->Release();
This suggests the graphics driver is leaking resources. Does Mozilla have a contact at intel (or Microsoft?) that can look at this issue?

Ah, this would make a lot of sense to me, creating the DXVA2 decoder is the only thing that seems to make sense to cause this issue. I wonder if changing this line to just return true instead of calling SupportsConfig() would reduce or eliminate the issue?

I'm also wondering if gfx.direct3d11.reuse-decoder-device has something to do with this, I noticed when reading its bug history that it was initially created because of some driver issues on Intel.

Flags: needinfo?(Zaggy1024)

Reporter

Comment 15

•

1 year ago

(In reply to Zaggy1024 from comment #14)

Ah, this would make a lot of sense to me, creating the DXVA2 decoder is the only thing that seems to make sense to cause this issue. I wonder if changing this line to just return true instead of calling SupportsConfig() would reduce or eliminate the issue?

Yes. Changing this single line eliminates the performance regression introduced in fe0e4a38498c. It doesn't effect the performance issues introduced in earlier commits.

Assignee

Comment 16

•

1 year ago

By doing some experiments, I can 100% reproduce VP9 issue on my Windows 11 laptop, but for AV1 (also the link in the comment5) it's not obvious so I can't make sure if it's reproducible on my setup. For H264/HEVC, I also didn't observe any significant regression after each seek.
(However, it's worth to mention that the performance of H264/HEVC is WAY worse than vp9)

For the situation we've observed, we need to figure out
(1) Whether ID3D11VideoDecoders are properly released
(2) Can we avoid creating new ID3D11VideoDecoder?
(2) If (1) is not, would they affect the decoding performance?

For (1), I couldn't really verify this, but from the investigation I've done, I didn't see any obvious problem on how we deal with the those video decoder. We expect those ID3D11VideoDecoder and their underlying resources should be properly released.

For (2), and why we create so many video decoder? Shouldn't we reuse a decoder? In normal situation, we would reuse the video, that is why we can't reproduce this issue while video is playing. If we seek video before video is playing, then it hits this special mechanism which makes us into the dormant state right away after seeking. Dormant state would release all the decoder resources, which usually happen when a video being paused too long, and our default setting is 5s.

So now we know that we can actually reuse the decoder, however, it doesn't solve the problem, because we didn't expect releasing decoder resources would bring such a side effect of performance regression.

Let's go to (3), is the performance regression really caused by creating ID3D11VideoDecoder? Maybe, but I found that once I disabled the pref media.wmf.zero-copy-nv12-textures, then the issue is no longer reproducible on my laptop. So what I'm guessing if that setting these attributes might create some resources which requires additional clean-up processes.

Sotaro, do you have any thought about what resources we might need to manually clear up if we enable zero-copy? Also, stefan, could you help me verify if disabling the pref media.wmf.zero-copy-nv12-textures works for you or not? Thank you.

Flags: needinfo?(stefan.dessens)

Flags: needinfo?(sotaro.ikeda.g)

Flags: needinfo?(alwu)

Assignee

Updated

•

1 year ago

Priority: -- → P1

Zaggy1024

Comment 17

•

1 year ago

•

Edited

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

For (2), and why we create so many video decoder? Shouldn't we reuse a decoder? In normal situation, we would reuse the video, that is why we can't reproduce this issue while video is playing. If we seek video before video is playing, then it hits this special mechanism which makes us into the dormant state right away after seeking. Dormant state would release all the decoder resources, which usually happen when a video being paused too long, and our default setting is 5s.

Only tangentially related to the bug I suppose, but it seems like it might be nice to only go dormant a certain time after a seek in anticipation of the user possibly needing to refine the location they're seeking to. I suppose doing so may partially mask this bug, though.

(Might doing this also help with the performance of single-frame seeks on YouTube?)

(In reply to stefan.dessens from comment #15)

Yes. Changing this single line eliminates the performance regression introduced in fe0e4a38498c. It doesn't effect the performance issues introduced in earlier commits.

The fact that this is only one part of the performance regression makes me think that this is probably a driver issue, since my understanding is that the MFT would be internally create the same D3D11 decoder interface that we use in D3D11DXVA2Manager to test for hardware support, and I would expect the transform to be doing all the necessary cleanup internally that we would also be expected to do.

Reporter

Comment 18

•

1 year ago

I can still reproduce with media.wmf.zero-copy-nv12-textures = false. This pref doesn't seem to have any effect on the test case. I tested a few times with and without restarting browser after changing the pref.

For AV1, the video player at the test site works differently and the usual approach with seeking doesn't work, the gpu threads don't go dormant immediately after the seek. The fastest way to repro with av1 is to reload the page 20 times. Then go back to the vp9 video, perform a seek, and carefully compare the MediaPDecoder thread timings with a clean run. I tested this a few times and the slowdown-per-av1-reload is about half of the slowdown-per-vp9-seek.

I said I can't reproduce it with h264. I tried again by reloading a random vimeo video 10 times, after which seeking in the vp9 video is slower. It accumulates faster than av1 because vimeo creates 6 decoders per page load.

I didn't check whether h264/av1 video becomes slower, I only checked that creating many h264/av1 decoders results in slower vp9 seeks.

(In reply to Zaggy1024 from comment #17)

(Might doing this also help with the performance of single-frame seeks on YouTube?)

That would be Bug 1501715. Performing a single-frame seek in a youtube video that has been recently playing doesn't create any new decoders, it's slow because it always starts decoding at the last keyframe, which may be hundreds of frames back.

Reusing decoders does have the potential to significantly improve pageloads. When I load vimeo at least 300ms is wasted creating decoders that are never used.

The fact that this is only one part of the performance regression makes me think that this is probably a driver issue, since my understanding is that the MFT would be internally create the same D3D11 decoder interface that we use in D3D11DXVA2Manager to test for hardware support, and I would expect the transform to be doing all the necessary cleanup internally that we would also be expected to do.

I came to the same conclusion, WMF must be creating a few decoders internally.

Flags: needinfo?(stefan.dessens)

Assignee

Comment 19

•

1 year ago

Would you mind help me check if disabling the pref gfx.direct3d11.reuse-decoder-device (then restarts Firefox) to see whether that helps? Doing that can fix the problem on my side, which makes me wonder whether the ID3D11Device incorrectly keeps all ID3D11VideoDecoder alive. Thanks!

Flags: needinfo?(stefan.dessens)

Reporter

Comment 20

•

1 year ago

Disabling gfx.direct3d11.reuse-decoder-device fixes the problem on my end as well. That's interesting.

Flags: needinfo?(stefan.dessens)

Assignee

Comment 21

•

1 year ago

Thanks for the confirmation. I'm going to report this issue to Microsoft and do other improvements on our side in the meanwhile.

Assignee

Comment 22

•

1 year ago

As the workaround exists, lower this bug to S3, but still keep it as P1.

Severity: S2 → S3

Assignee

Comment 23

•

1 year ago

Attached file Bug 1888354 - part1 : don't enter dormant state immediately after seeking. (obsolete) — Details

Assignee

Comment 24

•

1 year ago

Attached file Bug 1888354 - part1 : don't use the compositor device for the hw decoding capability check. — Details

We found an issue where the ID3D11VideoDecoder won't release its
underlying resources properly if the decoder iscreated from a compositor
device by ourselves. This problem has been observed with both VP9 and,
reportedly, AV1 decoders, it does not seem to affect the H264 decoder,
but the underlying decoder created by MFT seems not having this issue.

Therefore, when checking whether we can use hardware decoding, we should
use a non-compositor device to create a decoder in order to prevent
resource leaking that can significantly degrade the performance. For the
actual decoding, we will still use the compositor device if it's
avaiable in order to avoid video copying.

Depends on D206961

Assignee

Comment 25

•

1 year ago

Attached file Bug 1888354 - part2 : merge 'CreateDecoder()' into 'CanCreateDecoder()' to indicate the reason of creating decoder which is just for checking hw decoding capability. — Details

Depends on D206962

Sotaro Ikeda [:sotaro]

Comment 26

•

1 year ago

Sotaro, do you have any thought about what resources we might need to manually clear up if we enable zero-copy? Also, stefan, could you help me verify if disabling the pref media.wmf.zero-copy-nv12-textures works for you or not? Thank you.

I noticed were the followings.

IMFSample of ID3D11Texture2D needed to be kept alive during the ID3D11Texture2D.
- https://searchfox.org/mozilla-central/rev/6b39381c0056c0dff0820fffebedf9980adc8883/gfx/layers/D3D11TextureIMFSampleImage.h#91
All IMFSamples needed to be destroyed before destroying video MFTDecoder(Bug 1766203)

Flags: needinfo?(sotaro.ikeda.g)

Zaggy1024

Comment 27

•

1 year ago

With these patches, would we not still see resource leakage if the video playback itself restarts repeatedly on the compositor device?

It's definitely worth optimizing the hardware codec support checks on Windows, but I'm thinking it would be more efficient if we can simply skip calling D3D11DXVA2Manager::CanCreateDecoder(), since that presumably allocates some memory for the decoding on the CPU/GPU. If WMFDecoderModule::CanCreateMFTDecoder() and ID3D11VideoDevice::CheckVideoDecoderFormat() will suffice, then we can avoid the overhead of creating (and in the case of AV1, looking up) a decoder MFT, as well as that directly-created D3D11 decoder.

If ID3D11VideoDevice::CheckVideoDecoderFormat() may sometimes gives false positives, we could instead cache the results from D3D11DXVA2Manager::CanCreateDecoder() somewhere to still avoid the unnecessary work.

Perhaps these improvements should be done as a separate bug, though, if they will only be a partial solution?

Assignee

Comment 28

•

1 year ago

(In reply to Zaggy1024 from comment #27)

With these patches, would we not still see resource leakage if the video playback itself restarts repeatedly on the compositor device?

Indeed, I wasn't tested enough video decoder on the compositor device in the beginning, which made me think maybe the media foundation properly release resources. But after I test enough video decoders (100+) on the compositor device, I can see that the performance is degraded again.

Sotaro, as we already release all IMFSample in bug 1766203, could it be other leakage in the gfx texture side? If we couldn't find the leakage, I would recommend to disable reusing compositor device temporarily because the performance degradation is serious. I also reported this issue to Microsoft last week, but haven't heard anything from them yet. Thanks!

Flags: needinfo?(sotaro.ikeda.g)

Assignee

Comment 29

•

1 year ago

(In reply to Zaggy1024 from comment #27)

It's definitely worth optimizing the hardware codec support checks on Windows, but I'm thinking it would be more efficient if we can simply skip calling D3D11DXVA2Manager::CanCreateDecoder(), since that presumably allocates some memory for the decoding on the CPU/GPU. If WMFDecoderModule::CanCreateMFTDecoder() and ID3D11VideoDevice::CheckVideoDecoderFormat() will suffice, then we can avoid the overhead of creating (and in the case of AV1, looking up) a decoder MFT, as well as that directly-created D3D11 decoder.

Unfortunately, only checking WMFDecoderModule::CanCreateMFTDecoder() is not enough, which causes the bug 1859368. But I'm not sure if adding ID3D11VideoDevice::CheckVideoDecoderFormat() will make result more precise, maybe worth to try.

Sotaro Ikeda [:sotaro]

Comment 30

•

1 year ago

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

But after I test enough video decoders (100+) on the compositor device,

How did you test it? Does the problem happen with any GPUs?

Sotaro, as we already release all IMFSample in bug 1766203, could it be other leakage in the gfx texture side?

Sorry. I can't think of any off the top of my head.

Flags: needinfo?(sotaro.ikeda.g) → needinfo?(alwu)

Jim Mathies [:jimm]

Updated

•

1 year ago

Blocks: ttff

Assignee

Updated

•

1 year ago

Blocks: 1890622

Assignee

Comment 31

•

1 year ago

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

How did you test it? Does the problem happen with any GPUs?

I've filed bug 1890622 for a further investigation, and I will land current patches for the mitigation first.

In bug 1890622 comment0, I described the STR and also attached the profiled result in comment1. I have two graphic cards, and the issue only happens on Intel Xe. The reporter also uses Intel series (Intel UHD Graphic), so maybe this is Intel-only problem.

Flags: needinfo?(alwu)

https://hg.mozilla.org/mozilla-central/rev/3b9e4ebb76f8
https://hg.mozilla.org/mozilla-central/rev/84fd593fa5c5

Assignee

Updated

•

1 year ago

Blocks: 1890692

Phabricator Automation

Comment 32

•

1 year ago

Comment on attachment 9395657 [details]
Bug 1888354 - part1 : don't enter dormant state immediately after seeking.

Revision D206961 was moved to bug 1890692. Setting attachment 9395657 [details] to obsolete.

Attachment #9395657 - Attachment is obsolete: true

Phabricator Automation

Updated

•

1 year ago

Attachment #9395658 - Attachment description: Bug 1888354 - part2 : don't use the compositor device for the hw decoding capability check. → Bug 1888354 - part1 : don't use the compositor device for the hw decoding capability check.

Phabricator Automation

Updated

•

1 year ago

Attachment #9395660 - Attachment description: Bug 1888354 - part3 : merge 'CreateDecoder()' into 'CanCreateDecoder()' to indicate the reason of creating decoder which is just for checking hw decoding capability. → Bug 1888354 - part2 : merge 'CreateDecoder()' into 'CanCreateDecoder()' to indicate the reason of creating decoder which is just for checking hw decoding capability.

Pulsebot

Comment 33

•

1 year ago

Pushed by alwu@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/3b9e4ebb76f8 part1 : don't use the compositor device for the hw decoding capability check. r=sotaro https://hg.mozilla.org/integration/autoland/rev/84fd593fa5c5 part2 : merge 'CreateDecoder()' into 'CanCreateDecoder()' to indicate the reason of creating decoder which is just for checking hw decoding capability. r=media-playback-reviewers,padenot

tszentpeteri

Comment 34

•

1 year ago

bugherder

Status: NEW → RESOLVED

Closed: 1 year ago

status-firefox126: --- → fixed

Resolution: --- → FIXED

Target Milestone: --- → 126 Branch

Camelia Badau [:cbadau], Desktop Test Engineering

Updated

•

11 months ago

Flags: qe-verify+

Sotaro Ikeda [:sotaro]

Updated

•

11 months ago

Updated

•

11 months ago

Blocks: 1894058

Blocks: 1896823

Ryan VanderMeulen [:RyanVM]

Updated

•

10 months ago

Regressions: 1897006