x265 HEVC Encoder

[Motenai Yoda]

I'd suggest an quantizer-related modifier for deblock's, psy's and aq's strengths.
ie usually at low quant (let's say 12-) and at high quant (35+) psy-rd and psy-rdoq will attempt to better maintain fine detail that is yet well retained at low quants and will not at high quant even with psy, but instead decrease quality a lot (specially at high quant).
differently aq and deblock will be even more useful and effective from low quant to high quant.

maybe for psy a gauss-like curve with peak at about 23/24, for aq a log-like one and for deblock an exp-like one.
as for quant reference may can be take the first frame of the gop or the prev/reference I/P or the frame itself.

[foxyshadis]

What is the CLI for a 4:4:4 encode and what are the benefits of it?

You automatically get an encode in whatever colorspace you pass in. If you don't use y4m, you can use --input-csp to specify i422 or i444. x265 has no option to modify the colorspace.

The benefit and drawback is the same as the difference between 4:2:0 and 4:4:4 in general: Better color resolution, important for low-resolution and computer-generated video, but requires more space and doesn't really have any hardware decoding support.

[xooyoozoo]

I'd suggest an quantizer-related modifier for deblock's, psy's and aq's strengths. [...]

HEVC, as a spec, already ties deblocking strength to quantization value, and even if you wish to change that, your only tools are extremely coarse-grained. The best available option is changing deblock for an entire slice/pic.

Psy weighs towards original energy, so it's inherently self-limiting at low-quantization. Do you have proof of how further limiting psy at low QP is helpful?

AQ weighs towards a SSIM-friendly output and effectively moves bits away from edges and towards flat regions. SSIM as a metric isn't quantization dependent, low QP flat regions still need help to prevent banding inherent in 8bit coding, and at high QPs, edges are blurry enough as it is. I'm not sure if there's anything to change unless you're proposing a fundamentally different RD metric.

[jlpsvk]

@LigH
Waiting for you r 1.5.xxx build!!! :)

[LigH]

Ladies and gentlemen, this is x265 v1.5:

x265 1.5+9-7a42ca02d198 (http://www.mediafire.com/download/s36a6k4uxsaiucb/x265_1.5+9-7a42ca02d198.7z)

Time to clean my archive (https://www.mediafire.com/folder/6lfp2jlygogwa/HEVC) from v1.2 builds...

[jlpsvk]

@LigH
One question...using Main10 profile. Is that big difference between last 1.4.544 and 1.5.9 or you meant it like between initial 1.4 and 1.5? :)

[LigH]

The difference between v1.4+544 and v1.5+9 is tiny. Just evolution, no revolution.

[FranceBB]

The difference between v1.4+544 and v1.5+9 is tiny. Just evolution, no revolution.

I'll try it in a few hours with a 4K content.
By the way, how do you compile it? I mean: GCC? ICC? Visual C++?

[LigH]

Many C++ compilers are supported. I used GCC 4.8.2 in MSYS.

[Boulder]

Do you see the issue in which weighted P-frames are not used according to the log?

x265 [info]: Weighted P-Frames: Y:0.0% UV:0.0%

It stopped working at some point but I thought it was fixed. I also have this issue with my own VS2010 builds.

[Ajvar]

Congratulations! I believe number 1.5 is really like a milestone like 1.0 and 2.0. Lets hope that with it the ERA OF HEVC and x265 further massive popularization will be associated.
So that anytime you google x264 vs x265 results would be separated into past (when you could call x265 an early adoptive) and Current where x265 is a full grown encoder which you can use without fear nor thinking that maybe you need to wait hence it's experimental now and future builds will be totally different.

Speaking about psy-rd default values (0.3). is it safe to assume that encoding PC game captured videos (like left 4 dead) you can set from 0.5 to 1.0 due to everything is unrealistic anyways?

[LigH]

If you want to be safe, don't assume ... test and tell.

[foxyshadis]

Congratulations! I believe number 1.5 is really like a milestone like 1.0 and 2.0. Lets hope that with it the ERA OF HEVC and x265 further massive popularization will be associated.
So that anytime you google x264 vs x264 results would be separated into past (when you could call x265 an early adoptive) and Current where x265 is a full grown encoder which you can use without fear nor thinking that maybe you need to wait hence it's experimental now and future builds will be totally different.

Speaking about psy-rd default values (0.3). is it safe to assume that encoding PC game captured videos (like left 4 dead) you can set from 0.5 to 1.0 due to everything is unrealistic anyways?

I took the best 4K L4D2 recording I could find, resized to 720p and recorded with 0, .3 and 1.0 at crf 21 slow. They all look good; the main difference with stronger psy is that the 1.0 seems to cause a little more distortion of object edges and lumpy areas (not flat but not detailed) when viewing frame-by-frame, although textures might be retained a tiny bit better than 0.3. The effect is present at 0.3 but more pronounced at 1.0, but it's kind of splitting hairs. I'll be damned if I can see either effect in motion though, nor does it affect the file size in crf mode. (~0.1%)

[jlpsvk]

Congrats to x265 team. :)

With last 1.4 and with 1.5, I found preset SLOW, with DEBLOCK -3:-3 and with CRF18 completely sufficient for my 1080p encodes (bluray backups), with excellent visual quality and more than 50% size down. :) (i.e.: Godzilla (2014) - x264 placebo CRF20 - 5.0GB, x265 settings above - 2.1GB - audio just copied)

[Ajvar]

If you want to be safe, don't assume ... test and tell.
True but I'm not experienced as much as others here to make judges. Plus even though I have fast computer my hands are not well trained to do multiple comparison encodings very fast.
I took the best 4K L4D2 recording I could find, resized to 720p and recorded with 0, .3 and 1.0 at crf 21 slow. They all look good; the main difference with stronger psy is that the 1.0 seems to cause a little more distortion of object edges and lumpy areas (not flat but not detailed) when viewing frame-by-frame, although textures might be retained a tiny bit better than 0.3. The effect is present at 0.3 but more pronounced at 1.0, but it's kind of splitting hairs. I'll be damned if I can see either effect in motion though, nor does it affect the file size in crf mode. (~0.1%)

Thank you! I believe in this case for me higher values will be better for 30fps video (very strict edges may give stroboscopic looking on low fps video while tiny bit smoothed are better) while lower values will fit 60fps one without using deblocking.

[xooyoozoo]

I recently tested 'tune fast-decode' and it looked, well, about as bad as expected.

I seem to recall the HM encoder heuristically disabling slice level SAO in upper-hierarchy b-frames (note: my mind may have made this up). What if x265 does something similar with deblock and SAO to make 'fast-decode' less of pyrrhic victory?

[foxyshadis]

Thank you! I believe in this case for me higher values will be better for 30fps video (very strict edges may give stroboscopic looking on low fps video while tiny bit smoothed are better) while lower values will fit 60fps one without using deblocking.

I didn't find it reducing that effect at all; edges are still sharp, they just move in weird ways, and don't always follow the motion. At reasonable crf values the effect is very slight and only noticeable by flipping back and forth frame-by-frame, though it rises as the crf does. You still have to use something like MVFlowBlur to introduce motion blur to reduce the strobe effect.

[Ajvar]

I didn't find it reducing that effect at all; edges are still sharp, they just move in weird ways, and don't always follow the motion. At reasonable crf values the effect is very slight and only noticeable by flipping back and forth frame-by-frame, though it rises as the crf does. You still have to use something like MVFlowBlur to introduce motion blur to reduce the strobe effect.

Aaaaah, I see. Language barrier that was.

[FranceBB]

Comparison between 1.4 and 1.5:

first of all, with a silly encoding like:

Main10 profile, Level-5, WPP Streams: 34, frame threads: 2, pool: 4, Internal BitDepth: 10, CTU Size: 64, RQT depth inter: 1 RQT depth intra: 1, ME: hex, range: 57, subpel: 2, merge: 2, keyframe min: 23, max: 250, scenecut: 40, lookahead: 20, bframes: 4, badapt: 2, b-pyramid: 1, weightp: 1, weightb: 1, refs: 3, rate control: CRF 25, AQ-Strength: 1.0, CUTree: 1, tools: rd=3
on a 4K content (file master upscaled) 23,976 fps progressive, it took quite the same with 1.5 version (I mean, encoding time), but on playback, 1.5 version was very slight.
On a 6 core AMD without GPU acceleration (not supported by nvidia gtx650) with 6 MB of cache and 3.4 GHz, 1.4 version was not playable, while 1.5 version was just a bit jerky, so that's a very good performance boost.

As to the quality, they look the same, but I made some test in order to see differences with defaults settings:

Encoding with:
--crf 25 --profile main10 --preset medium

Video lenght: 24 minutes
Resolution: 3840x2160 (file master upscaled)
fps: 23,976 progressive

1.4 version: 1013 MB -- 1.5 version: 724 MB

Detail loss? Not at all! (or should I say "more or less"? xD) :eek:

Screen: https://mega.co.nz/#!SUljXCwL!bU_BSc_vHs_kscTHo5FqGmfZs4jHvNSO0gCs66ifp_I

Borders around the right ear on the second image are a little bit worst in 1.5 version. Plus, there is a little bit haloing in 1.5 version, but it's just a little bit.
As to the blocking on the dark background, it's the same both in 1.4 and 1.5 due to crf 25 setting.
Anyway... c'mon, 24 minutes at 4K resolutions, 10bit, 23,976 with a watchable quality in just 724 MB it's a very good thing.

So... very good improvement with this new version 1.5. I think we are getting closer and closer to a good codec :)

By the way, I know it's still early to talk about it, but... how about an Open CL x265 encoding? It would speed everything up.

[jkauff]

The latest Handbrake nightly includes x265 1.5. For my first experiment with HEVC, I encoded a 35GB Blu-ray movie using the default settings and CRF 18 Slow. Took over two hours on a 4790K running at 4400, but the resulting file was less than a GB in size with no discernible quality loss. Very, very impressive.

Next step is to see how high I can go with CRF without losing visible quality.

[JohnAStebbins]

The latest Handbrake nightly includes x265 1.5. For my first experiment with HEVC, I encoded a 35GB Blu-ray movie using the default settings and CRF 18 Slow. Took over two hours on a 4790K running at 4400, but the resulting file was less than a GB in size with no discernible quality loss. Very, very impressive.

Next step is to see how high I can go with CRF without losing visible quality.

One fun experiment is to see how low you can push the bitrate in an ABR encode before things get ugly. It's impressive how much better the quality of x265 is over x264 at low bitrates. e.g. An 1080p x265 encoding at 300kbps is "usable" where an x264 encoding of the same source at 300kbps is pretty much garbage.

[jkauff]

One fun experiment is to see how low you can push the bitrate in an ABR encode before things get ugly. It's impressive how much better the quality of x265 is over x264 at low bitrates. e.g. An 1080p x265 encoding at 300kbps is "usable" where an x264 encoding of the same source at 300kbps is pretty much garbage.
Good idea, I'll try that next. I keep a couple of my favorite movies on my 16GB iPhone for things like power outages, I could fit a few more on it with x265 ABR set lower than the 1000kbps I use for x264.

[LigH]

Bad idea... :rolleyes:

HEVC decoding will probably drain your phone akku a lot faster than AVC decoding. So in case of a power outage, better have spare USB charging batteries. :p

[stax76]

Hi,

there is a new StaxRip release adding new default values and new builds including batch file to convert the file/folder names, so far it handles LigH's builds, others will be added so using always new builds is easy. The new release also adds H265 GPU encoding with GTX 960 card.

http://forum.doom9.org/showpost.php?p=1709820&postcount=4729

[uneedme]

As I "dreamed" before, the Nvidia Grid is opened up for domestic usage of remote virtual server trail. They build up the very windows environment for the lame user, like me, to try on within 24 hours......

Although, the purpose for this trial is “Play”aaS, I tried remote video encoding with network-storage（Nvidia bundled with dropbox）......

Nvidia Grid said the Linux-like environment version will be online soon, so the self-built-distributional-remote-virtual-servers for lame users is feasible on sight......

Wish they will not charge too much for this service, after the trial......

cloud-video-encoding......


http://i.imgur.com/NOTrxqQ.jpg

http://www.nvidia.com/object/trygrid.html


— —......

[jkauff]

Bad idea... :rolleyes:

HEVC decoding will probably drain your phone akku a lot faster than AVC decoding. So in case of a power outage, better have spare USB charging batteries. :p
Hmm. Hadn't thought about the horsepower required for decoding. Guess I'll wait for the iPhone 7. :p

[javlak]

As I "dreamed" before, the Nvidia Grid is opened up for domestic usage of remote virtual server trail. They build up the very windows environment for the lame user, like me, to try on within 24 hours......

Although, the purpose for this trial is “Play”aaS, I tried remote video encoding with network-storage（Nvidia bundled with dropbox）......

Nvidia Grid said the Linux-like environment version will be online soon, so the self-built-distributional-remote-virtual-servers for lame users is feasible on sight......

Wish they will not charge too much for this service, after the trial......

cloud-video-encoding......

— —......

Shameless, shameless (but completely necessary!) plug:

http://forum.doom9.org/showthread.php?t=171000

[uneedme]

Shameless, shameless (but completely necessary!) plug:

http://forum.doom9.org/showthread.php?t=171000

It is encouraged to be even more shameless...... lolol

[Makaveli84]

Hello all.
One thing that I still dislike about x265 (and which has been discussed a lot) is how it smooths down the picture giving it a "plastic-like" feel. For me personally, this is most noticeable in human skin. For example, in facial close-ups, x265 seems to lose a lot of texturing and details (i.e. skin-tone, dimples, forehead wrinkles, five o'clock shadows/short trimmed beards, etc..)

My question: how can I offset this natural tendency of x265? More precisely, how far can I/should I push certain texture retaining settings before lowering the CRF value? Here's what I'm currently working with:

- preset slow
- psy-rd = 1.0
- psy-rdoq = 1.0
- aq-strength = 1.5
- aq-mode = ??? (I honestly still prefer 2, though it seems the consensus and default value is now 1)

Finally, can deblocking alpha and beta values be set using ffmpeg? I tried passing a "deblock=-1,-1" setting within my "-x265-params foo:bar" command line, but it complained that "deblock" is not a recognized option.

Thanks...

[LigH]

Double-fixed and merged: x265 1.5+21-16e9b6f5aa85 (https://www.mediafire.com/download/4dp6v7r3qncy01r/x265_1.5+21-16e9b6f5aa85.7z)
__

A "--tune grain" should abbreviate some of your many single parameters. But in general: Loss of detail is a quite certain result of lack of bitrate. HEVC is no miracle.

[Boulder]

I think he means "compared to x264" like the most of us test the encoder. To me it seems that with regular settings, denoising the video is a no-no as x265 itself removes noise no matter what :)

[Makaveli84]

A "--tune grain" should abbreviate some of your many single parameters. But in general: Loss of detail is a quite certain result of lack of bitrate. HEVC is no miracle.

As I mentioned before, I'm using zeranoe's ffmpeg for Windows, so "tune grain" (or any other tuning for that matter) is not yet an option.

And anyway, I'm interested in learning how to manually fine tune x265's settings, so my questions still stand.

As for the last part, well, HEVC and its x265 implementation (maybe alongside other implementations) claim that they can achieve the same subjective/perceived quality as AVC/x264 using only half its bitrate. Did they assume that people won't notice the loss of details and the "plastic look"? To me, it seems that x265 is simply different than x264, not better.

[uneedme]

Hello all.
One thing that I still dislike about x265 (and which has been discussed a lot) is how it smooths down the picture giving it a "plastic-like" feel. For me personally, this is most noticeable in human skin. For example, in facial close-ups, x265 seems to lose a lot of texturing and details (i.e. skin-tone, dimples, forehead wrinkles, five o'clock shadows/short trimmed beards, etc..)

My question: how can I offset this natural tendency of x265? More precisely, how far can I/should I push certain texture retaining settings before lowering the CRF value? Here's what I'm currently working with:

- preset slow
- psy-rd = 1.0
- psy-rdoq = 1.0
- aq-strength = 1.5
- aq-mode = ??? (I honestly still prefer 2, though it seems the consensus and default value is now 1)

Finally, can deblocking alpha and beta values be set using ffmpeg? I tried passing a "deblock=-1,-1" setting within my "-x265-params foo:bar" command line, but it complained that "deblock" is not a recognized option.

Thanks...


- rd = 5

(4 Adds RDO Quant
5 Adds RDO prediction decisions
6 Currently same as 5
from 4 [mandatory for psyrd and psyrdoq to work] up to 6)

- psy-rd = 0.3-0.5 or + (up to 2)
- psy-rdoq = 30-35 or + (up to 50)

(grain is a kind of very detailed and complicated Celluloid effect; defult grain retain is p-rd 0.5 p-rdoq 30. so you can tell if you want to keep more details rdoq better above 30)


- deblock=-3:-1 < -> -6:-1 (up/down to -6 )
http://forum.doom9.org/showthread.php?t=109747


it seems better on reserving more details (only by my judgement......)

lookthrough you can find some
http://x265.readthedocs.org/en/1.5/cli.html

[Makaveli84]

I think he means "compared to x264" like the most of us test the encoder. To me it seems that with regular settings, denoising the video is a no-no as x265 itself removes noise no matter what :)

Yes, and yes.

For example: using default settings and slow preset, going from CRF 25 to CRF 23 (and even to CRF 21) hardly made a difference in detail/texture retention. Raising psy-rd to 1.0 and aq-strength to 2.0 (aq-mode set at 2 for all encodes) yielded a richer-looking output but also caused a hike in bitrate.

[Makaveli84]

- rd = 5

(4 Adds RDO Quant
5 Adds RDO prediction decisions
6 Currently same as 5
from 4 [mandatory for psyrd and psyrdoq to work] up to 6)

- psy-rd = 0.3-0.5 or + (up to 2)
- psy-rdoq = 30-35 or + (up to 50)

(grain is a kind of very detailed and complicated Celluloid effect; defult grain retain is p-rd 0.5 p-rdoq 30. so you can tell if you want to keep more details rdoq better above 30)


- deblock=-3:-1 < -> -6:-1 (up/down to -6 )
http://forum.doom9.org/showthread.php?t=109747


it seems better on reserving more details (only by my judgement......)

lookthrough you can find some
http://x265.readthedocs.org/en/1.5/cli.html

:thanks:
Thanks uneedme, this is quite helpful. Any ideas on how aq-strength comes into play with different scenarios or setting combinations?

Now if I can only figure how to set deblocking settings using damn ffmpeg! :confused:

[foxyshadis]

As for the last part, well, HEVC and its x265 implementation (maybe alongside other implementations) claim that they can achieve the same subjective/perceived quality as AVC/x264 using only half its bitrate. Did they assume that people won't notice the loss of details and the "plastic look"? To me, it seems that x265 is simply different than x264, not better.

x265 has never claimed that. It's a goal of the HEVC standard, and compared to JM, the HM does achieve it for quite a few use cases. Grain is noise, though, one of the hardest things to compress, and without film grain modeling it's always going to require roughly similar bitrate across generations. It's clean video and 4K video that gets the biggest reductions.

Anyway, since you're stuck on 1.4 for now, there is no deblock param, that's why it's not working. You had lft (enable loop filter) and that's it. It was added just days after the branch, before 1.4 was even officially released, but it wasn't backported.

Just hold on until zeranoe updates to 1.5, or pipe it into the command line x265.

Aside: You have to use commas in x265 params too, for the same reason as x264: Colons separate the options.

[Makaveli84]

x265 has never claimed that. It's a goal of the HEVC standard, and compared to JM, the HM does achieve it for quite a few use cases. Grain is noise, though, one of the hardest things to compress, and without film grain modeling it's always going to require roughly similar bitrate across generations. It's clean video and 4K video that gets the biggest reductions.
But it's not grain that I was talking about. I mean the way I understand it, film grain is global spatial noise, whilst textured details are usually different and more specific, thus potentially easier to efficiently encode (in that these details should benefit from x265's use of CTUs just like other areas/blocks of the picture). That, or maybe my expectations of x265's efficiency were higher than they should've been... :confused:


Anyway, since you're stuck on 1.4 for now, there is no deblock param, that's why it's not working. You had lft (enable loop filter) and that's it. It was added just days after the branch, before 1.4 was even officially released, but it wasn't backported.
Just hold on until zeranoe updates to 1.5, or pipe it into the command line x265.
That explains it then, thanks for the info!



Aside: You have to use commas in x265 params too, for the same reason as x264: Colons separate the options.

LoL.. It's the same as ffmpeg's x264 syntax, so I know! ;)

[x265_Project]

But it's not grain that I was talking about. I mean the way I understand it, film grain is global spatial noise, whilst textured details are usually different and more specific, thus potentially easier to efficiently encode (in that these details should benefit from x265's use of CTUs just like other areas/blocks of the picture). That, or maybe my expectations of x265's efficiency were higher than they should've been... :confused:

Film grain is a special kind of noise. It is unique on every frame of video; it has no temporal redundancy. This reduces the effectiveness of motion compensated prediction, as it adds a lot of noise to the process (what would be a good match without the film grain appears to not be such a good match when you add noise).

Spatial details in the actual scene are generally found in more than one frame, and so motion compensated prediction can usually encode these details efficiently. The only exception is spatial detail that has very high frequency motion (things that are changing rapidly like tiny ripples on a lake, or confetti falling... or film grain).

After motion compensated prediction, the encoder calculates the difference between the source frame and the predicted frame, and it encodes this "residual error". As prediction is useless for encoding film grain, it all shows up in the residual error, contributing a lot of energy that demands to be encoded.

Video encoders like x265 want to use efficient encoding modes like merge or skip as often as possible. These modes reference other blocks, signaling that this block is just like that other block in that other frame, for example. Ideally, many blocks in each B or P frame would be encoded without any residual error being encoded (in other words, motion compensated prediction is good enough by itself). With film grain, there is always a lot of residual error that wants to be encoded in every block, preventing the use of more efficient encoding modes.

I hope this helps more than it confuses the subject!

[Boulder]

So what you are basically saying is that x265 can never be what x264 is what comes to grain retention, unless you use so high bitrates that it is not actually worth spending the extra time needed for encoding or decoding compared to x264? Or the other way around: it is impossible to get much better than x264 currently is without sacrificing the properties of the original material in such way?

[uneedme]

So what you are basically saying is that x265 can never be what x264 is what comes to grain retention, unless you use so high bitrates that it is not actually worth spending the extra time needed for encoding or decoding compared to x264? Or the other way around: it is impossible to get much better than x264 currently is without sacrificing the properties of the original material in such way?


I dont think it is a sacrificing. More detailed things need more information to describe carrying.

The encoder extract the very logic properties to represent the original information. x265 and x264, just use the different logic to work.

For none(difficult)-logic-able information, such as film grain, two encoders probably keep very similar logic way to process. 'cause x264 also needs high-bitrate to retain those information. (Thus, none-sacrifici-ble portions)

So film with too much radical movement information,the outcomes might have same file size.

Should you want to reduce x265 outcome to 50% file size of x264s' and also want to keep lots of film grain effect, it is contradicted and impossible.


Unless, you have a very large information libraries on local side, the decoder is to just point out and pick

or very powerful graphic engine to instant graphic processing......like 3D gaming's drawing (the gamers' replay file is all very small, cause they have the same engine to reproduce)

Watching a film with everytime large libraries port in or installing a large 3D engine is unpractical and insane. (for pc user it might be possible but none-profitable, no company would do that; it might happen in the future...who knows... watch "the godfather" mafia films with "the godfather" game engine......)

With limited-residual lib and little instant reproducing capability, x265 could not have eye-taking film grain processing capability much greater than x264.



Happy Chinese new year!


- -......

[Boulder]

So film with too much radical movement information,the outcomes might have same file size.That was my point: is x264 already as good as it gets what comes to getting a transparent encode? It seems that with x265, we have two main classes: those who want a small filesize and prefer that the video is at least perfectly watchable and those who try to keep the result as close to the source as possible. I myself belong to the middle which is why I'm interested in knowing if there is "any hope" to get the best of both worlds.

EDIT: after all, x265 is somehow based on x264 :)

[uneedme]

That was my point: is x264 already as good as it gets what comes to getting a transparent encode? It seems that with x265, we have two main classes: those who want a small filesize and prefer that the video is at least perfectly watchable and those who try to keep the result as close to the source as possible. I myself belong to the middle which is why I'm interested in knowing if there is "any hope" to get the best of both worlds.

EDIT: after all, x265 is somehow based on x264 :)



Balancing to the everyone satisfied odd point is still a mystery...;)



Happy Chinese new year!!


- -......

[Ajvar]

Who in the hell figured the grain in films? When I was young teenager film grain was considered as major problem while now people tend to keep it. Why not to use AVS filtering and remove it?

[Boulder]

I'd say that grain tends to bring up false details and it also makes the image appear sharper than it actually is. Noise is a different thing, it can be a problem.

[Tommy Carrot]

It's not just film grain that x265 has problems with. It does a singnificantly worse job at retaining fine details compared to x264. It still looks smooth and "too clean" where x264 is already more or less transparent. I don't think it's an inherent problem with the hevc standard, afaik it has almost all the tools h.264 has, just with the addition of a bunch new ones, so it should be capable of being at least at good in all cases. I guess it's a tuning problem, x265 is focusing on preserving the high contrast parts and edges as accurately as possible, but it's sacrificing the low-contrast parts in exchange.

[Sagittaire]

It's not just film grain that x265 has problems with. It does a singnificantly worse job at retaining fine details compared to x264. It still looks smooth and "too clean" where x264 is already more or less transparent. I don't think it's an inherent problem with the hevc standard, afaik it has almost all the tools h.264 has, just with the addition of a bunch new ones, so it should be capable of being at least at good in all cases. I guess it's a tuning problem, x265 is focusing on preserving the high contrast parts and edges as accurately as possible, but it's sacrificing the low-contrast parts in exchange.

Well it's really simple to solve that with pre-process. You must just introduce higher complexity in low contrast with noise. All the codec have HVS problem in low contrast and low luminosity zone (x264 have this problem too). In fact all the 8 bits codec have this problem even with low quantizer because it's ... 8 bits. Only good dithering can solve this problem.

[Tommy Carrot]

Well it's really simple to solve that with pre-process. You must just introduce higher complexity in low contrast with noise. All the codec have HVS problem in low contrast and low luminosity zone (x264 have this problem too). In fact all the 8 bits codec have this problem even with low quantizer because it's ... 8 bits. Only good dithering can solve this problem.
Oh, i'm not talking about blocking artifacts on flat areas. My problem with x265 is that it tends to smooth away the fine details, where the luma (and possibly the chroma) variance is fairly small, like the pores on the skin, the foliage of the trees in cloudy weather, darker areas, etc.

X264 does a much better job at preserving these. When more or less transparent quality is the goal, these "next-gen" codecs still cannot compete with x264.

[x265_Project]

So what you are basically saying is that x265 can never be what x264 is what comes to grain retention, unless you use so high bitrates that it is not actually worth spending the extra time needed for encoding or decoding compared to x264? Or the other way around: it is impossible to get much better than x264 currently is without sacrificing the properties of the original material in such way?
I said nothing about x264. I was just describing the challenge that film grain poses to video encoders in general.

[Boulder]

I said nothing about x264. I was just describing the challenge that film grain poses to video encoders in general.The question still remains: is it even possible to tune x265 towards better grain/noise/whatever retention or is H.265 video just designed so that it is more like an alternative to x264 instead of a pure successor? There doesn't seem to be a clear answer to that anywhere.

[uneedme]

Oh, i'm not talking about blocking artifacts on flat areas. My problem with x265 is that it tends to smooth away the fine details, where the luma (and possibly the chroma) variance is fairly small, like the pores on the skin, the foliage of the trees in cloudy weather, darker areas, etc.

X264 does a much better job at preserving these. When more or less transparent quality is the goal, these "next-gen" codecs still cannot compete with x264.

Have you tried set the arguments to high detail preserved ones.Film grain, a special noise, can be preserved, which means the fine details can be reserved as well......

x265 is designed to encode up to 4k even 8k output, the pores is no need to be detailed as much as x264 does on the common scale......

The rmvb(real) codec's performance on s-video output SDTV is breathtaking, but sucks on LCD display.

8k detail finess is definitely not as much as 720x576 needed.

Currently, because of the hardware limitation, we compare the x265 fast-encode with x264 placebo......


All you need is to find the right tuning parameters...... to early to coffin the newbies.....

or truly it might need two sets of "default" to suit for this two major usages. Or maybe even break the threshold on designing, like deblock up/down to +-12 +-18......