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.borgm...@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-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".