On 14.03.2018 18:56, Thomas Mundt wrote:
2018-03-13 16:10 GMT+01:00 Vasile Toncu <vasile.to...@tremend.com>:
On 06.03.2018 20:38, Thomas Mundt wrote:
Hi,
2018-03-05 13:48 GMT+01:00 Carl Eugen Hoyos <ceffm...@gmail.com>:
2018-03-05 12:37 GMT+01:00, Paul B Mahol <one...@gmail.com>:
On 3/5/18, Vasile Toncu <vasile.to...@tremend.com> wrote:
Hello,
Thanks for the review. I've made changes according to your guidance.
It would be great to know if the community will go on with our
intention
of adding reinterlace as a alternative for tinterlace.
That being said, here is the new patch.
As already said, this is not acceptable.
There is no point in having 2 filters with near same funcionality.
If you consider the new filter ok, the existing filter will be removed
in the same push. I believe sending only the new filter makes
reviewing easier.
For me reviewing would be easier when Vasile sends a patchset that
includes
the replacement of tinterlace filter.
That way existing fate tests could be used which are fortunately pretty
extensive in this case.
Also it would be helpful when you and/or other experienced ffmpeg
developers would clarify first which parts of tinterlace have to be
rewritten for proper relicensing.
Being left in the dark makes working on patches frustrating.
Another question is how to deal with vf_interlace? IMHO for the user there
should be no difference in output, speed and license.
Two options:
1. Relicensing and slice threading will also be ported to vf_interlace
2. The commands from vf_interlace will be included in the new tinterlace
filter. vf_interlace will be deleted together with old tinterlace filter
I would prefer the second option, but maybe there are even better options
that don´t come to my mind.
Please comment.
Thanks,
Thomas
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Hello everyone,
sorry for a delayed response.
From what has been discussed in here, I think the reinterlace will exist
with tinterlace for a period of time, just after that the tinterlace can be
removed.
To have the reinterlace added, what is needed to be done from my side?
Thanks,
Vasile Toncu
Two filters with almost the same functionality won´t be accepted, as Paul
stated in this thread.
Also there is vf_interlace filter, which is a subset of vf_tinterlace and
should not differ in speed, output and license. As already said, I would
prefer to include vf_interlace options into vf_tinterlace and remove
vf_interlace.
Also you want several changes: Making tinterlace filter LGPL, adding new
options and adding slice threading.
This should be done in a patch set:
Patch 1/5: Include vf_interlace options into vf_tinterlace filter and
remove vf_interlace
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
