x265 HEVC Encoder

[littlepox]

I'm not sure some speed/quality parameter like --rd 5 should be changed with a tune
Of which entity is the improvement of --rc-lookahead 80 and --no-strong-intra-smoothing on film based content?
also difference (in quality) between --rdpenalty 1/2 and --ctu 32 --max-tu-size 16?

I forgot to mention, one should use preset medium ~ veryslow for this preset. It is difficult to get a tuning for all presets, all bit-rate levels, all resolutions, so we focus on a most used, specific setting: preset slow, --crf 18, 10bit 1080p.

At this level, we believe some preset options should be tuned for a better quality/speed purposes. For example:

--ctu 32 --max-tu-size 16: Though this pair does not give a significant quality gain as before(due to improvement on the logic about handling large CUs/TUs), It loses nothing in quality during the test (to be specific, It shows a very insignificant quality gain), and it still boosts the encoding speed and multi-threading. So we use it primarily for speed and secondarily for quality.

--no-sao: sao is perhaps the worst setting in x265, making the default settings as blurred as RealVideo. Removing it gives a far better detail retention.

--rdoq-level 1: In our test for the same bitrate, --rdoq-level 1&2 does not show significant difference(or 1 is slightly better than 2 for detail retention). Since 1 is probably faster than 2, we use 1.

--subme 3: this is to ensure that chroma residual is used in ME analysis, which we found to be very useful.

--rd 5: same reason, we find it more useful than costly.

--rc-lookahead 80: same reason. You may lower down that a bit, but please at least set it to be 50.

--no-strong-intra-smoothing: In the test setting, very few cases you need to smooth the boundary of large blocks, as we focus on mid-high bit-rate with 10bit. So the smoothing gives a negative return. BTW, coupled with --ctu 32 --max-tu-size 16, this option is not even relevant. Just in case someone still allow --ctu 64 --max-tu-size 32.



This setting is still in its beta stage, we plan to refine it later with more test settings.

[burfadel]

--rdoq-level 1: In our test for the same bitrate, --rdoq-level 1&2 does not show significant difference(or 1 is slightly better than 2 for detail retention). Since 1 is probably faster than 2, we use 1.

I found the same myself, in that with the other settings set the same, --rdoq-level 1 seemed to retain the detail more effectively. You should notice however that the bitrate is lower with --rdoq-level 2 than 1. I found that using --psy-rdoq 1.28 the file size was roughly the same over a range of test samples I did, and the quality ended up being nicer than --rdoq-level 1.

I looked into this because I mentioned previously --psy-rdoq 1 looked nicer, but it was pointed out to me the file size is smaller. They mentioned that at the same bitrate, level 2 was nicer and I agree with that :). I found raising the --psy-rdoq to 1.28 achieved this and was nicer than lowering the CRF by 0.1 until a similar file size was found.

Additionally, I found --me star to be the most effective performance and quality wise, however hex is the default at medium preset. I would suggest using -me star if using the medium preset with your suggested settings.

In any case, try a sample clip with --rdoq-level 2 --psy-rdoq 1.28 --me star compared to the same clip with the settings you suggested and see the difference :). The file size when using --psy-rdoq 1.28 with --rdoq-level 2 will likely be fairly similar to the file size of --rdoq-level 1 and --psy-rdoq 1 (default setting).

I also notice you have --rd 5, it is nicer but costly speed wise. On top of --rd 5 you can use --rd-refine but that is very costly performance wise. I found in some respects --rdoq-level 2 and --psy-rdoq 1.28 with --rd 4 produces similar results. Of course, using those with --rd 5 and --rd-refine is even more effective, but very costly performance wise! I found --rdoq-level 2 and --psy-rdoq 1.28 retained the texture of almost flat areas more effectively than default settings, much like --rd 5 and --rd-refine does as well. If performance isn't an issue, use all four settings together!

[burfadel]

I've updated VS 2015 to update 3 and realize that 12-bit x265 compiled with options
set CXXFLAGS=/arch:AVX /GS- /GL
hangs at beginning (before encoding, illegal instruction). VS 2015 update 2 with the same options works. VS 2015 update 3 with this options works for 8-bit and 10-bit x265.

If I compile by VS 2015u3 in debug mode it works. It could be that update 3 to VS 2015 is not perfect.

I have heard of inconsistent behaviour with a pre-update 3, but post-update 2 version of the runtimes, although the latest runtimes seem to be okay. I realise the compiler is separate to the runtimes, just thought I'd mention it. It's the reason why I haven't updated my installer, although I think the latest runtimes at least are okay now...

Ironic that they're pushing for VS2015 (version 15) now that VS15 (which will likely end up being called Visual Studio 2017) is in preview and can be tried. Currently it uses the same runtimes as VS2015.
https://www.visualstudio.com/en-us/downloads/visual-studio-next-downloads-vs.aspx

[littlepox]

Strange, we managed to keep a similar bitrate(<5% of diff) and compare the results.

Doing further tests on rdoq-level; will update this post later.

Update: change rdoq-level 1 to 2; Since it demonstrated some advantage with more testcases.

[burfadel]

Did you try bumping the --psy-rdoq a little when using --rdoq-level 2?

[littlepox]

Did you try bumping the --psy-rdoq a little when using --rdoq-level 2?

I tried two methods:

decreasing crf a bit
increasing rdoq a bit

Both of them seem better than the --rdoq-level 1, but two of them are sort of indistinguishable.

[RainyDog]

Thanks for your updated --tune-film recommendations littlepox. Your thread from last year was what made me transition to x265.

The biggest change that sticks out to me with these new beta tunings is the change from --qcomp 0.8 to 0.65. Can you elaborate on the reason for this please?

[littlepox]

Thanks for your updated --tune-film recommendations littlepox. Your thread from last year was what made me transition to x265.

The biggest change that sticks out to me with these new beta tunings is the change from --qcomp 0.8 to 0.65. Can you elaborate on the reason for this please?

Previously increasing qcomp did show a lot of advantage, but now it seems less attractive. We'd better increase psy or decrease crf instead of raising qcomp, at least with the current testcases.

[RainyDog]

Previously increasing qcomp did show a lot of advantage, but now it seems less attractive. We'd better increase psy or decrease crf instead of raising qcomp, at least with the current testcases.

Thanks. I'll mess about with lowering qcomp back down from 0.8 and decreasing CRF values to compensate too.

But do you not also find that higher qcomp equals less aggressive cutree and that also to be beneficial?

[littlepox]

Thanks. I'll mess about with lowering qcomp back down from 0.8 and decreasing CRF values to compensate too.

But do you not also find that higher qcomp equals less aggressive cutree and that also to be beneficial?


It is beneficial, but not as beneficial as crf and psy.

[LigH]

Version 2.0 was just announced in the mailing list. I'll expect a verbose post here soon...

[littlepox]

Out of curiosity, when are they going to disable the infamous Smoothing-All-Objects (sao) in the default setting?

It kills nearly every tiny detail with no bit-rate advantage, even at very low quality/bitrate.

[x265_Project]

x265 version 2.0 has been released. This release supports many new features as well as support for ARM assembly optimizations for most basic pixel and ME operations, as well as SAO cleanups and a fully tested reconfigure functionality.

Full documentation is available at http://x265.readthedocs.org/en/stable/

=========================================== New Features =========================================

• uhd-bd: Enforce Ultra-HD Blu-ray Disc parameters (overrides any other settings)
• rskip: Enables skipping recursion to analyze lower CU sizes using heuristics at different rd-levels. Provides good visual quality gains at the highest quality presets.
• rc-grain: Enables a new rate control mode specifically for grainy content. Strictly prevents QP oscillations within and between frames to avoid grain fluctuations.
• tune grain: A fully refactored and improved option to encode film grain content including QP control as well as analysis options.
• asm: ARM assembly is now enabled by default, native or cross compiled builds supported on armv6 and later systems.
==================================== API and Key Behaviour Changes ==================================
• x265_rc_stats added to x265_picture, containing all RC decision points for that frame
• PTL: high tier is now allowed by default, chosen only if necessary
• multi-pass: First pass now uses slow-firstpass by default, enabling better RC decisions in future passes
• pools: fix behaviour on multi-socketed Windows systems, provide more flexibility in determining thread and pool counts
• ABR: improve bits allocation in the first few frames, abr reset, vbv and cutree improved
=============================================== Misc ==============================================
• An SSIM calculation bug was corrected

