Why does x265 suck so bad?

[JN-]

I did some testing of this a good while back. I found that hevc and h264 levelled out at approximately 70 Mbps, no advantage quality above that. At low bitrates there was a substantial difference in favour of hevc but no way 50%.

Test UHD/4k content, it should close or better than 50% - HEVC use coding techniques tuned for UHD and higher resolution content.

--
typos fixed, sorry

OK, accepted.

I found my original testing, August 2020. I used ...
01 Match Quality, establish Data and Size difference" (UHD NVENC IPB and ALL-I) and
02 Match Data and Size, establish Quality difference (FHD CPU IPB)

RE: Item 01. Nvenc. Source test clip was a 25fps, 27 second UHD clip. 306MB size, data rate 95.3Mbps.

There was a 44.34% size reduction, a 47.2% data rate reduction at my lowest tested file size of 5.9 MB.
At 55,810 kbps there was a 3.49% size reduction and a 3.67% data rate reduction.
By 71,952 kbps there was a -0.43% size reduction and a -0.37% data rate reduction.

[sophisticles]

I'm sure that everyone will recognize the sources used for this test.

The claim has been that x265 at the default crf 28 will produce a visually equivalent file as x264 at default crf 23 with half the size i.e. half the bit rate.

This test was done by inputting the 1080p 4:2:2 files found at the link below into Shotcut on Manjaro Linux and and exporting them using x264 and x265 preset medium.

Encoding times were 5:33 for x264, 11:58 for x265.

[Aludin]

H.265 isn't only for UHD. Everyone used to say H.264 was only efficient for HD. x264 was significantly better than MPEG-2 even on 120p.

On the whole, for the average case, x265 showed bitrate of about 59% of that of x264 at the same CRF

...and shittier quality. The rest of your quotes can all be summed up as inconclusive. He can't make up his mind because he can't tell the difference.

It would seem that H.265 is not quite the 50% bitrate reduction as often claimed, perhaps because I’m being extra-picky with regards to image detail. It definitely does produce less objectionable artifacts which often result in image smoothing rather than macroblocking. I found the bitrate reduction to be in the 30-40% ballpark considering the best encoding preset, which is still worthwhile.

Bitrate reduction without a control for quality. Is blurring better than distortion? He has no clue.

x264 matured way longer than x265 exist and this is NORMAL - every codec need time to mature and refine. If you are unhappy with H.265 why you are not using other video codecs - there is full freedom on this.

Bullshit. x264 with just 2 years of development was way better than its predecessor. x265 can't top its predecessor by more than a few percentage points after TEN F*CKING YEARS. I've been welcoming evidence to the contrary but all I see is people playing games and making lame excuses.

And what other video codecs do you suggest?

side note: the comparison is from 'Posted on August 27, 2016', x265 did improve since then.

No, it actually didn't. The quality got worse if anything and so did the speed.

Or yet another poor workman blaming his tools.

So post your tools, source and exact commandline and get a quick buck, what are you waiting for?

I'm sure that everyone will recognize the sources used for this test.

I don't, you will have to provide it if I am to reproduce results.

[poisondeathray]

This was from the Tears of Steel DCP test. 12bit444 was converted to 10bit420 using zimg , and the 10bit420 version was the reference. Zimg also used for the downscaled version using the default bicubic resampling

Encoder versions posted in the graphic . Only command was --preset slow for all of them and varying CRF plotted with their resulting bitrate for the RD curve

719,999 more tests to go...



[Attachment 77900 - Click to enlarge]


[Attachment 77901 - Click to enlarge]

[4kblurayguru]

Did you use paid versions of other h.265 encoders?

[Aludin]

This was from the Tears of Steel DCP test. 12bit444 was converted to 10bit420 using zimg , and the 10bit420 version was the reference. Zimg also used for the downscaled version using the default bicubic resampling

Encoder versions posted in the graphic . Only command was --preset slow for all of them and varying CRF plotted with their resulting bitrate for the RD curve

Wheres the files? I see only a tiny improvement in the graph, unless VMAF is like SSIM where 98 is twice as better than 96.

Did you use paid versions of other h.265 encoders?

No. I can't reproduce results of a codec I need privileged access to, nor would many on here if I did.

[poisondeathray]

This was from the Tears of Steel DCP test. 12bit444 was converted to 10bit420 using zimg , and the 10bit420 version was the reference. Zimg also used for the downscaled version using the default bicubic resampling

Encoder versions posted in the graphic . Only command was --preset slow for all of them and varying CRF plotted with their resulting bitrate for the RD curve

Wheres the files? I see only a tiny improvement in the graph, unless VMAF is like SSIM where 98 is twice as better than 96.

Search for "Tears of Steel DCP Test" to download the source

Read about VMAF and what it actually measures, and "3H" viewing distance . It's a linear scale that maps human perception
https://netflixtechblog.com/vmaf-the-journey-continues-44b51ee9ed12
https://github.com/Netflix/vmaf

It's not a perfect metric, there are many pros /cons, but arguably it's the best one right now for measuring subjective perception under their defined viewing conditions, has at least some temporal components, and high correlation with test subjects, large sample sizes and participants. It's the probably the only commonly used metric that has been updated and improved consistently over the years, with the last update in Dec 2023. There is a large community and feedback, and you can report issues, or test cases where the metric "fails". For example, you could apply some filters, sharpening to "cheat" and improve scores on the v1 metric, but improvements negated that in later versions.

https://videoprocessing.ai/benchmarks/video-quality-metrics_frm.html


Read graphs like you would for any metric. At any given "quality" level on the Y-axis, what bitrate on the X-axis is required to achieve that ?

[Aludin]

Search for "Tears of Steel DCP Test" to download the source

There are many sources. They list a 6GB MOV download, a 4TB download, a Youtube source, which one did you use for this test?
More importantly, where are the encodes?

I read about VMAF years ago and all I remember is not being impressed and ignoring it, I forget why. It was inferior to SSIM+ but as it's closed source, I had to stop using it since the numbers wouldn't mean anything to anyone else, so I might have to revisit VMAF if this is the new in thing.

[Anonymous84]

--

[poisondeathray]

There are many sources. They list a 6GB MOV download, a 4TB download, a Youtube source, which one did you use for this test?
More importantly, where are the encodes?

It was this one
http://download.blender.org/mango/dcp/tos_dcp_test_04.zip

I deleted the encodes, it's just a quick meaningless test. I was more interested in looking into Netflix claims at 1080. Probably a way to justify their quality...

I read about VMAF years ago and all I remember is not being impressed and ignoring it, I forget why. It was inferior to SSIM+ but as it's closed source, I had to stop using it since the numbers wouldn't mean anything to anyone else, so I might have to revisit VMAF if this is the new in thing.

I wasn't impressed either at first. But I've used it a lot over the years along with other metrics, and now I'm convinced it probably does have the highest correlation. There are many papers that essentially say the same thing. It's still 1 measure, not perfect, so I wouldn't bet the house on it either. VMAF is used frequently by the industry, so start getting used to it.

Personally , based on quite of bit of usage, I don't agree with the 50% less bitrate claim at full HD resolutions across all types of content (and not just by metrics either , also by eye). It's probably closer to ~20-30% average for me. Basically closer to ~1/2 of the generic HEVC vs. AVC claim. Definitely not below 10%. But at UHD, that value is probably higher than 50% . AVC is basically unusable for me at UHD/4K

x265 is just not viable format right now and much more hardware hungry than x264, whereas quality improve is debatable. And many older great hardware players do not support x265.

I thought so too a few years ago, but at this point 10bit 4:2:0 HEVC is usable right now. Lots of hardware support. Video cards, TV's support it right out of the box . NVEnc GPU HEVC encoding is fairly good and super fast.

This essentially mirrors xvid (mpeg-4 asp) and earlier x264 situation. Early on, limited AVC HW support, older players did not support. Quality was poor and "oversmoothing/blurring" at first so everything kept on using xvid. Eventually quality got better, HW support grew. It's the same thing here - early on x265 oversmoothing/blurring, eventually got better

If you want a rough measure of the current state of things, look at scene encoders (not anime encoders , who are usually 1st adopters) . HEVC is probably the most common format now, when it used to be maybe a few %. Similar situation with xvid - eventually x264 caught on, became dominant format. x264 is like the old xvid. It's the changing of the guard

And x264 is basically unusable for UHD (meaning it would be very silly to use x264 at UHD, when you have x265 - the benefits are large at that resolution)

[poisondeathray]

No, send me your encodes. If my workflow is messed then I genuinely wanna get it right. I don't wanna "blame my tools" like one in this thread accused me. I want us to be on the same page.

I'll see if I have time to redo it . I suggest that you repeat it - and if you get different results then post

And it's just 1 short test, meaningless by itself. 1 data point. Maybe it's an outlier. It's low motion scenes - you can't generalize that to everything. But if you do 719,999 tests then you will have a more complete understanding of things

I'd argue time would be better spend on testing other sources to see the trends

And I personally don't care about anything coming from Netflix, they have no credibility.

It's about testing claims. If someone makes a dubious claim, it's everyone's job to look in to it

I have no concerns if that claim was made for UHD/4K. The HEVC vs AVC advantage is large at UHD, anyone who says otherwise is absolutely wrong.

But they made a claim for 1080, and specifically for x264 and x265. The claim is a bit high compared to what I've seen

At low bitrates with Xvid, you got both smearing AND blocking, while x264 had blur but still watchable quality.

I agree with you at low bitrates . AVC inloop deblocking

To clarify what I was referring to - back then at typical good quality "DVD backup " bitrates, not low quality barely watchable bitrates, the main x264 complaint early on was blurring. It wasn't until later that the focus was detail retention.

In fact, later on, that's what set x264 apart from other AVC encoders - details retention instead of blur

FYI it's like that for all codec development. Most are developed initially using PSNR, hence the blur. Later as they mature, other "features" get added. Same thing happened / is happening with AV1

And allow me to burst your bubble: scene encoders are some of the dumbest pieces of shit on the planet

I agree. Most of them do things only to post "first"

What you misunderstood is that observation is about usage - what is being used at a point in time. If there was limited HEVC HW support, you can bet that the % of HEVC posts would be much lower

The delay in HEVC pickup can 99% be blamed on the licensing fiasco and greedy stakeholders . This single handedly delayed HW development support, put HEVC back a few years. By the time it got sorted out, we are onto VVC development already.

[Anonymous84]

--

[sophisticles]

The 50% claims were with respect to the jm reference encoder h265 vs h264 .

x265 and x264 are specific encoder implementations of h265 and h264 respectively. No 50% claims have been made about that.

https://trac.ffmpeg.org/wiki/Encode/H.265

Choose a CRF. CRF affects the quality. The default is 28, and it should visually correspond to libx264 video at CRF 23, but result in about half the file size. CRF works just like in x264, so choose the highest value that provides an acceptable quality.

[poisondeathray]

The 50% claims were with respect to the jm reference encoder h265 vs h264 .

x265 and x264 are specific encoder implementations of h265 and h264 respectively. No 50% claims have been made about that.

https://trac.ffmpeg.org/wiki/Encode/H.265

Choose a CRF. CRF affects the quality. The default is 28, and it should visually correspond to libx264 video at CRF 23, but result in about half the file size. CRF works just like in x264, so choose the highest value that provides an acceptable quality.

I meant no developer has made any of those 50% claims regarding x265 and x264

Anyone can edit the ffmpeg wiki . It's like wikipedia. And full of errors like wikipedia too.

I could edit it to say a "zillion times better, and bakes you a cake too" . If you look at the history of that document, it's just a user, not a developer


The original 50% claim that everyone refers to was a demo a year before x265 even came out. It even preceded the final HEVC draft revision - it was a beta JM reference version. HEVC was supposed to be amazing...etc...

Netflix is not a direct HEVC developer, and they made a specific claim regarding x265, x264 - but at least they backed it up with 720,000 tests

[pandy]

Curious - 50% claim was specified for what type of conditions? Under what type of constrains? In real live no one care - i see in live feeds broadcast encoders struggling with motion - they introducing a lot of temporal aliasing and no one complain so who cares? For sure not broadcasters who are focused on creating maximum possible number of channels where advertisements block are thinly interleaved with some shitty content.
50% claim was made in times where creating H.265 with jm took like few days and statistic was focused on PSNR so 50% on average may be synonym for 40% on this and for example 60% on other content.

[Sharc]

The ffmpeg wiki does not claim 50%. I have not seen any "claim" anywhere claiming 50% unconditionally.

This guide focuses on the encoder libx265 which can offer around 25–50% bitrate savings compared to H.264 video encoded with libx264, while retaining the same visual quality. These gains will be most pronounced at resolutions of 1080p and higher.

[sophisticles]

If I may add to the fun.

I took the Tears of Steel sample that PDR linked to and converted it to what should be a mathematically lossless equivalent using:

ffmpeg -i tos_video.mxf -c:v ffv1 -pix_fmt yuva444p12le -color_range jpeg ToS.mkv

This is what I used as source for this test.

I created a x264 and a x265 file using the following command lines:

ffmpeg -i ToS.mkv -c:v libx264 -preset medium -tune film -crf 23 -pix_fmt yuv444p10le -color_range pc x264.mkv

