[FFmpeg-devel] [PATCH] Port x264 SSE2 deblocking code to H.264 decoder

Måns Rullgård mans
Wed Dec 17 21:01:54 CET 2008


"Robert Swain" <robert.swain at gmail.com> writes:

> 2008/12/17 Robert Swain <robert.swain at gmail.com>:
>> 2008/12/17 Michael Niedermayer <michaelni at gmx.at>:
>>> On Wed, Dec 17, 2008 at 06:26:58PM +0000, Loren Merritt wrote:
>>>> On Wed, 17 Dec 2008, Michael Niedermayer wrote:
>>>> > On Wed, Dec 17, 2008 at 05:08:18AM +0000, Loren Merritt wrote:
>>>> >>
>>>> >> I don't plan to relicense to LGPL.
>>>> >> How loud will people complain if I optimize x264's deblocker
>>>> >> in a way that's not drop-in compatible, update ffmpeg c to
>>>> >> match, and delete the existing LGPL mmx versions?
>>>> >
>>>> > Would it be possible to support both the existing LGPL variant
>>>> > and your proposed one at the same time? (via #ifdef GPL)
>>>>
>>>> It would not be feasible to ifdef all the calling c code.
>>>> In this case the change in behaviour won't be very large, so one
>>>> could update the LGPL version so that they're interchangeable
>>>> again. But the question was really about, what if I import a
>>>> function different enough that I don't volunteer to do that
>>>> update?
>>>
>>> You would have to convince the (majority of) ffmpeg developers
>>> that this is a good idea. Personally i dont really care if our
>>> h264 decoder is LGPL or GPL.
>>> And even less so if a optional LGPL asm function is replaced by a
>>> better GPL one with changed behavior, which is what was suggested
>>> if i did not misunderstand.
>>
>> Personally, I'm far more concerned about decoder speed than GPL vs LGPL.
>
> ...as long as it is functional under LGPL.

Removing existing assembler optimisations would effectively make it
non-functional for many people.

-- 
M?ns Rullg?rd
mans at mansr.com




More information about the ffmpeg-devel mailing list