The animation is awesome. The music is catchy, and fits the animation well.

I want to say I have some issues with the video encode - I think I'm seeing blocking artifacts from vp8/vp9 not getting enough bitrate, most notable on the reds, as it usually is.

A two-pass webm encode (At I'd guess CRF 18 or so) on a lossless source would look better than this, I expect.

To head off the avalanche of this question: What's the source for the music?
edit: I can read, honest! https://www.youtube.com/watch?v=AiJbA-81Pew

tredfg543 said:
The animation is awesome. The music is catchy, and fits the animation well.

I want to say I have some issues with the video encode - I think I'm seeing blocking artifacts from vp8/vp9 not getting enough bitrate, most notable on the reds, as it usually is.

A two-pass webm encode (At I'd guess CRF 18 or so) on a lossless source would look better than this, I expect.

To head off the avalanche of this question: What's the source for the music?

That's indeed a weird issue. I thought I had left enough of a bit-rate range to avoid artifacts, but it seems that something went ass up in the encoding process.

anonybold said:
That's indeed a weird issue. I thought I had left enough of a bit-rate range to avoid artifacts, but it seems that something went ass up in the encoding process.

In my experience, you're best off doing a 2-pass encode with constant quality, and just letting the encoder do it's thing. You can do a couple test encodes with various crf settings, and compare the results and filesizes.

https://trac.ffmpeg.org/wiki/Encode/VP9

further to this, feeding a lossless source into vp9 is *hugely* important. It does a much, much better job when it's not encoding mistakes from previous lossy encodings.

edit to the edit: 1300x2000 is also a very odd pixel dimension. Assuming you're able to render this at will from the original source, I'd suggest sticking to a "normal" display size and ratio. Closest real display size would be a rotated 16:10 1080p display, which is 1920x1200.

Suggested rendering and encoding resolutions, preserving this aspect ratio:
- 1200x1846 [Native 1:1 on a rotated 16:10 1080p monitor]
- 1080x1660 [Native 1:1 on a rotated conventional 1080p display]
- 1404x2160 [Native full-height playback on a landscape UHD display]

I feel like I'm watching an Indian Metalocalypse. I say Indian because of the music.

Mmmmmmnah

tredfg543 said:
edit to the edit: 1300x2000 is also a very odd pixel dimension. Assuming you're able to render this at will from the original source, I'd suggest sticking to a "normal" display size and ratio. Closest real display size would be a rotated 16:10 1080p display, which is 1920x1200.

Suggested rendering and encoding resolutions, preserving this aspect ratio:
- 1200x1846 [Native 1:1 on a rotated 16:10 1080p monitor]
- 1080x1660 [Native 1:1 on a rotated conventional 1080p display]
- 1404x2160 [Native full-height playback on a landscape UHD display]

This isn't really necessary, as long as the dimension can be divided by 2, it should work absolutely fine. For some reason libvpx does allow encoding with odd numbered resolutions, but you get all kinds of weird issues with many things, where x264 full on stops the encode immidiately.
Of course if it's vectors or 3D renders then yeah, sticking to common display resolutions is good idea and does boost visual fidelity in cases where othervice the player would've needed to upscale, but not necessary and the primary point is that if you already have bitmaps, scaling those in rende up or down should be avoided unless you know what you are doing. Resolution is like framerate, higher is technically better, but depending on many factors it might not be what you want.