ffmpeg -i ToS.mkv -c:v libx265 -preset medium -crf 28 -pix_fmt yuv444p12le -color_range pc x265.mkv

I also created the difference files like this:

ffmpeg -i ToS.mkv -i x264.mkv -filter_complex "blend=all_mode=difference" -c:v libsvtav1 -preset 10 -crf 30 -pix_fmt yuv420p10le -color_range pc x264-diff.mkv

ffmpeg -i ToS.mkv -i x265.mkv -filter_complex "blend=all_mode=difference" -c:v libsvtav1 -preset 10 -crf 30 -pix_fmt yuv420p10le -color_range pc x265-diff.mkv

The results are pretty impressive for x265 considering that it's less than 1/4 the size of x264.

I have thrown on a qsv hevc encode for comparison as well:

ffmpeg -i ToS.mkv -c:v hevc_qsv -preset 1 -q 28 -scenario 3 -pix_fmt p010le -color_range pc qsv.mkv

ffmpeg -i ToS.mkv -i qsv.mkv -filter_complex "blend=all_mode=difference" -c:v libsvtav1 -preset 10 -crf 30 -pix_fmt yuv420p10le -color_range pc qsv-diff.mkv

[sophisticles]

Bullshit. x264 with just 2 years of development was way better than its predecessor.

You have no idea what you are talking about.

The first couple of years of x264 were atrocious, before DS, I don't remember the other main developer's name, took over the project.

People complained about x264 all the time and there were numerous well documented problems with x264 that all the psy garbage was meant to fix.

[sophisticles]

]
I don't, you will have to provide it if I am to reproduce results.

https://media.xiph.org/video/derf/

Well known repository of test samples for you to choose from.

I recommend picking a few that have the same bit rate, same frame rate, same resolution, imputing them into Shotcut, exporting a lossless test source and proceeding from there.

I have posted ffmpeg command lines that work on Windows and Linux.

[sophisticles]

If I may add something about objective metrics, such as PSNR, SSIM, VMAF, MS-SSIM, and all the others.

Think of them as akin to testing a car.

If i give you two cars and tell you to find out which is the fastest and you just test 0-60, well you haven't really told me anything.

If you wanted to see which is the fastest you would need 0060, 1/8 mile, 14 mile, flying kilometer, 0-100, 0-100-0, 0-150, top speed, Pike's Peak, 30-50, 50-70, slalom, skidpad, Le Mans, Sebring, the list just goes on.

And then you would also need different atmospheric conditions, like high altitude, temperature, etc, because turbo intercooled and electric engines don't suffer the power loses that naturally aspirated engines do under those conditions.

Same thing with testing video, have you looked at YUV channels on all frames, or just picked the highest value achieved by an encoder on any channel and any frame?

[Aludin]

@sophisticles
I am not contesting x265's efficiency for UHD, that is way too tedious to test given that my new 10th gen PC encodes 720p at only 2 fps. I am interested in SD and HD only. I will take your word on the UHD.

You are looking too deep into the rest of the stuff, let's get step one out of the way, then we can quibble about objective metrics and whether Tears of Steel is good enough of a poster boy for showcasing generalized utility.

You have no idea what you are talking about.

The first couple of years of x264 were atrocious, before DS, I don't remember the other main developer's name, took over the project.

People complained about x264 all the time and there were numerous well documented problems with x264 that all the psy garbage was meant to fix.

You have no idea who you are talking to. I did tests, made a whole thread about it. Early x264 was already an order of magnitude ahead of the second best. The people who complained about x264 were morons who compared a low bitrate x264 to a high bitrate of Xvid. Incidentally, the psy garbage was exactly as you described it: garbage. It made the quality worse. Whether it made clueless morons happy is as relevant as whether astronomers humoring people by telling them the earth is flat increases the national GDP or not. Who cares.

Blast from the past plenty of these discussions/flame wars are still on doom9 forum.

Not surprised at all. I relish the good old days of unleashing the horde of goatse and shitting dicknipples upon the fruitcakes, their meltdowns were gold.

It's heartwarming to know that these freaks are now in their 40s and 50s and still spergin' it up.

[sophisticles]

I am interested in SD and HD only.

For this test I did something a bit different, I don't know if you are aware of an open source movie called Valkaama:

http://www.valkaama.com/

I used the first VOB from the DVD for this test and made 5 encodes, x264 crf 23. tune film, preset medium, x264, qp 23, tune film, preset medium, x265, preset medium, crf 23, x265, preset medium, crf 23 and kvazaar qp 22.

I leave quality determinations up to you.

[Aludin]

I don't see any VOB for download on the site. One FTP server has a bunch of MTS files but no VOB.

Why not just resize your first source? And why use only a medium preset? Give it your best shot and make x265 shine.

[sophisticles]

I don't see any VOB for download on the site. One FTP server has a bunch of MTS files but no VOB.

http://www.valkaama.com/index.php?page=valkaama&l=en

Why not just resize your first source? And why use only a medium preset? Give it your best shot and make x265 shine.

I don't really have a horse in this race, it's not like I am a x developer or make money from the software.

The reality is I have been critical of both x264 and x265 over the years and I have stated that I felt svt-hevc was better than x265 and that svt-av1 was the best software encoder currently available.

You are free to use whatever you want, you said that the 50% claims were bullshit, i demonstrated that for 1080p and above they hold true,

[Aludin]

Alright, I've used up all my bandwidth so I will have to wait until next month (tomorrow) to grab it.

I don't really have a horse in this race, it's not like I am a x developer or make money from the software.

Nonetheless you did enter the race, I just don't want you to claim you weren't trying when you finish last, mang.

The reality is I have been critical of both x264 and x265 over the years and I have stated that I felt svt-hevc was better than x265 and that svt-av1 was the best software encoder currently available.

I'll check out svt-hevc but I gotta be honest here, you claimed in the past that MainConcept was superior to x264 so I'm not holding my breath.

You are free to use whatever you want, you said that the 50% claims were bullshit, i demonstrated that for 1080p and above they hold true,

Your sample was 1800p. I did not test 1080p yet, mainly because I lack a 1080p source that wasn't processed with a lowpass by an overpaid dipshit at Hollywood. But given that my test run with 720p was very disappointing, I'm not optimistic about 1080. We'll see tomorrow.

[_Al_]

Nonetheless you did enter the race

Nobody entered any race. You are in it alone. Riding a horse into a nonexistent battle, shouting and screaming assaulting wind mills.

[sophisticles]

I'll check out svt-hevc but I gotta be honest here, you claimed in the past that MainConcept was superior to x264 so I'm not holding my breath.

Yes i have said that and you know who else said that? Dark Shikari, aka Jason aka Fiona.

Back when he had his developer of x264 blog he had posted how mb-tree came into existence.

He was doing test encodes and found that MC was producing much higher I frames than x264, though he claimed that x264 produced higher quality overall.

He hacked in mb-tree in about 20 minutes as a way of bringing x264's I frames up to par with Main Concept's.

The last time I tested MC's hevc encoder I found it to be fantastic and better than x264 and x265.

I also think ATEME's hevc encoder is better than either x264 or x265, but this I based on the final encodes I have seen and not personal tests.

[lordsmurf]

I'll check out svt-hevc but I gotta be honest here, you claimed in the past that MainConcept was superior to x264 so I'm not holding my breath.

Yes i have said that and you know who else said that? Dark Shikari, aka Jason aka Fiona.
Back when he had his developer of x264 blog he had posted how mb-tree came into existence.
He was doing test encodes and found that MC was producing much higher I frames than x264, though he claimed that x264 produced higher quality overall.
He hacked in mb-tree in about 20 minutes as a way of bringing x264's I frames up to par with Main Concept's.
The last time I tested MC's hevc encoder I found it to be fantastic and better than x264 and x265.
I also think ATEME's hevc encoder is better than either x264 or x265, but this I based on the final encodes I have seen and not personal tests.

I've said this myself for at least a decade now. x264 is fine as a freeware encoder, I use it myself regularly, even more than MC (mostly due to Hybrid, with it's Avisynth/Vapoursynth inclusion). But I have to call BS on x264 being "better" than MC, because it's just not.

But, as usual, details matters. Some MainConcept settings are hidden, or not in the SDK. So you can fiddle and twiddle with x264 settings, ad nauseam, to create x264 encodes that are "better" than MC encodes. But those MC encodes are not 1:1, not apples to apples, but apples to oranges. And that's where many MC comparisons failed, often using included MC SDK version in Vegas/whatever.

I never really got involved in these "better encoder" pissing/dick-measuring contests, because I just do not care. I was busy using the software in a constructive way, and those were rarely constructive conversations. I thought those days were over, the trolls left, everybody went exhaustedly back to their corner (or left the ring entirely). Sometimes a "blast for the past" isn't a good thing.

[dellsam34]

Why arguments though? Everyone use whatever they feel like it's better for them and move on.

[Sharc]

Why arguments though? Everyone use whatever they feel like it's better for them and move on.

+1