H.264 Support in Fedora Workstation (by default)

Ask Fedora
, , , ,
1

The point of this post:

  • Ascertain current default H.264 support on Fedora Workstation.
    • Ascertain how that support is implemented and how far it goes.
  • Ascertain whether the situation will improve in the near future.

This is going to get very technical very fast.

H.264 is the video codec used in the .mp4 container. It’s been around for more than 20 years, and is by far the most widely used video codec in the world. It’s also patent-encumbered, which means you need to pay the licensors for H.264 royalties when delivering software that decodes/encodes the codec (like Fedora) to users. So, Fedora does not include software with support for H.264 except through OpenH264.

Current Support

ffmpeg -version in Fedora 40 Workstation gives me:

FFmpeg Configuration 
ffmpeg version 6.1.1 Copyright (c) 2000-2023 the FFmpeg developers
built with gcc 14 (GCC)
configuration: --prefix=/usr --bindir=/usr/bin --datadir=/usr/share/ffmpeg --docdir=/usr/share/doc/ffmpeg --incdir=/usr/include/ffmpeg --libdir=/usr/lib64 --mandir=/usr/share/man --arch=x86_64 --optflags='-O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -march=x86-64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer ' --extra-ldflags='-Wl,-z,relro -Wl,--as-needed -Wl,-z,pack-relative-relocs -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld-errors -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -Wl,--build-id=sha1 -specs=/usr/lib/rpm/redhat/redhat-package-notes ' --disable-htmlpages --enable-pic --disable-stripping --enable-shared --disable-static --enable-gpl --enable-version3 --enable-libsmbclient --disable-openssl --enable-bzlib --enable-frei0r --enable-chromaprint --enable-gcrypt --enable-gnutls --enable-ladspa --enable-lcms2 --enable-libshaderc --enable-vulkan --disable-cuda-sdk --enable-libaom --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libcdio --enable-libcodec2 --enable-libdav1d --enable-libdc1394 --enable-libdrm --enable-libfdk-aac --enable-libflite --enable-libfontconfig --enable-libfreetype --enable-libfribidi --enable-libgme --enable-libgsm --enable-libiec61883 --enable-libilbc --enable-libjack --enable-libjxl --enable-libmodplug --enable-libmp3lame --enable-libmysofa --enable-libopenh264-dlopen --enable-libopenjpeg --enable-libopenmpt --enable-libopus --enable-libplacebo --enable-libpulse --enable-librabbitmq --enable-librav1e --enable-librist --enable-librsvg --enable-librubberband --enable-libsnappy --enable-libsvtav1 --enable-libsoxr --enable-libspeex --enable-libssh --enable-libsrt --enable-libtesseract --enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libvmaf --enable-libvorbis --enable-libv4l2 --enable-libvpx --enable-libwebp --enable-libxml2 --enable-libzimg --enable-libzmq --enable-libzvbi --enable-lto --enable-libvpl --enable-lv2 --enable-vaapi --enable-vdpau --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libvo-amrwbenc --enable-libxvid --enable-openal --enable-opencl --enable-opengl --enable-pthreads --enable-vapoursynth --enable-muxers --enable-demuxers --enable-hwaccels --disable-encoders --disable-decoders --disable-decoder='h264,hevc,vc1' --enable-encoder=',a64multi,a64multi5,aac,libfdk_aac,ac3,adpcm_adx,adpcm_argo,adpcm_g722,adpcm_g726,adpcm_g726le,adpcm_ima_alp,adpcm_ima_amv,adpcm_ima_apm,adpcm_ima_qt,adpcm_ima_ssi,adpcm_ima_wav,adpcm_ima_ws,adpcm_ms,adpcm_swf,adpcm_yamaha,alac,alias_pix,amv,anull,apng,ass,asv1,asv2,av1_amf,av1_nvenc,av1_qsv,av1_vaapi,ayuv,bitpacked,bmp,cinepak,cljr,dca,dfpwm,dnxhd,dpx,dvbsub,dvdsub,dvvideo,exr,ffv1,ffvhuff,flac,flashsv,flashsv2,flv,g723_1,gif,h261,h263,h263_v4l2m2m,h263p,h264_amf,h264_nvenc,h264_qsv,h264_v4l2m2m,h264_vaapi,hap,hdr,hevc_amf,hevc_nvenc,hevc_qsv,hevc_v4l2m2m,hevc_vaapi,huffyuv,ilbc,jpegls,jpeg2000,libaom,libaom_av1,libcodec2,libgsm,libgsm_ms,libilbc,libjxl,libmp3lame,libopencore_amrnb,libopenh264,libopenjpeg,libopus,librav1e,libschroedinger,libspeex,libsvtav1,libtheora,libtwolame,libvo_amrwbenc,libvorbis,libvpx_vp8,libvpx_vp9,libwebp,libwebp_anim,libxvid,mjpeg,mjpeg_qsv,mjpeg_vaapi,mlp,mp2,mp2fixed,mpeg1video,mpeg2video,mpeg2_qsv,mpeg2_vaapi,mpeg4,mpeg4_v4l2m2m,msmpeg4v2,msmpeg4v3,msvideo1,nellymoser,opus,pam,pbm,pcm_alaw,pcm_f32be,pcm_f32le,pcm_f64be,pcm_f64le,pcm_mulaw,pcm_s16be,pcm_s16be_planar,pcm_s16le,pcm_s16le_planar,pcm_s24be,pcm_s24le,pcm_s24le_planar,pcm_s32be,pcm_s32le,pcm_s32le_planar,pcm_s8,pcm_s8_planar,pcm_u16be,pcm_u16le,pcm_u24be,pcm_u24le,pcm_u32be,pcm_u32le,pcm_u8,pcx,pgm,pgmyuv,phm,png,ppm,qoi,qtrle,r10k,r210,ra_144,rawvideo,roq,roq_dpcm,rpza,rv10,rv20,s302m,sbc,sgi,smc,snow,sonic,sonic_ls,speedhq,srt,ssa,subrip,sunrast,svq1,targa,text,tiff,truehd,tta,ttml,utvideo,v210,v308,v408,v410,vc1_qsv,vc1_v4l2m2m,vc2,vnull,vorbis,vp8_qsv,vp8_v4l2m2m,vp8_vaapi,vp9_qsv,vp9_vaapi,wavpack,wbmp,webvtt,wmav1,wmav2,wmv1,wmv2,wrapped_avframe,xbm,xface,xsub,xwd,y41p,yuv4,zlib,zmbv,' --enable-decoder=',aasc,libfdk_aac,ac3,acelp_kelvin,adpcm_4xm,adpcm_adx,adpcm_afc,adpcm_agm,adpcm_aica,adpcm_argo,adpcm_ct,adpcm_dtk,adpcm_ea,adpcm_ea_maxis_xa,adpcm_ea_r1,adpcm_ea_r2,adpcm_ea_r3,adpcm_ea_xas,adpcm_g722,adpcm_g726,adpcm_g726le,adpcm_ima_acorn,adpcm_ima_alp,adpcm_ima_amv,adpcm_ima_apc,adpcm_ima_apm,adpcm_ima_cunning,adpcm_ima_dat4,adpcm_ima_dk3,adpcm_ima_dk4,adpcm_ima_ea_eacs,adpcm_ima_ea_sead,adpcm_ima_iss,adpcm_ima_moflex,adpcm_ima_mtf,adpcm_ima_oki,adpcm_ima_qt,adpcm_ima_qt_at,adpcm_ima_rad,adpcm_ima_smjpeg,adpcm_ima_ssi,adpcm_ima_wav,adpcm_ima_ws,adpcm_ms,adpcm_mtaf,adpcm_psx,adpcm_sbpro_2,adpcm_sbpro_3,adpcm_sbpro_4,adpcm_swf,adpcm_thp,adpcm_thp_le,adpcm_vima,adpcm_xa,adpcm_xmd,adpcm_yamaha,adpcm_zork,alac,alias_pix,amrnb,amrwb,amv,anm,ansi,anull,apac,ape,apng,arbc,argo,ass,asv1,asv2,atrac1,atrac3,atrac3al,atrac3p,atrac3pal,aura,aura2,av1,av1_qsv,ayuv,bethsoftvid,bfi,bink,binkaudio_dct,binkaudio_rdft,bintext,bitpacked,bmp,bmv_audio,bmv_video,bonk,brender_pix,c93,cbd2_dpcm,ccaption,cdgraphics,cdtoons,cdxl,cinepak,clearvideo,cljr,cook,cpia,cscd,cyuv,dca,dds,derf_dpcm,dfa,dfpwm,dirac,dnxhd,dolby_e,dpx,dsd_lsbf,dsd_msbf,dsicinaudio,dsicinvideo,dss_sp,dvaudio,dvbsub,dvdsub,dvvideo,dxa,dxtory,eacmv,eamad,eatgq,eatgv,eatqi,eightbps,eightsvx_exp,eightsvx_fib,escape124,escape130,evrc,exr,ffv1,ffvhuff,ffwavesynth,fits,flac,flashsv,flashsv2,flic,flv,fmvc,fourxm,ftr,g723_1,g729,gdv,gem,gif,gremlin_dpcm,gsm,gsm_ms,gsm_ms_at,h261,h263,h263_v4l2m2m,h263i,h263p,hap,hca,hcom,hdr,hnm4_video,hq_hqa,hqx,huffyuv,hymt,iac,idcin,idf,iff_ilbm,ilbc,imc,indeo2,indeo3,indeo4,indeo5,interplay_acm,interplay_dpcm,interplay_video,ipu,jacosub,jpeg2000,jpegls,jv,kgv1,kmvc,lagarith,libaom,libaom_av1,libcodec2,libdav1d,libgsm,libgsm_ms,libilbc,libjxl,libopencore_amrnb,libopencore_amrwb,libopenh264,libopenjpeg,libopus,librsvg,libschroedinger,libspeex,libvorbis,libvpx_vp8,libvpx_vp9,libzvbi_teletext,loco,lscr,m101,mace3,mace6,mdec,media100,metasound,microdvd,mimic,misc4,mjpeg,mjpeg_qsv,mjpegb,mlp,mmvideo,motionpixels,mp1,mp1float,mp2,mp2float,mp3,mp3adu,mp3adufloat,mp3float,mp3on4,mp3on4float,mpc7,mpc8,mpeg1video,mpeg1_v4l2m2m,mpeg2video,mpeg2_qsv,mpeg2_v4l2m2m,mpeg4,mpeg4_v4l2m2m,mpegvideo,mpl2,msa1,mscc,msmpeg4v1,msmpeg4v2,msmpeg4v3,msnsiren,msp2,msrle,mss1,mss2,msvideo1,mszh,mts2,mv30,mvc1,mvc2,mvdv,mvha,mwsc,mxpeg,nellymoser,nuv,on2avc,opus,paf_audio,paf_video,pam,pbm,pcm_alaw,pcm_bluray,pcm_dvd,pcm_f16le,pcm_f24le,pcm_f32be,pcm_f32le,pcm_f64be,pcm_f64le,pcm_lxf,pcm_mulaw,pcm_s16be,pcm_s16be_planar,pcm_s16le,pcm_s16le_planar,pcm_s24be,pcm_s24daud,pcm_s24le,pcm_s24le_planar,pcm_s32be,pcm_s32le,pcm_s32le_planar,pcm_s64be,pcm_s64le,pcm_s8,pcm_s8_planar,pcm_sga,pcm_u16be,pcm_u16le,pcm_u24be,pcm_u24le,pcm_u32be,pcm_u32le,pcm_u8,pcm_vidc,pcx,pfm,pgm,pgmyuv,pgssub,pgx,phm,photocd,pictor,pjs,png,ppm,prosumer,psd,ptx,qcelp,qdm2,qdmc,qdraw,qoi,qpeg,qtrle,r10k,r210,ra_144,ra_288,rasc,rawvideo,realtext,rka,rl2,roq,roq_dpcm,rpza,rscc,rv10,rv20,s302m,sami,sanm,sbc,screenpresso,sdx2_dpcm,sgi,sgirle,shorten,simbiosis_imx,sipr,siren,smackaud,smacker,smc,smvjpeg,snow,sol_dpcm,sonic,sp5x,speedhq,speex,srgc,srt,ssa,stl,subrip,subviewer,subviewer1,sunrast,svq1,svq3,tak,targa,targa_y216,tdsc,text,theora,thp,tiertexseqvideo,tiff,tmv,truehd,truemotion1,truemotion2,truemotion2rt,truespeech,tscc,tscc2,tta,twinvq,txd,ulti,utvideo,v210,v210x,v308,v408,v410,vb,vble,vcr1,vmdaudio,vmdvideo,vmnc,vnull,vorbis,vp3,vp4,vp5,vp6,vp6a,vp6f,vp7,vp8,vp8_qsv,vp8_v4l2m2m,vp9,vp9_qsv,vp9_v4l2m2m,vplayer,vqa,vqc,wady_dpcm,wavarc,wavpack,wbmp,wcmv,webp,webvtt,wmav1,wmav2,wmavoice,wmv1,wmv2,wnv1,wrapped_avframe,ws_snd1,xan_dpcm,xan_wc3,xan_wc4,xbin,xbm,xface,xl,xpm,xsub,xwd,y41p,ylc,yop,yuv4,zero12v,zerocodec,zlib,zmbv,'

