x265 HEVC Encoder

[CruNcher]

Thanks for the test - we will look into this.

Interesting saw similar issues on early Ateme 10 Bit Titan bitstreams as well but their the pixels where white instead black :D

[Atak_Snajpera]

I'm shocked how AVX2 and FMA3 optimization can provide such high speed boost for SkyLake!

command line: x265_x64.exe [crowd_run_1080p50.yuv+ducks_take_off_1080p50.yuv+in_to_tree_1080p50.yuv+old_town_cross_1080p50.yuv+park_joy_1080p50.yuv] --frames 2500 --min-keyint 50 --keyint 500 -o NUL

Intel Xeon E5-2690 @ 3.2GHz ( 8C / 16T )

y4m [info]: 1920x1080 fps 50/1 i420p8 sar 1:1 unknown frame count
raw [info]: output file: NUL
x265 [info]: HEVC encoder version 2.2+15-a18ab7656c30
x265 [info]: build info [Windows][GCC 6.2.0][64 bit] 8bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
x265 [info]: Main Still Picture profile, Level-4.1 (Main tier)
x265 [info]: Thread pool created using 16 threads
x265 [info]: Slices : 1
x265 [info]: frame threads / pool features : 5 / wpp(17 rows)
x265 [info]: Coding QT: max CU size, min CU size : 64 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 1 inter / 1 intra
x265 [info]: ME / range / subpel / merge : hex / 57 / 2 / 2
x265 [info]: Keyframe min / max / scenecut / bias: 50 / 500 / 40 / 5.00
x265 [info]: Lookahead / bframes / badapt : 20 / 4 / 2
x265 [info]: b-pyramid / weightp / weightb : 1 / 1 / 0
x265 [info]: References / ref-limit cu / depth : 3 / on / on
x265 [info]: AQ: mode / str / qg-size / cu-tree : 1 / 1.0 / 32 / 1
x265 [info]: Rate Control / qCompress : CRF-28.0 / 0.60
x265 [info]: tools: rd=3 psy-rd=2.00 rskip signhide tmvp strong-intra-smoothing
x265 [info]: tools: lslices=6 deblock sao

encoded 2500 frames in 151.70s (16.48 fps), 7025.74 kbps, Avg QP:37.21

Intel Core i7-6700K @ 4.5GHz ( 4C / 8T )

y4m [info]: 1920x1080 fps 50/1 i420p8 sar 1:1 unknown frame count
raw [info]: output file: NUL
x265 [info]: HEVC encoder version 2.2+15-a18ab7656c30
x265 [info]: build info [Windows][GCC 6.2.0][64 bit] 8bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
x265 [info]: Main Still Picture profile, Level-4.1 (Main tier)
x265 [info]: Thread pool created using 8 threads
x265 [info]: Slices : 1
x265 [info]: frame threads / pool features : 3 / wpp(17 rows)
x265 [info]: Coding QT: max CU size, min CU size : 64 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 1 inter / 1 intra
x265 [info]: ME / range / subpel / merge : hex / 57 / 2 / 2
x265 [info]: Keyframe min / max / scenecut / bias: 50 / 500 / 40 / 5.00
x265 [info]: Lookahead / bframes / badapt : 20 / 4 / 2
x265 [info]: b-pyramid / weightp / weightb : 1 / 1 / 0
x265 [info]: References / ref-limit cu / depth : 3 / on / on
x265 [info]: AQ: mode / str / qg-size / cu-tree : 1 / 1.0 / 32 / 1
x265 [info]: Rate Control / qCompress : CRF-28.0 / 0.60
x265 [info]: tools: rd=3 psy-rd=2.00 rskip signhide tmvp strong-intra-smoothing
x265 [info]: tools: lslices=6 deblock sao

encoded 2500 frames in 110.45s (22.63 fps), 7025.74 kbps, Avg QP:37.21


If we normalize results in this way FPS/GHz/Logical Processors this is what we get

SkyLake -> 0.63
SandyBridge -> 0.32

Basically SkyLake architecture is two times more efficient in x265 than SandyBridge!

[dipje]

it's the bit-by-bit increase in IPC (2nd gen core i7 vs 6th gen core i7) also I think, and it already has been stated that x265 is pretty hungry on memory bandwidth and skylake got pretty big changes in the memory department.

[ShogoXT]

Thanks for all the hard work you guys been putting into it. I have a couple questions.

A: If I want to update the x265 on Staxrip, would you recommend the stable or nightly releases? I noticed most of the nightly releases have been bug fixes lately.

B: I am currently using a Core i7 920 OCed that has no AVX. It currently is encoding at a painful 6-7fps for my projects. Soon il finally get a new computer. Is Ryzen or Kaby Lake looking to be the way to go?
Cores vs instructions I guess?

Thanks again.

[littlepox]

Thanks for all the hard work you guys been putting into it. I have a couple questions.

A: If I want to update the x265 on Staxrip, would you recommend the stable or nightly releases? I noticed most of the nightly releases have been bug fixes lately.

B: I am currently using a Core i7 920 OCed that has no AVX. It currently is encoding at a painful 6-7fps for my projects. Soon il finally get a new computer. Is Ryzen or Kaby Lake looking to be the way to go?
Cores vs instructions I guess?

Thanks again.

A: Unless you are the developer, or you are helping the developers to address bugs/feedbacks, better stick with the stable builds.

B. The Intel CPU is the way to go, most likely. However you do wish to wait for Ryzen to see whether Intel decides to go for some discount.

[Asmodian]

For x265/4 Ryzen might offer very competitive performance/price. We expect higher core counts at each price point with Ryzen and the IPC is looking similar to Haswell, with reasonable clock speeds too. x265 likes cores a lot. :)

It is hard to know much for sure at this point but there is supposed to be an official Ryzen preview on the 5th of this month. :D

It will be a long time before we get a 6/8/10 core Kaby Lake. :(

[NikosD]

x265 gains a lot from AVX2 (not FMA3 - FMA3 is for floating point only which is irrelevant with x265)

RyZen has slower AVX2 units, but x265 gains also a lot from multiple cores, which RyZen has plenty of them.

The CPU comparison will be very interesting after RyZen's official release and I should definitely wait for that.

Besides AVX2, multicores and memory bandwidth you have to consider power consumption (TDP) and last but not least, price (for most of the users that care about it)

[hajj_3]

zen+ is rumoured to have AVX512. Only xeon processors have AVX512 currently so that would be cool if it was true. Does anyone know if AVX512 helps over AVX2 for x265?

[littlepox]

For those who argue Zen would be favourable for x265, do you know how did they dream of Bulldozer when they were using x264?

[NikosD]

Very strong argument, comparing RyZen with Bulldozer.

[LigH]

Does anyone know if AVX512 helps over AVX2 for x265?

I do remember that Multicoreware already discussed taking advantage of some AVX512 instructions.

[Ma]

Does anyone know if AVX512 helps over AVX2 for x265?

Currently x265 doesn't use AVX-512. In the future it should help if the CPU has AVX-512BW extension (Byte and Word Instructions).

AVX-512 is divided into a number of extensions and only AVX-512F (AVX-512 Foundation) is required in all CPUs. AVX-512F is not enough for x265.

[Atak_Snajpera]

For x265/4 Ryzen might offer very competitive performance/price. We expect higher core counts at each price point with Ryzen and the IPC is looking similar to Haswell, with reasonable clock speeds too. x265 likes cores a lot. :)

It is hard to know much for sure at this point but there is supposed to be an official Ryzen preview on the 5th of this month. :D

