x265 HEVC Encoder

[foxyshadis]

New features in x265 1.4+174-35d086074bb5 (https://www.mediafire.com/download/7h8421j2a0h8h07/x265_1.4+174-35d086074bb5.7z): different Noise Reduction values for Inter and Intra CUs, and a published parameter for bitrate control tolerance (internally already used for the CBR tuning).

Also 8-bit and 10-bit should have broadly similar sizes at the same crf now. Anyone using 10-bit and crf should adjust their base value accordingly.

For x265 project: Why remove --nr entirely, instead of making it an alias that sets both inter/intra?

[x265_Project]

For x265 project: Why remove --nr entirely, instead of making it an alias that sets both inter/intra?
You mean, why don't we remove it entirely? It's worth discussing, but my initial thought would be that we would want to make it easier to use noise reduction by providing a single setting. Anyone who wants finer control can override the --nr setting with the separate inter and intra values.

[LigH]

Yes, just as you explained, the suggestion is rather the opposite: You should please not remove "--nr X", but make it an alias to "--nr-intra X --nr-inter X". So it won't break compatibility to command line parameter sets created for older versions immediately. The current patch appears to remove "--nr", though, which is a pity.

And in addition: Why does it make sense to define different strengths? Do you already have evidence that it is useful? If yes, please give a sample which relation is how useful in which case... ;)

[foxyshadis]

You mean, why don't we remove it entirely? It's worth discussing, but my initial thought would be that we would want to make it easier to use noise reduction by providing a single setting. Anyone who wants finer control can override the --nr setting with the separate inter and intra values.

--nr is gone in the head, now. Simplifying to --nr X[:Y] would match the deblock switch, but verbose command-lines aren't the end of the world.

And in addition: Why does it make sense to define different strengths? Do you already have evidence that it is useful? If yes, please give a sample which relation is how useful in which case... ;)

Eh, it's always fun to have something new to play with. I'm going to try it out just to see what happens when you use wildly different values for each.

[x265_Project]

--nr is gone in the head, now.
That slipped past me. I'll chat with the boys and girls in the back room about the command-line syntax.

Tom

[lotusgg]

So... --aq-mode 1 is default now.

[Gravitator]

Who has the desire to demonstrate their configuration wizard on the > sample (https://mega.co.nz/#!dFdjlL5Q!X-39N69mg22VEH-eX9tvnDBHGmKVyEDgAX6o74k2G78) (within the framework 6800-7000kb/s). - In order to see the bar high and strive to exceed it.

[Gravitator]

So... --aq-mode 1 is default now.
This is to protect the heap of fans from the negligence of the developer :)

[benwaggoner]

That slipped past me. I'll chat with the boys and girls in the back room about the command-line syntax.



Tom


As long as we're messing with nr parameters and making them a lot more complicated, would it be worth considering being able to set different strengths for luma and chroma?

So, one could set luma and chroma strengths for both inter and predicted blocks. That'll give the boys and girls in the back room something to chew on :).

I don't know if it would actually be worthwhile to do chroma and luma differently without the parameter to test...


-Ben Waggoner (via TapaTalk)

[LigH]

