2018-03-29 15:44 GMT+02:00 Vasile Toncu <vasile.to...@tremend.com>: > > > On 14.03.2018 18:56, Thomas Mundt wrote: > >> 2018-03-13 16:10 GMT+01:00 Vasile Toncu <vasile.to...@tremend.com>: >> >> >>> On 06.03.2018 20:38, Thomas Mundt wrote: >>> >>> Hi, >>>> >>>> 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. >>>> 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. >>>> Thanks, >>>> Thomas >>>> _______________________________________________ >>>> ffmpeg-devel mailing list >>>> ffmpeg-devel@ffmpeg.org >>>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel >>>> >>>> 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? >>> >>> Thanks, >>> 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 >> vf_interlace. >> 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 >> > > Hello, > > Further research I've made showed that vf_tinterlace already contains all > the functionality from vf_interlace. I am ready to start the patches. > > Please confirm. >
The functionality is not the point. The options must not be removed. "ffmpeg -i input vf interlace output" must remain for the user. > Regards, > Vasile Toncu > >> 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. >> >> Regards, >> Thomas >> _______________________________________________ >> ffmpeg-devel mailing list >> ffmpeg-devel@ffmpeg.org >> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel >> > > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
