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