Uploaded by Rainboom Dash
3840x2160 01:45.45 WEBM 26.21 MBInterested in advertising on Derpibooru? Click here for information!
Help fund the $15 daily operational cost of Derpibooru - support us financially!
Description
replaced original compressed ~10khz limited audio for higher quality
Tags
+-SH safe2197702 +-SH artist:deadlycomics61 +-SH edit174876 +-SH fluttershy261181 +-SH pinkie pie258403 +-SH twilight sparkle361107 +-SH earth pony514798 +-SH pegasus507452 +-SH pony1628138 +-SH g42053633 +-SH animated127547 +-SH big donut2 +-SH contemplating62 +-SH drums1468 +-SH duo178627 +-SH duo female33727 +-SH female1829118 +-SH future twilight1215 +-SH high res409233 +-SH mare758123 +-SH minecraft3284 +-SH mississippi6 +-SH music4673 +-SH musical instrument15442 +-SH san francisco75 +-SH sound17344 +-SH steven universe1730 +-SH thinking2689 +-SH webm26470
Loading...
Loading...
I thing I just had a
~~codegarsm!~~
happy response to that!, It’s a shame that optimization like this is not implemented in every video platform or in every camera for that matter! Only 2 seconds of footage from my phone camera weight 25 MB…If you really wanna see something impressive, I encoded it with x265 at similar bitrate and it’s a lot higher quality
https://derpibooru.org/images/2217811#comment_8832135
25mb with audio and video included
I’m still not sure how to make VP9 not use 235 I-frames on this FS contemplation video but eh… VP9 is waaaaaaaaaaaaay better than VP8 (most people use VP8 and it sucks ass… what’s really funny is if you feed it more bitrate a lot of times it’ll still cause pretty significant artifacting.. it’s actually kinda hard to achieve transparency with VP8 without feeding it massive amounts of bitrate) but it’s still kinda dumb sometimes… oh well
I counted and if I counted correctly there’s about 235 I-frames in this 105 second video… luckily VP9 I-frame compression is quite efficient, heh.. blows standard jpegs out of the water
Edited
I know I’m typing a lot of text but I just wanted to say I think VP9 was just being a dumbass when it said to do a new I-Frame EVERY time Fluttershy jumped
Also, even when I say min-keyint=1 with x264 it somehow doesn’t use nearly as many keyframes… VP9 is weird
video compression also has indirect motion estimation so even if it doesn’t see the actual motion it can still figure it out, just not as efficiently, I think..
It really doesn’t matter.. the video is still very high-quality and file size isn’t massive
@Xaekai
so, yeah, I did no encoding parameter optimization :/ Probably should have told it to wait like a second or two in-between keyframes
what I said wasn’t really accurate.. it doesn’t HAVE to be an I-Frame, in fact, x264 used a lot of P/B frames on the jumps.. BUT it didn’t know where the motion moved to so I assume it was a bad decision and that’s only because by default it has a limit of one new keyframe every 24 frames.. I know you can change minimum distance with VP9 but by default it must be set really low or not have one at all
I just did veryslow with Handbrake (which is the same as -deadline best with ffmpeg afaik) and no other parameters
This really isn’t that hard to encode since a lot of jumps are just a small portion of change in screen and it isn’t happening super rapidly.. it’s probably not even capturing where it moves to since that would require really high motion estimation ranges which I’m not sure are possible to change with VP9
Wait, if it doesn’t capture where it moves to it’d have to be an I-Frame, though.. hmm.. yeah, I’m confused… I actually think it can still capture the motion just not as accurately without higher ranges
edit: wow, I just looked and it’s actually encoding a new I-Frame per jump… lol, that’s amazing
Edited
thanks
I’m just glad everyone can enjoy the artists’ creations
Even so, this is so cool, you deserve more credit!
interframe compression>intraframe compression
0_o
I have no words to describe how amazed i am right now!, I had maded gifs with only a couple frames more heavy that 25 Mb! It’s like sorcery to me!
if you are referring to the 25mb limit, actually wasn’t hard
This was way more compressed >>2217811 (merged) the skippiness on that is really bugging me… they clearly didn’t render it properly as I think it was made in flash.. even ~25 fps video should not be this bad
or this (grimdark, grotesque) >>2237097 30 fps, lots of movement, moving sunburst background.. still wondering if I should have squeezed 3840 x 2160.. hmm.. main issue was nasty banding in a couple of areas.. might have been able to encode separately with higher bitrate on those specific parts and splice together with mkvtoolnix..
or this one >>2228000 or >>2246965 or the smile hd one… really, there’s a lot that were more compressed is my point, lol
Edited