[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#38045: closed (IceCat-68.x lacks support for some codecs including H

From: GNU bug Tracking System
Subject: bug#38045: closed (IceCat-68.x lacks support for some codecs including H264/MP4)
Date: Thu, 16 Jan 2020 06:27:02 +0000

Your message dated Thu, 16 Jan 2020 01:24:50 -0500
with message-id <address@hidden>
and subject line Re: IceCat: some codecs don't work without workaround
has caused the debbugs.gnu.org bug report #38045,
regarding IceCat-68.x lacks support for some codecs including H264/MP4
to be marked as done.

(If you believe you have received this mail in error, please contact

38045: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=38045
GNU Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- Subject: Video Rendering Issues on IceCat Date: Sun, 03 Nov 2019 11:33:23 -0500
Hello Guix and GNUzilla!

I am currently using IceCat (68.2.0-guix0-preview3) on Guix System.

Starting from version 68.X.X, I started to face issues with playing
videos online. This happens on most of the websites (not all though).

I get any of these following errors:
1) No compatible source was found for this media.
2) Your browser does not support the playback of this video. Please try
using a different browser.
3) Error loading player: No playable sources found.

I thought issues could be due to any of the add-ons I am using. But I
was able to reproduce these errors by running Icecat on safe-mode (i.e.
with all add-ons disabled).


Attachment: signature.asc
Description: This is a digitally signed message part

--- End Message ---
--- Begin Message --- Subject: Re: IceCat: some codecs don't work without workaround Date: Thu, 16 Jan 2020 01:24:50 -0500
Hi Jakub,

Jakub Kądziołka <address@hidden> wrote:
> I had some problems with video codecs in IceCat 68.3.0-guix0-preview1.
> For example, consider this page: http://demo.nimius.net/video_test/. By
> default, the videos under the headings H.264 / AAC and MPEG4 don't work
> ("No video with supported format and MIME type found.").
> The following steps make the first of these videos work:
> 1. Open about:config
> 2. Click "I accept the risk!"
> 3. Set security.sandbox.content.read_path_whitelist to /gnu/store/
>    (the trailing / is important).
> The instructions were originally sketched out in this help-guix
> message:
> https://lists.gnu.org/archive/html/help-guix/2019-12/msg00150.html
> I believe it would be beneficial to make this a default.
> On IRC, bandali suggested that it would be better to only whitelist the
> necessary store subdirectories. I don't know how to gather such a list,
> but it it seems like a good idea.

Thank you for bringing this to my attention.  I agree with Amin Bandali
that a more precise whitelist is preferable.  Moreover, I was not
comfortable whitelisting all of /gnu/store.

I'm glad to report that it appears to be sufficient to whitelist the
RUNPATH of libavcodec.so, plus the /share/mime/ directory from
shared-mime-info.  I've implemented this in commit
429c8284d232c3f9fbe3dc87a3da323f3a864c03 and pushed it to 'master'.

> I don't know how about:config entries modified by the user behave when
> IceCat is updated, but in some of the behaviors I can imagine, the
> config entry stops updating,

As currently implemented, we now arrange to set the *default* value of
'security.sandbox.content.read_path_whitelist' to an appropriate

Users who have customized 'security.sandbox.content.read_path_whitelist'
to work around this issue should now erase that customization, by
right-clicking on its entry in <about:config>, and clicking on "Reset".
It might also be necessary to restart IceCat after doing so.

> in which case it would be better to add the paths to some internal
> whitelist (I reckon such a whitelist already exists and contains
> something like /usr/lib).

I agree that it would be preferable, but I wasn't sufficiently motivated
to implement it.  Feel free to propose a patch.  I'm not sure it would
make much of a difference in practice though, because the net result for
anyone who has customized it to /gnu/store/ will be the same: until they
reset their customization, their effective whitelist will be all of

What do you think?

Anyway, thanks to everyone who contributed to this fix!  I'm closing
both the older bug (38045) and the more recent duplicate (38831), but
feel free to reopen if appropriate.


--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]