Another weekly: x265 1.4+209-6ba7be7b1697 (https://www.mediafire.com/download/2ygm491yxel4qov/x265_1.4+209-6ba7be7b1697.7z)

[Motenai Yoda]

I don't know if it would actually be worthwhile to do chroma and luma differently without the parameter to test...
If --nr still is a dct "zeroer" maybe it can be simulate using DctFilter/DctFilterD

however how to use --deblock/--flt tC:Beta offsets?
why don't add a --fullhelp params instead of --log-level full --help?

[benwaggoner]

If --nr still is a dct "zeroer" maybe it can be simulate using DctFilter/DctFilterD
Potentially, yes. Although since it takes place after quantization, the specifics of the underlying codec probably have a significant impact.

[Daemon404]

Just a heads up, ChromaShift nightlies are currently down due to a failed HDD. They'll be back later today.

EDIT: It's back.

[oopsipoo]

hi guys, any eta on the opencl based encoder? i mean any planned/projected month/year?

[x265_Project]

hi guys, any eta on the opencl based encoder? i mean any planned/projected month/year?
Nothing to announce at this time. We have been working since the start of the x265 project on a private branch that leverages GPUs, but to get true acceleration under a wide range of conditions we need advanced capabilities in the chips and drivers. On some platforms these capabilities are just starting to become available. We've made great progress, but we will publish no code before its time.

[oopsipoo]

Nothing to announce at this time. We have been working since the start of the x265 project on a private branch that leverages GPUs, but to get true acceleration under a wide range of conditions we need advanced capabilities in the chips and drivers. On some platforms these capabilities are just starting to become available. We've made great progress, but we will publish no code before its time.

fair enough, thanks and keep up the excellent work

[LigH]

Belated Merry Christmas: x265 1.4+223-1bf769c6953d (https://www.mediafire.com/download/niadkkaqzowft6i/x265_1.4+223-1bf769c6953d.7z)

[aufkrawall]

Could it be that I444 is broken?
Videos look like this with LAV 0.63:
http://abload.de/thumb/i44410bit.mkv_snapshou0uhm.png (http://abload.de/image.php?img=i44410bit.mkv_snapshou0uhm.png)

Sample:
http://www24.zippyshare.com/v/90243098/file.html
Same happens with 8 bit.

[x265_Project]

Could it be that I444 is broken?
Videos look like this with LAV 0.63:
http://abload.de/thumb/i44410bit.mkv_snapshou0uhm.png (http://abload.de/image.php?img=i44410bit.mkv_snapshou0uhm.png)

Sample:
http://www24.zippyshare.com/v/90243098/file.html
Same happens with 8 bit.
Can you share more details?

What was your command line? Did you specify the input bit depth for the 10 bit encode? What was your video source (format, bit depth, etc.)? Did you try decoding the HEVC bitstream with the HM decoder to verify that LAV was not the problem?

[aufkrawall]

Source is AviSynth YV24 (Rec709) via MeGUI. I suppose avs4x265 is not guilty since HEVC result is fine if I don't specify to let x265 output I444. 4:2:0 result is fine.

Command line was very simple:
--crf 0 --input-csp i444 --range limited --output "output" "input"
I originally didn't specify the input depth for 10 bit, source is just 8 bit and with x265 8 bit build, it looks exactly the same.
Now I've just given it a quick try, specifying input depth doesn't change result.

Where can I get compiled HM decoder with documantation?
Btw: Does x265 really flag the files right when specifying range or colormatrix? MediaInfo doesn't read out these information, although I can't say if it's due to lack of support with HEVC or because the flags are simply not set.

[jlpsvk]

Any news about banding? Still huge artefacts with default AQ-MODE 1 and AQ-STRENGTH 1.0. Horrible comparing to x264. :( 10-bit encodes has not this problem, but only RK3288 HW based players will hopefully support 10-bit HEVC (is in the datasheet from Rockchip).

[LigH]

And did you even try to compare similar bitrates, or do you omit in your complaint that the bitrate of your x265 encode was a lot lower than the one of your x264 encode, making your complaint not quite helpful?

[mandarinka]

x265 doesn't have psychovisual RDO enabled by default (yet). Try with --psy-rd 1.0 or with --psy-rd 1.0 --psy-rdoq 5.0

[jlpsvk]

Yep..

I am encoding with psy-rd 1.0 and psy-rdoq 1.0...can test 5.0. but still horrible banding. :( No matter what the bit rate is... :( I can still see some banding on even higher bitrates, than with x264.

My command line:

--preset slow --crf 18.0 --frame-threads 3 --no-open-gop --psy-rd 1.0 --aq-mode 1 --aq-strength 1.0 --psy-rdoq 1.0 --keyint 240 --min-keyint 23
--pmode --range full --weightp --weightb --deblock -3:-3 --rd 4 --me 2 --pme --vbv-maxrate 0 --vbv-bufsize 0

On x264 with CRF=21 I cannot see any banding...yes...I know, CRF is not the same in x264 and x265. But subjectively, CRF 21 with x264 is overally worse, than CRF 18 with x265. Except color gradients and dark areas....there is big banding issue with 8-bit x265 (not in 10-bit x265). I cannot see these banding issues on x264 encodes.

Encoding source: Bluray
Encoding x265 version: 1.4.223 by LigH

[lotusgg]

Can you try a higher aq-strength, like 1.5 or 2.0?
--tune grain has also proven useful in that matter.

[mandarinka]

But you still didn't say what bitrates you are getting with x264 and with x265.

If you for example have 2000kbps at 720p with x264, it isn't very realistic that x265 would be just as good at say 800-1000kbps, especially if it has better preserved lineart (I usually see that in my testing) - that suggests x265 has put more bits into those parts at the expense of flat areas and textures.

[jlpsvk]

high aq-strength wastes bitrate for static parts of image and little movement is too ugly then. :(

what is tune grain doing? can see it in x265 documentation... :(

[jlpsvk]

@Mandarinka

x264:
Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings, CABAC : Yes
Format settings, ReFrames : 5 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 2h 0mn
Bit rate : 4 019 Kbps
Width : 1 920 pixels
Height : 800 pixels
Display aspect ratio : 2.40:1
Frame rate mode : Constant
Frame rate : 23.976 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.109
Stream size : 3.39 GiB (98%)
Writing library : x264 core 144 r2525 40bb568
Encoding settings : cabac=1 / ref=5 / deblock=1:-3:-3 / analyse=0x3:0x133 / me=umh / subme=11 / psy=1 / psy_rd=1.00:0.15 / mixed_ref=1 /
me_range=64 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=0 / chroma_qp_offset=-3 / threads=12 / lookahead_threads=3 /
sliced_threads=0 / nr=0 / decimate=0 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=16 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 /
weightb=1 / open_gop=0 / weightp=2 / keyint=240 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=60 / rc=crf / mbtree=1 / crf=21.0 /
qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=8 / vbv_maxrate=62500 / vbv_bufsize=78125 / crf_max=0.0 / nal_hrd=none / filler=0 / ip_ratio=1.40 /
aq=3:1.00

x265: (don't know why, MKVtoolnix is parsing out the x265 encoder options)
Video
ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Codec ID : V_MPEGH/ISO/HEVC
Duration : 2h 0mn
Bit rate : 2 617 Kbps
Width : 1 920 pixels
Height : 800 pixels
Display aspect ratio : 2.40:1
Frame rate mode : Constant
Frame rate : 23.976 fps
Bits/(Pixel*Frame) : 0.071
Stream size : 2.21 GiB (98%)

[lotusgg]

Small movements won't get messed if you use CRF with higher aq1 strength.
As for --tune grain, see the bottom of this page (http://x265.readthedocs.org/en/default/presets.html).

[jlpsvk]

ok..that is what i didn't know ,that in CRF, higher AQ-STRENGTH will not cut bitrate from moving parts. but again... I am afraid, that in that case, the file size will almost the same as in x264.

ok, trying now with:

--no-open-gop --psy-rd 1.0 --aq-mode 1 --aq-strength 1.8 --psy-rdoq 5.0 --keyint 240 --min-keyint 23
--pmode --range full --weightp --weightb --deblock -3:-3 --rd 4 --me 2 --pme --vbv-maxrate 0 --vbv-bufsize 0

Tha main goal is to recode my blurays to HEVC (to save space on NAS) but with the same visual quality, as with x264.

[jlpsvk]

Ok....with the higher stated settings...banding almost gone, but bitrate around 25% higher than with x264. :( I really don't need 50% less bitrate while having the same visual quality, but some 30% less of x264 would be good at the same visual quality. 10-bit x265 with CRF 20 looks great and has 50% less bitrate than x264. But, unplayable in most of HW players (all AMLogic chips with HEVC support does not have 10-bit decoding, only Rockchip RK3288 has, but not tested yet, as I am still waiting for Tronsmart R28 Pro).

[lotusgg]

Try --tune grain without specifying aq-strength or psy-rd/oq

[jlpsvk]

tried already....banding still present (though helped a little)....only thing which helped, is raising the aq-strength, but is raises bitrate to levels of x264.

[lotusgg]

so you either try aq-strength variations or give up to 10 bits.

[jlpsvk]

I know...but what is different, if x264 can do 8-bit without banding issues, and x265 no? :( if RK3288 will be able do decode 10-bit, I'm sure, I will stick with 10-bit. :)

[lotusgg]

try raising the bitrate by 1,5 and lowering the aq-strength to 1,6

[LigH]

Happy New Year: x265 1.4_244-f255e8d06423 (https://www.mediafire.com/download/4zcp2l49zdszc8v/x265_1.4_244-f255e8d06423.7z)

[m3sh]

I have been having some trouble with CRF encodes not properly limiting bitrate to the vbv-maxrate, hoping some of the experts here can point out what I've been missing.

x265 [info]: HEVC encoder version 1.4+5-eebb372eec893efc
x265 [info]: build info [Windows][GCC 4.9.1][64 bit] 8bpp
x265 [info]: Compiling by snayper [x265.ru]
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX

As an example... using a 4096x1716p24 clip source and testing a 7Mbps encode:

encoded 151 frames in 255.62s (0.59 fps), 7370.56 kb/s, SSIM Mean Y: 0.9892497 (19.686 dB)

when i have used the following encode .bat:

set max_gop="96"
set rd="3"
set bbias="40"
set cpbdelay="4"
set sar="1:1"
set fps="24000/1000"
set mealgo="star"
set psyrd="1.0"
set subme="7"
set maxmerge="5"
set color="bt709"
set aq_mode="2"
set aq_str="1.2"
set tu_intra_depth="4"
set tu_inter_depth="4"
set bframes="6"
set crf="18"
set ref="5"
set vbvbr="7000"
set /A vbvbuffer=%vbvbr% * %cpbdelay%
set title="7M_testclip"


%x265bin% --sar %sar% --colorprim %color% --transfer %color% --colormatrix %color% --crf %crf% --aq-mode %aq_mode% --aq-strength %aq_str% --weightb --fps %fps% --me %mealgo% --vbv-bufsize %vbvbuffer% --vbv-maxrate %vbvbr% --bitrate %vbvbr% --rc-lookahead %max_gop% --no-open-gop --keyint %max_gop% --b-intra --bframes %bframes% --bframe-bias %bbias% --tu-inter-depth %tu_inter_depth% --tu-intra-depth %tu_intra_depth% --ref %ref% --max-merge %maxmerge% --subme %subme% --psy-rd %psyrd% --rd %rd% --hrd --input-res 4096x1716 --ssim -o %title%.hevc %if% > %title%_x265.txt 2> %title%_x265_output.txt

I've got more egregious examples where the overshoot in bitrate is as much as 20% of the target bitrate, ie. testing at 1M bitrates, I get 1.2Mbps out from CRF 18, or at 7Mbps I get a 8.3Mbps output. Testing the same with CRF removed and using a typical 2 pass approach with the same settings otherwise and this does not happen. As well I find the behaviour changes depending on the content source, though sources are of varying frame rates: 24, 23.976, or 29.97 FPS and different resolutions (3840x2160, 4096x1716, 3840x1600).

P.S. Apologies to all if this was explored in previous posts to this thread. I am subscribed to the thread and haven't seen anything in the weekly digest, either way...

P.P.S - I'm well aware that SSIM results are skewed by psy-vis stuff, ignore it :)

[vivan]

Read about vbv - http://mewiki.project357.com/wiki/X264_Encoding_Suggestions#VBV_Encoding

Basically you have 4*7000 kb buffer that is
1) filled to 90% (vbv-init) when you start playback
2) could be filled at 7000 kb/s speed

This means that during playback you can get up to 7000*151/24 + 4*7000*0.9 bits from that buffer, which is 69 mb. Divide it by 151/24 and you'll get 11 mb/s (as maximum possible average bitrate that meets vbv settings).

Also you're setting both crf and bitrate --crf %crf% ... --bitrate %vbvbr% You shouldn't do that.

[m3sh]

@vivan...

Ahh yes, good catch on the miss on the crf/bitrate setting. Out of curiousity, will it simply discard the --bitrate assertion if CRF is set?

I remain a bit confused that this is an issue with x265. I've used basically the same settings with vbv for x264, ie. 4s CPB delay, max rate set at for example 7Mbps, and have *never* exceeded the maxrate over thousands of encodes, but your math makes sense.

Actually - I think this is in part an artifact of the sample being short based upon the math you've shown. If a long asset, the vbv buffer fill component of that sum has negligible impact on the max bitrate... ie. (7000*151/24 + 7000*4*0.9)/(151/24) becomes basically 7000 when the length of the asset is sufficiently long. Explains why I never saw this a lot before (wasn't doing this kind of testing before with short samples).

[vivan]

Ahh yes, good catch on the miss on the crf/bitrate setting. Out of curiousity, will it simply discard the --bitrate assertion if CRF is set?As I understood docs (http://x265.readthedocs.org/en/default/cli.html#cmdoption--bitrate) if you set bitrate then crf is ignored.
So you're getting 1-pass bitrate mode.

I remain a bit confused that this is an issue with x265. I've used basically the same settings with vbv for x264, ie. 4s CPB delay, max rate set at for example 7Mbps, and have *never* exceeded the maxrate over thousands of encodes, but your math makes sense, so I guess that's all just a coincidence.Probably they were much longer? Basically max possible overshoot in % is (length + delay*0.9) / length, so it becomes negligible on much longer videos.

[jlpsvk]

@LigH

Thanks!! What's new? :)

[foxyshadis]

@LigH

Thanks!! What's new? :)

8th->15th:
Faster, more avx2 ASM, bug fixes
New: Chroma ME
Default AQ is now 1

15th->29th:
Faster, more avx2 & sse2 ASM, bug fixes

29th->5th:
Faster, more sse4 ASM (especially for psy-rdo), bug fixes
Intra search tries harder

[jlpsvk]

Thanks. :)

I just realized, that my oldie PC (Intel Core2 Quad Q8300 2.5GHz) with 4GB RAM, running KODIbuntu 14 can decode 10-bit HEVC 1080p videos smoothly without single framedrop at 50% CPU usage. :) Decoder used is ff-hevc.

[LigH]

In general, there are several optimizations for CPUs supporting AVX2 and SSE4 recently. But there are also generic optimizations, restructuring, Assembler versions of previous C routines (even without too modern instruction sets) which report speed-ups of up to 10x for tiny bits (e.g. sign calculation for decision switches). No, that alone won't speed up x265 by 10x :o but may have an impact even on older CPUs (like AMD before FX generation, using at most SSE2).

Having a fast decoder is nice, but doesn't matter in a thread about the x265 encoder. ;)

[jlpsvk]

@LigH

Allow me one more off-topic. Do you think that Intel J1900 (Quad-Core, 2.0GHz, Haswell based Celeron) will be able to decode 1080p HEVC smoothly? I want to build HTPC with KODIbuntu, PCIe DVB-S2 tuner and with SW decoding of HEVC.

[nevcairiel]

Do you think that Intel J1900 (Quad-Core, 2.0GHz, Haswell based Celeron) will be able to decode 1080p HEVC smoothly?

Thats not a Haswell-based Celeron, thats a Atom-based Celeron.
It'll quite likely be too slow, as it doesn't even have SSE4.2, not to mention AVX or AVX2.

[jlpsvk]

yeah...but as I mentioned....Core2 Quad Q8300 has not either and only 50% CPU usage with 1080p. And in tests, both are almost comparable in multicore operations.

[LigH]

Not my decision, I am no moderator here. Furthermore, I have no clue ... but I believe a new topic asking for "low threshold hardware" (with practical experience reports) would not be worse than "polluting" this existing topic. ;)
__

Back to x265:

I just read about a submitted patch introducing a kind of "lookahead buffer overrun buffer" for a smoother prediction especially with "--b-adapt 2". The developers appear to be full of ideas, certainly based on very systematic analyses of bottlenecks.

Go on! http://cosgan.de/images/smilie/froehlich/a020.gif (http://www.cosgan.de/smilie.php)

[jlpsvk]

:) Great.

And agree...here's the topic for decoding HW.

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