Benwaggoner HEVC encoding challenge

[Gravitator]

Tears of Steel VVenC 1mbps: https://drive.google.com/file/d/1shmEm5cRMAUgw5THII5bn2vJ0haO0hci/view?usp=sharing

Thanks! On dark scenes, the quality is just disgusting (8-bit).

[benwaggoner]

Thanks! On dark scenes, the quality is just disgusting (8-bit).
Low luma in 8-bit SDR requires a fair amount of psychovisual optimization due to the nonlinearity of Rec. 709's EOTF compared to human perception. --aq-mode 3's bias for lower QP in dark regions is the right idea, albeit too aggressive.

PSNR and VMAF don't capture that nonlinearity, so encoders tuned for those metrics tend to have issues in dark regions.

[Gravitator]

--aq-mode 3's bias for lower QP in dark regions is the right idea, albeit too aggressive.
I propose to prohibit the use of 8-bit! This castrated regime stifles the potential of modern encoders.

[Asmodian]

I propose to prohibit the use of 8-bit! This castrated regime stifles the potential of modern encoders.

If we are proposing unrealistic prohibitions, can I add chroma subsampling to the list? :mad:

[Gravitator]

If we are proposing unrealistic prohibitions, can I add chroma subsampling to the list? :mad:
Why not realistic? After all, it is reasonable.
Ordinary users do not know about chrome. According to an old habit, they will put 8bit - get the worst result (horror movies at low bitrates).

[benwaggoner]

I propose to prohibit the use of 8-bit! This castrated regime stifles the potential of modern encoders.
This specific test is 8-bit specific, mainly because comparing 8-bit encodes is less fraught.

But a 10-bit HDR test would be an obvious next step. Perhaps with Sol Levante.

[Mr.Rippley]

###Hi! I decided to learn how to efficiently encode video using HEVC. What is needed for this? Some special software or coding settings should be set "very slowly". Now I use StaxRip 2.8. I would like to achieve the quality and size of the video as on the PSA website, there are just magicians(IMHO). Unfortunately, I can't learn from them because they erase the attributes of their video files, so the encoding parameters are not visible in the media. ### At first I decided to write this, but after reading this forum I fell into antagonism. For many years I studied MPEG2 and DV coding, since I worked in television. Then I studied DivX and AVC for myself. For the last couple of years I have been trying to master HEVC (only 10 bits) to the maximum... Now it turns out that this codec is defective, sorry, not perfect. And yet, can anyone answer me the ### question ### at the beginning of the post? The best coding program(GUI) for Windows? What are the most important settings, parameters? Or just set a placebo preset?

[benwaggoner]

###Hi! I decided to learn how to efficiently encode video using HEVC. What is needed for this? Some special software or coding settings should be set "very slowly". Now I use StaxRip 2.8. I would like to achieve the quality and size of the video as on the PSA website, there are just magicians(IMHO). Unfortunately, I can't learn from them because they erase the attributes of their video files, so the encoding parameters are not visible in the media. ### At first I decided to write this, but after reading this forum I fell into antagonism. For many years I studied MPEG2 and DV coding, since I worked in television. Then I studied DivX and AVC for myself. For the last couple of years I have been trying to master HEVC (only 10 bits) to the maximum... Now it turns out that this codec is defective, sorry, not perfect. And yet, can anyone answer me the ### question ### at the beginning of the post? The best coding program(GUI) for Windows? What are the most important settings, parameters? Or just set a placebo preset?
You can use whatever you want to submit something. It's not like there's a prize or anything :sly:! The goal is to produce the best looking file that's playable in an available video player within the specified technical parameters (of which there aren't many).

No codec is effective, and pretty much everything shared so far started with a placebo preset and was tuned from there.

But you can post whatever you like; it's not like you'll be kicked out or anything if you can't beat the previous best efforts.

[jcj]

Here's my submissions for ToS and Sol. All of these encodes are done with --preset veryslow --no-cutree --keyint 120 --rc-lookahead 120 --vbv-maxrate 4000 --vbv-bufsize 12000, and 5 passes. I made some small modifications to improve the 2pass rate control - https://pastebin.com/0vYpLmf3 https://pastebin.com/S8x2VEa4

ToS 1M: https://www.mediafire.com/file/bqac9a7ws14b1e5/tos-1000-vsl-nocutree-psy1_50-p5.mkv/file
The ToS encode additionally has --psy-rd 1 --psy-rdoq 50

Sol 1M: https://www.mediafire.com/file/9zndceg12wedjkp/sol-1000-vsl-nocutree-psy1_0-db3-aq3-p5.mkv/file
Sol 2M: https://www.mediafire.com/file/l60gtmsaba3ihfg/sol-2000-vsl-nocutree-psy1_0-db3-aq3-p5.mkv/file
The Sol encodes additionally have --psy-rd 1 --psy-rdoq 0 --deblock 3:3 --fades

Using --no-cutree is the key to good quality for ToS. The slow scenes are vastly improved, with better facial texture and less artifacts in moving areas. I think this is the best 1M ToS x265 encode to date.

