1947948 - youtube somtime switch codec av1 to vp9 when seek video and make video freeze a little bit

Status: UNCONFIRMED

(Core :: Audio/Video: Playback, defect)

Description

[mix5003]

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

Steps to reproduce:

1. go to video that use av1 in youtube (for example https://www.youtube.com/watch?v=yHhdTRVvDFU)
2. use 1080p and 2x (i am not sure is this relate or not)
3. seek video. for me use left or right arrow in keyboard

Actual results:

sometime after seek video switch to vp09 codec and before that switch video freeze a little bit.

this is video when issue happens: https://youtu.be/HDN6_mdf9Ts
this is profiler in media profile: https://share.firefox.dev/41chdfn

Expected results:

it should not switch codec, or at least video should more smoothly.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Audio/Video: Playback' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[az [:az]]

Interesting, it doesn't look like you're really having frame drops before it switches over. Could you test with 1x as well and let us know if you encounter the same problem? Is this new behavior for you? If it's changed recently, using mozregression would allow us to find the exact changes that caused this behavior to occur.

Comment 3

[mix5003]

i can not reproduce by seek time method in 1x.

i think step to reproduce at my first comment is not reliable. so mozregression may produce incorrect result.
i use step to reproduce above to try but give me different result 3 times.

i found another way to reproduce but it up to you luck again, but i think it easy to reproduce.
i use this step to reproduce and use with mozregression

1. open 1080p youtube with av1 video
2. use 2x speed for easy reproduce (but if you combine with popover 1x may cause issue too)
3. fast open and close picture in picture video 10 times, seek video randomly order

i use above step in mozregression and it give me same result 3 times (round 2 and 3 i scope to date 2024-01-01 to 2024-02-29 only)

2025-02-15T17:42:22.497000: DEBUG : Found commit message:
Bug 1882001 - Re-enable zero copy video of hardware decoded video with NVIDIA GPUs to early beta on Windows r=jrmuizel,gfx-reviewers

Video overlay without ZeroCopyNV12Texture with NVIDIA GPUs is enabled until release by  Bug 1851625. Then is seems OK to enable zero copy video of hardware decoded video with NVIDIA GPUs to early beta.

Differential Revision: https://phabricator.services.mozilla.com/D202693

2025-02-15T17:42:22.497000: DEBUG : Did not find a branch, checking all integration branches
2025-02-15T17:42:22.500000: INFO : The bisection is done.
2025-02-15T17:42:22.501000: INFO : Stopped

but i think the commit above not a root cause because i can reproduce in release channel (firefox 135) too.

and when problem happend i found this message in mozregression

2025-02-15T11:42:31.784000: INFO : b'[Child 29460, MediaDecoderStateMachine #1] WARNING: Decoder=1e8dc217700 Decode error: NS_ERROR_DOM_MEDIA_DECODE_ERR (0x806e0004) - RefPtr<MediaDataDecoder::DecodePromise> __cdecl mozilla::WMFMediaDataDecoder::ProcessError(HRESULT, const char *): MFTManager::Output(2):c00d7170: file /builds/worker/checkouts/gecko/dom/media/MediaDecoderStateMachineBase.cpp:167'

Comment 4

[mix5003]

Attachment: TroubleshootingInfo.txt

Comment 5

[mix5003]

Attachment: debug_log.txt

i am not sure is this help or not.
this is log from mozregression. that i use build type debug to reproduce issue.

i hope it help you.

Comment 6

[mix5003]

but i think the commit above not a root cause because i can reproduce in release channel (firefox 135) too.
i forgot to tell, it can but more more harder.

Comment 7

[az [:az]]

Thanks for the info! :alwu, would you have any thoughts here?

Comment 8

[Alastor Wu [:alwu]]

After checking your profile in the comment0, a decode error happened for the AV1 on the WMF decoder, which should be the reason why Youtube switched to vp9. How easy this error could happen on your device? Does this issue only happen when doing 2x? Can you reproduce this issue on other videos as well?

In addition, if you can reproduce this issue constantly, could you try to disable the pref media.wmf.zero-copy-nv12-textures to see if it helps? Thanks!

Comment 9

[mix5003]

1. this is easy to reproduce by use seek in 2x video or pop picture in picture and send it back to tab
2. at this time i can reproduce at 1x too. but i normally play video with 1.5x or 2x. (and 0.75x can reproduce too)
3. yes i can reproduce this on other av1 video in youtube as well
4. set media.wmf.zero-copy-nv12-textures to false. help to prevent this issue.

Comment 10

[Alastor Wu [:alwu]]

Hi, Sotaro, this sounds like a zero copy issue, any thought about this? should we add this driver/card to the block list? Thanks!

Comment 11

[Sotaro Ikeda [:sotaro]]

I wonder if the problem might be a bit similar to Bug 1931328 and Bug 1920061. During seek, we might need to return video frames to hw video decoder.

Comment 12

[mix5003]

a little update.
for now i think this issue has been fixed by Bug1936128
but if set media.ffvpx-hw.enabled to false the issue still exists