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

[Thilo Borgmann via ffmpeg-devel <ffmpeg-devel@ffmpeg.org>]

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