Licode should swap to ffmpeg

[jnoring]

Licode currently uses libav, which is a fork of the ffmpeg project. Although it wasn't clear to me a year ago, it's pretty clear that ffmpeg is a better overall project and will be the long-term victor in that split. Here's why:

• libav is a subset of ffmpeg features. ffmpeg generally accepts patches from libav, but not vice-versa.
• the project activity on ffmpeg dwarfs libav. Looking at messages posted to their usergroup, ffmpeg has more in a day than libav has in some months.
• ffmpeg now has periodic releases instead of a "use trunk!" attitude
• may help fix seeking issues in our mkv files. currently libav isn't handling this well, and it's probably because they really see very little activity these days and their mkv/vp8 muxing is probably doing something wrong.

I'm happy to supply a patch to do this, assuming the devs here agree?

[lodoyun]

I agree. There is nothing tying us to libav and it does look like ffmpeg has seen more activity since we decided to go the other way. 👍

If you need any help with the patch I can allocate some time for this.

[zevarito]

Guys, has Licode switched to FFMpeg ?

[pritammobisoft]

This got me thinking about licensing of Licode. Parts of FFMPEG are GPL v3 and parts are LGPLv3. The Licode project's license is stated as MIT.

But as per this question on open source stack exchange, if you include a GPL v3 dependency in your program then the whole program "might" be required to use GPL v3 license.

So if Licode wants to stay MIT I think the core developers need to think more about FFMPEG depedency. I am not a lawyer, but just wanted to mention this, as unsuspecting users of Licode might use it because of it's MIT license and later might be surprised that they are required to follow GPL.