Adventures in AVC video encoding...
I somehow came across some marketing hype from Mainconcept about their AVC encoder and this caused me to take a look at their AVC output again. A little.
I tried a couple of examples. Worst case, a first person GoPro view on a mountain bike. A tough but compressible case, a sample I got from the Net of a crowd run. This later item is also extreme quality. It was filmed on a 65mm film camera and scanned. UHDp50, 10 second, 23 GiB lossless...ouch! I have a 1080p50 version of this.
No point in covering an easy case but I did a quick DL (from Youtube) of the most recent Hitfilm tutorial video. X-ray scan. Mostly static and little movement or predictable movement. From this it appears that Youtube is now doing constrained/capped CRF type encodes of video these days. Previously I always saw an average bitrate and most/all videos were the same average. The 1080p30 version of the X-ray scan video was a whole 970 Kbps. Yes, that low. How can such a low bitrate still provide quality video? The wonders/magic of temporal video compression my friends.
I sampled random frames across the video time for comparison. I loaded the videos into Hitfilm. Each on their own layer. For comparo I clicked a top layer visibility on/off/on/off/on/off rapidly to view pixel level differences. One thing, shame on Youtube (YT) for taking constant frame rate video and resulting in variable frame rate downloads. It is not really variable, but it is not perfectly constant. Shame on them. This caused me some issue(s) with Hitfilm since Hitfilm often butchers VFR video timing. So I had to move the YT layer one frame fore/aft at time to get things to match for the on/off comparo. No such issues with Hitfilm or handbrake encodes. Frame accurate to the source.
It should be noted that the MTB GoPro example compresses better if it is mildly stabilized to get rid of an pixel level camera mount "buzz". Heck, even knobby tires on smooth asphalt can cause a pixel buzz. I stabilized translation only and not roll. Bikes lean when they turn. I have not checked if the Hitfilm stabilizer stabilizes lean/roll out of a sample video.
First, the Mainconcept AVC (MC) encoder can now be trusted to hit or be very close to your set target bitrate in the Hitfilm export preset. I don't know in what version of Hitfilm this showed up. In Hitfilm 15 it is there. Previously MC always overshot your target when you had the max bitrate above the average. Especially with hard to encode source material. So if you asked for 12Mbps you got something a fair bit higher than that. Maybe this is why FxHome in Hitfilm 2017 changed the Youtube preset to 16Mbps average and max. Previously they had 10Mbps average and 15Mbps max. The later is a more sensible relative choice. I wonder if an encoder with rate control that offers average and max, that maybe the rate control algorithm works best if max is above average.
Worst case example. I did encodes of 8Mbps (8avg, 12 max) and 12Mbps (12 avg, 18 max) from Hitfilm, and an x264 encode at an average of 8Mbps (via Handbrake, single pass, no CRF). I uploaded the GoPro original to YT and downloaded the result. That result was 4.3Mbps average. I've known for a while that YT has targeted <= 5Mbps average for 1080 <= 30p. The YT result is butchered. Very pixelated and blocky. I realistically expected this. This example has little or no opportunity for temporal compression so bitrate is everything and the YT target bitrates are low. The 8Mbps MC encode is superior to the YT result. The x64 encode is better than the MC but not dramatically so. The 12Mbps is of course better and the 16Mbps Hitfilm YT preset even more so. Why did I choose an 8Mbps as a primary sample. Because YT recommends 8Mbps for 1080 <= 30p for AVC uploads. The MC 8Mbps sample is better than the YT result but then the question is it enough better. That is really too indeterminate a question to answer or even test. Case by case basis. But if you bump up the YT recommendation you should be able to sleep better and have smaller uploads. I think one certainly needs to have max well above average. With current generations of the MC encoder we can now do this. Yea.
Tough case example. I targeted 12Mbps average here. The YT recommended upload AVC bitrate for 1080 50/60p. The original uploaded to YT was a Cineform RGB 1.4Gbps file. Yup, huge. The YT download result had a 5.9Mbps average bitrate. Both the MC and x264 encodes were superior to the YT result. You can see the blocking twitching on the tree and grass. They retained detail in the big tree and grass better than YT. x264 retaining more color tonal variation than MC in the grass. There is a lot of movement here, but the runners bouncing is reasonably predictable and their speed towards camera seems slow enough. Both allowing reasonable amounts of temporal compression to help the YT result not be terrible like the worst case example. I should be noted that 50/60p almost always gets more temporal compression due to the high(er) frame rate. This is why you often see 60p bitrates spec'd at only 50% more than 30p even though you have twice the data. They expect to get more temporal compression.
I did do an SSIM (Structural Similarity Index) comparison of all these videos and the numbers told a similar story to the eyes. I compared a test encode to the original source to gen an SSIM metric for that encode.
I wish I had an source media example to test of a few reports we have gotten on game source material where the Hitfilm YT preset pixelated for a second or so at times. Of course what would YT do with such material.
So what of all this? Mostly I knew this result already but new is to use the max bitrate feature of the Hitfilm AVC encoder (Mainconcept). 50% higher max than average might be a good general choice. This max bitrate feature is reliable now. At Youtube recommended AVC bitrates the MC encode result is superior to the Youtube result in these test cases. As for target average bitrate for YT uploads. That is tricky. I would go a little above the YT recommendation to feel safer. At least 25%. It's only upload time. Let your eyes judge and not mine. The MC encoder is close to x264 in ways but then far off in some others. Hence at times you may need significantly more bitrate in MC for the YT upload. Those are probably uncommon cases but of course they probably exist. As always, bitrate cures all video compression ills. Not happy with the Hitfilm export quality, then raise the bitrate(s). As always, if you want/need the best quality at the smallest bitrate then x264 is the way to go. Export Cineform/Prores from Hitfilm and transcode via your favorite external encoder using x264 for the final AVC result.
The GoPro example. Original GoPro media upload to YT. 35Mbps 1080p30. 55 seconds.
The Tough result. 1.4Gbps Cineform RGB upload. 1080p50. 10 seconds.