subject:"\[FFmpeg\-devel\] \[PATCH\] reitnerlace \- tinterlace\-like filter under LGPL"

Re: [FFmpeg-devel] [PATCH] reitnerlace - tinterlace-like filter under LGPL

2018-03-29 Thread Thomas Mundt

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

2018-03-29 Thread 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.

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

    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-14 Thread Thomas Mundt

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

2018-03-13 Thread 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

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-06 Thread Thomas Mundt

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

> 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-06 Thread Carl Eugen Hoyos

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

2018-03-06 Thread Thomas Mundt

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

2018-03-05 Thread Vasile Toncu


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

2018-03-05 Thread 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.

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

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

2018-03-05 Thread 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.
___
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 Thread Vasile Toncu


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,

Re: [FFmpeg-devel] [PATCH] reitnerlace - tinterlace-like filter under LGPL

2018-02-21 Thread Thomas Mundt

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
>

[FFmpeg-devel] [PATCH] reitnerlace - tinterlace-like filter under LGPL

2018-02-12 Thread 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.


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

Re: [FFmpeg-devel] [PATCH] reitnerlace - tinterlace-like filter under LGPL

Re: [FFmpeg-devel] [PATCH] reitnerlace - tinterlace-like filter under LGPL

Re: [FFmpeg-devel] [PATCH] reitnerlace - tinterlace-like filter under LGPL

Re: [FFmpeg-devel] [PATCH] reitnerlace - tinterlace-like filter under LGPL

Re: [FFmpeg-devel] [PATCH] reitnerlace - tinterlace-like filter under LGPL

Re: [FFmpeg-devel] [PATCH] reitnerlace - tinterlace-like filter under LGPL

Re: [FFmpeg-devel] [PATCH] reitnerlace - tinterlace-like filter under LGPL

Re: [FFmpeg-devel] [PATCH] reitnerlace - tinterlace-like filter under LGPL

Re: [FFmpeg-devel] [PATCH] reitnerlace - tinterlace-like filter under LGPL

Re: [FFmpeg-devel] [PATCH] reitnerlace - tinterlace-like filter under LGPL

Re: [FFmpeg-devel] [PATCH] reitnerlace - tinterlace-like filter under LGPL

Re: [FFmpeg-devel] [PATCH] reitnerlace - tinterlace-like filter under LGPL

Re: [FFmpeg-devel] [PATCH] reitnerlace - tinterlace-like filter under LGPL

Re: [FFmpeg-devel] [PATCH] reitnerlace - tinterlace-like filter under LGPL

Re: [FFmpeg-devel] [PATCH] reitnerlace - tinterlace-like filter under LGPL

[FFmpeg-devel] [PATCH] reitnerlace - tinterlace-like filter under LGPL

16 matches

Site Navigation

Mail list logo

Footer information