Closed Bug 1711882 Opened 4 years ago Closed 6 months ago

Firefox doesn't play xHE-AAC content (mp4a.40.42)

Categories

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

defect

Tracking

()

VERIFIED FIXED
143 Branch
Tracking Status
relnote-firefox --- 143+
firefox143 --- verified

People

(Reporter: jya, Assigned: padenot)

References

(Blocks 1 open bug, Regressed 1 open bug, )

Details

(4 keywords)

Attachments

(6 files)

Site doesn't play because mimeType mp4a.40.42 isn't allowed there:
https://searchfox.org/mozilla-central/rev/443f87caa5fadba920b0382e12874693d6c6133a/dom/media/VideoUtils.cpp#664-673

Apple's AudioToolbox and recent version of Android will support it ; not sure about Windows Media Foundation.

Severity: -- → S3
Priority: -- → P3
Blocks: media-triage
Summary: Firefox doesn't play xeHE-AAC content → Firefox doesn't play xHE-AAC content

May be patent encumbered. We'll have to investigate the feasibility here.

No longer blocks: media-triage
Summary: Firefox doesn't play xHE-AAC content → Firefox doesn't play xeHE-AAC content
Summary: Firefox doesn't play xeHE-AAC content → Firefox doesn't play xHE-AAC content

It is definitely patent encumbered and I don't think there's much reason to choose it over Opus

Hi everyone! What's the status on this? Chromium-based browsers are able to decode xHE-AAC streams no problem.

It is definitely patent encumbered and I don't think there's much reason to choose it over Opus

Opus isn't supported by .mp4 containers, while xHE-AAC (USAC) is, as demonstrated by the video below. It's unwatchable in Firefox, since there's no sound:

https://odysee.com/@InfinityHD:0/mf_avqlab:c

Moreover, xHE-AAC decoding support has been introduced in ffmpeg 7.1

Could anyone look into this? Thanks.

As the title of this suggests, Firefox doesn't play xHE-AAC/USAC content.
This is not a patent encumberment issue, as Mac (Core Audio) and Windows 11 (Media Foundation) already include the USAC/xHE-AAC codec, and have for quite some time now. This is similar to the AAC codec family.

I believe all that is necessary is to add the following single line:

MIME type:
aCodec.EqualsLiteral("mp4a.40.42"); // MPEG-D USAC (xHE-AAC)

Mozilla source file:
/dom/media/VideoUtils.cpp
https://searchfox.org/mozilla-central/source/dom/media/VideoUtils.cpp
This is where it goes / Line 1118:

bool IsAACCodecString(const nsAString& aCodec) {
return aCodec.EqualsLiteral("mp4a.40.2") || // MPEG4 AAC-LC
aCodec.EqualsLiteral(
"mp4a.40.02") || // MPEG4 AAC-LC(for compatibility)
aCodec.EqualsLiteral("mp4a.40.5") || // MPEG4 HE-AAC
aCodec.EqualsLiteral(
"mp4a.40.05") || // MPEG4 HE-AAC(for compatibility)
aCodec.EqualsLiteral("mp4a.67") || // MPEG2 AAC-LC
aCodec.EqualsLiteral("mp4a.40.29"); // MPEG4 HE-AACv2
}

Here are a few Live HLS USAC/xHE-AAC StreamS with an HLS MSE Player you can use to test against. These play in Safari and Chrome on both Windows 11 and Mac Sequoia:

https://la2.indexcom.com/player/xheaac/
https://la2.indexcom.com/player/big8radiox/
https://la2.indexcom.com/player/eval/player3/

Please contact me if you need more details or more streams.

Thank you.
Greg Ogonowski
StreamS/Modulation Index LLC

This errors out here: https://pernos.co/debug/Gzmkut1nJwQB5CFTEqfsTw/index.html#f{m[CLju,CG+h_,t[4g,JXyo_,f{e[CLju,CGFO_,s{aduH9YAAA,bAZU,uJ9o97A,oJ9rCoA___/, should be easy to add support (after adding the mimetype check above).

Attached video sin1k-opus.mp4 β€”

(In reply to Lev from comment #3)

Opus isn't supported by .mp4 containers, while xHE-AAC (USAC) is, as demonstrated by the video below. It's unwatchable in Firefox, since there's no sound

Opus is supported in mp4 / ISOBMFF: https://www.opus-codec.org/docs/opus_in_isobmff.html. Attached is an example simply produced by doing:

ffmpeg -i sin1k.wav -acodec libopus sin1k.mp4

According to the comment0 and the comment 3, xHE-AAC can be supported on MacOS, Android and Linux (via ffmpeg). In addition, Windows supports xHE-AAC as well, so we should be able to support xHE-AAC on all platforms.

Just found that Netflix tries to serve mp4a.40.42 to Wolvic and fails (whereas Firefox Nightly on Windows is served with mp4a.40.5 regardless of Chrome Mask being enabled or not).

(FYI in case anyone never heard of Wolvic - it's a VR browser based on Gecko 128 ESR)

Heh, "Netflix Now Streaming with Fraunhofer’s xHE-AAC Audio on Android Mobile" in 2021, and I ran it on Meta Quest 3S which is based on Android. But the user agent string only says Linux...

Confirmed that Firefox Nightly for Android gets the same console warning about mp4a.40.42 on Netflix.

Summary: Firefox doesn't play xHE-AAC content → Firefox doesn't play xHE-AAC content (mp4a.40.42)

Can someone attach a file (not a stream) that fails to play so we can get going?

Superb, thanks a lot. Demuxer patch in https://github.com/mozilla/mp4parse-rust/pull/435. Then we'll need to pull it in, do the mime type business previously mentioned and we should be good.

Assignee: nobody → padenot
Keywords: devrel-needed

Here is an xHE-AAC(tm)/USAC file and stream resource:

https://db2.indexcom.com/xheaac/

Let me know if you need other samples.
There are plenty more available for the asking.

It would be best to use Mac Core Audio and Windows Media Foundation Audio Decoders.
xHE-AAC/USAC Decoders are available on both operating systems. Microsoft Windows 11 and up. No 10.
ffmpeg should be avoided.

Hope this helps move this overdue development along..
/greg.

Depends on: 1978328
Flags: needinfo?(padenot)

Should we call this out in the Fx143 relnotes?

Flags: needinfo?(padenot)

Release Note Request (optional, but appreciated)
[Why is this notable]: New codec can be played back on supported OS: xHE-AAC
[Affects Firefox for Android]: Yes (Android 9+)
[Suggested wording]: xHE-AAC playback is now supported on Windows 11 (22H2 and more recent), macOS 10.15 and more recent, and Android 9 and more recent
[Links (documentation, blog post, etc)]: none

relnote-firefox: --- → ?
Flags: needinfo?(padenot)

Added to the Fx143 relnotes, thanks.

Regressions: 1978862
Blocks: 1982387
QA Whiteboard: [qa-triage-done-c144/b143] [qa-ver-needed-c144/b143]
Flags: qe-verify+
QA Contact: cgeorgiu

I've repro this issue using an affected Nightly build 142.0a1 (2025-07-08) on Win 11.

The issue is verified as fixed on latest Beta 143.0b2 under Win 11 and macOS 28.

Status: RESOLVED → VERIFIED
QA Whiteboard: [qa-triage-done-c144/b143] [qa-ver-needed-c144/b143] → [qa-triage-done-c144/b143] [qa-ver-done-c144/b143]
Flags: qe-verify+
Regressions: 1990331
Regressions: 1989946
No longer regressions: 1990331
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: