Re: [FFmpeg-devel] [PATCH v12 0/8] [WIP] webp: add support for animated WebP decoding
On Tue, May 21, 2024 at 9:50 AM Thilo Borgmann via ffmpeg-devel wrote: > > Hi, > > [...] > >>> 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. > > I could fix 488x488.webp and have an almost identical output to libwebp. > > 488x488.webp features an ARGB canvas and has both, ARGB & YUVA420P > p-frames. > > Do you have more files with other variations of canvas & p-frames? If > they at all exist... e.g. canvas YUV and p-frames RGB? > Sent a few created with `gif2webp -mixed` off list. A more exhaustive set can be created using cwebp and webpmux to assemble them. > Pinged Meta as well for real-world samples. Will take some more days > until I get feedback. Will then post the next iteration... > > 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-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v12 0/8] [WIP] webp: add support for animated WebP decoding
Hi, [...] 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. I could fix 488x488.webp and have an almost identical output to libwebp. 488x488.webp features an ARGB canvas and has both, ARGB & YUVA420P p-frames. Do you have more files with other variations of canvas & p-frames? If they at all exist... e.g. canvas YUV and p-frames RGB? Pinged Meta as well for real-world samples. Will take some more days until I get feedback. Will then post the next iteration... 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-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v12 0/8] [WIP] webp: add support for animated WebP decoding
On Thu, Apr 18, 2024 at 11:21 AM Thilo Borgmann via ffmpeg-devel 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 > > wrote: > >> > >> From: Thilo Borgmann > >> > >> 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 > 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-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v12 0/8] [WIP] webp: add support for animated WebP decoding
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 wrote: From: Thilo Borgmann 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 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 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v12 0/8] [WIP] webp: add support for animated WebP decoding
On Wed, Apr 17, 2024 at 12:20 PM Thilo Borgmann via ffmpeg-devel wrote: > > From: Thilo Borgmann > > 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-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v12 0/8] [WIP] webp: add support for animated WebP decoding
From: Thilo Borgmann 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 -- 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-requ...@ffmpeg.org with subject "unsubscribe".