Adventures in AVC video encoding...

NormanPCN
NormanPCN Posts: 4,298 Expert
edited September 2020 in General

FWIW

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.


Comments

  • Triem23
    Triem23 Posts: 20,188 Power User
  • NormanPCN
    NormanPCN Posts: 4,298 Expert
    edited September 2020

    Some additional points with respect to "what of all this".

    Source material content matters when it comes to video compression. Immensely. I showed an example where a screen capture tutorial at 1080p30 was < 1Mbps and high quality and a worst case 1080p30 at 4.3Mbps was a blocky mess. Same Youtube (YT), same frame size a frame rate. Different content. What can you do about that? One example could be not having trees blowing in a breeze in the background. At least if trees on screen, then still air so the trees are static. Or have a shallow depth of field so a high frequency background is blurry. Blurry compresses easier than detail. A stable camera can help. A car moving through the background may not be a big deal since at common "cinematic" frame rates (AKA all motion => blur) the car will be a blurry mess. Blur compresses easier. A car with vegetation behind could pose a problem.

    On another note, I mentioned that if you are not happy with your Hitfilm export result then raise the bitrate. Try typically raising by 50%. It can take a lot of bitrate to make very visible differences verses pixel peeping. Again, test with your media and your eyes.

    Here is the YT result from the crowd run of the upload from the Hitfilm 12Mbps export. So not pristine like the Cineform RGB upload. You can compare the two YT results. There is a levels difference between them so the grass "color" and some runner shirt colors look different. Hitfilm can/has muck with Cineform levels if the file contained full range. I have no control on Handbrake with this decode so I don't know if something happened there. I do not have control over what Youtube does with the levels of my Cineform RGB upload. It's RGB so levels should not be there but who knows with so many cooks in the kitchen. So you have to look past this slight contrast difference. Also, compression artifacts can be different but still similar in quality. Blocky different is not necessarily blocky worse. Kinda subjective here. Easiest thing is just watch and do you "feel" much difference between them.


    Here is another 10 second 1080p50, tough test case example. Seemingly simpler but still tough in different ways than the crowd run. Just trying to show variation of what is tough to encode to low bitrates. Again, a pristine 1.3Gbps Cineform RGB upload to YT.


    For any wondering, these HQ tough test cases I got from a Swedish site (Sveriges Television AB (SVT)) of sample clips for video compression testing. Realistic things to point a camera at but harsh examples with respect to video compression. I have one other I downloaded. Ducks taking off from water. Lots of pond ripples in the wake of the flight. They did have easy examples but I did not bother with those.

    It is not just YT that is low bitrate video. Cable and satellite TV are also prime offenders. Just as much? A measly standard definition DVD is very high quality compared to most HD video sources. A DVD is effectively high bitrate. As I write this I wonder how well a high bitrate DVD would compare to typical/common low bitrate 4K content. Probably not as bad as it might seem.

  • NormanPCN
    NormanPCN Posts: 4,298 Expert

    This thread was a lot about Youtube results from uploads. A question came up recently as to how can you know how Youtube encodes. Well, they tell us. To an extent. I figured I would just pop these links in here to this old dry forum post. They are even drier. 😴

    Long story short. These days Youtube transcodes in two pass. Not what most of us think as two pass LongGOP encoding. They transcode to an intermediate of their choosing and the tool doing the transcode sniffs out some metrics about what is going on inside the video. Thus allowing then to maybe adjust the encode settings for the given video. There are limits of course. They have business decisions with respect to ultimate bitrate for the file as a whole. This mechanism is destination codec independent in the first pass. Like typical two pass LongGOP they can know video segments that are low bitrate and those that are high bitrate.

    --

    This one is about detecting perceptual quality of the input and when you can encode "down" to the quality level of the upload.

    "In this paper, an efficient machine learning metric is proposed to detect low quality inputs, whose bitrate can be further reduced without sacrificing perceptual quality"


  • NormanPCN
    NormanPCN Posts: 4,298 Expert
    edited September 19

    I am reviving this old thread with some new information. The original information is still completely valid and may be of interest.

    ---

    Given that Hitfilm Express 2021.2 and 2021.3 and the new Hitfilm Free use the operating system AVC encoder, I thought I would do a very quick look-see at those encodes relative to Hitfilm Pro (Mainconcept AVC encoder)(the encoder used in initial post).

    There are often posts of users noticing newer Express not encoding as good as previously. In this case I am only testing on Windows, so the "operating system AVC encoder" is the Windows encoder in Windows 11.

    I took one of my pristine quality test files, Crowd Run (above), and encoded that in Hitfilm Free 2022.1. I list some SSIM metrics of the encodes. SSIM listed is for the Y channel avg(median?). As stated above, the visuals roughly follow the metrics.

    Crowd Run is 1080p50.

    • Hitfilm Pro 16 Mbps = 0.867628
    • Hitfilm Free 20 Mbps = 0.861087
    • Hitfilm Free 24 Mbps = 0.879934

    The Youtube preset in Hitfilm Pro always previously ran at 16 Mbps. Free runs at 20 Mbps.

    The Windows 11 AVC encoder is not as good as the Mainconcept AVC encoder. This was expected. The bitrate increase FxHome added to the commonly used Youtube preset is a pretty good increase to compensate for the lesser encoder. Every encode sample of course has different needs.

    Of course, I can't show you the the encode results. I can only show a Youtube result, which will not be as good as the upload. This is a tough to encode test clip. All this is discussed above, but you can compare the upload of a pristine, basically perfect, result uploaded to Youtube. Link is above. That result is not even remotely as good as the upload. Some things can just never look ideal at low bitrates. This is of course everything. Youtube, cable/satellite TV and all that. They are all low bitrate these days.

    So the Windows 11 AVC encoder is generally about the same as the Mainconcept AVC except, and this is a big except, the Windows 11 encode is prone to short trashy/blocky/blurry sections. 

    Here is an example from a video game capture. Specifically the game Control. We are looking at a still. What is occurring on screen in this area of the video. The floor is moving up, like an elevator. The character was dropping down, thus the camera is moving down, but their feet have touched down. So the camera should now be moving up but only recently. The camera just started panning left. At this instant is when the floor goes blocky. The game does add some motion blur. In this case the motion blur is primarily on the wall. The floor gets only slight motion blur. Here the wall is fine. The wall hold up well enough. Soft detail is easy(er) to compress. It is only losing it for a few frames before it recovers. The encoder does seem to have a problem with the low(er) contrast checker red floor. Different color might be okay. I have seen a report where a black and white sample has issues. Maybe lack/little detail in multiple channels has an issue.

    Basically the Windows 11 encoder needs a ton more bitrate to not crap out this region of the encode. 40 Mbps. Look at the floor. You can see the Mainconcept 16 Mbps encode is as good or better in this section. This makes the encode potentially uneven section by section. This all reproduces reports by others on this forum with respect to the operating system encoder having quality issues in select instances.

    Also, note there are other sections in this file that exhibit this issue. All are motion related if my memory serves me. The motion vector/estimation analysis in the encoder may be a bit suspect in some circumstances. Specific motion directions/angles and/or motion distances or a combo of the above. The slight motion blur on the floor may have contributed. All speculation. The issue is real and it is there.

    Here is the original game capture.


    Here is the 20 Mbps Hitfilm Free 2022.1 encode.


    Here is a 40 Mbps Hitfilm Free 2022.1 encode.

    Here is a Hitfilm Pro 2021.2 16 Mbps encode.


    Crowd run. Youtube result. Hitfilm Pro 2021.2 16 Mbps upload.


    Crowd Run. Youtube result. Hitfilm Free 2022.1. Windows 11. 20 Mbps upload.

    Crowd Run. Youtube result. Hitfilm Free 2022.1. Windows 11. 24 Mbps result.