Closed Bug 1935655 Opened 2 months ago Closed 16 days ago

The sound does not seem to work on Fandom website for aarch64 build while it works for SNAP

Categories

(Release Engineering :: General, defect, P3)

Product:
Release Engineering
Component:
General
Platform:
Desktop
Linux
Type:
defect

Tracking

(firefox135 affected)

Status:
RESOLVED WONTFIX
Tracking Flags:
Tracking Status
firefox135 --- affected

People

(Reporter: danibodea, Unassigned)

References

(
URL
)

Details

Attachments

(2 files)

Screenshot from 2024-12-06 15-05-13.png
1.97 MB, image/png
Details
left 133 SNAP - media support - 135 tar.bz - right.png
1.66 MB, image/png
Details

Note

  • When the user plays videos from Fandom articles, he will notice that the sound does not work.

Found in

  • Nightly v135.0a1 aarch64

Affected versions

  • Nightly v135.0a1 aarch64

Tested platforms

  • Affected platforms: Ubuntu24.04.1 LTS + aarch64
  • Unaffected platforms: not tested on Windows/MacOS + aarch64

Steps to reproduce

  1. Load a Fandom article with a video:
    https://dcextendeduniverse.fandom.com/wiki/Harley_Quinn
  2. Play the video and make sure the sound is enabled.

Expected result

  • Sound is playing.

Actual result

  • The sound is NOT playing.

Regression range

  • This issue also occurs on the older Nightly v127.0a1 (aarch64) and Nightly v130.0a1 (aarch64).

Additional notes

  • This issue does not occur in the case of a SNAP installed build Release v133.0 (aarch64):
    Name Firefox
    Version 133.0
    Build ID 20241125204259
    Distribution ID canonical-002
    User Agent Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:133.0) Gecko/20100101 Firefox/133.0
    OS Linux 6.11.0-1001-asahi-arm #1-Ubuntu SMP PREEMPT_DYNAMIC Sat Sep 28 14:42:09 UTC 2024
  • The issue reproduces on Nightly v135.0a1 aarch64 built:
    Name Firefox
    Version 135.0a1
    Build ID 20241206092831
    Distribution ID -
  • It is important to mention that a different video players are observed in these 2 browser versions.

Notice that different video players are observed in these 2 browser versions; Left is SNAP V133 and right is aarch64 v135.0a1.

URL: https://dcextendeduniverse.fandom.com...
Severity: -- → S2
status-firefox133: --- → affected
status-firefox134: --- → affected
status-firefox135: --- → affected
OS: Unspecified → Linux
Hardware: Unspecified → Desktop
See Also: → 1934634

Does media/sound work on other sites?

Flags: needinfo?(dbodea)

Vimeo: A similar issue also occurs in the case of Vimeo; the video is not played back at all (shows error: "The player is having trouble. We’ll have it back up and running as soon as possible.") on Nightly v135.0a1 .tar.bz aarch64 while it is played back correctly on Release v133.0 SNAP aarch64.

Youtube: This issue does NOT occur in the case of Youtube videos.

Netflix: does not play videos on either of these browsers (but I suspect this is because of the lack of Widevine):

  • Widevine cannot be enabled on Release v133 aarch64 SNAP.
  • Widevine does not install on Nightly v135.0a1 aarch .tar.xz.

Other video platforms will be tested and documented during the test run.

Flags: needinfo?(dbodea)
Hardware: Desktop → ARM64

A similar issue is found on the https://www.uol.com.br/ website:

  • The video on the main page is being played with sound correctly on Release v133.0 SNAP aarch64 while it is not played at all on Nightly v135.0a1 aarch64 .tar.xz .
  • The videos from an article are being played with sound on both systems.

Please let us know if any of the newly observed issues from this report should be logged separately.

Can you capture a profile, using the media playback preset in about:logging?

The whole system crashes every time when attempting to upload the profile captured using the fandom article so I am not able to provide it. No crash is visible in about:crashes.

I have provided another media playback profile using Vimeo (which does not play the videos at all): https://share.firefox.dev/4fbfvP3

Please let me know if I can help further.

A similar issue can be observed in the case of live video and non-live videos from BBC:

Please let us know if any of the newly observed issues from this report should be logged separately.

(In reply to Daniel Bodea [:danibodea] from comment #3)

This issue also occurs in the case of Vimeo, while it does not occur in the case of Youtube.

Netflix does not play videos on either of these browsers (but I suspect this is because of the lack of Widevine):

  • Widevine cannot be enabled on Release v133 aarch64 SNAP.
  • Widevine does not install on Nightly v135.0a1 aarch .tar.xz.

Other video platforms will be tested and documented during the test run.

We don't have a Linux ARM64 Widevine plugin. Google does distribute one with ChromeOS, but my understanding is that it needs symbols they added or are only present in libbionic and wasn't intended for generic Linux. We might be able to make it work if there was sufficient need.

We do distribute OpenH264 though, so that should work.

A similar issue can be found on ESPN:
The videos on the main page are not played in either of the 2 browsers:

  1. In Nightly v135.0a1 aarch64 .tar.bz simply shows the error "No compatible source was found for this media."
  2. In Release v133.0 aarch64 SNAP keep freezing when attempting to play the video and eventually shows the error: "The media could not be loaded, either because the server or network failed or because the format is not supported."

Please let us know if any of the newly observed issues from this report should be logged separately.

(In reply to Daniel Bodea [:danibodea] from comment #6)

The whole system crashes every time when attempting to upload the profile captured using the fandom article so I am not able to provide it. No crash is visible in about:crashes.

I have provided another media playback profile using Vimeo (which does not play the videos at all): https://share.firefox.dev/4fbfvP3

Please let me know if I can help further.

I see this for an mp4 with av1:
(MediaFormatReader) MediaFormatReader[ffffaeba3d00] ::OnDemuxFailed: Failed to demux video, failure:NS_ERROR_DOM_MEDIA_WAITING_FOR_DATA

Also the video doesn't have audio?
(MediaDecoder) MediaDecoder[ffffa5296500] MetadataLoaded, channels=0 rate=0 hasAudio=0 hasVideo=1

Looks more like a codec issue than an audio issue. Are mochitests passing for all codecs?

What does about:support's media section look like?

Flags: needinfo?(dbodea)

(In reply to Julien Cristau [:jcristau] from comment #11)

What does about:support's media section look like?

I have attached about:support information for both these browsers.

Flags: needinfo?(dbodea)

(In reply to Daniel Bodea [:danibodea] from comment #6)

The whole system crashes every time when attempting to upload the profile captured using the fandom article so I am not able to provide it. No crash is visible in about:crashes.

I have provided another media playback profile using Vimeo (which does not play the videos at all): https://share.firefox.dev/4fbfvP3

Please let me know if I can help further.

I have managed to finally capture a profile while reproducing the issue on Fandom website: https://share.firefox.dev/41niNM3
I have set the "media playback" Logging preset, then pressed "Start Logging", then loaded and played the Harley Quin video, let it play the ads twice with no sound, then I closed the tab, and captured the profile.
Furthermore, to upload the profile to the server, I had to deselect the checkboxes related to "extension information" and "resource URLs and paths" before it would allow me to upload it.
I have to mention that a crash report was reported, but it could not be submitted (Report ID: 5c1003cb-0672-6e7a-e5cf-642f63dded4e).

I've re-uploaded the profile with all checkboxes selected here: https://share.firefox.dev/4ihbwn7

The original issue is also reproduced on Facebook Reels and Facebook Videos: the videos are played back with no sound on Nightly v135.0a1 aarch64 .tar.bz while they are correctly played back with sound on Release v133.0 aarch64 SNAP.

The original issue is also reproducible with Instagram videos (like this one): the videos are played back with no sound on Nightly v135.0a1 aarch64 .tar.bz while they are correctly played back with sound on Release v133.0 aarch64 SNAP.

The original issue also reproduces on twitter (https://x.com/): Nightly v135.0a1 aarch64 does not play videos with sound.

The original issue also occurs on Whatsapp: Nightly v135.0a1 aarch64 does not play videos with sound.

I dont have a running aarch64 system with ubuntu right now, any recent changes that may be related?

Flags: needinfo?(seb128)
Flags: needinfo?(nathan.teodosio)

Can you test with core24 stable? $ sudo snap refresh --channel=candidate/core24 firefox I'm worried this may be due to core24 on nightly

Flags: needinfo?(dbodea)
Flags: needinfo?(seb128)
Flags: needinfo?(nathan.teodosio)
Flags: needinfo?(dbodea)

Of course. I have reinstalled Firefox Release using command: sudo snap install --channel=candidate/core24 firefox
Then I retested the websites mentioned. All videos were played back with sound as expected.
The only difference I observed is with the video on the main page of ESPN; the video was correctly played back in contrast with the errors seen in the non-core24 Release browser.

Given the similar results, I tend to exclude core24 from being the cause of the issues seen in Nightly v135.0a1.

I need to ask: How can I verify that the build is indeed core24 or not (after installation)?

Thanks!

Flags: needinfo?(lissyx+mozillians)

(In reply to Daniel Bodea [:danibodea] from comment #21)

Of course. I have reinstalled Firefox Release using command: sudo snap install --channel=candidate/core24 firefox
Then I retested the websites mentioned. All videos were played back with sound as expected.
The only difference I observed is with the video on the main page of ESPN; the video was correctly played back in contrast with the errors seen in the non-core24 Release browser.

Given the similar results, I tend to exclude core24 from being the cause of the issues seen in Nightly v135.0a1.

I need to ask: How can I verify that the build is indeed core24 or not (after installation)?

Thanks!

sorry, i removed the needinfo and hide my comments because i misread the bug at first, i thought the issue was on snap, so disregard my messages :)

Flags: needinfo?(lissyx+mozillians)

(In reply to Andreas Pehrson [:pehrsons] from comment #10)

Looks more like a codec issue than an audio issue. Are mochitests passing for all codecs?

Can you tell me how I can verify whether codecs are properly installed? What are these mochitests?

Thanks!

Flags: needinfo?(apehrson)

(In reply to Daniel Bodea [:danibodea] from comment #21)

I need to ask: How can I verify that the build is indeed core24 or not (after installation)?

$ snap connections firefox | grep gnome
(42 is core22, 46 is core24)

(In reply to Daniel Bodea [:danibodea] from comment #23)

(In reply to Andreas Pehrson [:pehrsons] from comment #10)

Looks more like a codec issue than an audio issue. Are mochitests passing for all codecs?

Can you tell me how I can verify whether codecs are properly installed? What are these mochitests?

Thanks!

about:support should list all supported codecs, but per comment 12 they seem fine, except for H264 and AAC. Not sure if they're the source of your problems. But then the report is for audio only, not video.

Mochitests are the integration tests we run in CI. With a local build you do ./mach mochitest dom/media/test for media playback mochtiests. Julien, do we run any for this platform?

If you could record a profile while you reproduce the issue, we'd have something to debug. Please use a fresh Firefox instance when recording so there are not so many content processes - it becomes hard to find the right one. And keep it short, or there might be so much data it won't be able to upload.

I do webrtc normally and this seems like playback issues. I'll forward your needinfo to some playback folks so they can continue the investigation.

Flags: needinfo?(karlt)
Flags: needinfo?(jcristau)
Flags: needinfo?(cchang)
Flags: needinfo?(apehrson)

(In reply to Andreas Pehrson [:pehrsons] from comment #25)

Mochitests are the integration tests we run in CI. With a local build you do ./mach mochitest dom/media/test for media playback mochtiests. Julien, do we run any for this platform?

Not yet, no. :/

Flags: needinfo?(jcristau)
Blocks: 1934634
See Also: 1934634 →
See Also: → 1936055

I've also discovered the following websites with a similar problem:

  • Reddit (test page)
  • TikTok
  • Linkedin
  • Amazon (
    - videos in descriptions of products play without sound
    - videos in the presentation carousel of products don't play at all
  • IMDB
  • Weather.com
  • microsoft.com (main page video does not play)
  • apple.com (videos don't play at all)

This issue was also observed on:

These examples don't play at all in Fx135, but they play in Fx133.

status-firefox133: affected → ---
status-firefox134: affected → ---

Does this arm64 machine have ffmpeg/libavcodec installed with AAC/AVC(H264) support? If no, could you install ffmpeg and try again?

I don't know how to verify that. Can you help me?

Flags: needinfo?(apehrson)

(commands are for an Ubuntu terminal)
check if installed: apt list ffmpeg --installed (nothing listed means not installed)
install: sudo apt install ffmpeg
(when installed) list codecs: ffmpeg -decoders (look for aac and h264)

Flags: needinfo?(apehrson)

According to the instructions it appears it was not installed, so I ran the second command to install it.
After installation I listed the codecs using the third command and checked for the mentioned codecs: both AAC and h264 are now present.

I have retested all the mentioned sources above and I can confidently say that the issue no longer reproduces in Nightly v135.0a1.

Does this mean that the issue is invalid? Why did it only occur on Fx135, before the installation of ffmpeg? Thanks, Andreas!

Flags: needinfo?(apehrson)

The snap might bundle ffmpeg libraries together with firefox.

The snap doesn't have access to the system ffmpeg indeed, it is weird that installing deb packages is making any difference...

@seb128: this bug is about the non-snap firefox build for linux arm64, so not that weird :)

@jcristau, oh, sorry, I got confused by the previous comment asking to test a core24 build. In which case it seems like it would not be a bug, just that the snap bundle the ffmpeg libraries needed but that those were not installed on the system for the non snap version...

How was the 135 Firefox installed? I believe if done through the package manager there should be a dependency on ffmpeg, though jcristau probably knows better.

Flags: needinfo?(karlt)
Flags: needinfo?(cchang)
Flags: needinfo?(apehrson)

Should be from https://archive.mozilla.org/pub/firefox/nightly/latest-mozilla-central/firefox-135.0a1.en-US.linux-aarch64.tar.xz or equivalent, outside the package manager. That said, the .deb package doesn't have ffmpeg dependencies either.

The bit that's unclear to me is whether anything here is arm64 specific; I'd expect the same situation on amd64, unless the OS install was different. Does a default ubuntu desktop come with libavcodec et al? Was the install on the QA hardware somehow stripped down?

(In reply to Andreas Pehrson [:pehrsons] from comment #37)

How was the 135 Firefox installed? I believe if done through the package manager there should be a dependency on ffmpeg, though jcristau probably knows better.

Firefox 135 was not installed since we only know to find one in the archive, here

Since you probably intended intended to ask about Firefox 133, then I believe the Release Fx133 might have been installed by default on the Ubuntu 24.04.1 since installation of the OS, but I will have to ask the the "IT department" for this information. I will provide this information this information as soon as I have it.

Blocks: 1936353
No longer blocks: 1936353

(In reply to Julien Cristau [:jcristau] from comment #38)

Should be from https://archive.mozilla.org/pub/firefox/nightly/latest-mozilla-central/firefox-135.0a1.en-US.linux-aarch64.tar.xz or equivalent, outside the package manager. That said, the .deb package doesn't have ffmpeg dependencies either.

The bit that's unclear to me is whether anything here is arm64 specific; I'd expect the same situation on amd64, unless the OS install was different. Does a default ubuntu desktop come with libavcodec et al? Was the install on the QA hardware somehow stripped down?

We've received a second ARM device, another MacBook with a fresh install of Ubuntu 24.04.1 from Asahi.
It had a default installation of Firefox Release SNAP canonical v133.0.3 by default, so it might be tied up to a package manager.

This device has shown the same behavior as mine: Firefox Release SNAP canonical 133.0.3 has played videos correctly, while Nightly v135.0a1 aarch64 (.tar.xz) could not play videos correctly from the specific sources mentioned in this report AND it also needed to install ffmpeg before being able to playback as expected in Nightly v135.0a1 aarch64.

Unfortunately, we can't determine whether this is specific to our installations of Ubuntu on ARM devices or whether it is an issue general to Ubuntu. As I remember from setting up older Ubuntu test machines, we usually had to install codecs before using them for testing.

Please feel free to close it if you believe it invalid.

See Also: → 1936667

(In reply to Julien Cristau [:jcristau] from comment #38)

That said, the .deb package doesn't have ffmpeg dependencies either.

Maybe we should have a Recommends: for it, the way Debian's packages do?

Priority: -- → P3
Hardware: ARM64 → Desktop

(In reply to Jed Davis [:jld] ⟨⏰|UTC-8⟩ ⟦he/him⟧ from comment #41)

(In reply to Julien Cristau [:jcristau] from comment #38)

That said, the .deb package doesn't have ffmpeg dependencies either.

Maybe we should have a Recommends: for it, the way Debian's packages do?

Yeah, this is a plausible solution.
Debian's package Recommends: FFmpeg's libavcodec and libavcodec-extra.
Installing ffmpeg installs a version of FFmpeg libavcodec.
It looks like Debian's package is generating the libavcodec packages/versions by scanning dom/media/platforms/ffmpeg/FFmpegRuntimeLinker.cpp

https://searchfox.org/mozilla-central/source/dom/media/platforms/ffmpeg/FFmpegRuntimeLinker.cpp#49-52
https://searchfox.org/mozilla-central/source/dom/media/platforms/ffmpeg/FFmpegRuntimeLinker.cpp#56-60

Turns out this has come up before and is not something we can fix.

Status: NEW → RESOLVED
Closed: 16 days ago
Resolution: --- → WONTFIX
See Also: → 1811671
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: