Open Bug 2000470 Opened 8 months ago Updated 4 months ago

Youtube videos fail to play and seek

Categories

(Core :: Audio/Video, defect)

Product:
Core
Component:
Audio/Video
Version:
Firefox 147
Platform:
Desktop
Linux
Type:
defect

Tracking

()

People

(Reporter: george, Unassigned)

References

(Blocks 1 open bug)

Details

Attachments

(2 files)

seeking log
8.61 KB, text/plain
Details
playing log
8.47 KB, text/plain
Details

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:147.0) Gecko/20100101 Firefox/147.0

Steps to reproduce:

Try to play a Youtube Video. Or try to Seek in a Youtube video.

Actual results:

Video fails to play, or takes a long time to play. When I try to seek it just fails.

Expected results:

Video should just play.

I use Linux kernel 6.17.8 and mesa 25.3.0

I get the following console warnings in the browser

Media resource blob:https://www.youtube.com/(any guid here) could not be decoded. watch
This error message will be blank when privacy.resistFingerprinting = true.  If it is really necessary, please add it to the whitelist in MediaError::GetMessage: Error GMP callback (GMPErr:7) 6 base.js:12262:19
WEBGL_debug_renderer_info is deprecated in Firefox and will be removed. Please use RENDERER. base.js:11517:165
Media resource blob:https://www.youtube.com/(any guid here) could not be decoded, error: Error Code: NS_ERROR_DOM_MEDIA_DECODE_ERR (0x806e0004)
Details: Error GMP callback (GMPErr:7)

Media resource blob:https://www.youtube.com/(any guid here) could not be decoded, error: Error Code: NS_ERROR_DOM_MEDIA_FATAL_ERR (0x806e0005)
Details: auto mozilla::MediaChangeMonitor::CreateDecoderAndInit(MediaRawData *)::(anonymous class)::operator()(const MediaResult &) const: Unable to create decoder
Component: Untriaged → Audio/Video
OS: Unspecified → Linux
Product: Firefox → Core
Hardware: Unspecified → Desktop

Same here and it spams the crash logs as well and spikes my CPU usage. It plays eventually for me but consistent high CPU usage. When I try to do anything like go back more than 5 seconds for example the playback fails, same when trying to go forward using the arrow keys as well.
Linux 6.17.8 and Mesa 25.3.0 as well. AMD CPU & iGPU.
images

I wonder if it's not related to https://bugzilla.mozilla.org/show_bug.cgi?id=1962139

The GMP error suggests you are getting an H264 video, we are using OpenH264, and the plugin is failing to decode with a callback:
https://searchfox.org/firefox-main/rev/70425199e9a5fa80aa7419fa51763013a67226e1/dom/media/gmp/gmp-api/gmp-errors.h#44
https://searchfox.org/firefox-main/rev/70425199e9a5fa80aa7419fa51763013a67226e1/dom/media/gmp/GMPVideoDecoderChild.cpp#131

You can turn on extra logging from OpenH264 by enabling the library logs, e.g. MOZ_LOG="GMPLibrary:5" /path/to/firefox or using about:logging, using the Media playback setting and appending ,GMPLibrary:5 to the end. Could you please reproduce and supply that log? Thanks!

Blocks: openh264-integration
Flags: needinfo?(george)
Attached file seeking log —
Attached file playing log —

Sure, I got two logs, first is when the seeking fails while the video is playing. Second is when the video refuses to play at all. I pasted them as attachments

Flags: needinfo?(george)

There are two problems. The first appears to be the sandbox killing the RDD process, which might be why we are falling back to OpenH264?

[92888] Sandbox: seccomp sandbox violation: pid 92888, tid 92906, syscall 72, args 28 1027 12 0 139719018123280 15016672.  Killing process.
[GFX1-]: VideoBridgeParent receives IPC close with reason=AbnormalShutdown

And the second, where OpenH264 failures the decoding:

[OpenH264] this = 0x0x7f1288388000, Info:DecodeFrameConstruction(): will output first frame of new sequence, 1920 x 1088, crop_left:0, crop_right:0, crop_top:0, crop_bottom:4, ignored error packet:0.
[OpenH264] this = 0x0x7f1288388000, Warning:referencing pictures lost due frame gaps exist, prev_frame_num: 4, curr_frame_num: 15
[OpenH264] this = 0x0x7f1288388000, Info:decode failed, failure type:34

where error 34 or 0x42 is a combination of dsRefLost:
https://github.com/cisco/openh264/blob/cf568c83f71a18778f9a16e344effaf40c11b752/codec/decoder/core/src/decoder_core.cpp#L1474
https://github.com/cisco/openh264/blob/cf568c83f71a18778f9a16e344effaf40c11b752/codec/decoder/core/src/decoder_core.cpp#L307

and dsRefListNullPtrs:
https://github.com/cisco/openh264/blob/cf568c83f71a18778f9a16e344effaf40c11b752/codec/decoder/core/src/decoder_core.cpp#L2930

The latter issue needs an issue filed with one the OpenH264 issue tracker.

thanks, I've filed an issue at the OpenH264 Github repository

It appears to be an innocent enough syscall for checking if two fds are the same, perhaps the underlying libc is using it on your system:
https://github.com/torvalds/linux/commit/c62b758bae6af16fee94f556091fa74883a96b1e

Often userspace needs to know whether two file descriptors refer to the
same struct file. For example, systemd uses this to filter out duplicate
file descriptors in it's file descriptor store (cf. [1]) and vulkan uses
it to compare dma-buf fds (cf. [2]).

The only api we provided for this was kcmp() but that's not generally
available or might be disallowed because it is way more powerful (allows
ordering of file pointers, operates on non-current task) etc. So give
userspace a simple way of comparing two file descriptors for sameness
adding a new fcntl() F_DUDFD_QUERY.

Oh, the DMA buf impl is probably using it given the description. That would suggest you do indeed have hardware H264 decoding and it would work if we allow that. I'll put together a build for you to try.

Can you try the build from this try job to see if H264 decoding works?
https://treeherder.mozilla.org/jobs?repo=try&revision=0c9b221b55ca4de4eac0006d296a0cdee12f9a05

Flags: needinfo?(george)

(In reply to Andrew Osmond [:aosmond] (he/him) from comment #13)

Can you try the build from this try job to see if H264 decoding works?
https://treeherder.mozilla.org/jobs?repo=try&revision=0c9b221b55ca4de4eac0006d296a0cdee12f9a05

I'm confused, is there a button to download the build? I can't find any.

Flags: needinfo?(george)

This is a direct link to the artifact:
https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/FbOqVjElTBeaF65-d5zPag/runs/0/artifacts/public/build/target.tar.xz

Flags: needinfo?(george)

Yes, Youtube works fine with this build. However, the codecs are either AV1 or VP9 so I can't verify the openh264 working. MOZ_LOG="GMPLibrary:5" returns nothing (as it should, I think)

Flags: needinfo?(george)

I tried a local .mp4 h264 and it's working fine with this build as well, while it's failing on nightly. In this case, the fix looks like to be working for both issues. Should I close the issue on openh264 github?

(In reply to George Sofianos from comment #17)

I tried a local .mp4 h264 and it's working fine with this build as well, while it's failing on nightly. In this case, the fix looks like to be working for both issues. Should I close the issue on openh264 github?

Nope, those are separate problems. I'll leave this bug open for tracking the OpenH264 issue on the other side. With my patch, you end up using hardware decoding so you avoid using OpenH264 at all. I'll file a new bug to get my patch landed.

S4, depends on OpenH264 fix.

Severity: -- → S4
See Also: → 2001472
Status: UNCONFIRMED → NEW
Ever confirmed: true

(In reply to Andrew Osmond [:aosmond] (he/him) from comment #19)

S4, depends on OpenH264 fix.

You are saying this isn't important because we can't fix it. But our defect severity scoring system is orthogonal to who needs to fix it. It might still be an S4, if this affects only atypical configurations or a small group of users, but at this point, it's hard for a reader to understand why it's S4 :(

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: