x265 HEVC Encoder

[Blowis]

Better quality and a larger file size. You could just lower the crf slightly and get about the same effect. With a crf of 21, QPs over 30 will rarely be used anyway, but when they are, you shouldn't see a difference.



At the very least, rd, ref, and b-adapt should change. Are you sure they're the same?

Hi,
ok I'll leave default crf-max and use crf:21 it suits me.

I use StaxRip I selected the desired profile and I modify the parameters.
As I selected the same parameter but faster is faster than medium. I do not understand because I'm more test with 2 videos.

[LoRd_MuldeR]

I thought if I put crf-max lower than 51 I would have a better quality.
For example I use crf: 21 and I put crf-max: 30 I would have a better quality than crf-max: 51

You can also look at this as follows:

Normally, the encoder can choose the "optimal" (as determined by the encoder's RC algorithms) CRF value freely from the whole range. But, with CRF-Max, you enforce an upper limit for that range.

So, if the encoder normally would have chosen a CRF value above your selected CRF-Max, it is now forced to pick CRF-Max.

Whether this will actually improve the visual quality is uncertain - after all there should be a reason why the encoder originally wanted an even higher CRF for that scene. But one thing is for sure: It will cost more bits ;)

In particular, if you are willing to spend more bits for quality, it may be better to just use a somewhat higher target CRF (or a somewhat higher target bitrate), instead of messing with CRF-Max.

[Sagittaire]

Hi,
ok I'll leave default crf-max and use crf:21 it suits me.

I use StaxRip I selected the desired profile and I modify the parameters.
As I selected the same parameter but faster is faster than medium. I do not understand because I'm more test with 2 videos.

cfr mode is here to reproduce same quality than mulipass mode in only one pass mode without possible bitrate target.

to simplify crf will use low quantizer in easy part (low motion, flat texture ... etc) and higher quantizer in hard part (high motion, textured area, noisy part).

For me, if you want really constrained crf decision and have higher "constant quantizer mode" like, the best way is not limit the min an max quantizer (VBV compliance limitation for exemple). Better to use that:

- lower curve compression with higher qcomp (0.6 by default), 1.0 for qcomp mean no curve compression.
- lower ratio for Iframe and Bframe with ipratio and pbratio
- lower aq-strength for AQ

In addition constant quantizer mean constant quality only for the mathematical codec algorithme and not for eyes. in x264 and x265 code, psy setting, RD curve decison, matrix quantisation ... etc ... will have major implication on frame size even if you have the same quantizer and crf. CRF mode is not absolute quality level: Different source can have really low HVS quality with crf at 20 and really high HVS quality with crf at 40.

[Asmodian]

Better quality and a larger file size. You could just lower the crf slightly and get about the same effect.

I would argue that lowering crf slightly usually results in a better effect. The extra bits from using a high qp might be spent on block which will be used again while the high qp that was capped was almost certainly being used on a block that will not be referenced later. :)

ok I'll leave default crf-max and use crf:21 it suits me.


Try 20.9 too ;)

As I selected the same parameter but faster is faster than medium. I do not understand because I'm more test with 2 videos.

Faster is faster but it is also larger and/or lower quality. You do not get the same quality at the same crf if you change any other setting. Faster presets result in lower quality / size.

[LigH]

New year, new build... new feature:

--[no-]rd-refine Enable QP based RD refinement for rd levels 5 and 6. Default disabled

For each analysed CU, calculate R-D cost on the best partition mode for a range of QP values, to find the optimal rounding effect. Default disabled.

Only effective at RD levels 5 and 6

x26 1.8+201-769081eb5f4c (GCC 4.9.2) (https://www.mediafire.com/download/sdgynjrrbqzfj5y/x265_1.8+201-769081eb5f4c.GCC492.7z)
x26 1.8+201-769081eb5f4c (GCC 5.3.0) (https://www.mediafire.com/download/cccrbrfwa2h0g62/x265_1.8+201-769081eb5f4c.GCC530.7z)

BTW, x265 v1.9 is coming soon. Do we still need GCC 4.9.x builds? Or is GCC 5.3.0 the currently "best" GNU C/C++ compiler version?

[LigH]

Faster is faster but it is also larger and/or lower quality. You do not get the same quality at the same crf if you change any other setting. Faster presets result in lower quality / size.

Often. But not in general. There are always "academical exceptions". And preset placebo is no practical preset, only an "academical waste of time".

[LoRd_MuldeR]

BTW, x265 v1.9 is coming soon. Do we still need GCC 4.9.x builds? Or is GCC 5.3.0 the currently "best" GNU C/C++ compiler version?

GCC 5.x builds are consistently ~10% faster for me (compared to GCC 4.9.x). Didn't notice any apparent problems so far.

[Jamaika]

--[no-]rd-refine Enable QP based RD refinement for rd levels 5 and 6. Default disabled

How is it with these novelties? Can I use rd-refine at the function bitrate for levels 5?
I used
x265 --y4m --input-csp i444 --output-depth 8 --limit-refs 3 --limit-modes --high-tier --rd 6 --psy-rd 0.3 --rdoq-level 2 --psy-rdoq 50.0 --rd-refine --bitrate 6000 --vbv-bufsize 30000 --vbv-maxrate 30000 --preset veryslow ...
and movie places stutters.;) Is there a need for this function faster processors?

[LigH]

To ensure that the preset is overridden by additional single parameters, I would prefer to put the preset option as one of the first in the whole command line...

I doubt that RD refinement has any impact on the decoding speed; it should only optimize the quality retention during a GOP (reduce rounding error accumulation), if I understood it correctly... So if it seems to cause playback issues, then there may be bugs to discover.

[Jamaika]

My mistake. I put the wrong decoder HEVC for yuv444(AYUV) and the film is stuttered. Sorry.

[LigH]

Due to a few important bug fixes, and a "merge with stable":

x265 1.8+205-d94f6c2b45f8 (https://www.mediafire.com/download/bvwrku72t80mkwz/x265_1.8+205-d94f6c2b45f8.7z)

GCC 5.3.0 only from now on.

[K.i.N.G]

>=10 bit can still be useful.

x265 1.8+191

source
http://abload.de/img/source_ewsvl.png

8 bit (default)
http://abload.de/img/8bitbyzbv.png

8 bit (--psy-rd 2)
http://abload.de/img/8bit-psy-rd2eolk2.png

10 bit (default)
http://abload.de/img/10bito3zd2.png

12 bit (default)
http://abload.de/img/12bit46zh3.png

In fades it's way more pronounced:
output videos (https://mega.nz/#F!QhEhxb5T!Q8Zkgb1x3CK4RO3rKdoIWQ)
(source (https://mega.co.nz/#!osdxQbCR!vim8f5gAD5nf0w0jf-vEAA3mGySmEOoZQOH_GE3Z2uw), mirror (http://217.160.126.132/lighthouse_lossless.mp4))

Actually, for my eyes there's allot more banding in the 10bit and 8bit encodes...

[movmasty]

Due to a few important bug fixes, and a "merge with stable":

x265 1.8+205-d94f6c2b45f8 (https://www.mediafire.com/download/bvwrku72t80mkwz/x265_1.8+205-d94f6c2b45f8.7z)

GCC 5.3.0 only from now on.
Works on XP sp3, to whom may interest
and make Internet Friendly Media Encoder works on XP too(1st gui i found, hope to find another asap)

Does not worl with x264_launcher, wich uses other newer(?) builds

Got half the speed of x264 with faster preset.
Size 49% of the heavy compressed x264 with CRF 28, quality a bit lower, smoothing a bit too heavy.

Could someone please put updates on First post?

[LigH]

Well, yes, I still try to build 32-bit binaries XP-compatible; but they are less interesting, can't handle high resolutions due to memory restrictions for 32-bit processes. And high bitdepth builds don't use assembly optimization; they are even more restricted by the memory limit.

[Jamaika]

Due to a few important bug fixes, and a "merge with stable":
Finally any messages.
x265 [warning]: CRF max must be greater than CRF <-- function crf-min/max can use but analizer HEVC Elecard StreamEye4 doesn't show changes
x265 [warning]: NAL HRD parameters require VBV parameters, ignored <-- (use only by high-tier)
x265 : Main 4:4:4 profile, Level-4 (Main tier) <-- can change level, increased level to 5.1
x265 [info]: lowering VBV max bitrate to 12000Kbps
x265 [info]: lowering VBV buffer size to 12000Kb
Other observations:
[I]--limit-refs 3 --limit-mod --rd-refine --high-tier --preset placebo <-- visible quality loss
--high-tier --vbv-maxrate 30000 --vbv-bufsize 30000 --preset placebo <-- no effect on improving the quality
--rd 6 --psy-rd 0.3 --rdoq-level 2 --psy-rdoq 50.0 --preset placebo <-- effect banding, sharper image
--rd 6 --psy-rd 0.3 --no-psy-rd --no-psy-rdoq --preset placebo <-- no effect banding, blur image (ie. animation BPG)
--limit-mod <-- lossless quality

My best settings:
x265.exe --y4m --limit-mod --rd-refine --no-info --no-open-gop --no-hrd
--rd 6 --psy-rd 0.3 --rdoq-level 2 --psy-rdoq 50.0 --bframes 0 --deblock -3:-3 --qcomp 1.00 --me umh
--preset veryslow --no-b-intra --no-sao --rect --no-amp --no-temporal-mvp --no-signhide --no-strong-intra-smoothing
--input-depth 8 --input-res 1920x1080 --input-csp i444 --output-depth 8 --fps 30000/1001 --keyint 30 --crf 28 --vbv-bufsize 30000 --vbv-maxrate 30000 --range limited --output "x265.cc_1.8.0.205.h265" -
--rd-refine <-- function rd-refine for profile Main reduces some banding. In my opinion, it performs better without using the high-tier.
--bframes 0 <-- function reduces the saw at the edges of objects. It is good to use the function qcomp=1.00

The problem of color. The use of color matrix=bt709 in excessive add a particular color will be clipped color. Thus, we have a different color scheme as standard TV.
How do we want to keep the selected colors don't use ColorMatrix.

[Sagittaire]

My best settings:
x265.exe --y4m --limit-mod --rd-refine --no-info --no-open-gop --no-hrd
--rd 6 --psy-rd 0.3 --rdoq-level 2 --psy-rdoq 50.0 --bframes 0 --deblock -3:-3 --qcomp 1.00 --me umh
--preset veryslow --no-b-intra --no-sao --rect --no-amp --no-temporal-mvp --no-signhide --no-strong-intra-smoothing
--input-depth 8 --input-res 1920x1080 --input-csp i444 --output-depth 8 --fps 30000/1001 --keyint 30 --crf 28 --vbv-bufsize 30000 --vbv-maxrate 30000 --range limited --output "x265.cc_1.8.0.205.h265" -

You seem to abuse the local specialty of jamaica ... :devil:

1) Why use vbv without HRD? It's completely useless. VBV are here for hardware profil compliance and must be use with HRD tag I think. You want play your file with hardware decoding? Use VBV can hurt quality in really complexe part: you use it only it's necessary ...

2) bFrame are major implemantation in modern codec. Use bframe is always good for efficience. Modern codec have algorithme for use itself no-bframe if it's useless localy. If you want higher quality for bframe, lower the bframe ratio.

3) --no-b-intra --no-sao --rect --no-amp --no-temporal-mvp --no-signhide --no-strong-intra-smoothing ... ???

[burfadel]

Also why 8-bit? CRF seems pretty high (lower quality) too. That would result in a fairly poor looking 1920x1080 video with those other settings. If space is an issue, it would actually be higher quality to reduce the resolution and choose more suitable options (even close to defaults), 10-bit, and lower CRF.

[Jamaika]

And who says I'm a specialist. I am a poor man who is interested in new codecs. They say that wasted time because I have not bought HEVC editor. 1000 conditions codec should not interest me.:D

1) Why use vbv without HRD? It's completely useless. VBV are here for hardware profil compliance and must be use with HRD tag I think. You want play your file with hardware decoding? Use VBV can hurt quality in really complexe part: you use it only it's necessary ...
Maybe you and right. It is a pity that there is no message. There is only written in the manual: "Default disabled". I am not aware that in the VBV automatically turns on.
Is this parameter as a separate function VBV has some special application?
x265 [info]: VBV/HRD buffer / max-rate / init : 30000 / 30000 / 0.900
When off is still the same message.

2) bFrame are major implemantation in modern codec. Use bframe is always good for efficience. Modern codec have algorithme for use itself no-bframe if it's useless localy. If you want higher quality for bframe, lower the bframe ratio.

--ipratio
Sets the target average increase in bitrate for I-frames as compared to P-frames. Seen as 'keyframe boost' in xvid. Higher values increase the quality of I frames. This makes them better references, which can improve the overall image quality. The problem is that the extra bits taken by the I-frames are taken from the P and B-frames, which makes this variable a balancing act.
http://forum.doom9.org/showthread.php?p=1733944#post1733944
http://x265.readthedocs.org/en/default/presets.html#tuning

3) --no-b-intra --no-sao --rect --no-amp --no-temporal-mvp --no-signhide --no-strong-intra-smoothing ... ???
Good question. What is it used for a preset veryslow? When the films is dynamic these parameters don't improve quality.
The quality probably negligible to notice compare to default veryslow settings.


@burfadel
Everything can be done. Just as I'm wondering how I have AVC 8bit why it convert to 10bit?

[foxyshadis]

1) Why use vbv without HRD? It's completely useless. VBV are here for hardware profil compliance and must be use with HRD tag I think. You want play your file with hardware decoding? Use VBV can hurt quality in really complexe part: you use it only it's necessary ...

Streaming?

--ipratio
Sets the target average increase in bitrate for I-frames as compared to P-frames. Seen as 'keyframe boost' in xvid. Higher values increase the quality of I frames. This makes them better references, which can improve the overall image quality. The problem is that the extra bits taken by the I-frames are taken from the P and B-frames, which makes this variable a balancing act.
http://forum.doom9.org/showthread.php?p=1733944#post1733944
http://x265.readthedocs.org/en/default/presets.html#tuning
It's a balancing act, which means choosing one extreme or the other hurts. Turning them off always hurts. The post you linked to uses 10 b-frames, so it's an odd choice to support your use of none?

Good question. What is it used for a preset veryslow? When the films is dynamic these parameters don't improve quality.
Veryslow is veryslow, it's right there on the tin, its options are only to extract a percent or two more out of the video. A faster profile would offer a better mix of speed for quality than this, maybe the slow preset, based on your option mix. Why --no-temporal-mvp, --no-sao, and --no-signhide? They're extremely fast and save bitrate. It seems like you're just turning off options at random, mixing veryslow with ultrafast, and that's the best way to break a codec.

I think you should go back to the drawing board, start at --profile slow and only modify from there as you find fixable problems. (Note that the new default --psy-rd is much higher than yours, as well.)

[Boulder]

I didn't get any answers regarding --rdoq-level and --psy-rdoq - the default for rdoq-level is 2 for veryslow but if the goal is to retain more grain, is it better to switch to --rdoq-level 1 and have --psy-rdoq around 5.0-10.0 or so? None of the presets seem to use --rdoq-level 1.

[shinchiro]

Why --no-temporal-mvp, --no-sao, and --no-signhide?.

I still disabled sao for good since it still blur the details..

[divxmaster]

After weeks of testing 1080p, I am using (10bit)
--crf 20 --psy-rd 1.5 --psy-rdoq 1.1 --aq-mode 2 --tu-intra-depth 3 --merange 41 --preset slow --bframes 5 --max-merge 5 --min-keyint 23 --keyint 288 --deblock -3:-3 --no-open-gop --rdoq-level 2
This gives great results, with good detail retention and reasonable size of 2-4gb per bluray, depending on source grain.
For heavily grained movies (quantum of solace for example), I use vapoursynth 'vid = haf.SMDegrain(vid, tr=3,thSAD=400,RefineMotion=True,contrasharp=True,pel=2)'

@atak_snajpera Excellent tip on high psyrd. I have compromised on 1.5, as 2 increase bitrate too much for me
@stax76, I wish I had found the excellent video comparison tool in staxrip much sooner!
@Ligh, x265 seems to parse out preset first, and then process the rest of the arguments (I think)

Cheers,
Divxmaster

[Jamaika]

Thank you for answers

It's a balancing act, which means choosing one extreme or the other hurts. Turning them off always hurts. The post you linked to uses 10 b-frames, so it's an odd choice to support your use of none?
For preset veryslow/slower are default value ipratio/bpratio/bframes = 1.40/1.30/8. For BPG animation is bframes = 0.
I thought it was the best option possible. I did not think that the value bframe is so important.
User Sagittaire is right. Best environmental option is bframes = 3 / ipratio = 1.00 / bpratio = 1.00.

I wonder why you can not set default it to presets medium <> veryslow under CRF.
Why --no-temporal-mvp, --no-sao, and --no-signhide? They're extremely fast and save bitrate. It seems like you're just turning off options at random, mixing veryslow with ultrafast, and that's the best way to break a codec.

Tests are needed. Also important is the user's taste.
For ip/bpratio = 1.40/1.30 didn't like quality.

I didn't like switching these functions. I didn't check how it looks for 1.00. Currently I don't have the time and the corresponding film on longer tests with an analysis of each function. Besides, who is going to read and looked thirty photos. Waiting for the new X265 codec version 1.9.
Note that the new default --psy-rd is much higher than yours, as well.
Thanks. User requests have been met. Apparently there is no bandings.

[2themax]

I'm having an issue making x265 adhere to level I am specifying. I realize that it will automatically change the level to match the options, but I need level 5.1 to adhere to the UHD BD spec. Any suggestions on what I can do to make that happen?

x265 --preset veryslow --output "out.hevc" --input "in.yuv" --input-res 3840x2160 --input-csp i420 --fps 24 --profile main10 --level-idc 51 --high-tier --open-gop --keyint 24 --min-keyint 1 --bitrate 65000 --vbv-maxrate 95000 --vbv-bufsize 100000 --pass 1 --colorprim bt709 --transfer bt709 --colormatrix bt709 --hrd --aud --sar 1:1 --output-depth 10

[sneaker_ger]

Unrelated to your problem, but:
--vbv-maxrate 95000 --vbv-bufsize 100000
Buffer must not be greater than maxrate.

[2themax]

Unrelated to your problem, but:

Buffer must not be greater than maxrate.
It's not an issue in the optical disc world. For instance, the BD vbv is 30,000 but the max bit rate is 40,000.

[sneaker_ger]

It's not an issue in the optical disc world.
Spec is spec, nobody cares about anything else.

For instance, the BD vbv is 30,000 but the max bit rate is 40,000.
Read carefully. My statement does not contradict that. 30,000 is not greater than 40,000.

[nevcairiel]

Unrelated to your problem, but:

Buffer must not be greater than maxrate.

Actually buffer being greater than maxbitrate is perfectly fine.
A H.264 L4.0 BD compliant stream has max bitrate 24000 and buffer 30000, while a L4.1 stream has bitrate 40000 and buffer 30000 as well.

The buffer size just means how much will be buffered (duh!), you can equally buffer 2 seconds worth, or 2*maxbitrate. It influences a few things, including memory requirements in the decoder and startup time (to fill the buffer), but there is no problem with it.

[2themax]

Spec is spec, nobody cares about anything else.


Read carefully. My statement does not contradict that. 30,000 is not greater than 40,000.
Sorry I read the second part wrong but you are still incorrect. nevcairiel gave a good example in the above post. BD is its own spec and VBV (CPB in AVC) can be higher than max bit rate.

[sneaker_ger]

3.5.3 STD delay
Maximum of STD delay is 1 second for video stream, 60 seconds for still picture.
BD-ROM_Part3_V3.0_WhitePaper_150724.pdf (http://www.blu-raydisc.com/assets/Downloadablefile/BD-ROM_Part3_V3.0_WhitePaper_150724.pdf)

Am I interpreting that wrong?
Same for AVC according to "Encoding Video for Blu-Ray using H264/AVC" thread (http://forum.doom9.org/showthread.php?t=154533).

[nandaku2]

I'm having an issue making x265 adhere to level I am specifying. I realize that it will automatically change the level to match the options, but I need level 5.1 to adhere to the UHD BD spec. Any suggestions on what I can do to make that happen?

x265 writes into the VPS the minimum decoder level required to decode a video successfully. In this case, Level 5 High-tier decoder support is sufficient to decode the video.

[Jamaika]

--colorprim bt709 --transfer bt709 --colormatrix bt709
I see that everyone uses BT709 for 10bit files. If you record something in Slog camera can be used BT2020? I know they have a problem with the new ColorMatrix some TV.

[2themax]

x265 writes into the VPS the minimum decoder level required to decode a video successfully. In this case, Level 5 High-tier decoder support is sufficient to decode the video.

Correct but I need to somehow override that function so the stream adheres to the UHD BD spec.

[LigH]

UHD BD supports level 5.1, you say (I wonder where you can read that, any sources known?)... as the maximum level, I believe. Why do you believe that lower level results are not supported?

[sneaker_ger]

3.1 General Constraints
Profile
Main 10 profile
general_profile_idc in SPS shall be set to 2.
Tier
High Tier
general_tier_flag in SPS shall be set to 1.
Level
Level 5.1
general_level_idc in SPS shall be set to 153.
Source:
http://www.blu-raydisc.com/assets/Downloadablefile/BD-ROM_Part3_V3.0_WhitePaper_150724.pdf

"shall" = absolute requirement

[LigH]

should < shall < must

[sneaker_ger]

The paper does not offer a definition for the words but usually:
MUST This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification.
https://tools.ietf.org/html/rfc2119

If you look to the BluRay paper you will see that "shall" is used all the time, very seldomly "must". There is no doubt how it's meant.

[x265_Project]

Correct but I need to somehow override that function so the stream adheres to the UHD BD spec.
We don't have our hands on any UHD-BD players yet, but I would be surprised if the Main 10, High Tier, Level 5.1 HEVC decoder in a UHD-BD player would refuse to decode Main Tier or Level 5.0 stream. If, for UHD-BD specification compatibility reasons, we need to provide the ability to force --level-idc (http://x265.readthedocs.org/en/default/cli.html#cmdoption--level-idc) to use the specified value regardless of the ability for lower level decoders to handle the bitstream, we'll be happy to add this support.

[2themax]

The paper does not offer a definition for the words but usually:

https://tools.ietf.org/html/rfc2119

If you look to the BluRay paper you will see that "shall" is used all the time, very seldomly "must". There is no doubt how it's meant.

From the BD spec.

Shall: indicates an action or feature that is mandatory and must be implemented to claim compliance to this specification.

We don't have our hands on any UHD-BD players yet, but I would be surprised if the Main 10, High Tier, Level 5.1 HEVC decoder in a UHD-BD player would refuse to decode Main Tier or Level 5.0 stream. If, for UHD-BD specification compatibility reasons, we need to provide the ability to force --level-idc (http://x265.readthedocs.org/en/default/cli.html#cmdoption--level-idc) to use the specified value regardless of the ability for lower level decoders to handle the bitstream, we'll be happy to add this support.
Right now because of this I can not import a HEVC stream to even test the theory.

[x265_Project]

From the BD spec.

Shall: indicates an action or feature that is mandatory and must be implemented to claim compliance to this specification.


Right now because of this I can not import a HEVC stream to even test the theory.
Alright. We'll take a look at this.

[2themax]

Alright. We'll take a look at this.
Thanks for looking into it.

[benwaggoner]

Sorry I read the second part wrong but you are still incorrect. nevcairiel gave a good example in the above post. BD is its own spec and VBV (CPB in AVC) can be higher than max bit rate.
Correct.

Note that vbv-maxrate is in kbits/sec and vbv-bufsize is in kbits. Different units. HEVC is a little atypical in that Main Tier the bufsize=maxrate because default max buffer at peak bitrate is generally 1 second. But older codecs like H.264 often had max vbv-bufsize larger than max vbv-maxrate.

[sneaker_ger]

Correct.
But not on BluRay. See post #3131.

[benwaggoner]

But not on BluRay. See post #3131.
Yes, that is my understanding as well.

I haven't tried making a BD HEVC stream yet, though.

[LigH]

A few more bugs fixed, and merged with stable:

x265 1.8+212-792f6ead9c50 (https://www.mediafire.com/download/4adcqgsku2yvy6s/x265_1.8+212-792f6ead9c50.7z)

[LazyNcoder]

Hi guys,
I have a grainy video and I wanna encode it to x265 but it's killing me.
I tried --nr-inter --nr-intra at first. but it's not quite what I have in mind. it removes some noises not all, and in same scene with still camera and everything, remaining noises come and go. I mean it's not practical at all.
I also tried --tune grain. It made the video so blur. Almost removed all the noises but the problem is keyframes. like when the camera changes, all the noises appear for little amount of time and then they disappear. it's so annoying and again, not practical at all.

I'm out.

I also wanted to try StaxRip with RgTools.dll but it says it can't find the dll file but it's right there in the right path.

any suggestion?

[LigH]

Too few details, we are already missing your whole command line and source details (e.g. a MediaInfo analysis to know dimensions and framerate to have a relation to your bitrate control options).

If x265 noticably reduces noise right after a keyframe, you will certainly have a way too low bitrate target. Encoding grainy material requires a lot more bitrate than encoding smooth material, that's a fact, there is no magic to avoid that.

[LazyNcoder]

Too few details, we are already missing your whole command line and source details (e.g. a MediaInfo analysis to know dimensions and framerate to have a relation to your bitrate control options).

If x265 noticably reduces noise right after a keyframe, you will certainly have a way too low bitrate target. Encoding grainy material requires a lot more bitrate than encoding smooth material, that's a fact, there is no magic to avoid that.

It's a regular promotional - but much noisy - 1080p 24mbps 24fps video. nothing too special about the command line, --crf 20 --preset slower --output-depth 10 --rdoq-level 1 --aq-mode 3. with x265 1.8+212-792f6ead9c50 that you've kindly posted above.

I also tried NLMeans noise reduction built-in handbrake. It was awesome. but since handbrake can only produce 8bit videos, the result had huge banding problem even with aq-mode 3.

I used crf 20 with both --tune garin and without it when I used --nr-inter 400 nr-intra 400. --tune grain was blurred no matter what crf I used. Also, lower bitrate can help reducing grain but it also reduce video quality at the same time (duh).

[dipje]

KNLMeansOpenCL is available as a vapoursynth and plugin and runs in basically any kind of bitdepth. I think the AviSynth plugin also has support for 'the ugly 16bit avisynth hack'.


But do you have a noisy source and you want x265 to remove the noise and give good quality video... or do you want to preserve the noise as good as possible? This is not yet clear to me.

You talk about noise-reduction plugins, but at the same time you talk about '--tune grain' (which is to preserve grain, not remove it).

[LazyNcoder]

KNLMeansOpenCL is available as a vapoursynth and plugin and runs in basically any kind of bitdepth. I think the AviSynth plugin also has support for 'the ugly 16bit avisynth hack'.


But do you have a noisy source and you want x265 to remove the noise and give good quality video... or do you want to preserve the noise as good as possible? This is not yet clear to me.

You talk about noise-reduction plugins, but at the same time you talk about '--tune grain' (which is to preserve grain, not remove it).

No, I want to remove the noise. I thought the same about --tune grain but when I used it, I see it's not what I think it is.

I thought there's a simple answer for this, so I just asked. Now, let me walk you guys through it.

Original picture (http://s2.postimg.org/fjaxtoyeh/Original.png)

--tune grain keyframe (http://s27.postimg.org/pasno6yir/Grain_key.png)

--tune grain 7 frames after the keyframe (http://s16.postimg.org/7fdss6xzp/Grain.png)

--nr-intra 200 nr-inter 200 (http://s2.postimg.org/zayv4dovd/Inter.png)