2018-03-07 0:49 GMT+01:00 Carl Eugen Hoyos <ceffm...@gmail.com>: > 2018-03-06 19:38 GMT+01:00, Thomas Mundt <tmund...@gmail.com>: > > > > 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. > > 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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel