video encoding

I tend to make long ffmpeg strings to test compression for stuff before forgetting my results. no longer. I shall write them down now

obs recordings

I’ve been finding it harder to justify re-encoding my OBS recordings. before typing this out, I would record in x264 with CRF 19 at preset veryfast, then for long term storage, I’d re-encode to av1 after the fact with svt-av1-hdr. my CPU is not good enough to make encoding svt-av1 directly a viable option (even on preset 9 it spikes all 12 threads to ~50%). this is the same with x265. I don’t like GPU encoding for vague file size reasons.

I never did any hard lined tests with this kind of setup, though. one day I was bored enough to try. I recorded a scene in super battle golf—on CRF 7 and a 4:4:4 color profile to simulate a “close-enough-to-lossless” video feed. I chose super battle golf because it has the general average of stuff I record: fast subjects, bright colors, and detail in the fairways. I then would run this script, which:

converts the input video to h264 crf 18-23 with presets fast-veryfast (to simulate “recording” this feed)
converts the crf=18:preset=faster h264 video to av1 and h265 at various presets (to simulate my re-encoding of a recorded video)
compares the outputs to the original input using vmaf

you can see a table of my results of this little experiment.

I used ac-bias=2 on av1 to tune a bit more towards detail. the default for svt-av1-psy is 1. though, even with that, I found the av1 encoding to smooth a bit more on the details bits of the fairway. I think I enjoy the “noisier” and blockier artifacts that the h264 encodings give; they feel more true to how the source looks on a frame-by-frame basis, even if the vmaf score is theoretically lower.

I was surprised to see how much veryfast drops compared to faster. better to know now than later, I suppose. don’t use anything above faster for x264.

theoretically, the h265 encodings from the crf=18 h264 one would be better in that regard, but I want to dissuade myself from its patent weirdness. will h265’s patent stuff ever affect me personally in my entire life? probably not. but I would still like to stay aray from it.

overall, I came out of a full day of staring at videos and tuning parameters with… I think I’m just going to record at crf 22, preset faster, and not bother with re-encoding. it just leaves everything the most well-rounded. the file size really isn’t an issue in the long term; I don’t record nearly often enough to justify re-encoding for cold storage. do I really want to keep my computer spiked to 100% on all cores for an entire night of video encoding to save ~20% of space at the same quality threshold? no. I don’t.

I’ll leave the old parameters I initially had on this page here:

h265/x265

good for things that are “noisy”. parameters can be found on the x265 docs

ffmpeg -i INPUT -c:a copy -c:v libx265 -crf 27 -x265-params 'no-sao=1:keyint=300:min-keyint=300' -preset slower OUTPUT.mp4

probably don’t need crf 27 for most stuff, 29-33 seems reasonable. example footage: R.E.P.O., which has a lot of blocky grain

av1

good for things that are “smooth” and less noisy. parameters can be found on the project page. I use it for resonite clips

10-bit is recommended even if source is 8-bit for slightly more depths on the blacks for little to no filesize increase. this is usually my starting cmdline when encoding videos overnight:

ffmpeg -i INPUT -c:a copy -c:v libsvtav1 -crf 40 -svtav1-params 'tune=0' -pix_fmt yuv420p10le -preset 3 OUTPUT.webm

NOTE: this doesn’t use svt-av1-hdr. I developed more rigorous lines for svt-av1-hdr. something like -svtav1-params 'crf=40:preset=4:hbd-mds=1:ac-bias=2:tune=0'.

2 pass

if you get an error like can't open ffmpeg2pass-2.log and are wondering why in the world it’s trying to open -2 when your first pass had -0, it’s because ffmpeg uses the output video track for the number on the pass file. when doing the first pass, there’s no audio, so it outputs -0. on the second pass, if the video is after the audio, it’s going to open -1 or -2 or whatever.

you can work around this by explicitly stating -c:v:0 for both passes

vp9

parameters can be found on ffmepg-codecs. other stuff on ffmpeg trac

I don’t find vp9 to have a lot of use between h265 and av1, but occasionally it might win me out when pixel-peeking. noting the aforementioned 2-pass shenanigans:

ffmpeg -i INPUT -c:v:0 libvpx-vp9 -crf CRF -g KEYINT -keyint_min KEYINT -b:v 0 -pass 1 -an -f null /dev/null \
&& ffmpeg -i INPUT -c:v:0 libvpx-vp9 -c:a copy -crf CRF -g KEYINT -keyint_min KEYINT -b:v 0 -pass 2 OUTPUT.webm

back