It will be a long time before we get a 6/8/10 core Kaby Lake. :(

x265 likes cores to some point. According to documentation it cannot use more than 16 threads (--frame-threads).
According to my tests 16 is sometimes to low to saturate my Xeon E5-2690. I notice occasional drops to 70%-80% in cpu usage. Only if scene is very complex cpu usage goes to 90-95%.

[sneaker_ger]

Not more than 16 frames at the same time. It can use more cores than that, though.

[Magik Mark]

I could honestly say that using these CLIs sped up my encoding by 30%. Quality is even better because of "aq motion"

--aq-motion
--multi-pass-opt-analysis
--multi-pass-opt-distortion
--multi-pass-opt-rps

Nice work!

[pradeeprama]

Not more than 16 frames at the same time. It can use more cores than that, though.

Note that in addition to frame-level parallelism (specified by -F option), we also have threads for wpp that can be allocated in a socket-aware manner (specified with the --pools option).

From what I've seen so far, the # HW threads that x265 can saturate depends also on the preset as the amount of work done is very different across different presets. We can easily saturate up to 22-25 HW threads when encoding 4K videos (reasonably complex content), but going beyond that with a single instance of x265 is hard due to the amount of serial dependence introduced from our strict quality restrictions.

[LigH]

x265 2.2+22-20217c8af8ac (https://www.mediafire.com/file/9tnn4lwywp37r6i/x265_2.2+22-20217c8af8ac.7z)

Scalinglists support for 4:4:4 videos + fixes for ssim-rd and others

[Magik Mark]

x265 2.2+22-20217c8af8ac (https://www.mediafire.com/file/9tnn4lwywp37r6i/x265_2.2+22-20217c8af8ac.7z)

Scalinglists support for 4:4:4 videos + fixes for ssim-rd and others

What are these others? In layman's term pls

Thanks for the work! Will give it a try asap

[LigH]

Memory leaks, build warnings, SEA details ...

x265 commit log (https://bitbucket.org/multicoreware/x265/commits/all)

[Magik Mark]

x265 2.2+22-20217c8af8ac (https://www.mediafire.com/file/9tnn4lwywp37r6i/x265_2.2+22-20217c8af8ac.7z)

Scalinglists support for 4:4:4 videos + fixes for ssim-rd and others

ssim rd is running smoothly. However, it slowed down the encoding. Turning it off speeds back everything. Can't see difference when its off or on.

Where should I be focusing to see the difference?

[LigH]

No need for a full-quote every time, even if it is small...

There is never a guarantee that the achieved difference in visual quality is as remarkable as the difference in efforts taken. One may have to visualize the loss against the original material in both cases to be able to point at it.

[JohnLai]

I could honestly say that using these CLIs sped up my encoding by 30%. Quality is even better because of "aq motion"

--aq-motion
--multi-pass-opt-analysis
--multi-pass-opt-distortion
--multi-pass-opt-rps

Nice work!

Hmm? How does enabling --aq-motion increase your encoding speed if it perform more analysis?

[Atak_Snajpera]

Can somebody with multi-socket machine run this benchmark? One of my users reported that despite 5 simultaneously running x265_x64.exe encoders CPU usage is only 75%-80% on his 2 x Intel Xeon E5-2670 @ 2.59GHz ( 8C / 16T ) [Windows 7 Ultimate]
Benchmark log
2 x Intel Xeon E5-2670 0 @ 2.59GHz ( 8C / 16T )

y4m [info]: 1920x1080 fps 50/1 i420p8 sar 1:1 unknown frame count
raw [info]: output file: NUL
x265 [info]: HEVC encoder version 2.2+15-a18ab7656c30
x265 [info]: build info [Windows][GCC 6.2.0][64 bit] 8bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
x265 [info]: Main Still Picture profile, Level-4.1 (Main tier)
x265 [info]: Thread pool 0 using 16 threads on numa nodes 0
x265 [info]: Thread pool 1 using 16 threads on numa nodes 1
x265 [info]: Slices : 1
x265 [info]: frame threads / pool features : 6 / wpp(17 rows)
x265 [info]: Coding QT: max CU size, min CU size : 64 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 1 inter / 1 intra
x265 [info]: ME / range / subpel / merge : hex / 57 / 2 / 2
x265 [info]: Keyframe min / max / scenecut / bias: 50 / 500 / 40 / 5.00
x265 [info]: Lookahead / bframes / badapt : 20 / 4 / 2
x265 [info]: b-pyramid / weightp / weightb : 1 / 1 / 0
x265 [info]: References / ref-limit cu / depth : 3 / on / on
x265 [info]: AQ: mode / str / qg-size / cu-tree : 1 / 1.0 / 32 / 1
x265 [info]: Rate Control / qCompress : CRF-28.0 / 0.60
x265 [info]: tools: rd=3 psy-rd=2.00 rskip signhide tmvp strong-intra-smoothing
x265 [info]: tools: lslices=6 deblock sao

encoded 2500 frames in 102.07s (24.49 fps), 7025.74 kbps, Avg QP:37.21

http://i.cubeupload.com/qX2JPa.png
http://www.mediafire.com/file/nm5n7xg2nb22zl7/x265_FHD_Benchmark.7z

[Ma]

Cool benchmark. On Intel Core i5-3450S @ 2.8GHz ( 4C / 4T ) the score was (3 runs): 8.78, 8.80, 8.80
After replacing x265_x64.exe to VS 2017 AVX build (also 2.2+15) the score was: 9.19, 9.20, 9.18

[OldiesManiac]

@ Atak_Snajpera

I use a dual Xeon E5-2690v4 28 physical cores system and even with 1 x265 encode I am near to 80 % mean.

With 2 simultaneaous encodes it's near 100 %.

Using Win10 x64.

CPU Usage:
https://extraimage.net/image/2STX

rgds

[Atak_Snajpera]

But do you see the same high cpu usage in benchmark? I'm asking because I use default x265 settings (--preset medium) with 1920x1080 test samples. I know that x265 can pretty easily max out many cores with 3840x2160 and some slower presets.

[ndkamal]

I could honestly say that using these CLIs sped up my encoding by 30%. Quality is even better because of "aq motion"

--aq-motion
--multi-pass-opt-analysis
--multi-pass-opt-distortion
--multi-pass-opt-rps


How did you use these options in command line in two pass for example ?

Thanks for avance.

[Motenai Yoda]

--pmode?

[jlpsvk]

is --no-rskip so benefical to picture quality or compression efficiency? because with --no-rskip the encode is about 2.5fps slower...

--output-depth 10 --preset slow --rd 6 --tu-intra-depth 4 --tu-inter-depth 4 --amp --cbqpoffs -3 --qpstep 8 --bframes 8 --rc-lookahead 60 --min-keyint 23
--keyint 240 --no-open-gop --colorprim bt709 --colormatrix bt709 --transfer bt709 --deblock -3:-3 --psy-rdoq 10 --no-sao --crqpoffs -3 --high-tier --qg-size 8 --aq-motion

vs

--output-depth 10 --preset slow --rd 6 --tu-intra-depth 4 --tu-inter-depth 4 --amp --cbqpoffs -3 --qpstep 8 --bframes 8 --rc-lookahead 60 --min-keyint 23
--keyint 240 --no-open-gop --colorprim bt709 --colormatrix bt709 --transfer bt709 --deblock -3:-3 --psy-rdoq 10 --no-sao --crqpoffs -3 --high-tier --qg-size 8 --aq-motion --no-rskip

[LoRd_MuldeR]

is --no-rskip so benefical to picture quality or compression efficiency? because with --no-rskip the encode is about 2.5fps slower...

It disables a speed optimization ("early exit from CU depth recursion") that slightly degrades quality - in theory.

So, no surprise that it makes your encode run slower. But whether quality (compression efficiency) is actually improved is up for debate/testing ;)

(Note: All presets below "veryslow" keep --rskip enabled)

[jlpsvk]

I know what it does...but I just wanted to know, if somebody tested it...because 2.5fps speed drop is huge. ;) I personally don't think, it's worth it....

[LoRd_MuldeR]

...because 2.5fps speed drop is huge. ;)

Well, whether a 2.5 fps speed drop is huge or negligible depends on what FPS you got before ;)

but I just wanted to know, if somebody tested it... [...] I personally don't think, it's worth it....

The fact that the developers added --no-rskip only to the "veryslow" and "placebo" presets indicates that they don't think the quality/speed trade-off is usually worth it.

...unless you don't care about speed anyway.

[jlpsvk]

i've got 6-8fps...depending on the source.. :) so 2.5fps if 30% slower.. :(

[burfadel]

i've got 6-8fps...depending on the source.. :) so 2.5fps if 30% slower.. :(

Then don't use it! The quality difference is probably in effect, non-existent or at least, so minute you'd really have to be looking closely at the right point on a the right frame zoomed in enough to be able to see there. There are a lot of other settings that you can use that are more beneficial, or save bitrate that benefits ABR video (target being size) or results in a smaller file (target quality). In the latter, you can decrease the CRF (remember decimals are allowed, such as 19.8) to get the equivalent approximate file size, which naturally means the output should be better quality.

[jlpsvk]

Then don't use it! The quality difference is probably in effect, non-existent or at least, so minute you'd really have to be looking closely at the right point on a the right frame zoomed in enough to be able to see there. There are a lot of other settings that you can use that are more beneficial, or save bitrate that benefits ABR video (target being size) or results in a smaller file (target quality). In the latter, you can decrease the CRF (remember decimals are allowed, such as 19.8) to get the equivalent approximate file size, which naturally means the output should be better quality.

I ended up with this and getting around 6fps encoding speed:
--crf 20 --output-depth 10 --preset slow --rd 6 --tu-intra-depth 4 --tu-inter-depth 4 --amp --cbqpoffs -3 --qpstep 8 --bframes 8 --rc-lookahead 60 --min-keyint 23
--keyint 240 --no-open-gop --colorprim bt709 --colormatrix bt709 --transfer bt709 --deblock -3:-3 --psy-rdoq 10 --no-sao --crqpoffs -3 --high-tier --qg-size 8 --aq-motion

[burfadel]

I am currently using
--crf 20 --output-depth 10 --rd 4 --tu-intra-depth 4 --tu-inter-depth 4 --rdoq-level 2 --amp --early-skip --fast-intra --b-intra --limit-modes --aq-mode 2 --ipratio 1.38 --pbratio 1.28 --me star --max-merge 4 --weightb --analyze-src-pics --bframes 6 --rc-lookahead 45 --ref 6 --psy-rdoq 1.28 --no-sao --qg-size 8 --limit-tu 3 --ssim-rd

using the latest 'nightly' build (2.2+22). It gets very decent encode speed, and decent output! If I really wanted to sacrifice encode speed but get better quality, I would only change --rd 4 to --rd 6, and IMPORTANTLY :) add --rd-refine which you can only use on --rd 5 and --rd 6. This slows down --rd 6 even further, but actually makes IMO --rd 6 worth the actual speed loss, if you find the slower encoding speed acceptable.

