Viewing sample resized to 44% of original (view original) Loading...
Parent: post #298049 (learn more) show Β»
Description
Nerdy Talk

Converted with ffmpeg using these commands:

ffmpeg -y -hwaccel auto -i .\source.mp4 -c:v libvpx-vp9 -pix_fmt yuv420p -b:v 1700K -pass 1 -an -f webm NUL

& ffmpeg -y -hwaccel auto -i .\source.mp4 -c:v libvpx-vp9 -pix_fmt yuv420p -b:v 1700K -row-mt 1 -pass 2 -c:a libopus -b:a 128K .\output.webm

I would like to also note I used Swivel to convert the swf file into x264 High with 15Mb/s bitrate with AAC 258Kb/s bitrate. This is overkill but I wanted to make sure it was as close to lossless as possible for the conversion to webm. I think it turned out pretty well!

  • Comments
  • Sometimes I swear Zone can't be a single person, and that the real "Zone" is actually a cover for a loose collective of official artists producing adult parodies of their own work.

  • Reply
  • |
  • 16
  • neo987 said:
    Sometimes I swear Zone can't be a single person, and that the real "Zone" is actually a cover for a loose collective of official artists producing adult parodies of their own work.

    Hey! I've heard something similar about one writer. He was just this good, though.

  • Reply
  • |
  • 3
  • Converted with ffmpeg using these commands:

    ffmpeg -y -hwaccel auto -i .\source.mp4 -c:v libvpx-vp9 -pix_fmt yuv420p -b:v 1700K -pass 1 -an -f webm NUL

    & ffmpeg -y -hwaccel auto -i .\source.mp4 -c:v libvpx-vp9 -pix_fmt yuv420p -b:v 1700K -row-mt 1 -pass 2 -c:a libopus -b:a 128K .\output.webm

    I would like to also note I used Swivel to convert the swf file into x264 High with 15Mb/s bitrate with AAC 258Kb/s bitrate. This is overkill but I wanted to make sure it was as close to lossless as possible for the conversion to webm. I think it turned out pretty well!

    I'm still entirely unsure as to why you are using constant bitrate mode, there's literally no reason to! You aren't livestreaming the video, encoding isn't in a hurry to be done right now nor do you have the luxury of just cranking the bitrate to heaven. Constant quality mode, always, if filesize becomes a problem, then constrained quality mode.

    And now because of this, the encoder has hard cap as to what it can do, so you end up with some nasty artifacting on larger movements and scene changes which do not have keyframes in them:
    https://puu.sh/He5Nr/2ff3c824c8.jpg
    https://puu.sh/He5RT/2d05490275.mp4 (focus on softness on outlines and mushiness on background texture)
    And simple scenes with no movement are now eating up all of the available bitrate bandwidth for absolutely nothing. Given, most of these problems are over after 42ms and pick back up in couple frames so they are most likely ignored by most, but for someone who knows what video compression looks like, this looks terrible and hideous. If this was anime scene release I would delete the file and seek out for better encode from another group.

    Bitrate is only half of the story, 15mbps stream can look much worse from 10mbps and with Swivel, I think even 24mbps or """lossless""" bitrate settings were not good enough, they could be using some faster presets. Nvidia shadowplay I have to crank up to 50mbps for it to be useable. It would not surprise me of earlier problems were simply present from that initial render and they just came from that. It does support lossless AVI, so I do not see any reason not to use that (-c:v rawvideo as input option) as frames are actually perfect, instead of messing around with another lossy encoding in another format first.

    TL;DR: not up to my personal standards, 7/10.

  • Reply
  • |
  • 6
  • mairo said:
    I'm still entirely unsure as to why you are using constant bitrate mode, there's literally no reason to! You aren't livestreaming the video, encoding isn't in a hurry to be done right now nor do you have the luxury of just cranking the bitrate to heaven. Constant quality mode, always, if filesize becomes a problem, then constrained quality mode.

    And now because of this, the encoder has hard cap as to what it can do, so you end up with some nasty artifacting on larger movements and scene changes which do not have keyframes in them:
    https://puu.sh/He5Nr/2ff3c824c8.jpg
    https://puu.sh/He5RT/2d05490275.mp4 (focus on softness on outlines and mushiness on background texture)
    And simple scenes with no movement are now eating up all of the available bitrate bandwidth for absolutely nothing. Given, most of these problems are over after 42ms and pick back up in couple frames so they are most likely ignored by most, but for someone who knows what video compression looks like, this looks terrible and hideous. If this was anime scene release I would delete the file and seek out for better encode from another group.

    Bitrate is only half of the story, 15mbps stream can look much worse from 10mbps and with Swivel, I think even 24mbps or """lossless""" bitrate settings were not good enough, they could be using some faster presets. Nvidia shadowplay I have to crank up to 50mbps for it to be useable. It would not surprise me of earlier problems were simply present from that initial render and they just came from that. It does support lossless AVI, so I do not see any reason not to use that (-c:v rawvideo as input option) as frames are actually perfect, instead of messing around with another lossy encoding in another format first.

    TL;DR: not up to my personal standards, 7/10.

    The last several days have been me running with little sleep, so I more than likely didn't read stuff correctly (dyslexia doesn't help either.) But I agree with what you said, I honestly didn't know Constrained Quality Mode actually allocated bits differently compared to constant bitrate. I considered pushing VBR, but after reading on a presentation about WebM, and the difference between Constant Quality Mode, Variable Bitrate Mode, and then Constrained Quality Mode, it’s clear in how the encoding is done. They tested encoding over 50K ten-second video clips with all the modes and found that the Constrained Quality Mode brings better quality, and it's because variable bitrate tends to push bits into parts of the encode that is effectively invisible to the human eye, essentially making it wasted bits, while constrained quality doesn't, instead, saving those bits for something else. But, of course, you caught the reason why I leaned into constant bitrate, the file size. Had I been more open-minded to the modes, and tried constraining the quality first, the video could have turned out better with fewer artifacts, that was my fault, and me not doing enough research into the other modes didn't help. I more than likely overread material or information that would've helped me in the long run much faster.

    With that, I still want to preface that I'm learning, transcoding is still something that is new to me. I mostly program or draw, transcoding is something that I have taken an interest in as of late because I want to understand it, all of it. I wish the encode for this could've been better, especially with what I know now, but I'm going to take this information and use it for more tests before I come back with more conversions. Thanks for explaining flaws and issues within this upload, those artifacts aren't good at all, and I'm hoping to learn how to push the best quality possible without making those run rampant throughout the video. I'll try and do better next time, and that does include getting an uncompressed and truly lossless capture of the source material as well.

  • Reply
  • |
  • 1
  • what is this, it looks so professionnal, i mean, alot of solo artists make "professional looking stuff" but im just surprised of how, "canon" this looks, i dont know this cartoon but if this was some kind of secret episode the team worked on i wouldnt be surprised. it looks like this actually aired of late night tv

  • Reply
  • |
  • 6
  • Another classic Zone animation brought back from Flash!

    I recognize that bad guy's voice, the same VA did the voice for The Dark Lord Chuckles The Silly Piggy in Dave the Barbarian.

  • Reply
  • |
  • 1