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

[Thomas Mundt]

2018-03-13 16:10 GMT+01:00 Vasile Toncu <vasile.toncu at tremend.com>:

>
>
> On 06.03.2018 20:38, Thomas Mundt wrote:
>
>> Hi,
>>
>> 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.
>> That way existing fate tests could be used which are fortunately pretty
>> extensive in this case.
>> 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.
>> Being left in the dark makes working on patches frustrating.
>>
>> Another question is how to deal with vf_interlace? IMHO for the user there
>> should be no difference in output, speed and license.
>> 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 would prefer the second option, but maybe there are even better options
>> that don´t come to my mind.
>>
>> Please comment.
>> Thanks,
>> Thomas
>> _______________________________________________
>> ffmpeg-devel mailing list
>> ffmpeg-devel at ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
>
> Hello everyone,
>
> sorry for a delayed response.
>
> From what has been discussed in here, I think the reinterlace will exist
> with tinterlace for a period of time, just after that the tinterlace can be
> removed.
>
> To have the reinterlace added, what is needed to be done from my side?
>
> Thanks,
> Vasile Toncu
>

Two filters with almost the same functionality won´t be accepted, as Paul
stated in this thread.
Also there is vf_interlace filter, which is a subset of vf_tinterlace and
should not differ in speed, output and license. As already said, I would
prefer to include vf_interlace options into vf_tinterlace and remove
vf_interlace.
Also you want several changes: Making tinterlace filter LGPL, adding new
options and adding slice threading.
This should be done in a patch set:

Patch 1/5: Include vf_interlace options into vf_tinterlace filter and
remove vf_interlace
Patch 2/5: Your new LGPL vf_reinterlace filter without the new options,
fixes and slice threading
Patch 3/5: Rename vf_reinterlace and replace vf_tinterlace by it
Patch 4/5: Add slice threading
Patch 5/5: Add the new options and fate tests for them

Please run fate. All tests should pass.
As already said, I don´t have the skills to suggest what has to be done
making the relicensing legal. So I can do a technical review only.
These are just my suggestions to the best of my knowledge! There might be
better ideas from more experienced developers.
Please comment.

Regards,
Thomas