10-bit precision VP9 encoding thread

for %%f IN (*.mp4, *.mkv, *.y4m) do (
ffmpeg -i "%%f" -pass 1 -y -vf scale=-1:540 -c:v libvpx-vp9 -profile:v 2 -pix_fmt yuv420p10le -lag-in-frames 25 -auto-alt-ref 1 -g 300 -b:v 800k -row-mt 1 -threads 4 -speed 1 -tile-columns 1 -tile-rows 1 -an -pass 1 -f webm nul
ffmpeg -i "%%f" -pass 2 -y -vf scale=-1:540 -c:v libvpx-vp9 -profile:v 2 -pix_fmt yuv420p10le -lag-in-frames 25 -auto-alt-ref 1 -g 300 -b:v 800k -row-mt 1 -threads 4 -speed 1 -tile-columns 1 -tile-rows 1 -an -pass 2 "%%~nf_out.webm"
)

-vf scale=-1:540 Changes output resolution while maintaining aspect ratio, should be 50% of source res (ie 540 for 1080p and 360 for 720p). If source is ~480p, remove param.
-profile:v 2 -pix_fmt yuv420p10le Enforces 10-bit internal encoder precision, ~20% better compression and reduces color banding for HQ 720p/1080p sources (ie at least ~10Mbps)
-lag-in-frames 25 Number of frames checked ahead for interframe compression. 25 is max and recommended with alt ref frames.
-auto-alt-ref 1 Range 0-6. Closest thing to mpeg-la (tm) b-frames, higher = better compression but only for low motion content (ie anime).
_-g 300_ Keyframe interval. Lower interval = better seeking for the user but worse compression. Diminishing returns after 200-300.
_-an_ Removes audio, replace with opus params to include audio.


-b:v 800k Bitrate. For 3MB limit: ~400k for 60 sec, ~800k for 30 sec...
-row-mt 1 Enables better multi-threaded encoding, requires at least 1 for columns/rows.
-threads 4 How many CPU threads used. Diminishing returns after 4.
-speed 1 Range 0-4. Higher = faster encoding FPS but lower quality.
-tile-columns 1 -tile-rows 1 How many squares the video is split up for multi-threaded encoding. ~480p output res doesn't benefit from a value higher than 1 for both.

Attached: GUESS_WHAT_DAY_IT_IS.webm (960x540, 2.96M)

Other urls found in this thread:

x264.nl/x264/10bit_02-ateme-why_does_10bit_save_bandwidth.pdf
twitter.com/NSFWRedditVideo

hevc is better

Nope, VP9's alt ref frames are actually impressively on par with HEVC's b-frames (tm) (r).

Holy shit I can see the CIA headquarters. VP9 is the best!

In regards to editing video: if you can't into ___-vf___ then try avidemux. Just make sure to save the output as CRF 0 x264 to avoid damage from lossy encoding.

>-b:v
You're supposed to use -crf

CRF doesn't target file sizes. Which are freakishly small here so it's hard to use too much bandwidth.

Skill issue, CBR wastes bits.

That's what 2-pass is for. Else alt ref frames would fail (thanks google).

Happy 9/11, amerimutts

Why not constrained quality? Use both crf and b:v so that it tries to aim for the set rate factor while sticking close to the set bitrate.

Because target bitrate changes with file size/duration and better bitrate control without CRF. AFAIK you can actually eek out higher video quality by doing a CRF encode and using the average bitrate from that to perform a 2-pass.

If I had 2 more brain cells I would probably be able to figure out some params to automatically assign a proper bitrate for a given file size and then you'd just have 1 script for 3MB target and another for 6MB target. Alas

Attached: 179.gif (989x1186, 1.31M)

whoops forgot to VP9 that gif. I wonder if the transparency will transfer over...

Attached: 179_out.webm (989x1186, 103.46K)

fug

Attached: fug.png (1886x873, 222.71K)

>AFAIK you can actually eek out higher video quality by doing a CRF encode and using the average bitrate from that to perform a 2-pass.
That's exactly what I was doing with VP8 videos, it only took seconds to re-do the whole thing if I fucked up and made a file too big. And yeah, on action-paced videos the difference in quality was quite noticeable compared to just setting the bitrate, but vp9 just takes too fucking long to encode stuff. I also made a script (just took most of the code from there and some threads on Any Forums webm threads).
-pix_fmt yuva420p10le should work, testin

Forgot webm

Attached: output-19-20-37.webm (640x480, 497.98K)

I guess not. test2

Attached: output-19-23-18.webm (640x480, 840.31K)

explain to a brainlet like me on how does 10-bit videos can be smaller than 8-bit

i still cant understand what this means:

x264.nl/x264/10bit_02-ateme-why_does_10bit_save_bandwidth.pdf

God fucking damnit, you still have ommit profile, disable alt ref, AND drop back down to 8-bit for alpha. I honestly had a shred of hope google would have fixed that after VP8.

Attached: 179_out.webm (989x1186, 165.2K)

4chinks disabled video alpha....
Of course, of course.

going with this logic, why not just make 64+++bit videos then?

is there any kikery going on here?

inb4 take meds

idk man doesn't look like that was enough to bring the whole building down

In simple terms lossy encoding destroys details. When a video encoder operates with 10-bit internal precision math it destroys less detail compared to 8-bit internal precision math. Though this greater precision is only useful if your source is high quality to begin with. Applying 10-bit to 1Mbps 8-bit 1080p video for example won't do much because the very low bitrate reduced the overall colors in the video and 10-bit can't undo that damage.

Diminishing returns after 10-bit. You get ~5% better compression vs ~20% and color banding won't be reduced any further to a noticeably extent.

>you can actually eek out higher video quality by doing a CRF encode and using the average bitrate from that to perform a 2-pass.
You are retarded, learn to read fucking documentation
you get two quantization steps for free because two of the bits weren't doing anything anyway
Cool it with the antisemetic remarks