From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 05 14:51:38 2025 Received: (at submit) by debbugs.gnu.org; 5 Apr 2025 18:51:38 +0000 Received: from localhost ([127.0.0.1]:44800 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1u18cE-0008Ho-B0 for submit@debbugs.gnu.org; Sat, 05 Apr 2025 14:51:38 -0400 Received: from lists.gnu.org ([2001:470:142::17]:41188) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1u18cB-0008HY-Ix for submit@debbugs.gnu.org; Sat, 05 Apr 2025 14:51:36 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1u18c3-0001Lq-A2 for bug-guix@gnu.org; Sat, 05 Apr 2025 14:51:27 -0400 Received: from fhigh-a2-smtp.messagingengine.com ([103.168.172.153]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1u18c0-0004IT-TI for bug-guix@gnu.org; Sat, 05 Apr 2025 14:51:27 -0400 Received: from phl-compute-11.internal (phl-compute-11.phl.internal [10.202.2.51]) by mailfhigh.phl.internal (Postfix) with ESMTP id 0A3AE11400CC for ; Sat, 5 Apr 2025 14:51:23 -0400 (EDT) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-11.internal (MEProxy); Sat, 05 Apr 2025 14:51:23 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=retrospec.tv; h= cc:content-transfer-encoding:content-type:content-type:date:date :from:from:in-reply-to:message-id:mime-version:reply-to:subject :subject:to:to; s=fm1; t=1743879083; x=1743965483; bh=6+sTvuPZJR C3W7DcDQ0OygDUVCxNr4KlnXMrknpud30=; b=gRrNRIetjVzejPdKewV1qFy/kz TDXHuELt0gJrhNSGWUCZGCxtnGnIQHgJQXiD+D7qPxxM4N+l9DZjz2FPY+L4E/IY 9qay6cA7U+SvuZLO7CnaCemzYGakgCpg8Vmu1NLylfbQCXuwrt8ddXA9ch5JXfcK KdlkHf2FoNSbRbycoGQ4oy8acMQz9x8lnXmZQ6mQjNCvpL3JhQoJEjNAt/0Ytkoi Y7IJd5lsBlsS2Akik678XC31mRITH00xAs5z16YT44YHgda2oEhBE05J9isWkqtX 4TeycdVz6OTycnsHwTY9hgRGPmc4ZolMS8VeNjD0DZab0+bc3s+qcBkWSNHA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:message-id:mime-version:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t= 1743879083; x=1743965483; bh=6+sTvuPZJRC3W7DcDQ0OygDUVCxNr4KlnXM rknpud30=; b=Xfb/VcG6ungkFTDongROUg4PWLYFU44PL8wAHX6P3ZI3Emw/aeL b2P148zJcsYKMgi5REURIDRM3vOLy0Dg7Y/HMiqfCTkfmfpys1Mn798fRok13o1H WiQzN/CiO+e5t1j1RgPZy2gHEO+fWgoBMNqThEjYKY+Qi8XoUKe1PIslLYOYIDDG zk1Z9cRAuwvPT/o5mfqLEfRk73f6zURA9fbClM/I448EXBg8ejezULNi6NumEMmg 818swpssYvF5KioDCuZIC40uh457sVXpNsryWrbdqCIgHhCrMfs+K0qAGOY65hRw AJq35YTNxki6+mWzaLLdbxxNwN7xvTRDiFA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgdduleehuddvucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggv pdfurfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucenucfjughrpefhvf fufgffkfggtgfgsehtqhertddtreejnecuhfhrohhmpefkrghnucfguhhrvgcuoehirghn sehrvghtrhhoshhpvggtrdhtvheqnecuggftrfgrthhtvghrnhepfffhkeeiffdvtedtje fhjeeigfeukeekieehgefhhffgfeejuedvgfejkeeiveehnecuffhomhgrihhnpeifihhk ihhpvgguihgrrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrg hilhhfrhhomhepihgrnhesrhgvthhrohhsphgvtgdrthhvpdhnsggprhgtphhtthhopedu pdhmohguvgepshhmthhpohhuthdprhgtphhtthhopegsuhhgqdhguhhigiesghhnuhdroh hrgh X-ME-Proxy: Feedback-ID: id9014242:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Sat, 5 Apr 2025 14:51:22 -0400 (EDT) From: Ian Eure To: bug-guix@gnu.org Subject: mullvadbrowser & torbrowser =?utf-8?Q?can=E2=80=99t?= play AAC LATM streams User-Agent: mu4e 1.12.9; emacs 29.4 Date: Sat, 05 Apr 2025 11:51:21 -0700 Message-ID: <87tt72a1cm.fsf@retrospec.tv> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=103.168.172.153; envelope-from=ian@retrospec.tv; helo=fhigh-a2-smtp.messagingengine.com X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 0.7 (/) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.3 (/) When testing patches for #77460 and #77461, I noticed that neither=20 mullvad nor torbrowser can play live videos. ex. if you launch=20 either browser, navigate to youtube.com, search "live" and click=20 on any video with the red "live" badge, you get a "Your browser=20 can=E2=80=99t play this video" error. If I launch Mullvad from a shell, I see this output: [Child 22618, MediaDecoderStateMachine #1] WARNING:=20 Decoder=3D7efdca045b00 Decode error: NS_ERROR_DOM_MEDIA_FATAL_ERR=20 (0x806e0005) - Error no decoder found for audio/mp4a-latm: file=20 /tmp/guix-build-mullvadbrowser-14.0.7.drv-0/firefox-mullvad-browser-128.8.0= esr-14.0-1-build2/dom/media/MediaDecoderStateMachineBase.cpp:167 This seems related to #72265, which was a report about LibreWolf=20 not enabling hardware acceleration for video decoding; after=20 applying the provided patch, the same problem resulted. I think=20 the same situation is happening with these browsers. I don=E2=80=99t have= =20 a satisfying fix; LW still has no hwaccel support, and neither=20 does Firefox in nonguix. Mullvad=E2=80=99s about:support claims AAC is supported with hardware=20 acceleration. LATM is a container format[1], not a codec, and=20 doesn=E2=80=99t show up anywhere on that page. Per the FFmpeg changelog,=20 LATM support was added to in version 0.9(!), and doesn=E2=80=99t appear to= =20 have a configure flag to control whether it=E2=80=99s enabled or not. So=20 it=E2=80=99s not clear to me why Firefoxen aren=E2=80=99t able to decode th= ese=20 streams. Thanks, -- Ian [1]:=20 https://en.wikipedia.org/wiki/Advanced_Audio_Coding#Container_formats From debbugs-submit-bounces@debbugs.gnu.org Thu May 29 17:27:11 2025 Received: (at 77559) by debbugs.gnu.org; 29 May 2025 21:27:11 +0000 Received: from localhost ([127.0.0.1]:39991 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uKkmN-00089t-18 for submit@debbugs.gnu.org; Thu, 29 May 2025 17:27:11 -0400 Received: from mx0.riseup.net ([198.252.153.6]:42300) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uKkmJ-00089M-V4 for 77559@debbugs.gnu.org; Thu, 29 May 2025 17:27:08 -0400 Received: from fews02-sea.riseup.net (fews02-sea-pn.riseup.net [10.0.1.112]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx0.riseup.net (Postfix) with ESMTPS id 4b7fZs5Xmkz9wSj; Thu, 29 May 2025 21:27:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak; t=1748554021; bh=PR5C+hFx/mNPlNm1DH9JMfjbAntDt8qqTIhaTNPEUl8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=gr9c5CEjaCcZ9FTHx4uqv25uXKSp48JzvJWrKWvrPp0whFzitw9KCJ1btgP4VPoIQ TrqpMNrHHWDRTVjNQFCBFvWla6rauOM+Uhv/V9E7FCza27TzUKZAfYQ41kXz+5nqEj zrPYN3xF/sGW+9JHSBIINDVGOnkPQvw5gz5MQfxQ= X-Riseup-User-ID: 97CA0FEE2A7E6209333222DB279B7D13370235C66951B6106AE387B87245A0F7 Received: from [127.0.0.1] (localhost [127.0.0.1]) by fews02-sea.riseup.net (Postfix) with ESMTPSA id 4b7fZr3f0KzFvcK; Thu, 29 May 2025 21:27:00 +0000 (UTC) Date: Thu, 29 May 2025 18:26:36 -0300 From: =?iso-8859-1?Q?Andr=E9?= Batista To: Ian Eure Subject: Re: bug#77559: mullvadbrowser =?utf-8?Q?&_?= =?utf-8?Q?torbrowser_can=E2=80=99t?= play AAC LATM streams Message-ID: References: <87tt72a1cm.fsf@retrospec.tv> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <87tt72a1cm.fsf@retrospec.tv> X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 77559 Cc: 77559@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Hi Ian, sáb 05 abr 2025 às 11:51:21 (1743864681), ian@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! From debbugs-submit-bounces@debbugs.gnu.org Sat May 31 12:27:07 2025 Received: (at 77559) by debbugs.gnu.org; 31 May 2025 16:27:08 +0000 Received: from localhost ([127.0.0.1]:59245 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uLP32-00064H-1l for submit@debbugs.gnu.org; Sat, 31 May 2025 12:27:07 -0400 Received: from fhigh-b7-smtp.messagingengine.com ([202.12.124.158]:36643) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uLP2y-00062X-52 for 77559@debbugs.gnu.org; Sat, 31 May 2025 12:27:01 -0400 Received: from phl-compute-01.internal (phl-compute-01.phl.internal [10.202.2.41]) by mailfhigh.stl.internal (Postfix) with ESMTP id 331C125400D0; Sat, 31 May 2025 12:26:54 -0400 (EDT) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-01.internal (MEProxy); Sat, 31 May 2025 12:26:54 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=retrospec.tv; h= cc:cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm3; t=1748708814; x=1748795214; bh=EP8kPA7tk8GGf4aIu+wwdUBv6qR38Vv+tLo2RhFuFFQ=; b= CAqGgTl1/bQGNP51uMIqlBpHNfODnVn5cjiAKtjcSryB86J8CcEnbvyvqePkqLfh rrS92RA/EQwccFOfyN0Z0KMWkybS5SR7qpRc94caKEEN8qjO41ZYGOuPRoJ5SImN 8oTz9WiRjV3f5q+RCL47FGBK1YPo8PqlGXvEQ6illNSuPIy8En27AgjGHaYUHa3C eXhGrhrZ84pK2RmL1nvwvMCL5zuAJ4McopcDV2Q+vyHPWSdVOsX3P5wDkZ1IGhtp uGyJsYFAbMsHeqQRS0IcA4zXmc93kLIr7AqzHpMMB5z808OUbpJMiGnqnALKo9RL bJF/2qd2hNSOmdZH541ZjA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1748708814; x= 1748795214; bh=EP8kPA7tk8GGf4aIu+wwdUBv6qR38Vv+tLo2RhFuFFQ=; b=l 8bzWFrLGnrLy+GhTipyvZv9CWOMebJuK/bwriE1DLZ7FNda5o+vtHz90MnfeaDoI prtZPQUjdbAwdo56KUx7YPz3MHhbCwDb9r2KgEUMXyHXm4INuJBp6DsUV597OXWi L7/dppbVSoFh9j93gI27B4qr7iyA8JbSE8FTIHk4LItduD4uiS/bDLjBkIWS5GFu 3yjmabPXRTRXsiQtAYMim20Gmf8ZJEXQ9sro6Z7FJ+S3GWq4RfVfXmuz2KDrU4Io Flt/y4UPqKPwfpmFpL5/L+Mn5+eVSUTRR6qfk+871Y96NCxFBn7uhgpgUmk8Aiqk LIK5RAxIExwPQxzKZF+QA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddtgdefvdefkeculddtuddrgeefvddrtd dtmdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpggft fghnshhusghstghrihgsvgdpuffrtefokffrpgfnqfghnecuuegrihhlohhuthemuceftd dtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefhvfevufgjfhgf fffkgggtgfesthhqredttderjeenucfhrhhomhepkfgrnhcugfhurhgvuceoihgrnhesrh gvthhrohhsphgvtgdrthhvqeenucggtffrrghtthgvrhhnpeevueelueegudejueekhffh hfelgfejheefffehgfffleekveekuedtgeekleegffenucevlhhushhtvghrufhiiigvpe dtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehirghnsehrvghtrhhoshhpvggtrdhtvhdp nhgspghrtghpthhtohepvddpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepjeejhe ehleesuggvsggsuhhgshdrghhnuhdrohhrghdprhgtphhtthhopehnrghnughrvgesrhhi shgvuhhprdhnvght X-ME-Proxy: Feedback-ID: id9014242:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 31 May 2025 12:26:53 -0400 (EDT) From: Ian Eure To: =?utf-8?Q?Andr=C3=A9?= Batista Subject: Re: bug#77559: mullvadbrowser & torbrowser =?utf-8?Q?can=E2=80=99?= =?utf-8?Q?t?= play AAC LATM streams In-Reply-To: (=?utf-8?Q?=22Andr=C3=A9?= Batista"'s message of "Thu, 29 May 2025 18:26:36 -0300") References: <87tt72a1cm.fsf@retrospec.tv> User-Agent: mu4e 1.12.9; emacs 29.4 Date: Sat, 31 May 2025 09:26:47 -0700 Message-ID: <87v7pg4ugo.fsf@retrospec.tv> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 77559 Cc: 77559@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Hi Andr=C3=A9, Andr=C3=A9 Batista writes: > Hi Ian, > > s=C3=A1b 05 abr 2025 =C3=A0s 11:51:21 (1743864681), ian@retrospec.tv=20 > enviou: >> When testing patches for #77460 and #77461, I noticed that=20 >> neither mullvad >> nor torbrowser can play live videos. ex. if you launch either=20 >> browser, >> navigate to youtube.com, search "live" and click on any video=20 >> with the red >> "live" badge, you get a "Your browser can=E2=80=99t play this video"=20 >> error. >>=20 > > Is there another way to test this besides going to youtube? Any stream using LATM audio should reproduce the issue, though I=20 don=E2=80=99t know of a non-YouTube place which does that. LATM is=20 low-latency, for live video, so maybe CSPAN or a radio station=E2=80=99s=20 live stream. > Also, is this a guix only thing? AKA, have you tried other=20 > versions > of these browsers elsewhere with different results? Yes, it=E2=80=99s related to RDD sandboxing, and breaks on Guix because=20 ffmpeg et al aren=E2=80=99t in /usr/lib as upstream expects. I installed mullvadbrowser from the official packges on a Debian=20 Bullseye machine, and the problem doesn=E2=80=99t reproduce. > The way you describe the issue makes me wonder if this is=20 > related to > youtube, tor/mullvad browsers or guix. YouTube is incidental to the problem, it=E2=80=99s just a reliable way to=20 get an AAC LATM audio stream to reproduce the problem. >> This seems related to #72265, which was a report about=20 >> LibreWolf not >> enabling hardware acceleration for video decoding; after=20 >> applying the >> provided patch, the same problem resulted. I think the same=20 >> situation is >> happening with these browsers. I don=E2=80=99t have a satisfying fix;=20 >> LW still has >> no hwaccel support, and neither does Firefox in nonguix. >>=20 > > Sorry but I'm confused here: you mean, without that patch LW=20 > could play > these streams, but after applying it cannot? Correct. Prior to the patch in #72265, LibreWolf decoded=20 everything in software, and LATM AAC worked. After the patch, LW=20 decoded supported formats with hardware acceleration, but support=20 for LATM AAC broke. > Or did you create a local version of the browsers in question=20 > with > the same patch and got no luck? I=E2=80=99m not sure what you=E2=80=99re asking. I pushed the patch, then = got=20 reports that live video didn=E2=80=99t work, then reverted it. See=20 #73429. > I may be in the wrong here, but isn't hardware acceleration=20 > privacy > sensitive in the context of these browsers? Meaning it could be=20 > used > to fingerprint users based on the hardware they have available. This is a question for upstream, however, the official Mullvad=20 package=E2=80=99s about:support shows that it supports hardware decoding,=20 so this is presumably desired. I don=E2=80=99t know what visibility one=20 is afforded into hw/sw decoding, but intuitatively, I expect=20 software decoding to be less common in 2025, thus making the user=20 more identifiable. Either way, the current situation is very bad, since inability to=20 play LATM AAC is easily detectable (based on whether the client=20 requested and consumed the whole LATM stream), and identifies the=20 client as a a Guix-provided browser. >> Mullvad=E2=80=99s about:support claims AAC is supported with hardware=20 >> acceleration. >> LATM is a container format[1], not a codec, and doesn=E2=80=99t show up= =20 >> anywhere on >> that page. Per the FFmpeg changelog, LATM support was added to=20 >> in version >> 0.9(!), and doesn=E2=80=99t appear to have a configure flag to control=20 >> whether it=E2=80=99s >> enabled or not. So it=E2=80=99s not clear to me why Firefoxen aren=E2= =80=99t=20 >> able to decode >> these streams. >>=20 > > Do they currently work on LibreWolf though? Yes. Prior to #73429, they were both working with software=20 decoding only. After I pushed that, LATM AAC broke, so I reverted=20 it. Since ab24e2ebe51720f332215b110c1bb151718d16bd, all=20 audio/video types have worked with hardware decoding. At the time=20 I filed this bug, I didn=E2=80=99t have a fix, but a generous contributor=20 figured out what was wrong and sent a patch. Some variant of=20 patches/librewolf-add-store-to-rdd-allowlist.patch will likely fix=20 mullvad/torbrowser as well. Thanks, -- Ian