| Message ID | 20240417192012.22436-1-thilo.borgmann@mail.de |
|---|---|
| Headers | show |
| Series | webp: add support for animated WebP decoding | expand |
On Wed, Apr 17, 2024 at 12:20 PM Thilo Borgmann via ffmpeg-devel <ffmpeg-devel@ffmpeg.org> wrote: > > From: Thilo Borgmann <thilo.borgmann@mail.de> > > Marked WIP because we'd want to introduce private bsf's first; review > welcome before that though > VP8 decoder decoupled again > The whole animated sequence goes into one packet > The (currently public) bitstream filter splits animations up into non-conformant packets > Now with XMP metadata support (as string, like MOV) > Tests mostly work for me. There are a few images (that I reported earlier) that give: Canvas change detected. The output will be damaged. Use -threads 1 to try decoding with best effort. They don't animate without that option and with it render incorrectly. A few other notes: - should ffprobe report anything with files containing xmp? - 0 duration behaves differently than web browsers, which use the gif behavior and set it to 10; as long as it's consistent in ffmpeg between the two either is fine to me. - The files in https://crbug.com/690848 don't exit cleanly from ffplay, other corrupt files do; ffmpeg exits, so maybe it's a non-issue. > > Patch 5/8 is still there for making changes in lavc/webp reviewable but shall be stashed when pushing. > > -Thilo > > Josef Zlomek (2): > libavcodec/webp: add support for animated WebP > libavformat/webp: add WebP demuxer > > Thilo Borgmann via ffmpeg-devel (6): > avcodec/webp: remove unused definitions > avcodec/webp: separate VP8 decoding > avcodec/bsf: Add awebp2webp bitstream filter > avcodec/webp: make init_canvas_frame static > fate: add test for animated WebP > avcodec/webp: export XMP metadata > > Changelog | 2 + > configure | 1 + > doc/demuxers.texi | 28 + > libavcodec/bitstream_filters.c | 1 + > libavcodec/bsf/Makefile | 1 + > libavcodec/bsf/awebp2webp.c | 350 ++++++++ > libavcodec/codec_desc.c | 3 +- > libavcodec/version.h | 2 +- > libavcodec/webp.c | 796 ++++++++++++++++-- > libavformat/Makefile | 1 + > libavformat/allformats.c | 1 + > libavformat/version.h | 2 +- > libavformat/webpdec.c | 383 +++++++++ > tests/fate/image.mak | 3 + > tests/ref/fate/exif-image-webp | 4 +- > tests/ref/fate/webp-anim | 22 + > tests/ref/fate/webp-rgb-lena-lossless | 2 +- > tests/ref/fate/webp-rgb-lena-lossless-rgb24 | 2 +- > tests/ref/fate/webp-rgb-lossless | 2 +- > .../fate/webp-rgb-lossless-palette-predictor | 2 +- > tests/ref/fate/webp-rgb-lossy-q80 | 2 +- > tests/ref/fate/webp-rgba-lossless | 2 +- > tests/ref/fate/webp-rgba-lossy-q80 | 2 +- > 23 files changed, 1530 insertions(+), 84 deletions(-) > create mode 100644 libavcodec/bsf/awebp2webp.c > create mode 100644 libavformat/webpdec.c > create mode 100644 tests/ref/fate/webp-anim > > -- > 2.43.0 > > _______________________________________________ > 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".
Hi, On 17.04.24 00:52, James Zern via ffmpeg-devel wrote: > On Wed, Apr 17, 2024 at 12:20 PM Thilo Borgmann via ffmpeg-devel > <ffmpeg-devel@ffmpeg.org> wrote: >> >> From: Thilo Borgmann <thilo.borgmann@mail.de> >> >> Marked WIP because we'd want to introduce private bsf's first; review >> welcome before that though >> VP8 decoder decoupled again >> The whole animated sequence goes into one packet >> The (currently public) bitstream filter splits animations up into non-conformant packets >> Now with XMP metadata support (as string, like MOV) >> > > Tests mostly work for me. There are a few images (that I reported > earlier) that give: thanks for testing! > Canvas change detected. The output will be damaged. Use -threads 1 > to try decoding with best effort. > They don't animate without that option and with it render incorrectly. That issue yields from the canvas frame being the synchronization object (ThreadFrame) - doing so prevents the canvas size changed mid-stream. _Maybe_ this can be fixed switching the whole frame multithreading away from ThreadFrame to sth else, not sure though and no experience with the alternatives (AVExecutor?). Maybe Andreas can predict if it's worth/valid to change that whole part of it? I'm not against putting more effort into it to get it right. > A few other notes: > - should ffprobe report anything with files containing xmp? It does, it is put into the frame metadata as a blob. ./ffprobe -show_frames <file> will reveal it. > - 0 duration behaves differently than web browsers, which use the gif > behavior and set it to 10; as long as it's consistent in ffmpeg > between the two either is fine to me. We are consistent to GIF in ffmpeg. Both do assume 100ms default delay. Notice the defaults in their defines (ms for webp, fps for gif) in the demuxers: #define WEBP_DEFAULT_DELAY 100 #define GIF_DEFAULT_DELAY 10 > - The files in https://crbug.com/690848 don't exit cleanly from > ffplay, other corrupt files do; ffmpeg exits, so maybe it's a > non-issue. ffplay always crashes after any file on osx for me. If ffmpeg terminates fine, it's a non-issue for that patchset. I'll however look into it once I can, I hear people saying their ffplay not always crashes... Thanks! -Thilo
On Thu, Apr 18, 2024 at 11:21 AM Thilo Borgmann via ffmpeg-devel <ffmpeg-devel@ffmpeg.org> wrote: > > Hi, > > On 17.04.24 00:52, James Zern via ffmpeg-devel wrote: > > On Wed, Apr 17, 2024 at 12:20 PM Thilo Borgmann via ffmpeg-devel > > <ffmpeg-devel@ffmpeg.org> wrote: > >> > >> From: Thilo Borgmann <thilo.borgmann@mail.de> > >> > >> Marked WIP because we'd want to introduce private bsf's first; review > >> welcome before that though > >> VP8 decoder decoupled again > >> The whole animated sequence goes into one packet > >> The (currently public) bitstream filter splits animations up into non-conformant packets > >> Now with XMP metadata support (as string, like MOV) > >> > > > > Tests mostly work for me. There are a few images (that I reported > > earlier) that give: > > thanks for testing! > > > > Canvas change detected. The output will be damaged. Use -threads 1 > > to try decoding with best effort. > > They don't animate without that option and with it render incorrectly. > > That issue yields from the canvas frame being the synchronization object > (ThreadFrame) - doing so prevents the canvas size changed mid-stream. > _Maybe_ this can be fixed switching the whole frame multithreading away > from ThreadFrame to sth else, not sure though and no experience with the > alternatives (AVExecutor?). Maybe Andreas can predict if it's > worth/valid to change that whole part of it? I'm not against putting > more effort into it to get it right. > > > > A few other notes: > > - should ffprobe report anything with files containing xmp? > > It does, it is put into the frame metadata as a blob. > ./ffprobe -show_frames <file> > will reveal it. > Thanks. I didn't try that option. > > > - 0 duration behaves differently than web browsers, which use the gif > > behavior and set it to 10; as long as it's consistent in ffmpeg > > between the two either is fine to me. > > We are consistent to GIF in ffmpeg. Both do assume 100ms default delay. > Notice the defaults in their defines (ms for webp, fps for gif) in the > demuxers: > > #define WEBP_DEFAULT_DELAY 100 > #define GIF_DEFAULT_DELAY 10 > It doesn't seem the default delay is getting applied to this file: http://littlesvr.ca/apng/images/SteamEngine.webp Or at least the rendering is off in ffplay. The duration of all frames are 0 in that file. > > > > - The files in https://crbug.com/690848 don't exit cleanly from > > ffplay, other corrupt files do; ffmpeg exits, so maybe it's a > > non-issue. > > ffplay always crashes after any file on osx for me. If ffmpeg terminates > fine, it's a non-issue for that patchset. I'll however look into it once > I can, I hear people saying their ffplay not always crashes... > > Thanks! > -Thilo > _______________________________________________ > 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".
From: Thilo Borgmann <thilo.borgmann@mail.de> Marked WIP because we'd want to introduce private bsf's first; review welcome before that though VP8 decoder decoupled again The whole animated sequence goes into one packet The (currently public) bitstream filter splits animations up into non-conformant packets Now with XMP metadata support (as string, like MOV) Patch 5/8 is still there for making changes in lavc/webp reviewable but shall be stashed when pushing. -Thilo Josef Zlomek (2): libavcodec/webp: add support for animated WebP libavformat/webp: add WebP demuxer Thilo Borgmann via ffmpeg-devel (6): avcodec/webp: remove unused definitions avcodec/webp: separate VP8 decoding avcodec/bsf: Add awebp2webp bitstream filter avcodec/webp: make init_canvas_frame static fate: add test for animated WebP avcodec/webp: export XMP metadata Changelog | 2 + configure | 1 + doc/demuxers.texi | 28 + libavcodec/bitstream_filters.c | 1 + libavcodec/bsf/Makefile | 1 + libavcodec/bsf/awebp2webp.c | 350 ++++++++ libavcodec/codec_desc.c | 3 +- libavcodec/version.h | 2 +- libavcodec/webp.c | 796 ++++++++++++++++-- libavformat/Makefile | 1 + libavformat/allformats.c | 1 + libavformat/version.h | 2 +- libavformat/webpdec.c | 383 +++++++++ tests/fate/image.mak | 3 + tests/ref/fate/exif-image-webp | 4 +- tests/ref/fate/webp-anim | 22 + tests/ref/fate/webp-rgb-lena-lossless | 2 +- tests/ref/fate/webp-rgb-lena-lossless-rgb24 | 2 +- tests/ref/fate/webp-rgb-lossless | 2 +- .../fate/webp-rgb-lossless-palette-predictor | 2 +- tests/ref/fate/webp-rgb-lossy-q80 | 2 +- tests/ref/fate/webp-rgba-lossless | 2 +- tests/ref/fate/webp-rgba-lossy-q80 | 2 +- 23 files changed, 1530 insertions(+), 84 deletions(-) create mode 100644 libavcodec/bsf/awebp2webp.c create mode 100644 libavformat/webpdec.c create mode 100644 tests/ref/fate/webp-anim