|
|
Subscribe / Log in / New account

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.



to post comments

The world beyond OpenH264

Posted Mar 25, 2025 21:06 UTC (Tue) by mat2 (guest, #100235) [Link] (18 responses)

Will it be possible to disable a download of this codecs-extra extension? Or perhaps just substitute it for a package without the patent-encumbered codecs? For ethical and legal reasons, I try to avoid using patented but unlicensed / improperly licensed code.

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.)

The world beyond OpenH264

Posted Mar 25, 2025 21:59 UTC (Tue) by intelfx (subscriber, #130118) [Link] (7 responses)

> 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.

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.

The world beyond OpenH264

Posted Mar 26, 2025 11:36 UTC (Wed) by abo (subscriber, #77288) [Link] (1 responses)

Fluendo already does this (selling codecs which integrate with gstreamer and ffmpeg, under agreement with various patent holders).

The world beyond OpenH264

Posted Mar 26, 2025 21:24 UTC (Wed) by mat2 (guest, #100235) [Link]

It appears that no longer - or at least I cannot find on their webpage any references to where I can buy their Oneplay Codec Pack.

The world beyond OpenH264

Posted Mar 26, 2025 21:11 UTC (Wed) by mat2 (guest, #100235) [Link] (4 responses)

> Why not have this hypothetical entity sell patent licenses for FFmpeg?

Because FFmpeg is licensed under GPL / LGPL, which effectively prohibits such licensing (or at least makes it problematic).

The world beyond OpenH264

Posted Mar 26, 2025 23:20 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]

GPLv2 doesn't prohibit a third-party from selling licenses. Microsoft had been doing that with Linux-related patents for a while.

Essentially, you can sell a piece of paper telling that the patent holders won't sue you if you are using ffmpeg.

The world beyond OpenH264

Posted Mar 27, 2025 4:38 UTC (Thu) by intelfx (subscriber, #130118) [Link] (2 responses)

> Because FFmpeg is licensed under GPL / LGPL, which effectively prohibits such licensing (or at least makes it problematic).

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.

The world beyond OpenH264

Posted Mar 27, 2025 8:13 UTC (Thu) by Wol (subscriber, #4433) [Link] (1 responses)

> that would prohibit selling *patent* licenses

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,
Wol

Patent pool trickery

Posted Mar 27, 2025 9:47 UTC (Thu) by farnz (subscriber, #17727) [Link]

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.

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).

The world beyond OpenH264

Posted Mar 25, 2025 22:30 UTC (Tue) by wjt (subscriber, #56250) [Link]

> Will it be possible to disable a download of this codecs-extra extension?

Yes, use `flatpak mask`: https://www.man7.org/linux/man-pages/man1/flatpak-mask.1....

The world beyond OpenH264

Posted Mar 26, 2025 13:42 UTC (Wed) by dowdle (subscriber, #659) [Link]

I'd love to have a total for the number of users who don't want to download the codecs... so I can download them extra times to make up for it. :)

The world beyond OpenH264

Posted Mar 26, 2025 14:19 UTC (Wed) by mcatanzaro (subscriber, #93033) [Link] (7 responses)

> The OpenH264 codec supports only a Constrained Baseline Profile of H.264, not the Main or High profiles of it

This is wrong.

The world beyond OpenH264

Posted Mar 26, 2025 14:46 UTC (Wed) by farnz (subscriber, #17727) [Link] (6 responses)

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

Posted Mar 26, 2025 15:15 UTC (Wed) by mcatanzaro (subscriber, #93033) [Link] (4 responses)

The official Cisco OpenH264 GitHub README is wrong. I guess nobody updated the README when support for higher profiles was added.

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.)

The world beyond OpenH264

Posted Mar 26, 2025 15:46 UTC (Wed) by farnz (subscriber, #17727) [Link] (1 responses)

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.

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.

The world beyond OpenH264

Posted Mar 27, 2025 0:26 UTC (Thu) by numgmt (guest, #167446) [Link]

Thank you for this explanation! I now finally know why the support for decoding High Profile video is so spotty.

The world beyond OpenH264

Posted Mar 27, 2025 0:21 UTC (Thu) by numgmt (guest, #167446) [Link] (1 responses)

The web uses High Profile video. But OpenH264 doesn't fully support all High profile video. For instance, it doesn't support High 10. There are a number of High profile videos I have available locally that I can't play.

So it has some support for High Profile, but it's incomplete. Enough for web.

Profile names in H.264

Posted Mar 27, 2025 9:34 UTC (Thu) by farnz (subscriber, #17727) [Link]

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.

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.

The world beyond OpenH264

Posted Mar 31, 2025 13:50 UTC (Mon) by fabiop (guest, #24661) [Link]

Other than other replies here, note there is this PR for OpenH264 project: https://github.com/cisco/openh264/pull/3656
It never got any response in a couple years.

What is the next best codec to move to?

Posted Mar 31, 2025 15:20 UTC (Mon) by ber (subscriber, #2142) [Link] (2 responses)

While patented and proprietary video formats provide complications, what is the best container/codec that we as Free Software community shall migrate to?

WebM with V9 and Opus?

What is the next best codec to move to?

Posted Mar 31, 2025 16:18 UTC (Mon) by intelfx (subscriber, #130118) [Link] (1 responses)

VP9 in the "we have H.265 at home" weight category. Otherwise, AV1 in the "better than H.265, but at the cost of severe air boiling" weight category.

What is the next best codec to move to?

Posted Apr 1, 2025 10:46 UTC (Tue) by mathstuf (subscriber, #69389) [Link]

And I assume the preferred container is still Matroska (even with its warts)?


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds