Posted under General
Only difference is that the intermediate case with zip + timings is absolutely useless. It's like making DVD backup to a magnetic tape storage: it can keep the data but in no way useful. In the end choosing from useless backups vs. useful backups makes the choice obvious for me. Don't know why you even try to argue. Is it just for the sake of it or do you have anything to say on the actual topic?
xoredwolf said:
Only difference is that the intermediate case with zip + timings is absolutely useless. It's like making DVD backup to a magnetic tape storage: it can keep the data but in no way useful. In the end choosing from useless backups vs. useful backups makes the choice obvious for me. Don't know why you even try to argue. Is it just for the sake of it or do you have anything to say on the actual topic?
zip + timings is the way pixiv stores them originally. Converting to svg is useless if you're not even going to use the svgs, it's simpler to keep the originals so you don't have the added complexity of converting twice instead of once.
ElectricSheep said:
But many tools, image viewers and websites can't handle it, so it has to be just one option among several.
I checked, all current browsers - desktop and mobile - can display SVG. See here: http://caniuse.com/svg
Schrobby said:
I checked, all current browsers - desktop and mobile - can display SVG. See here: http://caniuse.com/svg
But can they display it correctly?
I just viewed the example svg animation posted earlier in firefox 31. It looked horrible while it was loading because it inserted blank white frames as it buffered the next frame, giving a very choppy appearance.
It seems this problem doesn't affect chrome or opera. Although it wouldn't surprise me if they had some other issue I just haven't noticed in my brief testing.
Also, that's the wrong page. That's for regular svgs, not animations. This is the page for svg animations: http://caniuse.com/svg-smil
Updated
Toks said:
But can they display it correctly?
[..]
Also, that's the wrong page. That's for regular svgs, not animations. This is the page for svg animations: http://caniuse.com/svg-smil
Dunno. I guess it should be tested. The white frames are only during loading, once done it displays just fine.
Wrong page? Doh. Well, save IE and Opera Mini the result is basically the same.
Schrobby said:
I checked, all current browsers - desktop and mobile - can display SVG. See here: http://caniuse.com/svg
I said "websites", not "browsers". And browsers make terrible image viewers for things you have on the filesystem.
The best/easiest solution: converter
http://ugoira.dataprocessingclub.org/
Loc0 said:
The best/easiest solution: converter
http://ugoira.dataprocessingclub.org/
Seems to work pretty good in most cases. Trying to convert to webm sometimes doesn't do anything, but clicking submit multiple times usually fixes it.
Though I found one post it works poorly for - with pixiv #44663338 converted to webm there is very noticeable quality loss. Also, the file size for the webm is much larger than should be necessary (7097 KB, compare with the webm output of that post by my script which is only 387 KB). So far this is the only post I've found that is affected by these bugs.
Kadoya said:
Quick question: how do I fetch the source for these? Being overtly reliant on the bookmarklet and DBUP all this time kinda made me quite stupid on how to do it manually.
For the source (when I was uploading ugoira), I used this format: http://i1.pixiv.net/img01/img/(artist)/(id number), and yes you have to enter it manually. Example: http://i1.pixiv.net/img131/img/mizushina565/44390234.gif for post #1722827.
Question: From the converter, are we going save the webm to our hard disk first before we can upload here, would that result to a quality reduction?
Updated
The Toks script should set the encoding frame rate. The default of 25 is probably too high for many ugoira and may result in overly aggressive compression. Possible solutions are to base the frame rate on the longest frame duration, use 1fps for highest quality, or base the frame rate on the shortest frame duration and duplicate frames accordingly. Of course the last solution is pointless if it can't beat the other two in file size. I'm not certain 1fps is the lowest, but I haven't been able to figure out how to get it lower.
The other Ruby and Perl scripts don't explicitly handle variable frame rates either. Maybe the quality is considered acceptable, even if unintentionally so? I might as well ask what's the rational for 2 of the scripts choosing crf 4, the other crf 22, and none setting qmin & qmax?
One last thing. Is duplicating the last frame the definitive way to convert to webm? Should users who don't duplicate it be notified by PM?
*edit* Figured I'd say for the record, I'd suggest testing things out yourself. Setting a sky high bitrate worked better for me than 1 fps.
Updated
Dbx said:
The other Ruby and Perl scripts don't explicitly handle variable frame rates either.
Toks' and mine actually do set the actual VFR frame rate as a 2nd pass via mkvmerge.
The framerate in the ffmpeg encoding stage is not really important apart from encoding quality calculations, which can be tweaked based on any arbitrarily chosen framerate or a calculated average.
I might as well ask what's the rational for 2 of the scripts choosing crf 4, the other crf 22, and none setting qmin & qmax?
This is actually complicated. When targeting a specific file size then 2pass mode + a bitrate goal calculated from the length of the constant frame rate duration (not VFR since that's applied later) are the proper way to go and crf has very little impact while qmin/qmax already have a wide range letting the rate-controller choose properly.
For single-pass, quality-based encoding not targeting a specific file size it indeed does make a difference and 22 would probably be too high.
In my script the encoding options aren't all that sensible but they still produce "good enough" output anyway.
One last thing. Is duplicating the last frame the definitive way to convert to webm? Should users who don't duplicate it be notified by PM?
Webm is not designed for looping. It uses frame offsets. Points in time. There simply is no way to specify the duration of an individual frame. So the duplication is more of a workaround than something "official". You'd probably have to prod some web standards people to ask them what they think.
So I just came across these slidedecks from tech talks the Pixiv developers gave on how Ugoira works:
https://speakerdeck.com/harukasan/ugoku-backend is partly in English and talks about the server-side intrastructure. There are some interesting stats about Pixiv in here, like the fact that Pixiv runs on 400 (!) servers.
http://tototoshi.github.io/slides/ugoira-tech-talks-ugoku-gazou-henkan/ is in Japanese. Not sure what it's says.
https://marcan.st/talks/2014_pixiv_ugoku_player/ briefly talks about how their HTML5 zip player works. The really interesting bit is at the end: it turns out Pixiv actually released their player as open source! It's available at https://github.com/pixiv/zip_player. It looks like it would be pretty feasible to integrate this into Danbooru to give us native ugoira support.
ElectricSheep said:
Toks' and mine actually do set the actual VFR frame rate as a 2nd pass via mkvmerge.
The framerate in the ffmpeg encoding stage is not really important apart from encoding quality calculations, which can be tweaked based on any arbitrarily chosen framerate or a calculated average.
It might not have been clear, but I was indeed talking about frame rates for their effect on quality during encoding. One could at any point say his settings are "good enough," but I wondered if the choice of lowest crf meant the compromise on frame rate was unintentional.
