PixivUtil2
PixivUtil2 copied to clipboard
Tell ffmpeg not to reset filter state for ugoira encode
Related to #1109 #1110
There's no need to explicitly re-encode each frame, as ffmpeg's option reinit_filter allows to ignore input frames' parameters inconsistency.
More info on Super User: https://superuser.com/questions/1465039/.
This PR removes check_image_encoding function and adds -reinit_filter 0 to ffmpeg's params.
Tested by gif encoding illustrations id 101814634 (which broke my own personal download scripts) and 91281700, 96990356 (from #1109)
@Toyem ping for comment?
I can check the commit tonight on the 3 major OS with a bunch of images I know are problematic but it looks much cleaner than what I coded. If everything works, it's a great improvement 👍
@Nandaka I've tested it with Linux (Ubuntu 22.04) and MacOS Catalina 10.15.7 and it's working perfectly fine, much faster and with the same result. I couldn't test it with Windows cause my hard drive decided to corrupt himself tonight but for what i can test, it's a perfectly fine improvement.
Wait ! i spoke too soon, i got an error when trying to download 101814634 as an apng. What's weird is that the apng file is here and perfectly fine but i still have an error, is it just me ? pixivutil.log
Sorry, my bad - I did not actually check for other output formats conversion.
It seems hqdn3d filter for apng conversion doesn't work properly with -reinit_filter 0.
I'll look into what I can do with this a bit later.
I found that the usage of hqdn3d filter was explained in https://github.com/Nandaka/PixivUtil2/issues/796#issuecomment-693232061, but I couldn't reproduce mentioned there "not all frame will be processed" problem - not with direct ffmpeg invocation at least. Is it still relevant? For 101814634, it also increases output apng size in almost three times.
Anyways, it seems that empty scale filter as the first one in the list just does the required job of converting all of the input frames into uniform pixel format to be used by the following filters.
Also, an irrelevant thing I found while testing 72165291 encode (from https://github.com/Nandaka/PixivUtil2/issues/796#issuecomment-693232061): ffmpeg may drop frames with the current encoding params (input 150 -> output 114).
Calculating correct input/output framerate or just dumbly passing -r 999 for output would probably fix it.
I tested it and it seems to work (still not tested on Windows, did not have time to reinstall the whole VM)
how could images from a zip have different color formats in https://github.com/Nandaka/PixivUtil2/issues/1109? I think it should avoid re-encoding to prevent quality loss.