The thing is to find the right balance of encode speed and quality for your needs, and also choose settings that 'make sense'. I should point out that you have set --psy-rdoq to 10, which IMO is very high, but it doesn't matter anyway since it isn't effective without --rdoq-level.

The settings I chose work well for me and to my liking, and performs really well.

[jlpsvk]

I am currently using
--crf 20 --output-depth 10 --rd 4 --tu-intra-depth 4 --tu-inter-depth 4 --rdoq-level 2 --amp --early-skip --fast-intra --b-intra --limit-modes --aq-mode 2 --ipratio 1.38 --pbratio 1.28 --me star --max-merge 4 --weightb --analyze-src-pics --bframes 6 --rc-lookahead 45 --ref 6 --psy-rdoq 1.28 --no-sao --qg-size 8 --limit-tu 3 --ssim-rd

using the latest 'nightly' build (2.2+22). It gets very decent encode speed, and decent output! If I really wanted to sacrifice encode speed but get better quality, I would only change --rd 4 to --rd 6, and IMPORTANTLY :) add --rd-refine which you can only use on --rd 5 and --rd 6. This slows down --rd 6 even further, but actually makes IMO --rd 6 worth the actual speed loss, if you find the slower encoding speed acceptable.

The thing is to find the right balance of encode speed and quality for your needs, and also choose settings that 'make sense'. I should point out that you have set --psy-rdoq to 10, which IMO is very high, but it doesn't matter anyway since it isn't effective without --rdoq-level.

The settings I chose work well for me and to my liking, and performs really well.

--psy-rdoq 10 is in effect, as I am using --preset slow and in that --rdoq-level 2 is by default, so no need to set it up. :)

will try --rd-refine speed loss. :)

edit: tried --rd-refine is cool... :) no such speed loss, but about 400kbps bitrate drop...from 3430 to 3003kbps...and the picture is better i thinks.

@burfadel: tried your settings...my preset is much better quality and detail retention....GTX 1060 can do HEVC 10bit encode at that quality with MediaCoder HQ preset with speed about 130fps. :)

[Magik Mark]

Guys,

I'm getting this warning:

x265 [warning]: Cannot use Analysis load/save option and multi-pass-opt-analysis/multi-pass-opt-distortion together,Disabling Analysis load/save and multi-pass-opt-analysis/multi-pass-opt-distortion

I only have " multi-pass-opt-analysis" activated the other one is off

HEVC encoder version 2.2+22-20217c8af8ac

[LigH]

The meaning is: You can't use either multi-pass-opt* option together with analysis load or save. If you want to load and save the analysis data, you can't optimize it at the same time.

[jlpsvk]

one small question.. :) which AQ-MODE you would recommend to use generally for bluray movies backuping? 1,2,3? :) (x265 2.2+22 and up)

[Magik Mark]

one small question.. :) which AQ-MODE you would recommend to use generally for bluray movies backuping? 1,2,3? :) (x265 2.2+22 and up)



Ad mode = 3 retains very good black level. Encodes a little bit longer though


Sent from my iPhone using Tapatalk

[Barough]

If u do 8-bit encodes so do i recommend you to always use --aq-mode 3 otherwise do is 2 enough. For more info, check the x265 documentation.

Sent from my Samsung Galaxy S7 edge via Tapatalk

[Magik Mark]

If u do 8-bit encodes so do i recommend you to always use --aq-mode 3 otherwise do is 2 enough. For more info, check the x265 documentation.

Sent from my Samsung Galaxy S7 edge via Tapatalk



The doc says:

"This is recommended for 8-bit encodes or low-bitrate 10-bit encodes, to prevent color banding/blocking."

May I ask how do we define low bit rate? I do anywhere between 1500 to 4000. Do these values fall on low bit rate definition?


Sent from my iPhone using Tapatalk

[birdie]

May I ask how do we define low bit rate? I do anywhere between 1500 to 4000. Do these values fall on low bit rate definition?

At what resolution? FPS? What's your desired picture quality? Do you like your encodes to look indistinguishable from the original?

[Vesdaris]

Guys, what settings would you recommend for a somewhat fast encoding(medium preset) but trying to maintain as much details (and not get all blurry) as x264 can?

[microchip8]

Guys, what settings would you recommend for a somewhat fast encoding(medium preset) but trying to maintain as much details (and not get all blurry) as x264 can?

no SAO, no Strong Intra Smoothing, lower deblock filter to -2 or even -3, CTU of 32, AQ mode to 3

if you have grainy source, migh give the grain tuning a try. Apparently it produces very good results (haven't tried it myself but I've seen claims of that)

[jlpsvk]

no SAO, no Strong Intra Smoothing, lower deblock filter to -2 or even -3, CTU of 32, AQ mode to 3

if you have grainy source, migh give the grain tuning a try. Apparently it produces very good results (haven't tried it myself but I've seen claims of that)

for what is "--no-strong-intra-smoothing" good? do I need it/is it worth with my preset? :)

--crf 20 --output-depth 10 --preset slow --rd 6 --tu-intra-depth 4 --tu-inter-depth 4
--amp --qpstep 8 --bframes 8 --rc-lookahead 60 --min-keyint 24 --keyint 240 --no-open-gop
--colorprim bt709 --colormatrix bt709 --transfer bt709 --deblock -3:-3 --psy-rdoq 10 --no-sao
--high-tier --qg-size 8 --aq-motion --rd-refine --ssim-rd --aq-mode 3

[microchip8]

for what is "--no-strong-intra-smoothing" good? do I need it/is it worth with my preset? :)

--crf 20 --output-depth 10 --preset slow --rd 6 --tu-intra-depth 4 --tu-inter-depth 4
--amp --qpstep 8 --bframes 8 --rc-lookahead 60 --min-keyint 24 --keyint 240 --no-open-gop
--colorprim bt709 --colormatrix bt709 --transfer bt709 --deblock -3:-3 --psy-rdoq 10 --no-sao
--high-tier --qg-size 8 --aq-motion --rd-refine --ssim-rd --aq-mode 3

intra smoothing blurs. If you want to keep as much details as possible, disable it

[jlpsvk]

intra smoothing blurs. If you want to keep as much details as possible, disable it

and what about psy-rd?

[microchip8]

and what about psy-rd?

psy-rd is beneficial and is not related to intra smoothing. I find a value of 3.5 to be "optimal"