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

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


Jason Garrett-Glaser wrote:
> On Wed, Dec 17, 2008 at 6:39 AM, M?ns Rullg?rd <mans at mansr.com> wrote:
>>
>> Diego Biurrun wrote:
>>> On Wed, Dec 17, 2008 at 12:58:12PM +0000, M?ns Rullg?rd wrote:
>>>>
>>>> Diego Biurrun wrote:
>>>> > On Wed, Dec 17, 2008 at 10:56:16AM +0000, M?ns Rullg?rd wrote:
>>>> >>
>>>> >> Loren Merritt wrote:
>>>> >> > On Wed, 17 Dec 2008, Guillaume POIRIER wrote:
>>>> >> >
>>>> >> >> Since basicly only Loren and yourself have worked on that code,
>>>> >> >> maybe you'd both be willing to re-licence it in LGPL?
>>>> >> >
>>>> >> > 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?
>>>> >>
>>>> >> A simple "no" would have sufficed.  Are you on a crusade against all
>>>> >> things non-gpl or what?
>>>> >
>>>> > Now where did this come from?
>>>>
>>>> Did you read what Loren wrote?  He pretty much threatened to deliberately
>>>> destroy the existing lgpl optimisations.
>>>
>>> I rather read it as replacing existing optimizations by superior (GPL)
>>> ones.
>>
>> That wouldn't require first making it incompatible with the lgpl version.
>
> It could.  Classic example is the case of SSE2 chroma deblocking,
> which requires a significant reorganization (to call both u/v
> simultaneously).  I could imagine other optimizations which, when
> taken advantage of, would make it rather aggravating and
> unmaintainable to try to support both an old deblocking function and a
> new one.

In such a case the existing functions should be fixed, not deleted.

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




More information about the ffmpeg-devel mailing list