h264 announced while not available




4 years ago
4 years ago


(Reporter: wolfiR, Unassigned)


43 Branch

Firefox Tracking Flags

(Not tracked)



(1 attachment)



4 years ago
When I visit www.youtube.com/html5 with Firefox 43 on Linux I get all checkmarks checked but Firefox is actually not able to play H.264 according to the test video here:

I guess this is because the libavcodec library of my Linux distribution does not include H.264 support because of patent reasons. Firefox should be able to detect the actual support.
This is fixed in bug 1211335 and is available in 44 beta.
Sorry it missed the deadline for 43 :(
Last Resolved: 4 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1211335
as a temporary workaround, set the preference media.fragmented-mp4.enable to false

This will disable aac/mp3/h264 ffmpeg decoder and with youtube you'll fall be to MSE/webm (VP9 and Opus or Vorbis)
hmmm actually my bad, this is in 43 already, and we properly check that ffmpeg is compiled with h264 support before reporting that we do accept mp4/h264.

Comment 4

4 years ago
This is what I just noticed. In that case I'm confused though since for me it does not seem to work.

11:26:42.544 Media resource http://www.html5videoplayer.net/videos/toystory.mp4 could not be decoded.1 mp4-h-264-video-test

When I replace libavcodec with another inofficial package it plays fine.

Can I provide any debugging information?
Resolution: DUPLICATE → ---
I just checked. Removed all system copy of ffmpeg and compiled my own with the following option:
./configure --enable-shared --prefix=/usr/local --disable-nonfree --disable-decoder=aac --disable-decoder=h264 --disable-decoder=mp3

make && make install

ran Firefox 43 downloaded from www.mozilla.org

www.youtube.com/html5 properly shows that MSE & H264 is not available.
it shows that h.264 is available but that's because gstreamer is installed and gstreamer has a h264 plugin installed.

So I uninstalled the gstreamer0.10-ffmpeg plugin and restarted firefox.

Now neither h.264 nor mse & h264 are reported as being unavailable.

I can't fault the code here... 

Which distribution are you using? maybe I can download a VM and try to reproduce.

BTW, there's currently a bug on YouTube side where even if mediasource is available, they won't serve it to us. So either wait a few days and you'll be able to enjoy high-resolution video (via MSE/VP9) or fake your user agent to report that it's version 44.
Flags: needinfo?(mozilla)

Comment 6

4 years ago
I'm trying it on openSUSE Leap 42.1.
The ffmpeg package sources and build configuration is here:

I'll do a bit more testing myself as well.


4 years ago
Flags: needinfo?(mozilla)

Comment 7

4 years ago
One more thing I noticed in my tests:
When libavcodec is detected (and is not supporting H.264) it does also not fall back to GStreamer. When I completely remove libavcodec from the system, Firefox plays H.264 as in http://www.html5videoplayer.net/videos/toystory.mp4 through GStreamer again.
So I think it really comes down to the libavcodec detection still which for some reason is not completely exact at least with the version shipped by openSUSE.
what does youtube.com/html5 shows for MSE.H264 and plain H264?

If it shows MSE.H264 has being unavailable, then we have properly detected that libavcodec can't do H264 (gstreamer can't be used with MSE)

If however H264 shows as being available (while MSE is shown as unavailable) then it's GStreamer that is playing up, not our handling of libavcodec and it's gstreamer not properly reporting that libavcodec can't do h264.

GStreamer is going soon, too buggy

Comment 9

4 years ago
When the openSUSE version of libavcodec is installed it shows all methods available (with and without having gstreamer's libav installed). If I wipe libavcodec completely the MSE.H264 is gone while the H264 stays checked if gstreamer's libav is installed.
(In reply to Wolfgang Rosenauer [:wolfiR] from comment #9)
> When the openSUSE version of libavcodec is installed it shows all methods
> available (with and without having gstreamer's libav installed). If I wipe
> libavcodec completely the MSE.H264 is gone while the H264 stays checked if
> gstreamer's libav is installed.

Ah, strange. I have openSUSE 42.1 versions of gstreamer, ffmpeg and libavcodec installed, and in SeaMonkey 2.43a1 YouTube tells me H264 is not available but everything else (including "MSE & H264") is. (I know that these packages are available also from Packman but AFAICT my only Packman package is Flash, which openSUSE 42.1 does not offer.)
Can someone post the config.log generated when running ffmpeg's configure following opensuse packager?

I'm not fluent in their packaging system, and this would save me time troubleshooting the problem

Comment 12

4 years ago
Posted file config.log
do you know if they use LibAV or FFmpeg ?
(In reply to Jean-Yves Avenard [:jya] from comment #13)
> do you know if they use LibAV or FFmpeg ?

NM, they do use ffmpeg.
ok.. I can reproduce the problem now...

thank you for that...
The issue is actually ffmpeg, with those options it returns that H264 is actually available.

You can also check that in the generated config.h you find:
#define CONFIG_H264_DECODER 1

my guess this happens because you have the option --enable-vaapi and --enable-vdpau provided which are hardware h264 decoders but are unusable here...
oh.. actually, the decoder code *is* available... So the entire idea of bypassing patented stuff is totally silly.
The Suse ffmpeg does include the h264 decoder.

You can see that in the ffmpeg configure script you find:

so if you add --enable-vdpau or --enable-vaapi then the software h264 will be enabled and active, and as such Suse is shipping with h264 decode.

And you can check yourself that youtube mp4/h264 video *will play* (because they serve opus audio with h264 video)

mp4 with aac however will not play as here ffmpeg do not have an AAC decoder available.
here we see that http://pearce.org.nz/video/h264.html
The CanPlayType is passing the codec type, yet return "probably" it should have returned "no" here.

In any case, Suse should seriously reconsider why they provide those configuration arguments, because if its to remove patented codecs, it's a big fail. but I'm no lawyer.
so this bug was fixed in bug 1211339 which can be found in beta..

The assumption of this bug however wasn't h264 but aac.
Last Resolved: 4 years ago4 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1211339
You need to log in before you can comment on or make changes to this bug.