[FFmpeg-devel] [RFC][PATCH] libwebp: combine libwebp_anim and libwebp encoders into one

[Michael Niedermayer]

On Sun, May 24, 2015 at 04:22:42PM -0300, James Almer wrote:
> Use either the WebPEncoder or WebPAnimEncoder APIs depending on availability
> of the latter.
> 
> Signed-off-by: James Almer <jamrial at gmail.com>
> ---
> This is an RFC because the resulting encoder will use one of the two APIs, which
> is a change from the current behavior of having one encoder for each API.
> The new encoder was added only two days ago so removing it shouldn't be an issue.
> Basically, is there any benefit from using the native lavf muxer over letting
> WebPAnimEncoder do the entire process to justify having two encoders?
> 
> The resulting ifdeffery is minimal now that the webp muxer can act as a raw muxer
> cleanly, so the only concern is the above. We can deal with cosmetics later, but
> the functional change needs to be done asap least we want to deal with deprecation
> nonsense if the new encoder makes it into a release.

They are 2 different encoders, the old is partly implemented in
FFmpeg, the new does all steps in an external lib
The 2 variants work differently
command lines for the old encoder do NOT work with WebPAnimEncoder,
at least not with the current implementation we have

try it yourself
./ffmpeg -i matrixbench_mpeg2.mpg -cr_threshold 10000 -cr_size 16 -t 10 -loop 2 -vcodec libwebp test.webp

works with the old encoder but after this patch produces a video
that is a flickering checkerboard

Also libwebp lacks a maintainer in MAINTAINERs
anyone volunteers ?

I might be willing to maintain it when the 2 encoders can be tested
without the need to build ffmpeg twice (they can be in one .c file for
that or in multiple of course),
I know from the xcb/x11 alternative that i practically never bother
to test both variants when i would have to build teh code twice.
So if that becomes needed then someone else should maintain it

Of course even if both can be build at the same time, i would still
be happy if someone else, maybe you ? does the maintaince

Thanks

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No snowflake in an avalanche ever feels responsible. -- Voltaire
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20150524/984a53ed/attachment.asc>