Free/Open h.264 video decoding libraries? (Non-GPL)

Question

The main players seem to be x264, and xvid, and both are GPL. This means we can't integrate decoding capabilities into a playback application without licensing the whole thing as GPL, so we can't use either.

The preferred target platform is Linux. Any non-viral open license is fine, we're more than happy to provide the source of any changes we make to libraries, just not our whole application.

Is there anything? Or maybe we should use GPL for now as a test during development, and plan to replace it with commercially licensed codec before shipping?

Answer 1

Cisco released a BSD-licensed h264 library for encoding and decoding.

I wish you would just use GPL, but I'm not going to just tell you to do that when there is an answer out there.

http://www.openh264.org/
and the GitHub page:
https://github.com/cisco/openh264

Answer 2

Note that VLC and most of its libraries are now LPGL

VLC engine relicensed to LGPL - http://www.videolan.org/press/lgpl-libvlc.html

VLC playback modules relicensed to LGPL - http://www.videolan.org/press/lgpl-modules.html

Answer 3

PocketVideo's OpenCore is now open-sourced under Apache 2.0 license as part of Android OS: https://github.com/android/platform_external_opencore

Answer 4

Take a look at the Intel IPP Libraries. They are not free, but are very cheap (a once-off payment of a hundred dollars or something). You can also get a free evaluation to test it out. The licence is very open, and as far as I know allows you unlimited distribution in your application forever once you buy it.

Answer 5

The ffmpeg H.264 decoder is LGPL. Only the encoders are GPL, and x264 does not provide a decoder.

It also has the advantage over Framewave and IPP of actually being usable.

Answer 6

IANAL.

If you ship unmodified binaries created from unmodified GPL source and your application simply invokes them, I believe your entire app does not have to be GPL. You may have to include GPL documentation and/or the source of the bundled GPL apps, but if you are not making any modifications or linking against GPL code, your code should be unaffected.

As far as the MPEG standards, that may be another bag of worms entirely...

Answer 7

IANAL, but if you're shipping anywhere software patents are enforced, not only do you have to pay the MPEG LA royalties for h.264 decoding, but the license might preclude you from using the open-source decoders anyhow. I've heard of similar annoyances applying to other codecs.

Answer 8

I've done some work with FFmpeg, though it was limited to libavformat (the codec part is called libavcodec). I found the API to be surprisingly straight forward and easy to use. They provide a few really useful and enlightening samples in the standard source distribution.

Generally the library holds rather high quality, but some modules seems to be lacking, so I can't vouch for the h264 part. I've heard good things about the encoder, though.

Answer 9

Ok, FFMpeg appears to handle h.264. I believe most of it is LGPL.

Would still love to hear experiences with it (good or bad), or other options, thanks.

-- Correction, the version I just tested appears to be compiled with "--enable-gpl", which leads me to beleive it's making use of GPL licensed codecs. Argh!

Answer 10

A project derived from AMD performance library, Framewave, now has a video component supporting h.264 decoding.

The license is the "Apache 2.0 license"

you can check it out at Sourceforge SVN