For Sol, --no-cutree doesn't seem to make a difference. The 2M is better than the 2M VP9. The 1M is comparable to rwill's H265. It's better in the fast scenes and worse in the slow scenes.

[rwill]

Although it is Work In Progress here are EVC Baseline Profile Encodes of ToS and Sol Levante:
https://drive.google.com/drive/folders/1plFE_-kqDrWs_rqYaHMkVWqxgQyCvQvo

I used my encoder.

You need a somewhat working decoder to decode the streams, you can get one here (in source form):
https://github.com/rwillenbacher/xevd

I am not happy with how all pictures look etc. but I think it turned out ok, given its early in encoder development.

[benwaggoner]

Would folks be interested in my providing a 10-bit SDR of Tears of Steel for testing? 10-bit support is mandatory for AV1 and nigh universal for HEVC now.

And for HDR testing, is there a preference between 1080p or 2160p? 1080p is faster to encode and easier to compare, but most HDR is also UHD so that's the primary use case?

I was thinking of using Sol Levante for HDR, but it has some uniquely challenging to encode sequences I've not been able to make look good at 15 Mbps 1080p with the encoders I've tried. Good as a stress test, but not good as a representative example.

[rwill]

Would folks be interested in my providing a 10-bit SDR of Tears of Steel for testing? 10-bit support is mandatory for AV1 and nigh universal for HEVC now.

For your encoding challenge ?

I don't think that for ToS 8 or 10 bit makes a real difference as an encoder can only produce, I take a very rough estimate here, 6.5 bits precision on average at these low bitrates.

Might be interesting academically though.

[Forteen88]

--psy-rdoq 50
Doesn't that create LOTS of noise?!

[benwaggoner]

For your encoding challenge ?

I don't think that for ToS 8 or 10 bit makes a real difference as an encoder can only produce, I take a very rough estimate here, 6.5 bits precision on average at these low bitrates.
I'm not sure if you're measuring "bits of precision" in a relevant way. Certainly the encode will have output with smooth histograms over the 8- and 10-bit ranges. Frequency domain and raster precision have quite different visual impact.

Extra input precision means less dithering is required, and thus less extra noise.

[rwill]

I'm not sure if you're measuring "bits of precision" in a relevant way. Certainly the encode will have output with smooth histograms over the 8- and 10-bit ranges. Frequency domain and raster precision have quite different visual impact.

Extra input precision means less dithering is required, and thus less extra noise.

I mean something like SNR. Thats why I wrote 'very rough estimate'.

The higher the quantization the less important the bit depth and associated dithering becomes. I mean if dithering is quantized away anyway its only purpose is to generate some sort of local higher precision for low frequency components to avoid banding, blocking and sorts. So my guess is that it does not matter if the input is 8 or 10 bit if a H.265 encoder is in QP >= 30 regions most of the time anyway.

I know some people are adding dithering/noise to encodes but am just unable to see any reason to use it with encodes where quantization is so high that it will not have a meaningful impact on the end result because the precision of the input is vastly higher than what can be reconstructed after a high quantization. We do have Deblocking Filters now...


@Forteen88

It will not create noise but one will most likely lose the coding efficiency benefits of RDOQ.

[HD MOVIE SOURCE]

Would folks be interested in my providing a 10-bit SDR of Tears of Steel for testing? 10-bit support is mandatory for AV1 and nigh universal for HEVC now.

And for HDR testing, is there a preference between 1080p or 2160p? 1080p is faster to encode and easier to compare, but most HDR is also UHD so that's the primary use case?

I was thinking of using Sol Levante for HDR, but it has some uniquely challenging to encode sequences I've not been able to make look good at 15 Mbps 1080p with the encoders I've tried. Good as a stress test, but not good as a representative example.

I'd love to see Tears of Steel at 4K with HDR, that would be cool. I've been trying to find one with 4K and 5.1 audio, but I can't find that. What's the best encode done so far?
Sol Levante is a good encoding test, are there any more lossless videos like that? Thats the first lossless file I've encoded and it looks excellent.

[HD MOVIE SOURCE]

When you're only dealing with 1 Mbps, is there any way to get scene cuts to look cleaner without turning into artifacts? That's my biggest issue with a restricted bit-rate. Does anyone have any advice?

[benwaggoner]

I'd love to see Tears of Steel at 4K with HDR, that would be cool. I've been trying to find one with 4K and 5.1 audio, but I can't find that. What's the best encode done so far?
Sol Levante is a good encoding test, are there any more lossless videos like that? Thats the first lossless file I've encoded and it looks excellent.
Tears of Steel was only made as 4K SDR, alas. I looked into remastering it for HDR a few years back. It was theoretically possible, but would require regrading all the camera footage and a lot of tweaking and rerendering of the CGI stuff to incorporate HDR elements.

[benwaggoner]

When you're only dealing with 1 Mbps, is there any way to get scene cuts to look cleaner without turning into artifacts? That's my biggest issue with a restricted bit-rate. Does anyone have any advice?
Can you share your command line?

There's a lot of tweaks in x265 that can be done.

Bigger gap between --keyint and --min-keyint
Reduce --ipratio
Increase --rc-lookahead (max is --keyint)
Use --open-gop
Play around with the 3.x scenecut features.

