index.xml

<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Pixels</title>
    <link>https://bbhtt.in/</link>
    <description>Recent content on Pixels</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en</language>
    <copyright>CC BY-NC-SA 4.0</copyright>
    <lastBuildDate>Sat, 22 Mar 2025 18:48:40 +0530</lastBuildDate>
    
        <atom:link href="https://bbhtt.in/index.xml" rel="self" type="application/rss+xml" />
    
    
    <item>
      <title>Closing the chapter on OpenH264</title>
      <link>https://bbhtt.in/posts/closing-the-chapter-on-openh264/</link>
      <pubDate>Sat, 22 Mar 2025 18:48:40 +0530</pubDate>
      
      <guid>https://bbhtt.in/posts/closing-the-chapter-on-openh264/</guid>
      <description>&lt;p&gt;People might have noticed me talking about dropping OpenH264 from
&lt;a href=&#34;https://gitlab.com/freedesktop-sdk/freedesktop-sdk&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;Freedesktop SDK&lt;/a&gt;.
Here, I&amp;rsquo;ll try to go a bit into the history, the timeline and what led
to the final decision.&lt;/p&gt;
&lt;h2 id=&#34;a-bit-of-an-introduction&#34;&gt;A bit of an introduction&lt;/h2&gt;
&lt;p&gt;If you are unfamiliar with the Freedesktop SDK project: it was born out
of the initial &lt;a href=&#34;https://github.com/flatpak/freedesktop-sdk-images&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;1.6 Flatpak runtime image&lt;/a&gt;
created by &lt;a href=&#34;https://github.com/alexlarsson&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;Alexander Larsson&lt;/a&gt; to
provide a host independent &amp;ldquo;runtime&amp;rdquo; for Flatpaks. Since then, with the
help of &lt;a href=&#34;https://www.codethink.co.uk/&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;Codethink&lt;/a&gt; and others, it grew
into an independent project maintained by the community that aims to
provide a &amp;ldquo;A minimal Linux runtime&amp;rdquo;.&lt;/p&gt;
&lt;p&gt;Currently that includes the &lt;code&gt;org.freedesktop.{Sdk, Platform}&lt;/code&gt;
&lt;a href=&#34;https://docs.flatpak.org/en/latest/introduction.html#terminology&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;Flatpak runtimes&lt;/a&gt;,
a bunch of other &lt;a href=&#34;https://docs.flatpak.org/en/latest/extension.html&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;Flatpak extensions&lt;/a&gt;
such as the GL (Mesa) extensions, a bootable image stack that includes
things like the Linux kernel, firmware and drivers and a collection
of docker images.&lt;/p&gt;
&lt;p&gt;The runtimes (and more broadly the &amp;ldquo;Flatpak&amp;rdquo; stack) form the base for
the &lt;a href=&#34;https://gitlab.gnome.org/GNOME/gnome-build-meta/&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;GNOME&lt;/a&gt; and
&lt;a href=&#34;https://invent.kde.org/packaging/flatpak-kde-runtime&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;KDE&lt;/a&gt; Flatpak
runtimes which are collectively used by 2000+ Flatpaks, while the
bootable stack along with other parts forms the base for things like
&lt;a href=&#34;https://os.gnome.org/&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;GNOME OS&lt;/a&gt;.&lt;/p&gt;
&lt;h2 id=&#34;some-history&#34;&gt;Some history&lt;/h2&gt;
&lt;p&gt;H.264 is one of the &lt;a href=&#34;https://www.cloudflare.com/learning/video/what-is-h264-avc/&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;most widely used&lt;/a&gt;
codecs today but unfortunately it is patented with several patents
&lt;a href=&#34;https://meta.wikimedia.org/wiki/Have_the_patents_for_H.264_MPEG-4_AVC_expired_yet%3F&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;still active&lt;/a&gt;.
Patents like this are a blocker to shipping software dealing with the
codec in the base runtime (since we want it usable by a wide variety of
vendors and free of any legal grey areas) and unfortunately makes life
difficult for everyone involved.&lt;/p&gt;
&lt;p&gt;To workaround this and ship working software to users, 6 years ago, in
2019 the precursor to the OpenH264 extension, called the
&lt;a href=&#34;https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/commit/1c1d87eb7f1e7952bf79825cfb65225f3a3c3e30&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;html5-codecs extension&lt;/a&gt;
was added to the Freedesktop runtime by Tom Coldrick. The idea was
simple - it would contain support for FFMPEG&amp;rsquo;s internal H.264 decoder
and would be an optional Flatpak extension since we were unable to ship
it in the runtime itself.&lt;/p&gt;
&lt;p&gt;Fast-forward a few months, in June 2019, &lt;a href=&#34;https://gitlab.com/ramcq&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;Robert McQueen&lt;/a&gt;
opened an &lt;a href=&#34;https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/issues/815&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;issue&lt;/a&gt;
to include &lt;a href=&#34;https://github.com/cisco/openh264&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;Cisco&amp;rsquo;s OpenH264&lt;/a&gt;
(commonly referred as &lt;code&gt;libopenh264&lt;/code&gt; too) as an extension to the runtime.&lt;/p&gt;
&lt;p&gt;&lt;code&gt;libopenh264&lt;/code&gt; code is open source but due to the H.264 patents, no
vendor is legally allowed to distribute their own binaries (some vendors
build it themselves and hand it to Cisco but no one made that arrangement
for us). The solution to this was to distribute Cisco&amp;rsquo;s unmodified
binaries directly to the user which would effectively be free of any
royalties but the catch is, the binaries have
&lt;a href=&#34;https://www.openh264.org/BINARY_LICENSE.txt&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;some license restrictions&lt;/a&gt;
on them.&lt;/p&gt;
&lt;p&gt;So Endless around that time, added &lt;a href=&#34;https://docs.flatpak.org/en/latest/module-sources.html#extra-data&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;extra-data&lt;/a&gt;
support to Flatpak. This meant that the Flatpak extension metadata
would only contain an URL to Cisco&amp;rsquo;s binaries, checksums and a &amp;ldquo;recipe&amp;rdquo;
to make a working extension out of it. The binary would be downloaded
on the end user&amp;rsquo;s machine, inside a sandbox and then the &amp;ldquo;recipe&amp;rdquo;
would be executed to create a working extension. This avoids various
&amp;ldquo;redistribution&amp;rdquo; restrictions entirely since we aren&amp;rsquo;t shipping the
binary itself.&lt;/p&gt;
&lt;p&gt;However, one last catch remained with this approach. Unless the end user
system has downloaded the extension, a part of the ABI will be missing
from the base runtime itself. Additionally, the extension would also
get mounted to a non-standard location inside the Flatpak sandbox. So to
build something against that we needed a &amp;ldquo;public&amp;rdquo; library that is
included in the runtime itself.&lt;/p&gt;
&lt;p&gt;Endless came up with a stub OpenH264 library called &lt;a href=&#34;https://github.com/endlessm/noopenh264/&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;noopenhh264&lt;/a&gt;,
as a solution to this. This would be kept ABI/API compatible to the
actual Cisco&amp;rsquo;s OpenH264 library and would live inside the runtime at
&lt;code&gt;$libdir&lt;/code&gt; to allow software to link to libopenh264 and provide a
fallback. At runtime, if the user downloads the actual OpenH264
extension, the stub library would get overridden by the library in
extension through Flatpak&amp;rsquo;s ld.so config and voilà, you have a working
OpenH264 setup!&lt;/p&gt;
&lt;h2 id=&#34;the-start-of-the-openh264-extension&#34;&gt;The start of the openh264 extension&lt;/h2&gt;
&lt;p&gt;Following the gruelling details above, in August 2019, Tom Coldrick
&lt;a href=&#34;https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/merge_requests/1638&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;again added&lt;/a&gt;
this &amp;ldquo;noopenh264&amp;rdquo; library to the runtime and set up the extension point
called &lt;code&gt;org.freedesktop.Platform.openh264&lt;/code&gt;.&lt;/p&gt;
&lt;p&gt;Around that time, the development of the &amp;ldquo;stub&amp;rdquo; noopenh264 library also
moved under the &lt;a href=&#34;https://gitlab.com/freedesktop-sdk/noopenh264&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;Freedesktop SDK umbrella&lt;/a&gt;
while the development of this extra-data extension was going on in a
&lt;a href=&#34;https://gitlab.com/freedesktop-sdk/openh264-extension&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;dedicated repository&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;I talked about a &amp;ldquo;recipe&amp;rdquo; of an extra-data Flatpak extension a while
back, which is nothing but a set of commands in a special file called
&lt;code&gt;apply_extra&lt;/code&gt; to stage and install the source. As an example, if it
was a &lt;code&gt;.deb&lt;/code&gt; it would be a sequence of &lt;code&gt;ar&lt;/code&gt; or &lt;code&gt;bsdtar&lt;/code&gt; commands to
extract it, then install it inside Flatpak&amp;rsquo;s extra-data prefix.&lt;/p&gt;
&lt;p&gt;The catch here is that using any utility like that makes the extension
directly dependent on a particular branch of the Flatpak runtime and thus
the API/ABI provided by it.&lt;/p&gt;
&lt;p&gt;As every yearly major release of the Freedesktop runtime is a completely
new ABI, we would need to continuously spin off new branches of the
OpenH264 extension i.e. for version 2.1.0 of libopenh264 we would need
&lt;code&gt;org.freedesktop.Platform.openh264//2.1.0-{18.08, 19.08, 20.08}&lt;/code&gt; branches
for the extension and so on. This would make it a bit of an chore to
update the extension in Freedesktop runtime itself and also for
our downstream runtimes.&lt;/p&gt;
&lt;p&gt;As a solution to this, a custom &lt;code&gt;apply_extra&lt;/code&gt; script was &lt;a href=&#34;https://gitlab.com/freedesktop-sdk/openh264-extension/-/commit/8a80eaaab8cd6b6aa7e241e681bdbaeed5632e56&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;written&lt;/a&gt;,
which utilised only a few standard headers and would be &lt;a href=&#34;https://gitlab.com/freedesktop-sdk/openh264-extension/-/commit/98601a6bcfd5a287106653bc69e54b58ce619c9e&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;built statically&lt;/a&gt;
against a fixed toolchain.&lt;/p&gt;
&lt;p&gt;The meant a bit of complexity, since we aren&amp;rsquo;t allowed to use most
things that would make this process easier but it also meant the final
extension was independent of the runtime API/ABI and was built on top
of &amp;ldquo;NoRuntime&amp;rdquo;.&lt;/p&gt;
&lt;h2 id=&#34;the-flaws-start-to-show-up&#34;&gt;The flaws start to show up&lt;/h2&gt;
&lt;p&gt;This entire setup worked quite well for a long time despite some
maintenance issues from Cisco. However there were some flaws.&lt;/p&gt;
&lt;p&gt;A while back I told that every vendor is forced to distribute binaries
hosted by Cisco at &lt;code&gt;https://ciscobinary.openh264.org&lt;/code&gt;. Unfortunately
&lt;code&gt;ciscobinary.openh264.org&lt;/code&gt; is missing a valid SSL certificate
&lt;a href=&#34;https://github.com/cisco/openh264/issues/909#issue-34658985&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;at least since 2014&lt;/a&gt;
and Cisco neither supplies GPG signatures nor strong checksums like
SHA-256 for the binary releases.&lt;/p&gt;
&lt;p&gt;This meant that we have no way to verify the authenticity of Cisco&amp;rsquo;s
binaries, opening us to various classes of MiTM and supply-chain
vulnerabilities. We reached out to Mozilla and via Fedora/RedHat to get
Cisco to fix this, as one can see the comments on the thread but
nothing ever happened.&lt;/p&gt;
&lt;p&gt;More recently (around 2024-2025), this SSL issue meant that the domain
started getting &lt;a href=&#34;https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/merge_requests/24521#note_2329956598&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;DNS blocked&lt;/a&gt;
and would make the extra-data download fail, botching an install.&lt;/p&gt;
&lt;p&gt;Another critical issue was that if upstream did security fixes and then
released them with an ABI break, we couldn&amp;rsquo;t fix it for the Flatpak
runtimes. Distributing binaries directly through extra-data meant there
is no scope for cherry-picking patches and the ABI break meant the new
version would only be able go to a new branch of the runtime.&lt;/p&gt;
&lt;p&gt;We didn&amp;rsquo;t really have a choice here. If we dropped this extension
considering the potential flaws, the entirety of the Flatpak user base
would loose H.264 decoding and encoding support, so we had to live with
the setup.&lt;/p&gt;
&lt;h2 id=&#34;the-start-of-the-codecs-extra-extension&#34;&gt;The start of the codecs-extra extension&lt;/h2&gt;
&lt;p&gt;Around June 2024 &lt;code&gt;gdk-pixbuf&lt;/code&gt; due to a series of security issues,
&lt;a href=&#34;https://discourse.gnome.org/t/change-in-the-gdk-pixbuf-loaders-built-by-default-in-2-42-11/21845&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;dropped support&lt;/a&gt;
for a lot of &amp;ldquo;fringe&amp;rdquo; loaders. We immediately noticed the change as
we constantly analyse ABI in stable branches.&lt;/p&gt;
&lt;p&gt;To compensate for the dropped loaders, we &lt;a href=&#34;https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/merge_requests/19916&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;decided&lt;/a&gt;
to add &lt;code&gt;webp, avif, jxl, heif&lt;/code&gt; support (with pixbuf loaders) to the
runtime. Around the same time, &lt;a href=&#34;https://gitlab.com/wjt&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;Will Thompson&lt;/a&gt;
opened an &lt;a href=&#34;https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/issues/1704&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;issue&lt;/a&gt;
to add &lt;code&gt;libheif&lt;/code&gt; to the runtime with the problematic HEIC decoder as a
runtime extension.&lt;/p&gt;
&lt;p&gt;Consequently, we decided that yet another extension just for two libheif
plugins is not worth the maintenance effort and these would rather be
in the &lt;code&gt;ffmpeg-full&lt;/code&gt; extension (This was the successor to the
&lt;code&gt;html5-codecs&lt;/code&gt; extension, created around 2019-2020). So I &lt;a href=&#34;https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/merge_requests/20268&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;again&lt;/a&gt;
&lt;a href=&#34;https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/merge_requests/19942&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;added&lt;/a&gt;
&lt;code&gt;libx265, libde265&lt;/code&gt; and the corresponding libheif plugins to the
ffmpeg-full extension. After a few months I also &lt;a href=&#34;https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/merge_requests/21970&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;added&lt;/a&gt;
&lt;code&gt;libx264&lt;/code&gt; to it too as we were already shipping &lt;code&gt;libx265&lt;/code&gt; and Cisco&amp;rsquo;s
OpenH264 had suboptimal encoding performance.&lt;/p&gt;
&lt;p&gt;I was happy with the result and all of this shipped in Freedesktop SDK
24.08. But some people were unhappy for valid reasons.&lt;/p&gt;
&lt;p&gt;When the &lt;code&gt;ffmpeg-full&lt;/code&gt; extension was created, due to various concerns
it was never added to the runtime or SDK manifest; it lived as an
optional &amp;ldquo;app&amp;rdquo; extension - meaning app developers would need to add a
&lt;a href=&#34;https://docs.flatpak.org/en/latest/extension.html#loading-existing-extensions&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;short snippet&lt;/a&gt;
in their Flatpak manifest to use it.&lt;/p&gt;
&lt;p&gt;This was problematic in some ways - sometimes app developers were
unaware of the extension or that they needed it and the app manifest
was missing the snippet that allowed to use the extension. This made
user and developer experience a bit poor. Once we started
shipping &lt;code&gt;libheif&lt;/code&gt; in &lt;code&gt;ffmpeg-full&lt;/code&gt;, it became slightly more
problematic as the actual libheif library was in the runtime but without
the extension it cannot decode any HEIF/HEIC image. So the extension
was practically mandatory. &lt;a href=&#34;https://github.com/tsdgeos&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;Albert Astals Cid&lt;/a&gt;,
part of the team who maintains KDE Flatpaks on Flathub complained about
this and an &lt;a href=&#34;https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/issues/1825&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;issue was opened by Erick555&lt;/a&gt;
to discuss the possibility of making ffmpeg-full a runtime extension.&lt;/p&gt;
&lt;p&gt;I was initially reluctant to do this for various reasons and the
situation was again a bit out of our hands (this time due to H.265
patents) but we asked various parties such as Endless and quite
surprisingly it turned out no one really had an objection to making it
a runtime extension or even make it auto-download along with the
runtime.&lt;/p&gt;
&lt;p&gt;Along with this change, we decided to rename the &lt;code&gt;ffmpeg-full&lt;/code&gt; extension
again, this time to &lt;code&gt;codecs-extra&lt;/code&gt; to better reflect the fact that it
will not only contain FFMPEG with patented parts but other libraries
too that deals with patented codecs. This would sort of be an equivalent
to the various &amp;ldquo;meta-packages&amp;rdquo; that distros provide for patented or
restricted codecs.&lt;/p&gt;
&lt;p&gt;Thus the seeds were planted and I switched &lt;code&gt;ffmpeg-full&lt;/code&gt; to
&lt;code&gt;codecs-extra&lt;/code&gt; a &lt;a href=&#34;https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/merge_requests/24620&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;month ago&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;This is supposed to ship in Freedesktop SDK 25.08. The major change for
app developers is that there is no longer any need to have something
like&lt;/p&gt;
&lt;div class=&#34;highlight&#34;&gt;&lt;pre tabindex=&#34;0&#34; class=&#34;chroma&#34;&gt;&lt;code class=&#34;language-yaml&#34; data-lang=&#34;yaml&#34;&gt;&lt;span class=&#34;line&#34;&gt;&lt;span class=&#34;cl&#34;&gt;&lt;span class=&#34;nt&#34;&gt;add-extensions&lt;/span&gt;&lt;span class=&#34;p&#34;&gt;:&lt;/span&gt;&lt;span class=&#34;w&#34;&gt;
&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;&lt;span class=&#34;line&#34;&gt;&lt;span class=&#34;cl&#34;&gt;&lt;span class=&#34;w&#34;&gt;  &lt;/span&gt;&lt;span class=&#34;nt&#34;&gt;org.freedesktop.Platform.ffmpeg-full&lt;/span&gt;&lt;span class=&#34;p&#34;&gt;:&lt;/span&gt;&lt;span class=&#34;w&#34;&gt;
&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;&lt;span class=&#34;line&#34;&gt;&lt;span class=&#34;cl&#34;&gt;&lt;span class=&#34;w&#34;&gt;    &lt;/span&gt;&lt;span class=&#34;nt&#34;&gt;version&lt;/span&gt;&lt;span class=&#34;p&#34;&gt;:&lt;/span&gt;&lt;span class=&#34;w&#34;&gt; &lt;/span&gt;&lt;span class=&#34;s1&#34;&gt;&amp;#39;24.08&amp;#39;&lt;/span&gt;&lt;span class=&#34;w&#34;&gt;
&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;&lt;span class=&#34;line&#34;&gt;&lt;span class=&#34;cl&#34;&gt;&lt;span class=&#34;w&#34;&gt;    &lt;/span&gt;&lt;span class=&#34;nt&#34;&gt;directory&lt;/span&gt;&lt;span class=&#34;p&#34;&gt;:&lt;/span&gt;&lt;span class=&#34;w&#34;&gt; &lt;/span&gt;&lt;span class=&#34;l&#34;&gt;lib/ffmpeg&lt;/span&gt;&lt;span class=&#34;w&#34;&gt;
&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;&lt;span class=&#34;line&#34;&gt;&lt;span class=&#34;cl&#34;&gt;&lt;span class=&#34;w&#34;&gt;    &lt;/span&gt;&lt;span class=&#34;nt&#34;&gt;add-ld-path&lt;/span&gt;&lt;span class=&#34;p&#34;&gt;:&lt;/span&gt;&lt;span class=&#34;w&#34;&gt; &lt;/span&gt;&lt;span class=&#34;l&#34;&gt;.&lt;/span&gt;&lt;span class=&#34;w&#34;&gt;
&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;p&gt;in the manifest. &lt;code&gt;org.freedesktop.Platform.codecs-extra&lt;/code&gt; will be
automatically installed by the runtime and will be available to users.&lt;/p&gt;
&lt;h2 id=&#34;dropping-the-openh264-extension&#34;&gt;Dropping the openh264 extension&lt;/h2&gt;
&lt;p&gt;The above &lt;code&gt;codecs-extra&lt;/code&gt; change meant that we now didn&amp;rsquo;t really have an
use case for &lt;code&gt;org.freedesktop.Platform.openh264&lt;/code&gt; since &lt;code&gt;codecs-extra&lt;/code&gt;
had FFMPEG&amp;rsquo;s internal H.264 decoder and the &lt;code&gt;libx264&lt;/code&gt; encoder.&lt;/p&gt;
&lt;p&gt;So I initially disabled autodownload and considering the various &amp;ldquo;flaws&amp;rdquo;
with OpenH264 discussed above, I &lt;a href=&#34;https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/issues/1834&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;opened an issue&lt;/a&gt;
for planned retirement in 26.08.&lt;/p&gt;
&lt;p&gt;This was completely overturned when a &lt;a href=&#34;https://github.com/cisco/openh264/security/advisories/GHSA-m99q-5j7x-7m9x&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;high severity flaw&lt;/a&gt;
was discovered in libopenh264 affecting versions 2.5.0 and earlier.&lt;/p&gt;
&lt;p&gt;The 23.08 branch of the Freedesktop runtime was locked to 2.2.0 and
upgrading to a fixed version was not possible due to multiple ABI breaks
and SONAME bumps upstream. Patching was also not an option as I said
earlier.&lt;/p&gt;
&lt;p&gt;We scrambled to mitigate this. For 23.08, we decided to make an
&amp;ldquo;ABI break&amp;rdquo; and &lt;a href=&#34;https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/issues/1846&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;drop the extension&lt;/a&gt;
as updating was impossible. So I made a bit of an intimidating &lt;a href=&#34;https://discourse.flathub.org/t/upcoming-freedesktop-23-08-runtime-release-will-drop-openh264-extension/9022&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;announcement&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;But we still had 24.08 left which was on 2.4.1 and updating to the fixed
version i.e. 2.6.0 was again blocked due to an ABI bump.&lt;/p&gt;
&lt;p&gt;However, looking through the commits between 2.4.1 and 2.6.0 and
analysing the library through libabigail we couldn&amp;rsquo;t find an actual
ABI break that was made and considering Cisco in the past made
unnecessary SONAME bumps, we tried patching the 2.6.0 release to
provide the older ABI.&lt;/p&gt;
&lt;p&gt;I &lt;a href=&#34;https://gitlab.com/freedesktop-sdk/openh264-extension/-/merge_requests/68&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;messed&lt;/a&gt;
with that venerable apply_extra and wrote a small utility to patch
SONAMEs. But upstream, in time, pointed us to the ABI break
and this idea had to be scrapped entirely. (I later found out why
liabigail was unable to show the ABI break after talking to Dodji
Seketeli, the libabigail maintainer.)&lt;/p&gt;
&lt;p&gt;We then &lt;a href=&#34;https://github.com/cisco/openh264/issues/3863&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;asked upstream&lt;/a&gt;
to provide a patch release 2.5.1 instead with the old ABI and to our
surprise they did within a few weeks! This shipped in 24.08.15 fixing
the 24.08 branch of the runtime.&lt;/p&gt;
&lt;p&gt;After all this debacle and the extra &amp;ldquo;headache&amp;rdquo;, none of us felt
comfortable shipping the openH264 extension anymore. Thus it was
&lt;a href=&#34;https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/merge_requests/24871&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;dropped&lt;/a&gt;
for the master branch, which means there won&amp;rsquo;t be any
&lt;code&gt;org.freedesktop.Platform.openh264&lt;/code&gt; extension or &lt;code&gt;noopenh264&lt;/code&gt; for 25.08+.&lt;/p&gt;
&lt;h2 id=&#34;epilogue&#34;&gt;Epilogue&lt;/h2&gt;
&lt;p&gt;Considering all things, I think and hope we made the correct decision
and hopefully the new &lt;code&gt;org.freedesktop.Platform.codecs-extra&lt;/code&gt; works
out. &lt;code&gt;libx264, libx265&lt;/code&gt; and others are built from source and there
are no binaries or extra-data involved. So we should theoretically be
able to patch and fix any issues that come up in the future.&lt;/p&gt;
&lt;p&gt;Apart from all this, I&amp;rsquo;m slightly worried at the prospects of legal
issues cropping up with this setup and also that the new extension
contains &amp;ldquo;too much&amp;rdquo;, but we will have to see where things flow.&lt;/p&gt;
&lt;p&gt;As a fun tidbit, I wasn&amp;rsquo;t aware that Fedora was also using our
&lt;code&gt;org.freedesktop.Platform.openh264&lt;/code&gt; extension. I caused a bit of work
for them as noopenh264 &lt;a href=&#34;https://gitlab.com/freedesktop-sdk/noopenh264/-/commit/2177b9cb3542d0c9ccba4d20e56516118f8e747d&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;moved home&lt;/a&gt;
once again, now to Fedora and they are looking for ways to make their
own OpenH264 extension similar to how we did.&lt;/p&gt;
&lt;p&gt;I hope the experience here helps anyone in the future wanting to maintain
such an extension and this will also serve as a reminder to how much
extra work patents like these causes.&lt;/p&gt;
&lt;p&gt;Lastly I&amp;rsquo;d like to thank Endless for giving us not only noopenh264 but
also extra-data support in Flatpak that made all this possible;
&lt;a href=&#34;https://gitlab.com/TheRealMichaelCatanzaro&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;Michael Catanzaro&lt;/a&gt; and &lt;a href=&#34;https://gitlab.com/nanonyme&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;Seppo Yli-Olli&lt;/a&gt;
for maintaining this setup for a long time; &lt;a href=&#34;https://gitlab.com/valentindavid&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;Valentin David&lt;/a&gt;
for helping me in the last few days and everyone else who worked on
this ❤️&lt;/p&gt;</description>
    </item>
    
    <item>
      <title>Hello, World</title>
      <link>https://bbhtt.in/posts/hello-world/</link>
      <pubDate>Fri, 05 Apr 2024 09:32:40 +0530</pubDate>
      
      <guid>https://bbhtt.in/posts/hello-world/</guid>
      <description>&lt;p align=&#34;center&#34;&gt;
  &lt;img src=&#34;./cat.png&#34; alt=&#34;A cat standing on two legs with one hand on a bed and the other one stretched in the opposite direction - in a stuck position&#34; /&gt;
