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. |
12th December 2017, 10:42 | #21 | Link | |
Lost my old account :(
Join Date: Jul 2017
Posts: 326
|
Quote:
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 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. |
|
12th December 2017, 19:10 | #22 | Link |
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). |
12th December 2017, 21:02 | #23 | Link |
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. |
12th December 2017, 21:23 | #26 | Link | |
Registered User
Join Date: Jan 2010
Location: France
Posts: 851
|
Quote:
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) ? |
|
13th December 2017, 10:09 | #27 | Link | ||
Registered User
Join Date: Jun 2017
Posts: 89
|
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:
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:
|
||
13th December 2017, 10:55 | #29 | Link |
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 |
15th December 2017, 08:34 | #33 | Link | |
Registered User
Join Date: Jun 2017
Posts: 89
|
Quote:
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. |
|
15th December 2017, 13:13 | #35 | Link |
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. |
15th December 2017, 13:40 | #36 | Link |
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 |
15th December 2017, 13:45 | #37 | Link | |
Registered User
Join Date: Nov 2003
Posts: 12
|
Quote:
--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. |
|
15th December 2017, 14:03 | #38 | Link | ||
Registered User
Join Date: Jun 2017
Posts: 89
|
Sure!
This is why everyone should do a few simple comparisons themselves. Quote:
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:
|
||
15th December 2017, 15:11 | #39 | Link | |
Registered User
Join Date: Nov 2003
Posts: 12
|
Quote:
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. |
|
15th December 2017, 18:10 | #40 | Link | |
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:
|
|
|
|