Danbooru

How to upload ugoira, the new pixiv animation system

Posted under General

wrr said:

I have MKVmerge. but i dont understand what you mean by "in your PATH"

care to explain in detail?

Google how to add a directory to your path. The directory you want to add to it is wherever you installed mkvmerge; for me this is C:\Program Files (x86)\MKVToolNix but it might be slightly different for you.

Looks like redundant effort but here another userscript for extracting the zip: https://github.com/an-electric-sheep/userscripts/

I also have converter scripts for webm and gif. I noticed that .webm needs special treatment for the last frame if you want to loop them since MKV uses timecodes, it has no concept of a frame duration, just a point at time in which the frame should be displayed. Which means that the last frame get displayed, the video is done and then it immediately jumps back to the first frame when looping. Therefore the last frame needs to be shown twice with two different timecodes to get the same delay as the pixiv animation.
.gif does not suffer from this issue as it uses delays.

ElectricSheep said:

I noticed that .webm needs special treatment for the last frame if you want to loop them since MKV uses timecodes, it has no concept of a frame duration, just a point at time in which the frame should be displayed. Which means that the last frame get displayed, the video is done and then it immediately jumps back to the first frame when looping. Therefore the last frame needs to be shown twice with two different timecodes to get the same delay as the pixiv animation.

Thanks for pointing that out, I updated my script to fix that.

ElectricSheep said:

Looks like redundant effort but here another userscript for extracting the zip: https://github.com/an-electric-sheep/userscripts/

I also have converter scripts for webm and gif. I noticed that .webm needs special treatment for the last frame if you want to loop them since MKV uses timecodes, it has no concept of a frame duration, just a point at time in which the frame should be displayed. Which means that the last frame get displayed, the video is done and then it immediately jumps back to the first frame when looping. Therefore the last frame needs to be shown twice with two different timecodes to get the same delay as the pixiv animation.
.gif does not suffer from this issue as it uses delays.

I don't know anything about video, but I made a 1fps webm out of two images like so:
ffmpeg -f image2 -r 1 -i %d.png out.webm

The last frame displayed correctly in Firefox and Dragon Player, but not in Chrome and MPC-HC. VLC didn't play it at all. Maybe someone can test this in other browsers.

10half said:

On uploading a 6mb webm file with audio, received this message: "error: RuntimeError - video must not have audio channels". Is this a limitation, or a site policy?

I intentionally made audio not be allowed, since the purpose of adding webm support was as a replacement for other animation formats like gif, and those can't have sound. Danbooru isn't a video-sharing site like youtube so it didn't seem appropriate. And it wouldn't do to suddenly have people uploading full anime episodes or movies or something. (Also why I limited the duration of uploaded videos.)

The limitation can be removed if there's a legitimate reason for people to want to upload webms with sound, I just couldn't think of any.

Updated

I've been having fun with the whole webm thing, I thought about the sound aspect as well, and figured in the end that it is better to not have sound than have it. Along the same lines as you, the goal of the site is anime images and not full blown videos like a youtube. Enabling sound would likely be more of an opening up Pandora's Box. Not that I can't see novel uses for it, I think the potential misuse of it outweighs any real gains.

The only thing similar that we do currently have are music_videos, which the bulk are pure flash creations, though a few are actually videos (anime openings, etc) made into a flash format.

What's the current duration limit for webm uploads?

Toks said:

Here's a bookmarklet that does the first 4 steps (as soon as you click it your browser prompts you to download the zip):

javascript:window.location = pixiv.context.ugokuIllustFullscreenData.src;

I thank you from the bottom of my heart.
You did many people a great favour.

Is it possible to convert SMIL-animated SVG to GIF or APNG? Because SVG + unpacked images in my opinion is the best way to preserve those clips with original quality and timings for now. Here is a simple userscript for saving zip and svg:

// ==UserScript==
// @name        Ugoira backup
// @include     http://www.pixiv.net/member_illust.php*
// @grant       none
// @run-at      document-start
// ==/UserScript==

document.addEventListener('DOMContentLoaded', function(){

var frames = pixiv.context.ugokuIllustFullscreenData.frames,
    numFrames = frames.length,
    width = pixiv.context.illustSize[0],
    height = pixiv.context.illustSize[1];

var result = '<svg version="1.1" baseProfile="tiny" id="svg-root"\
  width="'+width+'" height="'+height+'" viewBox="0 0 '+width+' '+height+'"\
  xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">';

for(var i=0; i<=numFrames-1; i++) {
    result += '<image id="frame'+i+'"'+' width="'+width+'" height="'+height+'" '+' xlink:href="./'+frames[i].file+'" display="'+ ((i==0) ? 'inline' : 'none') +'">'+
        '<set id="show'+i+'" attributeName="display" to="inline" begin="'+((i==0)?'0s;':'')+'show'+((i+numFrames-1) % numFrames)+'.end" dur="'+(parseInt(frames[i].delay,10)/1000)+'s" fill="freeze"/>'+
        '<set id="hide'+i+'" attributeName="display" to="none"  begin="show'+i+'.end" dur="0.001s" fill="freeze"/>'+
        '</image>';
}
result +='</svg>';

$("._ugoku-illust-player-container").after(
    $("<a>", {
        href : 'data:image/svg+xml,'+result,
        text: 'Get ugoira .svg ' ,
        target:'_blank'
    })
);

$("._ugoku-illust-player-container").after(' | ');

$("._ugoku-illust-player-container").after(
    $("<a>", {
        href : pixiv.context.ugokuIllustFullscreenData.src,
        text: 'Get ugoira .zip '
    })
);

}, false);

upd: Added @run-at document-start to the userscript because some browsers default it to document-end.

Updated

Because SVG + unpacked images in my opinion is the best way to preserve those clips with original quality and timings for now.

In my opinion just downloading the .zip + the timing information in a text file is more convenient for programming purposes, the SVG doesn't really convey any additional information.

I would consider SVG+SMIL as one possible *output format* to preserve the originals. APNG can obviously do the same, but at the cost of increased footprint.

the SVG doesn't really convey any additional information.

Why do you need an additional information? It meant to be played like a video and it plays like one with proper timings and no overhead or loss like APNG or GIF and on any modern browser too (though I saw some of them having trouble with <img> tag for displaying SMIL SVGs instead of opening them in a separate tab).

It's very good for backup because you can't play ".zip + the timing information in a text file". And it is easily made into single-file format by Base64-encoding the images into xlink:href's using additional external processing (with userscript it's not a trivial task if possible at all).

Here is the single-file SVG demo: https://cdn.mediacru.sh/Fn0fq5fMM7nb.svg

Updated

Why do you need an additional information?

I never said I did. The point is that SVG is a quite verbose format. Not exactly a good intermediate storage format.

makes sense:
pixiv -(extraction script)-> zip + timing -(encoding script)-> output formats (apng, gif, webm, svg)
doesn't make sense:
pixiv -(extraction script)-> svg          -(encoding script)-> output formats

It's very good for backup because you can't play ".zip + the timing information in a text file".

You don't need to be able to play backups. Backups are cold storage.

You're confounding different use-cases here. A easy-to-handle intermediate processing/storage format vs. various output formats for presentation.

1 4 5 6 7 8 9 10