&lt;/p&gt;
</description>
    </item>
    
    <item>
      <title>About</title>
      <link>https://bbhtt.in/about/</link>
      <pubDate>Fri, 07 Jul 2023 12:44:33 +0530</pubDate>
      
      <guid>https://bbhtt.in/about/</guid>
      <description>&lt;blockquote&gt;
&lt;p&gt;&lt;em&gt;I’m Nobody! Who are you? Are you – Nobody – too? Then there’s a pair of us!&lt;/em&gt; ~ Emily Dickinson&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;Hello and welcome to my little corner of the internet!&lt;/p&gt;
&lt;p&gt;You might know me by my online alias, &lt;em&gt;bbhtt&lt;/em&gt;, which is just a blend of
some letters of my real name, Boudhayan Bhattcharya. I live in India and
completed my B.Sc. (Honours) in 2021 and M.Sc. in Mathematics in 2023.
Currently, I&amp;rsquo;m pursuing a Ph.D. in Mathematics. I teach Mathematics
for work and occasionally contribute to &lt;a href=&#34;https://en.wikipedia.org/wiki/Free_and_open-source_software&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;FOSS projects&lt;/a&gt;
during my free time.&lt;/p&gt;
&lt;p&gt;I love watching &lt;a href=&#34;https://letterboxd.com/bbhtt/films/&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;movies&lt;/a&gt;,
TV shows, and &lt;a href=&#34;https://anidb.net/user/983003&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;anime&lt;/a&gt;, and I&amp;rsquo;m always
listening to &lt;a href=&#34;https://open.spotify.com/user/m18qz71984e1gjbkfbd36zwmi&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;music&lt;/a&gt;.
Although, most of the time, I&amp;rsquo;m lost in some random YouTube binge.&lt;/p&gt;
&lt;p&gt;I also try to read books and play some games on &lt;a href=&#34;https://steamcommunity.com/id/bbhtt/&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;Steam&lt;/a&gt;
every now and then, and sometimes I mess around with casual online chess
on Lichess.&lt;/p&gt;
&lt;p&gt;You can contact me via:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;Email: &lt;a href=&#34;mailto:bbhtt@bbhtt.in&#34;&gt;bbhtt@bbhtt.in&lt;/a&gt;. My GPG key
is &lt;a href=&#34;./bbhtt.pub&#34;&gt;D26D 7533 9500 9DB2 B3B2 6094 0C32 51A2 4745 E484&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href=&#34;https://matrix.org/&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;[matrix]&lt;/a&gt;: &lt;a href=&#34;https://matrix.to/#/@bbhtt:matrix.org&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;@bbhtt:matrix.org&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;IRC: bbhtt on &lt;a href=&#34;ircs://irc.libera.chat/bbhtt,isuser&#34;&gt;Libera.chat&lt;/a&gt;, &lt;a href=&#34;ircs://irc.oftc.net/bbhtt,isuser&#34;&gt;OFTC&lt;/a&gt;&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;Unless otherwise stated, all textual content here is licensed under
&lt;a href=&#34;https://creativecommons.org/licenses/by-nc-sa/4.0/&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;CC BY-NC-SA 4.0&lt;/a&gt;.&lt;/p&gt;
</description>
    </item>
    
  </channel>
</rss>