multithreaded x264 quality loss?

Boogerlad · 11th July 2010, 00:07

hi, I'm a forum lurker =)
before, x264 used slicing of each frame for multithreading, but I heard it's now a frame based multithreading system. Is there still that quality loss for each additional thread? If so, how much percentage?

thanks!

Dark Shikari · 11th July 2010, 00:10

Negligible.

Boogerlad · 11th July 2010, 00:48

one more question; Is it possible to go even better than the quality in the "placebo" preset?

Mutant_Fruit · 11th July 2010, 00:51

Sure, use lossless

Boogerlad · 11th July 2010, 01:54

doesn't lossless give you the worst compression ratio? like, ultra fast and placebo could be the same size, but placebo would look better. Lossless would look better than placebo, but the file size would be bigger.

Audionut · 11th July 2010, 02:41

--preset placebo --tune grain --keyint 24 --qpmin 0 --chroma-qp-offset -12 --merange 256

Dark Shikari · 11th July 2010, 02:53

Quote:

Originally Posted by Audionut

--preset placebo --tune grain --keyint 24 --qpmin 0 --chroma-qp-offset -12 --merange 256

At the same bitrate, that will probably produce much worse results

onesloth · 11th July 2010, 13:13

Quote:

Originally Posted by Boogerlad

one more question; Is it possible to go even better than the quality in the "placebo" preset?

There is a reason the preset is named 'placebo'

sonnati · 18th July 2010, 14:48

Recently I tested a server with two 6-cores (12 threads) xeons for a total of 24 threads. Using a preset veryslow and thread auto I have had a lot of artifacts in fast moving scenes expecially in CBR where the final average bitrate was considerably lower than the desired.
This strange behaviour disappeared setting a low thread number, like 6 or 8.

Dark Shikari · 18th July 2010, 20:15

Quote:

Originally Posted by sonnati

Recently I tested a server with two 6-cores (12 threads) xeons for a total of 24 threads. Using a preset veryslow and thread auto I have had a lot of artifacts in fast moving scenes expecially in CBR where the final average bitrate was considerably lower than the desired.
This strange behaviour disappeared setting a low thread number, like 6 or 8.

Ratecontrol tends to not adapt fast enough for 1-pass CBR at extremely large thread numbers. I would recommend avoiding very large thread numbers for that reason in CBR mode.

burfadel · 19th July 2010, 03:23

Generally CBR should be avoided if possible anyway, if encoding to a certain bitrate to ensure a final output filesize 2-pass (ABR) is much more suitable. If file size isn't so much an issue and you want to approximate an output quality then CRF may be more suitable.

If you want something decent above standard settings, try something like:
<code>--rc-lookahead 80 --nr 900 --bframes 6 --b-adapt 2 --direct auto --subme 10 --trellis 2 --psy-rd 1:0.4 --me umh --merange 24 --aq-mode 2 --sync-lookahead 24</code>

Very similar to the presets, but they're my preferred settings...

Main things for me are --subme 10, --trellis 2, --me umh, and --aq-mode 2

sonnati · 19th July 2010, 11:37

Thank you DS.

PS: I need CBR because I'm encoding for Satellite Broadcasting.

11th July 2010, 00:07	#1 \| Link
Boogerlad Registered User Join Date: Oct 2009 Posts: 24	multithreaded x264 quality loss? hi, I'm a forum lurker =) before, x264 used slicing of each frame for multithreading, but I heard it's now a frame based multithreading system. Is there still that quality loss for each additional thread? If so, how much percentage? thanks!

11th July 2010, 00:10	#2 \| Link
Dark Shikari x264 developer Join Date: Sep 2005 Posts: 8,688	Negligible. __________________ Follow x264 development progress \| akupenguin quotes \| x264 git status ffmpeg and x264-related consulting/coding contracts \| Doom10

11th July 2010, 00:51	#4 \| Link
Mutant_Fruit Registered User Join Date: Apr 2004 Posts: 287	Sure, use lossless __________________ Nothing to see here...

11th July 2010, 02:41	#6 \| Link
Audionut Registered User Join Date: Nov 2003 Posts: 1,272	--preset placebo --tune grain --keyint 24 --qpmin 0 --chroma-qp-offset -12 --merange 256 __________________ http://www.7-zip.org/

11th July 2010, 00:48	#3 \| Link
Boogerlad Registered User Join Date: Oct 2009 Posts: 24	one more question; Is it possible to go even better than the quality in the "placebo" preset?

11th July 2010, 01:54	#5 \| Link
Boogerlad Registered User Join Date: Oct 2009 Posts: 24	doesn't lossless give you the worst compression ratio? like, ultra fast and placebo could be the same size, but placebo would look better. Lossless would look better than placebo, but the file size would be bigger.

18th July 2010, 14:48	#9 \| Link
sonnati Registered User Join Date: Jun 2008 Posts: 20	Recently I tested a server with two 6-cores (12 threads) xeons for a total of 24 threads. Using a preset veryslow and thread auto I have had a lot of artifacts in fast moving scenes expecially in CBR where the final average bitrate was considerably lower than the desired. This strange behaviour disappeared setting a low thread number, like 6 or 8.

19th July 2010, 03:23	#11 \| Link
burfadel Registered User Join Date: Aug 2006 Posts: 2,234	Generally CBR should be avoided if possible anyway, if encoding to a certain bitrate to ensure a final output filesize 2-pass (ABR) is much more suitable. If file size isn't so much an issue and you want to approximate an output quality then CRF may be more suitable. If you want something decent above standard settings, try something like: <code>--rc-lookahead 80 --nr 900 --bframes 6 --b-adapt 2 --direct auto --subme 10 --trellis 2 --psy-rd 1:0.4 --me umh --merange 24 --aq-mode 2 --sync-lookahead 24</code> Very similar to the presets, but they're my preferred settings... Main things for me are --subme 10, --trellis 2, --me umh, and --aq-mode 2

19th July 2010, 11:37	#12 \| Link
sonnati Registered User Join Date: Jun 2008 Posts: 20	Thank you DS. PS: I need CBR because I'm encoding for Satellite Broadcasting.