[HD MOVIE SOURCE]

Can you share your command line?

There's a lot of tweaks in x265 that can be done.

Bigger gap between --keyint and --min-keyint
Reduce --ipratio
Increase --rc-lookahead (max is --keyint)
Use --open-gop
Play around with the 3.x scenecut features.


Im using uhd-bd=1 and keyint of 24. The reason for that is I always want to see the restrictions of encoding with 4K discs. I completely understand it's not optimal for this challenge.

This is what I use for my normal encodes using a constant rate factor of 0 with maxrate and buffsize control. Using these settings when lowering the maxrate and buffsize to 1 is pretty tough. I don't mind that it looks bad, I just want to see if there's anything that would make scene cuts look better.

Slow speed.

uhd-bd=1:no-open-gop:total-frames=0:min-keyint=1:keyint=24:rc-lookahead=24:lookahead-slices=0:vbv-maxrate=98000:vbv-bufsize=99000:ref=5:subme=7:aq-mode=3:aq-strength=1.6:bframes=3:b-adapt=0:ipratio=1.00:pbratio=1.00:no-deblock:no-sao:no-strong-intra-smoothing:psy-rd=0.00:psy-rdoq=0.00:rdoq-level=0:no-cutree

I set vbv-maxrate=98000:vbv-bufsize=99000 to vbv-maxrate=1000:vbv-bufsize=1000

I really just did it to see what it would look like under 4K BD restrictions and the restricted bit-rates. I did notice though you use a buff size of around 4000, are we aloud to do that?

[rwill]

This is what I use for my normal encodes using a constant rate factor of 0 with maxrate and buffsize control. Using these settings when lowering the maxrate and buffsize to 1 is pretty tough. I don't mind that it looks bad, I just want to see if there's anything that would make scene cuts look better.
...
I did notice though you use a buff size of around 4000, are we aloud to do that?



Tears of Steel
1.0, 1.5, and 2.0 Mbps ABR
4 Mbps peak bitrate
12 Mbps VBV
Max 5 sec (120 frame) GOP
No preprocessing


What you are doing is more or less running constant rate (CBR) with 1 second buffer and 1 second keyint. No wonder everything looks like crap.

[HD MOVIE SOURCE]

What you are doing is more or less running constant rate (CBR) with 1 second buffer and 1 second keyint. No wonder everything looks like crap.

Ah, I see now, thanks for pointing that out. I will take a 2nd attempt and see. With that said, apart from keyint settings, are there any settings that can help with a scenecut even if I continue to use 1-second keyint?

[rwill]

Ah, I see now, thanks for pointing that out. I will take a 2nd attempt and see. With that said, apart from keyint settings, are there any settings that can help with a scenecut even if I continue to use 1-second keyint?

Well, the keyframes have to fit into the VBV buffer which is re-filled at maxrate. Their bits are taken from the global bit-budget. I don't know really. Higher VBV maxrate would help maybe to make space in the buffer but everything is gonna be bit-starved anyway.

[HD MOVIE SOURCE]

Well, the keyframes have to fit into the VBV buffer which is re-filled at maxrate. Their bits are taken from the global bit-budget. I don't know really. Higher VBV maxrate would help maybe to make space in the buffer but everything is gonna be bit-starved anyway.

Okay, interesting, I realized I don't really know how the maxrate and buffer really work. So basically if though you're targeting 1 Mbps, you can allow for higher maxrates so that when scene cutting, you have more bits right?

Just wondering though, let's say I set my maxrate to 4Mbps, and set the buffer to 100Mbps, what does that actually do? I'm just trying to picture the interaction.

[rwill]

https://forum.doom9.org/showthread.php?p=1953919#post1953919

Your "buckets" will be 100Mbit and will empty/fill with 4Mbit.

[HD MOVIE SOURCE]

https://forum.doom9.org/showthread.php?p=1953919#post1953919

Your "buckets" will be 100Mbit and will empty/fill with 4Mbit.

So the buffer would just be ahead of the maxrate by 100 Mbps? and the max rate will continuously take 4Mbps out of the buffer?

In that post you linked, some talked about underflow, what, and how I test for it? Somebody responded and said to check how it decodes or something. So, is there something I can do to test whether my maxrate and buffer settings work correctly?

I noticed that the buffer rate is 12 Mbps, and the maxrate is 4 Mbps, is this 3x difference typical? Would this help with scenecuts, but having more stored buffer?

Thanks.

[rwill]

https://en.wikipedia.org/wiki/Video_buffering_verifier

Have you read this and the respective links to CBR and VBR yet? It explains most basic bit allocation and the pros and cons.

[excellentswordfight]

I noticed that the buffer rate is 12 Mbps, and the maxrate is 4 Mbps, is this 3x difference typical? Would this help with scenecuts, but having more stored buffer?

Thanks.
I think its set to 12 in the original post cause that is max bitrate for level 4 main tier (i.e. most devices capable of decoding the stream should have a big enough buffer to handle the stream). The most common values i've seen is either set it based on the level or 1-2x maxrate.

