Bugzilla

(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](https://searchfox.org/mozilla-central/rev/5df192b9edee971a1ab06ff9ef688d92c21a92c1/dom/media/MediaDecoderStateMachine.cpp#791-793) 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](https://searchfox.org/mozilla-central/rev/5df192b9edee971a1ab06ff9ef688d92c21a92c1/modules/libpref/init/StaticPrefList.yaml#10460).

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.

(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.

(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](https://searchfox.org/mozilla-central/rev/5df192b9edee971a1ab06ff9ef688d92c21a92c1/dom/media/MediaDecoderStateMachine.cpp#791-793) 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](https://searchfox.org/mozilla-central/rev/5df192b9edee971a1ab06ff9ef688d92c21a92c1/modules/libpref/init/StaticPrefList.yaml#10460).

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.