So, encode/decode support for H.264, H.265, and VC-1 is disabled. AAC support, which is the audio codec commonly used with H.264, is enabled and provided by libfdk-aac, which is presumably patent-free. H.265 has many thousands of patents that won’t expire for a long time yet, and I’m not sure where VC-1 is used.

H.264 support is not provided by ffmpeg’s x264. It is instead provided by OpenH264 with the OpenH264 package and as an encoder/deocder for ffmpeg. Cisco provides OpenH264 in binary format only, and covers licensing fees for all parties. Firefox automatically downloads OpenH264 but Fedora disables it by default.

Without enabling OpenH264, I went to YouTube, Netflix, and Binge and was able to play video on all of them. I have no clue what codec they served me because I can’t figure out how to analyze that with Firefox’s developer tools. if somebody could teach me how, that would be much appreciated. I installed Chromium and checked with the Media tab in Developer Tools, and it said I was using the dav1d decoder, so YouTube serves me AV1. I was not able to check Netflix or Binge, as DRM isn’t currently working for me on Chromium; only Firefox.

Next, i tried to play some H.264 video files locally. As I understand it, this functionality is enabled by GStreamer for some video players; specifically gstreamer1-plugin-openh264. At least, Totem uses it. mpv uses ffmpeg directly from my understanding.

Regardless, it didn’t work. OpenH264 does not appear to have support for High 10 Profile. And here’s the relevant issue: Adding support for 10 bit depth video? · Issue #3616 · cisco/openh264 · GitHub

I tried another H.264 video, this time using what appeared to be plain High Profile based on ffprobe output, but both mpv and Totem struggled. It would freeze for seconds at a time and produce artifacting. mpv’s log produces this:

Error while decoding frame!
[ffmpeg/video] libopenh264: [OpenH264] this = 0x0x55bdb45bd030, Warning:referencing pictures lost due frame gaps exist, prev_frame_num: 49, curr_frame_num: 51
[ffmpeg/video] libopenh264: DecodeFrame failed

So OpenH264 is currently lacking full compatibility with some H.264 streams, particularly High Profile. In fact, most of my videos are either unplayable or barely, “technically” playable by default. I have a few Main Profile videos that play okay.

Open Questions:

  1. Does Fedora make use of hardware decoders for H.264/H.265?
  2. Is there any built-in way to check what decoder Firefox is using to decode media for a site?
  3. Is OpenH264 meant to support plain High Profile properly and I’m missing something, or has this always been a gap in the decoder? The Github page doesn’t mention High Profile as a feature. I only have these H.264-related pacakges installed:
gstreamer1-plugin-openh264-0:1.22.9-3.fc40.x86_64
openh264-0:2.4.0-2.fc40.x86_64

