Hi André,
André Batista <[email protected]> writes:
Hi Ian,
sáb 05 abr 2025 às 11:51:21 (1743864681), [email protected]
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
