/vt/ - Virtual Youtubers

>>6346392
The first pass doesn't encode any (visible) video at all, it's not "uncompressed" - it's taking "notes" on what to do afterwards. The "making the WEBM" part really shouldn't make a difference either. Having it done with mkvtoolnix on my end is just an extra/redundant step because of the front-end that allows AVISynth/vapoursynth scripting. Selecting MKV/WEBM output automatically switches the "final" output to mkvmerge, so it's just how the VP8 stream ends up in the container. If I used ffmpeg to encode it and put it right into a WEBM all in one step, it would look 100% identical with the only changes being invisible (metadata).
I finally see what you mean about the color - and not with my fucking eyes even though f.lux was on last night. WEBM on the left, "master" on the right, (You) on the bottom. Good fucking grace, even without f.lux how did you even SEE that? I kneel, but only to the FREAK cones in your fucking eyes, niggerchama.
Anyways, it's likely the encoder itself. With e.g. x265 you can make very specific tweaks, even on a frame-by-frame level for things like block size, color, bitrate for color information, etc. libvpx ain't got time for that shit. I was surprised it let me stuff -crf, -qmin/max, AND -b:v into one command while seemingly obeying all of them. The documentation lists some, but not all, commands separately for VP8 and VP9. I thought Frankensteining them together would just crash it, but it looked way better than a regular two-pass at the same bitrate.
Even the master output's background color is slightly off on my end, which is either chroma key garbage because Resolve blows, or even at 15 Mbps H.264, the encoder thought "HUMAN EYES CANNOT DISCERN THIS DIFFERENCE." even yours is slightly off - remember - $error: rgb(255, 108, 108); is what we were aiming for
TL;DR It's the encoder dithering the colors down to try and maintain quality. Extra bits to prevent macroblocking at that large a resolution and that miniscule a bitrate had to come from somewhere.