Using the OpenH264 code might be a way out, as it is under the BSD license, and Cisco pays the H264 licensing costs. Unfortunately, OpenH264 is in C++, not Java, and platform-specific.
Probably one could access it from an ImageJ plugin with JNI, but that's nothing I am familiar with. If someone wants to do it, I would not discourage him or her.
The main caveat seems to be that one must not distribute OpenH264 with a plugin, every user would have to download it separately.
> Hi Michael,
>
> On Thu, 23 Jan 2014, Michael Schmid wrote:
>
>> On Jan 22, 2014, at 19:14, Knecht, David wrote:
>>
>>> Is there any reason that the codec options in Save as/Movie are so
>>> limited? It would be nice to be able to use H264 and other codecs for
>>> compressing movie
>>
>> there would be two problems saving movies as H264 in the core of ImageJ:
>> - License issues - ImageJ is completely public domain. I am not aware
>> of any H264 implementation in Java compatible with this.
>
> There is even more to it. While H.264 allows distribution of free video
> without paying royalties, the same is distinctly *not* true for free
> encoders/decoders:
>
http://en.wikipedia.org/wiki/H.264#Patent_licensing>
> That does imply that you would have to pay royalties if you distribute
> software encoding H.264, you have to pay up, even if you release the code
> into the public domain. (There are really complicated rules and exceptions
> and agreements and waivers around H.264, so you *might* get away with
> distributing an encoder implementing only a very limited set of features,
> but you need to ask a lawyer, so even that is not free -- great job
> security for people of the law!).
>
>> - Complexity and size - I think we should keep ImageJ nifty and lean
>> (due to the small size, it starts very quickly);
>
> ImageJ does not start very quickly... it does have to do a lot in the
> background, such as parsing all the plugins and generating the menu
> structure. The size of ImageJ has little to do with the startup time,
> therefore, but the number of plugins does.
>
> Also, a plugin that implements encoding with 100 different codecs would
> slow down the startup time exactly as much as a plugin implementing only
> one codec.
>
> Of course, the size would be affected if one were to make said complex
> plugin part of the core ImageJ. That is why many functions needed by many,
> but not needed by many more, are not part of core ImageJ.
>
> Actually, there is another very good reason why high-complexity plugins
> need to stay out of the core: already with the current set of core
> plugins, development is impeded: the more complexity, the more bugs.
>
>> an H264 codec would bloat ImageJ a lot.
>
> I fully agree. H.264 is a very complicated standard, coming with quite a
> lot of parameters and a number of "profiles" that already select sensible
> combinations of parameters.
>
>> If someone wants to write a plugin (where these limitations would not
>> apply), based on some java H264 library on the web, it would be welcome!
>
> I must caution that anybody who writes such a plugin might run into legal
> trouble. Better check that out first, before spending a *lot* of time to
> implement it!
>
> Ciao,
> Dscho
>
> --
> ImageJ mailing list:
http://imagej.nih.gov/ij/list.html