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

Cosmin Stejerean cosmin at cosmin.at
Fri Aug 4 20:55:39 EEST 2023


On May 24, 2015 at 04:49PM, Michael Niedermayer wrote:
> On Sun, May 24, 2015 at 06:39:05PM -0300, James Almer wrote:
> > On 24/05/15 5:59 PM, Michael Niedermayer wrote:
> > > 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
> >
> > My intention was to keep it all as a single encoder, using one of the two APIs depending
> > on availability. If the AVOptions have different results on them then i guess it's not
> > really feasible after all. So patch dropped.
>
> I dont know if its (im)possible with the new API to support the
> stuff, just that it is not supported with the current
> wraper/implementation we have


There are still two encoders for animated webp, libwebp and libwebp_anim. Do we still need both? There was an attempt to combine these back in 2015 or so that was dropped at the time. 

At this point though WebPAnimEncoder has been around for years. Using libwebp_anim seems to be about 3x faster in my testing and produces smaller file sizes, and is selected by ffmpeg by default. New users may not realize that specifying `-c:v libwebp` is the inferior choice.

Can we revisit merging these two? I propose dropping the current libwebp and renaming (or aliasing) libwebp_anim to libwebp and dropping support for libwebpmux < 0.4.0. I can submit a patch if there is agreement.


- Cosmin




More information about the ffmpeg-devel mailing list