2018-03-05 13:48 GMT+01:00 Carl Eugen Hoyos <ceffm...@gmail.com>:
> 2018-03-05 12:37 GMT+01:00, Paul B Mahol <one...@gmail.com>:
> > On 3/5/18, Vasile Toncu <vasile.to...@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.
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.
ffmpeg-devel mailing list