[Android] Feature request: add openH264 cross-compile support

[foobra]

Does mobile-ffmpeg direct support openH264 cross-compile? If not , could you please support it ? thanks

[tanersener]

OpenH264 is not one of the libraries that mobile-ffmpeg supports and there are several reasons for that. The most important one is MPEG LA licensing fees. As explained in the OpenH264 FAQ page when you use source code then you have to pay for MPEG LA licensing fees.

... a team can choose to use the source code, in which case the team is responsible for paying all applicable license fees ...

It's not clear whether mobile-ffmpeg library owner or application owner has to pay. So, I don't want create a legal issue for me by supporting OpenH264.

[tanersener]

I can certainly say that I won't publish a binary with OpenH264 in it due to reasons I explained above but I may include instructions to build mobile-ffmpeg with OpenH264. I'm still evaluating the idea.

[tanersener]

I just added openh264 support to the development branch. You can build mobile-ffmpeg with openh264 but mobile-ffmpeg will not publish a binary with openh264 inside due to the reasons I explained above. Please remember that if you build mobile-ffmpeg with openh264 and distribute that library, then you are subject to pay MPEG LA licensing fees.

[alexcohn]

You refrain from bundling openh264, but are the licensing restrictions for libx264 any better?

[tanersener]

Is it a question or a complaint? How about expressing your opinion directly?

[alexcohn]

It's a question; I did not study the cumbersome details of MPEG LA restrictions for h264. From the little I read, I saw nothing that would make distribution of libx264 different from openh264. On the other hand, I think it's natural that Cisco uses more careful language than Videolan.

[tanersener]

I read the details of openh264 license and learned that if I publish openh264 binaries that I have compiled, I have to pay for MPEG LA licensing fees. So, I decided not to publish a mobile-ffmpeg binary with openh264 inside.

x264 is licensed under GPL. When I look at its license I don't see any clear terms about royalty fees. That's why I don't see any problems publishing mobile-ffmpeg binaries with x264 inside. If there is a condition that I'm missing in x264 license which requires me to pay similar royalty fees then I'll stop publishing x264 too.

[alexcohn]

I am not a lawyer, so please take my conclusions with a grain of salt. But I tried to read more about the MPEG LA licensing, and this is what I have found:

The fact that neither of us finds any mention of MPEG LA licensing in x264 documentation does not mean that they don't apply. A detailed answer circa 2015 sums up that use of h264 binaries from either source may be problematic if these binaries come from a server which is under the US jurisdiction (GitHub is). The official binaries from https://artifacts.videolan.org/x264 are not hosted in the US (unfortunately, they don't include iOS or Android). The official binaries from https://github.com/cisco/openh264/releases/tag/v2.1.1 are covered by Cisco. That's why, to cover their $ss, they add the clause in their FAQ to explain what uses they don't cover: any other way to distribute the binaries that encode and/or decode H.264.

The MPEG LA license terms for codec manufacture (which may be interpreted to include binary distribution, and Cisco seems to have accepted this interpretation, or at least, its consequences) are listed on page 10 of https://www.mpegla.com/wp-content/uploads/avcweb.pdf:

Products sold to end users and OEM for PC but not part of OS (decoder, encoder or product consisting of one decoder and one encoder = “unit”)

• 0 - 100,000 units/year = no royalty (available to one legal entity in an affiliated group)
• US $0.20 per unit after first 100,000 units/year
• Above 5 million units/year, royalty = US $0.10 per unit
• Enterprise cap: $3.5M per year 2005-2006, $4.25M per year 2007-08, $5M per year 2009-10, $6.5Mper year 2011-2015; $8.125M in 2016 and $9.75M per year in 2017 through 2020

Enterprise selling branded OEM for PC OS ommitted for brevity, because they definitely don't apply to mobile-ffmpeg.

• Includes right to manufacture and sell AVC encoders and decoders with the right of End Users to use them for personal and consumer (including internal business) purposes without remuneration but not for other uses.

I must confess that I don't understand the meaning of the last paragraph, but it definitely applies equally to openh264 and libx264.

By the way, similar rules apply to HEVC (a.k.a. H.265). The fact that libx264 and libx265 are GPL, does not matter for MPEG LA licensing. The question is whether the application that uses mobile-ffmeg, can be interpreted as selling the H.264 video.

TL;NR: there seems to be no justification to apply diferent policies to distribution of libx264 and openh264 binaries. It may be possible to have these binaries downloaded from the official sites, then MPEG LA licensing is not your problem. You can let the users download and build these libraries themselves, and again MPEG LA licensing is not your problem. Or, you can ignore the licensing problem altogether.

[tanersener]

Well, it looks like the wiki pages about licenses and commercial application usage have to be updated. But not sure about the details. There are still a few big questions unanswered.

The main question is where does mobile-ffmpeg stand in this picture. mobile-ffmpeg is a library and distributed binaries are not standalone applications. By providing the binaries, am I responsible of paying the patent fees?

