Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Video Encoding > High Efficiency Video Coding (HEVC)

Reply
 
Thread Tools Search this Thread Display Modes
Old 23rd March 2020, 19:24   #61  |  Link
Funky080900
Registered User
 
Join Date: Aug 2019
Posts: 6
libaom 1Mbps: https://drive.google.com/file/d/1gEw...ew?usp=sharing

Code:
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
Funky080900 is offline   Reply With Quote
Old 24th March 2020, 05:49   #62  |  Link
Tadanobu
Registered User
 
Join Date: Sep 2019
Posts: 36
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.
Tadanobu is offline   Reply With Quote
Old 24th March 2020, 15:27   #63  |  Link
Funky080900
Registered User
 
Join Date: Aug 2019
Posts: 6
First denoise the video
Code:
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
Code:
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.
Attached Files
File Type: zip film_grain.zip (126.9 KB, 25 views)
Funky080900 is offline   Reply With Quote
Old 24th March 2020, 18:27   #64  |  Link
Blue_MiSfit
Derek Prestegard IRL
 
Blue_MiSfit's Avatar
 
Join Date: Nov 2003
Location: Los Angeles
Posts: 5,696
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.
Blue_MiSfit is offline   Reply With Quote
Old 25th March 2020, 20:55   #65  |  Link
quietvoid
Registered User
 
Join Date: Jan 2019
Posts: 70
Quote:
Originally Posted by Blue_MiSfit View Post
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.
quietvoid is offline   Reply With Quote
Old 27th March 2020, 00:06   #66  |  Link
foxyshadis
ангел смерти
 
foxyshadis's Avatar
 
Join Date: Nov 2004
Location: Lost
Posts: 9,496
Quote:
Originally Posted by Blue_MiSfit View Post
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.
__________________
There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order.
foxyshadis is offline   Reply With Quote
Old 27th March 2020, 01:08   #67  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 9,944
Quote:
Originally Posted by Blue_MiSfit View Post
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...
__________________
LAV Filters - open source ffmpeg based media splitter and decoders
nevcairiel is offline   Reply With Quote
Old 27th March 2020, 02:23   #68  |  Link
Blue_MiSfit
Derek Prestegard IRL
 
Blue_MiSfit's Avatar
 
Join Date: Nov 2003
Location: Los Angeles
Posts: 5,696
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?
Blue_MiSfit is offline   Reply With Quote
Old 30th March 2020, 06:30   #69  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 3,260
Quote:
Originally Posted by nevcairiel View Post
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.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 23rd April 2020, 11:37   #70  |  Link
Sagittaire
Testeur de codecs
 
Sagittaire's Avatar
 
Join Date: May 2003
Location: France
Posts: 2,488
Quote:
Originally Posted by Funky080900 View Post
libaom 1Mbps: https://drive.google.com/file/d/1gEw...ew?usp=sharing

Code:
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 ... ;-)
__________________
Le Sagittaire ... ;-)

1- Ateme AVC or x264
2- VP7 or RV10 only for anime
3- XviD, DivX or WMV9

Last edited by Sagittaire; 23rd April 2020 at 11:44.
Sagittaire is offline   Reply With Quote
Old 23rd April 2020, 23:22   #71  |  Link
Blue_MiSfit
Derek Prestegard IRL
 
Blue_MiSfit's Avatar
 
Join Date: Nov 2003
Location: Los Angeles
Posts: 5,696
Quote:
Originally Posted by Sagittaire View Post
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!
Blue_MiSfit is offline   Reply With Quote
Old 24th April 2020, 00:03   #72  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 3,260
Quote:
Originally Posted by Sagittaire View Post
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.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 24th April 2020, 11:28   #73  |  Link
Sagittaire
Testeur de codecs
 
Sagittaire's Avatar
 
Join Date: May 2003
Location: France
Posts: 2,488
Quote:
Originally Posted by benwaggoner View Post
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 ... ;-)
__________________
Le Sagittaire ... ;-)

1- Ateme AVC or x264
2- VP7 or RV10 only for anime
3- XviD, DivX or WMV9

Last edited by Sagittaire; 24th April 2020 at 11:54.
Sagittaire is offline   Reply With Quote
Old 24th April 2020, 20:24   #74  |  Link
Funky080900
Registered User
 
Join Date: Aug 2019
Posts: 6
Quote:
Originally Posted by Sagittaire View Post
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.
Funky080900 is offline   Reply With Quote
Old 25th April 2020, 13:11   #75  |  Link
Sagittaire
Testeur de codecs
 
Sagittaire's Avatar
 
Join Date: May 2003
Location: France
Posts: 2,488
@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
__________________
Le Sagittaire ... ;-)

1- Ateme AVC or x264
2- VP7 or RV10 only for anime
3- XviD, DivX or WMV9

Last edited by Sagittaire; 25th April 2020 at 13:29.
Sagittaire is offline   Reply With Quote
Old 27th April 2020, 23:15   #76  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 3,260
Quote:
Originally Posted by Sagittaire View Post
@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.

Quote:
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.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 28th April 2020, 02:31   #77  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 3,260
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.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 28th April 2020, 02:56   #78  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 3,260
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
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 28th April 2020, 08:04   #79  |  Link
Sagittaire
Testeur de codecs
 
Sagittaire's Avatar
 
Join Date: May 2003
Location: France
Posts: 2,488
Quote:
Originally Posted by benwaggoner View Post
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).

Code:
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 ...
__________________
Le Sagittaire ... ;-)

1- Ateme AVC or x264
2- VP7 or RV10 only for anime
3- XviD, DivX or WMV9

Last edited by Sagittaire; 28th April 2020 at 08:30.
Sagittaire is offline   Reply With Quote
Old 28th April 2020, 08:44   #80  |  Link
Sagittaire
Testeur de codecs
 
Sagittaire's Avatar
 
Join Date: May 2003
Location: France
Posts: 2,488
@ 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.
__________________
Le Sagittaire ... ;-)

1- Ateme AVC or x264
2- VP7 or RV10 only for anime
3- XviD, DivX or WMV9

Last edited by Sagittaire; 28th April 2020 at 12:11.
Sagittaire is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 10:55.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, vBulletin Solutions Inc.