Description of problem:
Firefox is unable to play h264 video via HTML5. HTML5 is a pretty big deal for a mainstream browser to be missing. If someone else can confirm my report, I think this should be a release blocker.
Version-Release number of selected component (if applicable):
I don't know the affected version ranges, but this is happening on current cauldron, and the underlying problem might actually be somewhere in the gstreamer backend.
100% reproducable with trivial effort.
Steps to Reproduce:
1. Use the test page at https://www.youtube.com/html5 to verify.
Youtube is actually one of the sites with the least impact, but it's an easy test. My master program requires H264 this for lectures via mediasite (no other Linux options), so I've actually went back to using an old MGA3 box, where this same functionality works.
[rick@newsauramon BUILD]$ rpm -qa | grep gstreamer | sort
In firefox, "media.gstreamer.enabled" is set to true.
To have H264 support, you are supposed to have the appropriate gstreamer libraries installed, which I think I have done. If not, we need some documentation at the minimum.
If needed, I can pull my package set from the MGA3 computer. Perhaps someone could see if this issue is present in MGA4?
Steps to Reproduce:
(In reply to Richard Houser from comment #0)
> Description of problem:
> Firefox is unable to play h264 video via HTML5. HTML5 is a pretty big deal
> for a mainstream browser to be missing. If someone else can confirm my
> report, I think this should be a release blocker.
Works for me. Clean install of Mageia-5-beta1-x86_64-DVD.iso+updates.
I wonder if it is because I have tainted media enabled.
Noticed your list does not have gstreamer1.0-x264-1.4.3-2.mga5.tainted installed.
Created attachment 5816 [details]
diff of your_list my_list
Comment on attachment 5816 [details]
diff of your_list my_list
Thank you for the diff. I went through that list, ripped out as much as I could, etc. This is the relevent list I now have on my machine, and it's working:
[rick@newsauramon mga_packages]$ rpm -qa | grep gstreamer | grep 1.0 | sort
If I remove either gstreamer1.0-faad-1.4.3-2.mga5.tainted (no free version available) or
gstreamer1.0-plugins-good-1.4.3-2.mga5, the detection fails. This isn't particularl intuitive, as the dependency is based on an audio codec, not the plugins that specifically reference mpeg codecs.
The others in the list have various other dependencies on my system that make them too difficult to remove (some like libav in firefox on itself), but I'm pretty sure we only need the two I've identified.
I'm not sure what the actual fix should be, due to the tainted aspec of an otherwise clean package. Perhaps a combination these options?:
1. SPEC update adding a recommend against these two packages
2. Documentation fix/erata, due to the tainted aspect
3. Should there be a gstreamer1.0-faad-stub or something in the core repo with an equivalent provide to preserve the dependency and then an obsolete against it in the tainted version?
(In reply to Richard Houser from comment #3)
> If I remove either gstreamer1.0-faad-1.4.3-2.mga5.tainted (no free version
> available) or
> gstreamer1.0-plugins-good-1.4.3-2.mga5, the detection fails. This isn't
> particularl intuitive, as the dependency is based on an audio codec, not the
> plugins that specifically reference mpeg codecs.
I have some bad news. Just did a clean install of Mageia-5-beta2-x86_64-DVD.iso and fadd/good rpms are installed but https://www.youtube.com/html5 now shows H.264 not enabled even though I have this plugin.
OpenH264 Video Codec provided by Cisco Systems, Inc.
Play back web video and use video chats.
I might be wrong here but AFAIK this plugin isn't for video playback. It's mostly for video chats. So the YouTube's H264 video might be incompatible.
(In reply to Sander Lepik from comment #5)
> I might be wrong here but AFAIK this plugin isn't for video playback. It's
> mostly for video chats. So the YouTube's H264 video might be incompatible.
https://www.youtube.com/html5 is not a video but a plugin test link.
Check it out.
I know what it is, I have html5 enabled there. But it doesn't test if you have plugin or not, it tests if your browser can play specific formats and I'm afraid that OpenH264 doesn't provide needed support.
How about Firefox 38 ESR?
WebRTC H264 video streams from CiscoSpark native clients are not decoded correctly. (Fixed in Firefox ESR 38.0.1; was already fixed in Firefox 38.0)
Firefox 38 ESR will arrive in Mageia 5 shortly after the release, right now it's too early to do the change just before the release.
Removing the errata tag, as it's an upstream issue, and we probably don't want to start listing all shortcomings of projects we package :)
Rémi, we need at least to tell in the release notes that Firefox 38 will be provided as an update. Also, Firefox is a very important package so an Errata entry, even for an upstream bug, would be nice. Adding FOR_ERRATA back, remove it again if you still disagree.
*** Bug 16092 has been marked as a duplicate of this bug. ***
I got it working with the Gnome LiveDVD (final set). There is no sound at first but I just enabled the Tainted Release repo and updated. After that sound was available. I'm guessing that one of the good|bad|ugly plugins package for gstreamer 1.0 is needed to do the work.
Hi, just passing by and thought I add my comment, since I've had the same problem. Actually, I'm not sure about it, because I supposed html5 would have Google's own codec (V8 or something) instead of h264. But then again, I barely understand all this... :-( I can discover the exact video details if it is important.
It's interesting to note that:
1. I already had the tainted repos enabled and they didn't make it work;
2. Phonon-vlc in tainted is the same version (2.2.1 IIRC) which is in the normal repos, thus it was not updated. I forced it to happen, to no avail.
3. Installing Firefox directly from Mozilla solved the problem.
Here's my post, wrongly posted in bug 16316 and now copied here, for your convenience:
It solved for me, too, so I thought about writing one of my short comments to enrichen this bug... :-)
This is M5 on a less old than usual machine: a Core 2 Duo ~3.0GHz, 2GB RAM, onboard video and sound (HDA Intel). Pretty much standard, has always worked to this day. It's from the December'09 IIRC but nonetheless very fast.
KDE+Xfce+LXDE were installed.
Firefox wouldn't play any sound in HTML5 videos. Flash is not installed and I chose the HTML5 player in that famous Youtube player preference page.
Midori was installed and complained something about packagekit-gstreamer-something wanting gst-* (yeah, forgot to take notes and the message never came back again). To make a long story short, I tried to install phonon-gstreamer, against Luc (Menut) advice in a Mageia wiki (praising phonon-vlc) and it was to no avail.
Tested in W3schools video demo -- no sound, too (just checked with Mozilla's FF and it has sound).
The funny thing is that Last.fm did play song snippets alright. Also, W3schools has an html5 audio test which worked OK.
Summing up, Midori, Qupzilla and Konqueror all had no sound in html5 videos.
Chromium worked on a few (I suppose it could be related to a different audio codec, but it's really just a wild guess), but didn't even play the images without sound in most videos. It just went "an error occurred... try later".
So I decided to look over here and try to find a bug and voilÃ ! Tried the Verscheldes' suggestion and, to my surprise, it really worked!
Tell me if you want some hardware detail, but let me say that outside of html5 videos everything worked in sound in the original installation, from initial KDE TA-DA-like intro to tests in sound configuration. So, it was not a driver problem.
I'm changing this bug's priority to major, if you don't mind, because I believe Chromium still in not up to par regarding site compatibility as Firefox. If FF stops working we'd be in very big trouble.
Two main uses I have call for it IMHO: old machines where perhaps just Konqueror would work besides FF and smartcard login, which until now has only been possible for me in FF (perhaps IE in Wine could do it, but I'd like to find another way before resorting to it).
Firefox 38.1esr (Portuguese/Brazil) from Mozilla plays html5 video with sound.
Hi, I'm sorry, I'm not so sure about whether I should file another bug or whether this one should be changed.
As I've written before, it's not a FF problem, because it also happens in Midori and Qupzilla -- though, yes, installing Mozilla's Firefox solved it in that Mozilla version.
I managed to get a Midori screen about its complaint about the missing AAC decoder. It's attached. Please feel free to remove it and avise me about opening a new bug if that's the case. From my POV, maybe the present bug is not specific to Firefox.
Created attachment 6829 [details]
Midori error message about missing codec
Packagekit-gstreamer-plugin requires an additional plugin (sic) to decode this file
The following plugin is required:
MPEG-4 AAC decoder
Do you wish to search for it now? Cancel / Search
(choosing search opens a dialogue which apparently is searching but never concludes... possibly related to a gpk-dbus-service -- just a guess)
Also, I'm testing this on 32-bits (586). Again, please advise me if it's the case of opening a new bug. I don't want to create duplicates.
Just tried something and it worked.
I observed many packages have the same name and version in the Core Release and in the Tainted repos.
One such is libavcodec56, version 2.4.9 ... both in 1.mga5 and in 1.mga5.tainted.
There's a blue down arrow besides the tainted package (I think it means it will be updated), but such updated didn't happen (possibly, I wonder, because of the version numbers).
Asking for it to be installed triggered a lot of packages as dependencies to be updated (some 40? I can't remember).
After that, html5 sound in video started working as expected.
I did a reinstall from scratch to test it... the only thing different I did is not asking for online medias during the installation, but rather added them after the first boot with MCC ("Configure additional medias...").
Does anyone know what urpmi command would cause all pending tainted updates to be installed, regardless of version numbers?
Just complementing the info above, I managed to test sound with another app -- I guess it's the Epiphany Gnome app (it appeared as "Web" in the KDE menu).
Sound worked just like in Firefox. I tried then Konqueror, which didn't start the video in Youtube (though I had asked the HTML5 player); but it worked (sound and all) with W3schools html5 video demo.
Next, I remembered I was using the 31.x version from the DVD, updated to FF 38.1 and voilÃ : it worked!
I tried updating from tainted with:
[root@localhost ~]# urpmi --media "Tainted Release" --auto-select
which gave me:
[root@localhost ~]# urpmi --media "Tainted Release" --auto-select
Um pacote nÃ£o pÃ´de ser instalado:
libxine2-1.2.6-5.mga5.tainted.i586 (devido a estar faltando libfame-0.9.so.1)
Prosseguir instalaÃ§Ã£o mesmo assim? (S/n) s
which translates to:
[root@localhost ~]# urpmi --media "Tainted Release" --auto-select
A package could not be installed:
libxine2-1.2.6-5.mga5.tainted.i586 (due to missing libfame-0.9.so.1)
Proceed with the installation anyway? (Y/n) y
Apparently things were installed, and a following command with auto-update didn't install anything.
Also, as per comment #18 (mine), I propose this bug is not upstream... and would like to know what you guys think.
I too no more think it's an upstream bug, but rather an upstream change in the way it handles that. We had a similar problem at work with a compiled-by-us firefox on ubuntu, which wouldn't have sound for mp3 anymore counting from versions 31.7.0 and 38, until we installed the "ugly" gstreamer plugin.
Hi all! I did some further testing and would like to comment on them, in the hope it could help somehow. Unfortunately I didn't take notes (like usually), so this will be drawn from my memories of this weekend.
Feel free to correct any errors I might have unwillingly committed.
First, about the installation: it's a Core 2 Duo, 2.93 GHz, 2GB RAM and enough HD space. I tried installing Gnome and KDE with the classic installer DVD; KDE with the KDE live DVD and KDE again with Mageia 5 RC. Flashplayer was not installed on purpose to better gauge HTML5 compatibility.
In all tests I purposely avoided Firefox. I tried to run Midori instead, Web/Epiphany or Konqueror when available and more infrequently Qupzilla.
The rationale for that is that Firefox and Chrome(ium) have their own internal resources, while those other browsers are more reliant on the OS.
Overall, I found all default installations are lacking with regard to multimedia.
Sound is always missing -- and that occurs also in the RC -- but in one case there was no video, too (KDE on the classic installer IIRC). Sometimes Google wouldn't play a video with HTML5, stating instead an error has occured -- I'm not sure about what happened.
In one case, as reported in the duplicate bug 16092, sound worked just in Firefox (with the KDE live installer).
After installation of task-codec-video, task-codec-audio _and_ libavcodec56 from the tainted repos, sound would work in most browsers, which apparently made things work. But I noticed the mixer volume would reset at every new webm video start. This was very annoying at late hours. This problem would be observable only in Midori; Firefox, meanwhile, didn't mess with the mixer: the volume went unchanged from video to video.
Chromium was not tested for reasons similar to Firefox: both are less reliant on the OS features. In previous tests that Youtube HTML5 compatibility page has shown all formats accepted by Chrome (including VP9 IIRC).
Things are not so bad because people mostly use FF or Chrome and these can be made to work. Also, most people probably will want to use the flashplayer-plugin because of things like online games or sites which do not provide HTML5 versions of their videos.
What is bad is that people end up making a mess about which packages to install, I myself included in that group. What I expected from my previous use of Mageia (and even Mandriva) was that updates would ensue right after the Tainted repos being enabled. Contrary to such expectation, enabling them produced no effect... not even by manually asking for an update. One has to toggle installation of each individual package in the Tainted repos.
After this is fixed (and it maybe even a mirror update problem), I guess we could put a note on Errata about making sure Tainted is enabled. Of course, Tainted cannot be used in some places, so we would need a package to supply whatever is missing from the default install -- even without the Tainted repos.
During beta testing, browsing was probably tested mostly with FF and/or Chrome, which is a good thing because these are two most used browsers, but it may have had the side-effect of hiding problems which those two browsers solved by themselves.
Changed platform to all as I'm testing the 586 version (albeit on a 64-bit PC).
Hi, folks, is this article somehow relevant for the present discussion?
I had problems playing h264 videos using html5 ever since I upgraded from mga4 to mga5 earlier this year. And today I stumbled across a link that solved my problem.
It turns out one have to enable two setting in Â«about:configÂ» to enable Firefox to play h264 videos.
Setting these two to Â«TrueÂ» in Firefox settings, which seems to be disabled by default, makes Firefox play x264 videos again:
(In reply to Johnny A. Solbu from comment #25)
> I had problems playing h264 videos using html5 ever since I upgraded from
> mga4 to mga5 earlier this year. And today I stumbled across a link that
> solved my problem.
> It turns out one have to enable two setting in Â«about:configÂ» to enable
> Firefox to play h264 videos.
> Setting these two to Â«TrueÂ» in Firefox settings, which seems to be disabled
> by default, makes Firefox play x264 videos again:
I confirm this works (wasn't before)
(In reply to Manuel Hiebel from comment #26)
> (In reply to Johnny A. Solbu from comment #25)
> > media.fragmented-mp4.exposed
> > media.fragmented-mp4.ffmpeg.enabled
> I confirm this works (wasn't before)
The question then becomes, can we enable these settings in packaging?
(In reply to Johnny A. Solbu from comment #27)
> > > media.fragmented-mp4.exposed
> > > media.fragmented-mp4.ffmpeg.enabled
> The question then becomes, can we enable these settings in packaging?
Sure. But there would also be the question what happens in a installation, where no tainted codecs are installed ? On the other hand, it can't be much worse then currently where it doesn't work at all.
@Thierry: Any objections?
(for the notice, since some days it crash firefox, I switched it to default and it's now ok)
What's the status for this bug? Has the proposal from comment #25 been applied?
Hi, Samuel and everyone!
Please see the link in comment #24 for a longer description of those settings mentioned in comment #25.
I guess we should back up a few steps and try to understand why such situations arise. I'm not 100% certain of the following, so please someone correct me if something is incorrect to some degree.
AFAIU, Mageia's ability to play media depends on some codecs, of which:
1. some may be in libraries -- installed at any time (either from normal or tainted repos) and
2. some may be played by some particular applications which already embed them (the codecs) or can have they added as plug-ins.
A first thing to check is whether codecs are correctly made available and installed from the normal and tainted repos.
Second, Firefox (and perhaps other apps, too), might lack some settings to make codecs work (both when it uses the system ones and when it uses some internal component or plug-in). Some of these tweaks are found on the aforementioned link.
I'm not an expert on codecs to know which would be missing, but I guess there should be some kind of diff to checks packages installed by two distros -- just to make sure Mageia is on par with e.g. Mint.
The same thing would apply to Firefox configs.
Sorry if I state the obvious, the best thing would be having a media-savvy guy in charge of making sure Mageia adapts to new codecs ASAP. Such a person is hard to find and even then, not always available for voluntary work.
If this is already done, if you already have such a guy or team -- or even if this is so obvious that it's boring... well, sorry... I mean no harm.
From past posts, I know you always keep an eye on the main distributions.
If it will help I have created a test web page that features a wide
selection of the same video(s) but delivered using the most popular,
or new, codecs. That page can be found at:
The page was created to test various HTML5 coding. I use it when I encounter
any device in which I question its ability to render/play any one of the
popular codecs. I'll go into a smartphone store and try the various phones
to see what they can, and cannot play. Results vary extremely widely.
My own personal smartphone ( Samsung ) plays every one of these files
but it does so using the VLC media player. I have found that natively
Chromebooks play most if not all of everything on this page. I have
found that Windows 10 platforms play little to none of them.
Adding codecs, tricks, bells, whistles, cheats and hacks may/will
improve the performance of the platform under test. I'm kinda partial
to HTML5 code and the new VP9 codec. That's kinda nice.
What's going on here is the major suppliers of whatever are trying
to avoid paying royalty fees or get sued for not paying them. Or
complaints on why they don't play or play poorly.