[littlepox]

Another problem with x265 in its current mid-high quality encoding, is the blurring effect in chroma planes. x264 by default uses chroma-qp-offset -2 for yuv420&422 content and this offset is further enhanced with high psy settings. The logic behind is with chroma sub-sampling, details in the chroma planes are fragile, and psy works primarily on luma planes thus favoring more bits to be distributed to luma plane. Thus x264 uses chroma-qp-offset to get the bits back to chroma planes.

In x265, there seems no such mechanics. That's why we'd recommend to tweak -3 -3 manually for cbqoffset and crqoffset. Even so, x265 still blurs up the chroma plane as if it used to be at v1.x, only leaving major edges survive. I hope we see some improvements there in the future.

[Khun_Doug]

[QUOTE=x265_Project;1773941]x265 version 2.0 has been released. This release supports many new features as well as support for ARM assembly optimizations for most basic pixel and ME operations, as well as SAO cleanups and a fully tested reconfigure functionality.

I'm new at posting to the forum so please be patient if this doesn't submit correctly or isn't formatted properly.

Does anyone know when will a release of ffmpeg be available with the X265 2.x release included? I've been testing Hybrid with limited success, and VirtualDub using external encoders with better success. But myffmpeg and VidCoder seem the best for creating X265 videos. But myffmpeg is tweaky about the version of ffmpeg and some of the recent versions do not work. I'm anxious to see (and use) the new version of X265.

[Leo 69]

@Khun_Doug

Use StaxRip. That's an awesome piece of software, a lot more customizable than VidCoder and has a user-friendly interface. You can change the default x265.exe to the newest one and enjoy all the new features.

[Motenai Yoda]

Does anyone know when will a release of ffmpeg be available with the X265 2.x release included?
here (expire in 2 days) http://expirebox.com/download/f89c6d593bcb32e6335bb791f33b64a5.html

[littlepox]

x265 v1.0 provided an HEVC encoder with basic usage;
x265 v2.0 now finally replaces x264 as the best encoder in visual quality(with customized tunings).

As far as from our recent tests, the improvement is the perhaps the most impressive among all version jumps.
Keep up the good work developers, you are creating another incredible miracle.

Maybe in x265 v3.0, we can see the 50% promise to be realized. Now it's sort of half way there; our test suggest currently x265 saves about 25% of the bitrate compared to x264.

[nakTT]

x265 v1.0 provided an HEVC encoder with basic usage;
x265 v2.0 now finally replaces x264 as the best encoder in visual quality(with customized tunings).

As far as from our recent tests, the improvement is the perhaps the most impressive among all version jumps.
Keep up the good work developers, you are creating another incredible miracle.
Glad to hear that. Can't wait to get home and give it a try.

By the way, is there any noticeable improvement between this early 2.0 to the late 1.9 (e.g: 1.9+229)?

[LigH]

Not really a lot. In a short range around a new tag, there are usually only small fixes, cleanups, clarifications in the documentation, to "stabilize" the development status. But see for yourself in the commit log:

https://bitbucket.org/multicoreware/x265/commits/all

There is no increment count, so you will have to look for the hashes to know which of them was 1.9+229.

[nakTT]

Not really a lot. In a short range around a new tag, there are usually only small fixes, cleanups, clarifications in the documentation, to "stabilize" the development status. But see for yourself in the commit log:

https://bitbucket.org/multicoreware/x265/commits/all

There is no increment count, so you will have to look for the hashes to know which of them was 1.9+229.
Thank you very much for the reply and the advice.

[birdie]

So what are those magic settings to make x265 2.0 produce an equally sharp output with reduced bitrate vs. x264? I don't care performance/speed even if takes up to 20 times longer to encode vs x264. ;-)

Also I'd love to see a comparison with VP9.

[luigizaninoni]

I'd like to ask a question about early-skip parameter. I usually use slower preset with minor tweaks. As the name says, encodings are rather slow. However, I noticed that if I enable early-skip switch, speed gets a nice bump of about 40%. The penalty is a somewhat larger file (perhaps 2% or 3%). So my question is: does early-skip impact only on file size (I am more than willing to trade speed for a little more bitrate) ? Or do I also suffer a significant quality loss ? (to my untrained eyes, difference in quality is minimal, but someone with more experience could give some better advice)

[jlpsvk]

LigH, waiting for your 2.x build. :) When can we wait it?

[ndkamal]

A beta version of the new --tune film based on the most up-to-date stable 10-bit build:

--ctu 32 --max-tu-size 16 --crf 18 --pbratio 1.2 --cbqpoffs -3 --crqpoffs -3 --no-sao --subme 3 --b-intra --no-amp --weightb --aq-mode 3 --aq-strength 0.9 --rd 5 --psy-rd 2.0 --psy-rdoq 3.0 --rdoq-level 2 --rc-lookahead 80 --qcomp 0.65 --no-strong-intra-smoothing

Tweak the crf between 16~20
Comments and feedback are welcome.



Hi Littlepox,

I have made some tests with the beta version of the new --tune film, and the result is very good near from tune film from x264. This beta version work best on 10-bit than 8-bit version of the encoder. I hope than new tune film will be incorporate soon in the release of x265.

[mandarinka]

Another problem with x265 in its current mid-high quality encoding, is the blurring effect in chroma planes. x264 by default uses chroma-qp-offset -2 for yuv420&422 content and this offset is further enhanced with high psy settings. The logic behind is with chroma sub-sampling, details in the chroma planes are fragile, and psy works primarily on luma planes thus favoring more bits to be distributed to luma plane. Thus x264 uses chroma-qp-offset to get the bits back to chroma planes.

In x265, there seems no such mechanics. That's why we'd recommend to tweak -3 -3 manually for cbqoffset and crqoffset. Even so, x265 still blurs up the chroma plane as if it used to be at v1.x, only leaving major edges survive. I hope we see some improvements there in the future.

Thanks for pointing out that. I think I noticed said thing, but for some reason it didn't occur to me that I should try to offset the QP, then. Oh well.

[littlepox]

Several interesting facts about three different aq modes:

aq-mode = 1 is the safest choice. It is intended for high and stable quality encoding with 10-bit precision.

aq-mode = 2 is the most efficient choice. It gives less bits in high motion scenes compared to aq-mode 1, and it saves a lot of bit-rate, when you can choose to further lower down your crf or increase your psy. Human eyes are less sensitive to high motion scenes, so you can only spot its donwsides if you watch the video frame by frame. Recommend if you are using 10-bit, and encoding at a sweet-pot bit-rate.

aq-mode = 3 is the choice for 8-bit encoding, as well as low-bitrate 10 bit encoding. It distributes bits to dark areas, where color banding and blocking is most visible. Even in 10-bit encoding, if bit-rate is low, major distortions and detail loss are going to appear in dark site, and aq-mode=3 makes the best outcome. When used alone it significantly boosts the bit-rate, so you'd need to lower down the strength a bit(~0.2) and increase your crf for the size control.

The exact bitrate/crf intervals for each of them is circumstantial, we probably need further research on that.

[herbert]

Thank you for your continued testing, littlepox.

I tried your most recent settings on a sample and found the encoding times to be less than practical. After some tinkering the biggest culprits seem to be --b-intra and --rd 5, each reducing encoding speed by a third.

Have you compared the cost/benefit of --b-intra and --rd >3 and would you consider them mandatory for a possible --tune film setting?

