On Tue, May 21, 2024 at 9:50 AM Thilo Borgmann via ffmpeg-devel <ffmpeg-devel@ffmpeg.org> 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".