H.264 Baseline/Main/Extended Patents

The patents for Version 1, which includes the Baseline/Main/Extended profiles may have already expired, at least in Europe, and possibly in the US, according to this page: Have the patents for H.264 MPEG-4 AVC expired yet? - Meta

H.264 High Profile Patents

Since its initial standardization in 2003, H.264 has undergone 26 standards revisions, with the latest version (27) being standardized in 2021. Major additions include SVC in 2007 and MVC in 2009. The most important change, however, came with Version 3 in 2005: the High, High 10, High 4:2:2, and High 4:4:4 Profiles. The High Profile is used almost everywhere, and even the use of SVC and MVC is backwards compatible with High Profile.

What this means: while more patents exist for later versions of the H.264 standard, they can be ignored. When the patents for High Profile expire, it will be possible to ship a royalty-free decoder that can decode all H.264 streams.

Open Questions:

  1. Will Fedora replace OpenH264 with another royalty-free decoder when the High Profile is patent-free? Or will OpenH264 be further developed to include more features? My understanding is that this encoder/decoder is constrained in certain ways.

When Will They Expire?

Good question. This is one possible answer: Have the patents for H.264 MPEG-4 AVC expired yet? - Meta

Sometime in the next 4 years, maybe? No one seems entirely sure which patents are necessary for High Profile, so it could be earlier or later. Additionally, some of the patent expiration dates, which are based on Google Patents, could be wrong. Either way, it’s happening this decade.