Firefox is downloading openh264 binaries from Cisco and escape from paying patent fees. Those openh264 binaries are similar to mobile-ffmpeg binaries. They are just libraries, not standalone applications. This means that mobile-ffmpeg might be responsible of paying those fees.

I want to have a clear answer about this before deciding about supporting/dropping a feature.

[alexcohn]

I fully agree that the clarity is very important here, but unfortunately I have no idea how such licensing law guidance can be obtained (without paying big money). For example, to what extent the paragraph about the right of End Users to use them for personal and consumer (including internal business) purposes without remuneration is applicable to mobile-ffmpeg? – I don't know.

The language of the MPEG LA license does not make distinction between standalone applications and libraries. They do have separate clause for products that are part of the OS, but this is not relevant for mobile-ffmpeg.

The case of Firefox is definitely remarkable: they go into the pain of downloading the binaries from Cisco to be on the safe side. Unfortunately, mobile-ffmpeg cannot follow the same path: neither Android nor iOS support such download directly to end-user's device.

[tanersener]

Tried to find similar use cases on the web, where there is a library like mobile-ffmpeg which can't be directly installed to an end-user device. Found these two discussions/messages.

https://mailman.videolan.org/pipermail/x264-devel/2010-July/007508.html
https://software.intel.com/en-us/forums/media/topic/494720

In both of these links, library maintainers say that app developer is responsible of paying the patent fees. That x264 post is a pretty interesting one. x264 developer there clearly says that if Company A uses Company B's encoder in their product, Company A must pay the fees, not Company B. mobile-ffmpeg is Company B in that example.

For example, to what extent the paragraph about the right of End Users to use them for personal and consumer (including internal business) purposes without remuneration is applicable to mobile-ffmpeg? – I don't know.

I noticed that MPEG LA uses the term Products sold to end users and OEM for PC but not part of OS and I don't think mobile-ffmpeg falls into that category. End-users can't buy/install/use mobile-ffmpeg without an application. This puts mobile-ffmpeg into a different position compared to ffmpeg. In ffmpeg, there is actually a binary which can be installed and run in an End-user device.

Moreover, on mobile platforms, official applications are distributed using app stores (App Store, Google Play, Galaxy Store, etc). Installing applications manually is also supported on Android. But there has to be a website which distributes the .apk. End-user applications are downloaded from these two sources: application stores and websites. So, they're actually distributing applications and they know number of units referred in MPEG LA license terms.

Also, I can't think of a scenario where an Android/iOS application installed on an End-user device can download mobile-ffmpeg binaries directly from github/bintray and run them inside the application. As you've said, this is not possible at the moment. For me this means that: Technically mobile-ffmpeg can't distribute binaries to an end-user.

So, I believe mobile-ffmpeg looks safe in terms of MPEG LA fees.

[alexcohn]

Now I read more about the GPL libraries, e.g. kvazaar, and I believe that binary distribution of these is even more risky than more flexible licenses (e.g. openh264). As commenter jwr put it, the GPL license is a tool to fight the freedom battle.

[alexcohn]

Practically speaking, the chances of MPEG LA suing you for infringement of their license are extremely low. They have very little incentive to waste the time of their lawyers trying to shut your library down. In the worst case, while it's possible to force GitHub to delete the library, it's much harder to hold personally you responsible for anything.

[tanersener]

There are too many license details to deal with. GPL v2 can be a problem as stated inside that kvazaar discussion. I need to check and validate again that each external library license is compatible with each other and also with FFmpeg. I'm building FFmpeg using --enable-version3 which means it is licensed under (L)GPL v3. But does this effect x264 and kvazaar licenses as well? They are under (L)GPL v2.x and I know that v2 and v3 are not compatible with each other. Also how can kvazaar distribute binaries in github without any legal problems? There are still too many questions unanswered.

Honestly, I don't want to interpret licenses. I don't have enough knowledge about them. I think stopping distributing binaries is the safest option here.

[alexcohn]

Honestly, I don't want to interpret licenses. I don't have enough knowledge about them. I think stopping distributing binaries is the safest option here.

Absolutely. No binaries, no problem. Unfortunately, this applies not only to openh264, but also to kvazaar and x26x.

[tanersener]

Well, I'm considering stopping distributing all packages. FFmpeg itself is also bound to both (L)GPL and MPEG LA. The difference is the version. I'm using it using (L)GPL v3.0 which is more patent friendly according to the web. But they look the same to me and I don't understand the difference.

Unfortunately, this will kill my other projects: flutter_ffmpeg and react-native-ffmpeg.

[febg11]

@tanersener Do you have plans to completely remove flutter ffmpeg from the pub Dev site? I was going to try switch to using openh264 for my android compression but will try going a native java route if you are planning to remove it in the near future.

Your libraries are been really useful but I understand the risk you are exposing yourself to and can see why you would close the projects.

If you could let me know your plans I would be grateful.

[tanersener]

mobile-ffmpeg binaries are published in jcenter() and github right now. I'm not %100 sure but I believe it is against their policies. And I guess they can stop hosting those binaries if they receive a complaint about them.

So, I'm trying to find alternative ways of distributing the binaries to protect all three projects. This is the current situation.