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

Thomas Mundt tmundt75 at gmail.com
Wed Mar 7 03:04:56 EET 2018


2018-03-07 0:49 GMT+01:00 Carl Eugen Hoyos <ceffmpeg at gmail.com>:

> 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.
>

I would have no problem using fate with two patches - one that removes
vf_tinterlace and another that adds a new vf_tinterlace when they are both
available for the review.
But it seems that Vasile, and to be honest me too, understood your
suggestion that first he shall send a new filter with a different name.
That one shall be reviewed and later on vf_ tinterlace be replaced.

> 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.
>

Do you mean the whole filter shall be rewritten?
I´m sorry, but I have no clue at what difference from the original, code,
that does the same thing, can be considered as rewritten.


>
> > Being left in the dark makes working on patches frustrating.
>
> I don't understand this comment, sorry.
>

I hope my answer above explains my problem.


>
> > 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 didn´t notice that anything was suggested in relation to vf_interlace.
It is not included in the patch and maybe should be separate one.


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


More information about the ffmpeg-devel mailing list