581773 - Consider using LGPL-licensed ffvp8 for WebM videos

Status: RESOLVED WONTFIX

(Core :: Audio/Video, enhancement)

Description

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

ffvp8 seems to be a slightly faster implementation than libvpx.

http://x264dev.multimedia.cx/?p=499

Comment 1

[cajbir (:cajbir)]

ffvp8 is LGPL which make it difficult for us to use.

Comment 2

[Shmerl]

According to http://www-archive.mozilla.org/MPL/relicensing-faq.html#why-relicensing the problem may arise when MPL code intends to extend the functionality of LGPL licensed library through linking into it directly. What about the other way around case (when LGPL code extends the functionality of MPL code)?

Comment 3

[Gervase Markham [:gerv]]

While there is no legal reason we can't use LGPLed code, Mozilla licensing policy since the project began has avoiding doing so in order to avoid increasing the complexity of our licensing (which can currently be summed up as "cool with the MPL? Then you can use our stuff"). 

As it's a policy, rather than a legal requirement, it would not be _impossible_ to change, but significant benefits would have to be demonstrated. To give you some idea of what code we have not used for this reason even though it might provide benefits, in the recent past, we didn't use gstreamer because it was LGPLed.

Unless our WebM implementation has performance issues, and roc comes and says this is something we should seriously consider, this is a WONTFIX.

Gerv

Comment 4

[cajbir (:cajbir)]

(In reply to comment #3)
> To give you
> some idea of what code we have not used for this reason even though it might
> provide benefits, in the recent past, we didn't use gstreamer because it was
> LGPLed.

I've been asked to review the gstreamer patch with the intent to land it turned off (as I understand it so Mobile can use it turned on). My understanding is we don't use LGPL code so I'm unsure where things go in that regard. Are you CC'd on the bug?

(Not advocating for it's inclusion or use of ffvp8, I just thought this would be a good point to ask)

Comment 5

[Gervase Markham [:gerv]]

cdouble: not sure if I'm CCed on that bug - can you check? And tell me the bug number?

Gerv

Comment 6

[cajbir (:cajbir)]

Bug 422540 and it doesn't appear you're currently cc'd.

Comment 7

[[Baboo]]

(In reply to Gervase Markham [:gerv] from comment #3)
> Unless our WebM implementation has performance issues, and roc comes and
> says this is something we should seriously consider, this is a WONTFIX.

What if Chrome/Chromium switches to ffvp8? http://crbug.com/50811

Comment 8

[Gervase Markham [:gerv]]

Mozilla has changed policy and we are now accepting carefully-demarcated LGPLed libraries into Mozilla core. So if people still want to do this, there is no licensing objection. But if not, please resolve the bug.

Gerv

Comment 9

[Ralph Giles (:rillian)]

Thanks for the reminder, Gerv.

WebRTC requires a vp8 encoder as well as decoder, so using ffvp8 means trading code size for decoder performance. We'd also have to write a maintain new webrtc bindings if we wanted to use ffvp8 there as well.

As such I don't see sufficient reason to do this. If we have performance problems with libvpx in the future we can revisit, but for now I'm resolving on the bases that 'slightly faster' isn't persuasive.