Think about it this way, you use maxrate to specifiy the maximum read speed of your target decoder; so if you use 4Mbps a 5Mbps client connection will be able to stream that without issue (audio and headroom needs to be taken in account as well). This is one of reason why physical media (e.g. bluray) uses lower VBV limits than what the video standard allows for, cause the the relative slow read speeds of the optical discs. And by setting a higher buffsize than your maxrate you allow for sections with higher bitrate cause data has accumulated in the buffer, and the vbv modell ensures that as long as you can feed data to the decoder of the speed of the maxrate you wont underflow (i.e. the decoder runs out of data). This can be very beneficial for streaming were you need to set rather constrained maxrate vaules.

And btw, why are you using no-strong-intra-smoothing? It will only result in more blocking and banding, and especially at this bitrate it will not improve image quality at all. Even at high bitrates I havnt seen any positive effects of disabling this feature.

And also, I'm not sure why you are so fixated on the UHD-Bluray specifications, if you are not authoring for a physical disc, those requirements becomes rather irrelevant. Why even go to the lengths were you try to mix that with low-bandwith-streaming? There are no magic in those requirements, and most of the specifics are actually restrictions that will hurt quality.

[benwaggoner]

I think its set to 12 in the original post cause that is max bitrate for level 4 main tier (i.e. most devices capable of decoding the stream should have a big enough buffer to handle the stream). The most common values i've seen is either set it based on the level or 1-2x maxrate.
Yep, that's exactly where I got 12 Mbps. It was the most restrictive for the minimum compatible Profile @ Level (generally 4.0) for codecs relevant to the test.

And also, I'm not sure why you are so fixated on the UHD-Bluray specifications, if you are not authoring for a physical disc, those requirements becomes rather irrelevant. Why even go to the lengths were you try to mix that with low-bandwith-streaming? There are no magic in those requirements, and most of the specifics are actually restrictions that will hurt quality.
Yeah, I didn't have any optical disc scenario in mind when I came up with the test in the first place. That said, comparing best-effort to best-effort with optical disc constraints is an interesting way to demo the hit on compression efficiency due to Blu-ray requirements. I see a lot of AVSForum folks assuming that streaming has to be bad because Blu-ray bitrates go so much higher. But Bl8-ray NEEDS higher bitrates to get the same quality than streaming does. An IDR every 24 frames minimum is some serious overhead!

[HD MOVIE SOURCE]

Yeah, I'm honestly just seeing how certain restrictions like bit-rate, and even a uhd-bd=1 effect quality. I just like to test things and see if there's neat workarounds to improve quality even under certain restrictions.

Its my first time encoding at a lower-than-normal bit-rate, so I'm seeing what I can get away with and what I cannot. Changing the bufsize and maxrate has really helped, as I am trying this with CRF instead on 2-pass average bit-rate. Again, I'm seeing how the bit-rate constraints impact the CRF.

I see that intra-smoothing and deblock absolutely play a huge impact with bit-rates this low.

I gues the biggest thing here is keeping the bit-rate low, but having enough buffer than upon a scenecut, there's enough buffer to give that scenecut enough bits so artifacts are kept at bay. This is definitely something that Physical Media has issues with and can be improved with streaming because of the one second buffer on discs.
When it comes to encoding like this as though its for ststreaming, you mayas well use 250 or is it 260 keyint right to reduce the impact even on iframes right? I downloaded Ben's encodes and they look very good for having a 1 Mbps target bit-rate. I actually didn't think it was possible to get video this acceptable with bit-rates that low.

[excellentswordfight]

When it comes to encoding like this as though its for ststreaming, you mayas well use 250 or is it 260 keyint right to reduce the impact even on iframes right? I downloaded Ben's encodes and they look very good for having a 1 Mbps target bit-rate. I actually didn't think it was possible to get video this acceptable with bit-rates that low.
No, cause that will impact seeking and abr-switching. 2-4s interval is usually whats recommended for dash and hls streaming. The restrictions/scenario is very streaming-centered, as it imo should, as that is the biggest real life scenario for low-bitrate encoding. 5s (120=24*5) is already stretching this a bit, i've not seen a lot of GOP encodes going above 4s (or 120f). Broadcasters is usually in the 1-2s range (I also think thats what recommended by DVB partly cause its affect on channel switching). So in the real world it basically only for private use were large GOPs are used (like the common 10s GOP limit). Not sure though how its in the realm of extreme low bitrate cases like video-conference etc.

From what i've seen is that the compression gain starts to flat out after about 4s, but were going from 1s to 2s can make a rather noticeable impact.

[benwaggoner]

I gues the biggest thing here is keeping the bit-rate low, but having enough buffer than upon a scenecut, there's enough buffer to give that scenecut enough bits so artifacts are kept at bay. This is definitely something that Physical Media has issues with and can be improved with streaming because of the one second buffer on discs.
When it comes to encoding like this as though its for ststreaming, you mayas well use 250 or is it 260 keyint right to reduce the impact even on iframes right? I downloaded Ben's encodes and they look very good for having a 1 Mbps target bit-rate. I actually didn't think it was possible to get video this acceptable with bit-rates that low.
Yeah, my encodes are also a few years old. I could do them even better today. We get year-on-year improvements with existing codecs based on better code and better understanding of tuning. Then big step-change improvements with new codecs.

Today we can do a decent 1440p HDR with 2 Mbps ABR. When I started encoding, 2 Mbps got me a lousy looking 240x180 12 fps with 8-bit 11 KHz mono audio in QuickTime 1.0. Which wouldn't even play well off a (forthcoming) 1x CD-ROM. Like many Moore's Law dependent technologies, it's pretty amazing how what seemed like science fiction five years earlier is best practices today.

Higher keyint values are a tradeoff between random access speed (worse) and compression efficiency (potentially improved). I picked 96 for this test as a pretty common value, and less than some longer shots so we could see how the encoder handles a new GOP mid-shot, where visual discontinuities can happen.

To make sure there's enough VBV for IDRs, using 2-pass encoding or a lot of lookahead are key. For x265, setting --rc-lookahead = --keyint can reduce quality fluctuations significantly. Uses a lot of RAM, though! I was doing some 8K encoding a few days ago where a single x265 process was using about 40 GB.

[benwaggoner]

No, cause that will impact seeking and abr-switching. 2-4s interval is usually whats recommended for dash and hls streaming. The restrictions/scenario is very streaming-centered, as it imo should, as that is the biggest real life scenario for low-bitrate encoding. 5s (120=24*5) is already stretching this a bit, i've not seen a lot of GOP encodes going above 4s (or 120f). Broadcasters is usually in the 1-2s range (I also think thats what recommended by DVB partly cause its affect on channel switching). So in the real world it basically only for private use were large GOPs are used (like the common 10s GOP limit). Not sure though how its in the realm of extreme low bitrate cases like video-conference etc.
I've certainly seen 5 sec segments in DASH, and HLS originally recommended 10 sec per segment. It's a tradeoff between efficiency and ABR switching latency. Longer segments are easier to get away with in VOD since the client can download them faster than realtime. Live needs shorter segments as one can't download fragments (or sub-fragments) that haven't been encoded yet.

From what i've seen is that the compression gain starts to flat out after about 4s, but were going from 1s to 2s can make a rather noticeable impact.
Yeah, 3-5 has been a pretty safe bet for a couple of decades now. I've used up to 20 sec before for special cases, like simple animations that don't require random access. Some years back I was able to get some of the Kindle Fire preloaded intro videos down to 100 Kbps 1080p24 HEVC with that and other content-specific tuning.

[excellentswordfight]

I've certainly seen 5 sec segments in DASH, and HLS originally recommended 10 sec per segment. It's a tradeoff between efficiency and ABR switching latency. Longer segments are easier to get away with in VOD since the client can download them faster than realtime. Live needs shorter segments as one can't download fragments (or sub-fragments) that haven't been encoded yet..
Oh, I dont doubt that its used! And as someone that comes from a broadcast-background and are mostly involved with live encoders 4s is already rather high for me :) And most VOD content i've come across has used 2 or 4s, but vod-streaming as an interest is relatively new to me.

But gop length and segment size are different things, no? Gop size doesnt have to be the same as the segment length as long as the IDR-placements fits the segments or have i missed something? Current Apple HLS recommendation is 2s for the gop size and 6s for the segment afaik.

[benwaggoner]

Oh, I dont doubt that its used! And as someone that comes from a broadcast-background and are mostly involved with live encoders 4s is already rather high for me :) And most VOD content i've come across has used 2 or 4s, but vod-streaming as an interest is relatively new to me.

But gop length and segment size are different things, no? Gop size doesnt have to be the same as the segment length as long as the IDR-placements fits the segments or have i missed something? Current Apple HLS recommendation is 2s for the gop size and 6s for the segment afaik.
Correct, one can have multiple GOPs in a single segment. HLS famously recommended 3 second GOPs in 10 sec segments, for example. But, but 3*3<>10 I said! Never really found out the "why" of that

That said, most adaptive streaming targets H.264 or HEVC, which support non-IDR I-frames. Those are fully intra coded frames, but don't preclude a frame after it referencing a frame before it. There's no practical downside to using those inside a GOP, and some minor upsides, so generally things are encoded with an IDR at the start of every fragment, and a non-IDR I-frame for any natural keyframes inside that segment.

An advantage of this approach is that a packager doesn't have to figure out which IDRs are at segment boundaries and which ones aren't. A non-IDR I doesn't have to carry the once-per-GOP metadata. And if the I-frame is just a single flash frame like a strobe light, the frames after can reference the frames before, which can save a whole lot of bits (it's the same reason that VC-1 had intra-only B-frames (BI frames) to substitute a flash frame that would otherwise be coded as a P-frame).

[HD MOVIE SOURCE]

Yeah, my encodes are also a few years old. I could do them even better today. We get year-on-year improvements with existing codecs based on better code and better understanding of tuning. Then big step-change improvements with new codecs.

Today we can do a decent 1440p HDR with 2 Mbps ABR. When I started encoding, 2 Mbps got me a lousy looking 240x180 12 fps with 8-bit 11 KHz mono audio in QuickTime 1.0. Which wouldn't even play well off a (forthcoming) 1x CD-ROM. Like many Moore's Law dependent technologies, it's pretty amazing how what seemed like science fiction five years earlier is best practices today.

Higher keyint values are a tradeoff between random access speed (worse) and compression efficiency (potentially improved). I picked 96 for this test as a pretty common value, and less than some longer shots so we could see how the encoder handles a new GOP mid-shot, where visual discontinuities can happen.

To make sure there's enough VBV for IDRs, using 2-pass encoding or a lot of lookahead are key. For x265, setting --rc-lookahead = --keyint can reduce quality fluctuations significantly. Uses a lot of RAM, though! I was doing some 8K encoding a few days ago where a single x265 process was using about 40 GB.


Yeah, I encoded Big Buck Bunny at 60 frames per second and it used a lot more RAM. I've had a few encodes just stop because of it so I upgraded my RAM and I've never had any issues with that anymore.

So, I encoded Tears of Steel with your advice, on buffer and maxrate and it came out to a hair over your bit-rate on your file so I was happy. It looked much better. But, I kept the restrictions as though it was a 4K Blu-ray, just for science. I might upload it into my Google drive if you want to take a look.

Just wondering, do Blender even post fully uncompressed open movies, that haven't already been encoded? I'm currently encoding all of their open movies, but most are MP4s, and tears of steel got a DCP which was really nice. I re-scale mine, because 4K Blu-ray doesn't use the max 4K it uses 3840x2160p, so it downscales, and then you add borders get the pixels back to 2160p. I notice that a lot, even on their other open movies, they use strange resolutions most of the time. If they're not originally 4K I upscale them, which I've found doesn't look as poor as I originally thought upscaling would look. I've seen some poor upscales on 4K Blu-ray and just always assumed it must be because they upscaled from 2K, but I've found it to be quite good.

I noticed on the spears on munsil Blu-ray, it had Big Buck Bunny at 30 frames per second and the version was different it had the opening logo when looking at the tree at the start. The 4K version I use doesn't show the title at the tree scene of Big Buck Bunny. And, the 4K version, the original file has banding in a few scenes, whereas the spears and munsil Blu-ray version did not have that. So I looked around and could not find that version. So, I wonder if they got a special version? I contacted Blender and asked if they had listings for all their movies un-encoded, completely uncompressed, but weren't really that helpful. I subbed to their website to get access to a few more open movies, and support their work. I watched my encoded version and against the original file, and both had the banding in the same spot. It's hard to see if you're not like me (I'm crazy lol), but it's there.

I like what Netflix has done with SolLevante, its completely uncompressed, that turned out absolutely perfect with HDR too. I wanted to put dolby atmos audio on the encode too, but they provided a completely uncompressed atmos track that needed to be encoded. I couldn't believe how big just the audio file was. Its like 110Mbps LOL, just for audio. So, I had to use the 5.1 track, which I converted to AC3 at 640kbps. I think I'd need a special Dolby encoder to encode the audio, which is way out of my league.

I encoded sprite fright and that came out really well. As long as the source is clean even though they've encoded it, it will come out good, but I wish they did a prores or MOV files just so I could sleep better at night LOL.

So, your encodes used the DCP for tears of steel right? Thats the one I used, then I muxed the 5.1 audio to it, turned out really nice in the end. I don't like the grain structure they used though. It's blurry, and inconsistent. I checked the source file and it's imperfect on the source too. You can see this on the credits, the grain that they're using isn't a fine grain, its almost noisy.

Just realized Ive been talking a bit too long now, LOL Thanks for listening.

[benwaggoner]

Blender seems to be paywalling the sources for their newer titles for subscribers. Even for the older ones, there have been a variety of different versions, some added years after the original.

IIRC, my ToS came from a 4K high bit TIFF image sequence. Also, the 60 fps Big Buck Bunny came out some time after the original 24p render. BBB is a fun clip, but it is also pretty absurdly easy to encode, so I don't like to use it for encoding tests.

Now that StEM2 is out with free source downloads, I imagine that's going to be the most popular encoder test clips for years to come. They did a great job of including all sorts of elements that can stress all sorts of compression, image processing, and display processes. It's available in full 2020 PQ HDR, 709, up to 8K, etc. https://theasc.com/asc/stem2.

It's absolutely what I'd use for an updated version of this test today.

[excellentswordfight]

Blender seems to be paywalling the sources for their newer titles for subscribers. Even for the older ones, there have been a variety of different versions, some added years after the original.

IIRC, my ToS came from a 4K high bit TIFF image sequence. Also, the 60 fps Big Buck Bunny came out some time after the original 24p render. BBB is a fun clip, but it is also pretty absurdly easy to encode, so I don't like to use it for encoding tests.

Now that StEM2 is out with free source downloads, I imagine that's going to be the most popular encoder test clips for years to come. They did a great job of including all sorts of elements that can stress all sorts of compression, image processing, and display processes. It's available in full 2020 PQ HDR, 709, up to 8K, etc. https://theasc.com/asc/stem2.

It's absolutely what I'd use for an updated version of this test today.
Wow, that looks amazing! Thanks for sharing the link. Very nice to have both HDR & SDR masters as well.

Before I start downloading do you know the specs of the IMF packages? "lossy HDR App 2E" is twice the size of "lossy SDR App 2E", is the SDR 1080p and hdr 2160p? I think I´m going to create a 1080p h264 bluray compatible SDR-version and one 2160p h265 uhd-bluray compatible HDR10-version if I need something leaner and to use as bluray-reencode simulations and tuning, and Im thinking what versions would be best to use as sources.

[benwaggoner]

Wow, that looks amazing! Thanks for sharing the link. Very nice to have both HDR & SDR masters as well.

Before I start downloading do you know the specs of the IMF packages? "lossy HDR App 2E" is twice the size of "lossy SDR App 2E", is the SDR 1080p and hdr 2160p? I think I´m going to create a 1080p h264 bluray compatible SDR-version and one 2160p h265 uhd-bluray compatible HDR10-version if I need something leaner and to use as bluray-reencode simulations and tuning, and Im thinking what versions would be best to use as sources.
I've not looked at the DCP packages yet. I've just started playing with the DNxHD QuickTime.

Note that SDR is available in two different aspect ratios.

[HD MOVIE SOURCE]

Blender seems to be paywalling the sources for their newer titles for subscribers. Even for the older ones, there have been a variety of different versions, some added years after the original.

IIRC, my ToS came from a 4K high bit TIFF image sequence. Also, the 60 fps Big Buck Bunny came out some time after the original 24p render. BBB is a fun clip, but it is also pretty absurdly easy to encode, so I don't like to use it for encoding tests.

Now that StEM2 is out with free source downloads, I imagine that's going to be the most popular encoder test clips for years to come. They did a great job of including all sorts of elements that can stress all sorts of compression, image processing, and display processes. It's available in full 2020 PQ HDR, 709, up to 8K, etc. https://theasc.com/asc/stem2.

It's absolutely what I'd use for an updated version of this test today.

I'll check that out thank you. Are there any 4K UHD prores The Rings of Power trailers? I'd like to see how close to the stream quality I can get. Trailers are generally quite busy so more bit-rates are needed for high scene-cut segments. I think it would be a good test also.

[HD MOVIE SOURCE]

Blender seems to be paywalling the sources for their newer titles for subscribers. Even for the older ones, there have been a variety of different versions, some added years after the original.

IIRC, my ToS came from a 4K high bit TIFF image sequence. Also, the 60 fps Big Buck Bunny came out some time after the original 24p render. BBB is a fun clip, but it is also pretty absurdly easy to encode, so I don't like to use it for encoding tests.

Now that StEM2 is out with free source downloads, I imagine that's going to be the most popular encoder test clips for years to come. They did a great job of including all sorts of elements that can stress all sorts of compression, image processing, and display processes. It's available in full 2020 PQ HDR, 709, up to 8K, etc. https://theasc.com/asc/stem2.

It's absolutely what I'd use for an updated version of this test today.

I've encoded the 4K version of StEM2 twice now and at 5 mins and 08 seconds, there seems to be some digital artifact. It is a line that goes across the top portion of the screen for half a second and disappears. I've encoded it twice and its in the same place. I think it could be an artifact with the file itself. I think what I'll do is download the 4K DCP file and see if that file has corrected the error.

I downloaded the 126GB file.

Do they have a contact? Ill see if I can shoot them an email about it.

[excellentswordfight]

I've encoded the 4K version of StEM2 twice now and at 5 mins and 08 seconds, there seems to be some digital artifact. It is a line that goes across the top portion of the screen for half a second and disappears. I've encoded it twice and its in the same place. I think it could be an artifact with the file itself. I think what I'll do is download the 4K DCP file and see if that file has corrected the error.

I downloaded the 126GB file.

Do they have a contact? Ill see if I can shoot them an email about it.
I noticed it as well, its present in all versions, It doesnt look like an re-encoding issue tbh, more like a glitch during capture. But its strange that it wasnt noticed and fixed in post...

[benwaggoner]

I'll check that out thank you. Are there any 4K UHD prores The Rings of Power trailers? I'd like to see how close to the stream quality I can get.
Certainly none that are available to the public!

Trailers are generally quite busy so more bit-rates are needed for high scene-cut segments. I think it would be a good test also.
Also for the newly updated --hist-scenecut algorithm.

[HD MOVIE SOURCE]

Certainly none that are available to the public!


Also for the newly updated --hist-scenecut algorithm.

Interesting, so what has changed for --hist-scenecut algorithm? Scenecuts are something I honestly haven't played around with, is there anything that could help with keyint=24 BD content? Making scenecuts hold higher bit-rates or anything like that?

[HD MOVIE SOURCE]

I noticed it as well, its present in all versions, It doesnt look like an re-encoding issue tbh, more like a glitch during capture. But its strange that it wasnt noticed and fixed in post...

Very strange, we noticed it on first viewing, was really easy to spot. If it was a capture issue, couldn't they have blurred or managed it somehow is post?

I've checked multiple versions and they all contain the glitch.

[Forteen88]

Today I did a new encode with SolLevante_SDRv2_1080p24_8bit.y4m as video-source.
My encode filename is SolLevante_SDRv2_1080p24_8bit_out(MC-HEVC10,24fps,Aspect16-9,ColorRange-Full,2pass,PQ30,target1000,max4000,AdaptiveBFramePlacement).mp4
Using MainConcept TotalCode Studio 5.30 (which uses MainConcept H.265/HEVC video encoder Version: 12.2.0.3600)
MC-HEVC10 Main 10(Main 10)@4.1 (standard settings except I enabled "Adaptive B-Frame Placement"). 24fps, Aspect16:9, ColorRange-Full, 2pass, PQ30 (which is maximum quality but longest encode-time). Only the default 7 B-Frames.
Target Bitrate: 1000kbps
Max bitrate: 4000kbps
Size: 31.45 MB
https://www.sendspace.com/file/na8jbn

I see lots of blockings, like in BenWaggoner's x265-encode.
EDIT: Oh, I also see now that I should've used 8bit, not 10bit in this challenge, but I think that more people here are interested in 10bit-encodes.
BenWaggoner wrote: "This specific test is 8-bit specific, mainly because comparing 8-bit encodes is less fraught.
But a 10-bit HDR test would be an obvious next step. Perhaps with Sol Levante."
Also, shouldn't have set color range to FULL (which was the default in TotalCode Studio), I should have set it to "Clamped" (aka "Limited"). MSU Video Quality Measurement Tool doesn't allow different color range videos to be compared.

[Forteen88]

Sol Levante's 4K HDR source is available under Creative Commons, from which I derived an 8-bit SDR 1080p .y4m (https://1drv.ms/u/s!AlvIQZWsyeO-k9llZI15s0x3uwd_nQ?e=PlqcNz), as 8-bit SDR playback and testing is still a lot more available.

I've kicked off a 1000 Kbps test encode with x265 for reference that I should post tomorrow.How come the Sol Levante's 4K HDR source is 4:23 minutes long but that x265-encode of it is only 4:01 minutes long?

[DTL]

With all the talk about VP9 and AV1 and VVC and different encoder implementations for all of them, I thought it might be fun to set up an open challenge for folks to deliver the best possible quality for each.

To that end, in a semi-inebriated late-night conversation at IBC, we defined a scenario relevant to some important real-world scenarios that reasonably stress current encoders.

No preprocessing




As for the 'real-world' moving pictures content physically damaged by 'real physics' photon shot noise it is no good to limit 'preprocessing'. And it significantly limit 'compressability' of moving pictures content.

As we see with AV1 encoder it may internally apply 'very slight' denoise of about 3..5 averaging frames and 'massive beat' HEVC in compression tests to xx% .

But if allow to make preprocessing - the total challenge is turned in comparison of quality of denoiser+MPEG pair.

As I see modern video cameras to get 'real world' images have good progress of 'internal denoisers' so the world of broadcasting really moves to this direction. When you buy new set of video cameras with lower noise to your studio with less noise you also got great benefit to the quality of the compressed by MPEG encoders content for broadcasting. But it may be also simulated by (much cheaper) denoise hardware unit before your master MPEG coder. Or even software of zero price if you make software file-based processing and use software MPEG encoder.

Also internally both temporal denoiser and MPEG encoder based on the same ideas of motion tracking (block or object based) so may use same hardware to make motion estimation (and may be MPEG encoder may reuse motion estimation from denoiser). May be it is already implemented in modern codecs after HEVC - like in AV1.

So the 'preprocessing' between real world and MPEG coder is really essential part of total moving pictures compression process. To remove 'real world' random data and to clean really required visual information about scene from random noise of intermediate scene-view transfer media of photons flux.
The inter-frame 'denoiser' simply simulate video camera with more accumulating time per each scene object in compare with 'primary scene frame-based' camera. Primary camera (if not using internal interframe digital denoise) is limited to inter-frame time interval to accumulate photons. Also can not perform individual scene objects trackng.

The 'motion compensated denoiser' can extend accumilating time to about total visibility time of the object in the cut-scene and perform individual tracking if each scene object is not static relative to the primary video camera. So it simulates massive array (equal to the blocks number in blocks-based denoiser) of 'secondary video cameras' with individual tracking and much more extending data accumulating time without motion blur.

And after this 2-stages physical + simulated secondary video cameras scene data transform you got more clean scene data to MPEG encoder and pass it to simple enough MPEG encoder and got better output quality because MPEG can now spent more bits to the real scene objects encoding and not to residual noise encoding after non-complete motion compensation of nosied blocks.

[benwaggoner]

Interesting, so what has changed for --hist-scenecut algorithm? Scenecuts are something I honestly haven't played around with, is there anything that could help with keyint=24 BD content? Making scenecuts hold higher bit-rates or anything like that?
--hist-scenecut is supposed to do better scene cut decisions, so it would help in that regard. I've not heard much positive feedback that it does so, particularly in pre-3.5 implementations.

--scenecut-aware-qp would be of more specific interest, as it will save some bits around natural scene cuts where the big temporal discontinuity will mask small ones for a few frames. I've not experimented with it much myself, but the idea is certainly sound.

[Boulder]

--hist-scenecut definitely works better than the classic mode in 8-bit encodes and 10-bit HDR encodes which are not black and white.