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. |
22nd September 2019, 12:33 | #1 | Link |
Registered User
Join Date: Mar 2016
Posts: 16
|
Is x265 fundamentally broken?
I just found this: https://bitbucket.org/multicoreware/...goes-the-wrong
It seems that x265 preset options are fundamentally broken. The slower presets will just increase file size dramatically (up to 50%) without offering better image quality (maybe in benchmarks, but not in real world). What do you think? Is it still worth using x265 or should we look for alternatives? |
22nd September 2019, 12:40 | #2 | Link |
Registered Developer
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,348
|
The issue smells of half-Information and no actual scientific testing.
Size between presets is not comparable when using CRF, if you want proper comparison then either use a two pass fixed Bitrate Encode, or adjust the CRF value until output size is similar. And only then compare quality - both objectively and subjectively. Nothing in that issue has the makings of decent testing. And CRF has always been vastly misunderstood by many people. It's not designed to give a consistent file size over a wide range of settings, as such file size is not a comparable value at all if you change preset with CRF. Consistent file size is provided by ABR or CBR modes instead.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders Last edited by nevcairiel; 22nd September 2019 at 12:45. |
22nd September 2019, 12:49 | #4 | Link |
Registered Developer
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,348
|
CRF is only "constant quality" when no other settings change. The "constant quality" refers to the encode you are doing right now, ie. the quality is constant throughout the entire encode. Its not constant when you change every other setting.
If you want to compare quality vs. size, do as I explained above, dial in settings that produce the same file size, and _then_ compare the quality of these. Then you can only begin to judge how different slow vs. fast is.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders Last edited by nevcairiel; 22nd September 2019 at 12:53. |
22nd September 2019, 13:05 | #5 | Link |
Registered User
Join Date: Mar 2016
Posts: 16
|
This is very confusing. Then the metric used by CRF to determine quality must be very fragile and contra intuitive. I'd expected that it will optimize for some visual model to offer such and such quality level. But I understand your point.
|
23rd September 2019, 19:51 | #6 | Link | |
Registered User
Join Date: Feb 2002
Location: San Jose, California
Posts: 4,407
|
Quote:
None of the "constant quality" modes from any codec are constant when you change other settings, x264 behaves in almost exactly the same way. In general the faster settings have noticeably lower quality at the same crf.
__________________
madVR options explained |
|
24th September 2019, 07:01 | #7 | Link |
Registered User
Join Date: Aug 2010
Location: Athens, Greece
Posts: 2,901
|
It's been already exposed many times, that slower modes of CRF using x265, are desperately trying to extract quality from the video stream repeating the same algorithms again and again, but most of the times they increase the size of the encoded video without actually increasing quality.
It would be wise to stay at "x265 slow" and not going slower, but nowadays it would be even wiser to try a hardware encoder of H.265 like Turing's which produces low size, good quality (even better in many cases than x265) and extremely fast H.265 encodings.
__________________
Win 10 x64 (19042.572) - Core i5-2400 - Radeon RX 470 (20.10.1) HEVC decoding benchmarks H.264 DXVA Benchmarks for all |
24th September 2019, 11:48 | #8 | Link | |
Registered User
Join Date: Feb 2002
Location: San Jose, California
Posts: 4,407
|
Quote:
I think you do not understand the consequences of this 'repeating the same algorithms again and again', it only keeps the best choice of out everything it tries.
__________________
madVR options explained |
|
24th September 2019, 13:51 | #9 | Link |
Registered User
Join Date: Aug 2010
Location: Athens, Greece
Posts: 2,901
|
According to an analysis I read recently, lower presets will get you smaller file sizes.
The preset tells your encoder how hard to try to get the quality, so even if it reaches the right quality but still has time to search, it will try find ways to decrease the data required even further. But there’s an anomaly, sometimes using slower presets (or larger parameters) you will get a larger file size because sometimes with CQ the encoder will search within the parameters you allowed it but couldn’t find enough quality, so it just saves the frame. But if your parameters are searching far and wide for more options, it can locate tiny pieces of extra quality to fit in and once it finds them, it will use however many bits it needs to fill the target.
__________________
Win 10 x64 (19042.572) - Core i5-2400 - Radeon RX 470 (20.10.1) HEVC decoding benchmarks H.264 DXVA Benchmarks for all |
24th September 2019, 20:01 | #10 | Link |
Registered User
Join Date: Feb 2002
Location: San Jose, California
Posts: 4,407
|
Slower presets are not setting "how hard to try to get the quality". That doesn't even make sense, speed settings don't change any quality metrics, that is what CRF sets. A Slower preset allows x265 to test more encoding methods (it always picks the most efficient method) but it does not make it want to preserve detail any more or weight quality v.s. size differently.
Do you have any sources? I think this is one of those wrong urban legends based on bad testing (using CRF encodes) and misunderstanding how x265 works. Also the desire to say the faster preset is better quality is pretty tempting if you feel like you should use the best quality possible but don't actually want it to be that slow. Sour grapes, if you will.
__________________
madVR options explained |
24th September 2019, 20:31 | #11 | Link |
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,770
|
Reading through the readthedocs, it's obvious how quality is different between presets, because different modes controlled by different presets use different ways to measure and optimize quality.
Presets control --rd, for a big example. What even gets included in rate distortion optimization changes with rd level. So how chroma quality is measured and optimized changes between 2 and 4. Something with complex chroma running at a fast preset might give smaller size because it is just making the chroma look terrible. aq-mode also has fundamental impact on how the codec works in practice. |
24th September 2019, 20:57 | #12 | Link |
Registered User
Join Date: Aug 2010
Location: Athens, Greece
Posts: 2,901
|
It's late September of 2019.
I think it's time to declare project x265 dead. It can't get any other AVX2/AVX512 optimizations and it can't improve quality in the same size any more. Time to move on to H.265 hardware encoding and other codecs (AV1)
__________________
Win 10 x64 (19042.572) - Core i5-2400 - Radeon RX 470 (20.10.1) HEVC decoding benchmarks H.264 DXVA Benchmarks for all |
24th September 2019, 21:05 | #13 | Link |
ffx264/ffhevc author
Join Date: May 2007
Location: /dev/video0
Posts: 1,844
|
I think you're wrong. If x265 is "dead" so is x264. Yet they still get developed further. x265 first listens to its customers and what they want. That's the first priority of the x265 devs. After this comes all other
|
24th September 2019, 21:08 | #14 | Link | |
Registered User
Join Date: Feb 2002
Location: San Jose, California
Posts: 4,407
|
Quote:
Hardware encoding is still offers worse quality and AV1 and similar is not ready yet and is not supported by current hardware for playback. I am totally confused as to what your point is. You just irrationally hate x265?
__________________
madVR options explained |
|
25th September 2019, 04:51 | #15 | Link | |
Registered User
Join Date: May 2009
Posts: 331
|
Quote:
Hardware encoding is garbage. You have fixed functions that can not be changed until the actual hardware itself is updated, at extreme cost to the user. AV1 is no where near ready for home users. It requires a literal order of magnitude of processing power over HEVC to get not even similar results. If we're to declare it dead, should we declare MPEG2 dead as well? MPEG1? How about Huffy? |
|
25th September 2019, 17:20 | #16 | Link | |
結城有紀
Join Date: Dec 2003
Location: NJ; OR; Shanghai
Posts: 894
|
Quote:
When AVXx was first introduced, it was even slower than SSEx sometimes. How about now? We all enjoy AVX2 bringing 20-30+% performance boost. AVX512 right now is not even widely supported, and there's only Intel implementation. It's also widely known that Intel down clock when executing lots of AVX2 code. When AMD finally have a proper AVX2 implementation, we observe that it does not down clock. So we can still hope in a day when we can have full speed AVX512 and it'll eventually outperform AVX2. |
|
25th September 2019, 18:14 | #17 | Link |
Registered User
Join Date: Aug 2010
Location: Athens, Greece
Posts: 2,901
|
Excellent post, agreed in everything.
But I must say that my low TDP 65W Coffee Lake Refresh - Core i3 9100F using a budget motherboard and a budget cooler can keep the absolute, total power virus called Prime95 SmallFFTs running at all Core turbo clock exactly the same as any workload while running extremely optimized AVX2-FMA3 code (for the few minutes that I was running the torturing test) So, after the "buggy" first AVX2 implementation of Haswell, Intel has improved a lot its AVX2 implementation in next generations.
__________________
Win 10 x64 (19042.572) - Core i5-2400 - Radeon RX 470 (20.10.1) HEVC decoding benchmarks H.264 DXVA Benchmarks for all |
27th September 2019, 19:19 | #18 | Link | |
Derek Prestegard IRL
Join Date: Nov 2003
Location: Los Angeles
Posts: 5,989
|
Quote:
It's far from dead. If it's dead to you that's fine, but that's not what the industry thinks. In any case, there's plenty of interesting developments in AV1 and hardware HEVC encoding, BTW - all the off-topic posts related to an older version of this statement have been moved by the HEVC forum moderation team. Let's stay on topic, please. |
|
27th September 2019, 19:27 | #19 | Link | |||
Software Developer
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,248
|
Quote:
If we ignore MB-Tree for now, it is pretty much just a "complexity" measure based on the expected frame size (in bits) in conjunction with the qComp ("quantizer curve compression") algorithm and a fixed (used-defined) scaling factor. Read here for some basic information on how the different RC modes work: https://code.videolan.org/videolan/x...atecontrol.txt Quote:
On the subject of presets and CRF mode: In general, a "slower" preset improves the "quality per bit" ratio (better quality at same file size), at the cost of slower encoding speed. Conversely, a "faster" preset improves encoding speed at the cost of a worse "quality per bit" ratio (worse quality at same file size). But: When it comes to CRF mode, the is no guarantee (and I think there never was) that a specific CRF value still results in the same absolute file size (average bitrate) after switching to another preset! Therefore, it is quite possible that, after switching to a "slower" preset, you end up with better quality and a larger file – at the same CRF value. That alone doesn't say anything! However, if you carefully adjusted your CRF value, in order to find the highest CRF value that still gives satisfactory quality, and if you did this separately for each preset, then you would probably find that, in the end, the "slower" preset can get away with a smaller file than the "faster" one. Quote:
https://bitbucket.org/multicoreware/...20d244bd49ef17 Also, the longer an encoder has already been under development, the more effort will be required to get an additional improvement. So, it is kind of "natural" that things improve fast at the beginning and slow down after a while...
__________________
Go to https://standforukraine.com/ to find legitimate Ukrainian Charities 🇺🇦✊ Last edited by LoRd_MuldeR; 28th September 2019 at 12:01. Reason: Added "On the subject of presets and CRF mode" |
|||
27th September 2019, 19:31 | #20 | Link |
Software Developer
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,248
|
Please note: All off-topic posts have been moved to "moderation". The same is going to happen to any further post that does not add something relevant to the topic.
__________________
Go to https://standforukraine.com/ to find legitimate Ukrainian Charities 🇺🇦✊ Last edited by LoRd_MuldeR; 27th September 2019 at 19:46. |
|
|