GNU bug report logs - #77559
mullvadbrowser & torbrowser can’t play AAC LATM streams

Previous Next

To reply to this bug, email your comments to 77559 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Ian Eure <ian <at> retrospec.tv>
To: bug-guix <at> gnu.org
Subject: mullvadbrowser & torbrowser can’t play AAC LATM
 streams
Date: Sat, 05 Apr 2025 11:51:21 -0700

When testing patches for #77460 and #77461, I noticed that neither 
mullvad nor torbrowser can play live videos.  ex. if you launch 
either browser, navigate to youtube.com, search "live" and click 
on any video with the red "live" badge, you get a "Your browser 
can’t play this video" error.

If I launch Mullvad from a shell, I see this output:

[Child 22618, MediaDecoderStateMachine #1] WARNING: 
Decoder=7efdca045b00 Decode error: NS_ERROR_DOM_MEDIA_FATAL_ERR 
(0x806e0005) - Error no decoder found for audio/mp4a-latm: file 
/tmp/guix-build-mullvadbrowser-14.0.7.drv-0/firefox-mullvad-browser-128.8.0esr-14.0-1-build2/dom/media/MediaDecoderStateMachineBase.cpp:167

This seems related to #72265, which was a report about LibreWolf 
not enabling hardware acceleration for video decoding; after 
applying the provided patch, the same problem resulted.  I think 
the same situation is happening with these browsers.  I don’t have 
a satisfying fix; LW still has no hwaccel support, and neither 
does Firefox in nonguix.

Mullvad’s about:support claims AAC is supported with hardware 
acceleration.  LATM is a container format[1], not a codec, and 
doesn’t show up anywhere on that page.  Per the FFmpeg changelog, 
LATM support was added to in version 0.9(!), and doesn’t appear to 
have a configure flag to control whether it’s enabled or not.  So 
it’s not clear to me why Firefoxen aren’t able to decode these 
streams.

Thanks,
 -- Ian

[1]: 
https://en.wikipedia.org/wiki/Advanced_Audio_Coding#Container_formats

Message #8 received at 77559 <at> debbugs.gnu.org (full text, mbox):

From: André Batista <nandre <at> riseup.net>
To: Ian Eure <ian <at> retrospec.tv>
Cc: 77559 <at> debbugs.gnu.org
Subject: Re: bug#77559: mullvadbrowser & torbrowser can’t play AAC LATM streams
Date: Thu, 29 May 2025 18:26:36 -0300

Hi Ian,

sáb 05 abr 2025 às 11:51:21 (1743864681), ian <at> retrospec.tv enviou:
> When testing patches for #77460 and #77461, I noticed that neither mullvad
> nor torbrowser can play live videos.  ex. if you launch either browser,
> navigate to youtube.com, search "live" and click on any video with the red
> "live" badge, you get a "Your browser can’t play this video" error.
> 

Is there another way to test this besides going to youtube?

Also, is this a guix only thing?  AKA, have you tried other versions
of these browsers elsewhere with different results?

The way you describe the issue makes me wonder if this is related to
youtube, tor/mullvad browsers or guix.

> If I launch Mullvad from a shell, I see this output:
> 
> [Child 22618, MediaDecoderStateMachine #1] WARNING: Decoder=7efdca045b00
> Decode error: NS_ERROR_DOM_MEDIA_FATAL_ERR (0x806e0005) - Error no decoder
> found for audio/mp4a-latm: file /tmp/guix-build-mullvadbrowser-14.0.7.drv-0/firefox-mullvad-browser-128.8.0esr-14.0-1-build2/dom/media/MediaDecoderStateMachineBase.cpp:167
> 
> This seems related to #72265, which was a report about LibreWolf not
> enabling hardware acceleration for video decoding; after applying the
> provided patch, the same problem resulted.  I think the same situation is
> happening with these browsers.  I don’t have a satisfying fix; LW still has
> no hwaccel support, and neither does Firefox in nonguix.
> 

Sorry but I'm confused here: you mean, without that patch LW could play
these streams, but after applying it cannot?  Or did you create a local
version of the browsers in question with the same patch and got no
luck?

I may be in the wrong here, but isn't hardware acceleration privacy
sensitive in the context of these browsers?  Meaning it could be used
to fingerprint users based on the hardware they have available.

> Mullvad’s about:support claims AAC is supported with hardware acceleration.
> LATM is a container format[1], not a codec, and doesn’t show up anywhere on
> that page.  Per the FFmpeg changelog, LATM support was added to in version
> 0.9(!), and doesn’t appear to have a configure flag to control whether it’s
> enabled or not.  So it’s not clear to me why Firefoxen aren’t able to decode
> these streams.
> 

Do they currently work on LibreWolf though?

Cheers!

Message #11 received at 77559 <at> debbugs.gnu.org (full text, mbox):

From: Ian Eure <ian <at> retrospec.tv>
To: André Batista <nandre <at> riseup.net>
Cc: 77559 <at> debbugs.gnu.org
Subject: Re: bug#77559: mullvadbrowser & torbrowser can’t play AAC LATM streams
Date: Sat, 31 May 2025 09:26:47 -0700

Hi André,

André Batista <nandre <at> riseup.net> writes:

> Hi Ian,
>
> sáb 05 abr 2025 às 11:51:21 (1743864681), ian <at> retrospec.tv 
> enviou:
>> When testing patches for #77460 and #77461, I noticed that 
>> neither mullvad
>> nor torbrowser can play live videos.  ex. if you launch either 
>> browser,
>> navigate to youtube.com, search "live" and click on any video 
>> with the red
>> "live" badge, you get a "Your browser can’t play this video" 
>> error.
>> 
>
> Is there another way to test this besides going to youtube?

Any stream using LATM audio should reproduce the issue, though I 
don’t know of a non-YouTube place which does that.  LATM is 
low-latency, for live video, so maybe CSPAN or a radio station’s 
live stream.


> Also, is this a guix only thing?  AKA, have you tried other 
> versions
> of these browsers elsewhere with different results?

Yes, it’s related to RDD sandboxing, and breaks on Guix because 
ffmpeg et al aren’t in /usr/lib as upstream expects.

I installed mullvadbrowser from the official packges on a Debian 
Bullseye machine, and the problem doesn’t reproduce.


> The way you describe the issue makes me wonder if this is 
> related to
> youtube, tor/mullvad browsers or guix.

YouTube is incidental to the problem, it’s just a reliable way to 
get an AAC LATM audio stream to reproduce the problem.


>> This seems related to #72265, which was a report about 
>> LibreWolf not
>> enabling hardware acceleration for video decoding; after 
>> applying the
>> provided patch, the same problem resulted.  I think the same 
>> situation is
>> happening with these browsers.  I don’t have a satisfying fix; 
>> LW still has
>> no hwaccel support, and neither does Firefox in nonguix.
>> 
>
> Sorry but I'm confused here: you mean, without that patch LW 
> could play
> these streams, but after applying it cannot?

Correct.  Prior to the patch in #72265, LibreWolf decoded 
everything in software, and LATM AAC worked.  After the patch, LW 
decoded supported formats with hardware acceleration, but support 
for LATM AAC broke.


> Or did you create a local version of the browsers in question 
> with
> the same patch and got no luck?

I’m not sure what you’re asking.  I pushed the patch, then got 
reports that live video didn’t work, then reverted it.  See 
#73429.


> I may be in the wrong here, but isn't hardware acceleration 
> privacy
> sensitive in the context of these browsers?  Meaning it could be 
> used
> to fingerprint users based on the hardware they have available.

This is a question for upstream, however, the official Mullvad 
package’s about:support shows that it supports hardware decoding, 
so this is presumably desired.  I don’t know what visibility one 
is afforded into hw/sw decoding, but intuitatively, I expect 
software decoding to be less common in 2025, thus making the user 
more identifiable.

Either way, the current situation is very bad, since inability to 
play LATM AAC is easily detectable (based on whether the client 
requested and consumed the whole LATM stream), and identifies the 
client as a a Guix-provided browser.


>> Mullvad’s about:support claims AAC is supported with hardware 
>> acceleration.
>> LATM is a container format[1], not a codec, and doesn’t show up 
>> anywhere on
>> that page.  Per the FFmpeg changelog, LATM support was added to 
>> in version
>> 0.9(!), and doesn’t appear to have a configure flag to control 
>> whether it’s
>> enabled or not.  So it’s not clear to me why Firefoxen aren’t 
>> able to decode
>> these streams.
>> 
>
> Do they currently work on LibreWolf though?

Yes.  Prior to #73429, they were both working with software 
decoding only.  After I pushed that, LATM AAC broke, so I reverted 
it.  Since ab24e2ebe51720f332215b110c1bb151718d16bd, all 
audio/video types have worked with hardware decoding.  At the time 
I filed this bug, I didn’t have a fix, but a generous contributor 
figured out what was wrong and sent a patch.  Some variant of 
patches/librewolf-add-store-to-rdd-allowlist.patch will likely fix 
mullvad/torbrowser as well.

Thanks,
 -- Ian

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.