Comparisons of x265 vs x264

[x265_Project]

Just tested x265 v1.7+374 and noticed that the detail loss issue is still present. x264 @ CRF18 looks sharper than x265 @ CRF15, despite an almost identical file size. Has any progress been made in solving this problem?
Hi Alex,
It would help if you would share the rest of your x265 command line, and ideally, a short clip.

This is an area of ongoing research and it's definitely a priority. x265 has all of the coding tools of x264, plus many more options (larger block sizes, more accurate motion prediction, etc.), so there is no fundamental reason why it shouldn't be able to produce better visual quality at any bit rate. x265 wins easily at low bit rates, but we agree that there are situations at mid-higher bit rates where x265 has cleaner motion and lower noise, but less apparent detail and sharpness than x264. Though x265's picture is objectively more accurate, subjectively people prefer more sharpness and detail. We're looking at a number of things that might contribute to this effect, and I hope to have more to share soon. In the meantime, you can definitely get more detail by increasing the default psy-rd value from 0.3 to something like 0.6.

[zambelli]

Hi Alex,
It would help if you would share the rest of your x265 command line, and ideally, a short clip.
Absolutely, I'd be happy to.

Here are a few clips I encoded recently:
http://1drv.ms/1IshUCC

The x264 clip was encoded at CRF 18, while the x265 clips were encoded at CRF 16, 17 and 18. I will upload the source file tomorrow when I'm back at the office.

The command lines were very simple:

x264 --preset slow --crf 18
x265 --preset slow --crf 16

Thanks!

[x265_Project]

Thanks Alex. It's hard to see any differences as you've chosen a very generous bit rate (720P30 @ 10 Mbps). To my eyes, at full speed or frame by frame, the x265 CRF 16 (which is ~ 10% lower bit rate) looks as good or better than the x264 clip. The x265 CRF 17 and CRF 18 clips start to get slightly softer, but it's barely perceptible.

We have a side by side video player (UHDcode Pro Player) that might help you with these comparisons. It can play AVC, HEVC, or YUV - individually or side by side, including over/under with a wipe bar. Email me (tom.vaughan @ multicorewareinc . com) and I'll make this available. That offer stands for any video professional who is evaluating x265 or UHDcode.

[zambelli]

Thanks, Tom, for the kind offer. I am already comparing the videos frame-by-frame though using Avisynth + LAV Filters + VirtualDub. I typically use the Interleave() function to flip between sources so I can focus on particular areas of the image. The x264 CRF18 clip looks sharper than the x265 CRF16 clip in every single shot that I've compared. I understand the difference might be negligible in real-time viewing, but it still doesn't make sense that HEVC would look softer as its bitrate approaches that of AVC.

[Sagittaire]

Thanks Alex. It's hard to see any differences as you've chosen a very generous bit rate (720P30 @ 10 Mbps).

Well this bitrate will be like BluRay quality or DVD quality for the size/pixel. At this bitrate MPEG2 and MPEG4 ASP will provide excellent quality too and perhaps even better. Really useless to compare at this quality with HEVC because H264, VP9, VC1, XviD ... will make excellent job with less ressource (encode and decode).

If you want really compare make H264 encoding at 720p30 10 Mbps and HEVC encoding at 1080p30 10 Mbps. Or better 720p30 for MPEG2, 1080p30 for H264 and 2160p30 for HEVC. With this comparison, you make real demonstration for each codec powerfull.

[zambelli]

Well this bitrate will be like BluRay quality or DVD quality for the size/pixel. At this bitrate MPEG2 and MPEG4 ASP will provide excellent quality too and perhaps even better. Really useless to compare at this quality with HEVC because H264, VP9, VC1, XviD ... will make excellent job with less ressource (encode and decode).
How about I define my own use cases? ;)

My goal for this particular exercise is archival quality - near transparency from source - with at least 25% bitrate savings and equal (or better) quality compared to H.264.

So if I find that x264 CRF17 gives me archival quality (a subjective bar, of course, but a bar nonetheless), for example, I would expect x265 to produce equal or better results at any CRF setting that yields a 25% lower bitrate. Make sense?

What I'm pointing out is that x264 still has better picture quality than x265 even at similar bitrates. That doesn't seem right.

[birdie]

What I'm pointing out is that x264 still has better picture quality than x265 even at similar bitrates. That doesn't seem right.

It seems just right because x265 hasn't yet matured enough to compete x264, besides HEVC wasn't meant to replace AVC at resolutions equal to or below FullHD. HEVC was mainly developed to provide better quality at 4k/8K UHD resolutions (given the same bitrate) and low bitrates. Of course that's my interpretation of what HEVC has turned out to be. Its marketing materials run contrary to what I'm saying (50% bandwidth reduction vs. AVC).

If your purpose is to preserve the fine details then forget about x265 for at least a year.

[littlepox]

besides HEVC wasn't meant to replace AVC at resolutions equal to or below FullHD. HEVC was mainly developed to provide better quality at 4k/8K UHD resolutions (given the same bitrate) and low bitrates. Of course that's my interpretation of what HEVC has turned out to be.

I don't think so. When MPEG4 based Xvid comes out, do we still prefer MPEG2 on VCD contents? And when x264 claimed the AVC era, we then never appreciated Xvid/RealVideo for DVDRips. It's never supposed to be that x265 has all the features of x264 but can only be used at low-end quality encoding.

[birdie]

Actually Xvid/DivX and most other MPEG-4 codecs were shit plain and simple. Most if not all 700MB/1400MB DVD encodes using MPEG-4 ASP codecs look much worse than their source DVDs, so let's omit MPEG-4 ASP for a while.

The true breakthrough in regard to video compression came in a form of AVC/x264 and even then it didn't happen overnight - x264 was in development for several years before it became a real MPEG2 contender.

It looks like the HEVC standard is simply not enough to beat AVC when we're talking about preserving fine details at relatively high bitrates (>6Mb/sec for FullHD@24fps videos). If you look at marketing materials for HEVC it's usually compared to AVC at ridiculously low bitrates where AVC blockiness looks worse than HEVC blurriness.

[Boulder]

If you look at marketing materials for HEVC it's usually compared to AVC at ridiculously low bitrates where AVC blockiness looks worse than HEVC blurriness.Which always makes me wonder why transparency is not the key point. Is it just because we nowadays live in a world of mobile stuff and there is no need to have transparent results? What I've been trying to say all the time is that x264 produces results much closer to the source (with all its possible faults etc.) but x265 seems to take a very different point of view regardless of the settings.

[birdie]

Boulder (http://forum.doom9.org/member.php?u=7925)

When you're trying to cram 4K streams into existing delivery channels you'll realize that probably HEVC is a better solution. ;-) At least with today's bandwidth. ;-)

However for the prosumer HEVC at its current state is not an option even remotely.

[Boulder]

As I said, they have a different point of view. That is why x265 cannot be considered a true replacement for x264 in its current form, but maybe in the future.

[foxyshadis]

With sufficient tweaking -- often, turning off some of x265's best compression features -- you can get a rough equivalent to x264. It'll be slower and hardware support is minimal, so it seems kind of pointless right now. Let them serve different niches for the time being, until someone gets around to optimizing x265 for grain retention. That's not going to pay the bills until UHD Bluray gets traction (if ever).

On the other hand, saying "Wait a few years" is as meaningless as it ever was, it could happen next week or never, and even "Give it time, it'll happen" is false hope. If it happens, it'll be because someone made it happen, not some arbitrary time passing.

[benwaggoner]

It seems just right because x265 hasn't yet matured enough to compete x264, besides HEVC wasn't meant to replace AVC at resolutions equal to or below FullHD. HEVC was mainly developed to provide better quality at 4k/8K UHD resolutions (given the same bitrate) and low bitrates. Of course that's my interpretation of what HEVC has turned out to be. Its marketing materials run contrary to what I'm saying (50% bandwidth reduction vs. AVC).
It's entirely untrue to suggest HEVC was only designed for low bitrates or UHD frame sizes, and absolutely is intended to be able to replace H.264 with superior quality at the same bitrate.

If your purpose is to preserve the fine details then forget about x265 for at least a year.
That's an oddly specific prediction. We've seen plenty of improvements here. Did you try --psy-rd 0.6? A build today with --qg-quality on by default and the recent rate control improvements, and raising --psy-rd should yield significant improvements in detail retention compared to a few months ago.

[Sulik]

Disabling large transform sizes (using 16x16 CTB size and perhaps limiting max TU size to 8x8) should results in artifacts more similar to x264 (better at preserving grain), but that would eliminate a significant part of the benefits of x265 at really low bitrates...

[benwaggoner]

Disabling large transform sizes (using 16x16 CTB size and perhaps limiting max TU size to 8x8) should results in artifacts more similar to x264 (better at preserving grain), but that would eliminate a significant part of the benefits of x265 at really low bitrates...
That's exactly the kind of choice that rate distortion optimizing mode decisions should be making.