[littlepox]

Thank you for your continued testing, littlepox.

I tried your most recent settings on a sample and found the encoding times to be less than practical. After some tinkering the biggest culprits seem to be --b-intra and --rd 5, each reducing encoding speed by a third.

Have you compared the cost/benefit of --b-intra and --rd >3 and would you consider them mandatory for a possible --tune film setting?

The benchmark for the trade-off parameters are x265.exe --tune film(without --rd --subme....) --preset veryslow. If you use --tune film --preset medium, you are almost as good as using --tune film --preset veryslow. The difference in bit-rate and visual quality is within a given threshold.

So, you should realize that this --tune film is NOT meant for fast encoding use-cases. To sacrifice little from --preset veryslow, it has to be running at a speed as slow as --preset slow.

Then, our test suggest --rd 5 and --b-intra is a must.

As I've said, making a --tune film for all use-cases is tough and inefficient. We'd rather now focus on the ripping use-case:

1. You can tolerate the speed to some degree, i.e, --preset slow and slower;
2. You are not too concerned about compatibility, i.e, you choose 10-bit encoding.
3. You are encoding for mid-high level of quality, i.e, crf=16..20


When speed is a concern, you may lower down --rd to 4; it is still quite acceptable. However do NOT use 3 since then the psy-RDOQ is disabled.
--b-intra is fairly powerful in certain cases, enabling b-frames to cope with "stranger" blocks. Coupled with --pbratio 1.2 they boost the quality of bframes which takes up 70+% of total frames. Disabling is NOT recommended.

[LigH]

There is an addition to the v2.0 announcement:

Addendum: x265 is capable of triggering this Centos kernel bug (https://bugs.centos.org/view.php?id=8371) causing a deadlock, mostly observed on large multi-socketed servers. Please update your kernels to kernel-2.6.32-504 or above to avoid that risk.

Apart from that...

LigH, waiting for your 2.x build. :)

