Maybe it's time for Danbooru to support video formats. Gif is too limited compared to ugoira, and apng is too large compared to an ugoira made of jpegs. Not to mention the lack of apng support.
Somehow, supporting video feels real yucky to me, but that sort of resistance to video is probably what spurred the creation of ugoira in the first place... I don't suppose anyone would advocate adding support for displaying native ugoira.
Between gif, apng, ugoira, and some video format, video seems like the best choice to me.
For the record, I've been writing a ruby script to convert these, here (currently only gif is supported as output). And there has been discussion on it here.
Ooooooh~ shiny! Is there a chance this will be integrated into danbooru? It'd be perfect if you can just upload Ugoira like usual and have them autoconverted to APNG.
Ooooooh~ shiny! Is there a chance this will be integrated into danbooru? It'd be perfect if you can just upload Ugoira like usual and have them autoconverted to APNG.
Your script assumes the delay is the same for all frames, so it won't work right if each frame has a different delay.
gifs round the delays down to the centisecond, so ugoira with delays exact to the millisecond won't be the correct speed if gif is chosen as output.
For some posts, the webm and mp4 ones seem extremely sped up to me. I assume that you're just passing the frames as-is without slowing it down, meaning it will display each image for exactly one frame - way too quick (unless the delay happened to be small to begin with).
Converting to mp4 will fail with "height not divisible by 2" if the images have an odd number height.
For the record, I've been writing a ruby script to convert these, here (currently only gif is supported as output). And there has been discussion on it here.
I could possibly fix that for gifs, but not for apng or any of the other formats as they all assume a constant frame rate. I may fix gifs later today.
Ooooooh~ shiny! Is there a chance this will be integrated into danbooru? It'd be perfect if you can just upload Ugoira like usual and have them autoconverted to APNG.
Integrating it with Danbooru is being discussed in the issue I linked. Not definite yet though.
CureGecko said:
I could possibly fix that for gifs, but not for apng or any of the other formats as they all assume a constant frame rate. I may fix gifs later today.
That's not true for apng. They support different delays for each frame.
As for webm/mp4...
Schrobby said:
Is it possible to set a low framerate and display the frames that should appear longer multiple times?
That's what I was thinking too. Find the greatest common factor among the frame delays and then duplicate each frame by (frame_delay/GCF) times.
Well, maybe it would be reasonable to build .swf files from .jpgs? Swf format is already supported by danbooru, size difference from ugoiras should be marginal, and there seem to be tools allowing to build swf using ruby (https://rubygems.org/gems/ming-ruby), but I'm "a little" unfamiliar with swf format and its capabilities regarding showing a series of images with varying delays.
Both MP4 and WebM support variable frame rate (in fact just about any container format does except for AVI), they can show each frame for a different duration, so they would be capable of displaying ugoira at the original speeds without any need to duplicate frames or other hacks.
I'm not aware of any authoring tools that can set timecodes for individual frames like that, though.
Webm duplicating frames with the gcf method: 409kb
Gif produced by my ruby script: 1.39mb
Original zip size: 1.3mb
So the gcf thing does increase file size compared to not using it, but I don't think this will be a big issue since both of the webms combined are still smaller than the alternatives - including the original ugoira.
Both MP4 and WebM support variable frame rate (in fact just about any container format does except for AVI), they can show each frame for a different duration, so they would be capable of displaying ugoira at the original speeds without any need to duplicate frames or other hacks.
I'm not aware of any authoring tools that can set timecodes for individual frames like that, though.
How does one go about setting variable frame rates then? My google-fu is too weak it seems.
How does one go about setting variable frame rates then? My google-fu is too weak it seems.
One relatively simple way would be using mkvmerge to make the webm with an external timecode file. That way you can specify the timecode for each frame.
I will have to research apng, and as for mp4/webm I was thinking setting to 30fps and then making links to each frame to duplicate the correct amount in order to reach the correct number of frames for the delay. Since MP4/WEBM is great at compressing, it shouldn't be a big deal as it will see that they are the same and only make effectively 1 frame worth of data.
One relatively simple way would be using mkvmerge to make the webm with an external timecode file. That way you can specify the timecode for each frame.
where the timecodes.tc looks like
Is WEBM a MKV format? If so, timecode would be best. I could also instead of outputting MP4 for H264, output MKV...
Yeah, it's a Matroska file with extremely limited options regarding video and audio content and other stuff.
You need a recent enough MKV toolkit to generate webms. At least my mkvmerge (6.7.0) autodetects webm file suffixes and adjusts the output format appropriately.
You need a recent enough MKV toolkit to generate webms. At least my mkvmerge (6.7.0) autodetects webm file suffixes and adjusts the output format appropriately.
