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

[Thomas Mundt]

2018-03-29 15:44 GMT+02:00 Vasile Toncu <vasile.toncu at tremend.com>:

>
>
> 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
>>
>
> Hello,
>
> Further research I've made showed that vf_tinterlace already contains all
> the functionality from vf_interlace. I am ready to start the patches.
>
> Please confirm.
>

The functionality is not the point. The options must not be removed.
"ffmpeg -i input vf interlace output" must remain for the user.


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