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 12th December 2017, 10:42   #21  |  Link
excellentswordfight
Lost my old account :(
 
Join Date: Jul 2017
Posts: 322
Quote:
Originally Posted by jd17 View Post
I did not know that is possible.
However, what would be the benefit?

Isn't one of the reasons to use a CRF instead of a bitrate target to be freed from any bitrate constraints?

I thought CRF uses whatever bitrate necessary for each moment to achieve a certain degree of quality...
If CRF uses whatever is needed - what difference would a 2pass encode even make?
CRF with maxrate and bufsize constrains would imo only make sense for big streaming services, the use of CRF there would not be to increase quality but to lower filesize (i.e. storage cost) without much of an quality loss for low complexity material.

So for 1080p24 streaming it would look something like this
Code:
--crf 20 --vbv-maxrate 9000 --vbv-bufsize 12000 --keyint 48 --min-keyint 24 --rc-lookahead 48
And agree, I dont see a good reason for 2pass CRF even if it's possible.

Nico8583, what are kind of playback environment are you aiming for? It sounds like CRF encoding with the lowest preset you find tolerable is what you are looking for. I would start at preset slow crf 18 and go from there.

Last edited by excellentswordfight; 12th December 2017 at 10:59.
excellentswordfight is offline   Reply With Quote
Old 12th December 2017, 19:10   #22  |  Link
Nico8583
Registered User
 
Join Date: Jan 2010
Location: France
Posts: 851
Thank to all
excellentswordfight, I want to play some Blu ray to x265 movies stored to my NAS on a Samsung 55" TV with a HTPC or a Zidoo X9S. I think to go to CRF18 and Slow preset.
Is the number of threads has an impact to quality ? I can encode on a 4 cores but perhaps I can access to a 16 cores (2 x Intel Xeon 8 cores).
Nico8583 is offline   Reply With Quote
Old 12th December 2017, 21:02   #23  |  Link
jd17
Registered User
 
Join Date: Jun 2017
Posts: 89
Maybe this helps, I created some statistics for my encodes...


Average bitrate of 28 CRF19 / slow / no-sao / 10bit Blu-ray encodes ("regular" movies for me):
5613 kbit/s
That average does include two movies with extreme grain, 14300 and 19000 kbit/s.
Excluding them in the average brings it down to:
4766 kbit/s

Lowest bitrate encode is 2572 kbit/s.


Average bitrate of 27 CRF17 / slow / no-sao / 10bit Blu-ray encodes ("reference" movies for me = very good image quality):
6902 kbit/s
One high grain movie is included (12194 kbit/s).
Average without it:
6699 kbit/s

Lowest bitrate encode is 3777 kbit/s.


These numbers might not seem very low, but you have to consider that these are extremely high quality, transparent or near transparent encodes.
Calculating a similar average for transparent x264 encodes would result in something like 12000-16000 kbit/s.
jd17 is offline   Reply With Quote
Old 12th December 2017, 21:11   #24  |  Link
Nico8583
Registered User
 
Join Date: Jan 2010
Location: France
Posts: 851
Thank you for these informations
Could you give an example of command line ? And why no-sao gives a better quality ? All fast presets use no-sao but all slow preset use sao.
Nico8583 is offline   Reply With Quote
Old 12th December 2017, 21:16   #25  |  Link
sneaker_ger
Registered User
 
Join Date: Dec 2002
Posts: 5,565
Quote:
Originally Posted by Nico8583 View Post
Is the number of threads has an impact to quality ?
More threads can hurt quality but it should be negligible for most users. I would leave threads/pools at auto.
sneaker_ger is offline   Reply With Quote
Old 12th December 2017, 21:23   #26  |  Link
Nico8583
Registered User
 
Join Date: Jan 2010
Location: France
Posts: 851
Quote:
Originally Posted by sneaker_ger View Post
More threads can hurt quality but it should be negligible for most users. I would leave threads/pools at auto.
I let it to auto and x265 detects 4, 8 or 16 threads.
I read more threads can hurt quality with x264 but I didn't know with x265, so it's the same, thank you. Do you know a document about that ( threads number vs quality) ?
Nico8583 is offline   Reply With Quote
Old 13th December 2017, 10:09   #27  |  Link
jd17
Registered User
 
Join Date: Jun 2017
Posts: 89
Quote:
Originally Posted by Nico8583 View Post
Could you give an example of command line ?
I use Handbrake, Hybrid or both for my encodes. I see no drawbacks in doing that. It makes things comfortable and saves me some time.

That being said, there are no changes to the x265 defaults in my encodes apart from:
--output-depth 10
--preset slow
--no-sao
--crf 17 / 19
--keyint 240 (for 23.976p / 24p movies)
--min-keyint 24 (for 23.976p / 24p movies)

Quote:
And why no-sao gives a better quality ?
I suggest you make a few comparisons yourself.

Here are links to some old stills I created:
https://forum.doom9.org/showpost.php...9&postcount=17

They were done with preset medium, but that does not matter since you can just compare sample 4 and 5 to see the impact of sao and look at sample 1 for reference.
The difference between --sao and --no-sao would be similar with slow encodes.

The gist for me:
--sao = blurred, smoothed
--no-sao = detailed, grain retention, much closer to the source

(People around here sometimes translate SAO to "smooth all objects" for fun. You might understand why... )

Quote:
All fast presets use no-sao but all slow preset use sao.
Only ultrafast and superfast disable --sao by default. I think the reason for that is, that encoding without --sao is also a bit quicker. It's not much but every little bit counts for these "extreme" presets.
jd17 is offline   Reply With Quote
Old 13th December 2017, 10:35   #28  |  Link
Nico8583
Registered User
 
Join Date: Jan 2010
Location: France
Posts: 851
Thank you, I'll look at it when I'll be at home.
Do you have made new tests with newer version of x265 ? It seems there are some improvments with sao, no ?
Nico8583 is offline   Reply With Quote
Old 13th December 2017, 10:55   #29  |  Link
jd17
Registered User
 
Join Date: Jun 2017
Posts: 89
To my knowledge, nothing changed since 2.4 regarding sao.

https://x265.readthedocs.io/en/defau...easenotes.html
jd17 is offline   Reply With Quote
Old 13th December 2017, 22:20   #30  |  Link
Nico8583
Registered User
 
Join Date: Jan 2010
Location: France
Posts: 851
You're right
I'm going to make some tests like you with a short Blu ray movie (8bit vs 10bit, medium vs slow, sao vs no-sao, CRF18 vs CRF20...)
Nico8583 is offline   Reply With Quote
Old 14th December 2017, 10:50   #31  |  Link
jd17
Registered User
 
Join Date: Jun 2017
Posts: 89
Have fun testing and let us know how it goes!
jd17 is offline   Reply With Quote
Old 14th December 2017, 22:38   #32  |  Link
Nico8583
Registered User
 
Join Date: Jan 2010
Location: France
Posts: 851
No problem, I'll let you know
Another question : Handbrake adds no-strong-intra-smoothing and no-rect with all profiles, do you let it or do you remove it ?
Nico8583 is offline   Reply With Quote
Old 15th December 2017, 08:34   #33  |  Link
jd17
Registered User
 
Join Date: Jun 2017
Posts: 89
Quote:
Originally Posted by Nico8583 View Post
Another question : Handbrake adds no-strong-intra-smoothing and no-rect with all profiles, do you let it or do you remove it ?
Really? Are you sure?
If so, it must be a recent development...
What HandBrake build do you use?

I specifically tested no-strong-intra-smoothing vs. strong-intra-smoothing and actually preferred the latter:
https://forum.doom9.org/showthread.p...42#post1811742

I will have a look at some recent files I encoded once I get home.
jd17 is offline   Reply With Quote
Old 15th December 2017, 12:38   #34  |  Link
Nico8583
Registered User
 
Join Date: Jan 2010
Location: France
Posts: 851
I'm using Handbrake 1.0.7 (2017040900) and I choose H.265 MKV 1080p30 preset as base but when I choose every preset and change to x265 it adds automatically these parameters.
Nico8583 is offline   Reply With Quote
Old 15th December 2017, 13:13   #35  |  Link
jd17
Registered User
 
Join Date: Jun 2017
Posts: 89
Ah... I have never used any of the HandBrake presets (I thought you referred to fast, medium, slow etc. before), I created my own ones...
I can send you a screenshot later if you like.

I'd also recommend using the latest nightly, which includes x265 2.6.
1.07 is still 2.3 I think.

Last edited by jd17; 15th December 2017 at 13:30.
jd17 is offline   Reply With Quote
Old 15th December 2017, 13:40   #36  |  Link
Nico8583
Registered User
 
Join Date: Jan 2010
Location: France
Posts: 851
Even if I don't choose a preset it adds "strong-intra-smoothing=0:rect=0" (Extra options) to x265 options. I can remove it of course.
Thank you for the screenshot, I'll look at it when you could add it
Nico8583 is offline   Reply With Quote
Old 15th December 2017, 13:45   #37  |  Link
Arhu
Registered User
 
Join Date: Nov 2003
Posts: 12
Quote:
Originally Posted by jd17 View Post
I suggest you make a few comparisons yourself.
(..)
The gist for me:
--sao = blurred, smoothed
--no-sao = detailed, grain retention, much closer to the source
I've been in your footsteps, by the way, but my conclusions are slightly different for sao:

--no-sao = dirty, edged, artificial grain
--sao = more accurate representation of the source

There has been talk by a few users in the baseline settings thread that --no-sao may have looked better before (version < 2.5) but maybe doesn't anymore. I only started my encoding tests with 2.5 so I wouldn't know myself, just that I prefer --sao.


Also worth testing: --aq-mode 1 (default) vs. --aq-mode 3. I prefer the latter because the default often produced artifacts in dark areas for me even with lower CRF values.
Arhu is offline   Reply With Quote
Old 15th December 2017, 14:03   #38  |  Link
jd17
Registered User
 
Join Date: Jun 2017
Posts: 89
Quote:
Originally Posted by Arhu View Post
my conclusions are slightly different for sao
Sure!
This is why everyone should do a few simple comparisons themselves.

Quote:
There has been talk by a few users in the baseline settings thread that --no-sao may have looked better before (version < 2.5) but maybe doesn't anymore. I only started my encoding tests with 2.5 so I wouldn't know myself, just that I prefer --sao.
The only recent change to --sao I know of happened in 2.4.
I tested and compared 2.3 and 2.4 both with and without --sao and came to the same conclusion.
For my content (non-anime), I definitely prefer --no-sao, be it 2.3 or 2.4.

Quote:
Also worth testing: --aq-mode 1 (default) vs. --aq-mode 3. I prefer the latter because the default often produced artifacts in dark areas for me even with lower CRF values.
Do you encode in 8bit or 10bit?
jd17 is offline   Reply With Quote
Old 15th December 2017, 15:11   #39  |  Link
Arhu
Registered User
 
Join Date: Nov 2003
Posts: 12
Quote:
The only recent change to --sao I know of happened in 2.4.
2.5 introduced new lambda tables for 10 bit though, which could perhaps account for the difference? *shrugs*

Quote:
Originally Posted by jd17 View Post
Do you encode in 8bit or 10bit?
10 bit, although the same goes for 12 bit.
I did experiment with 8 bit for some time because I thought 10 bit encoding had a bug in x265, which turned out to be a dithering related ffmpeg issue but was mostly just a display problem (later fixed by Ma0).

Anyway, it also depends on the display setting. I have an 8-bit LCD display and don't really see anything wrong with --aq-mode 1 when using the display's default SRGB setting (so I guess it's working as intended), but in "movie mode" with elevated chroma artifacts become visible in dark scenes around the edges of moving, brighter objects. Looks like mosquito noise or ringing. --aq-mode 3 helped with these artifacts much more than a CRF reduction did.
Arhu is offline   Reply With Quote
Old 15th December 2017, 18:10   #40  |  Link
Nico8583
Registered User
 
Join Date: Jan 2010
Location: France
Posts: 851
Thank you for your participation, it's good to have opinions on the subject
I do all my tests with 2.6 so I can't compare with 2.3 and 2.4.
x265 documentation about aq-mode :
Quote:
Adaptive Quantization operating mode. Raise or lower per-block quantization based on complexity analysis of the source image. The more complex the block, the more quantization is used. This offsets the tendency of the encoder to spend too many bits on complex areas and not enough in flat areas.

0. disabled
1. AQ enabled (default)
2. AQ enabled with auto-variance
3. AQ enabled with auto-variance and bias to dark scenes. This is recommended for 8-bit encodes or low-bitrate 10-bit encodes, to prevent color banding/blocking.
So I may try with aq-mode=3 also
Nico8583 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 15:38.


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