[FFmpeg-devel] [PATCH] reitnerlace - tinterlace-like filter under LGPL
vasile.toncu at tremend.com
Thu Mar 22 15:56:36 EET 2018
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:
>>> 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:
>>>>>> 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
>>>>>> 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
>>> 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.
>>> ffmpeg-devel mailing list
>>> ffmpeg-devel at ffmpeg.org
>> 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
>> To have the reinterlace added, what is needed to be done from my side?
>> 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
> 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
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?
> 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.
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
More information about the ffmpeg-devel