[01.org Android-IA] Using Cisco OpenH.264 in AOSP
cprice at mmv.mobi
Wed May 11 13:57:09 PDT 2016
One of my astute colleagues brought up the notion of using OpenH.264 in the AOSP build path.
As you may know, Cisco has published free, Android-compatible H.264 codecs that are optimized across ARM and x86: http://www.openh264.org <http://www.openh264.org/>
The benefit? Cisco has agreed to pay decoder licensing costs to the MPEG LA for anyone that uses OpenH.264.
From their FAQ:
Q: Is Cisco guaranteeing that it will pay other licensing fees for H.264, should additional patent holders assert claims in the future?
A: Cisco is providing no such guarantee. We are only covering the royalties that would apply to the binary module under MPEG LA's AVC/H.264 patent pool.
Q: If I use the source code in my product, and then distribute that product on my own, will Cisco cover the MPEG LA licensing fees which I'd otherwise have to pay?
A: No. Cisco is only covering the licensing fees for its own binary module, and products or projects that utilize it must download it at the time the product or project is installed on the user's computer or device. Cisco will not be liable for any licensing fees incurred by other parties.
The catch there seems to be that we have to exclusively use Cisco’s binary module. The presence of another H.264 decoder module (say, Intel’s or Google’s OMX plugins), would still require paying the patent pool. Simply the presence of OpenH.264 on the device is not sufficient - it must be the exclusive decoder.
I’m sure you’ve figured out where I’m going with this. If we could use OpenH.264 in the AOSP build path, in place of OMX, that would probably mean not having to pay the MPEG LA for use of H.264 in Android devices running IA.
That could save Intel Android device makers a lot of money. And hassle. Each patent pool we can check off before going into production, helps a lot.
Looking at the module right now, it’s built to be embedded in an app, not in the AOSP build path. I’m not sure if the module will work out of the box.
Any interest (Intel or otherwise) in looking into this with me? It could be a considerable benefit to all OEMs running Intel if we could check this box off.
P.S. I realize the stock AOSP OMX decoder is probably more efficient, especially on IA devices, but this could be an option for OEMs that don’t want the go-to-market hassle - or, are using IoT applications that don’t need to worry about performance or power consumption.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Celadon