[Sulik]

That's exactly the kind of choice that rate distortion optimizing mode decisions should be making.

When it works :)

[birdie]

That's an oddly specific prediction. We've seen plenty of improvements here. Did you try --psy-rd 0.6? A build today with --qg-quality on by default and the recent rate control improvements, and raising --psy-rd should yield significant improvements in detail retention compared to a few months ago.

Tried that, no visible improvements so far (at CRF=21 which should be sufficient to preserve the details).

[iSunrise]

HEVC was mainly developed to provide better quality at 4k/8K UHD resolutions (given the same bitrate) and low bitrates. Of course that's my interpretation of what HEVC has turned out to be. Its marketing materials run contrary to what I'm saying (50% bandwidth reduction vs. AVC).
It's not really contrary, since to be able to optimize for even lower bitrate requirements at a given quality (irregardless of resolution), you would always need to change specific encoder qualities that are working more efficiently towards saving on the precious bits and bytes. The part where it gets interesting is where HEVC actually can make improvements without sacrificing (visible) quality compared to x264. If HEVC could provide even 10-20% bitrate savings and we all had the necessary HW decoders that do it natively, there is no reason not to prefer HEVC, but we are clearly not at that point, yet.

We really need to wait at least to the end of the year for the Ultra HD Blu-rays to arrive which will ultimately accelerate consumer interest and also push it into way more visibility. But don't ever expect a 20mbps HEVC stream that rivals a 100mbps Blu-ray. It's all a compromise. And yes, that means that fine-details will ultimately suffer, because it's harder to compress.

x264 just satisfies an extremely broad range of use cases for internet and also professional use which makes it so hard to beat. Even XVID was only an internet phenomenon (if you don't count DIVX, dumbest idea ever), but x264 (several years later, though) ultimately did become so good at what is does that XVID is already forgotten. And I think no one ever looked back, since.

It remains to be seen whether HEVC is able to do the same, but make no mistake, it will take several years. At least I have not seen anything that proves otherwise.

[benwaggoner]

Tried that, no visible improvements so far (at CRF=21 which should be sufficient to preserve the details).
I don't know that we can assume that CRF=CRF. We should be comparing same quality at different bitrates, or different quality at the same bitrate.

A rate control fix went in a couple of weeks ago that helps preserve detail, particularly in B-frames.

I wonder if some of this is down to just tuning --psy-rd, -aq-strength, --aq-mode, --qg-size, --rdoq-level, --deblock and --psy-rdoq to taste. That's a lot of psychovisual knobs to tune! x265 doesn't have --tune film or animation equivalent yet, which most people using x265 would probably use. Figuring those out the right tuning may be what's required.

[benwaggoner]

We really need to wait at least to the end of the year for the Ultra HD Blu-rays to arrive which will ultimately accelerate consumer interest and also push it into way more visibility. But don't ever expect a 20mbps HEVC stream that rivals a 100mbps Blu-ray. It's all a compromise. And yes, that means that fine-details will ultimately suffer, because it's harder to compress.
Note that with 24p film content with a 1/48th of a second motion blur, there really isn't much detail when there's motion. And per-pixel detail at UHD is very different from human perception than 1080p, unless everyone is going to buy a TV with double the diagonal of their old one, or sit half the distance. In practice, very few viewers are going to be able to resolve a single pixel in UHD, particularly with real-world content.

With relatively low-noise content like Tears of Steel, I can get quite transparent at 20 Mbps VBR. Out of whimsy, I got something quite decent from ToS at 5.7 Mbps.

Grain is the interesting challenge, and interesting philosophically. Certainly UHD masters can contain WAY more grain than was ever visible theatrically or ever seen by the creators. I'm skeptical that consumers really want to preserved and have to watch all that "new" grain just because it was there on the negative.

[birdie]

I wonder if some of this is down to just tuning --psy-rd, -aq-strength, --aq-mode, --qg-size, --rdoq-level, --deblock and --psy-rdoq to taste. That's a lot of psychovisual knobs to tune! x265 doesn't have --tune film or animation equivalent yet, which most people using x265 would probably use. Figuring those out the right tuning may be what's required.

I hate tuning things. My usual encoding strings looks this way:

ffmpeg -i input.mp4 -c:a copy -c:v libx264 -preset veryslow -crf 18 output.mkv

This is what I want from x265: less bitrate for the same quality (I'm not talking about low quality already compressed source video, I'm talking about FullHD clips with at least 25Mb/sec or higher bitrate). Of course, in case of x265 CRF will be different.

[benwaggoner]

I hate tuning things. My usual encoding strings looks this way:

ffmpeg -i input.mp4 -c:a copy -c:v libx264 -preset veryslow -crf 18 output.mkv

This is what I want from x265: less bitrate for the same quality (I'm not talking about low quality already compressed source video, I'm talking about FullHD clips with at least 25Mb/sec or higher bitrate). Of course, in case of x265 CRF will be different.
Well, at this point of x265's maturity some tuning will be required to get x264-style results. I don't know if it's reasonable to expect that the defaults would ever exactly match, but I think having a preset that gives x264-like results (ala --tune film) makes sense as an eventual goal.

But people really get used to their favorite artifacts, ala MPEG-2 "sizzle." Sometimes artifacts can enhance edges given a subjective increase in sharpness, at a loss of actual accuracy.

[foxyshadis]

Grain is the interesting challenge, and interesting philosophically. Certainly UHD masters can contain WAY more grain than was ever visible theatrically or ever seen by the creators. I'm skeptical that consumers really want to preserved and have to watch all that "new" grain just because it was there on the negative.

While UHD could conceivably image a tiny bit more grain, given that color grain on 35mm is ~10µm and silver crystals are ~1µm (equivalent of ~2000px and ~20000px horizontal), but several authorities believe that focusing on and amplifying the grain is doing it wrong, and ahistorical as movies have traditionally been viewed in theaters. It's almost fetishistic to amplify grain to highlight the extra punch of higher resolution (in the case of digital grain movies like 300 it truly is), to the point where studios are training consumers to expect more grain instead of more detail. Here's a document describing the difficulty and why it should be done better. (http://cool.conservation-us.org/coolaic/sg/emg/library/pdf/vitale/2007-04-vitale-filmgrain_resolution.pdf)

But instead, I expect studios will make up for exceeding the film grain in scans by generating digital grain on top -- or just upscaling and generating grain, as some do to create Blurays today -- and completely confound the codec.

[birdie]

Yeah, this sounds crazy considering that most AAA movies nowadays are shot using a 100% digital pipeline (starting with RED cameras), so in theory the movies that have been shot for the past 10 years should be absolutely grain free and it's definitely not the case. So, it's plausible that grain is added in post production as a way to add analogueness and panache to make them look professional and expensive.

Actually my gut feeling was right. Grain is added (http://www.studiodaily.com/2009/01/fine-tuning-the-digital-image-for-benjamin-button/) in post production.

So we unified the look of the picture. We took down the noise and enhanced the pictures to achieve an even amount of sharpness shot to shot. We put an even amount of grain on top so it had a film-grain distribution as opposed to a video-noise distribution. On some occasions, maybe the power supply was funky and they’d end up with flicker in the picture. If you start to really push the camera to its limit in a very, very low-light condition there are patterns that are inherent to the CCDs, and you end up with a screen-door pattern over the image. We have a filter we developed to take out that screen-door CCD pattern.

We did a number of iterations, with tests both to film and digital cinema screenings with David and Peter, to set the look. How much sharpness and how much grain did they want? Once the target had been set, we went through and used those as benchmarks for the aesthetic look. We then noise-reduced the movie, took out all the flicker and artifacts, and then put in an appropriate amount of noise for seamless transitions from shot to shot. This way, you wouldn’t be shocked by a sudden change in quality when it cuts from a slow-motion shot at nighttime to a regular-speed shot in a more well-lit area.

Also there are some techniques to emulate film grain (http://www.theverge.com/2013/11/22/5131598/creating-analog-with-digital-cinematography-of-nebraska-phedon-papamichael). Wow, I didn't know that.

[foxyshadis]

Another common technique is to shoot an entire reel of film against a grey screen, then scan that and merge it into the final edit. Now that digital algorithms are getting better it isn't used as often, but that's about as genuine you can fake it as you can get.

[littlepox]

Basically there are 3 concerns about grain keeping:

1. x265 does not only wipe out film grain, but also details/weak edges as small as grain. This is the key point of the problem. If you do some encoding in less grainy, but still rich-of-detail sources like recent anime blu-ray, you will know what I am talking about. In contrast, x264 can do that quite well, keeping all the details destroyed by x265. How are you supposed to "add detail and thin edges" to encoded anime?
2. people's eyes just don't like blurred images. you can sometimes add grain when you play the movie; only sometimes, not always as when you watch it on your smart TV.
3. when x264 can free you from worries with even lower bit-rates and much faster encoding speed, we'd expect x265 to do as well as, if not better than, its predecessor.

[iSunrise]

Grain is the interesting challenge, and interesting philosophically. Certainly UHD masters can contain WAY more grain than was ever visible theatrically or ever seen by the creators. I'm skeptical that consumers really want to preserved and have to watch all that "new" grain just because it was there on the negative.
While that definitely is something to think about for the remastering process and the decision making when doing all the high-precision scanning and director approved alterations from the original negative, this should not be the scope that the encoder needs to worry about.

The encoder needs to be able to adapt (via tuned settings) for certain content, while still having a better baseline performance for new UHD content (quality<-> bitrate) then e.x. H.264 or x264 for even lower bitrates.

Otherwise all the marketing mumbo-jumbo is just a smokescreen, because when an encoder is not able to capture all the fine details, even with very high bitrates and irregardless of the source resolution, it clearly is in not in a state that I would recommend to use.

It may be perfectly applicable for really clean and low-noise content already, but that is just a workaround for saying that "we can only save on bitrate, if we ignore some fine details, because they are just too bitrate intensive and too hard to compress".

I would consider 10-20mbps x264 as perfectly transparent for 99,9% of all cases and the moment x265 can beat that with an even higher resolution, I will not look back.

[foxyshadis]

--tune grain should probably set --ctu 32 --max-tu-size 16, maybe even --ctu 16 --max-tu-size 8 --deblock -4,-4 (or --no-deblock) for extreme grain/noise. It's the use of large prediction and especially transform blocks that makes it so difficult to retain grain; sure the block artifacts will rise, but in a grainy picture those are mostly covered up, exactly how x264 gets away with it.

--rdpenalty is a useful hack to make up for their psychovisual rd still being imperfect, but it applies only to intra blocks in inter frames, when the problem is more widespread than that. x265 is just too heavily weighted against dropping down to 8x8 and 4x4 transforms even when the user wants it to, so you have to take a sledgehammer with --ctu & --max-tu-size, because there's no setting to request "damn efficiency, gimme all the grain and texture." If rdpenalty applied more broadly that might not be the case.

[x265_Project]

--tune grain should probably set --ctu 32 --max-tu-size 16, maybe even --ctu 16 --max-tu-size 8 --deblock -4,-4 (or --no-deblock) for extreme grain/noise. It's the use of large prediction and especially transform blocks that makes it so difficult to retain grain; sure the block artifacts will rise, but in a grainy picture those are mostly covered up, exactly how x264 gets away with it.

--rdpenalty is a useful hack to make up for their psychovisual rd still being imperfect, but it applies only to intra blocks in inter frames, when the problem is more widespread than that. x265 is just too heavily weighted against dropping down to 8x8 and 4x4 transforms even when the user wants it to, so you have to take a sledgehammer with --ctu & --max-tu-size, because there's no setting to request "damn efficiency, gimme all the grain and texture." If rdpenalty applied more broadly that might not be the case.
Interesting suggestions. We're open to discuss more / better tune settings, or options that bias x265 towards smaller block sizes or in other ways that are useful. Message me when you're ready to chat.

[littlepox]

Interesting suggestions. We're open to discuss more / better tune settings, or options that bias x265 towards smaller block sizes or in other ways that are useful. Message me when you're ready to chat.

Indeed, we are also doing a lot of test on x265, and we've made some break though in high-bitrate encoding. How are we supposed to participate? drop a private message to you?

[shinchiro]

I wonder if anyone use aq-factor in astrataro's x264 patched build before? I've used this setting to retain grain very grain anime source (corpse party) with --aq-factor=1.00:1.50:3.00, when default x264 build failed at it no matter which settings I tweaked.

This basically mean give more aq to bframes. This is might be interesting to read about the benefit of it
https://astrataro.wordpress.com/2013/07/07/x264-rev2348704-tmod/#comment-548

[sneaker_ger]

Indeed, we are also doing a lot of test on x265, and we've made some break though in high-bitrate encoding. How are we supposed to participate? drop a private message to you?
Please make a thread here so everyone can see and test.

[sneaker_ger]

--tune grain should probably set --ctu 32 --max-tu-size 16, maybe even --ctu 16 --max-tu-size 8 --deblock -4,-4 (or --no-deblock) for extreme grain/noise.

I applied these to the grainy cartoon test I first did ~11 months ago (http://forum.doom9.org/showpost.php?p=1693749&postcount=77):

Used builds:
x264 r2579 8bit x64 from VideoLan
x265 1.7+399 10bit x64 "default" branch from https://encoder.pw/

Settings (all 2pass bitrate 7000):
original (https://mega.co.nz/#!hh0nRLia!7BghO78Nto3t9jVz_AObXbHuFd5HlDn7k4XOb_acysc)
x264 --preset veryslow --tune grain
x265 --preset slower --tune grain
x265 --preset slower --tune grain --ctu 32 --max-tu-size 16 ("foxy1")
x265 --preset slower --tune grain --ctu 16 --max-tu-size 8 --deblock -4,-4 ("foxy2")
x265 --preset slower --tune grain --ctu 16 --max-tu-size 8 --no-deblock ("foxy3")
x265 --preset slower --aq-mode 3 --aq-strength 0.5 --psy-rd 1.00 --psy-rdoq 10.0 --rdoq-level 2 --deblock -3:-3 --qcomp 1.00 --ipratio 1.00 --pbratio 1.00 ("sag"/"sagittaire")
x265 --preset slower --aq-mode 3 --aq-strength 0.5 --psy-rd 1.00 --psy-rdoq 10.0 --rdoq-level 2 --deblock -3:-3 --bframes 3 --min-keyint 1 --qcomp 1.00 --ipratio 1.00 --pbratio 1.00 --no-open-gop --pmode --pme ("sag1"/"sagittaire1")

(All output files, screens and batch scripts) (https://mega.co.nz/#F!Zx8TUTZJ!sdBhN6FIZ7Q4C6txBMY0-w)

http://abload.de/img/270_original_2pu9h.png
http://abload.de/img/270_x264_0furg.png
http://abload.de/img/270_x265_z2u1x.png
http://abload.de/img/270_foxy1_h4utf.png
http://abload.de/img/270_foxy2_puua3.png
http://abload.de/img/270_foxy3_iku00.png
http://abload.de/img/270_sag_0osyx.png
http://abload.de/img/270_sag1_kcseb.png

[x265_Project]

Indeed, we are also doing a lot of test on x265, and we've made some break though in high-bitrate encoding. How are we supposed to participate? drop a private message to you?

Email me. tom.vaughan @ multicorewareinc.com

[x265_Project]

Please make a thread here so everyone can see and test.
We have private conversations all day long with video experts around the world on the topic of how we can improve x265's visual quality, performance and features. I don't mind chatting here on Doom9, but I also like to meet people 1:1, learn more about what they are doing, and what they need. These conversations can be more productive face to face, or on the phone. In the end, everything we implement is made public - usually along with the rationale for the changes.

[sneaker_ger]

He can post their findings here while also having a private chat with you. These things are not mutually exclusive. But by posting here the findings will receive more scrutiny early on and satisfy our curiosity.

[zambelli]

Well, at this point of x265's maturity some tuning will be required to get x264-style results. I don't know if it's reasonable to expect that the defaults would ever exactly match, but I think having a preset that gives x264-like results (ala --tune film) makes sense as an eventual goal.

I think it's entirely reasonable to expect equivalent x264 & x265 tuning presets to yield similar results at a certain bitrate/QP range. The goal should be to eventually make upgrading from x264 to x265 a no-brainer for any compressionist in any scenario (assuming HEVC support is a non-issue) without requiring additional tuning.

[x265_Project]

He can post their findings here while also having a private chat with you. These things are not mutually exclusive. But by posting here the findings will receive more scrutiny early on and satisfy our curiosity.
Every video professional who interacts with us has the option to do that here, or do so privately. We've got large customers who post here, and sometimes we see feedback on certain things through Doom9 before we hear it from them privately. But it's hard to dive deep on a topic on a public forum while keeping the signal to noise ratio high. And there are always lots of specifics that people would rather (or are required to) keep private. So whenever possible we like to have both channels open.

[sneaker_ger]

Grainy hollywood-type movie comparison:

Used builds:
x264 r2579 10bit x64 from VideoLan
x265 1.7+399 10bit x64 "default" branch from https://encoder.pw/

Settings (all bitrate 7000):
original
x264 --preset veryslow --tune grain (3 pass)
x265 --preset slower --tune grain (3 pass)
x265 --preset slower --tune grain --ctu 16 --max-tu-size 8 --no-deblock ("foxy3", 2 pass)
x265 --preset slower --ctu 32 --max-tu-size 16 --qcomp 0.8 --aq-mode 1 --aq-strength 1.0 --psy-rd 0.7 --psy-rdoq 5.0 --rdoq-level 1 --deblock -2:-2 --qg-size 16 --no-sao --merange 44 --no-rect --no-amp ("littlepox" (http://forum.doom9.org/showthread.php?t=172458), 3pass)
(original and output file(s), screenshot package and batch scripts) (https://mega.co.nz/#F!lot1TBKB!_YjLHI7FpIQo1eoKzg4Inw)

http://abload.de/img/130_org_52akt.png
http://abload.de/img/130_x264_flxnc.png
http://abload.de/img/130_x265_3asj2.png
http://abload.de/img/130_foxy3_35yys.png
http://abload.de/img/130_littlepox_tklos.png

http://abload.de/img/205_org_1vzba.png
http://abload.de/img/205_x264_iebu3.png
http://abload.de/img/205_x265_4hsax.png
http://abload.de/img/205_foxy3_fvaxo.png
http://abload.de/img/205_littlepox_ojxe9.png

http://abload.de/img/635_org_7pb30.png
http://abload.de/img/635_x264_djy46.png
http://abload.de/img/635_x265_2nsiw.png
http://abload.de/img/635_foxy3_yky3y.png
http://abload.de/img/635_littlepox_78x41.png

http://abload.de/img/715_org_qizbc.png
http://abload.de/img/715_x264_dayp4.png
http://abload.de/img/715_x265_r6sy0.png
http://abload.de/img/715_foxy3_djx93.png
http://abload.de/img/715_littlepox_f0aqv.png

http://abload.de/img/1060_org_gqayh.png
http://abload.de/img/1060_x264_jbzlb.png
http://abload.de/img/1060_x265_pzstp.png
http://abload.de/img/1060_foxy3_tal55.png
http://abload.de/img/1060_littlepox_fhxsf.png

http://abload.de/img/1575_org_4dlhw.png
http://abload.de/img/1575_x264_yryml.png
http://abload.de/img/1575_x265_upsj2.png
http://abload.de/img/1575_foxy3_cjzne.png
http://abload.de/img/1575_littlepox_vtank.png

/edit: replaced x265 2pass by 3pass
/edit2: added "littlepox" (http://forum.doom9.org/showthread.php?t=172458) encode

[stax76]

@sneaker_ger

Thanks for the comparison, in the first and second scene which are rather dark x265 looked better but in the rest x264 looked better. Both x265 were rather similar. x265 was 5,3 times slower then x264.

[sneaker_ger]

in the first and second scene which are rather dark x265 looked better but in the rest x264 looked better.
There is a big exception right at the start: http://abload.de/img/first_scene_blurred_cisan.jpg
The area is very blurred in the x265 encode, not just less grainy.
But maybe it's just the ratecontrol having gone wild so early. I did x264 3pass because of a similar problem. I think I will test x265 3pass as well and replace current encode if it fixes that problem.

/edit: replaced now. Fixes that small blurryness at start.

[birdie]

Frame 1060, the protagonist forehead: x265 - not quite there ;-)

However at least in certain cases x265 looks better than x264. That's something!

[smegolas]

http://abload.de/img/1575_org_4dlhw.png
http://abload.de/img/1575_x264_yryml.png
http://abload.de/img/1575_x265_upsj2.png
http://abload.de/img/1575_foxy3_cjzne.png

/edit: replaced x265 2pass by 3pass

x265 still destroying fine detail, softening the image.

[Sagittaire]

Grainy hollywood-type movie comparison:

Used builds:
x264 r2579 10bit x64 from VideoLan
x265 1.7+399 10bit x64 "default" branch from https://encoder.pw/

Settings (all bitrate 7000):
original
x264 --preset veryslow --tune grain (3 pass)
x265 --preset slower --tune grain (3 pass)
x265 --preset slower --tune grain --ctu 16 --max-tu-size 8 --no-deblock ("foxy3", 2 pass)
(original and output file(s), screenshot package and batch scripts) (https://mega.co.nz/#F!lot1TBKB!_YjLHI7FpIQo1eoKzg4Inw)

http://abload.de/img/130_org_52akt.png
http://abload.de/img/130_x264_flxnc.png
http://abload.de/img/130_x265_3asj2.png
http://abload.de/img/130_foxy3_35yys.png

http://abload.de/img/205_org_1vzba.png
http://abload.de/img/205_x264_iebu3.png
http://abload.de/img/205_x265_4hsax.png
http://abload.de/img/205_foxy3_fvaxo.png

http://abload.de/img/635_org_7pb30.png
http://abload.de/img/635_x264_djy46.png
http://abload.de/img/635_x265_2nsiw.png
http://abload.de/img/635_foxy3_yky3y.png

http://abload.de/img/715_org_qizbc.png
http://abload.de/img/715_x264_dayp4.png
http://abload.de/img/715_x265_r6sy0.png
http://abload.de/img/715_foxy3_djx93.png

http://abload.de/img/1060_org_gqayh.png
http://abload.de/img/1060_x264_jbzlb.png
http://abload.de/img/1060_x265_pzstp.png
http://abload.de/img/1060_foxy3_tal55.png

http://abload.de/img/1575_org_4dlhw.png
http://abload.de/img/1575_x264_yryml.png
http://abload.de/img/1575_x265_upsj2.png
http://abload.de/img/1575_foxy3_cjzne.png

/edit: replaced x265 2pass by 3pass


As always test seem interessing but there are heterogenous result. First picture is by far better with x264 but difficult to conclude for the other.

Explain can be that you don't know if the codec use I, P, B or bframe. If you compare Pframe for x264 and bFrame for x265, x264 will probaly produce better result. Other way must be to use same frame type distibution for x264 and x265 (it's possible to impose that with external txt typeframe file distribution) or constant quantizer mode. Other way introduce Rate Control "Noise", with high variablitity in the conclusion.

[Motenai Yoda]

I like the foxy3 for the movie (maybe --no-deblock is too much, -2,-2 doesn't seems to smooth too much imho),
also foxy2 for the anime but x265 too (50/50 maybe a litte bit more x265)

[nandaku2]

Can you make the entire clip available for testing? Thanks in advance.

[Sagittaire]

I applied these to the grainy cartoon test I first did ~11 months ago (http://forum.doom9.org/showpost.php?p=1693749&postcount=77):

Used builds:
x264 r2579 8bit x64 from VideoLan
x265 1.7+399 10bit x64 "default" branch from https://encoder.pw/

Settings (all 2pass bitrate 7000):
original (https://mega.co.nz/#!hh0nRLia!7BghO78Nto3t9jVz_AObXbHuFd5HlDn7k4XOb_acysc)
x264 --preset veryslow --tune grain
x265 --preset slower --tune grain
x265 --preset slower --tune grain --ctu 32 --max-tu-size 16 ("foxy1")
x265 --preset slower --tune grain --ctu 16 --max-tu-size 8 --deblock -4,-4 ("foxy2")
x265 --preset slower --tune grain --ctu 16 --max-tu-size 8 --no-deblock ("foxy3")
(All output files, screens and batch scripts) (https://mega.co.nz/#F!Zx8TUTZJ!sdBhN6FIZ7Q4C6txBMY0-w)

http://abload.de/img/270_original_2pu9h.png
http://abload.de/img/270_x264_0furg.png
http://abload.de/img/270_x265_z2u1x.png
http://abload.de/img/270_foxy1_h4utf.png
http://abload.de/img/270_foxy2_puua3.png
http://abload.de/img/270_foxy3_iku00.png

Well for my curisity, I make little test with your source:

ffmpeg.exe -i original.mp4 -an -f rawvideo - | x265.exe --input-res 1920x1080 --fps 24000/1001 - -o crf25aq.265 --bitrate 7000 --pass 3 --stats hp.log --preset veryslow --aq-mode 3 --aq-strength 0.5 --psy-rd 1.00 --psy-rdoq 10.0 --rdoq-level 2 --deblock -3:-3 --bframes 3 --min-keyint 1 --qcomp 1.00 --ipratio 1.00 --pbratio 1.00 --no-open-gop --psnr --ssim --pmode --pme

This x265 setting outperform your x264 file by far for grain retention. Particulary for bframe (bframe are 75% of frame number). x264 with your default setting are really bad bframe quality with really bad grain retention.

[nandaku2]

Well for my curisity, I make little test with your source:

This x265 setting outperform your x264 file by far for grain retention. Particulary for bframe (bframe are 75% of frame number). x264 with your default setting are really bad bframe quality with really bad grain retention.

Interesting. For grainy videos, it was a tug of war between --rdoq-level 0 (this turns of psy-rdoq) and --rdoq-level 2 and high psy-rdoq.

RDOQ zeroes out (what it deems unnecessary) high frequency coefficients, so it would seem intuitive to turn it off for grainy sources. But I guess if we allow rdoq-level to zero out all possible coefficients, and then psy-rdoq acts to retain the visually perceptible ones, the bitrate distribution is visually more efficient.

[benwaggoner]

I note there are some film and some cartoon assets being discussed in this thread. There's a very good chance we'll eventually want to wind up with a --tune animation and a --tune film. How is grainy cartoon content normally handled in x264?