As an engineer working with video encoder/decoder everyday, I sometimes have a customer or a friend asking how much license fee they would need to pay for using H.264. They are not seeking legal advice from me fortunately, but I feel embarrassed to not have a confident answer.
The tricky part is that the scope of H.264 usage is so wide that there are countless different business models in different domains of the tech industry. Everyone may have a unique situation and the answer for each of them could be very different.
So today I decide to write a comprehensive yet easy to understand explanation in the most concise way so that one can internalize the fundamental ideas.
In a nutshell, the license fee is required by the patent managing group MPEG LA if you fall into two groups:
(1) Distribute H.264 encoder or decoder, paid or free, software or hardware
(2) Distribute content in H.264 format (except free Internet videos)
“Distribute” the capability of creating or consuming H.264 videos
Licensing is required if you give consumers the ability to create (a.k.a. encode) or watch (a.k.a. decode) H.264 videos.
This applies to device vendors that ship hardware H.264 encoder or decoder with their devices, like Apple, Samsung, Dell, HP, and Sony, for their smart phones, computers, and DVD players.
A hardware encoder/decoder may go through the factories of many companies along the supply chain before it’s sold to consumers. Only the company that puts the brand on the product has to pay the license fee, e.g. Samsung for a smartphone with hardware H.264 encoder instead of Qualcomm who actually builds the chips.
This group also includes software vendors whose products contain H.264 encoder or decoder, like Microsoft’s Windows OS, Adobe’s Flash player, Apple’s QuickTime player, and Google’s Android OS.
Note that this rule applies even if the software is free of charge. But if it’s open source and you distribute the source code instead of the compiled binary, you don’t need to pay the license fee.
This is why people host downloadable pre-built binaries of open source software like FFmpeg in countries outside US where the same patent laws don’t apply.
If your software can encode or decode H.264 video, but it calls some API from the OS or the browser to do the job, you don’t need to pay the license fee since the hardware/OS/browser vendors already have you covered.
If Microsoft incorporates a third party H.264 encoder/decoder into Windows OS, the third party company is free from license fee but Microsoft is not, because the end users only see Microsoft’s brand.
What if you sell software H.264 encoder to enterprise to deploy on their backend servers in large scale, e.g. for Netflix or YouTube? The answer is no if they purchase your source code. I’m not so sure about compiled library or executable, but the license fee starting threshold is 100,000 units and >100,000 units purchase for server side software will be extremely rare anyway.
Take YouTube for example, it’s reported that 500 hours of new content is uploaded per minute as of 2019, i.e. 30,000 minutes video uploaded per minute. Conservatively assume that one physical server transcodes a video at 1X speed (taking multiple bitrate/resolution into consideration), it would require only 30,000 servers to keep transcoding up to speed with uploading.
The math is dramatically different for client side software of course. If a mobile application contains H.264 encoder/decoder, they have to pay license fee for every app installation. If the encoder/decoder is from a third party vendor, it’s still the application creator’s responsibility to pay the license fee, not the third party vendor.
“Distribute” paid H. 264 content
Besides distributing “capability”, distributing H.264 content requires license fee too, but only if you charge people for the content, by title or by subscription (exception: broadcast on television is a different story).
So Netflix is required to pay license fee for the videos they distribute, while it’s not true for YouTube (at least for the non-premium content since YouTube does have paid channels now).
Similarly, no content incurred license fee for other UGC video platforms like Tiktok, Facebook, SnapChat, because they draw revenue from Ads instead of paid video views. Software encoder/decoder incurred license fee may still apply if their client software contains H.264 encoder or decoder.
Also note that it’s the video distributor, i.e. the video platform, being responsible for the license fee, not the video creator. This is reasonable because codec choice is made by the platform.
Cloud transcoding service providers
I read through the full license agreement (requested from MPEG LA by email) and still find it difficult to decide what rules apply to cloud transcoding service like AWS MediaConvert. They sell encoding “service”, different from hardware or software product, and they typically sell to business instead of end users.
My best guess is that they fall into the second group of distributing paid H.264 content, because they only make money when someone use the service to create H.264 video. Therefore they may pay license fee by title (if the service charge for transcoding minute) or by subscription (if the service offer subscription based plans), or a combination of both (if the service charge by minute for subscribers after a usage threshold).
So if a free Internet video platform P uses a cloud transcoding service T to compress video files, P doesn’t need to pay license fee since their content is free, while T has to because they charge for video files created from their service.
Zero fee threshold and annual cap
All being said, the license fee is 0 for small players anyway. That is, <100,000 units or subscriptions per year. “Unit” could be machines installed, devices sold, or software licenses activated. If your business doesn’t reach this threshold by any means of counting, you don’t need to worry about it.
For tech startups in nowadays, the license fee can be a real pain if your mobile application ships with your own H.264 encoder or decoder other than relying on the OS built-in codec support, because you may quickly exceed 100,000 installs. Then you will be charged 0.10$ to 0.20$ per install per year until capped at $9.75M (as of 2020).
We should keep in mind that MPEG LA is not coming after you to rob your business. On the contrary, it’s in their best interest if a large number of medium sized companies thrive, far better than relying on a few tech giants capped at an amount unproportional to their scale.
Another good news is, and you probably have heard a lot about it by now, you have an alternative: the modern, open, royalty free video codec AV1. Whether AV1 will replace H.264 as the most popular video codec is yet to be seen, but it definitely has the potential as many tech giants stand behind it. (Yes, it’s kind of ironic that the license fee is like pocket money for tech giants, but they make the biggest effort to eliminate it, for various reasons.)
Finally let’s have a quiz. Consider the following scenario:
Ada recorded a video on her iPhone and used a mobile app called WeeStudio to edit and publish it to video platform iTube.
WeeStudio invoked VideoToolbox provided by iOS to decode the H.264 video, compressed it with WeeStudio’s own encoder, and uploaded the video to iTube server.
iTube employed a public cloud transcoding service from vCompress to further reduce the size of the video.
When another user Bob watched the video in iTube app on his Android device, iTube decoded the video using an open source software decoder created by OpenCodec.
Among all the companies that appeared in the story — Apple (iPhone/iOS), WeeStudio (video editor), iTube (video platform), vCompress (cloud transcoding), Google (Android), OpenCodec (open source decoder) — which one(s) do not need to pay H.264 license fee? (find the answer at the end)
Please leave a comment if you find this post helpful, or have something to share!
Also keep in mind that I’m not a lawyer and I don’t have a lawyer to review my post — please proceed with caution and at your own risk.
Happy video hacking!
[The answer is: OpenCodec.]