Bhattcharya: Closing the chapter on OpenH264
Boudhayan Bhattcharya has posted a lengthy article about the announcement that the Freedesktop project is dropping OpenH264 from the Freedesktop SDK for Flatpak applications and runtimes.
Some Flatpak applications that depend on the Freedesktop runtime version 23.08 will lose H.264 playback support starting with the release scheduled for April, unless application developers replace it with the ffmpeg-full extension. The 24.08 runtime is unaffected, and future releases will include a new codecs-extra extension to replace OpenH264 that includes FFmpeg with support for a number of patented codecs.
Considering all things, I think and hope we made the correct decision and hopefully the new org.freedesktop.Platform.codecs-extra works out. libx264, libx265 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.
Apart from all this, I'm slightly worried at the prospects of legal issues cropping up with this setup and also that the new extension contains "too much", but we will have to see where things flow.
Posted Mar 25, 2025 21:06 UTC (Tue)
by mat2 (guest, #100235)
[Link] (18 responses)
The OpenH264 codec supports only a Constrained Baseline Profile of H.264, not the Main or High profiles of it, so it will be unable to play much video found today. On the other hand, the codecs in Android are permissively licensed, stable and apparently also support the Main and High profiles of H.264 (at least from grepping the source code of libavc), as well as AAC, H.265, etc. It should be possible to use them, properly license and sell for something like $5 apiece for those who cannot / don't want to use ffmpeg / etc. (I know about Fluendo, but they only ship GStreamer codecs and it doesn't work with Firefox etc.)
Posted Mar 25, 2025 21:59 UTC (Tue)
by intelfx (subscriber, #130118)
[Link] (7 responses)
So if you want to open the can of worms of "properly licensing and selling for something like $5 apiece" the codecs (deliberately omitting the question of whether there actually is an entity willing to set up and handle such sales), then why do you need "the codecs in Android" at all? Why not have this hypothetical entity sell patent licenses for FFmpeg?
Or are you objecting to usage of FFmpeg itself, *regardless* of whether someone sells you patent licenses for all relevant codecs? If so, then I would be extremely interested in the reasons for such objection.
Posted Mar 26, 2025 11:36 UTC (Wed)
by abo (subscriber, #77288)
[Link] (1 responses)
Posted Mar 26, 2025 21:24 UTC (Wed)
by mat2 (guest, #100235)
[Link]
Posted Mar 26, 2025 21:11 UTC (Wed)
by mat2 (guest, #100235)
[Link] (4 responses)
Because FFmpeg is licensed under GPL / LGPL, which effectively prohibits such licensing (or at least makes it problematic).
Posted Mar 26, 2025 23:20 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Essentially, you can sell a piece of paper telling that the patent holders won't sue you if you are using ffmpeg.
Posted Mar 27, 2025 4:38 UTC (Thu)
by intelfx (subscriber, #130118)
[Link] (2 responses)
As the sibling comment says, I'm not aware of anything in either GPL or LGPL that would prohibit selling *patent* licenses (for a given $binary, or any binary built from unmodified $source, or any other variation on that theme). Patents and copyrights are orthogonal.
Posted Mar 27, 2025 8:13 UTC (Thu)
by Wol (subscriber, #4433)
[Link] (1 responses)
It is there, though ... *for*patents*and*licences*you*own*. You are explicitly required to pass on any necessary licences you own, under the terms of the GPL, and that obviously includes patent licences.
But if you don't have such licences, you are neither able nor obligated to pass them on.
Not sure how this would impact your ability to share codec-playing software if you bought one of these licences, though.
Cheers,
Posted Mar 27, 2025 9:47 UTC (Thu)
by farnz (subscriber, #17727)
[Link]
Their primary reason to exist is to work around all the ways in which people might end up with a patent licence without paying for it - and one of the things they are quite legally able to do is to say that you have to prove that (say) Microsoft has a valid patent licence that it sublicensed to you under the GPL terms when it distributed a GPL'd codec. After all, if Microsoft doesn't have a licence itself, it can't pass it on to you - and Microsoft is not obliged to detail what patent licences it does, or does not, hold, merely to confirm that it's passed on all licences that it holds.
This means that relying on the terms of the GPL ends up with you being on the sharp end of an expensive lawsuit, since you need to pursue your upstream for discovery to show that they have licences they can pass onto you - and that not only gets pricy, but also runs the risk of exposing your upstream to further legal action (if they did not, in fact, have licences they could pass onto you).
Posted Mar 25, 2025 22:30 UTC (Tue)
by wjt (subscriber, #56250)
[Link]
Yes, use `flatpak mask`: https://www.man7.org/linux/man-pages/man1/flatpak-mask.1....
Posted Mar 26, 2025 13:42 UTC (Wed)
by dowdle (subscriber, #659)
[Link]
Posted Mar 26, 2025 14:19 UTC (Wed)
by mcatanzaro (subscriber, #93033)
[Link] (7 responses)
This is wrong.
Posted Mar 26, 2025 14:46 UTC (Wed)
by farnz (subscriber, #17727)
[Link] (6 responses)
Posted Mar 26, 2025 15:15 UTC (Wed)
by mcatanzaro (subscriber, #93033)
[Link] (4 responses)
If I uninstall OpenH264, I can't play videos in my web browser anymore except on websites that do not require H.264, like YouTube. With it installed, I can play video on almost every website. I understand web videos generally use high profile? (I'm not actually familiar with this terminology, but it was a big deal when OpenH264 started to support web videos several years ago; originally, it only supported WebRTC and was otherwise not useful.)
Posted Mar 26, 2025 15:46 UTC (Wed)
by farnz (subscriber, #17727)
[Link] (1 responses)
As best I can tell from a cursory code inspection, the README is correct in as far as it goes; it only fully supports CBP, but doesn't bail out on the wrong profile marker in the bitstream (allowing you to at least attempt to decode potentially unsupported profiles), and supports a subset of Main and High Profiles. Note that just because you flagged your video as Main profile doesn't mean it's actually using all the features of Main Profile; it's permissible for a video flagged as High profile to use only CBP features, for example.
What I'm seeing is signs that someone's added support for B slices, CABAC encoding, and some (but not all) of the options around quantization matrixes present in High profile. As a result, it doesn't support Main or High profiles, but it does support the output of some encoders.
For background, the profiles tell you what bitstream components the decoder can handle (or the encoder can use); the levels tell you how many macroblocks/second, macroblocks/frame and bits/second your decoder needs to handle to keep up, and how big the decoded picture buffer is. If you're claiming support for a profile in a decoder, you're claiming that you can decode all of the bitstream elements that that profile permits, but (for example), I'm not spotting code to handle separate quantization parameters for Cb and Cr planes, which is required for High profile, but not used by common encoders.
Posted Mar 27, 2025 0:26 UTC (Thu)
by numgmt (guest, #167446)
[Link]
Posted Mar 27, 2025 0:21 UTC (Thu)
by numgmt (guest, #167446)
[Link] (1 responses)
So it has some support for High Profile, but it's incomplete. Enough for web.
Posted Mar 27, 2025 9:34 UTC (Thu)
by farnz (subscriber, #17727)
[Link]
And remember that the decoder's behaviour is fully specified by the standard; a High 10 Profile bitstream can assume that if a 9 bpc picture is in the set of reference pictures, it's in there at 9 bpc, and thus pictures that reference the 9 bpc picture will be doing their differences against the 9 bpc reference, not that reference truncated to 8 bpc. And since H.264 allows for reference pictures to themselves be reconstructed from previous reference pictures, the error can accumulate quite quickly, going from "off by the LSB" to "reduced to 4 bpc of data plus 4 bpc of noise" if you use an 8 bpc truncated reference.
Posted Mar 31, 2025 13:50 UTC (Mon)
by fabiop (guest, #24661)
[Link]
Posted Mar 31, 2025 15:20 UTC (Mon)
by ber (subscriber, #2142)
[Link] (2 responses)
WebM with V9 and Opus?
Posted Mar 31, 2025 16:18 UTC (Mon)
by intelfx (subscriber, #130118)
[Link] (1 responses)
Posted Apr 1, 2025 10:46 UTC (Tue)
by mathstuf (subscriber, #69389)
[Link]
The world beyond OpenH264
The world beyond OpenH264
The world beyond OpenH264
The world beyond OpenH264
The world beyond OpenH264
The world beyond OpenH264
The world beyond OpenH264
The world beyond OpenH264
Wol
Note that this sort of thing is one of the reasons behind patent pools for codecs; that creates a non-practising entity which has the right to sublicense all of the patents it licenses, but does not itself sell another other than patent licences.
Patent pool trickery
The world beyond OpenH264
The world beyond OpenH264
The world beyond OpenH264
In what way is it wrong? The official Cisco OpenH264 GitHub says that it only supports "Constrained Baseline Profile" up to "Level 5.2", and not Baseline, Main, Extended or High profiles.
The world beyond OpenH264
The world beyond OpenH264
This gets complicated, and you'd need to actually test with a conformance suite to find out what it actually supports, or do a detailed dive into the code.
The world beyond OpenH264
The world beyond OpenH264
The world beyond OpenH264
Confusingly, High Profile and High 10 Profile are separate profiles. You can fully support High Profile, and have no support for High 10 Profile; the difference between High Profile and High 10 Profile is simply that High Profile only supports 8 bpc, while High 10 Profile supports 8, 9 and 10 bpc.
Profile names in H.264
The world beyond OpenH264
It never got any response in a couple years.
What is the next best codec to move to?
What is the next best codec to move to?
What is the next best codec to move to?