[FFmpeg-devel] [PATCH] reitnerlace - tinterlace-like filter under LGPL

Carl Eugen Hoyos ceffmpeg at gmail.com
Wed Mar 7 01:49:26 EET 2018


2018-03-06 19:38 GMT+01:00, Thomas Mundt <tmundt75 at gmail.com>:
>
> 2018-03-05 13:48 GMT+01:00 Carl Eugen Hoyos <ceffmpeg at gmail.com>:
>
>> 2018-03-05 12:37 GMT+01:00, Paul B Mahol <onemda at gmail.com>:
>> > On 3/5/18, Vasile Toncu <vasile.toncu at tremend.com> wrote:
>> >> Hello,
>> >>
>> >> Thanks for the review. I've made changes according to your guidance.
>> >>
>> >> It would be great to know if the community will go on with our
>> >> intention
>> >> of adding reinterlace as a alternative for tinterlace.
>> >>
>> >> That being said, here is the new patch.
>> >
>> > As already said, this is not acceptable.
>> >
>> > There is no point in having 2 filters with near same funcionality.
>>
>> If you consider the new filter ok, the existing filter will be removed
>> in the same push. I believe sending only the new filter makes
>> reviewing easier.
>
> For me reviewing would be easier when Vasile sends a patchset
> that includes the replacement of tinterlace filter.

The first patch would be quite trivial, this patch is the one you have to
review...

> That way existing fate tests could be used which are fortunately pretty
> extensive in this case.

I thought that one patch should remove the existing filter and
another one adding the new one but I agree that fate suggests
to do this in one patch.

> Also it would be helpful when you and/or other experienced ffmpeg
> developers would clarify first which parts of tinterlace have to be
> rewritten for proper relicensing.

The suggestion is to replace the whole filter instead of rewriting
parts which definitely is the safer solution.

> Being left in the dark makes working on patches frustrating.

I don't understand this comment, sorry.

> Another question is how to deal with vf_interlace? IMHO for the user there
> should be no difference in output, speed and license.

The whole point of this patch is to make a difference license-wise:
Having the same filter also for default compilation is an improvement
imo.

> Two options:
> 1. Relicensing and slice threading will also be ported to vf_interlace

> 2. The commands from vf_interlace will be included in the new tinterlace
> filter. vf_interlace will be deleted together with old tinterlace filter

I believe 2 was suggested. Is the patch not sufficient?

> I would prefer the second option, but maybe there are even better options
> that donĀ“t come to my mind.

Carl Eugen


More information about the ffmpeg-devel mailing list