Via-La (the licensor for H.264) publishes a list of active and expired patents every three months, so this is the best place to check whether a patent is active: https://www.via-la.com/licensing-2/avc-h-264/avc-h-264-patent-list/

Note that not all patents are necessarily required for implementing High Profile encoders/decoders.

Will Some Patents Be Invalidated Before They Expire?

Maybe! Unified Patents invalidated a patent required for H.264 (and H.265) in 2023 that was due to expire in 2026: IP Bridge video codec patent invalidity confirmed by PTAB in ex parte appeal — Unified Patents

Am I missing anything? Or am I wrong about anything? Would love to know more.

2 Likes
2

Well, since some time last year, I was testing this very scenario and found out that the av1 format is what they are serving. If you need to find out what format you are being served, I have such tools, and there are some browser tricks to retrieve that information.

I believe Google is pushing the av1& avif formats more, as even downloading images has produced some with avif format ( “which is fine in my book, it’s a better compression for jpg, png, webp” ) .

3

I’d love to know how to know what media I’m being served on FIrefox!

When I say “without enabling OpenH264”, I really mean, “I just installed Fedora Workstation and changed none of the defaults.” By default I have those 2 OpenH264 packages installed, so I assume I’m able to decode certain H.264 streams? But the Plugin for OpenH264 is disabled, so…

Oh, worth mentioning I tried Vimeo too. It seemed to freeze occasionally just like those High Profile videos I played locally, but it played.

I’m starting to wonder whether YouTube even serves H.264 anymore. I checked all the streams for a video with yt-dlp -F and downloaded the highest quality mp4 stream, but it turned out to be VP9.

4

In fedora the proprietary or licensing of the h264 codec means it can only be distributed by cisco.
Fedora enables the fedora-cisco-openh264 repo when the user enables the 3rd party repos during the initial setup of a new installation. (The rpmfusion-nonfree-steam and rpmfusion-nonfree-nvidia-driver repos are enabled at the same time)

I do not see that fedora will ever (or at least not in the near future) be able to directly include the h264 support in fedora, but does have an arrangement with cisco to allow the distribution via the noted repo.

Additional codecs that fedora cannot distribute for similar reasons can be obtained from the rpmfusion-nonfree (and the rpmfusion-free) repo by configuring the repo access as shown here then installing ffmpeg and/or libavcodec-freeworld from that location.

Fedora does include the ffmpeg-free package which has been stripped of problematic codecs, and has several parts of the libavcodec package which have also been stripped of the problematic codecs.

5

Unfortunately hardware decoders are not allowed in Fedora anymore. See this article for more information.

I’ll let somebody else answer this.

High profile is supposed to be fully supported; Red Hat and Endless sponsored that work a few years ago. But it looks like you’ve discovered this isn’t fully true? I wasn’t aware of this problem with 10 bit depth video. I’m not a multimedia expert and don’t have more to say about this.

I’m not sure. The challenge is we need to be confident that any decoder you want to enable is actually noninfringing. I’m not aware of anybody working on that. E.g. we can’t just enable the H.264 support in ffmpeg because we don’t know whether it implements stuff newer than 2005 (it probably does?). Even when all relevant patents are expired, we might be stuck with only OpenH264 if nobody is working on figuring out what we can and cannot do. So I’d say this is a help welcome area. Upstream H.264 decoder projects have decided to ignore patent issues and probably won’t be much help, so we’re kind of on our own here.

Unhelpfully, Fedora Legal has all but disappeared, so the IP risk decisions here will probably be made by Fedora developers who are not qualified to do so rather than by lawyers who are. The damage to Fedora and Red Hat if we get this wrong could be considerable, so we need to be really confident we’re not messing up.

I’d really like to see this change, but right now the status quo is we won’t be ready to change anything even if all patents expire. So contributing to improve OpenH264 is a safe choice for now.

This isn’t true. The Cisco repo is always enabled. The software is built and signed by Fedora, even though it’s being distributed by a third party.

(Actually, only their repo metadata is enabled. The repos themselves stay disabled.)

4 Likes
6

Is the output of dnf repolist invalid then?
Newly installed VM from the live workstation ISO and the 3rd party repos enabled during initial user setup gives this.

$ dnf repolist
repo id                                                         repo name
copr:copr.fedorainfracloud.org:phracek:PyCharm                  Copr repo for PyCharm owned by phracek
fedora                                                          Fedora 40 - x86_64
fedora-cisco-openh264                                           Fedora 40 openh264 (From Cisco) - x86_64
google-chrome                                                   google-chrome
rpmfusion-nonfree-nvidia-driver                                 RPM Fusion for Fedora 40 - Nonfree - NVIDIA Driver
rpmfusion-nonfree-steam                                         RPM Fusion for Fedora 40 - Nonfree - Steam
updates                                                         Fedora 40 - x86_64 - Updates

and this