x265 2.0+2-70581d6cd065 (https://www.mediafire.com/download/uvcmk0gu0stqed2/x265_2.0+2-70581d6cd065.7z) (MSYS/MinGW, GCC 5.3.0, 32+64bit 8/10/12bit EXEs+DLLs + multilib EXEs)

[Barough]

x265-v2.0+4-43ca554799c2 (http://mediaupload.us/asb7k60l96km) (MSYS/MinGW, GCC 5.4.0, 32 & 64bit 8/10/12bit multilib EXEs)

[stax76]

@echo off
C:\StaxRip\Apps\ffmpeg\ffmpeg.exe -i "D:\~Conv Temp\~Temp\Død.Kalm.x264_temp\Død.Kalm.x264.x265.avs" -f yuv4mpegpipe -pix_fmt yuv420p -loglevel error - | C:\StaxRip\Apps\x265\x265.exe --crf 22 --frames 1339 --y4m --output "D:\~Conv Temp\~Temp\Død.Kalm.x264_temp\Død.Kalm.x264.x265_out.hevc" -

cmd.exe /C call "D:\~Conv Temp\~Temp\Død.Kalm.x264_temp\Død.Kalm.x264.x265_encode.bat"

D:\~Conv Temp\~Temp\D¢d.Kalm.x264_temp\D¢d.Kalm.x264.x265.avs: No such file or directory
x265 [error]: unable to open input file <->


I've a bug report from a USA Win 10 user, he gets an error from x265 when his source file contains 'ø', I'm a German Win 10 user and it works fine here, isn't both USA and Germany using CP 1252? With CP 1252 the char 'ø' is on position 248.

https://en.wikipedia.org/wiki/Windows-1252

[MeteorRain]

Still waiting for the github mirror to be updated. When that is done, I'll compile my 2.0 builds.

[MeteorRain]

C:\StaxRip\Apps\ffmpeg\ffmpeg.exe -i "D:\~Conv Temp\~Temp\Død.Kalm.x264_temp\Død.Kalm.x264.x265.avs" -f yuv4mpegpipe -pix_fmt yuv420p -loglevel error - | C:\StaxRip\Apps\x265\x265.exe --crf 22 --frames 1339 --y4m --output "D:\~Conv Temp\~Temp\Død.Kalm.x264_temp\Død.Kalm.x264.x265_out.hevc" -
he gets an error from x265

I guess you should report that to ffmpeg?

[benwaggoner]

The benchmark for the trade-off parameters are x265.exe --tune film(without --rd --subme....) --preset veryslow. If you use --tune film --preset medium, you are almost as good as using --tune film --preset veryslow. The difference in bit-rate and visual quality is within a given threshold.
To clarify, you're referring to --tune grain in x265, right? There isn't a --tune film equivalent in x265 yet, nor --tune animation.

[filler56789]

I guess you should report that to ffmpeg?

I agree. avs2yuv works fine here with a file named "267øtest.avs". OS = US-English x64 Windows 7.

[littlepox]

To clarify, you're referring to --tune grain in x265, right? There isn't a --tune film equivalent in x265 yet, nor --tune animation.

No, I mean when I tested those trade-off parameters like rd=5/subme=3/b-intra, I set a comparison using the settings as in --preset veryslow, together with my other tunings like psy 2.0:3.0, aq 3:0.9...

veryslow uses subme=4 which I found to be inefficient, I change it to 3;
veryslow uses b-intra which is indeed useful, I keep it;
......
That's why in this --tune film you see some parameters typically in --preset. I believe they are necessary to keep the quality not degraded.

[stax76]

Problem was I was using CP 850 for batch files for any locale, it should be fixed using System.Console.InputEncoding.CodePage instead.

https://de.wikipedia.org/wiki/Codepage_850

[Khun_Doug]

When will the --help be updated to show the "--tune film" option? None of the 2.x encoders I have tested show this option.

Doug

[x265_Project]

When will the --help be updated to show the "--tune film" option? None of the 2.x encoders I have tested show this option.

Doug

x265 does not have a "--tune film".

[littlepox]

Just to clarify, the above discussion is not any official "--tune film", it is only "fan-made" customized tuning for film clips, and it is still fairly limited and immature.

[brumsky]

Several interesting facts about three different aq modes:

aq-mode = 1 is the safest choice. It is intended for high and stable quality encoding with 10-bit precision.

aq-mode = 2 is the most efficient choice. It gives less bits in high motion scenes compared to aq-mode 1, and it saves a lot of bit-rate, when you can choose to further lower down your crf or increase your psy. Human eyes are less sensitive to high motion scenes, so you can only spot its donwsides if you watch the video frame by frame. Recommend if you are using 10-bit, and encoding at a sweet-pot bit-rate.

aq-mode = 3 is the choice for 8-bit encoding, as well as low-bitrate 10 bit encoding. It distributes bits to dark areas, where color banding and blocking is most visible. Even in 10-bit encoding, if bit-rate is low, major distortions and detail loss are going to appear in dark site, and aq-mode=3 makes the best outcome. When used alone it significantly boosts the bit-rate, so you'd need to lower down the strength a bit(~0.2) and increase your crf for the size control.

The exact bitrate/crf intervals for each of them is circumstantial, we probably need further research on that.

Littlepox, what are the suggested CRF ranges for each of the modes?

Also, on another subject. I've been noticing issues with dark areas flickering. Kinda of a fussy look. It is difficult to describe.

Also, I noticed on stripped or checkered patterns a flickering effect as well, both in light and dark scenes.

Here are the settings I was using and noticed the issue.

--crf 21 --profile main10 --output-depth 10 --ctu 32 --max-tu-size 16 --bframes 8 --rc-lookahead 80 --scenecut 40 --ref 5 --limit-refs 0 --me 3 --merange 44 --subme 5 --no-rect --no-amp --limit-modes --max-merge 4 --no-early-skip --b-intra --no-sao --signhide --weightp --weightb --aq-mode 1 --aq-strength 1.0 --cutree --rd 4 --tu-intra-depth 3 --tu-inter-depth 3 --psy-rd 1.5 --psy-rdoq 5.0 --rdoq-level 2 --lookahead-slices 4 --qcomp 0.65 --no-strong-intra-smoothing --deblock -2:-2 --qg-size 32 --pmode

I've changed several of the settings after following this thread. :)

Thanks!

[Leo 69]

@brumsky

"Also, I noticed on stripped or checkered patterns a flickering effect as well, both in light and dark scenes."

Did you try lowering CRF to, say, 18? 21 is bad for my eyes, personally.

[Khun_Doug]

Just to clarify, the above discussion is not any official "--tune film", it is only "fan-made" customized tuning for film clips, and it is still fairly limited and immature.

Thanks for the clarification on the "fan made" option still in beta. I'll re-read some of the suggested settings and may be able to add some feedback. My primary focus is material from the 80's and 90's with a smattering of B&W classics. Almost all before HD filming was more prevalent so plenty of grain in all of these.

[RainyDog]

A beta version of the new --tune film based on the most up-to-date stable 10-bit build:

--ctu 32 --max-tu-size 16 --crf 18 --pbratio 1.2 --cbqpoffs -3 --crqpoffs -3 --no-sao --subme 3 --b-intra --no-amp --weightb --aq-mode 3 --aq-strength 0.9 --rd 5 --psy-rd 2.0 --psy-rdoq 3.0 --rdoq-level 2 --rc-lookahead 80 --qcomp 0.65 --no-strong-intra-smoothing

Tweak the crf between 16~20
Comments and feedback are welcome.

Littlepox, I've noticed that you're now only recommending to turn --amp off and leave --rect on. Previously you said that neither seemed to have any visible use so recommended to turn both off to save encoding time.

Are you now seeing a benefit to --rect then? Thanks.

[littlepox]

--rect is a bit useful so we recommend it at --preset slower/veryslow/placebo. However we do not think it valuable @ slow.
--amp, on the contrary, is only recommended @ --preset placebo; i.e., you have enough time to waste.


For those who give your feedback, kindly mention which bit-depth are you using. It is very common to have color-banding @ 8-bit without proper pre-processing; However if the source quality is good enough, massive color-banding and blocking should not appear in 10-bit encoding. Currently our focus is on the 10-bit ones.

[brumsky]

@brumsky

"Also, I noticed on stripped or checkered patterns a flickering effect as well, both in light and dark scenes."

Did you try lowering CRF to, say, 18? 21 is bad for my eyes, personally.

Leo 69, No I haven't tried CRF 18. I was hoping to get a smaller file size in general. I was hoping there was another setting I could use to assist with issues like this.

Littlepox post about aq-modes and how mode 3 give dark areas a higher preference for the dark scenes. This made me wonder if that could assist me with the issue I am seeing.

It looks like the picture becomes fussy or a significant amount of noise is added when it "flickers" - mostly in the dark scenes.

[Leo 69]

@brumsky

Can you provide a problematic sample? I'd be glad to play with it.

[pingfr]

Congratulations on the 2.0 milestone release.

I have a question for the devs so it might not be the best place to ask, maybe the Maling List is a better place, but;

Would there be any significant improvement in using such instructions sets: pclmulqdq (and maybe rdrand to some lesser extent?)

https://en.wikipedia.org/wiki/CLMUL_instruction_set

CLMUL instruction set is present in modern x86 CPUs since Ivy Bridge more or less and serves as an accelerator for GCM.

If the x265 code can take advantage of the CLMUL set we might even see a fps/efficiency/speed crunching increase. ;-)

My 2 cents.

[nevcairiel]

Would there be any significant improvement in using such instructions sets: pclmulqdq (and maybe rdrand to some lesser extent?)

x265 already uses all sorts of enhanced instruction sets from SSE to AVX2.
Note that carry-less multiplication has only very specific uses (mostly in crypto), but if it were to solve a specific problem more efficiently I'm sure they would use it.