From: Cosmin Stejerean <cosmin@cosmin.at>
To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Subject: Re: [FFmpeg-devel] [RFC][PATCH] libwebp: combine libwebp_anim and libwebp encoders into one
Date: Fri, 4 Aug 2023 17:55:39 +0000
Message-ID: <01010189c1b0d771-8340f30c-53d7-443f-98ee-14c6aec4c981-000000@us-west-2.amazonses.com> (raw)
In-Reply-To: <870DEC0E-C94E-4432-88CB-E0E4F6A7162E@cosmin.at>
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
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
parent reply other threads:[~2023-08-04 17:55 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <870DEC0E-C94E-4432-88CB-E0E4F6A7162E@cosmin.at>]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=01010189c1b0d771-8340f30c-53d7-443f-98ee-14c6aec4c981-000000@us-west-2.amazonses.com \
--to=cosmin@cosmin.at \
--cc=ffmpeg-devel@ffmpeg.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
This inbox may be cloned and mirrored by anyone:
git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git
# If you have public-inbox 1.1+ installed, you may
# initialize and index your mirror using the following commands:
public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \
ffmpegdev@gitmailbox.com
public-inbox-index ffmpegdev
Example config snippet for mirrors.
AGPL code for this site: git clone https://public-inbox.org/public-inbox.git