Re: [FFmpeg-devel] [PATCH] reitnerlace - tinterlace-like filter under LGPL
2018-03-29 15:44 GMT+02:00 Vasile Toncu : > > > On 14.03.2018 18:56, Thomas Mundt wrote: > >> 2018-03-13 16:10 GMT+01:00 Vasile Toncu : >> >> >>> On 06.03.2018 20:38, Thomas Mundt wrote: >>> >>> Hi, 2018-03-05 13:48 GMT+01:00 Carl Eugen Hoyos : 2018-03-05 12:37 GMT+01:00, Paul B Mahol : > On 3/5/18, Vasile Toncu 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
Re: [FFmpeg-devel] [PATCH] reitnerlace - tinterlace-like filter under LGPL
On 14.03.2018 18:56, Thomas Mundt wrote: 2018-03-13 16:10 GMT+01:00 Vasile Toncu : On 06.03.2018 20:38, Thomas Mundt wrote: Hi, 2018-03-05 13:48 GMT+01:00 Carl Eugen Hoyos : 2018-03-05 12:37 GMT+01:00, Paul B Mahol : On 3/5/18, Vasile Toncu 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. 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
Re: [FFmpeg-devel] [PATCH] reitnerlace - tinterlace-like filter under LGPL
On 14.03.2018 18:56, Thomas Mundt wrote: 2018-03-13 16:10 GMT+01:00 Vasile Toncu : On 06.03.2018 20:38, Thomas Mundt wrote: Hi, 2018-03-05 13:48 GMT+01:00 Carl Eugen Hoyos : 2018-03-05 12:37 GMT+01:00, Paul B Mahol : On 3/5/18, Vasile Toncu 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 Hi, From what I've researched, it seems that vf_interlace is just an incomplete functionality for vf_tinterlace, so it can be removed directly. Can anyone confirm this? 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
Re: [FFmpeg-devel] [PATCH] reitnerlace - tinterlace-like filter under LGPL
2018-03-13 16:10 GMT+01:00 Vasile Toncu : > > > On 06.03.2018 20:38, Thomas Mundt wrote: > >> Hi, >> >> 2018-03-05 13:48 GMT+01:00 Carl Eugen Hoyos : >> >> 2018-03-05 12:37 GMT+01:00, Paul B Mahol : >>> On 3/5/18, Vasile Toncu 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
Re: [FFmpeg-devel] [PATCH] reitnerlace - tinterlace-like filter under LGPL
On 06.03.2018 20:38, Thomas Mundt wrote: Hi, 2018-03-05 13:48 GMT+01:00 Carl Eugen Hoyos : 2018-03-05 12:37 GMT+01:00, Paul B Mahol : On 3/5/18, Vasile Toncu 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 Thanks ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] reitnerlace - tinterlace-like filter under LGPL
2018-03-07 0:49 GMT+01:00 Carl Eugen Hoyos : > 2018-03-06 19:38 GMT+01:00, Thomas Mundt : > > > > 2018-03-05 13:48 GMT+01:00 Carl Eugen Hoyos : > > > >> 2018-03-05 12:37 GMT+01:00, Paul B Mahol : > >> > On 3/5/18, Vasile Toncu 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
Re: [FFmpeg-devel] [PATCH] reitnerlace - tinterlace-like filter under LGPL
2018-03-06 19:38 GMT+01:00, Thomas Mundt : > > 2018-03-05 13:48 GMT+01:00 Carl Eugen Hoyos : > >> 2018-03-05 12:37 GMT+01:00, Paul B Mahol : >> > On 3/5/18, Vasile Toncu 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. > 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. > Being left in the dark makes working on patches frustrating. I don't understand this comment, sorry. > 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 would prefer the second option, but maybe there are even better options > that don´t come to my mind. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] reitnerlace - tinterlace-like filter under LGPL
2018-03-05 13:53 GMT+01:00, Paul B Mahol : > On 3/5/18, Carl Eugen Hoyos wrote: >> 2018-03-05 12:37 GMT+01:00, Paul B Mahol : >>> On 3/5/18, Vasile Toncu 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. > > I'm ok with that, but next commits that do that and also do rename are > not available. It should have been a former (not a next) commit that I considered trivial but I see now that because of fate it makes sense to add and remove in one patch. > I'm also not sure can reinterlace filter be considered really safe from > standpoint that it does not use any old GPL code. Not sure I understand: Do you mean that the new filter was not independently written? > Also bunch of stuff it does is trivial, both new and old GPL > code so I consider nobody should care about its license. That does not sound like a safe approach. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] reitnerlace - tinterlace-like filter under LGPL
Hi, 2018-03-05 13:48 GMT+01:00 Carl Eugen Hoyos : > 2018-03-05 12:37 GMT+01:00, Paul B Mahol : > > On 3/5/18, Vasile Toncu 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
Re: [FFmpeg-devel] [PATCH] reitnerlace - tinterlace-like filter under LGPL
Hello, The reinterlace behaves just like the tinterlace and in terms of fps is basically the same. The ASM Opts are used with reinterlace only in case of CONFIG_GPL enabled. There are two new modes, MODE_MERGE_BFF and MODE_MERGE_TFF for which I have documentation. Also reinterlace processes the planes of a frame in separate threads. I've tested it with diferent video formats, and the outputs are correct. Previously there have been acceptance for using some methods form tinterlace. Those methods have nothing to do with old, GPL licensed code, and are doing some trivial stuff. One can check thread starting at [1]. [1] http://ffmpeg.org/pipermail/ffmpeg-devel/2018-February/224941.html On 3/5/2018 2:53 PM, Paul B Mahol wrote: On 3/5/18, Carl Eugen Hoyos wrote: 2018-03-05 12:37 GMT+01:00, Paul B Mahol : On 3/5/18, Vasile Toncu 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. I'm ok with that, but next commits that do that and also do rename are not available. I'm also not sure can reinterlace filter be cosidered really safe from standpoint that it does not use any old GPL code. Also bunch of stuff it does is trivial, both new and old GPL code so I consider nobody should care about its license. ___ 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
Re: [FFmpeg-devel] [PATCH] reitnerlace - tinterlace-like filter under LGPL
On 3/5/18, Carl Eugen Hoyos wrote: > 2018-03-05 12:37 GMT+01:00, Paul B Mahol : >> On 3/5/18, Vasile Toncu 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. I'm ok with that, but next commits that do that and also do rename are not available. I'm also not sure can reinterlace filter be cosidered really safe from standpoint that it does not use any old GPL code. Also bunch of stuff it does is trivial, both new and old GPL code so I consider nobody should care about its license. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] reitnerlace - tinterlace-like filter under LGPL
2018-03-05 12:37 GMT+01:00, Paul B Mahol : > On 3/5/18, Vasile Toncu 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. Please comment, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] reitnerlace - tinterlace-like filter under LGPL
On 3/5/18, Vasile Toncu 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. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] reitnerlace - tinterlace-like filter under LGPL
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. Regards, -Vasile Toncu From 7419be6fa213383ed0908976eedfb963837ed738 Mon Sep 17 00:00:00 2001 From: Vasile Toncu Date: Mon, 12 Feb 2018 14:16:27 +0200 Subject: [PATCH] Added reitnerlace filter. --- libavfilter/Makefile | 1 + libavfilter/allfilters.c | 1 + libavfilter/reinterlace.h | 141 +++ libavfilter/vf_reinterlace.c | 757 ++ libavfilter/x86/Makefile | 1 + libavfilter/x86/vf_reinterlace_init.c | 101 + 6 files changed, 1002 insertions(+) create mode 100644 libavfilter/reinterlace.h create mode 100644 libavfilter/vf_reinterlace.c create mode 100644 libavfilter/x86/vf_reinterlace_init.c diff --git a/libavfilter/Makefile b/libavfilter/Makefile index 6a60836..c3095ba 100644 --- a/libavfilter/Makefile +++ b/libavfilter/Makefile @@ -286,6 +286,7 @@ OBJS-$(CONFIG_RANDOM_FILTER) += vf_random.o OBJS-$(CONFIG_READEIA608_FILTER) += vf_readeia608.o OBJS-$(CONFIG_READVITC_FILTER) += vf_readvitc.o OBJS-$(CONFIG_REALTIME_FILTER) += f_realtime.o +OBJS-$(CONFIG_REINTERLACE_FILTER) += vf_reinterlace.o OBJS-$(CONFIG_REMAP_FILTER) += vf_remap.o framesync.o OBJS-$(CONFIG_REMOVEGRAIN_FILTER) += vf_removegrain.o OBJS-$(CONFIG_REMOVELOGO_FILTER) += bbox.o lswsutils.o lavfutils.o vf_removelogo.o diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c index 9adb109..60fb9b5 100644 --- a/libavfilter/allfilters.c +++ b/libavfilter/allfilters.c @@ -295,6 +295,7 @@ static void register_all(void) REGISTER_FILTER(READEIA608, readeia608, vf); REGISTER_FILTER(READVITC, readvitc, vf); REGISTER_FILTER(REALTIME, realtime, vf); + REGISTER_FILTER(REINTERLACE, reinterlace, vf); REGISTER_FILTER(REMAP, remap, vf); REGISTER_FILTER(REMOVEGRAIN, removegrain, vf); REGISTER_FILTER(REMOVELOGO, removelogo, vf); diff --git a/libavfilter/reinterlace.h b/libavfilter/reinterlace.h new file mode 100644 index 000..3413a7e --- /dev/null +++ b/libavfilter/reinterlace.h @@ -0,0 +1,141 @@ +/* + * Copyright (c) 2017 Vasile Toncu + * Copyright (c) 2017 Thomas Mundt + * + * This file is part of FFmpeg. + * + * FFmpeg is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. + * + * FFmpeg is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with FFmpeg; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA + */ + +#include + +#include "avfilter.h" +#include "formats.h" +#include "internal.h" +#include "video.h" +#include "libavutil/avassert.h" +#include "libavutil/imgutils.h" +#include "libavutil/opt.h" +#include "libavutil/pixdesc.h" + +#include "libavutil/bswap.h" + +enum FilterMode { + MODE_MERGE, + MODE_DROP_EVEN, + MODE_DROP_ODD, + MODE_PAD, + MODE_INTERLEAVE_TOP, + MODE_INTERLEAVE_BOTTOM, + MODE_INTERLACE_X2, + MODE_MERGE_X2, + MODE_MERGE_TFF, + MODE_MERGE_BFF, + MODE_NB +}; + +enum FilterFlags { + FLAG_NOTHING = 0x00, + FLAG_VLPF = 0x01, + FLAG_EXACT_TB = 0x02, + FLAG_CVLPF = 0x04, + FLAG_NB +}; + +static const AVRational standard_tbs[] = { + {1, 25}, + {1, 30}, + {1001, 3}, +}; + +typedef struct { + const AVClass *class; + int mode; + int flags; + + AVFrame *prev_frame, *current_frame; + int64_t current_frame_index; + + void *black_vec[4]; + + int skip_next_frame; + + void *thread_data; + + uint8_t bit_depth; + + void (*lowpass_line)(uint8_t *dstp, ptrdiff_t width, const uint8_t *srcp, + ptrdiff_t mref, ptrdiff_t pref, int clip_max); + + AVRational preout_time_base; + +} ReInterlaceContext; + +#if CONFIG_GPL +void ff_reinterlace_init_x86(ReInterlaceContext *reinterlace); +#endif + +#define OFFSET(x) offsetof(ReInterlaceContext, x) +#define FLAGS AV_OPT_FLAG_FILTERING_PARAM|AV_OPT_FLAG_VIDEO_PARAM + +static const AVOption reinterlace_options[] = { + { "mode", "set mode", OFFSET(mode), AV_OPT_TYPE_INT, {.i64=MODE_MERGE}, 0, MODE_NB - 1, FLAGS, "mode" }, + { "merge", "merge frames",
Re: [FFmpeg-devel] [PATCH] reitnerlace - tinterlace-like filter under LGPL
Hi, 2018-02-12 16:37 GMT+01:00 Vasile Toncu : > Hello, > > there have been some discussions about tinterlace filter licensing. In the > end, I was unable to contact all the authorship holders. > > The main author, one from MPlayer project, is Michael Zucchi. It is quite > probably that the copyright is holden by the company that he worked for, > Ximian, which no longer exists. It is less probably that I'll came up with > the approval off all the parts involved in this deal. > > However, some of the later developers of tinterlace agreed to release the > parts they wrote under LGPL. I mention here Thomas Mundt and Stefano > Sabatini. > > This being said, I come up with a new filter - reinterlace - which > implements all the tinterlace functionalities and adds a few more. > > The new filter is added to ffmpeg without --enable-gpl and/or > --enable-nonfree. However, it these configure options are specified, the > reinterlace will use ASM opts, imported from tinterlace. I've used support > for 16bit depth video from the code written by Thomas Mundt. I added 2 new > modes MERGE_BFF and MERGE_TFF. I've changed MODE_PAD, so it does not drop > last frame from the input - tinterlace did so. > > In terms of performance, reinterlace gives basically the same fps as > tinterlace does. > > Here is the patch thats adds the filter. If everything goes well with this > patch, I'll add a new patch that changes current tinterlace with > reinterlace. > since I´m maintainer of the tinterlace filter I should review your patch. Unfortunately I don´t have a possibility to compile or test it ATM. So the review is incomplete and following comments are only parts of the changes that might be necessary. Also I don´t know which requirements have to be fulfilled for porting code from GPL to LGPL. I will need help from more experienced ffmpeg developers. > Thanks, > > -Vasile Toncu > > From 45010f4b4671edfe1318b84285d09dd28a882d63 Mon Sep 17 00:00:00 2001 > From: Vasile Toncu > Date: Mon, 12 Feb 2018 14:16:27 +0200 > Subject: [PATCH] Added reitnerlace filter. > > --- > libavfilter/Makefile | 1 + > libavfilter/allfilters.c | 1 + > libavfilter/reinterlace.h | 141 +++ > libavfilter/vf_reinterlace.c | 773 > ++ > libavfilter/x86/Makefile | 1 + > libavfilter/x86/vf_reinterlace_init.c | 101 + > 6 files changed, 1018 insertions(+) > create mode 100644 libavfilter/reinterlace.h > create mode 100644 libavfilter/vf_reinterlace.c > create mode 100644 libavfilter/x86/vf_reinterlace_init.c > > diff --git a/libavfilter/Makefile b/libavfilter/Makefile > index 6a60836..c3095ba 100644 > --- a/libavfilter/Makefile > +++ b/libavfilter/Makefile > @@ -286,6 +286,7 @@ OBJS-$(CONFIG_RANDOM_FILTER) += vf_random.o > OBJS-$(CONFIG_READEIA608_FILTER) += vf_readeia608.o > OBJS-$(CONFIG_READVITC_FILTER) += vf_readvitc.o > OBJS-$(CONFIG_REALTIME_FILTER) += f_realtime.o > +OBJS-$(CONFIG_REINTERLACE_FILTER)+= vf_reinterlace.o > OBJS-$(CONFIG_REMAP_FILTER) += vf_remap.o framesync.o > OBJS-$(CONFIG_REMOVEGRAIN_FILTER)+= vf_removegrain.o > OBJS-$(CONFIG_REMOVELOGO_FILTER) += bbox.o lswsutils.o > lavfutils.o vf_removelogo.o > diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c > index 9adb109..60fb9b5 100644 > --- a/libavfilter/allfilters.c > +++ b/libavfilter/allfilters.c > @@ -295,6 +295,7 @@ static void register_all(void) > REGISTER_FILTER(READEIA608, readeia608, vf); > REGISTER_FILTER(READVITC, readvitc, vf); > REGISTER_FILTER(REALTIME, realtime, vf); > +REGISTER_FILTER(REINTERLACE,reinterlace,vf); > REGISTER_FILTER(REMAP, remap, vf); > REGISTER_FILTER(REMOVEGRAIN,removegrain,vf); > REGISTER_FILTER(REMOVELOGO, removelogo, vf); > diff --git a/libavfilter/reinterlace.h b/libavfilter/reinterlace.h > new file mode 100644 > index 000..bb66f63 > --- /dev/null > +++ b/libavfilter/reinterlace.h > @@ -0,0 +1,141 @@ > +/* > + * Copyright (c) 2017 Vasile Toncu > + Copyright (c) 2017 Thomas Mundt > + * > + * This file is part of FFmpeg. > + * > + * FFmpeg is free software; you can redistribute it and/or > + * modify it under the terms of the GNU Lesser General Public > + * License as published by the Free Software Foundation; either > + * version 2.1 of the License, or (at your option) any later version. > + * > + * FFmpeg is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > + * Lesser General Public License for more details. > + * > + * You should have received a copy of the GNU Lesser General Public > + * License along with FFmpeg; if not, write to the Free Software > + * Foundation, Inc., 51 Fran
[FFmpeg-devel] [PATCH] reitnerlace - tinterlace-like filter under LGPL
Hello, there have been some discussions about tinterlace filter licensing. In the end, I was unable to contact all the authorship holders. The main author, one from MPlayer project, is Michael Zucchi. It is quite probably that the copyright is holden by the company that he worked for, Ximian, which no longer exists. It is less probably that I'll came up with the approval off all the parts involved in this deal. However, some of the later developers of tinterlace agreed to release the parts they wrote under LGPL. I mention here Thomas Mundt and Stefano Sabatini. This being said, I come up with a new filter - reinterlace - which implements all the tinterlace functionalities and adds a few more. The new filter is added to ffmpeg without --enable-gpl and/or --enable-nonfree. However, it these configure options are specified, the reinterlace will use ASM opts, imported from tinterlace. I've used support for 16bit depth video from the code written by Thomas Mundt. I added 2 new modes MERGE_BFF and MERGE_TFF. I've changed MODE_PAD, so it does not drop last frame from the input - tinterlace did so. In terms of performance, reinterlace gives basically the same fps as tinterlace does. Here is the patch thats adds the filter. If everything goes well with this patch, I'll add a new patch that changes current tinterlace with reinterlace. Thanks, -Vasile Toncu From 45010f4b4671edfe1318b84285d09dd28a882d63 Mon Sep 17 00:00:00 2001 From: Vasile Toncu Date: Mon, 12 Feb 2018 14:16:27 +0200 Subject: [PATCH] Added reitnerlace filter. --- libavfilter/Makefile | 1 + libavfilter/allfilters.c | 1 + libavfilter/reinterlace.h | 141 +++ libavfilter/vf_reinterlace.c | 773 ++ libavfilter/x86/Makefile | 1 + libavfilter/x86/vf_reinterlace_init.c | 101 + 6 files changed, 1018 insertions(+) create mode 100644 libavfilter/reinterlace.h create mode 100644 libavfilter/vf_reinterlace.c create mode 100644 libavfilter/x86/vf_reinterlace_init.c diff --git a/libavfilter/Makefile b/libavfilter/Makefile index 6a60836..c3095ba 100644 --- a/libavfilter/Makefile +++ b/libavfilter/Makefile @@ -286,6 +286,7 @@ OBJS-$(CONFIG_RANDOM_FILTER) += vf_random.o OBJS-$(CONFIG_READEIA608_FILTER) += vf_readeia608.o OBJS-$(CONFIG_READVITC_FILTER) += vf_readvitc.o OBJS-$(CONFIG_REALTIME_FILTER) += f_realtime.o +OBJS-$(CONFIG_REINTERLACE_FILTER) += vf_reinterlace.o OBJS-$(CONFIG_REMAP_FILTER) += vf_remap.o framesync.o OBJS-$(CONFIG_REMOVEGRAIN_FILTER) += vf_removegrain.o OBJS-$(CONFIG_REMOVELOGO_FILTER) += bbox.o lswsutils.o lavfutils.o vf_removelogo.o diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c index 9adb109..60fb9b5 100644 --- a/libavfilter/allfilters.c +++ b/libavfilter/allfilters.c @@ -295,6 +295,7 @@ static void register_all(void) REGISTER_FILTER(READEIA608, readeia608, vf); REGISTER_FILTER(READVITC, readvitc, vf); REGISTER_FILTER(REALTIME, realtime, vf); + REGISTER_FILTER(REINTERLACE, reinterlace, vf); REGISTER_FILTER(REMAP, remap, vf); REGISTER_FILTER(REMOVEGRAIN, removegrain, vf); REGISTER_FILTER(REMOVELOGO, removelogo, vf); diff --git a/libavfilter/reinterlace.h b/libavfilter/reinterlace.h new file mode 100644 index 000..bb66f63 --- /dev/null +++ b/libavfilter/reinterlace.h @@ -0,0 +1,141 @@ +/* + * Copyright (c) 2017 Vasile Toncu + Copyright (c) 2017 Thomas Mundt + * + * This file is part of FFmpeg. + * + * FFmpeg is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. + * + * FFmpeg is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with FFmpeg; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA + */ + +#include + +#include "avfilter.h" +#include "formats.h" +#include "internal.h" +#include "video.h" +#include "libavutil/avassert.h" +#include "libavutil/imgutils.h" +#include "libavutil/opt.h" +#include "libavutil/pixdesc.h" + +#include "libavutil/bswap.h" + +enum FilterMode { + MODE_MERGE, + MODE_DROP_EVEN, + MODE_DROP_ODD, + MODE_PAD, + MODE_INTERLEAVE_TOP, + MODE_INTERLEAVE_BOTTOM, + MODE_INTERLACE_X2, + MODE_MERGE_X2, + MODE_MERGE_TFF, + MODE_MERGE_BFF, + MODE_NB +}; + +enum FilterFlags { + FLAG_NOTHING =