$ grep "enabled=1" /etc/yum.repos.d/*
/etc/yum.repos.d/_copr:copr.fedorainfracloud.org:phracek:PyCharm.repo:enabled=1
/etc/yum.repos.d/fedora-cisco-openh264.repo:enabled=1
/etc/yum.repos.d/fedora.repo:enabled=1
/etc/yum.repos.d/fedora-updates.repo:enabled=1
/etc/yum.repos.d/google-chrome.repo:enabled=1
/etc/yum.repos.d/rpmfusion-nonfree-nvidia-driver.repo:enabled=1
/etc/yum.repos.d/rpmfusion-nonfree-steam.repo:enabled=1

Both those repos are enabled.

I agree that the metadata is enabled and the repos not enabled at first, but when the user selects to enable 3rd party repos they actually are enabled.

7

Added chromium, firefox, h264

8

That was an informative read, thank you!

Though it’s worth noting that Chrome enabled H.265 decoding in hardware over a year ago specifically to avoid patent issues: Google Chrome Plays HEVC: What Does it Mean?

Hardware decoders would be the cleanest way to solve this issue. The Chrome situation above does indicate that it’s legal, though I’m not sure if it differs from the Fedora situation…I guess Chrome passes the buck to Fedora to implement the software component that enables hardware decoding.

This is what happens when I try to play a High 10 Profile video, which I have a lot of:

image

(The Find in Software button just takes me to a list of two GStreamer packages I already have installed)

As for plain High Profile…it seems to vary. Crunchyroll videos are in H.264 High Profile, and the ones I tried play fine. See this H.264 High Profile video for example: https://www.crunchyroll.com/watch/GYME9M3P6/the-misfit-of-demon-king-academy

But not all web video plays back properly. For example, this Vimeo video: THANK YOU FOR NOT ANSWERING on Vimeo

In Firefox, it stutters a little, and the video track straight up freezes for a few seconds when you seek back but the audio still plays. In Google Chrome, this video plays perfectly fine even when seeking. In Chromium, H.264 doesn’t play back at all, but I guess that’s a separate issue…

I have a local H.264 High Profile video that uses the .mkv container and looks like this from ffprobe, but it freezes up a lot with DecodeFrame fails:

Metadata:
    encoder         : libebml v1.3.0 + libmatroska v1.4.0
    creation_time   : 2013-04-14T14:10:40.000000Z
  Stream #0:0: Video: h264 (High), yuv420p(progressive), 640x480, SAR 1:1 DAR 4:3, 23.98 fps, 23.98 tbr, 1k tbn (default)

Almost certainly.

I’d also really like to see this change! We’re only a few years out from H.264’s High Profile finally being patent-free, and H.265 hasn’t had much adoption, so in my eyes, it’s the last significant pain point for Linux distributions regarding video/audio (mp3 has been patent-free since 2017). Together with Nouveau + NVK & explicit sync making significant improvements to the NVIDIA stack and the color management protocol approaching v1, the out-of-the-box experience at least on Fedora Workstation could become much better for a lot of users.

Unfortunately, all I could really do to help was gather all the information about the situation as I know.

9

Hm, you’re right: all the repos do get enabled. (But the metadata really is turned off if you don’t click the button.) I think that’s probably a bug, though, because having unnecessary repos enabled slows down dnf, and because there’s no point in having the distinction between “enabled” and “only metadata enabled” if we don’t use it. I will ask about this.

One possibility is Google lawyers came to a different determination than Red Hat lawyers. Another possibility is that Google actually is paying royalties and you just don’t know about it. Yet another possibility is software decoding of H.265 might be disabled for performance reasons rather than legal reasons. I don’t know what the difference is. What I do know is HEVC won’t be allowed in Fedora for a very, very long time, so we’d better hope it doesn’t become popular on the web.

So it is supported, and just buggy. :wink: As a point of reference, that video plays perfectly fine in Epiphany Tech Preview (which also uses OpenH264). I’m not sure what codec is being used there, but suffice to say you’re encountering a bug of some sort.

P.S. Nice username.

1 Like
10

The Vimeo video plays fine for me on the default Firefox install, which I use basically only for the purpose of playing H.264 videos. I do have these packages installed

matthew@goku:~$ rpm-ostree status
State: idle
Deployments:
● fedora:fedora/40/x86_64/silverblue
                  Version: 40.20240427.0 (2024-04-27T01:30:53Z)
               BaseCommit: 65eb5cf8d3e9dc832fa7e307fb703f2d789b13c44684d246f0e572382f2357da
             GPGSignature: Valid signature by 115DF9AEF857853EE8445D0A0727707EA15B79CC
      RemovedBasePackages: noopenh264 0.1.0~openh264_2.4.0-1.fc40
          LayeredPackages: gstreamer-plugins-espeak gstreamer1-plugin-openh264.x86_64 gstreamer1-plugins-bad-free-extras.x86_64
                           gstreamer1-plugins-base-tools.x86_64 gstreamer1-plugins-good-extras.x86_64 gstreamer1-plugins-good-gtk.x86_64
                           gstreamer1-vaapi.x86_64 lame.x86_64 libva-utils.x86_64 mozilla-openh264.x86_64 mozilla-privacy-badger.noarch
                           openh264.x86_64

Not trying to brownnose but Epiphany is my current default because I like that it uses GStreamer. When Fedora Flatpaks has the openh264 package I’ll probably do an rpm-ostree reset and just use those. When I had it installed from Flathub it was able to use the openh264 package there just fine as well.

11

Also you can go get the hardware decoding for H.264 from the RPMFusion repo. Check out the per-vendor instructions for VA-API, they explicitly mention restoring hardware acceleration for H.264.

https://fedoraproject.org/wiki/Firefox_Hardware_acceleration

12

It seems likely that this was caused by lack of hardware acceleration. Web-safe videos seem to work properly aside from that. But my local video actually failed to decode properly with OpenH264 and regularly seemed to drop I-Frames.

I ended up configuring RPM Fusion and installing all the multimedia packages and as expected, video playback is fine now.

You’re right there. I would like to say it’s really unlikely Google is preparing to adopt H.265 software decoding now because of all companies, they’ve been one of the biggest pushing for new royalty-free formats like VP8/VP9/AV1. Then, they also said they would drop H.264 support 13 years ago: Chromium Blog: HTML Video Codec Support in Chrome

As you say, no one knows but Google.

What I do know is HEVC won’t be allowed in Fedora for a very, very long time, so we’d better hope it doesn’t become popular on the web.

I certainly hope so! (although it’s also worth mentioning that Firefox decodes HEVC on Windows in hardware now)

:slight_smile:

1 Like
13

Some tips regarding GStreamer plugins:

  • The GStreamer packages that end in -extras are split out separately because they are rarely used. Installing them increases your attack surface, so they are not suitable for most users and should only be installed if actually required.
  • gstreamer-vaapi is obsolete. It used to break video playback for users, but nowadays the va element from gstreamer1-plugins-bad-free takes precedence, so I think gstreamer-vaapi just doesn’t get used anymore at all. I think almost nobody should install this.
1 Like
14

likewise for me.

these are saved videos probably on the internal or an external disk, not streaming videos right & neither mpv nor vlc can play them?

15

Yes, these are local videos. MDN suggests High 10 is used on the web too, though I haven’t found a video in that profile yet. Fedora’s own Neal Gompa filed an issue about the lack of support for High 10 video in the OpenH264 issue tracker last year: Adding support for 10 bit depth video? · Issue #3616 · cisco/openh264 · GitHub

An OpenH264 collaborator also responded to this issue saying only 8-bit depth video is supported: What pixel formats does this support? · Issue #3511 · cisco/openh264 · GitHub

I haven’t tried VLC, but that’s the error I get when I try Totem/Videos; the default player. I also can’t play High 10 videos in mpv; I get lots of DecodeFrame fails.

16

Happened to be looking into this again…

As recently as 2020, OpenH264 was lacking full support for the Main profile: Which profiles of h264 is already supported. · Issue #3328 · cisco/openh264 · GitHub

Yes you are right that baseline profile is fully supported in both encoder and decoder. However, for main profile, we do not claim on that because only parts of tools in Main profile are supported (like CABAC). That’s why we would not add such information in wiki.

And here, in May 2020, huili says High Profile is partially supported: Decode and Encode H264 High Profile (AVC) · Issue #3280 · cisco/openh264 · GitHub

part of High Profile tools are supported. So decoder will not directly throw error unless it meets with what it does not actually support.

I don’t know if anything has actually changed with OpenH264 since then. The best I could do was clone the OpenH264 git repo and scrub through the log for mentions of high and profile. No commit messages have referenced High Profile since 2018. The 1.5.0 release notes (2015) in the RELEASES file mentions that OpenH264 supports “Constrained High Profile”: openh264/RELEASES at 1c2388750acf8646ca75a6038a544d5f8f47dca8 · cisco/openh264 · GitHub

As for when Red Hat/Endless sponsored work on OpenH264, this post from 2019 mentions that Fedora 31 bore the fruits of it: Fedora Workstation 31 – Whats new | Christian F.K. Schaller

Then we get the note for release 2.0 in July 2019 with B-Frame decoding support for High Profile, which seems to match up nicely with the sponsored work timeframe: Release Release version v2.0.0 · cisco/openh264 · GitHub

That probably explains why some of my High Profile videos hit some snags with OpenH264.

1 Like
17

i am big on gnome, i mean gnome is not my preferred desktop environment it is the desktop environment for me. my first foray into linux was with ubuntu gnome…gnome for me is linux. but sadly i have given up on epiphany(streaming video) & totem(video playback) since many years now as they have failed me on arch, debian, fedora & ubuntu.
so good luck with totem & do update if vlc does the job for you.

18

All videos are working fine for me with mpv now that I have the RPMFusion repos configured :slight_smile:

I don’t mind VLC but I’ve invested a lot into making mpv work for a few workflows that VLC doesn’t.

19

mpv is brilliant. stick with it.

2 Likes
20

Thanks for the tips! There was an official Fedora doc at one point that basically had the regex for good/bad/ugly plugins plus lame, but the command didn’t work for rpm-ostree for me so I went and installed them manually. Saw gstreamer-vaapi and it also looked like a package I’d want. Whoops!