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