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

[Vasile Toncu]

On 14.03.2018 18:56, Thomas Mundt wrote:
> 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
     Hi,

     From what I've researched, it seems that vf_interlace is just an 
incomplete functionality for vf_tinterlace, so it can be removed directly.

     Can anyone confirm this?

     Regards,
     Vasile Toncu

> 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
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel