Benwaggoner HEVC encoding challenge

[Tadanobu]

Could you please explain how you generated that film grain table please ? Because grain retention is one of the problem with aomenc. At least with default settings.

[Funky080900]

First denoise the video

ffmpeg -i ToS.y4m -vf nlmeans=s=1.5 denoised.yuv

Then use the noise_model application located under ./examples/noise_model: https://aomedia.googlesource.com/aom.../noise_model.c

noise_model --fps=24/1 --width=1920 --height=800 --i420 --input-denoised=denoised.yuv --input=ToS.yuv --output-grain-table=film_grain.tbl

I only kept sY sCb and sCr because the generated .tbl didn't look good.

[Blue_MiSfit]

WOW.

That is truly impressive. This reinforces my belief that film grain modeling is enormously important and will really make 1 Mbps 1080p totally viable. This is a game changing feature for AV1!

Do any of the encoders have / plan to integrate this in-loop during encoding? Working with YUV intermediates is pretty painful.

[quietvoid]

Originally Posted by Blue_MiSfit

WOW.

That is truly impressive. This reinforces my belief that film grain modeling is enormously important and will really make 1 Mbps 1080p totally viable. This is a game changing feature for AV1!

Do any of the encoders have / plan to integrate this in-loop during encoding? Working with YUV intermediates is pretty painful.

aomenc/libaom supports this with the option --denoise-noise-level=[0..50]
Anything higher than 0 enables denoising and film grain modeling, however there is not much control on the denoising strength/algorithms used.

[foxyshadis]

Originally Posted by Blue_MiSfit

WOW.

That is truly impressive. This reinforces my belief that film grain modeling is enormously important and will really make 1 Mbps 1080p totally viable. This is a game changing feature for AV1!

Do any of the encoders have / plan to integrate this in-loop during encoding? Working with YUV intermediates is pretty painful.

SVT-AV1 also has it, but it's mostly a clone of aomenc's. There have been a few minor changes that should show up in the next release, but FGM is one of those things that engineers are very loathe to touch, since it's all-but-untestable and intentionally introduces randomness.

[nevcairiel]

Originally Posted by Blue_MiSfit

This is a game changing feature for AV1!

H264 has Film Grain Modelling, just noone ever used it because its hard to use correctly.

Maybe we get more lucky this time around and enough engineering time is put into it...

[Blue_MiSfit]

Right, I remember a few devices did but very few.

It's so incredibly useful when delivering streaming video though!

I wonder, everyone agreed that HE-AAC was better than AAC at lower bitrates. That was never controversial. Since FGM is fundamentally similar, why the resistance from engineers?

[benwaggoner]

Originally Posted by nevcairiel

H264 has Film Grain Modelling, just noone ever used it because its hard to use correctly.

Maybe we get more lucky this time around and enough engineering time is put into it...

AV1's implementation is quite a bit better, from people I've talked to who have looked at both. Also, grain removal itself is quite computationally expensive and algorithmically complex, and is a lot more feasible today than it was in 2006 when FGM was a required (but never used) feature of H.264 for HD-DVD.

It wasn't mandatory anywhere else, which also was a huge barrier to adoption. It likely could have become quite useful for 720p streaming circa 2010. Fewer pixels, more MIPS, bigger bitrate challenges.

It's easy to forget that we have >100x more compute available per pixel for 1080p than we did when the HD optical formats launched. I bet the typical AV1 pixel gets >>1000x more MIPS than a launch Blu-ray or HD-DVD.

[Sagittaire]

Originally Posted by Funky080900

libaom 1Mbps: https://drive.google.com/file/d/1gEw...ew?usp=sharing

aomenc --passes=2 --pass=2 --fpf=firstpass.log --target-bitrate=1220 --kf-max-dist=120 --cpu-used=0 -t 4 --deltaq-mode=2 --film-grain-table=film_grain.tbl -o AV1-0.ivf input.y4m

Clearly impressive result but by definition you make pre-process with this encoding technique. And with source with dither it's a considerable advantage. If I make denoising (dithering high frequency cut), no doubt that HEVC will be really better too.

@ benwaggoner

For this challenge at really low bitrate, use source with dithering is not really good idea, because local complexity frequency is really high. Never, I will make direct encoding without preprocess with this source like this.

Anyway I will try ... I have actually time to lose ... ;-)

[Blue_MiSfit]

Originally Posted by Sagittaire

Clearly impressive result but by definition you make pre-process with this encoding technique. And with source with dither it's a considerable advantage. If I make denoising (dithering high frequency cut), no doubt that HEVC will be really better too.

I'd very much like to see denoised HEVC (static pre-processing) vs AV1 with FGM!

[benwaggoner]

Originally Posted by Sagittaire

For this challenge at really low bitrate, use source with dithering is not really good idea, because local complexity frequency is really high. Never, I will make direct encoding without preprocess with this source like this.

Banding is pretty hard to encode as well. Depending on the content and codec, dithering can allow for better quality at lower bitrates than not dithering.

I could probably knock out a non-dithered version if you'd like to try one.

[Sagittaire]

Originally Posted by benwaggoner

Banding is pretty hard to encode as well. Depending on the content and codec, dithering can allow for better quality at lower bitrates than not dithering.

I could probably knock out a non-dithered version if you'd like to try one.

No challenge is challenge ... ;-)

1) After first analyse, VBV (4 Mbps, 12 kbit) seem useless for 1000 kbps encoding. Defaut crf mode with x265 seem don't have VBV saturation in complexe scene.

2) Paradoxaly, certainely that the more complexe encoding will be 2000 kbps enconding with contrained VBV because you have high buffer saturation in complexe scene. But I have solution for that ... ;-)

[Funky080900]

Originally Posted by Sagittaire

Clearly impressive result but by definition you make pre-process with this encoding technique. And with source with dither it's a considerable advantage. If I make denoising (dithering high frequency cut), no doubt that HEVC will be really better too.

@ benwaggoner

For this challenge at really low bitrate, use source with dithering is not really good idea, because local complexity frequency is really high. Never, I will make direct encoding without preprocess with this source like this.

Anyway I will try ... I have actually time to lose ... ;-)

The denoised video was only used for generating the film grain table and not for encoding.
Libaom only ever saw the unaltered source file provided by Benwaggoner.

[Sagittaire]

@benwaggoner

use zone option is legal for this challenge?

After analyse, end credit is really high bitrate zone in constant quality mode (crf, cq or multipass encoding).

before credit zone (frame 14135), bitrate must be at 850 kbps and credit zone is inhabitually long with something like 15% of total frames

[benwaggoner]

Originally Posted by Sagittaire

@benwaggoner

use zone option is legal for this challenge?

It isn't legal in the base version, but I don't mind adding a version with content-specific temporal parameters. The basic test was really to exercise how well the encoder can do with static settings across variable content. But how well is possible no-holds-barred is also interesting.

After analyse, end credit is really high bitrate zone in constant quality mode (crf, cq or multipass encoding).

before credit zone (frame 14135), bitrate must be at 850 kbps and credit zone is inhabitually long with something like 15% of total frames

Yeah, that is a weirdness about this clip. Something with classic scrolling text would give an encoder opportunity to really squeeze and redistribute bits out of what can be really cranked down. All in all, though, ToS was the best broadly available and freely licensed source I found.

[benwaggoner]

I finally got around to posting some encodes comparing x264 --hevc-aq with --aq-mode 4. I reran my old tests using the latest x265 and new parameters. These are 1 Mbps. Just 2-pass VBR at veryslow; the UltraPlacebo versions to follow.

HEVC-AQ
AQ-MODE 4

Curious on which the rest of you think is superior.

[benwaggoner]

Oh, and I see I had a few old oddball things I didn't post before.

Best possible WMV encodes, via Expression Encoder and its built-in version of the VC-1 Professional Encoder SDK.

1000 Kbps
1500 Kbps
2000 Kbps

[Sagittaire]

Originally Posted by benwaggoner

I finally got around to posting some encodes comparing x264 --hevc-aq with --aq-mode 4. I reran my old tests using the latest x265 and new parameters. These are 1 Mbps. Just 2-pass VBR at veryslow; the UltraPlacebo versions to follow.

HEVC-AQ
AQ-MODE 4

Curious on which the rest of you think is superior.

http://jfl1974.free.fr/Videos/ToS/ToS-2.mkv

Well here really better result with more temporal stability and really better edge reproduction. I have really better result in scene introduction on the bridge (between 26 sec and 40 sec for exemple). We can see (real) mosquitoes flying around the actress' head. Really better result too than your previous placebo encoding for my eyes.

- Better subjectif result
- Better objectif result (than Ma encoding for exemple).

encoded 17620 frames in 29373.04s (0.60 fps), 1000.00 kb/s, Avg QP:30.93, Global PSNR: 42.353, SSIM Mean Y: 0.9653839 (14.607 dB)

I make encapsulation in mkv file with HE-AAC 5.1 audio at 128 kbps. I think it's really good quality for only 1000 kbps encoding at 1080p with 5.1 audio.

Test in progress with better psy setting for better subjective result if I can ...

[Sagittaire]

@ benwaggoner

Well it's really curious. I Check previous Ma's enconding or TomV's encoding. And Ma's enconding, TomV's encoding or my encoding seem have really better quality than your placebo encoding (particulary in low motion part). You don't have problem with your encoding profil? You are sure that onedrive don't make reencoding (at upload or at download?). Quality is really bad for me.

and Beamr 5 encoding are the best for my eyes: really good complexity conservation. Certainely high psy (and good) optimisation. I will try to produce better result.

[Opmox]

deleted