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

Previous Next

Full log

View this message in rfc822 format

From: Ian Eure <ian <at> retrospec.tv>
To: André Batista <nandre <at> riseup.net>
Cc: 77559 <at> debbugs.gnu.org
Subject: 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.