Open Bug 2062266 Opened 1 month ago Updated 16 days ago

Video playback errors

Categories

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

Product:
Core
Component:
Audio/Video: Playback
Version:
Firefox 153
Type:
defect

Tracking

()

Status:
UNCONFIRMED

People

(Reporter: x3x7apps, Unassigned)

References

(Blocks 3 open bugs)

Details

Attachments

(4 files)

Sample faulty video playback
3.42 MB, video/mp4
Details
about:support
237.31 KB, text/plain
Details
about:support playback functional
221.09 KB, text/plain
Details
Activating right click menu window results in proper playback
8.52 MB, video/mp4
Details

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

Steps to reproduce:

Using Fedora Firefox firefox-153.0.3-1.fc44.x86_64.rpm as well as a custom build one with same version I have playback errors with the video below

https://www.youtube.com/shorts/GFco2LtZ2Ls

Actual results:

The video playback is buggy having many display errors.

Expected results:

Proper video playback.
(google-chrome-stable-150.0.7871.186-1.x86_64 works fine for this test)

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.

Component: Untriaged → Audio/Video: Playback
Product: Firefox → Core

The problem is also with Firefox 153.0.4

This seems to be a problem with the browser profile. With a different profile the playback is fine. I do not know what is the setting causing it.

If I download the video (yt-dlp) then playback is fine when opening the media stream in Firefox. The problem has to do with playback within the Youtube webpage.

I have created a new profile and when using it the video playback is faulty. Maybe a Firefox expert can reproduce the problem this way.

I have several profiles and the one with the failure seems to be due to doing an about:support > Give Firefox a tune up (Refresh Firefox...) The older profiles work fine but new ones and refreshed ones are faulty.

Thanks for the report, and for including the cross-browser comparison — that is useful.

Analysis

The clip renders correctly in Chrome on the same machine, and the corruption reproduces both with the Fedora RPM and with your own build of 153.0.3, so this does not look like a distro packaging difference. On Linux, display errors of this kind (garbled or blocky frames rather than a hard playback failure) most often come from the hardware-accelerated decode path (ffmpeg/VAAPI) mis-decoding a particular stream, rather than from playback logic. The bug currently has no about:support and no media log, so the GPU and driver in use, and which decoder was actually selected for this video, are both unknown — those are the pieces needed to confirm or rule that out.

Next Steps

  1. Please capture a profile: open about:logging, on the Logging presets tab choose the "Media playback" preset, and under Logging output select "Logging to the Firefox Profiler". Click Start Logging, reproduce the issue from a fresh page load, then click Stop Logging — the captured profile opens in the Firefox Profiler. Click Upload Local Profile (the share button) and paste the resulting share URL here. The instruction video walks through it. If you have privacy concerns about the profile or the media content, email it to media-alerts@mozilla.com instead.

  2. A quick isolation test: in about:config, set media.hardware-video-decoding.enabled to false, then fully close every Firefox window and restart before testing — the change does not take effect until then. Replay the same short and let us know whether the corruption is gone. This separates the hardware (VAAPI) decode path from the software one and narrows things down considerably. Please set the pref back to true afterwards.

  3. Please attach your about:support data — open about:support, click Copy raw data to clipboard, and paste it here or attach it as a file. The GPU model, Mesa/driver version, and the Decision Log section are the relevant parts.

  4. If you can, attach a short screen recording or a screenshot showing the corruption. The visual signature (blocky macroblocks vs. torn or shifted frames vs. wrong colours) points at quite different causes.

Lastly, does this reproduce on other YouTube videos and on other sites, or only on this one short?

:stransky, could you take a look? This is video display corruption on Fedora 44 with Firefox 153.0.3 that Chrome does not show on the same machine — curious whether you have noticed anything relevant on the Linux HW decoding side recently.

Blocks: linux-playback, yt-playback
Flags: needinfo?(x3x7apps)
Flags: needinfo?(stransky)

Please try plain Mozilla binaries to mitigate Fedora specific bug:
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems#Testing_Mozilla_binaries
Thanks.

Flags: needinfo?(stransky)

I have used Firefox from here https://ftp.mozilla.org/pub/firefox/releases/153.0.4/linux-x86_64/en-US/firefox-153.0.4.tar.xz and I did run it as instructed in your link. The video playback is still faulty.

As requested by media-triaging-bot I tried media.hardware-video-decoding.enabled set to false and the playback was still faulty.

The about:support data is also attached.

Flags: needinfo?(x3x7apps)
Attached file about:support —

This is an about:support data from a Firefox profile which plays properly the video.

Logging data requested by media-triaging-bot https://share.firefox.dev/4cfCKsM

Another video with similar problem https://www.youtube.com/shorts/7vjlnHL1-B8

Thanks for the follow-up, and for the two about:support dumps in particular — a working profile and a faulty profile captured on the same machine with the same binary is the most useful artifact on this bug.

Analysis

This is not a Fedora packaging issue. Comment 9 confirms the corruption reproduces with the official Mozilla firefox-153.0.4.tar.xz linux-x86_64 build, so :stransky's question is answered — the problem is in Gecko, not in the Fedora build.

Hardware decoding is not involved. The about:support Decision Log shows HARDWARE_VIDEO_DECODING: unavailable ("Blocklisted by gfxInfo" → "Force disabled by gfxInfo") on the NVIDIA RTX A5000 / 595.84 / X11 setup, and Codec Support Information lists every codec as SWDEC with no HWDEC entries at all. So no hardware decode was ever engaged, and the media.hardware-video-decoding.enabled=false test correctly changed nothing. VA-API is not a factor here.

What the profile shows. The capture in comment 12 identifies the stream and the decoder precisely: video/av1, 1080x1080, 8-bit YUV420P, BT.709 limited range, delivered over MSE at 60 fps, decoded in software in the RDD process by the bundled ffvpx driving libdav1d (FFVPX: Using preferred software codec libdav1d). The decode pipeline itself looks healthy — 472 frames decoded at a steady 16.5 ms cadence (a full 60 fps), no NS_ERROR_DOM_MEDIA_* failures, and RDD process CPU peaking at under 5%. So the picture is being produced on time and without decode errors, yet it renders wrong.

A note for anyone reading the log later: the capture contains 472 Failed to copy image data warnings, one per frame. These are a false positive and should not be chased — MediaResult::Logged() emits its message unconditionally without inspecting the nsresult it is handed, so that line is printed on every successful copy too. The absence of any downstream decode error is in fact positive evidence that the copies succeeded.

Why one profile works and the other does not. Diffing the two about:support dumps: same binary (153.0.4, buildID 20260811133109), same kernel, same GPU and driver, same compositor and WebRender feature log, and identical Codec Support Information. There is no media.* or gfx.* preference difference between them at all — the only deltas are housekeeping timestamps, some mousewheel settings, and storage-migration flags. So the working-vs-faulty difference is not a Firefox setting. The most likely explanation is client-side YouTube state (cookies / local storage): YouTube buckets the fresh profile into AV1 and keeps the older profile on a different codec. That would also explain comment 4, where a yt-dlp copy of the same video plays back correctly as a local file.

The leading hypothesis is therefore that something specific to the AV1 output path is at fault rather than the decode itself. Notably, libdav1d installs its own picture allocator and so bypasses Gecko's customised get_buffer2 buffer-allocation hook, which means AV1 frames are copied into a recycled shared-memory image pool instead of being decoded straight into shared memory the way VP9 and H.264 are. Buffer reuse in that pool is the next thing to examine.

Next Steps

A few short checks would confirm or eliminate that hypothesis quickly. Each preference change needs every Firefox window closed and the browser restarted before testing, and please reset them afterwards.

  1. The most valuable single data point: on both profiles, play the same short, right-click the video and choose Stats for nerds, and paste the Codecs line from each. This directly confirms whether the working profile is being served a different codec.

  2. On the faulty profile, set media.av1.enabled to false in about:config and restart. This makes YouTube fall back to VP9. If the corruption disappears, the problem is AV1-specific — and this doubles as a usable workaround in the meantime.

  3. Then set media.av1.enabled back to true and instead set layers.recycle-allocator.rdd to false, and restart. If that clears the corruption, the fault is in shared-memory buffer reuse rather than in the decoder, which would be a very useful distinction.

  4. Only if neither of the above helps: set media.rdd-process.enabled to false and restart, which moves decoding into the content process entirely.

The sample recording in comment 5 is already attached and does not need re-uploading.

:stransky, for your awareness — this turned out not to be Fedora-specific and not to be a hardware-decode or VA-API problem; hardware decoding is blocklisted on this configuration and the failing path is software AV1 through bundled ffvpx/libdav1d.

Blocks: AV1
Severity: -- → S2
Flags: needinfo?(x3x7apps)
Priority: -- → P2
Severity: S2 → S3
  1. Same vide codec is used for both profiles. Codecs line is av01.0.08M.08
  2. media.av1.enabled to false does not solve the problem. Codecs is now vp09.00.51.08... but same playback errors.
  3. There is no layers.recycle-allocator.rdd config option. I used layers.recycle-allocator-rdd instead. No change if this is set to false.
  4. If media.rdd-process.enabled is false then Youtube complains that "Your browser can't play this video."
Flags: needinfo?(x3x7apps)

If I clear Youtube cookies from the working profile the video still plays properly.

The problem is also with latest Firefox 154.0.

I tested several versions of Mozilla Firefox, 140.0, 150.0, 153.0, 153.0.4 by creating a new profile for each and loading the 1st faulty URL. To my surprise all of them worked properly. Even the last one which previously failed with a new profile this time worked.

So far all I can write is that there is some issue with my old profile which has been refreshed (doing an about:support > Give Firefox a tune up (Refresh Firefox...) ). New profiles work properly.

Another thing I noticed with the faulty playback is that if I do a mouse click with the right button then the "Copy video URL, ... Stats for nerds" menu window appears and behind it the video now plays back properly. As long I keep the menu window on, the playback is fine. In short, the bug seems to be about video presentation and not decoding (as it has been tested with two video codec options with same results).

I imagined that a temporary fix is to export passwords and bookmarks, create a fresh profile and import the exported data. On a first test this did not work since after all this the playback got bad (It was very sensitive when resizing the window during playback). On a second trial playback is fine for the time being.

You may try profile refresh feature - but make sure the original profile is saved somewhere so it can be restored in case of failure.

I am reluctant to do the refresh again since that was what caused the playback errors. Creating a new profile and updating bookmarks and passwords looks to work so far. Would be nice to be able to import also the history of forms filled up. Is there a specific profile file to be copied to have this history updated?

Okay, if the new profile works for you I don't need any other info and we can close this one.

Do you know how to copy the forms history from the old profile?

Thank you for the link. I can use the info for much easier profile updates than the regular way of exporting bookmarks and passwords and importing them back in the new profile. There is also a formhistory.sqlite database that seems to be the form data I am looking for.

I assume you do not have the time to test a profile refresh and playback of the faulty URL. You can close the bug if you like although I would have appreciated if a solution can be found for why there are video playback errors with a refreshed profile. Would have been nicer to find what configuration needs to be changed so playback is proper.

I was wrong that I have a 100% working new profile. This video failed in my new settings https://www.youtube.com/shorts/MAiGrw0phaQ. However, it is working properly on my old settings.

All of the failures happen on Youtube shorts. Luckily, the regular videos work well (with some exceptions as found on this site).

Something happened in Firefox 155.0. Videos are now playing properly in both profiles.

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

Attachment

General

Creator:
Created:
Updated:
Size: