On 06.03.2018 20:38, Thomas Mundt wrote:

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:

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.
ffmpeg-devel mailing list

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?

Vasile Toncu

ffmpeg-devel mailing list

Reply via email to