Re: [FFmpeg-devel] [PATCH v12 0/8] [WIP] webp: add support for animated WebP decoding

[James Zern via ffmpeg-devel <ffmpeg-devel@ffmpeg.org>]

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".
_______________________________________________
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".