So, I'm looking at the Ugoira format and wondering if it's better to use framerate 'averaging' fix that people use (but makes some frames longer/shorter than they should be), repeat frame (inflates file size, and not always accurate timing but better than previous), or variable-framerate streaming for importing into WEBM files for uploading. I think that the ffmpeg-based tools are normally just using something like method A. B I noticed works but is awful file sizes. C is technically better option but I think I need to implement my own parser to generate the files for input that multiplexers expect for specifying timing. NONE of the stuff I read seems to imply they use that method. Other people discussing ffmpeg said it's not really implemented for Ugoira (even though it 'works' in sense of creating a too-fast video) because they don't understand the text file it includes.
If I wrote a converter for the timing info, would anyone use it? I've been told that VFR video is not 100% compatible. :( An alternative is to post the nasty version and mirror of the ZIP file with JPGs+text file in description?
I included links to past topics for reference.
https://e621.net/posts/2005062#comment-6233233 Having a ZIP parser was considered a security risk on server end.
https://e621.net/forum_topics/22301 Ugoira support feature request
https://e621.net/forum_topics/14529 They require referrer to grab the ZIP, not some password but this was several years ago so maybe it changed.
https://github.com/altbdoor/py-ugoira This says it does this but needs to download every time even if you have the full ZIP (not just the images). Ugh, guess I'll be reading a lot soon. Gallery-dl already does something like this, as does Pixiv Toolkit, but all 3 of these seem to not work on already downloaded files.
:edited next night:
Ugoira database format is JSON. First field is "ugokuIllutData"
ugokuIllutData/src to ugokuIllutData/originalSrc fields are useless since we already have this JSON file.
ugokuIllutData/mime_type 'should' be "image/jpeg" but it is implied by file extensions.
ugokuIllutData/frames has the list of frames we want!
Each entry is ./file with filename, then ./delay with frame length.
This is a very simple format. :)
FFMPEG concat ( https://trac.ffmpeg.org/wiki/Concatenate https://trac.ffmpeg.org/wiki/Slideshow ) file I need is just this: filename on a line, followed by command
Example based on said linked pages:
file 'file00.jpg' duration 1 file 'file01.jpg' duration 2 file 'file02.jpg' duration 3 file 'file03.jpg' duration 4 file 'file03.jpg'
This just gets slower and slower with each new image, for a total run time of 1+2+3+4 = 10 seconds per loop. Yes, you MUST have the last file's name listed twice. It leads to a dropped frame if you don't due to technical reasons. This is good for slideshows. So what if we specified say, 0.048 seconds? BTW, they specify why sites require that color space mentioned in the list of supported formats for uploads in that second link.
https://trac.ffmpeg.org/ticket/6128 Hmm, looking at this, too. "Using the concat demuxer with images and specified duration directives produces wrong duration" Far more detailed test of the 'quirk' with last frame.
https://video.stackexchange.com/questions/7903/how-to-losslessly-encode-a-jpg-image-sequence-to-a-video-in-ffmpeg An interesting idea but I don't think outputted file complies with requirements for uploads. ;) That framehash trick alone is worth seeing, though. It can be used to verify lossless compression by applying it to multiple versions of the 'same' video. Use a "Diff" tool to compare the outputted text files, and any lossy frames should show up.
https://superuser.com/questions/1661901/encoding-video-from-vfr-still-images I think I read this months ago.
I'm currently working on finding differences between inpoint/outpoint/duration commands in that concat format. Documentation only showed duration examples? https://ffmpeg.org/ffmpeg-utils.html#time-duration-syntax seems to list formats of time accepted, at least. Ah, found it at https://ffmpeg.org/ffmpeg-formats.html#concat
Updated