Merry Christmas to everyone!
These days before Christmas have been hectic for various reasons – largely supporting numerous FlashyWrappers customers (or people interested in FW) in regards to video replays. I recognize this is a pretty big issue and as far as desktop is concerned especially(where .ogv videos are currently supported). As you probably know, OGV videos can’t be played in Flash Player. There are several alternative plans to deal with this for current customers, including creating OGV video player.
However, by far the biggest demand there is when it comes to encoding to MP4 files. And understandably so, as MP4 is the only viable format to be played natively on any mobile device these days. Up until recently, there has been issues with doing that as the x264 encoder (used together in ffmpeg, on desktop FlashyWrappers) would effectively mean recompiling FFmpeg in GPL mode. This would not only mean forced GPL license on the whole of FlashyWrappers, but also forced GPL license for your software (as a customer of FlashyWrappers). This has always been the biggest issue for me really. I don’t really like to force any licenses on my customers and I’m sure many customers would not expect that in the first place.
The situation on mobile devices with iOS or Android is different – hardware H264 encoders can be utilized on those devices and nobody has to worry about licensing or royalty payments.
A change is coming to FW on desktops though. I’ve been researching quite alot around the OpenH264 lib in recent months. I came to the conclusion that it is pretty safe to include the library into FlashyWrappers (or rather, create another branch of FlashyWrappers desktop with official H264 support). So what are the catches? I’m not a lawyer and this is only based on my personal research, but:
1) First let me say that the good news is OpenH264 licenses both for their source code and binaries is BSD. This is absolutely non-restrictive license regardless of commercial or non-commercial use. That means, no license forcing you to make your software open sourced. That’s the most important thing
2) CISCO paid licensing fees for the binaries they are building from their sources. From what I understood, the party distributing the encoder must pay fees to MPEG LA. To make sure CISCO is the distributor all the time, you are required to make your app download their binaries before using them. That way CISCO is the distributor, you are not. This would be applicable only for AIR of course, where AIR could call the externally downloaded EXE file.
3) I will however go the other way first – including CISCO source code into one FlashyWrappers branch. Which will mean SWC / ANE files with no binaries to download. This is of course the only way for Flash Player based apps which can not download or execute any binaries, and as a side effect it will also work in desktop AIR, which is why this way is the priority.
So what about the royalty payments?
From what I personally understood, the royalty payments are zero for 0 – 100,000 units / installs per year of the encoder. I’m sure that many if not most of my customers (and me) won’t go above that number. This number is included in the MPEG LA license which you can also check, and I found confirmations on several forums that this is true (since 2005).
In case you get over 100K units then the fees are really not as horrible as you might have imagined – something like $0.2 / $0.1 per unit depending on how many units(installs) you sell.
Having said that, I feel it is safe to provide FlashyWrappers for desktop with OpenH264. I’ll need to find the time along the Android version (and there might still be issues with compiling this using FlasCC / Alchemy 2) but I’ll at least start the attempt very soon.
The only unclear part for me so far was whenever or not you’d need to obtain a license still from MPEG LA, but I’m assuming that BSD license of CISCO applies in this case (and CISCO dealt their license with MPEG LA). I can’t imagine this being a huge issue though.
Coming back to video replays – having H264 support should mean the ability to introduce video replays natively. Two big issues squished in one go 🙂