GNU bug report logs -
#38045
IceCat-68.x lacks support for some codecs including H264/MP4
Previous Next
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 38045 in the body.
You can then email your comments to 38045 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-guix <at> gnu.org
:
bug#38045
; Package
guix
.
(Sun, 03 Nov 2019 16:34:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Raghav Gururajan <raghavgururajan <at> disroot.org>
:
New bug report received and forwarded. Copy sent to
bug-guix <at> gnu.org
.
(Sun, 03 Nov 2019 16:34:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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).
Regards,
RG.
[signature.asc (application/pgp-signature, inline)]
Severity set to 'important' from 'normal'
Request was from
Raghav Gururajan <raghavgururajan <at> disroot.org>
to
control <at> debbugs.gnu.org
.
(Sun, 03 Nov 2019 16:49:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-guix <at> gnu.org
:
bug#38045
; Package
guix
.
(Sun, 03 Nov 2019 22:38:01 GMT)
Full text and
rfc822 format available.
Message #10 received at submit <at> debbugs.gnu.org (full text, mbox):
Raghav Gururajan writes:
> 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).
>
> Regards,
> RG.
I've had these issues as well, fwiw.
Information forwarded
to
bug-guix <at> gnu.org
:
bug#38045
; Package
guix
.
(Sun, 03 Nov 2019 22:38:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-guix <at> gnu.org
:
bug#38045
; Package
guix
.
(Mon, 04 Nov 2019 00:42:02 GMT)
Full text and
rfc822 format available.
Message #16 received at 38045 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi Raghav,
Are you actively working on this bug? If you are not, then as a matter
of etiquette, I think it would be best not to change its severity.
Raghav Gururajan <raghavgururajan <at> disroot.org> writes:
> 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).
Can you provide specific example URLs that do not work?
Did you try installing the gst-plugins-* packages? I observed similar
behavior in the past. I believe I resolved it by installing the right
gst-plugins-* packages, which is probably one of these:
gst-plugins-base
gst-plugins-good
gst-plugins-bad
gst-plugins-ugly
You might also have to adjust some settings in about:config. I can't
remember if I did that or not. Video in IceCat generally works, but
depending on the video you might need to jump through some extra hoops
to make it happen.
--
Chris
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-guix <at> gnu.org
:
bug#38045
; Package
guix
.
(Mon, 04 Nov 2019 13:03:02 GMT)
Full text and
rfc822 format available.
Message #19 received at 38045 <at> debbugs.gnu.org (full text, mbox):
Hi Chris!
> Are you actively working on this bug? If you are not, then as a
> matter
> of etiquette, I think it would be best not to change its severity.
I am not. Sorry about that. I read the control-debbugs help page and it
mentions that criteria for 'important' is unusablity of the program. So
I presumed that anyone can change the serverity level. No worries,
moving forward, I refrain from changing it. :-)
> Can you provide specific example URLs that do not work?
https://playedvid.com/whsfksz0zw8c
https://streamp1ay.me/yb4kihqvq8c9
> Did you try installing the gst-plugins-* packages? I observed
> similar
> behavior in the past. I believe I resolved it by installing the
> right
> gst-plugins-* packages, which is probably one of these:
>
> gst-plugins-base
> gst-plugins-good
> gst-plugins-bad
> gst-plugins-ugly
Yes, I have them installed.
> You might also have to adjust some settings in about:config. I can't
> remember if I did that or not. Video in IceCat generally works, but
> depending on the video you might need to jump through some extra
> hoops
> to make it happen.
I see. It was just weird that this is issue started after the upgrade.
Before that, all was fine.
Regards,
RG.
Information forwarded
to
bug-guix <at> gnu.org
:
bug#38045
; Package
guix
.
(Mon, 04 Nov 2019 16:27:02 GMT)
Full text and
rfc822 format available.
Message #22 received at 38045 <at> debbugs.gnu.org (full text, mbox):
Hi,
Raghav Gururajan <raghavgururajan <at> disroot.org> wrote:
> It was just weird that this is issue started after the upgrade.
> Before that, all was fine.
I have a hypothesis of what might have happened here.
Since the upgrade to version 68, the IceCat package in GNU Guix is no
longer using our system ffmpeg. Although ffmpeg is listed in the
'inputs', "guix gc --references $(guix build icecat)" shows that the
built package does not reference it. It must be using the bundled copy
of ffmpeg instead.
Prior to the upgrade to version 68, the IceCat package in Guix
referenced the system ffmpeg library, and that fact was reflected in the
output of "guix gc --references".
Possibly related: I noticed while debugging this upgrade that the
'link-libxul-with-libraries' phase no longer seems to be doing its job.
That's why I needed to add pulseaudio's lib directory to LD_LIBRARY_PATH
in the 'wrap-program' phase.
I would be grateful for help debugging these issues. I'm very heavily
overloaded with other tasks at present, and it may be a few weeks before
I can look into this specific bug.
Incidentally, I agree that 'important' is an appropriate severity level
for this bug.
Regards,
Mark
Information forwarded
to
bug-guix <at> gnu.org
:
bug#38045
; Package
guix
.
(Mon, 04 Nov 2019 16:38:02 GMT)
Full text and
rfc822 format available.
Message #25 received at 38045 <at> debbugs.gnu.org (full text, mbox):
Earlier, I wrote:
> I have a hypothesis of what might have happened here.
>
> Since the upgrade to version 68, the IceCat package in GNU Guix is no
> longer using our system ffmpeg.
Sorry, I forgot to mention why I think this might be relevant. The
reason is because upstream Firefox adopts the approach of downloading
certain codecs in pre-compiled form, to avoid certain patent concerns.
That's not necessary when using Guix's system ffmpeg library, but maybe
Mozilla rigged the bundled ffmpeg library to avoid including support for
those codecs.
Mark
Information forwarded
to
bug-guix <at> gnu.org
:
bug#38045
; Package
guix
.
(Wed, 13 Nov 2019 16:39:02 GMT)
Full text and
rfc822 format available.
Message #28 received at 38045 <at> debbugs.gnu.org (full text, mbox):
close 38190
retitle 38045 IceCat-68.x lacks support for some codecs including H264/MP4
thanks
Hi Jelle,
Jelle Licht <jlicht <at> fsfe.org> writes:
> On latest master, with the following icecat package:
> icecat 68.2.0-guix0-preview3 out /gnu/store/zqzhirykpqhay8n768aqqg4xplrmpfwz-icecat-68.2.0-guix0-preview3
>
> On the console (via <f12>) I find the following message on websites with
> embedded videos:
>
> The video on this page can’t be played. Your system may not have the
> required video codecs for: video/mp4; codecs="avc1.42E01E mp4a.40.2
I believe this is the same issue reported in
<https://bugs.gnu.org/38045>, so I'm closing this new bug as a
duplicate.
My best guess is here:
<https://debbugs.gnu.org/cgi/bugreport.cgi?bug=38045#22>
Thanks,
Mark
Changed bug title to 'IceCat-68.x lacks support for some codecs including H264/MP4' from 'Video Rendering Issues on IceCat'
Request was from
Mark H Weaver <mhw <at> netris.org>
to
control <at> debbugs.gnu.org
.
(Wed, 13 Nov 2019 16:39:04 GMT)
Full text and
rfc822 format available.
Reply sent
to
Mark H Weaver <mhw <at> netris.org>
:
You have taken responsibility.
(Thu, 16 Jan 2020 06:27:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Raghav Gururajan <raghavgururajan <at> disroot.org>
:
bug acknowledged by developer.
(Thu, 16 Jan 2020 06:27:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 38045-done <at> debbugs.gnu.org (full text, mbox):
Hi Jakub,
Jakub Kądziołka <kuba <at> kadziolka.net> 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
whitelist.
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
/gnu/store/*.
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.
Mark
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Thu, 13 Feb 2020 12:24:07 GMT)
Full text and
rfc822 format available.
This bug report was last modified 4 years and 67 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.