x265 HEVC Encoder

[nandaku2]

Hi Tom, I sure will do when you say psy-rd is ready for testing. But the source is so grainy I'm not convinced psy-rd will bring any benefit at such compression. At least in x264 it does not : it removes a lot of details to put back grain noise. And before testing psy-rd, I wanted to make sure standard SAD rdo was as good as x264 in grain and detail retention.

Are the algorithms for placing I-frames so different in x264 and x265? Why would x265 put one third less I-frames with both scenecuts at 40%? This biases comparison.

EDIT : and it makes single frame comparison with x264 even more pointless.
EDIT 2 : Got it. x264 and x265 --bframes 3 --b-adapt 1 return the same amount of I-frames. Placement and numbers of P and B frames are still totally different though.

The lookahead cost function in x265 is different than x264. x265 evaluates more intra modes and some changes in bidir modes (as compared to x264). This makes the slice decisions different. You could use --b-adapt 0 if you need all slice decisions same across x265 and x264.

[LigH]

The latest patch is supposed to reduce the RAM utilization. May be interesting to check v1.1+193 (http://www.mediafire.com/download/04t74go3oc7gumb/x265_1.1+193-da4aa721bf2f.7z) against an older build regarding encodability of 4K video even with a 32-bit build.
__

Stable at 1.6 GB with preset "slow", looks promising.
__

Preset "slower" requires about 1.9 GB RAM (Private Bytes: 2,040,092 KB / Working Set: 1,768,604 KB – at frame 30); the patch must have made it more dependent on the complexity, instead of assuming a maximum always.

I believe there may still be headroom with more efforts, but a further reduction will probably be harder to achieve (not without some deep reorganization and allocation "smartness"). For now, even on almost "obsolete" 32-bit OS, 4K encoding will be possible with preset "slow", maybe even "slower".

[foxyshadis]

@benwaggoner & @foxyshadis

well, to be specific

1) now at same medium bitrate(medium bitrate means, e.g. x264 crf22), x264-10bit act much better than x264-8bit in prevent banding(especially in dark flat area because of gamma compression) if Source has no banding -- of course benefit from high interal bit depth, also have positive to prevent other artifacts -- and now x264-10bit optimize is good enough even at [same encoding time & bitrate], it could still act better quality than x264-8bit

2) x265 8bpp now also use 8bit internal, I should use x265 16bpp for high bit internal -- x265 works like x264 in this regard

3) until now, H.264/AVC 10bit-depth has low compatibility. e.g. we could not use Hardware acceleration for 10bit video; mobile device/PS3 like hardware device(diff from PC could use x86-CPU for generic software decode and almost ignore decode performance and power consumption) playing 10bit video is much difficulty and unfriendly; seems video editing fields is the same(e.g. Adobe Premiere is not support for H.264 10bit video). I'm very worry about HEVC/H.265 age will be the same...

4) and...for [8bit input] and high-bit internal, if use 8bit output rather than 10bit output, should be smaller size at same quality?(I'm Not expert on this)

----
so, I'm interest in 8bit in/output and high-bit internal, especially in encoding
seek for lowest bitrate for same high quality is eternal topic for video compression, and I am, but I also care about a degree of compatibility (and encoding time)...

It doesn't matter what you put in or take out, the compatibility revolves entirely around the internal bit-depth. Whether the future brings wider 10-bit compatibility is entirely unknown, we just have to hope that since it's included in the base spec, some hardware makers will take advantage of that. So far the major GPU makers (Intel, AMD, nVidia, PowerVR) are barely incorporating support for 8-bit HEVC.

Using 10-bit internal with 8-bit input doesn't seem to have the same advantage over plain 8-bit in x265 as with x264. (And even that is fairly small.) I'm not sure if that's the encoder, or the standard, but we'll have to see how it evolves. Maybe HEVC just doesn't cause as much banding as AVC in general at 8-bit?

With respect to size, it doesn't matter if what you output, it's still the same file (unless you're re-encoding) and internally every calculation is done at the internal bit-depth until the final output, when it can be left alone or downsampled. Even with 8-bit input, Main 10 with 16-bit output instead of 8-bit dithered might look better simply due to not rounding as early. (No decoder currently produces float output, although they could if they wanted.) I don't know if anyone's really tested that, and you'd need a decent monitor to tell the difference, and right now I don't have one. It's an interesting area to investigate.

It definitely will help if you're doing any shader processing on the output; MadVR will accept up to 16-bit and won't ever drop down until it outputs to the screen.

[LigH]

Impressive results (http://www.mediafire.com/download/uc4f6prh7rjc01w/crowd_run_2160p50.x265-crf30-aq-psy.mp4) with the command line
--crf 30 --preset slower --aq-mode 2 --aq-strength 1.5 --psy-rd 0.3
Even the lawn in the background, which used to lose a lot of detail, is now satisfyingly persistent.

[zerowalker]

Thought of just asking, how is the Psy-rd getting a long?

I know it had issues and such a while back, is that still the case, or are you making progression?

[Procrastinating]

They've been making plenty of progress, but as far as I know it's not complete to the extent that they want yet. It's good enough now that it's better than not having it in a number of cases though.

[zerowalker]

Ah that's nice to hear.
Has it improved the "Blur" x265 tends to give details?

[LigH]

Carefully used, together with adaptive quantization, Psy-RDO has the potential to preserve more detail than in previous builds. Even though it is not yet completely correct.

They will tell us when they did it for certain...

In the meantime, enjoy another 4K encode (http://www.mediafire.com/download/88zuz6cmcps3288/in_to_tree_2160p50.x265-crf30-aq-psy.mp4) demonstrating the efficiency (same options as above (http://forum.doom9.org/showthread.php?p=1684607#post1684607)); x264 used to fail especially in the sky at similar bitrates (noticably worse behaviour at up to 3 times the bitrate of the x265 sample in an earlier 1080p test).

[Atak_Snajpera]

Carefully used, together with adaptive quantization, Psy-RDO has the potential to preserve more detail than in previous builds. Even though it is not yet completely correct.

They will tell us when they did it for certain...

In the meantime, enjoy another 4K encode (http://www.mediafire.com/download/88zuz6cmcps3288/in_to_tree_2160p50.x265-crf30-aq-psy.mp4) demonstrating the efficiency (same options as above (http://forum.doom9.org/showthread.php?p=1684607#post1684607)); x264 used to fail especially in the sky at similar bitrates (noticably worse behaviour at up to 3 times the bitrate of the x265 sample in an earlier 1080p test).

May I ask what cpu do you have? My Xeon 8c / 16t 2.9Ghz has troubles to maintain smooth frame rate during playback in MPC-HC 1.7.5 (EVR mode) . Video chokes at the very beginning and at the very end while playing in loop mode. Cpu usage is at ~66%. With MadVR enabled it is even worse. Probably my R4850 512MB does not have enough memory for 4K.

http://i.cubeupload.com/IyIqHA.png

[LigH]

My equipment here is way below yours: An AMD Phenom-II X4 is too slow to play this 4K video in realtime, and madVR is no option anyway with a GeForce 9600.

At home I have a Phenom-II X6 and GTS 450 available, that won't be fast enough either, I believe.

[zerowalker]

Okay thank for the fast update info:)

As for the Video LigH posted, i can tell you that i have no way of playing it in realtime.

And i have a quite good PC (i5 760 @4Ghz), and it goes to 100% and it's nowhere near it's original speed.

[EncodedMango]

And I thought it didn't work because I tried it on a laptop.

EDIT: Just to clarify, this is x265 decoding speed/cost at present which is causing this, right?

[LigH]

These clips are encoded with a rather high complexity, and they are to be played with 50 fps. I am not surprised that decoding them is too elaborate for realtime playback.

Realtime playback of less complex 25 fps 4K video would be possible with current hardware and decoders.

[nevcairiel]

Note when testing H.265 playback, you should most definitely use 64-bit versions of the player and decoder, as they are up to 50-100% faster, especially on 4K content (at least for anything FFmpeg based, like LAV/MPC-HC/etc.)
A lot of the decoder assembly is not compatible with 32-bit due to its complexity (and because the developers didn't want to spend time making it even more complex by allowing 32-bit support).

[fumoffu]

64bits doesn't help much in this case.
Tested on 4core i5 @4Ghz and 1GB video memory - nowhere near smooth playback. MPC-HC nightly 1.7.5.146 was using less then 300MB GPU memory and MPC-BE 1.4.2 almost 700MB (I have 1680x1050 monitors). I wonder if number of CPU threads have any effect on video memory required? It shoudn't right? Maybe I'll test it later. Also if you use MPC you can save like 50MB by changing the number of EVR Buffers from default 5 to 4.

[x265_Project]

Thought of just asking, how is the Psy-rd getting a long?

I know it had issues and such a while back, is that still the case, or are you making progression?

Work continues. Expect more updates this week.

[benwaggoner]

It doesn't matter what you put in or take out, the compatibility revolves entirely around the internal bit-depth. Whether the future brings wider 10-bit compatibility is entirely unknown, we just have to hope that since it's included in the base spec, some hardware makers will take advantage of that. So far the major GPU makers (Intel, AMD, nVidia, PowerVR) are barely incorporating support for 8-bit HEVC.
We are seeing some TV players support internal 10-bit decode, like the latest Samsung UHD TVs. They can play back HEVC up to 2160p60 10-bit. But not H.264 High 10.

Using 10-bit internal with 8-bit input doesn't seem to have the same advantage over plain 8-bit in x265 as with x264. (And even that is fairly small.) I'm not sure if that's the encoder, or the standard, but we'll have to see how it evolves. Maybe HEVC just doesn't cause as much banding as AVC in general at 8-bit?
It's by spec; HEVC does 8-bit better than H.264 did, so there's no real reason to encode 8-bit sources in Main 10.

[upyzl]

It doesn't matter what you put in or take out, the compatibility revolves entirely around the internal bit-depth. Whether the future brings wider 10-bit compatibility is entirely unknown, we just have to hope that since it's included in the base spec, some hardware makers will take advantage of that. So far the major GPU makers (Intel, AMD, nVidia, PowerVR) are barely incorporating support for 8-bit HEVC.
Maybe it's a little too early to talk about Hardware HEVC support now...
We are seeing some TV players support internal 10-bit decode, like the latest Samsung UHD TVs. They can play back HEVC up to 2160p60 10-bit. But not H.264 High 10.
Good to hear.
hope HEVC(8&10bit) Hardware support could reach today's as AVC-8bit in 2~3 years :D
Using 10-bit internal with 8-bit input doesn't seem to have the same advantage over plain 8-bit in x265 as with x264. (And even that is fairly small.) I'm not sure if that's the encoder, or the standard, but we'll have to see how it evolves. Maybe HEVC just doesn't cause as much banding as AVC in general at 8-bit?
It's by spec; HEVC does 8-bit better than H.264 did, so there's no real reason to encode 8-bit sources in Main 10.
really I'm not familar with HEVC spec, I maybe choose testing to verify... but definitely I think it's not proper time to test whether x265-8bit could handle as good as x264-10bit currently(mainly in middle-high bitrate for quite high quality encoding, I know in low bitrate x265 win completely), I may test when x265 is good for that

With respect to size, it doesn't matter if what you output, it's still the same file (unless you're re-encoding) and internally every calculation is done at the internal bit-depth until the final output, when it can be left alone or downsampled. Even with 8-bit input, Main 10 with 16-bit output instead of 8-bit dithered might look better simply due to not rounding as early. (No decoder currently produces float output, although they could if they wanted.) I don't know if anyone's really tested that, and you'd need a decent monitor to tell the difference, and right now I don't have one. It's an interesting area to investigate.
maybe I should ignore it...even if it really could reduce/save size, there's few people could identify different(of course I've no decent monitor)... hope future somebody could solve that :p
It definitely will help if you're doing any shader processing on the output; MadVR will accept up to 16-bit and won't ever drop down until it outputs to the screen.
Yes, in fact I just do.:D

last, thank you all for the patient replys:thanks:

[kolak]

We are seeing some TV players support internal 10-bit decode, like the latest Samsung UHD TVs. They can play back HEVC up to 2160p60 10-bit. But not H.264 High 10.


It's by spec; HEVC does 8-bit better than H.264 did, so there's no real reason to encode 8-bit sources in Main 10.

New Sony 4K TVs also support 10bit HEVC.

[Motenai Yoda]

No decoder currently produces float output, although they could if they wanted.
if mantissa is 10bit (16bit float) or less then I think will be same/worst than 10bit integer, coz above 511 up to 1023 exponent should be 0*, maybe it will help a bit for low levels.
*that was wrong, exponent should be 9+15.

It's by spec; HEVC does 8-bit better than H.264 did, so there's no real reason to encode 8-bit sources in Main 10.
according to my tests Main10 give slightly better results than Main with 8-bit sources.

just a question, with --input-depth 16 how it will be reduced to 10bit? truncated? rounded? dithered?

[foxyshadis]

if mantissa is 10bit (16bit float) or less then I think will be same/worst than 10bit integer, coz above 511 up to 1023 exponent should be 0, maybe it will help a bit for low levels.

Ew, no. Half-precision was a great hack for its time, but there's plenty of bandwidth to go around now, even for 2160p60. 32-bit is fine (which is what madVR uses).

As impressive as that data flood would be, at 6.4GB/s, that's still only about half of a PCIe 2 x16 link, and PCIe 3 doubles your bandwidth again.

according to my tests Main10 give slightly better results than Main with 8-bit sources.

just a question, with --input-depth 16 how it will be reduced to 10bit? truncated? rounded? dithered?

Sierra-2-4A error diffusion, according to the comment on ditherPlane in filters.cpp. (Comments in x265.h say downshifted, but that isn't true anymore.)

[sneaker_ger]

That requires the --dither switch, though?

[foxyshadis]

Yeah, I'm an idiot, I missed that. If you don't use --dither, it just bit-shifts to the internal, which always truncates down (or zero-extends 8-bit).

[LigH]

v1.1+202-e2ed009d296a (https://www.mediafire.com/download/jvclf65ewkj2mn8/x265_1.1%2B202-e2ed009d296a.7z) introduces Psy-RDO for RD levels 2..4; but without an official "all-clear", don't expect it to be completely "fixed" yet.

[Selur]

Note when testing H.265 playback, you should most definitely use 64-bit versions of the player and decoder, as they are up to 50-100% faster, especially on 4K content (at least for anything FFmpeg based, like LAV/MPC-HC/etc.)
sadly most folks here are stuck with 32bit since there's no 64bit version of MadVR :(

[LigH]

Isn't madVR a slowdown anyway, due to a rather complex chroma upsampling? Or can it be faster than a "plain" renderer like Hardware Overlay or EVR? It will probably depend on the GPU and its shader speed. I don't expect a passive cooled version (max. 128 bit bus) to be suitable.

[James Freeman]

sadly most folks here are stuck with 32bit since there's no 64bit version of MadVR :(

Sad but true.
:(

[xkinn123]

Has anyone test some samples using chrome offset (for example, --cbqpoffs 2 --crqpoffs 2) with color sample i422?
i can't play it on my mpv, mplayer, ffplay, or even MPC and VLC... (both linux and windows with the latest update)

[nevcairiel]

Isn't madVR a slowdown anyway, due to a rather complex chroma upsampling? Or can it be faster than a "plain" renderer like Hardware Overlay or EVR? It will probably depend on the GPU and its shader speed. I don't expect a passive cooled version (max. 128 bit bus) to be suitable.

In my experience using plain EVR was faster than madVR for 4K, but YMMV.

[benwaggoner]

In my experience using plain EVR was faster than madVR for 4K, but YMMV.
But MadVR is still the easiest way to do Rec. 2020 output. I think the new 2014 Adobe CC apps may be able to do this as well by applying A color profile to the HDMI output, which I hope to play with this weekend.

[Motenai Yoda]

Yeah, I'm an idiot, I missed that. If you don't use --dither, it just bit-shifts to the internal, which always truncates down (or zero-extends 8-bit).

ok but as docs says --dither works for 8bit only, not 10bit

http://x265.readthedocs.org/en/default/cli.html#cmdoption--dither

[Sagittaire]

ok but as docs says --dither works for 8bit only, not 10bit

http://x265.readthedocs.org/en/default/cli.html#cmdoption--dither

Well simply because dithering is really usefull for 8 bits or less.

[foxyshadis]

ok but as docs says --dither works for 8bit only, not 10bit

http://x265.readthedocs.org/en/default/cli.html#cmdoption--dither

Huh, docs are wrong. With --dither enabled, the code unconditionally dithers any higher depth to the internal depth, no matter what the build is. It upconverts all input to 16bit, then the main dither function is designed to go from 16bit to any lower depth. Must have changed since the docs were written.

[Sagittaire]

Huh, docs are wrong. With --dither enabled, the code unconditionally dithers any higher depth to the internal depth, no matter what the build is. It upconverts all input to 16bit, then the main dither function is designed to go from 16bit to any lower depth. Must have changed since the docs were written.

make upconvert to 16 bits with lower depth input is not Dithering but just complete aleatoire noise. Moreover make Dithering for 16 bits input is really, really, really useless.

[foxyshadis]

make upconvert to 16 bits with lower depth input is not Dithering but just complete aleatoire noise. Moreover make Dithering for 16 bits input is really, really, really useless.

I mean, the process is:

If --dither and input_depth > internal_depth --> pad input to 16-bit (unless it already is) --> dither down to internal_depth (8 or 10) --> pass to main encoder. Changing all input to 16-bit just makes the dither algorithm simpler. However, this is a function of x265cli, not libx265.

If it's not dithered, then the libx265 core will just immediately truncate or pad to internal_depth, and only ever holds 8- or 10-bit packed planes to save memory (though some functions temporarily expand blocks to 16-bit for convenience). It has no notion of dithering.

[phate89]

I have a question (i'm not an expert but i want to understand better the reasons). If i understood well google with vp9 while working on 10/12 bit wants to switch everything to 16 bit internally and other decoders already do this. Why x265 keeps 2 separate files and the 8 bit one is only 8 bit?
I understand that the advantage of higher internal precision is very small but it will slow down a lot more or the speed is the same? Will x265 join the 2 branches in the future?

[LoRd_MuldeR]

You are mixing up standards and implementations here!

HEVC is a video compression standard. And indeed, the HEVC standard does specify Profiles (http://en.wikipedia.org/wiki/High_Efficiency_Video_Coding#Profiles) for 8-Bit, 10-Bit, 12-Bit or even 16-Bit internal precision!

Now, x265 is an HEVC encoder. So it implements HEVC in software. This means they can only support what is defined by the standard. And, as far as I know, they support at least 8-Bit and 10-Bit. Not sure if they support 12-Bit and 16-Bit yet.

Furthermore, "High Bit-Depth" support in x265 is a compile-time option - just like in x264. So it's a decision you need to make at compile-time and that you can not change at runtime!

But that doesn't mean that x265 has two separate branches. In does not! It's actually the exactly same code that you can build either with "High Bit-Depth" enabled or not. That's why you get two separate x265 binaries. But that's all about it.

The reason is that computers usually address memory in units of 2^N bits. So for the 8-Bit build, you can get away with 8-Bit (one byte) per pixel/component. But for 10-Bit or more, you will need to use 16-Bit per pixel/component.

Changing the data types in your code between 8-Bit and 16-Bit is something you can hardly do at runtime, so that's why it's a compile-time option...

(I think in theory it would be possible to support 8-Bit encoding in a "High Bit-Depth" binary. You would just leave the upper eight bits unused. But that would probably be unnecessary slow, compared to a regular 8-Bit build!)

[phate89]

(I think in theory it would be possible to support 8-Bit encoding in a "High Bit-Depth" binary. You would just leave the upper eight bits unused. But that would probably be unnecessary slow, compared to a regular 8-Bit build!)

Maybe i'm not explained myself well but this is what i was talking about. I know that they're not the same. But an "high bit depth" build can do a 8 bit output and it should actually even improve (a little bit) the quality.
It's actually the first thing google will do to bring high bit depth to vp9 (https://www.youtube.com/watch?v=xo_R40C7RTo min 4:50).
But how much slower is an high bit depth encoding with output 8 bit than a regular encoding?

[LoRd_MuldeR]

The "High Bit-Depth" build option is basically about how much memory you allocate per pixel/component. With a "High Bit-Depth" build it's 16-Bit (as required for, e.g., 10-Bit/12-Bit encoding), otherwise it's just 8-Bit.

As said before, in theory, you could do 8-Bit encoding while internally keeping 16-Bit per pixel/component.

But all values would have to be truncated to 8-Bit anyway, i.e. the upper 8-Bit remain unused. This means that the output would be exactly the same as with a "true" 8-Bit build. Only that encoding would probably be running significantly slower...

BTW: You cannot do the "intermediate" calculations at 16-Bit precision and only round/truncate the final result to 8-Bit in order to get a valid 8-Bit stream. You need to enforce the same precision all the way trough! Otherwise encoder and decoder will de-synchronize. For example, since P- and B-Frames store the difference to the reference frames, the encoder must reconstruct those references frames exactly as a decoder would.

[xooyoozoo]

The VP9 high bit depth part was a brief tidbit in a high-gloss promotional. I'm not sure if I'd use it to determine what is and isn't possible for a software encoder (edit: without deviating from previous codec/decoder standard).

[x265_Project]

I have a question (i'm not an expert but i want to understand better the reasons). If i understood well google with vp9 while working on 10/12 bit wants to switch everything to 16 bit internally and other decoders already do this. Why x265 keeps 2 separate files and the 8 bit one is only 8 bit?
I understand that the advantage of higher internal precision is very small but it will slow down a lot more or the speed is the same? Will x265 join the 2 branches in the future?
Basically, an 8 bit encoder will run almost twice as fast as an encoder that is using 16 bits to store and process each color sample. Modern microprocessors support data types and instructions that can store and process multiple data samples in one instruction. This concept is called Single Instruction Multiple Data, or SIMD. More specifically, these instructions include Streaming SIMD Extensions (SSE), or Advanced Vector Extensions (AVX). In a 128 bit wide register the 8 bit build of x265 can store and operate on sixteen 8 bit color samples. The high bit depth (16 bit) build can only store and operate on eight 16 bit data samples with each SSE or AVX instruction. So, when you use twice the width for each data sample, you move and process data at half the speed.

Conceptually, I suppose we could compile both 8 bit and 16 bit versions of x265 into separate libraries, then create a single executable that would call the right library at run-time, but the executable would be twice as large, and it would take longer and be more difficult to build and maintain. Choosing the right library to use is really a job for application developers.

[IgorC]

x265 --crf 20 --preset medium --rd 6 --psy-rd 1.0 (average bitrate 1060 kbps) - ENCODING TIME : 22m55s
https://mega.co.nz/#!kM80wCTI!rIhFZ40t-9i_yISWiUN_rJ-4pEG6sdgi_7dlLY0f-a4

x264 --crf 21 --preset veryslow (average bitrate 1031 kbps) - ENCODING TIME : 9m22s
https://mega.co.nz/#!0ZcxzajB!QjH8qs4CX0GEZLtJkrUq6qEWkjA40ScXX1s3WR01K5E


Latest Xvid + slowest settings enabled + 2-pass
https://mega.co.nz/#!IZFmBDqI!4oIPL_XKkvac0-X6L-FRUsOz_z97RR025T7e1W_ZWAA


Great. Thank You. Just was watching for HEVC vs H.264 comparison. I can't decide between x264 and x265.
x264 has more details at cost of more noise. x265 has more stability in motion.
And xvid was clearly inferior to both. Disabling/Enabling post-processing in Xvid oficial decoder doesn't help here.

I don't understand people yelling about testing at 500 kbps. What is it? year 2004? 640x272?
Even Youtube uses 1 Mbit+ for 720p(VP9/H.264). Also a projection of results from low bitrate to high are generally misleading.


Similar history with audio compression. 48Khz HE-AAC@32kbps with parametric stereo will definitely sound better than mp3 with the same bitrate and so what. The question is : Will you be encoding your FLAC collection for your ipod/smatphone using such ridiculously low bitrate??? I do not think so! Most likely you will be using something between 64kbps-128kbps.
Exactly.
HE-AACv2@32kbps is better than MP3@32kbps. Though HE-AACv2@128kbps is considerably worse than MP3@128kbps.

Same valid for video codecs. One particular H.264 encoder can be better than MPEG2 at low bitrates. But if MPEG2 presererves fine details/grain good enough while one H.264 encoder doesn't do that then the situation can change at high bitrates.

Nothing new was said here. Just some simple logic and observations.

[2Bdecided]

HE-AACv2@128kbps is considerably worse than MP3@128kbps.?

At 128kbps, a half-decent HE-AACv2 encoder should switch off PS and SBR, just giving you standard AAC - which beats mp3 at 128kbps.

I guess if you force it to use PS, or force it to use SBR at a low-ish frequency, it would sound worse.

Back (vaguely) on topic: current broadcast encoders seem to favour the AVC tools in HEVC...
http://www.obe.tv/about-us/obe-blog/item/13-a-look-at-the-hevc-encoder-bbc-uhd-world-cup-part-2

Cheers,
David.

[Sagittaire]

Well, I make visual test on psy-rdo and with default setting, I have big local temporal quality flicking (seem not be a spacial quality problem). I make investiquation and psy-rdo seem have big problem on I-P-B frame transition.

For solve that I reduce the ratio quality between frame type ... and I have good result on my sample test. Psy-rdo seem work (on my sample test) even with high value if you choose low ratio quality between frame type.

x265.exe --input hp.yuv --output crf23aq.265 --input-res 720x304 --fps 25 --crf 24 --preset veryslow --aq-mode 2 --aq-strength 1.0 --psy-rd 0.5 --bframes 3 --min-keyint 1 --ipratio 1.1 --pbratio 1.1 --psnr

[Sagittaire]

Exactly.
HE-AACv2@32kbps is better than MP3@32kbps. Though HE-AACv2@128kbps is considerably worse than MP3@128kbps.

Same valid for video codecs. One particular H.264 encoder can be better than MPEG2 at low bitrates. But if MPEG2 presererves fine details/grain good enough while one H.264 encoder doesn't do that then the situation can change at high bitrates.

Nothing new was said here. Just some simple logic and observations.

No, it's really false simply because you choose 16 bits, 44.1 Khz, 2 channel source. There are many other properties than bitrate for Audio and for Video too.

- HE-AAC at 128 Kbps will be better than mp3 at 128 Kbps and by far if you choose 5.1 channel or 96 Khz source. HE-AAC 5.1 48Khz or HE-AAC 2.0 96Khz will produce better audio experience than equivalent MP3 2.0 48Khz at 128 Kbps and by far ... ;-)

- It's the same thing for video. 5 Mbps HEVC at 720x576 will be certainely not really better than 5 Mbps MPEG2 and even perhaps worst is some situation. Anyway 5 Mbps HEVC at 4K will produce uncomparable video experience if you compare at 5 Mbps MPEG2 in all resolution.

[LigH]

Version 1.2 is coming soon™; in the meantime, have v1.1+258-6623f1195baa (https://www.mediafire.com/download/9251jmhhc6l7cdm/x265_1.1+258-6623f1195baa.7z) (most recent stable+default merge) in my MediaFire archive (https://www.mediafire.com/#6lfp2jlygogwa).

[Sagittaire]

Well this time no doubt, x265 outperform x264 even with particular short sample like park_joy_1080p50.y4m. Psy-RDO work very well.

http://jfl1974.free.fr/park_joy_1080p50_x265.mp4

[LigH]

And there is version 1.2; just waiting for the verbose summary.

[Atak_Snajpera]

Well this time no doubt, x265 outperform x264 even with particular short sample like park_joy_1080p50.y4m. Psy-RDO work very well.

http://jfl1974.free.fr/park_joy_1080p50_x265.mp4

Liar!

https://mega.co.nz/#!wFMw0ICR!QGqoZBmYBIntiEq9cOdA4xr_pSvG_pDyJFqRxsSqH78

[Sagittaire]

Liar!

https://mega.co.nz/#!wFMw0ICR!QGqoZBmYBIntiEq9cOdA4xr_pSvG_pDyJFqRxsSqH78

Well I confirm that my x265 encoding is better than your x264 encoding ... and by far. Make screenshoot if you want tak_Snajpera (And buy a white cane or dog)

In order:
- More temporal stability for x265 and by far
- Less mosquito noise for x265 and by far
- less blocking for x265 and by far
- more high frequency retention (detail) for x265 and by far

Mosquito noise and detail retention are not the same thing ... !!!

[Atak_Snajpera]

Well I confirm that my x265 encoding is better than your x264 encoding ... and by far. Make screenshoot if you want tak_Snajpera (And buy a white cane or dog)

In order:
- More temporal stability for x265 and by far
- Less mosquito noise for x265 and by far
- less blocking for x265 and by far
- more high frequency retention (detail) for x265 and by far

Mosquito noise and detail retention are not the same thing ... !!!

And ofcourse you have forgotten about the most important thing. DETAILS ;) x265 blurs everything like crazy. See grass , see water , see leaves. They must pay you for spreading those lies no doubt!

x264 frame 100
http://i.cubeupload.com/mVSONo.png

x265 frame 100
http://i.cubeupload.com/Oc3H1z.png

[a5180007]

First frame : http://screenshotcomparison.com/comparison/82931

EDIT :
Although overall movie sizes are the same
x264 1st I-frame is 90,534 bytes, avg QP 34
x265 1st I-frame is 47,600 bytes, avg QP 40

Very different decisions... @Sagittaire : what are the encoding parameters?

Funny to see how the "banding artefacts" are related to the CTUs.
There is definitely something borked with psy-rd reconstruction.

http://i.imgur.com/aUafEw5.png

[fumoffu]

How about my x264 encode: http://a.pomf.se/onaaol.mkv (ugh.. sry filehost changes file names)
It looks similar to x265 but water is much better.

[Sagittaire]

And ofcourse you have forgotten about the most important thing. DETAILS ;) x265 blurs everything like crazy. See grass , see water , see leaves. They must pay you for spreading those lies no doubt!

x264 frame 100
http://i.cubeupload.com/mVSONo.png

x265 frame 100
http://i.cubeupload.com/Oc3H1z.png

Well, I don't like Screenshoot but like your eyes are really strange I will make that with the same frame 100:

http://jfl1974.free.fr/Comparison_100.png

Like you can see, x265 high frequency retention is by far better for x265. You say "more detail for x264" and I say "hard mosquito noise for x264" (and I prove that with your screen).

When I compare x265 vs x264 encoding I see:
- Hard temproral instability for x264
- Major blocking hellfest for x264
- Major Ringing hellfest for x264

For last time MOSQUITO NOISE IS NOT DETAIL RETENTION ... !!!

[Atak_Snajpera]

My eyes are fine. The problem is with your damaged brain. For some odd reason it prefers blured image instead of sharper with higher complexity. I hope they pay you well atleast for your trolling...

[poisondeathray]

Some strange issues with that red umbrella ghosting / echo image?

[Sagittaire]

My eyes are fine. The problem is with your damaged brain. For some odd reason it prefers blured image instead of sharper with higher complexity. I hope they pay you well atleast for your trolling...


Seriousely, In YOUR screen you prefer x264 ... ???

It's Ringing and Blocking hellfest ... lol

I can't even see some head on x264 encoding. For you, good detail prevervation must cut the head ... :eek:

And I use the same frame 100 than your screenshoot. Really easy for me to find other frame with really bad quality for x264 and bad detail preservation.

[a5180007]

@Sagittaire: could you please give the encoding parameters.

EDIT : will x265 write the encoding parameters in the SEI like x264 does in a near future?
I find it very annoying not to be able to see these parameters when downloading a x265 encoding.

@Atak_Snajpera : the x264 image is a Degas painting, the x265 is a Monet painting. Some like Monet, some others prefer Degas.
At this level of compression it is impressionism rather than reflecting reality. What is the point of testing at those crf when lower resolutions give better quality?

[Atak_Snajpera]

at low bitrate both encodes look bad. x264 is at least sharper. Grass , leaves ,water in x265 is noticable less detailed. I imediatelly notice that in motion.

[Sagittaire]

Some strange issues with that red umbrella ghosting / echo image?

Yes I see that for x265. It's certainely temporal artefact because here the quantification is really high. Anyway I find temporal stability and global quality really better for x265. There are major flicking in x264 encoding for I-P-B frame transition.

[Sagittaire]

at low bitrate both encodes look bad. x264 is at least sharper. Grass , leaves ,water in x265 is noticable less detailed. I imediatelly notice that in motion.

For last time it's not more detailled. It's mosquito noise like I prove that with your screen.

With your screen I see more sharp contour on tree or on character. It's really simple to see that.

Change your eyes .... really now.

[Atak_Snajpera]

you can easily tune x264 for the same result. Tomorrow i will try with preset anime ;)

btw what's the story with that funny deblocking effect on trees in first plane ;) ?

[Sagittaire]

you can easily tune x264 for the same result. Tomorrow i will try with preset anime ;)

No because I already try. x264 is not able at this quality level to have good temporal quality. A this level quality, you have major blocking and major ringing on moving object for x264 and not for x265.

Moreover your eyes see detail retention for x264 but it's not that. It's simply hard ringing and mosquito noise (temporal instability is easy to notice) but It reproduce no existing detail if you compare with the source ... :eek:

[poisondeathray]

Yes I see that for x265. It's certainely temporal artefact because here the quantification is really high. Anyway I find temporal stability and global quality

really better for x265. There are major flicking in x264 encoding for I-P-B frame transition.

I don't recall seeing that on previous x265 snaphots with the same test source with high quantizers. Please post the full x265 parameters

Other "echo/ghosts" as well - the 1st person has some "ghost" trailing him

I agree temporal stability is a major strength with x265 and other HEVC implementations - much more stable than x264, but this "echo/ghosting" temporal artifact is worrisome

"Global quality" however , is debatable, as you can see there seems to be some disagreement on subjective quality . Like all things, there are pros/cons

[Sagittaire]

http://forum.doom9.org/showthread.php?p=1686027#post1686027

I reduce ratio on I-P-B frame transition because:
- Reduce block flicking
- Reduce artecfact with high PSY-RDO value

[poisondeathray]

EDIT : will x265 write the encoding parameters in the SEI like x264 does in a near future?
I find it very annoying not to be able to see these parameters when downloading a x265 encoding.


Yes this would be very helpful for debugging, providing feeback, testing

[Atak_Snajpera]

Sagittaire

Good lossy codecs by default are designed to fool your brain. I don't care if those details are real or not. My brain prefers higher complexity. It is the same with audio. HE-AAC 64 kbps with fake half bandwidth (SBR) sounds much better than LC-AAC with the same bitrate.

[a5180007]

btw what's the story with that funny deblocking effect on trees in first plane ;) ?

Yes, that and the fact that the I-frame is half the size of the x264 one -about the same byte size as the following P-frames.
That's why it would be nice to have the encoding parameters to be able to reproduce *. I remember reading no so long ago in this post a moderator requesting the parameters to be given for all posted videos.
Hopefully I will get more luck when things have cooled down between you two ;)

* EDIT : E.g. if the number of B frames is not the same, I would not call this a fair comparison. I saw there was already a difference in --keyint (x265 is 250, x264 is 500).

[Sagittaire]

Yes, that and the fact that the I-frame is half the size of the x264 one -about the same byte size as the following P-frames.
That's why it would be nice to have the encoding parameters to be able to reproduce. I remember reading no so long ago in this post a moderator requesting the parameters to be given for all posted videos.
Hopefully I will get more luck when things have cooled down between you two ;)

http://forum.doom9.org/showthread.php?p=1686027#post1686027

[a5180007]

Thanks Sagittaire.


x265.exe --input hp.yuv --output crf23aq.265 --input-res 720x304 --fps 25 --crf 24 --preset veryslow --aq-mode 2 --aq-strength 1.0
--psy-rd 0.5 --bframes 3 --min-keyint 1 --ipratio 1.1 --pbratio 1.1 --psnr

With all respect, how is it related to your 1080p50 park-joy encoding? Which parameters are relevant?
With --crf 24 --preset veryslow --aq-mode 2 --aq-strength 1.0 --psy-rd 0.5 --bframes 3 --min-keyint 1 --ipratio 1.1 --pbratio 1.1 (x265_1.1+258), the first I-frame is 212,278 bytes, four times the size of the one in your encoding. Your encoding is likely 1 pass ABR, not --crf.

[foxyshadis]

Geez guys, you said exactly the same things and had just as much luck convincing each other last time. Like I said then, duke it out in another thread if you really care that much, and keep it civil.

[Sagittaire]

Thanks Sagittaire.


x265.exe --input hp.yuv --output crf23aq.265 --input-res 720x304 --fps 25 --crf 24 --preset veryslow --aq-mode 2 --aq-strength 1.0
--psy-rd 0.5 --bframes 3 --min-keyint 1 --ipratio 1.1 --pbratio 1.1 --psnr

With all respect, how is it related to your 1080p50 park-joy encoding? Which parameters are relevant?
With --crf 24 --preset veryslow --aq-mode 2 --aq-strength 1.0 --psy-rd 0.5 --bframes 3 --min-keyint 1 --ipratio 1.1 --pbratio 1.1 (x265_1.1+258), the first I-frame is 212,278 bytes, four times the size of the one in your encoding. Your encoding is likely 1 pass ABR, not --crf.

No ... x265 reported same quantizer and really higher size for IFrame (and really higher quality for psnr) than PFrame. Defaut ratio mean Oversized IFrame and too high quality flicking for my eyes. Same quantizer for I-P-B mean same quality level for all codec.

E:\Mes Logiciels\Codec\x265>x265.exe --input park_joy_1080p50.y4m --output crf24aq.265 --input-res 1920x1080 --fps 50 --
crf 35 --preset veryslow --aq-mode 2 --aq-strength 1.0 --psy-rd 1.0 --bframes 3 --min-keyint 1 --ipratio 1.1 --pbratio 1
.1 --weightp --psnr --frames 50 --recon x265.y4m
y4m [info]: 1920x1080 fps 50000/1000 i420p8 sar 1:1 frames 0 - 49 of 500
y4m [info]: reconstructed images 1920x1080 fps 50000/1000 i420
x265 [info]: HEVC encoder version 1.1+253-11c808e562b894d8
x265 [info]: build info [Windows][GCC 4.8.3][64 bit] 8bpp
x265 [info]: Compiling by snayper [x265.ru]
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64 SlowShuffle
x265 [warning]: --psnr used with psy on: results will be invalid!
x265 [warning]: --tune psnr should be used if attempting to benchmark psnr!
x265 [info]: WPP streams / pool / frames : 17 / 4 / 2
x265 [info]: Main profile, Level-5 (Main tier)
x265 [info]: CU size : 64
x265 [info]: Max RQT depth inter / intra : 3 / 3
x265 [info]: ME / range / subpel / merge : star / 57 / 4 / 4
x265 [info]: Keyframe min / max / scenecut : 1 / 250 / 40
x265 [info]: Lookahead / bframes / badapt : 40 / 3 / 2
x265 [info]: b-pyramid / weightp / weightb / refs: 1 / 1 / 0 / 5
x265 [info]: Rate Control / AQ-Strength / CUTree : CRF-35.0 / 1.0 / 1
x265 [info]: tools: rect amp rd=6 psy-rd=1.0 lft sao-lcu signhide
x265 [info]: frame I: 1 Avg QP:39.66 kb/s: 22466.80 PSNR Mean: Y:29.689 U:33.834 V:36.805
x265 [info]: frame P: 13 Avg QP:39.51 kb/s: 13403.75 PSNR Mean: Y:28.313 U:31.299 V:35.122
x265 [info]: frame B: 36 Avg QP:41.79 kb/s: 2440.41 PSNR Mean: Y:27.818 U:31.446 V:35.230
x265 [info]: global : 50 Avg QP:41.16 kb/s: 5691.41 PSNR Mean: Y:27.984 U:31.456 V:35.234
x265 [info]: Weighted P-Frames: Y:0.0% UV:0.0%
x265 [info]: consecutive B-frames: 14.3% 0.0% 0.0% 85.7%

encoded 50 frames in 434.37s (0.12 fps), 5691.41 kb/s, Global PSNR: 29.324

[SeeMoreDigital]

Geez guys, you said exactly the same things and had just as much luck convincing each other last time. Like I said then, duke it out in another thread if you really care that much, and keep it civil.Agreed...

Indeed, you might be better off creating the new topic by splitting out the non-relevant posts from this topic ;)

[a5180007]

http://i.imgur.com/EubXIDn.png
Park Joy CRF encoding, really?

@x265 Tom, do you have plans to add the encoding parameters to the SEI? I guess it is a very easy change, more likely a commercial decision.
EDIT : maybe you could add a switch eg --info to add parameters to SEI.

[Romario]

So, where are Changelog for x265 1.2 ? Please. :)

[foxyshadis]

@x265 Tom, do you have plans to add the encoding parameters to the SEI? I guess it is a very easy change, more likely a commercial decision.
EDIT : maybe you could add a switch eg --info to add parameters to SEI.

A patch to do so was just posted to the mailing list, should hit the repo soon. No switches, it'll be always on. Cool!

[x265_Project]

A patch to do so was just posted to the mailing list, should hit the repo soon. No switches, it'll be always on. Cool!

Thanks for the suggestion a5180007. This was on our todo list. We talked about this today, and after some discussion we agreed it should be even higher on our todo list. So, there you have it.... a patch was developed and is queued for testing.

[x265_Project]

x265 release 1.2 was tagged on Wednesday. This was a regularly scheduled release with improvements in performance, major improvements in memory usage, and improved psy-rd behavior.

There were a few of new options introduced:

--cu-stats, x265_param.bLogCuStats - enabling logging of CU stats (for R&D purposes only)

--hrd, x265.bEmitHRDSEI - enable HRD SEI signaling (use this option to add Hypothetical Reference Decoder information into the HEVC bitstream, in order to comply with HRD specifications)

--ipratio/--pbratio were exposed to the CLI

--lambda-file - allows experimentation with lambda tables (for R&D purposes only - this should not be needed for normal production encoding purposes)

Plus a number of options added for multi-pass encoding (incomplete). We will document those in the next release after the feature is complete.

Full documentation for the features supported in the release can be found at http://x265.readthedocs.org/en/1.2/.

[a5180007]

@x265 When trying to encode a video the same size as max CTU

(e.g. fill 1,536 "a" chars in an editor and save the file as 32x32.yuv) :
"x265 --input-res 32x32 --fps 25 --ctu 32 --threads 1 32x32.yuv -o 32x32.hevc" crashes.
"x265 --input-res 32x32 --fps 25 --ctu 32 --threads 2 32x32.yuv -o 32x32.hevc" hangs

Is this expected? I mean, surely the max ctu is supposed to be smaller than the video size, but shouldn't the exception be caught?
EDIT : x265 8bpp 1.2+76-6e116af on W8.1 32bits

[x265_Project]

@x265 When trying to encode a video the same size as max CTU

(e.g. fill 1,536 "a" chars in an editor and save the file as 32x32.yuv) :
"x265 --input-res 32x32 --fps 25 --ctu 32 --threads 1 32x32.yuv -o 32x32.hevc" crashes.
"x265 --input-res 32x32 --fps 25 --ctu 32 --threads 2 32x32.yuv -o 32x32.hevc" hangs

Is this expected? I mean, surely the max ctu is supposed to be smaller than the video size, but shouldn't the exception be caught?
EDIT : x265 8bpp 1.2+76-6e116af on W8.1 32bits
A 32x32 video? Is this a real use-case? What are you trying to encode, animated icons?

A crash is never "expected". We work hard to make x265 robust, and a crash is never acceptable, regardless of the command-line syntax or the input video. Yes - exceptions should be caught. If x265 fails it should fail gracefully, with an error message explaining why it couldn't complete the encode. I'll have to check with our engineers, but I suspect that a 32x32 video may be beyond the limits of the HEVC specifications.

[x265_Project]

If x265 fails it should fail gracefully, with an error message explaining why it couldn't complete the encode.

Starting with https://media.xiph.org/video/derf/y4m/flower_cif.y4m... scale to 32x32 with FFMPEG...
ffmpeg -s 352x288 -r 25.0 -pix_fmt yuv420p -i flower_cif_352x288.yuv -vf scale=32:32 flower_cif_32x32.yuv

x265 fails gracefully if you use default settings...

C:\Testx265>x265 --input v:\Sequences\flower_cif_32x32.yuv --input-res 32x32 --fps 30 -o 32x32.hevc
yuv [info]: 32x32 fps 30000/1000 i420p8 frames 0 - 249 of 250
x265 [info]: HEVC encoder version 1.2+54-e3e077965c39
x265 [info]: build info [Windows][MSVC 1700][64 bit] 8bpp
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZ CNT BMI2
x265 [error]: Picture size must be at least one CTU
x265 [error]: failed to open encoder

Encoding hangs with --ctu 32
I was able to reproduce the crash with --ctu 32 --threads 1 (thanks for reporting... we'll find and fix both of the above).

Encoding is successful with --ctu 16
C:\Testx265>x265 --input v:\Sequences\flower_cif_32x32.yuv --input-res 32x32 --
ctu 16 --fps 30 -o 32x32.hevc
yuv [info]: 32x32 fps 30000/1000 i420p8 frames 0 - 249 of 250
x265 [info]: HEVC encoder version 1.2+54-e3e077965c39
x265 [info]: build info [Windows][MSVC 1700][64 bit] 8bpp
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZ CNT BMI2
x265 [info]: WPP streams / pool / frames : 2 / 8 / 3
x265 [info]: Main profile, Level-1 (Main tier)
x265 [info]: CU size : 16
x265 [info]: Max RQT depth inter / intra : 1 / 1
x265 [info]: ME / range / subpel / merge : hex / 57 / 2 / 2
x265 [info]: Keyframe min / max / scenecut : 25 / 250 / 40
x265 [info]: Lookahead / bframes / badapt : 20 / 4 / 2
x265 [info]: b-pyramid / weightp / weightb / refs: 1 / 1 / 0 / 3
x265 [info]: Rate Control / AQ-Strength / CUTree : CRF-28.0 / 1.0 / 1
x265 [info]: tools: rd=3 lft sao-lcu signhide

x265 [info]: frame I: 1, Avg QP:35.75 kb/s: 60.72
x265 [info]: frame P: 86, Avg QP:36.65 kb/s: 19.43
x265 [info]: frame B: 163, Avg QP:44.70 kb/s: 3.73
x265 [info]: global : 250, Avg QP:41.89 kb/s: 9.36
x265 [info]: Weighted P-Frames: Y:1.2% UV:0.0%
x265 [info]: consecutive B-frames: 29.9% 9.2% 5.7% 54.0% 1.1%

encoded 250 frames in 0.07s (3846.15 fps), 9.36 kb/s
A new speed record for HEVC encoding! I'm going to put out a press release now.

[a5180007]

A 32x32 video? Is this a real use-case? What are you trying to encode, animated icons

Hi Tom,

Yeah, something like that :) Seriously, I was playing with 64x64 and 32x32 single frame yuv for Visual Studio step-by-step tracing purpose -to reduce number of encoded CTUs, and understand the process better. I agree this is not a likely situation for HEVC, but I also agree all cases should be considered for robustness.

And who knows, this Schrödinbug might help in solving the Heisenbugs ;)
Note that --threads >1 case should hang only for 0xFFFFFFFF mseconds, but I didn't have the patience to wait and see what would happen next...


EDIT : the encoding parameters are now in the SEI, thanks for this, very useful.

x265 (build 26) - 1.2+81-454a2fc37fee:[Windows][MSVC 1800][32 bit] 8bpp - H.265/HEVC codec - Copyright 2013-2014 (c)
Multicoreware Inc - http://x265.org - options: 32x32 fps=25000/1000 bitdepth=8 wpp ctu=16 tu-intra-depth=1 tu-inter-depth=1 me=1
subme=2 merange=57 no-rect no-amp max-merge=2 no-early-skip no-fast-cbf rdpenalty=0 no-tskip no-tskip-fast strong-intra-smoothing
no-lossless no-cu-lossless no-constrained-intra open-gop interlace=0 keyint=250 min-keyint=25 scenecut=40 rc-lookahead=20 bframes=4
bframe-bias=0 b-adapt=2 ref=3 weightp no-weightb aq-mode=2 aq-strength=1.00 cbqpoffs=0 crqpoffs=0 rd=3 signhide lft sao
sao-lcu-bounds=0 sao-lcu-opt=1 b-pyramid cutree rc=crf crf=28.0 qcomp=0.60 qpmin=0 qpmax=51 qpstep=4 ipratio=1.40 pbratio=1.30

But the build is still shown as build 26 -which I understand is the default build only in the case the cloning has not been made with Mercurial.
Shouldn't this be changed to the changeset revision number (in this case 7329)?

Also, it does not show the number of detected threads, which is important for reproducibility.

[LigH]

Despite a few compiler warnings, I uploaded x265 v1.2+82-6055baa75085 (https://www.mediafire.com/download/tduyyhjribgyblb/x265_1.2_82-6055baa75085.7z) as another merge-with-stable release.

[upyzl]

waiting for MediaInfo to support the new SEI :)

But the build is still shown as build 26 -which I understand is the default build only in the case the cloning has not been made with Mercurial.
Shouldn't this be changed to the changeset revision number (in this case 7329)?
maybe that's similar as x264 core number, not total rev number?
Also, it does not show the number of detected threads, which is important for reproducibility.
agreed

[Kurtnoise]

But the build is still shown as build 26 -which I understand is the default build only in the case the cloning has not been made with Mercurial.
Shouldn't this be changed to the changeset revision number (in this case 7329)?
The number here corresponds to the current API (http://en.wikipedia.org/wiki/Application_programming_interface) version, not the hash from the repository...

[a5180007]

The number here corresponds to the current API (http://en.wikipedia.org/wiki/Application_programming_interface) version, not the hash from the repository...

Indeed, it makes sense! Thanks Kurtnoise.

[Sagittaire]

http://i.imgur.com/EubXIDn.png
Park Joy CRF encoding, really?


Well you have source and encoding setting. It's easy to reproduce.

Anyway you make major error interpretation with your graph. CRF mode mean (for the encoder) constant quality (or constant quantizer with P-B ratio, AQ-PSY correction, AQ-RD correction, qcomp correction ... etc) and certainely not constant size for Pframe. Really better to check overall quantizer in your graph, no?

x265 [info]: frame I: 1 Avg QP:39.66 kb/s: 22466.80 PSNR Mean: Y:29.689 U:33.834 V:36.805
x265 [info]: frame P: 13 Avg QP:39.51 kb/s: 13403.75 PSNR Mean: Y:28.313 U:31.299 V:35.122
x265 [info]: frame B: 36 Avg QP:41.79 kb/s: 2440.41 PSNR Mean: Y:27.818 U:31.446 V:35.230
x265 [info]: global : 50 Avg QP:41.16 kb/s: 5691.41 PSNR Mean: Y:27.984 U:31.456 V:35.234

[LigH]

As far as I understood, "Constant Rate Factor" works like a threshold of maximum distortion (loss of detail) between original and reconstructed encoded video. From scene to scene, there are different requirements to stay below a maximum distortion. When there is little detail (blurred original), already a slightly more coarse quantization can guarantee enough detail preservation; this scene is "more compressible".

[a5180007]

Well you have source and encoding setting. It's easy to reproduce.

You are right, although the low I-frame size and the slope on the first 80 frames made me think it was ABR, the Park Joy CRF encodings have the same characteristics.

I am still bemused by the "scars" created by the psyrd 0.5, very visible on the bigger CTUs. I hope this can be solved.
EDIT : Might be we don't see the same artefacts with x264 psyrd simply because the macroblocks are small. Maybe the psyrd strength has to be tweaked according to the CTU size: a bigger CTU has less energy/pixel and might require less psyrd change.

Also, any reason why AQ auto-variance is still experimental in x264 but default in x265?

[Audionut]

Well the entire codebase is still somewhat experimental, right? :p

[fumoffu]

btw. I was wondering how does AQ auto-variance work - both in x264 and x265. It chooses some AQ value per every frame, right? But how does it chooses the value? Does it look for edges or smooth areas, measure picture "complexity"?
From what I understand AQ is sort of trade off between sharp edges and detail in relatively flat textured. So how does it decide what is more important in given frame?
Can the algorithm can be summarized in few sentences?

[a5180007]

AQ=1 : the aq-strength for all frames is the same.
AQ=2 : will adapt the aq-strength for each frame, based on its energy (ie complexity).

For the moment x265 is still oriented towards maximum ssim (default no-psyrd, aq=2). I haven't read anywhere that aq=2 would increase subjective quality.

[fumoffu]

AQ=2 : will adapt the aq-strength for each frame, based on its energy (ie complexity).


this doesn't really answer my question fully. lets say the complexity is high - does adaptive AQ lowers or increases AQ value? One way saves bitrate the other improves quality (with crf encoding). What if the picture is 50/50 for example, the bottom is grass and top half is clear blue sky? I guess it uses average complexity of the whole picture... Would it be possible to auto change AQ value for every CTU? ;)

[LigH]

Result of last week: x265 1.2+239-eb983d29c11a (https://www.mediafire.com/download/0q8gnzcy6cznyd6/x265_1.2+239-eb983d29c11a.7z) supports embedded encoding options and is supposed to speed up encodes on some AMD processors (amount yet untested).

[a5180007]

this doesn't really answer my question fully. lets say the complexity is high - does adaptive AQ lowers or increases AQ value? One way saves bitrate the other improves quality (with crf encoding). What if the picture is 50/50 for example, the bottom is grass and top half is clear blue sky? I guess it uses average complexity of the whole picture... Would it be possible to auto change AQ value for every CTU? ;)

In both cases AQ=1 or AQ=2, the quantizer varies for each CTU. This is the purpose of AQ.
AQ=2 strength is increased when frame average complexity increases, which means for each CTU the quantizer offsets from the frame average quantizer are increased. In other words, with AQ=2 in a complex frame there is a bigger difference between higher and lower quantizers than with AQ=1.

[fumoffu]

In both cases AQ=1 or AQ=2, the quantizer varies for each CTU. This is the purpose of AQ.
AQ=2 strength is increased when frame average complexity increases, which means for each CTU the quantizer offsets from the frame average quantizer are increased. In other words, with AQ=2 in a complex frame there is a bigger difference between higher and lower quantizers than with AQ=1.

OK I think I get it now. So if I understand correctly if the average complexity lowers the AQ strength is decreased. But that would mean that flat areas are getting less bits. What if those flatter areas are really important to me? I need as much detail there as possible? Would I be better off setting AQ mode to 1 and maybe even increasing AQ strength manually?

[Asmodian]

OK I think I get it now. So if I understand correctly if the average complexity lowers the AQ strength is decreased. But that would mean that flat areas are getting less bits. What if those flatter areas are really important to me? I need as much detail there as possible? Would I be better off setting AQ mode to 1 and maybe even increasing AQ strength manually?

Does't it mean that in complex frames flat areas get more of a boost than they do in simple frames? So if 50% grass 50% sky is "normal" AQ then in all sky AQ is weak while in all grass any simple CTUs get a larger boost.

This makes sense to me, a smooth red ball in the middle of a field of grass should get an extra boost vs the field while in a sky shot everything should be compressed pretty much the same.

I think? :p

[upyzl]

is it normal when see settings from SEI?
head contains junk words:
D:\enc>strings test_info.hevc | head
Nx265 (build 27) - 1.2+261-d303b4d860e9:[Windows][ICC 1400][64 bit] 8bpp - H.265
/HEVC codec - Copyright 2013-2014 (c) Multicoreware Inc - http://x265.org - opti
ons: 1920x1080 fps=24000/1001 bitdepth=8 wpp ctu=64 tu-intra-depth=1 tu-inter-de
pth=1 me=1 subme=2 merange=57 no-rect no-amp max-merge=2 no-early-skip no-fast-c
bf rdpenalty=0 no-tskip no-tskip-fast strong-intra-smoothing no-lossless no-cu-l
ossless no-constrained-intra open-gop interlace=0 keyint=250 min-keyint=23 scene
cut=40 rc-lookahead=20 bframes=4 bframe-bias=0 b-adapt=2 ref=3 weightp no-weight
b aq-mode=2 aq-strength=1.00 cbqpoffs=0 crqpoffs=0 rd=3 signhide lft sao sao-lcu
-bounds=0 sao-lcu-opt=1 b-pyramid cutree rc=crf crf=26.0 qcomp=0.60 qpmin=0 qpma
x=51 qpstep=4 ipratio=1.40 pbratio=1.30
RdN(
L8rx{
(.m`D4(!
kiKE
7<yQ
+20u
m;D-
>1.g
_/GT3K

D:\enc>strings test_no-info.hevc | head
RdN(
L8rx{
(.m`D4(!
kiKE
7<yQ
+20u
m;D-
>1.g
_/GT3K
Yt^5
compare: https://bitbucket.org/multicoreware/x265/commits/6af56f7c870355152c9897a7bca9fbd8047dd5fc

[LigH]

It is absolutely normal that data in the header consists of byte values which correspond to a few readable characters in ASCII code. It also consists of non-printable characters, but those are ignored by "strings", like shorter sequences of readable characters.

Computer scientists who know some basics about Claude Shannon's theory about information and entropy won't be surprised about this result.

You just discovered the "semantic gap": A HEVC decoder sees no meaning in the SEI info which a human can read; a human sees no meaning in the header data which a HEVC decoder can interpret.

[upyzl]

@LigH

oh, that's it... I thought the cmd would just output only the human-readable info, and if that it could be saved by a string variable directly for other usage...

[LigH]

The tool "strings" just filters longer sequences of readable characters, without knowing if it is actually text meant to be read by humans. "Random" sequences of data bytes "incidently" making readable character sequences pass it too.

[xooyoozoo]

Multi-pass encoding is now enabled through the cli.

Based on a few tests, the SSIM of CRF ~= Pass2 >= Pass1, so it seems to be working fine. However, "turbo first pass" doesn't exist yet.

[x265_Project]

Yes, 2 pass encoding is enabled in the Dev build, but there are a few bugs that we are aware of and working on (dealing with compatibility with rate control options used in the first or second pass). Detailed feedback (ideally, with source clips available to us and steps to reproduce the results) is welcomed.

Tom

[Sagittaire]

Multi-pass encoding is now enabled through the cli.

Based on a few tests, the SSIM of CRF ~= Pass2 >= Pass1, so it seems to be working fine. However, "turbo first pass" doesn't exist yet.

well you can make yourself "turbo first pass". I make several test and that work very well ...

[Selur]

I make several test and that work very well ...
What options did you disable/change during 1st pass?

----
btw. 2pass + qpfile -> crash (https://bitbucket.org/multicoreware/x265/issue/67/2pass-qpfile-specified-frame-type-not)

[Sagittaire]

What options did you disable/change during 1st pass?

----
btw. 2pass + qpfile -> crash (https://bitbucket.org/multicoreware/x265/issue/67/2pass-qpfile-specified-frame-type-not)

I make that for good first pass speed:

x265.exe --input hp.yuv --output crf23aq.265 --input-res 720x304 --fps 25 --pass 1 --stats hp.log --bitrate 450
--preset fast --me dia --ref 1 --aq-mode 0 --aq-strength 1.0 --psy-rd 0.0 --bframes 3 --b-adapt 2 --min-keyint 1 --ipratio 1.2 --pbratio 1.2 --psnr

Only frame decision is important (b-adapt 2). You can use very fast quality decision without problem (me, subme, ref, rd ...).

[Selur]

thanks

[Sagittaire]

well some test with 2 pass mode:

- fast first pass mode with crf
- Npass with fast, medium, slow, slower, veryslow and placebo preset

|--------------|----------|----------|-----------|
| fast | 449 kbps | 42.97 dB | 13.98 fps |
| medium | 449 kbps | 43.10 dB | 12.13 fps |
| slow | 449 kbps | 43.35 dB | 3.40 fps |
| slower | 448 kbps | 43.72 dB | 1.22 fps |
| veryslow | 449 kbps | 43.74 dB | 0.75 fps |
| placebo | 449 kbps | 43.75 dB | 0.47 fps |
| balanced | 449 kbps | 43.31 dB | 7.93 fps |
|--------------|----------|----------|-----------|

Conclusion:

- 2 pass mode work very well even if you use fast first pass.
- On my system (c2d Q6600) you have abyssal speed delta between medium and slow preset. It's certainely in the most important speed zone because BD Ripp 1080p will be done in this speed zone with performant CPU system. I propose alternative "balanced" preset setting in this really important zone.

balanced = slower + rd 4 + no-rect + no-amp + me hex

[x265_Project]

well some test with 2 pass mode:

- fast first pass mode with crf
- Npass with fast, medium, slow, slower, veryslow and placebo preset

|--------------|----------|----------|-----------|
| fast | 449 kbps | 42.97 dB | 13.98 fps |
| medium | 449 kbps | 43.10 dB | 12.13 fps |
| slow | 449 kbps | 43.35 dB | 3.40 fps |
| slower | 448 kbps | 43.72 dB | 1.22 fps |
| veryslow | 449 kbps | 43.74 dB | 0.75 fps |
| placebo | 449 kbps | 43.75 dB | 0.47 fps |
| balanced | 449 kbps | 43.31 dB | 7.93 fps |
|--------------|----------|----------|-----------|

Conclusion:

- 2 pass mode work very well even if you use fast first pass.
- On my system (c2d Q6600) you have abyssal speed delta between medium and slow preset. It's certainly in the most important speed zone because BD Ripp 1080p will be done in this speed zone with performant CPU system. I propose alternative "balanced" preset setting in this really important zone.

balanced = slower + rd 4 + no-rect + no-amp + me hex
Hi Sagittaire,
Thanks for the feedback. The big difference between medium and slow is that medium doesn't test rectangular blocks (--no-rect). Once you turn on --rect, you greatly increase the number of possible ways to partition a 64x64 CU. You can see what I mean if you look at the top of page 3 of this paper... https://www.ic.tu-berlin.de/fileadmin/fg121/Source-Coding_WS12/selected-readings/2012_12_HEVC-BM.pdf. At the first level of the quad-tree, you can partition a CU 8 different ways. With --no-rect, this drops to only 2 possibilities. The same is true at every level of the quad-tree except when you get down to 8x8 pixel blocks.

So, once you add --rect, there is a big increase in the number of possible partitions that must be checked to see which results in the most efficient way to encode the CU.

[foxyshadis]

Hi Sagittaire,
Thanks for the feedback. The big difference between medium and slow is that medium doesn't test rectangular blocks (--no-rect). Once you turn on --rect, you greatly increase the number of possible ways to partition a 64x64 CU. You can see what I mean if you look at the top of page 3 of this paper... https://www.ic.tu-berlin.de/fileadmin/fg121/Source-Coding_WS12/selected-readings/2012_12_HEVC-BM.pdf. At the first level of the quad-tree, you can partition a CU 8 different ways. With --no-rect, this drops to only 2 possibilities. The same is true at every level of the quad-tree except when you get down to 8x8 pixel blocks.

So, once you add --rect, there is a big increase in the number of possible partitions that must be checked to see which results in the most efficient way to encode the CU.

Maybe --rect could become a 0-3 argument, each testing more levels and partition possibilities at each level? Or make it depend on the rd level? Similar to how Steve talked about minimizing the number of intra tests on the mailing list a few days ago.

[x265_Project]

Maybe --rect could become a 0-3 argument, each testing more levels and partition possibilities at each level? Or make it depend on the rd level? Similar to how Steve talked about minimizing the number of intra tests on the mailing list a few days ago.
The same thought occurred to me as I typed the response above. I didn't want to raise the possibility publicly without checking on the scope of effort, so I emailed our Dev team asking if --rect 1 could be limited to 2N x N rectangles , with --rect 2 adding all of the 2N x n rectangles. We certainly have lots of other higher priorities right now, but let's see what they say in terms of the complexity that this would create and the scope of effort. It seems logical that it would create an intermediate level of partitioning that would enable a smaller step along the speed vs. efficiency tradeoff curve.

[fumoffu]

I have a question (I think it has been touched before but that was a long time ago).
Why merange is so high in all presets? Does it work the same as x264 merange?
because as you can find on some forums and also trough testing:
"...a large merange is basically useless. merange is the distance to search from the best predictor, not the maximum motion vector range. The best predictor is generally close enough to the correct MV that a large search radius is a waste of time."
and so in x264 in almost all presets merange is only 16 and changing it doesn't really do much except increasing encoding time...
So what is the reason for setting it so high in x265?

[x265_Project]

Maybe --rect could become a 0-3 argument, each testing more levels and partition possibilities at each level? Or make it depend on the rd level? Similar to how Steve talked about minimizing the number of intra tests on the mailing list a few days ago.
Our dev leads reminded me that --amp controls whether x265 checks the additional n x 2N rectangular partition possibilities. However, even with --amp we only ever check at most one AMP prediction, based on the results of the N x 2N rectangular predictions.

So, there are no intermediate levels that don't already exist.

There are other dials we can turn to spread out the distribution of performance presets, but we have some additional coding tools that aren't on by default yet (psy-rd and psy-rdoq), and we need to figure out where they should come into play, and the impact on performance and visual quality. We don't want to change things too often, so it's better to do this all at once.

Tom

[upyzl]

I have a question (I think it has been touched before but that was a long time ago).
Why merange is so high in all presets? Does it work the same as x264 merange?
because as you can find on some forums and also trough testing:
"...a large merange is basically useless. merange is the distance to search from the best predictor, not the maximum motion vector range. The best predictor is generally close enough to the correct MV that a large search radius is a waste of time."
and so in x264 in almost all presets merange is only 16 and changing it doesn't really do much except increasing encoding time...
So what is the reason for setting it so high in x265?

I'm not expert on it, but AFAIK, H.264/AVC coding unit should be MacroBlock, which size is 16x16; and H.265/HEVC coding unit is CTU, which default is 64x64

and here is the doc from MCW x265 Team:
http://x265.readthedocs.org/en/default/cli.html#cmdoption--merange

[x265_Project]

I have a question (I think it has been touched before but that was a long time ago).
Why merange is so high in all presets? Does it work the same as x264 merange?
because as you can find on some forums and also trough testing:
"...a large merange is basically useless. merange is the distance to search from the best predictor, not the maximum motion vector range. The best predictor is generally close enough to the correct MV that a large search radius is a waste of time."
and so in x264 in almost all presets merange is only 16 and changing it doesn't really do much except increasing encoding time...
So what is the reason for setting it so high in x265?
When we created our performance presets we ran many tests to see the effect on performance and quality for each parameter. Reducing the merange at most presets didn't produce any meaningful improvement on performance. It does have a slightly negative impact on encoding efficiency.

It's easy to run your own tests to verify this. Just run multiple encodes of the same clip with --ssim on (to measure quality), varying --merange for each test run. Your feedback and test results are welcomed!

[Kurtnoise]

Yes, 2 pass encoding is enabled in the Dev build, but there are a few bugs that we are aware of and working on (dealing with compatibility with rate control options used in the first or second pass). Detailed feedback (ideally, with source clips available to us and steps to reproduce the results) is welcomed.

Using any presets lower than "Fast" crash on the 2nd pass, here (well...not a crash but a lot of warnings/errors :


x265 [warning]: specified frame type is not compatible with max B-frames
x265 [warning]: specified frame type is not compatible with max B-frames
x265 [error]: slice=P but 2pass stats say B
x265 [error]: slice=P but 2pass stats say B
x265 [warning]: specified frame type is not compatible with max B-frames



Are you able to reproduce this ?

Currently, I'm using version 1.2+349-8bab on Windows 8.1 64 bits - 8bpp.

I tried different sources with different length and different bitrates but the issue still appears...

--preset superfast --pass 1/2 --bitrate 2500 --stats "file.stats" --output "output.hevc" "input.avs"

[Sagittaire]

Perhaps that preset under "fast" have lower bframe number. try to have same frametype structure in first and second pass (min key frame, max key frame, bframe number, pyramidal bframe, closed or open GOP ...).

[foxyshadis]

Kurt, are you sure the stats file got updated when you ran the first pass again? You'd get those errors if you'd run a first pass with --preset medium or above and a second pass with --preset fast or lower.

[x265_Project]

Using any presets lower than "Fast" crash on the 2nd pass, here (well...not a crash but a lot of warnings/errors :




Are you able to reproduce this ?

Currently, I'm using version 1.2+349-8bab on Windows 8.1 64 bits - 8bpp.

I tried different sources with different length and different bitrates but the issue still appears...

--preset superfast --pass 1/2 --bitrate 2500 --stats "file.stats" --output "output.hevc" "input.avs"

The --bframes setting must match between the 1st and 2nd pass. So, if you want to run a faster first pass using a performance preset that uses a different --bframes value, just add --bframes to the command line for the 1st pass, and use the value associated with the setting you will use for your 2nd pass.
You can find the bframes setting for each performance preset here... http://x265.readthedocs.org/en/default/presets.html

We're also aware of an issue with 2 pass and presets faster, superfast or ultrafast. Currently you don't get any B frames in the 2nd pass, making the 2nd pass less efficient than the first. The team is working to fix this.

[LigH]

A patch has just been submitted to the mailing list.

[Selur]

may be that patch will also help with my issue that using qpfile caused similar output&crashes

[Kurtnoise]

We're also aware of an issue with 2 pass and presets faster, superfast or ultrafast. Currently you don't get any B frames in the 2nd pass, making the 2nd pass less efficient than the first. The team is working to fix this.
That patch fixed my issue...:thanks:

[x265_Project]

We've checked in Psy-RDOQ. At this point, you should consider this feature highly experimental. We are performing tests to determine the scaling factor that is needed. Ongoing work includes Psy-RDOQ performance optimization.

As always, your test results (with full command line, --log 3 or 4 csv file with --SSIM on and ideally, a link to the publicly available source clip) are welcomed.

Tom

[upyzl]

MPC-BE 1.4.3 5157+ (MediaInfo 0.7.69+ svn rev.6373) dev (nightly builds (https://sourceforge.net/projects/mpcbe/files/MPC-BE/Nightly%20Builds%20%28from%20svn%20trunk%29/)) has supported new x265 SEI:
General
Complete name : D:\enc\test_265.mp4
Format : MPEG-4
Format profile : Base Media / Version 2
Codec ID : mp42
File size : 13.5 MiB
Duration : 1mn 31s
Overall bit rate mode : Variable
Overall bit rate : 1 237 Kbps
Encoded date : UTC 2014-08-01 01:50:26
Tagged date : UTC 2014-08-01 01:50:26
Writing application : qaac 2.35, CoreAudioToolbox 7.9.8.5, AAC-HE Encoder, CVBR 80kbps, Quality 96
HDCD : 0
VALID_BITS : 16

Video
ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main@L4.0
Codec ID : hvc1
Codec ID/Info : High Efficiency Video Coding
Duration : 1mn 31s
Bit rate : 1 153 Kbps
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Bits/(Pixel*Frame) : 0.023
Stream size : 12.5 MiB (93%)
Writing library : x265 1.2+413-e85b0aaa64e4:[Windows][ICC 1400][64 bit]
Encoding settings : wpp / ctu=64 / tu-intra-depth=1 / tu-inter-depth=1 / me=1 / subme=2 / merange=57 / no-rect / no-amp / max-merge=2 / no-early-skip / no-fast-cbf / rdpenalty=0 / no-tskip / no-tskip-fast / strong-intra-smoothing / no-lossless / no-cu-lossless / no-constrained-intra / open-gop / interlace=0 / keyint=250 / min-keyint=23 / scenecut=40 / rc-lookahead=20 / bframes=4 / bframe-bias=0 / b-adapt=2 / ref=3 / weightp / no-weightb / aq-mode=2 / aq-strength=1.00 / cbqpoffs=0 / crqpoffs=0 / rd=3 / signhide / lft / sao / sao-lcu-bounds=0 / sao-lcu-opt=1 / b-pyramid / cutree / rc=crf / crf=24.0 / qcomp=0.60 / qpmin=0 / qpmax=51 / qpstep=4 / ipratio=1.40 / pbratio=1.30
Encoded date : UTC 2014-08-01 01:50:26
Tagged date : UTC 2014-08-01 01:50:26

Audio
ID : 2
Format : AAC
Format/Info : Advanced Audio Codec
Format profile : HE-AAC / LC
Codec ID : 40
Duration : 1mn 31s
Bit rate mode : Variable
Bit rate : 82.1 Kbps
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 KHz / 24.0 KHz
Compression mode : Lossy
Stream size : 914 KiB (7%)
Encoded date : UTC 2014-08-01 01:50:26
Tagged date : UTC 2014-08-01 01:50:26

[sneaker_ger]

x264 is trademarked by VideoLan, a non-profit organisation. x265 is(or is trying to be) trademarked by multicoreware, a profit seeking business. The difference is in ways subtle, such as multicoreware trying to use their trademark to prevent people from releasing x265 builds.
VideoLAN has registered x265 as well, at least for the internal market of the European Union.

[Procrastinating]

sneaker_ger, you may have accidentally posted to the wrong thread.

In any case, Do we have a clear idea of how much benefit RDOQ will bring to x265? That is, do we have a sure idea whether RDOQ will bring significant benefits over RD? Or will we just wait and see.

[foxyshadis]

sneaker_ger, you may have accidentally posted to the wrong thread.

In any case, Do we have a clear idea of how much benefit RDOQ will bring to x265? That is, do we have a sure idea whether RDOQ will bring significant benefits over RD? Or will we just wait and see.

RDOQ beats plain RD. psy-rdoq? Who knows! Test hard! It's bash things against the wall time to see what shakes out.

[LigH]

Yo, check this out:

I encoded a series of small tests with "Kristen and Sara" 720p (@ varun); already reduced strengths show quite obviously a "bleeding" of energy from areas with fine details (hair) into areas with no details (blue background), causing "wobbling background" artefacts. A later analysis should show if this is caused rather by Psy-RD or Psy-RDOQ, or only in combination of both...

KS_psy.7z (https://www.mediafire.com/download/q2db5j6x5c41i4j/KS_psy.7z) in HEVC (https://www.mediafire.com/folder/6lfp2jlygogwa/HEVC)/samples (https://www.mediafire.com/folder/ldwl20fppplbx/samples)

[Sagittaire]

rdoq seem produce major visual improvement for park joy sample. Test in progress.

[xooyoozoo]

Did a quick test on a moderately grainy clip with (arbitrarily chosen) 0.5-3.0 psyrd-psyrdoq, and I think things are looking much better! My main nitpick is that chroma noise is a bit blatant.

Done on x265@8edb2a5 with turbo 1st pass diff from mailing list applied. Used 2pass and preset slower.
Bitstreams and side-by-side composition (https://www.mediafire.com/folder/22jrkonb4d2wb/2014-08-04-tales-hevc).
Some snapshots: 1 (http://i.imgur.com/eqQ5JZH.png), 2 (http://i.imgur.com/PC6auZY.png), 3 (http://i.imgur.com/UG1t7St.png).

The source is first 800 frames of the 80 mbits prores download from here (https://vimeo.com/83184433) (might need to be logged in).

[sneaker_ger]

Did a quick test on a moderately grainy clip with (arbitrarily chosen) 0.5-3.0 psyrd-psyrdoq
I thought 2.0 was the limit?

Btw, are psyrd and psyrdoq mutually exclusive?

[foxyshadis]

I thought 2.0 was the limit?

Btw, are psyrd and psyrdoq mutually exclusive?

2.0 is the limit for psy-rd, but psy-rdoq is unbound while they tweak it. They're complimentary, psy-rdoq is akin to x264's psy-trellis.

[Atak_Snajpera]

Is there any reason why x265 stats file is written in such odd way without proper line breaks ?

x265 stats file
http://i.cubeupload.com/AphD7Q.png

x264 stats file
http://i.cubeupload.com/dAN8CO.png

[sneaker_ger]

x265 produces a newline (LF) after each frame for me just like x264. :confused:

[Atak_Snajpera]

x265 produces a newline (LF) after each frame for me just like x264. :confused:

show me :)

[sneaker_ger]

http://abload.de/img/x265_2pass_stats_newlu2inf.png
(Using this build (http://chromashift.org/x265_builds/x265-1.2.474-highbitdepth-icl14.0-64.7z))

[Atak_Snajpera]

I use latest from here http://builds.x265.eu/ 1.2+496

[benwaggoner]

Is there any reason why x265 stats file is written in such odd way without proper line breaks ?
I've not had any issues with line breaks.

I VASTLY prefer the x265 CSV style to the weird turgid x264 style. Anything that can read CSV (like Excel) can easily import the x265 .stats files, while a bunch of annoying parsing is required to turn the x264 .stats files into easily analyzed data. Also, all per-item prefixes make the x264 .stats files way bigger.

I hope the CSV style will get backported to x264, at least as an option.

[Atak_Snajpera]

I've not had any issues with line breaks.

I VASTLY prefer the x265 CSV style to the weird turgid x264 style. Anything that can read CSV (like Excel) can easily import the x265 .stats files, while a bunch of annoying parsing is required to turn the x264 .stats files into easily analyzed data. Also, all per-item prefixes make the x264 .stats files way bigger.

I hope the CSV style will get backported to x264, at least as an option.

what version of x265 do you use?

[Atak_Snajpera]

Ok. It turns out that builds on http://builds.x265.eu/ are broken. I used older build from chromashift and log now has correct line breaks.

BTW. Noobish question here. Is this normal that those numbers are not in order like in x264?

x265 stats
http://i.cubeupload.com/JS3eko.png

x264 stats
http://i.cubeupload.com/QiyomG.png

[x265_Project]

BTW. Noobish question here. Is this normal that those numbers are not in order like in x264?

Can you help us understand what you are doing with the stats file? Are you trying to parse this file for some reason? x265 has a comma-separated value (--csv filename.csv ) log file function that should provide all of the information you would normally need.

[Atak_Snajpera]

I read stat file in order to verify how many frames have been actually processed by encoder in first pass. Then I inject that value to second pass as --frames xxxxxx switch. Why am I doing this? FFmpegSource() for some unknown reason sometimes likes to discard last frame. Movie initially is detected by decoder as let's say 1000 frames but encoder processes in first pass only 999 frames. With x264 stat file I just have to read last line in order to extract number of processed frames. With x265 I've encountered two issues. First latest builds from http://builds.x265.eu/ do not have proper line breaks. Older version from chromashift.org works fine. Then I've noticed that last line in x265 stat file does not always contain what I want. From technical point of view this is not a big problem for me but still I'm curious why values in x265's stats file do not act like in older brother x264.

[x265_Project]

I read stat file in order to verify how many frames have been actually processed by encoder in first pass. Then I inject that value to second pass as --frames xxxxxx switch. Why am I doing this? FFmpegSource() for some unknown reason sometimes likes to discard last frame. Movie initially is detected by decoder as let's say 1000 frames but encoder processes in first pass only 999 frames. With x264 stat file I just have to read last line in order to extract number of processed frames. With x265 I've encountered two issues. First latest builds from http://builds.x265.eu/ do not have proper line breaks. Older version from chromashift.org works fine. Then I've noticed that last line in x265 stat file does not always contain what I want. From technical point of view this is not a big problem for me but still I'm curious why values in x265's stats file do not act like in older brother x264.
I'll have to check with our engineers for the answer.

x265's --csv function with --log 3 or 4 will produce a log file with the frame count that shouldn't be too difficult to parse (although the frame count you are looking for will be in the 4 lines before the last line in the file). And, of course, add 1 to the frame number which is at the beginning of the (last-4) line in the csv log file, as frames are numbered starting from 0.

[Atak_Snajpera]

It turns out that even latest version from http://chromashift.org/x265_builds/ does not have line breaks in stat file. Why have you removed that? If it ain't broke, don't fix it ;)

[a5180007]

@Atak_Snajpera : it comes from commit 02d805e (https://bitbucket.org/multicoreware/x265/commits/02d805ee3d387366db2222ce0f1cc379629a6790), "\n" has been omitted to obtain a CSV file.

Just replace ";" with ";\n" in file with Notepad++ to have the old presentation.

[x265_Project]

It turns out that even latest version from http://chromashift.org/x265_builds/ does not have line breaks in stat file. Why have you removed that? If it ain't broke, don't fix it ;)
Our developer (Aarthi) responded "Sorry, it was my mistake! I accidentally ommitted LF from the end of print statment when trying to refactor! It doesn't break the build as we only look for ';' to obtain the next frame's info from stats file - so I didn't notice it earlier. l'll send that fix now." She has already submitted a patch to the x265-devel mailing list.

I also asked "Do you know why x265 occasionally writes stats out of frame order?"

Aarthi explained "Yes, this happens at the very end of the encode sometimes, when a lot of frame threads are used. For the last N frames (N = # frame threads), we don't wait until the RateControlEnd() of previous frame is called before calling the same for current frame. The encoder order block on RateControlEnd() is not imposed as there are no more frames in the input queue and this won't affect the flow. So, the frame stats for frame N can be printed before frame N-1. This doesn't affect 2 pass rate control, since in the second pass we index the frame data in the array based on the POC number obtained from each line of the stats file only."

[LigH]

x265 1.2+510-2bdcfcc1bb33 (https://www.mediafire.com/download/2ir3t5s7i659c3b/x265_1.2+510-2bdcfcc1bb33.7z) adds the linebreak in stats files back.

[a5180007]

This doesn't affect 2 pass rate control, since in the second pass we index the frame data in the array based on the POC number obtained from each line of the stats file only."

Not sure I understand this. How can the POC be correct if the decoding order is not in order, especially when the 2nd pass takes line number and not decoding number ?

[greenfountain]

How can the POC be correct if the decoding order is not in order, especially when the 2nd pass takes line number and not decoding number ?

in : -> poc or display order. out : ->encode order. the actual encoding is done in order; only the printf to stat file is out of order for the last few frames whenever Frame parallelism is enabled.
That being said, in the second pass, we assign the sliceTypes for each frame based to the data read from the stats file for the respective poc and the encode order is re-constructed within each lookahead window similar to first pass based on the slicetype assigned.

[x265_Project]

Not sure I understand this. How can the POC be correct if the decoding order is not in order, especially when the 2nd pass takes line number and not decoding number ?

The 2nd pass doesn't just read the stats file line by line, assuming that stats are written in encode order. x265 finds the correct line for the frame it is encoding.

[LoRd_MuldeR]

Looks like "high bitdepth" build is currently broken:
4>x265-static.lib(asm-primitives.obj) : error LNK2019: unresolved external symbol "unsigned char (* x265::IntraFilterType)[35]" (?IntraFilterType@x265@@3PAY0CD@EA)
referenced in function "void __cdecl x265::intra_allangs<2>(unsigned short *,unsigned short *,unsigned short *,unsigned short *,unsigned short *,int)" (??$intra_allangs@$01@x265@@YAXPEAG0000H@Z)
build\vc12-x86_64\Release\x265.exe : fatal error LNK1120: 1 unresolved externals

The only place I can see "IntraFilterType" being defined is in "predict.h" where it is defined as static.

Therefore it's clear that using "extern" like this, in "asm-primitives.cpp", won't work:
#if HIGH_BIT_DEPTH
extern unsigned char IntraFilterType[][35];
[...]

(Though simply including "predict.h" in "asm-primitives.cpp" doesn't work either)

[filler56789]

rev 1.2+518, 8-bit depth, shows a compiler warning with GCC 4.8.1 under MSYS
(sadly I remembered to copy the warning message after I had closed the CLI window :o )

[a5180007]

Maybe this warning (obtained with MSVC 1800) :
warning C4701: potentially uninitialized local variable 'lowmode' used x265\source\encoder\slicetype.cpp line 1714
EDIT : also warning C4800: 'const unsigned char' : forcing value to bool 'true' or 'false' (performance warning) x265\source\encoder\predict.cpp line 78

[LigH]

Yes, the warning about "lowmode". Not the const though.

I just reported both (lowmode warning and linker error) to the mailinglist.

[Darius510]

Is there any way to throttle down the intensity of encoding? My CPU is overclocked and stable in normal use, even stable with synthetic stress tests...but x265 is so intense and creates so much heat that it'll crash the entire system with an hour or two. Even something as mild as an option to switch it to 90% encoding speed would probably make a huge difference.

[x265_Project]

Is there any way to throttle down the intensity of encoding? My CPU is overclocked and stable in normal use, even stable with synthetic stress tests...but x265 is so intense and creates so much heat that it'll crash the entire system with an hour or two. Even something as mild as an option to switch it to 90% encoding speed would probably make a huge difference.

We don't have a command that monitors and limits the actual CPU %, but there are a couple of ways that you can throttle x265 back a bit on a multi-core PC.

--threads <n> - controls the number of parallel threads that x265 will allow. Normally this defaults to the # of threads your processor can support (equal to the # of cores, or the # of cores x 2 for a hyper-threaded processor). If you dial this back x265 will leave some threads for the rest of your system, and if you aren't running anything else this should cool things off a bit.

--no-wpp - this would turn off wavefront parallel processing. It would likely dial back performance, but it's not as definitive as --threads.

-- frame-threads <n> - controls the number of frames that will be processed in parallel. Dialing this back would reduce CPU utilization, but it's better to just adjust --threads.

If you're technically inclined you may want to look at dialing back the clock frequency of your CPU, and/or improving your CPU cooling. If you haven't done so, you may want to open your case and carefully vacuum any dust off your CPU heat sink and other internals.

[foxyshadis]

All the fast-intra related compiling problems are fixed now. Thanks, guys!

[Darius510]

We don't have a command that monitors and limits the actual CPU %, but there are a couple of ways that you can throttle x265 back a bit on a multi-core PC.



--threads - controls the number of parallel threads that x265 will allow. Normally this defaults to the # of threads your processor can support (equal to the # of cores, or the # of cores x 2 for a hyper-threaded processor). If you dial this back x265 will leave some threads for the rest of your system, and if you aren't running anything else this should cool things off a bit.



--no-wpp - this would turn off wavefront parallel processing. It would likely dial back performance, but it's not as definitive as --threads.



-- frame-threads - controls the number of frames that will be processed in parallel. Dialing this back would reduce CPU utilization, but it's better to just adjust --threads.



If you're technically inclined you may want to look at dialing back the clock frequency of your CPU, and/or improving your CPU cooling. If you haven't done so, you may want to open your case and carefully vacuum any dust off your CPU heat sink and other internals.


Thanks for the suggestions. I tried limiting threads, but since my i7 is hyperthreaded, dropping to 7 threads results in 3 loaded cores and one slightly less loaded core. I'd need to go all the way down to three threads to essentially get it to lay off an entire core at any given time, but then it's way, way too slow.

Cooling isn't an issue either, I've got a CPU cooler that's literally the size of my 7 month old baby's head and no less than 12 fans in the case.

x265 raises my CPU temp about 10C over x264, I'm assuming it extensively uses AVX instructions?

Perhaps this shouldn't be the job of any application/algorithm, but x265 is so hard on a CPU that some built in method to encode at less than full load would be very useful. I worry about all those poorly cooled PCs out there! :p

[x265_Project]

Thanks for the suggestions. I tried limiting threads, but since my i7 is hyperthreaded, dropping to 7 threads results in 3 loaded cores and one slightly less loaded core. I'd need to go all the way down to three threads to essentially get it to lay off an entire core at any given time, but then it's way, way too slow.

Cooling isn't an issue either, I've got a CPU cooler that's literally the size of my 7 month old baby's head and no less than 12 fans in the case.

x265 raises my CPU temp about 10C over x264, I'm assuming it extensively uses AVX instructions?

Perhaps this shouldn't be the job of any application/algorithm, but x265 is so hard on a CPU that some built in method to encode at less than full load would be very useful. I worry about all those poorly cooled PCs out there! :p
I know it's like Prime95 on steroids, but we run it around the clock on many machines without any issue at all. Your CPU has thermal management that is supposed to handle 100% utilization of all cores, adjusting the clock frequency as needed to prevent problems. I'm thinking that either you've got a defective CPU or a thermal issue.

If you'll forgive me for going on this tangent (I don't want to insult your intelligence)... for the benefit of others... even if you have a great heat sink, if the thermal paste wasn't applied correctly you could have air pockets, and that could lead to crashes. If you're a PC builder, I find what works best for consistently low CPU temps is to apply thermal paste in a star pattern (a larger drop of thermal paste in the middle, with lines radiating outward to the corners and sides)... kind of like this...
http://docs.oracle.com/cd/E19121-01/sf.x4200/819-1157-23/figures/Maint-26.jpgIn this way, as you place the cooler on the CPU, the air has a clear path to escape as the paste spreads, and it still gets all the way to the corners. You'll get some excess coming out the sides, but that's easy to wipe up.
See http://www.overclockers.com/applying-thermal-grease/ or https://www.youtube.com/watch?v=EyXLu1Ms-q4 for visual proof on why this pattern works better than pre-spreading the thermal paste. On an older PC I found that I could lower my idle temp by more than 10 degrees C once I figured this out.

Do you have a BIOS utility to monitor CPU temperatures? What kind of idle temp are you seeing? What do you see at full load?

I'm not sure how easy it would be to add a feature to monitor and throttle CPU utilization, but I can check into this.

[foxyshadis]

Is there any way to throttle down the intensity of encoding? My CPU is overclocked and stable in normal use, even stable with synthetic stress tests...but x265 is so intense and creates so much heat that it'll crash the entire system with an hour or two. Even something as mild as an option to switch it to 90% encoding speed would probably make a huge difference.

Your overclock's not as stable as you think, but summer hits me pretty hard, too. Besides the hardware problems Tom's explained well, I'd go into your BIOS and look for heat-throttling capability first; that's the best and lowest-level way to attack the problem before it can get bad. It'll throttle until your CPU cools down, then ease up until it heats up again. If you don't have that, a windows program to emulate it is TThrottle (http://efmer.com/b/eFMer_programs), but that one doesn't always work.

Here's another option: BES (http://mion.faireal.net/BES/), which can limit CPU usage, but only manually.

[Blue_MiSfit]

Yeah, remove the overclock :D

You're pushing your hardware too hard.

[Darius510]

I know it's like Prime95 on steroids, but we run it around the clock on many machines without any issue at all. Your CPU has thermal management that is supposed to handle 100% utilization of all cores, adjusting the clock frequency as needed to prevent problems. I'm thinking that either you've got a defective CPU or a thermal issue.



If you'll forgive me for going on this tangent (I don't want to insult your intelligence)... for the benefit of others... even if you have a great heat sink, if the thermal paste wasn't applied correctly you could have air pockets, and that could lead to crashes. If you're a PC builder, I find what works best for consistently low CPU temps is to apply thermal paste in a star pattern (a larger drop of thermal paste in the middle, with lines radiating outward to the corners and sides)... kind of like this...

http://docs.oracle.com/cd/E19121-01/sf.x4200/819-1157-23/figures/Maint-26.jpgIn this way, as you place the cooler on the CPU, the air has a clear path to escape as the paste spreads, and it still gets all the way to the corners. You'll get some excess coming out the sides, but that's easy to wipe up.

See http://www.overclockers.com/applying-thermal-grease/ or https://www.youtube.com/watch?v=EyXLu1Ms-q4 for visual proof on why this pattern works better than pre-spreading the thermal paste. On an older PC I found that I could lower my idle temp by more than 10 degrees C once I figured this out.



Do you have a BIOS utility to monitor CPU temperatures? What kind of idle temp are you seeing? What do you see at full load?



I'm not sure how easy it would be to add a feature to monitor and throttle CPU utilization, but I can check into this.


I get idle temps around 25-30C. Load temps in a game like crysis 3 maybe 60C. A synthetic stress test, maybe 70-80C. These are very good temps for an OCed Haswell. But X265....90-95C. The only thing that can surpass it is an AVX based stress test like linpack, but nobody seriously uses those with AVX-capable chips because the workload is so unrealistic and people fear it'll burn their chips out. x265 is kind of in a class of its own here. Sure, the chip itself will throttle back at 95C, but I think you'd have a hard time finding people comfortable with running a CPU at 95C for extended periods.

[Atak_Snajpera]

x265 is suppose to use everything you've got in your cpu. Afterall we want faster encoding speed right? if your cpu is not able to survive linpack stress test then your overclocked cpu has nothing but empty MHzs.

[Darius510]

x265 is suppose to use everything you've got in your cpu. Afterall we want faster encoding speed right? if your cpu is not able to survive linpack stress test then your overclocked cpu has nothing but empty MHzs.


I'd say it's supposed to do what it's programmed to do, and we may not all want the same thing. But I'm not here to start a fight or change anyone's mind, just looking to solve a problem on my end.

Is there any way to disable AVX support? I have a feeling that's the root cause of the extreme temps.

Either way, I am really impressed with x265 - I can cut a blu ray rip to nearly half it's size or less and all that seems lost is a little bit of film grain. Realistically, how much better can it get from here?

Also, I did come across some paper where a technique was described that reused some of the motion information from an h264 file to drastically speed encoding to h265...is that on the roadmap for x265?

[LigH]

Respect... :D

I wonder if you can disable AVX support by masking it in this parameter:
--[no-]asm <bool|int|string> Override CPU detection. Default: auto
Unfortunately, you may have to dig a bit deeper to find a relevant CPU feature mask string.

[Atak_Snajpera]

Either way, I am really impressed with x265 - I can cut a blu ray rip to nearly half it's size or less and all that seems lost is a little bit of film grain. Realistically, how much better can it get from here?

You can achieve even better results with x264. At very high bitrates ~15-20Mbps (half of regular blu-ray movie) x264 currently retains more details than x265. You do not need all those fancy algos/tools/whatever x265 has for that! x265 is only useful in crazy low bitrates like ~1 Mbps for 1080p.

I'd say it's supposed to do what it's programmed to do, and we may not all want the same thing. But I'm not here to start a fight or change anyone's mind, just looking to solve a problem on my end.
The problem is in your heatsink and too much overclocked cpu. Despite my efforts I'm unable to go above 68 C even with two x265 running at the same time!

http://i.cubeupload.com/qH0JN4.png

[Darius510]

You can achieve even better results with x264. At very high bitrates ~15-20Mbps (half of regular blu-ray movie) x264 currently retains more details than x265. You do not need all those fancy algos/tools/whatever x265 has for that! x265 is only useful in crazy low bitrates like ~1 Mbps for 1080p.


The problem is in your heatsink and too much overclocked cpu. Despite my efforts I'm unable to go above 68 C even with two x265 running at the same time!

http://i.cubeupload.com/qH0JN4.png


The Haswell architecture on my 4790K is very different from the sandy bridge on yours. Haswell is much hotter under load, especially when overclocked and using AVX apps. Also a big deal was made in the enthusiast community about how they switched the thermal interface between the die and the heat spreader after sandy bridge, which limits the thermal performance. They attempted to address the issue with the latest chips but it's still a fundamental limitation of the architecture, and this is apparently an increasing problem as they shrink the process further and further every year. I own one of the best HSFs you can buy, a Noctua D14....trust me, if you saw this thing you wouldn't be questioning it's capability.

http://www.legitreviews.com/images/reviews/1212/noctua_nhd14_014.jpg

Right now I'm testing with 7 threads and it seems 5-10C cooler, so hopefully that solves the problem....I'll know by whether it's still running this time tomorrow. :p

[Atak_Snajpera]

I own one of the best HSFs you can buy, a Noctua D14....trust me, if you saw this thing you wouldn't be questioning it's capability.

LOL! I also have Noctua D14 on my xeon :) This thing is soooo big that I can't even close my case :)

[mastrboy]

It's not just AVX instructions that heats a Haswell a lot more than former CPU's, it's anything that hits hard on the FPU.

Though it looks like Broadwell's lid will be soldered on, which should improve temperatures.
Not sure how happy overclockers who delid will be about that :p

(Also a owner of the Noctua D14, thanks to Haswell)

[filler56789]

Is there any way to disable AVX support? I have a feeling that's the root cause of the extreme temps.

Tweak and recompile :devil: the source-code :D

[x265_Project]

The Haswell architecture on my 4790K is very different from the sandy bridge on yours. Haswell is much hotter under load, especially when overclocked and using AVX apps. Also a big deal was made in the enthusiast community about how they switched the thermal interface between the die and the heat spreader after sandy bridge, which limits the thermal performance. They attempted to address the issue with the latest chips but it's still a fundamental limitation of the architecture, and this is apparently an increasing problem as they shrink the process further and further every year. I own one of the best HSFs you can buy, a Noctua D14....trust me, if you saw this thing you wouldn't be questioning it's capability.

http://www.legitreviews.com/images/reviews/1212/noctua_nhd14_014.jpg

Right now I'm testing with 7 threads and it seems 5-10C cooler, so hopefully that solves the problem....I'll know by whether it's still running this time tomorrow. :p
Righteous cooler dude.

Your 4970k has a TDP of 88 watts. Overclocked, you are using more power and generating more heat. But obviously your massive cooler is not pulling the > 100 watts of heat out as fast as it is being generating. Unless you're trying for 5 GHz, the Noctua D14 should be able to dissipate 125 watts or more, and it should be able to do this at sane CPU temps (under 70° C). So it seems like you have a heat transfer problem. Look at the temps that other people are reporting with overclocked 4790k's and this cooler...
http://www.newegg.com/Product/Product.aspx?Item=N82E16835608018
I hate to keep coming back to this, but if you pre-spread your thermal compound, you could have trapped air bubbles, and that would explain what you're seeing. I had the same problem, and when I removed and reapplied thermal compound the right way, my temps dropped by more than 10 degrees C at idle, and 20 degrees C at load. I would definitely not be comfortable running my CPU at anything above 70 degrees C sustained. If your thermal compound was applied properly you are overclocking past what your CPU can handle. You'll get a better overall result by bringing your clock speed back down to something reasonable versus limiting the # of x265 threads.

[Darius510]

Righteous cooler dude.



Your 4970k has a TDP of 88 watts. Overclocked, you are using more power and generating more heat. But obviously your massive cooler is not pulling the > 100 watts of heat out as fast as it is being generating. Unless you're trying for 5 GHz, the Noctua D14 should be able to dissipate 125 watts or more, and it should be able to do this at sane CPU temps (under 70° C). So it seems like you have a heat transfer problem. Look at the temps that other people are reporting with overclocked 4790k's and this cooler...

http://www.newegg.com/Product/Product.aspx?Item=N82E16835608018

I hate to keep coming back to this, but if you pre-spread your thermal compound, you could have trapped air bubbles, and that would explain what you're seeing. I had the same problem, and when I removed and reapplied thermal compound the right way, my temps dropped by more than 10 degrees C at idle, and 20 degrees C at load. I would definitely not be comfortable running my CPU at anything above 70 degrees C sustained. If your thermal compound was applied properly you are overclocking past what your CPU can handle. You'll get a better overall result by bringing your clock speed back down to something reasonable versus limiting the # of x265 threads.


I'll double check the mounting and thermal paste later today, I don't think it's the issue though. I should also mention that outside temps are 80-90, I leave the PC in an enclosed room and I'm running 4.6ghz/1.35V. So there's a lot of things contributing to the high temps at the moment, but I'm still testing the limits so to speak - if I find it can survive an hours long encode under the worst conditions, I'll feel confident that it'll be stable under more reasonable ones. I could prob drop the temps 10C by cracking a window. With the AC on temps are much more reasonable. :p

I just mean to point out that all other things being equal, x265 is far and away the most stressful real world application I've encountered. Outside of x265 hardly anything will break 70C for more than a moment. Unlike a lot of people here, I'm only going to be encoding on occasion, so I'd rather find a way for x265 to fit in with my current configuration than design around an infrequent use case.

[benwaggoner]

Your overclock's not as stable as you think, but summer hits me pretty hard, too. Besides the hardware problems Tom's explained well, I'd go into your BIOS and look for heat-throttling capability first; that's the best and lowest-level way to attack the problem before it can get bad. It'll throttle until your CPU cools down, then ease up until it heats up again.
For my 12-core Sandy Bridge workstation, I would get hard crashes after some hours of full-bore encoding until I set the BIOS fan speed to High. That was louder, but way more stable.

[benwaggoner]

You can achieve even better results with x264. At very high bitrates ~15-20Mbps (half of regular blu-ray movie) x264 currently retains more details than x265. You do not need all those fancy algos/tools/whatever x265 has for that! x265 is only useful in crazy low bitrates like ~1 Mbps for 1080p.
That totally doesn't match my results. I start seeing advantages in x265 over x264 below about 10 Mbps CBR for challenging 1080p content, and definitely by 5 Mbps.

Without --tune film x265 needs more command line parameters than x264 to get best results, though.

[benwaggoner]

--no-wpp - this would turn off wavefront parallel processing. It would likely dial back performance, but it's not as definitive as --threads.
Note that turning off WPP really reduced the threadability of decoding, which likely almost certainly result in slower decoding in software, particularly at large frame sizes. I would shy away from that for thermal management as it triggers a big change in the output bitstream.

[Darius510]

For my 12-core Sandy Bridge workstation, I would get hard crashes after some hours of full-bore encoding until I set the BIOS fan speed to High. That was louder, but way more stable.


Was that non-overclocked with the stock cooling?

[Blue_MiSfit]

Guys, we all love our hardware (and I espeically <3 my SANs) but let's try to keep the thread on track :)

[Atak_Snajpera]

That totally doesn't match my results. I start seeing advantages in x265 over x264 below about 10 Mbps CBR for challenging 1080p content, and definitely by 5 Mbps.

Without --tune film x265 needs more command line parameters than x264 to get best results, though.

I see obvious differences between 1 - 2 mbps for 1080p. With higher bitrates 4 mbps and more difference is too small to notice. I don't use cbr I use 2-pass mode for my tests.

[x265_Project]

Guys, we all love our hardware (and I espeically <3 my SANs) but let's try to keep the thread on track :)
Blue_MiSfit - the open question here is whether x265 can run fine on any hardware without some sort of CPU utilization monitoring and throttling. I believe the answer is yes, it can... but we want to understand the issue. Debugging the hardware config helps us clear up the question.

[Darius510]

Blue_MiSfit - the open question here is whether x265 can run fine on any hardware without some sort of CPU utilization monitoring and throttling. I believe the answer is yes, it can... but we want to understand the issue. Debugging the hardware config helps us clear up the question.


Right, that's why I asked if he was running everything stock...because I suspect x265 has the potential to cause issues on everyday machines. In any case I think it would only be a small percentage that's affected, but there is precedent - I've used crypto mining applications that actively monitor temperature and control fan speed to ensure it doesn't get out of hand. In a lot of ways they're very similar, since they also punish a GPU by running at maximum capacity for extended periods of time.

Granted, the actual monitoring is probably a feature best left to an application and not the codec, but some sort of wait or throttle function in the encoder will probably be needed to facilitate that.

[fumoffu]

Haswell and Ivy Bridge CPUs often have problems with high temps after OC.
If you're not scared (and have cash for new CPU, just in case :p) you can try this: https://www.youtube.com/watch?v=XXs0I5kuoX4

[foxyshadis]

Interesting that AVX2 (or maybe SSE4 in general?) causes such extraordinary power use. I was gearing up to start encoding actual movies, so I guess I'll have to monitor my laptop's heat. It's definitely useful information for Haswell owners, even non-overclockers.

[Dark Eiri]

Blue_MiSfit - the open question here is whether x265 can run fine on any hardware without some sort of CPU utilization monitoring and throttling. I believe the answer is yes, it can... but we want to understand the issue. Debugging the hardware config helps us clear up the question.

Absolutely every software is capable of running fine on absolutely every CPU, if it's a proper mantained machine. The hardware itself should work at it's maximum potential just fine. It's designed for doing exactly that.

If it's overclocked beyond it's limits or badly cooled, it's absolutely not the software's fault. It's either the user's fault for not doing it right or a faulty piece of hardware. Either way, it should not be a concern of the software. The only thing that would make it NOT run fine is some freezing bug in the code itself.

The CPUs are made to be stressed. If someone's CPU cannot handle having it's full potential used, it's their problem, not x265 in the slightest.

[NikosD]

Let's not exaggerate about x265' s ability to produce high temps.

Yes, for such a common (?) task of video encoding in H.265 format the heat produced is high.

My Core i7-4790 with stock cooler in high ambient temp, went fast at around 100 degrees (Celsius) and throttled the turbo frequency.

So from 3.8GHz went 3.7 and then 3.6, then again 3.7 etc.

If I run even more demanding CPU stress apps like Prime95 v28. 5 first option (Small FFT's) or Linx latest version in very high settings, then the CPU starts at 3.6 (never reaches turbo freq) and throttles 3.5, 3.4, 3.3 and then I just close the app because I feel pity for the CPU :)

Prime95 uses FMA3 and for Haswells produces maxTDP for me, even more than max TDP from Intel's spec.

It's a 84W TDP CPU, consuming ~100W during Prime95 test.

There are definitely problems with Ivy/Haswell CPUs with the internal IHS and the heat spreader, which all these apps (including x265 project) just bring them to surface.

[easyfab]

@x265_Project

What is your position about the command line synthax compared to x264 because I thought it was similar ? Should it be ? especially shortcut ?

Because during my tests "x264 2-pass vs x265 2-pass", I copy/paste my x264 command line. Problem : for x264 -p is the shortcut for --pass and for x265 it's the shortcut for --preset .
And yes, It took me some time to find out why x265 sucks so much in 2-pass ;)

[qyot27]

I know it was discussed a bit earlier, but what was/is the conclusion about whether certain features (like --ctu) need to be configured differently for different resolutions? Are higher CTU sizes always a higher precision option, or is there a point of diminishing returns for the larger sizes on smaller resolutions like 480p, or was that simply a speed vs. quality decision?

And just out of curiosity on the subject of RExt, which pieces/features need to be adjusted against the updated spec (which I assume has been released already, because it said it was supposed to be July and at least FFmpeg added support for decoding of non-4:2:0 content around the same time) so that the warning about non-compliancy is no longer necessary?

[LoRd_MuldeR]

Looks like "high bitdepth" build is currently broken:

The only place I can see "IntraFilterType" being defined is in "predict.h" where it is defined as static.

Therefore it's clear that using "extern" like this, in "asm-primitives.cpp", won't work:
#if HIGH_BIT_DEPTH
extern unsigned char IntraFilterType[][35];
[...]

(Though simply including "predict.h" in "asm-primitives.cpp" doesn't work either)

Looks like this has been addressed:
* https://bitbucket.org/multicoreware/x265/commits/3d3bc732b9e738909f9e5c79caf50c9098c9c25e
* https://bitbucket.org/multicoreware/x265/commits/7da2b731de3009f45b557001e660a7cde62c6cf1

[x265_Project]

@x265_Project

What is your position about the command line synthax compared to x264 because I thought it was similar ? Should it be ? especially shortcut ?

Because during my tests "x264 2-pass vs x265 2-pass", I copy/paste my x264 command line. Problem : for x264 -p is the shortcut for --pass and for x265 it's the shortcut for --preset .
And yes, It took me some time to find out why x265 sucks so much in 2-pass ;)
Our position is that x265 syntax should mirror x264 syntax wherever possible. Thanks for the tip. I'll ask the dev team to review this.

[x265_Project]

I know it was discussed a bit earlier, but what was/is the conclusion about whether certain features (like --ctu) need to be configured differently for different resolutions? Are higher CTU sizes always a higher precision option, or is there a point of diminishing returns for the larger sizes on smaller resolutions like 480p, or was that simply a speed vs. quality decision?
64x64 CTUs allow for higher encoding efficiency, but this also increases the number of possible block sizes and shapes that will be evaluated during motion estimation. Your results will vary depending on your content, but it's easy to run a couple of comparison tests to see the cost/benefit of --ctu 64 vs. --ctu 32.
And just out of curiosity on the subject of RExt, which pieces/features need to be adjusted against the updated spec (which I assume has been released already, because it said it was supposed to be July and at least FFmpeg added support for decoding of non-4:2:0 content around the same time) so that the warning about non-compliancy is no longer necessary?
It's not always easy to follow / understand how these standards bodies work. My understanding is that the range extension draft was consented on July 11th by the study group, but not yet approved and released by the ITU or MPEG. So, effectively they are approved, but they are not yet published as an updated version of the HEVC/H.265 spec. When MPEG's HEVC standards are fully approved they show up here... http://mpeg.chiariglione.org/standards/mpeg-h/high-efficiency-video-coding ... and the matching ITU H.265 standards show up here... http://www.itu.int/ITU-T/recommendations/rec.aspx?rec=11885. The new HM 16 reference encoder was just tagged, and it merges HM 15.0 with RExt 8.1, and so there is no turning back now. We've been keeping up with the RExt standards and supporting them for many months. If you are running tests, please let us know if you see any issues (for example, x265 encodes that don't decode perfectly with the latest HM decoder).

[xkinn123]

I felt my usual settings got slower...
what happened? Did you change your algorithm, x265_Project?

[LoRd_MuldeR]

I felt my usual settings got slower...
what happened? Did you change your algorithm, x265_Project?

This project is constantly evolving, so you cannot expect that your "usual settings" will always produce the same output or always run at the same speed.

It's probably the best to stick with the Preset system, since the Presets are updated/adjusted as needed during the development...

[xkinn123]

This project is constantly evolving, so you cannot expect that your "usual settings" will always produce the same output or always run at the same speed.

It's probably the best to stick with the Preset system, since the Presets are updated/adjusted as needed during the development...
Thank you.

Do you have any documentation explain about Psy-RDO and how it works?
I'm curious.

[LigH]

It has been documented rather briefly a lot of times; unfortunately, the topic seems to be complex enough to be explainable only to people who studied digital signal processing... You should have understood at least what "quantization" means, and how transformations to a frequency spectrum work. Then you will possibly learn that the quantization is altered based on the relation between lower and higher frequency parts of the spectrum, and the total amplitude in each "macroblock" or Coding Unit... I guess.

Briefly said: If there is enough contrast, then it doesn't need to be very exact, to spare a bit more for areas with little contrast, where a lack of precision would become more obvious.

[x265_Project]

I felt my usual settings got slower...
what happened? Did you change your algorithm, x265_Project?
We improve our algorithms all the time, but for most people with most settings performance should be getting faster. It would help if you could share your command-line syntax and your results (ideally, the summary data that is logged in a CSV file).

[x265_Project]

Heads up!! We're going to adjust Psy-RD and Psy-RDOQ strength scaling to provide a more typical range of values. Although both of these algorithms are off by default, if you are using them, you will need to adjust your strength values going forward.

Steve has pushed some (what we hope to be) final tunings of the two new psycho-visual optimization features. The features are still disabled by default, but the recommended values are now 1.0 for both.

http://x265.readthedocs.org/en/stable/cli.html#psycho-visual-options

Please try them out.

The stable branch has been merged with default in preparation of a 1.3 tag, which should happen early this week.

[raine]

Are we going to get detailed documentation for presets? In the old PDF version, I remember it was nicely tabulated.

@Darius510 I can suggest lower TDP processors (<=45W) when you buy a CPU next time. My Haswell never caused any problems at full loads even with the default Intel fan and questionable out-of-the-box thermal paste. Also saves energy. And here's a conjecture: using a 45W-TDP 2.7 GHz CPU could be faster than using a 88W-TDP 4 GHz with limited threads+AVX/AVX2 disabled (and it's is definitely much less noisy and energy-saving).

[NikosD]

The problem is that I bought Core i7-4790 with a TDP of 84W and the actual power is 100W during stress tests and close to 84W during x265 encoding.

We can't trust Intel based on TDP to predict thermal behavior.

[x265_Project]

Are we going to get detailed documentation for presets? In the old PDF version, I remember it was nicely tabulated.
Presets are documented here...
http://x265.readthedocs.org/en/default/presets.html
However, it is easier to read the presets table here...
https://bitbucket.org/multicoreware/x265/src/default/doc/reST/presets.rst

[a5180007]

@x265_Project, before 1.3 tagging, it would be better to change the --help (1.2+555-866f213 below) :

--psy-rd <0..2.0> Strength of psycho-visual rate distortion optimization, 0 to disable. Default 0.000000
--psy-rdoq <0..2.0> Strength of psycho-visual optimization in quantization, 0 to disable. Default 0.000000

[LoRd_MuldeR]

@x265_Project, before 1.3 tagging, it would be better to change the --help (1.2+555-866f213 below) :

--psy-rd <0..2.0> Strength of psycho-visual rate distortion optimization, 0 to disable. Default 0.000000
--psy-rdoq <0..2.0> Strength of psycho-visual optimization in quantization, 0 to disable. Default 0.000000

What exactly would you change?

To my understanding, the range for these options will remain 0.0 to 2.0. They only have been tuned so that a value of 1.0 should give visually pleasing results now. And they're still disabled by default.

[a5180007]

To my understanding, the range for these options will remain 0.0 to 2.0.

As stated above (post #1196), rdoq range has been changed to 0.0..10.0 so that 1.0 is the recommended value.


EDIT : also, psy-rd/psy-rdoq are not written to the SEI:

x265 --rd 4 --psy-rd 1.0 --psy-rdoq 1.0 park_joy_1080p50.y4m -o park_joy.hevc

x265 (build 31) - 1.2+555-866f21378d94:[Windows][MSVC 1800][32 bit] 8bpp - H.265/HEVC codec - Copyright 2013-2014 (c) Multicoreware
Inc - http://x265.org - options: 1920x1080 fps=50/1 bitdepth=8 wpp ctu=64 tu-intra-depth=1 tu-inter-depth=1 me=1 subme=2 merange=57
no-rect no-amp max-merge=2 no-early-skip no-fast-cbf rdpenalty=0 no-tskip no-tskip-fast strong-intra-smoothing no-lossless
no-cu-lossless no-constrained-intra no-fast-intra open-gop interlace=0 keyint=250 min-keyint=25 scenecut=40 rc-lookahead=20 bframes=4
bframe-bias=0 b-adapt=2 ref=3 weightp no-weightb aq-mode=2 aq-strength=1.00 cbqpoffs=0 crqpoffs=0 rd=4 signhide lft sao
sao-lcu-bounds=0 sao-lcu-opt=1 b-pyramid cutree rc=crf crf=28.0 qcomp=0.60 qpmin=0 qpmax=51 qpstep=4 ipratio=1.40 pbratio=1.30


Otherwise, much less ugly artefacts in 32 and 64 CTUs!

[x265_Project]

As stated above (post #1196), rdoq range has been changed to 0.0..10.0 so that 1.0 is the recommended value.

EDIT : also, psy-rd/psy-rdoq are not written to the SEI:

Thanks for the feedback. We'll take care of this.

[LigH]

Because it is "stable" now, x265 1.2+557-87400d5c90aa (https://www.mediafire.com/download/8nkrfp1prg6x4l0/x265_1.2+557-87400d5c90aa.7z).

[Blue_MiSfit]

I'm using the build that LigH just posted above ^^ 1.2+557-87400d5c90aa - the 8 bit variety on x64.

I thought I'd do some PSNR and speed tests just for fun, and got some odd behavior. See how it's warning be about setting --tune psnr even though I already have it set?


G:\>x265.exe --input parkjoy.y4m --preset medium --tune psnr --psnr --bitrate 80
00 --vbv-maxrate 8000 --vbv-bufsize 8000 --output parkjoy_x265_8000_medium.h265

y4m [info]: 1920x1080 fps 50/1 i420p8 sar 1:1 frames 0 - 207 of 208
x265 [info]: HEVC encoder version 1.2+557-87400d5c90aa
x265 [info]: build info [Windows][GCC 4.8.2][64 bit] 8bpp
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
x265 [info]: WPP streams / pool / frames : 17 / 8 / 3
x265 [warning]: --psnr used with AQ on: results will be invalid!
x265 [warning]: --tune psnr should be used if attempting to benchmark psnr!
x265 [info]: Main profile, Level-4.1 (Main tier)
x265 [info]: CU size : 64
x265 [info]: Max RQT depth inter / intra : 1 / 1
x265 [info]: ME / range / subpel / merge : hex / 57 / 2 / 2
x265 [info]: Keyframe min / max / scenecut : 25 / 250 / 40
x265 [info]: Lookahead / bframes / badapt : 20 / 4 / 2
x265 [info]: b-pyramid / weightp / weightb / refs: 1 / 1 / 0 / 3
x265 [info]: Rate Control / AQ-Strength / CUTree : ABR-8000 kbps / 0.0 / 1
x265 [info]: VBV/HRD buffer / max-rate / init : 8000 / 8000 / 0.900
x265 [info]: tools: rd=3 lft sao-lcu signhide

x265 [info]: frame I: 1, Avg QP:36.74 kb/s: 32723.60 PSNR Mean: Y:32.379
U:35.246 V:37.691
x265 [info]: frame P: 52, Avg QP:36.80 kb/s: 26042.37 PSNR Mean: Y:28.665
U:31.432 V:35.047
x265 [info]: frame B: 155, Avg QP:41.61 kb/s: 2187.03 PSNR Mean: Y:27.569
U:31.301 V:35.014
x265 [info]: global : 208, Avg QP:40.39 kb/s: 8297.68 PSNR Mean: Y:27.866
U:31.353 V:35.035
x265 [info]: Weighted P-Frames: Y:1.9% UV:1.9%
x265 [info]: consecutive B-frames: 1.9% 0.0% 1.9% 96.2% 0.0%

encoded 208 frames in 26.58s (7.82 fps), 8297.68 kb/s, Global PSNR: 29.198

[x265_Project]

I'm using the build that LigH just posted above ^^ 1.2+557-87400d5c90aa - the 8 bit variety on x64.

I thought I'd do some PSNR and speed tests just for fun, and got some odd behavior. See how it's warning be about setting --tune psnr even though I already have it set?

Good point. I'll have the team take a look at this.

Should be fixed with this patch... https://bitbucket.org/multicoreware/x265/commits/dca792ce978649a729fa903dea34de996742d5e8

[Blue_MiSfit]

Hooray I contributed :D

[LigH]

Because many stable and much fixes, wow ;) - x265 1.2+575-80129b1b6260 (https://www.mediafire.com/download/2wmz006fy6c8g42/x265_1.2+575-80129b1b6260.7z)

[benwaggoner]

@x265_Project, before 1.3 tagging, it would be better to change the --help (1.2+555-866f213 below) :

--psy-rd <0..2.0> Strength of psycho-visual rate distortion optimization, 0 to disable. Default 0.000000
--psy-rdoq <0..2.0> Strength of psycho-visual optimization in quantization, 0 to disable. Default 0.000000
Does this mean that --psy-rd has been refactored so that 1.0 should be the "default" now, not ~0.3 as before?

[benwaggoner]

And a couple of other questions about settings and presets

--rdpenalty defaults to 0, although by the description I'd think 1 (RD-penalty) would be prefereable. Is there a downside or risk to using 1? And what the heck is 2 for?
--weightb is off by default everywhere. Does using it have any risks or downsides?

[x265_Project]

Does this mean that --psy-rd has been refactored so that 1.0 should be the "default" now, not ~0.3 as before?

Yes it does.

[lotusgg]

Can someone compile and upload 1.3 stable for me?
For some reason, I just can't get it to work on my encoding ded.

[H3]

Can someone compile and upload 1.3 stable for me?
For some reason, I just can't get it to work on my encoding ded.

I hope this helps you:

http://builds.x265.eu/

[filler56789]

I hope this helps you:

http://builds.x265.eu/

Hmmm, according to Windows Explorer, their latest build is version 1.2+580-9461fc801cd2.

Version 1.2.581 (8bpp, both 32-bits and 64-bits) @ http://forum.videohelp.com/threads/357754-%5BHEVC%5D-x265-EXE-mingw-builds?p=2341579#post2341579

[LigH]

I'm going to build it, but the stable merge (1.3+2-2e17cb106b17) seems to have a lot of warnings regarding signed/unsigned comparisons etc., will probably prefer the latest development revision for publishing.
__

x26+1.3+18-bad70432b1d3 (http://www.mediafire.com/download/byqszmfpmyptlej/x265_1.3_18-bad70432b1d3.7z)

[x265_Project]

We are pleased to announce that we have reached version 1.3.

The primary changes in this release are the completion and tuning of the psycho-visual optimizations and new support for multiple pass encoding.

--psy-rd and --psy-rdoq are now completed and scaled such that their recommended initial values are 1.0.

Multipass encodes are now possible with --pass N and --stats FNAME

As usual, full documentation is at: http://x265.readthedocs.org/en/1.3/

= API Changes =

* param.bEmitInfoSEI, --[no-]info
include an SEI identifying the encoder and encoding options.

* param.bHighTier --high-tier
specify tier (used in conjunction with --level-idc)

* param.bEnableFastIntra --[no-]fast-intra
Use a gradient descent to scan angular intra modes

* param.totalFrames
optional indicator of total frame count, may improve rate control

* param.scalingLists
specify custom quantization matrices, "default" or filename

* param.psyRdoq
Psycho-visual optimizations for quantization

* param.bEnableSlowFirstPass
The first pass of multi-pass encodes will run in *turbo* mode unless this option is enabled.

[a5180007]

Nice improvements with this version !
Although the 2-pass is not a "pure CRF" yet. And there is a fair difference in first frames and I-frames sizes and ssim :

File http://www.diktafon.atw.hu/112.MTS
x265 1.3+18 crf28 (48,756 KB) vs --bitrate 6764 --pass 2 (48,738 KB)
http://i.imgur.com/fCzziJW.png

http://i.imgur.com/48tFEYC.png

[benwaggoner]

Yes it does.
Anything you can share about --rdpenalty and --weightb?

[x265_Project]

Anything you can share about --rdpenalty and --weightb?

These algorithms are in the same class... the code is in place, but we haven't spent much time on these functions as we had bigger fish to fry (RDOQ and psy-rdoq, etc.). We'll be turning our attention to these functions, but until we have had a chance to really evaluate how they are working in conjunction with the other changes we recently implemented, we can't recommend using them.

[NikosD]

Is there somewhere documented which parts of the code (functions ?) are optimised for AVX2 and which is the speed-up of these specific optimisations ?

Are there any functions using floating point numbers ?

Thanks!

[x265_Project]

Is there somewhere documented which parts of the code (functions ?) are optimised for AVX2 and which is the speed-up of these specific optimisations ?
Thanks!
denoise_dct
pixel_avg
frame_init_lowres_core
mbtree_propagate_cost
cvt32to16_shl
cvt16to32_cnt
pixel_satd
pixel_var
pixel_sad
pixel_ssd

You can turn off AVX2 or any other specific assembly code optimization using --asm (http://x265.readthedocs.org/en/default/cli.html#cmdoption--asm) to test the performance difference.

[benwaggoner]

denoise_dct
pixel_avg
frame_init_lowres_core
mbtree_propagate_cost
cvt32to16_shl
cvt16to32_cnt
pixel_satd
pixel_var
pixel_sad
pixel_ssd

You can turn off AVX2 or any other specific assembly code optimization using --asm (http://x265.readthedocs.org/en/default/cli.html#cmdoption--asm) to test the performance difference.
Any data for how much AVX2 speeds up those functions, or x265 overall?

It is pretty annoying that we still don't have a multi-socket AVX2 processor available. Just single-socket consumer-focused Haswell.

[nevcairiel]

It is pretty annoying that we still don't have a multi-socket AVX2 processor available. Just single-socket consumer-focused Haswell.

Soon.

[x265_Project]

Any data for how much AVX2 speeds up those functions, or x265 overall?

It is pretty annoying that we still don't have a multi-socket AVX2 processor available. Just single-socket consumer-focused Haswell.
Ben,
I don't have this data handy. We've been accelerating x265 in every way possible for months, and AVX2 assembly code optimizations are just one of areas that we have improved performance. Since performance has been improving in so many other areas someone would have to turn off AVX2 and run tests with the latest code on an AVX2 compatible machine.

As nevcairiel noted... it won't be long until Xeon E5 v3 processors (http://www.cpu-world.com/news_2014/2014080502_Xeon_E5-2600_v3_CPUs_are_available_for_pre-order.html) are available.

[Atak_Snajpera]

any plans on adding working tune presets like film,grain,anime and so on?

[x265_Project]

any plans on adding working tune presets like film,grain,anime and so on?
Yes, for sure. This had to wait until the psycho-visual optimizations were ready, but now we can figure out what works best for each type of content, and add these to --tune presets. We have some ideas, but it takes a lot of experimentation and testing to really determine the optimal adjustments. As an open source project, we would love to crowd-source some of this effort. So, I'm calling to all our friends on Doom9 for suggestions. If you are an Anime enthusiast, for instance, can you tell us what settings you have tried, and what adjustments seem to work best for you? We can get separate threads going for each tuning, if you like, and of course, we will contribute our expertise and our results.

Tom

[Romario]

So, x265_project, is 2-pass work without problems now ? Or not ?

What is more neccesary to development, 2-pass to improve ?

[x265_Project]

So, x265_project, is 2-pass work without problems now ? Or not ?

What is more neccesary to development, 2-pass to improve ?
2 pass is working great for me and my colleagues, and we've used it to create thousands of encoded streams. Let us know if you have any issues.

[Romario]

2 pass is working great for me and my colleagues, and we've used it to create thousands of encoded streams. Let us know if you have any issues.

Thanks.

Can you tell me reccomended settings for 2-pass mode ? But without fast first pass.

Thanks in advance.

[x265_Project]

Thanks.

Can you tell me reccomended settings for 2-pass mode ? But without fast first pass.

Thanks in advance.
OK. Variables that you supply are shown in capital letters...

x265 --input SOURCEFILE --input-res RES --fps FPS --bitrate BITRATE -p PRESET --pass 1 --slow-firstpass --stats STATSFILE.LOG OUTPUT1.hevc

x265 --input SOURCEFILE --input-res RES --fps FPS --bitrate BITRATE -p PRESET --pass 2 --stats STATSFILE.LOG OUTPUT2.hevc


So, for example...
x265 --input test.yuv --input-res 1920x1080 --fps 30 --bitrate 5000 -p slow --pass 1 --slow-firstpass --stats test_stats.log test-firstpass.hevc

x265 --input test.yuv --input-res 1920x1080 --fps 30 --bitrate 5000 -p slow --pass 2 --stats test_stats.log test.hevc

[LigH]

Another merge after a few refactors and fixes (e.g. more VBV precision in fast presets): x265 1.3+36-77fe0cc583e8 (https://www.mediafire.com/download/ium7wlb3ec9y6oa/x265_1.3+36-77fe0cc583e8.7z)

[Romario]

OK. Variables that you supply are shown in capital letters...

x265 --input SOURCEFILE --input-res RES --fps FPS --bitrate BITRATE -p PRESET --pass 1 --slow-firstpass --stats STATSFILE.LOG OUTPUT1.hevc

x265 --input SOURCEFILE --input-res RES --fps FPS --bitrate BITRATE -p PRESET --pass 2 --stats STATSFILE.LOG OUTPUT2.hevc


So, for example...
x265 --input test.yuv --input-res 1920x1080 --fps 30 --bitrate 5000 -p slow --pass 1 --slow-firstpass --stats test_stats.log test-firstpass.hevc

x265 --input test.yuv --input-res 1920x1080 --fps 30 --bitrate 5000 -p slow --pass 2 --stats test_stats.log test.hevc


Ok, thanks.

For me is little complicated to use *.yuv source files...This is not good for regular user like me...

Can I use MPEG2 source files or uncompressed AVI files as source ? And to write MKV or MP4 output ? When not, can you tell me with what encoding program can I use this settings.

[LigH]

Use avs4x265, to load other sources via AviSynth.

[lotusgg]

I'm trying to encode anime with avs4x265 with 2pass, but its insta-crashing on me.
http://prntscr.com/4h3aq7
Edit:
CLI I'm using:
avs4x265.exe --bitrate 1000 --pass 2 --preset medium --weightb --bframes 16 --rc-lookahead 40 --merange 57 --no-open-gop --min-keyint 25 --ipratio 1.0 --pbratio 1.0 --rd 4 --psy-rd 0.70 --psy-rdoq 0.70 --ctu 64 --aq-strength 0.5 --output akame_08_mbs.hevc --stats test_stats.log avs_x265.avs

avs_x265 is just a generic avs I use to edit for inputing a .mkv file.

[x265_Project]

I'm trying to encode anime with avs4x265 with 2pass, but its insta-crashing on me.
http://prntscr.com/4h3aq7
Edit:
CLI I'm using:
avs4x265.exe --bitrate 1000 --pass 2 --preset medium --weightb --bframes 16 --rc-lookahead 40 --merange 57 --no-open-gop --min-keyint 25 --ipratio 1.0 --pbratio 1.0 --rd 4 --psy-rd 0.70 --psy-rdoq 0.70 --ctu 64 --aq-strength 0.5 --output akame_08_mbs.hevc --stats test_stats.log avs_x265.avs

avs_x265 is just a generic avs I use to edit for inputing a .mkv file.
You have to create your stats file with a 1st encoding pass. Use the same command line syntax with --pass 1 to generate the stats file, then run --pass 2.

[LigH]

The universal raw video stream provider for x265, x264 and x262 (sic!) by 06_taro is now called avs4x26x (http://forum.doom9.org/showthread.php?t=162656) from version 0.10.0 on.

Support for a 64-bit version of AviSynth(+) was added.

[aegisofrime]

Hi x265 project...

I having two different encoding jobs running on two different PCs (one 4770 with 16GB of RAM, the other a 4500U with 8GB RAM) with two different sources. (Both DVDs to QTGMC though)

The error for the two crashes are as follows:


Crash on 4770 machine:
av2y [info]: error: wrote only 516806 of 518400 bytes
Crash on 4500U Machine:
av2y [info]: error: wrote only 516501 of 518400 bytes


The 4500U machine was running 1.3+36-77fe0cc583e8, while the 4770 was running 1.2+575-80129b1b6260

I'm running the encode with Mulder's Simple x264/265 launcher if that matters. Any idea how I could help to resolve this? Thanks! Let me know if you need more information.

[lotusgg]

You have to create your stats file with a 1st encoding pass. Use the same command line syntax with --pass 1 to generate the stats file, then run --pass 2.

Can I do it with in the same .bat file?

[LigH]

Yes, certainly.

[lotusgg]

Well, it worked.
But I have a question...
Is rd and rdoq good for anime? I'm using it without even knowing if its beneficial or otherwise. :p
And what can I do to prevent banding?

[LigH]

I wish I had good lossless cartoon/anime material to test on; but from what I saw in the "varun" samples with a very plain but tinted background (e.g. "Kristen and Sara"), PsyRD and PsyRDOQ may not be useful for such material in any arbitrary combination of values. I fear it may provoke structures from small detail areas to be transferred to slightly noisy areas, adding "moving wall" artefacts to supposedly flat color ramps, especially with higher PsyRD values. I guess it is more useful in real life footage where everything has a bit structure.

But you may have to test on your own to be certain.

[lotusgg]

I wish I had good lossless cartoon/anime material to test on; but from what I saw in the "varun" samples with a very plain but tinted background (e.g. "Kristen and Sara"), PsyRD and PsyRDOQ may not be useful for such material in any arbitrary combination of values. I fear it may provoke structures from small detail areas to be transferred to slightly noisy areas, adding "moving wall" artefacts to supposedly flat color ramps, especially with higher PsyRD values. I guess it is more useful in real life footage where everything has a bit structure.

But you may have to test on your own to be certain.

If you want material, I can give you some high-detailed/grained samples of anime.

[x265_Project]

Hi x265 project...

I having two different encoding jobs running on two different PCs (one 4770 with 16GB of RAM, the other a 4500U with 8GB RAM) with two different sources. (Both DVDs to QTGMC though)

The error for the two crashes are as follows:


The 4500U machine was running 1.3+36-77fe0cc583e8, while the 4770 was running 1.2+575-80129b1b6260

I'm running the encode with Mulder's Simple x264/265 launcher if that matters. Any idea how I could help to resolve this? Thanks! Let me know if you need more information.
If you're using an x265 launcher or another front-end application or GUI, it's hard for us to know where the problem lies. To debug the problem, it would be best to convert your input file to YUV (using FFMPEG, for example... you can start with a limited number of frames), and then run x265 directly with the same command line, using the YUV decoded frames as input. If this works, chances are the problem is with the front-end application.

[x265_Project]

If you want material, I can give you some high-detailed/grained samples of anime.
I would also like to get access to some good sample anime content. SFW only please. Can you point me to some good examples?

Thanks,
Tom

[filler56789]

@Tom: it's odd that you have never read or heard of avs2yuv or avs2pipe :D

[lotusgg]

I would also like to get access to some good sample anime content. SFW only please. Can you post on a cloud drive and private message me the link?

Thanks,
Tom

Are you fine with torrents? They're pretty heavy, so I can't just throw then online.

[LigH]

No pirating here. See forum rules. Private copies stay private.

[foxyshadis]

@Tom: it's odd that you have never read or heard of avs2yuv or avs2pipe :D

avs2yuv runs in a separate process from x265, so it shouldn't be the culprit; all x265 sees is YUV frames. Maybe try also encoding the script to x264 slow or veryslow to ensure stability under intense thermal pressure. That trips up a lot of people who aren't watching their temps. However, it can also be the avisynth side failing instead.

That entry can also mean that x265 didn't like what you were feeding it, since avs2yuv will fwrite until the buffer fills up even if the encoder doesn't accept anything. aegisofrime, your log should also include the command-lines and any other log entries from both x265 and avs2yuv, can you post them?

[sneaker_ger]

And what can I do to prevent banding?
I haven't specifically tested it but encoding with 10 bit is probably able to prevent most of it. Simply use a high-bitdepth build of x265, they will use 10 bit encoding by default.

[H3]

Does psy-rd and psy-rdoq worth it to use ? Because if I'm using it I just get more artifacts than a more detailed looking picture...

[x265_Project]

Does psy-rd and psy-rdoq worth it to use ? Because if I'm using it I just get more artifacts than a more detailed looking picture...
--psy-rd can only be used with the medium, slow, slower, veryslow, placebo presets (RD level 3 or higher).

--psy-rdoq can only be used with the slow, slower, veryslow or placebo presets (RD level of 4 or higher)

If you adjust the strength correctly, it should provide a very positive improvement. Can you share your command-line?

I recommend starting with --psy-rd 0.6 --psy-rdoq 1.0

Use lower values if you are using very low bitrates with a lot of motion and detail. Try some tests with different values to see what works best for your content and your other settings.

Tom

[benwaggoner]

I haven't specifically tested it but encoding with 10 bit is probably able to prevent most of it. Simply use a high-bitdepth build of x265, they will use 10 bit encoding by default.
x265 has a pretty good built in dithering mode as well, so if you need to encode at 8-bit from a 10-bit source, that's also an option.

Also, HEVC in general introduces less banding than H.264 does, so as long as you have source that's not banded in 8-bit, you may be pleasantly surprised by the results.

[Motenai Yoda]

Also, HEVC in general introduces less banding than H.264 does, so as long as you have source that's not banded in 8-bit, you may be pleasantly surprised by the results.
Well actually in a sensible number of times H.264 or HEVC doesn't "introduce" banding, but remove/reduce the slight dithering/noise that hide it. On 10bit encoding this dither/noise will be more often reduced like a some sort of gradient, that will be re-dithered at 8bit by decoders or renders.

[sneaker_ger]

Also, HEVC in general introduces less banding than H.264 does, so as long as you have source that's not banded in 8-bit, you may be pleasantly surprised by the results.

I did a test with low bitrates which show that x265 suffers from 8 bit as badly as x264, at least for low bitrates.
http://forum.doom9.org/showthread.php?p=1691801#post1691801

Open questions:
1. Would this be the same at higher bitrates?
2. Does x265 use the HEVC tools against banding?
http://forum.doom9.org/showthread.php?p=1614299#post1614299

[EndlessD]

I would also like to get access to some good sample anime content. SFW only please. Can you point me to some good examples?

Thanks,
Tom

On a side note:
Not every Anime is mastered in the same size and every release is different in terms of quality. If we are talking Japanese Animes, the Japanese BDs usually have the highest quality with a video-bitrate of ~35 Mbit/s, Western releases are most of the time at 15~25 Mbit/s. For DVDs the Japanese release is also the highest quality, most of the time at 9800 Kbit/s and Western releases fluctuate at normal DVD bitrates.
For Western or Korean Anime, I have no idea.

In terms of mastering size and quality they can be split in the following categories:

film content taken to DVD/BD (sometimes remastered)
SD mastered in 480p or smaller on DVD (pre HD time)
SD remasters on DVD (higher quality than the first DVD release)
SD remastered to 720~1080p achieved with filtering on BD
SD remastered in 540p/720p rescaled to 1080p on BD
SD remasters rescaled for DVD release (includes remasters achieved with filtering and normal ones)
HD mastered in ~720p rescaled to 1080p on BD (most common these days)
HD mastered in >720p but <1080p rescaled to 1080p on BD
HD mastered in 1080p on BD (still very rare these days)
HD rescaled to SD for the DVD release (this includes all HD categories)

I could provide samples for every category except the "film content" and ">720p but <1080p" or can provide some titles for each category.

[Darius510]

So I'm experimenting converting some blu-rays to h265. Ideally I'd like to maintain the same perceptual quality, without going overboard wasting bits accurately capturing what's merely a compression artifact from the original source. Something like a 18-16 CRF does a pretty good job, but sometimes the encoded video is even larger than the source!

Would using 2-pass ABR be better in this case? For example, setting the x265 bitrate at 60% of the source's bitrate for h264, 40% for vc1, and 25% for mpeg 2? Are there any advantages to encoding in 10-bit, even though the source is 8-bit? Would it decrease efficiency by encoding something that doesnt exist, or increase efficiency by giving x265 a wider palette of colors to work with? It's my understanding h264 has built in deblocking, does this mean I should use handbrake's deblocking filter during encoding, or does x265 take care of that automatically? What about the psychovisual options?

[sneaker_ger]

Would using 2-pass ABR be better in this case?
No, CRF and 2pass have about the same quality at the same bitrate. 2pass is only useful when you want to achieve a specfic bitrate/filesize instead of chooding a quality without knowing filesize.

For example, setting the x265 bitrate at 60% of the source's bitrate for h264, 40% for vc1, and 25% for mpeg 2?
x265 does not know about the original source format and Blu-Ray has so much bitrate that even MPEG-2 looks transparent.

Choose a CRF that you are happy with. Also, compare to x264. At high bitrates it's often better than x265 while being much faster and more compatible.

Are there any advantages to encoding in 10-bit, even though the source is 8-bit?
Yes, the higher internal precision increases efficiency.
See an example I just made:
http://forum.doom9.org/showthread.php?p=1691801#post1691801

It's my understanding h264 has built in deblocking, does this mean I should use handbrake's deblocking filter during encoding, or does x265 take care of that automatically?
H.264 and H.265 use in-loop deblocking, it's not meant to fix source files with blocking problems, only to prevent additional blocking during the encoding.

What about the psychovisual options?
They are still experimental but some claim good results for it.
These are listed as "typical value[s]":
--psy-rd 1.0 --psy-rdoq 1.0

[Zainian]

I would also like to get access to some good sample anime content. SFW only please. Can you point me to some good examples?


How about Big Buck Bunny? It's licensed under Creative Commons and has a 4K release: http://bbb3d.renderfarming.net/download.html

Okay, technically it's not anime produced in Japan, but it is still animation no?

[sneaker_ger]

They are probably talking about drawn/cartoon animation. CGI is a different matter.

[Darius510]

No, CRF and 2pass have about the same quality at the same bitrate. 2pass is only useful when you want to achieve a specfic bitrate/filesize instead of chooding a quality without knowing filesize.

x265 does not know about the original source format and Blu-Ray has so much bitrate that even MPEG-2 looks transparent.

Choose a CRF that you are happy with. Also, compare to x264. At high bitrates it's often better than x265 while being much faster and more compatible.

Well, I'm mostly just trying to save as much space as possible. I'm just trying to leverage the efficiency gains in h265 in my rips...CRF doesn't seem like the right tool for the job, when the input quality is so variable. For instance, with one source (LOTR), CRF 17 will compress a 35GB h264 file down to 6GB. With another (planet earth), it will compress a 8GB vc1 file down to 6GB. And it'll expand a 1GB mpeg2 source from a DVD to 1.5GB. That doesn't make any sense.

Maybe there's some flaw in my thinking, but knowing the relative efficiencies of each codec, shouldn't I be able to give h265 "enough" bits to reach the same relative quality? With 2-pass helping to distribute those bits appropriately over the whole file? Obviously it's not going to be perfect since I'm transcoding rather than working from the uncompressed master.

Yes, the higher internal precision increases efficiency.
See an example I just made:
http://forum.doom9.org/showthread.php?p=1691801#post1691801

How does one enable 10-bit precision? Just choose the Main10 profile? Also, if this is such an easy win, why isnt it on by default?

H.264 and H.265 use in-loop deblocking, it's not meant to fix source files with blocking problems, only to prevent additional blocking during the encoding.

So the handbrake deblocking is unnecessary, correct?

They are still experimental but some claim good results for it.
These are listed as "typical value[s]":
--psy-rd 1.0 --psy-rdoq 1.0

I've noticed they don't work with an rd of less than 4, which only slow and above have...and they are SLOW. Is it fine to manually just set rd to 4 on medium/fast, or does it need the other parameters of the slower presets to work properly?

[sneaker_ger]

CRF doesn't seem like the right tool for the job, when the input quality is so variable. For instance, with one source (LOTR), CRF 17 will compress a 35GB h264 file down to 6GB. With another (planet earth), it will compress a 8GB vc1 file down to 6GB. And it'll expand a 1GB mpeg2 source from a DVD to 1.5GB. That doesn't make any sense.
x265 does not know how big your source files were or what codec they used. It uses uncompressed video data as input. If the movie is complex (e.g. lots of action, cuts, grain) it will use a lot of bitrate (compared to a different movie at the same CRF). That's the reason as to why the output can be bigger than your source files.

How does one enable 10-bit precision? Just choose the Main10 profile?
Just use a high-bitdepth build. No additional settings are required. Check the log ("internal precision: 10") or MediaInfo to confirm it was done right.

Also, if this is such an easy win, why isnt it on by default?
Compatibility, not every decoder might be able to decode 10 bit HEVC. (+ maybe speed)

So the handbrake deblocking is unnecessary, correct?
If your source has blocking the handbrake filter might be useful. It the source has no blocking you don't need it.

Well, I'm mostly just trying to save as much space as possible. I'm just trying to leverage the efficiency gains in h265 in my rips
[...]
I've noticed they don't work with an rd of less than 4, which only slow and above have...and they are SLOW.
I really suggest you compare x264 to x265 yourself at the same bitrate. x265 is still very young, just because it uses a new video standard does not necessarily mean it always achieves better quality than the older x264 does.

[Darius510]

x265 does not know how big your source files were or what codec they used. It uses uncompressed video data as input. If the movie is complex (e.g. lots of action, cuts, grain) it will use a lot of bitrate (compared to a different movie at the same CRF). That's the reason as to why the output can be bigger than your source files.

Right, but I do...I can just check the source for it's bitrate and codec. Presumably the source has it's bits relatively distributed in the same way - more action = more bitrate.

The problem is that when its treating the input as if it's uncompressed, it can't tell a compression artifact from "real" detail. But regardless, given a fixed file size, all these codecs are going to distribute bits relatively the same way. So areas that are poorly compressed in one codec generally would be poorly compressed in another.

I've tested x264 vs x265 quite a bit, and even at the relatively high bitrates I'm encoding, given the same bitrate, there's no question that x265 comes out ahead every time.

[LigH]

It doesn't matter much whether you check its (no apostroph) bitrate if the video was once compressed with a lossy video compression technique, because the reconstructed video will not be the same as the original video. It will contain differences: compression artefacts. Another attempt to encode this output with a lossy compression technique may have to spend more bitrate for trying to maintain these compression artefacts than it would need to encode the really original video.

Hence, always prefer lossless material as common video source to compare different lossy compression codecs. Or at least use sources compressed with magnitudes of finer quantization than the ones you want to test (if you are about to compare bitrates or quality levels similar to CRF values >20, a source compressed with CRF <10 will possibly have no recognizable artefacts, relatively).

[sneaker_ger]

Right, but I do...I can just check the source for it's bitrate and codec. Presumably the source has it's bits relatively distributed in the same way - more action = more bitrate.
That presumption doesn't always hold true. I can encode the same video with --bitrate 1000 or --bitrate 50000. It does not tell you anything about the video complexity at all.
More examples:
- TV stream often use the constant bitrate assigned to them on e.g. the satellite. Complexity does not matter.
- On a Blu-Ray or DVD you might always try to fill the disc up completely. There is no reason to leave free space even for simple sources.

[Darius510]

It doesn't matter much whether you check its (no apostroph) bitrate if the video was once compressed with a lossy video compression technique, because the reconstructed video will not be the same as the original video. It will contain differences: compression artefacts. Another attempt to encode this output with a lossy compression technique may have to spend more bitrate for trying to maintain these compression artefacts than it would need to encode the really original video.

Hence, always prefer lossless material as common video source to compare different lossy compression codecs. Or at least use sources compressed with magnitudes of finer quantization than the ones you want to test (if you are about to compare bitrates or quality levels similar to CRF values >20, a source compressed with CRF <10 will possibly have no recognizable artefacts, relatively).

Definitely, but I simply don't have the uncompressed masters of studio films. Basically, I'm trying to solve a simple problem - I want to back up my blu-rays, and I don't have the space to store all the pure rips. I want to achieve near blu-ray quality at a smaller size by leveraging h265 instead of the less advanced codecs. Compatibility isn't an issue for me.

So I'm trying to figure out what's the best way to go about that, without wasting bits on perfectly reconstructing compression artefacts (that are barely visible anyway in fast motion scenes). Using CRF gives me unpredictable file sizes that probably waste too much bitrate on those artefacts...but would ABR really be any better about that?

[Darius510]

- On a Blu-Ray or DVD you might always try to fill the disc up completely. There is no reason to leave free space even for simple sources.

That's what I'd think too, but there is a huge variability...I've got single layer rips that range from 16GB to 24GB, dual layer rips that range from 25GB to 40GB. I'd think they'd want to use all the available space too, but that doesn't seem to be the case, even accounting for special features.

[x265_Project]

Definitely, but I simply don't have the uncompressed masters of studio films. Basically, I'm trying to solve a simple problem - I want to back up my blu-rays, and I don't have the space to store all the pure rips. I want to achieve near blu-ray quality at a smaller size by leveraging h265 instead of the less advanced codecs. Compatibility isn't an issue for me.

So I'm trying to figure out what's the best way to go about that, without wasting bits on perfectly reconstructing compression artefacts (that are barely visible anyway in fast motion scenes). Using CRF gives me unpredictable file sizes that probably waste too much bitrate on those artefacts...but would ABR really be any better about that?
Use ABR with 2 pass encoding. This will give you the highest possible quality at the bit rate you want.

[vivan]

Use ABR with 2 pass encoding. This will give you the highest possible quality at the bit rate you want.But he doesn't know what bitrate he wants!

[x265_Project]

But he doesn't know what bitrate he wants!
Well, yes... some experimentation may be needed. Darius510 just needs to figure out what percentage he wants to shrink his videos by. This use-case is perfect for H.265. Darius510 should be able to reduce the size of his high quality H.264 videos by 2x without a significant loss of quality, but he may be OK using an even higher shrink factor, depending on his priorities (smaller files, or highest possible quality). Use MediaInfo to determine the current bit rate of a video, then divide by the shrink X factor to determine the x265 bitrate setting. I would start with 2X, but you might even want to reduce your files by 3X or 4X.

[LigH]

If you don't know the target bitrate, but instead want to ensure a limited loss of quality, use CRF.

[xooyoozoo]

libvpx has a constrained-quality mode. It is a 2-pass encode where you set the maximum quality, so that any higher is wasting bits, and the suggested average bitrate, which is less strict than most 2pass modes. The libvpx encoder aims for the suggested bitrate unless local quality exceeds the previously set maxvalue. Then, quality is clamped, and bitrate can be lowered. If enough of a video is up against the quality "wall", then the total bitrate can be dramatically lower than the user-input bitrate value. IIRC, this is what Youtube uses for its WebM streams.

An ideal x265-analouge would be 2-pass with suggested bitrate, plus user-input min-crf (to not waste bits on easy clips), plus max-local-bitrate (to not waste bits on temporary complex parts; Main L5.0's vbv is probably enough for most 1080p videos).

The individual pieces seem to already exist in x265's cli, but I'm not sure if they can be combined and work as described above.

[LigH]

A reliable VBV control should achieve similar results. Just a bit more indirectly.

[Darius510]

Well, yes... some experimentation may be needed. Darius510 just needs to figure out what percentage he wants to shrink his videos by. This use-case is perfect for H.265. Darius510 should be able to reduce the size of his high quality H.264 videos by 2x without a significant loss of quality, but he may be OK using an even higher shrink factor, depending on his priorities (smaller files, or highest possible quality). Use MediaInfo to determine the current bit rate of a video, then divide by the shrink X factor to determine the x265 bitrate setting. I would start with 2X, but you might even want to reduce your files by 3X or 4X.


I've been having good results with 2X so far, honestly I'd be lying if I said I could see a difference without zooming way in and comparing side by side. 3x/4x is still quite good, but I'd prefer to preserve as much detail as possible.

Should I be taking the source codec into account though? I can see it both ways...h264 is obviously going to look way better than mpeg2 at a given bitrate, but where it falls apart tends to be very noisy instead of blurry. That's probably going to be even more demanding to transcode, not less.

[foxyshadis]

I've been having good results with 2X so far, honestly I'd be lying if I said I could see a difference without zooming way in and comparing side by side. 3x/4x is still quite good, but I'd prefer to preserve as much detail as possible.

Should I be taking the source codec into account though? I can see it both ways...h264 is obviously going to look way better than mpeg2 at a given bitrate, but where it falls apart tends to be very noisy instead of blurry. That's probably going to be even more demanding to transcode, not less.

You need to manually spot-check your discs' action scenes to see whether they're good or all screwed up. x265 certainly can't do this for you. For MPEG-2 video, there are some good quant-checkers out there, so you can quickly see if the quant is too high throughout the movie (quant has more correlation to quality in MPEG-2 than in newer codecs), then spot-check only the ones with bad numbers.

If a Blu-Ray is so small that a crf 18 is larger than the source, consider keeping the source. If you'd rather leverage the codec, then get rid of the crappy encode artifacts with pre-filtering (an --nr 100 might also help) and/or reduce resolution. Avisynth and ffmpeg have lots of ways you can filter, from lightning fast to slower than molasses. Personally, there's very little point to re-encoding instead of merely archiving if you're not going to make the video look better in the meantime. (If you make it look good enough, then maybe a little extra bitrate isn't unwarranted?) Otherwise, just raise the crf, because garbage in->garbage out, don't waste bits on it.

Are you certain you're not encoding interlaced without deinterlacing first? That right there will double your crf bitrate while reducing quality.

[Darius510]

You need to manually spot-check your discs' action scenes to see whether they're good or all screwed up. x265 certainly can't do this for you. For MPEG-2 video, there are some good quant-checkers out there, so you can quickly see if the quant is too high throughout the movie (quant has more correlation to quality in MPEG-2 than in newer codecs), then spot-check only the ones with bad numbers.

If a Blu-Ray is so small that a crf 18 is larger than the source, consider keeping the source. If you'd rather leverage the codec, then get rid of the crappy encode artifacts with pre-filtering (an --nr 100 might also help) and/or reduce resolution. Avisynth and ffmpeg have lots of ways you can filter, from lightning fast to slower than molasses. Personally, there's very little point to re-encoding instead of merely archiving if you're not going to make the video look better in the meantime. (If you make it look good enough, then maybe a little extra bitrate isn't unwarranted?) Otherwise, just raise the crf, because garbage in->garbage out, don't waste bits on it.

Are you certain you're not encoding interlaced without deinterlacing first? That right there will double your crf bitrate while reducing quality.


Well, there were some exceptions to the rules. For most movies, CRF 17 gave me a modest reduction. But then I'd have something like "300", which is super grainy, and only 15GB encoded with VC1. That one came out larger. Same deal with full metal jacket, it prob also didn't help that it was a full 1080p. Then on the other hand the two-disc LOTR EE discs are encoded at stupid high bitrates the entire way through and compressed way down to like 20% of their size. I'm sure I could denoise the hell out of them, but then I feel like I'm ruining them.

I still got a whole stack of discs to go through, I've just been getting such variable results in terms of file size that I was thinking maybe I'm not doing something right.

I do have a few interlaced nature docs and they came out WAY bigger...how am I supposed to encode those correctly?

[huhn]

I do have a few interlaced nature docs and they came out WAY bigger...how am I supposed to encode those correctly?

depends on how they are interlaced.

telecine with 3:2 can be fixed with a detelecine filter.

PsF (Progressive Segmented Frame or telecine 2:2) this is kind of not interlaced at all and rare so can be encoded as progressive. I would use a top filed matcher just to be save.

and true interlaced needs a deinterlacer these filter can be terrible slow.

VFR in interlaced very complicated to get this 100% right. a normal deinterlacer is save and shouldn't mess up to hard this content is very rare any way older cartoon or anime are some times like this.

[Darius510]

depends on how they are interlaced.



telecine with 3:2 can be fixed with a detelecine filter.



PsF (Progressive Segmented Frame or telecine 2:2) this is kind of not interlaced at all and rare so can be encoded as progressive. I would use a top filed matcher just to be save.



and true interlaced needs a deinterlacer these filter can be terrible slow.



VFR in interlaced very complicated to get this 100% right. a normal deinterlacer is save and shouldn't mess up to hard this content is very rare any way older cartoon or anime are some times like this.


I'd prefer not to deinterlace it at all if possible. It's a weird encode, the title is "frozen planet"....most of it looks like 24fps film, and interspersed are scenes where it's clearly interlaced video.

[huhn]

I'd prefer not to deinterlace it at all if possible. It's a weird encode, the title is "frozen planet"....most of it looks like 24fps film, and interspersed are scenes where it's clearly interlaced video.

this is a problem of processing not x265. this will go totally of topic. feel free to make a new topic about this people on this forum will help you for sure.

I'd prefer not to deinterlace it at all if possible.

you are doing this at the moment. resulting huge files and theoretical picture problems like 3:2 judder or other things. not sure if you make x265 clear that the input is interlaced but you should do this.

[Darius510]

this is a problem of processing not x265. this will go totally of topic. feel free to make a new topic about this people on this forum will help you for sure.

you are doing this at the moment. resulting huge files and theoretical picture problems like 3:2 judder or other things. not sure if you make x265 clear that the input is interlaced but you should do this.

Is there something about h265 or x265 that can't handle interlacing in the same way as h264?

[huhn]

Is there something about h265 or x265 that can't handle interlacing in the same way as h264?

interlaced material like telecine produce picture like this:
http://abload.de/img/aikatsu63.ts_snapshot95kce.png
http://abload.de/img/aikatsu63.ts_snapshotigjfh.png

these frames are very hard to encode.

x265 works different. I think it take the field and not the frame.

so I guess x265 will be better as x264 or is already.

you can read about this here:
http://x265.readthedocs.org/en/latest/cli.html

in the end the interlaced video has to be deinterlaced at playback. but deinterlacing be for encoding results in better picture quality because you choice the deinterlacer or telecine filter that suites the source best and because progressive frames are easier to encode for both x264 and x265.

detelecine for telecine source does wonders. no 3:2 judder, a lot smaller by better quality and you get the original frames back just awesome.

[Darius510]

interlaced material like telecine produce picture like this:
http://abload.de/img/aikatsu63.ts_snapshot95kce.png
http://abload.de/img/aikatsu63.ts_snapshotigjfh.png

these frames are very hard to encode.

x265 works different. I think it take the field and not the frame.

so I guess x265 will be better as x264 or is already.

you can read about this here:
http://x265.readthedocs.org/en/latest/cli.html

in the end the interlaced video has to be deinterlaced at playback. but deinterlacing be for encoding results in better picture quality because you choice the deinterlacer or telecine filter that suites the source best and because progressive frames are easier to encode for both x264 and x265.

detelecine for telecine source does wonders. no 3:2 judder, a lot smaller by better quality and you get the original frames back just awesome.

I guess I'm not explaining it right...it's not 24-30 progressive fps that are embedded in an interlaced stream. It's more like 1080i video on news, sports, soap operas, etc...where each field is different and it appears as smooth as 60fps. If I deinterlace before encoding, it loses that silky smoothness. The file properties reads 29.97fps, but on playback mpc-hc reads 60fps.

I figured I'd just be able to drop it into handbrake and it would encode into h265 as-is into an interlaced stream, but it doesnt seem to be the case.

[vivan]

interlaced material like telecine produce picture like this:
http://abload.de/img/aikatsu63.ts_snapshot95kce.png
http://abload.de/img/aikatsu63.ts_snapshotigjfh.png

these frames are very hard to encode.

x265 works different. I think it take the field and not the frame.Isn't this basically PAFF which is inferior to MBAFF?

If I deinterlace before encoding, it loses that silky smoothness. The file properties reads 29.97fps, but on playback mpc-hc reads 60fps.That's because you need to deinterlace to 60 fps :)

[huhn]

Isn't this basically PAFF which is inferior to MBAFF?

I don't encode interlaced at all. so no clue. I don't even know what you talking about.


http://x265.readthedocs.org/en/latest/cli.html
HEVC encodes interlaced content as fields. Fields must be provided to the encoder in the correct temporal order. The source dimensions must be field dimensions and the FPS must be in units of fields per second. The decoder must re-combine the fields in their correct orientation for display.

but you are in the best thread to ask about this.

[foxyshadis]

MBAFF is gone in HEVC. (We sigh, but the implementers say good riddance; I can't imagine how horrifying it'd be to implement everything from 4x4 to 64x64 MBAFF.)

Forgotten planet is VFR, which is easy to process these days. However, if you're not willing to do VFR processing, I'd just keep the video as-is, archived without re-encoding, unless it takes up a stupid amount of space. Just mux the raw video and whatever audio you want to keep into mp4 or mkv. All good players (and hardware video processors) can do VFR deinterlacing in real time, and it'll look better than straight-interlaced x265 encoding, especially if it's flagged as pulldown now.

As far as I know there are no freely available HEVC pulldown tools yet.


Again regarding file sizes: If the size is not acceptable, raise the crf or filter more. The encoder won't do this for you. You can't always beat a bad encode, and in that case you should just archive, but you can always fix a bad encode enough that it's worth spending the extra bits.

300 is a particularly insanely challenging movie, with all that digital grain. It was encoded by fine-tuning the encoder and the encoding settings for the movie -- it was an early title that was supposed to show off the superiority of VC-1 over H.264, back when Blu-ray was losing in the market -- but it's only just under 15GB of video. Until a remaster is released (the sequel uses 40% higher bitrate with a mature H.264 codec) you just have to accept that attempting to re-encode it is going to be extremely rough for any encoder.

Of course, if you had a 25GB remaster, and your encoding ended up the same 17GB, would you be happy then, despite being the same content? Source size doesn't matter, it's an artifact. If you think it matters, you need to make the hard decisions about when to reduce quality yourself.

[LigH]

Already several months ago, it was stated that HEVC would not even mention interlacing in the specification, because interlacing is not suitable for web video.

x265 specifically supporting interlacing again is a kind of concession to the "nagging audience"... ;) ;)

[LigH]

x265 1.3+58-c5624effb73c (https://www.mediafire.com/download/5wv13f3bq7pgwdr/x265_1.3+58-c5624effb73c.7z) backed out a possibly incomplete bugfix regarding B-frame bitrate prediction in VBV, causing problems in CBR mode, but re-enabled and fixed --cu-lossless.

[Darius510]

MBAFF is gone in HEVC. (We sigh, but the implementers say good riddance; I can't imagine how horrifying it'd be to implement everything from 4x4 to 64x64 MBAFF.)

Forgotten planet is VFR, which is easy to process these days. However, if you're not willing to do VFR processing, I'd just keep the video as-is, archived without re-encoding, unless it takes up a stupid amount of space. Just mux the raw video and whatever audio you want to keep into mp4 or mkv. All good players (and hardware video processors) can do VFR deinterlacing in real time, and it'll look better than straight-interlaced x265 encoding, especially if it's flagged as pulldown now.

As far as I know there are no freely available HEVC pulldown tools yet.


Again regarding file sizes: If the size is not acceptable, raise the crf or filter more. The encoder won't do this for you. You can't always beat a bad encode, and in that case you should just archive, but you can always fix a bad encode enough that it's worth spending the extra bits.

300 is a particularly insanely challenging movie, with all that digital grain. It was encoded by fine-tuning the encoder and the encoding settings for the movie -- it was an early title that was supposed to show off the superiority of VC-1 over H.264, back when Blu-ray was losing in the market -- but it's only just under 15GB of video. Until a remaster is released (the sequel uses 40% higher bitrate with a mature H.264 codec) you just have to accept that attempting to re-encode it is going to be extremely rough for any encoder.

Of course, if you had a 25GB remaster, and your encoding ended up the same 17GB, would you be happy then, despite being the same content? Source size doesn't matter, it's an artifact. If you think it matters, you need to make the hard decisions about when to reduce quality yourself.


Yeah, I would be happy. I'd feel like h265 was doing it's job in that case. Maybe this sounds weird, but I'm less concerned with file size than I am with the quality/size ratio. I feel like I'm needlessly wasting space using a less sophisticated codec when h265 seems to be superior in every way that matters. I guess I'm not giving enough leeway for the quality of the encodes, I'm just going by codec and size and assuming quality should be directly proportional to that. Perhaps that's oversimplifying it too much.

I've been tinkering a bit and I've been finding that a very light denoise before encoding produces a significantly smaller file size without any noticeable difference in image quality at the same CRF. Seems like the bits can either go towards encoding very faint noise or the underlying picture, and the filter seems to focus the encoder on what matters and ignoring that slight fuzziness that your eye just blends in anyway.

I swear though, this codec is like magic. It's unbelievable how good it looks at ridiculously low bitrates. I tried encoding a few segments of LOTR at 1000kbps, and it looked way better than it had any right to. Although there was a HUGE difference between the presets at low bitrates - veryslow was night and day better than fast, but I can barely tell the difference between them at 10000kbps+.

[Atak_Snajpera]

Regarding FILM tune preset. According to my quick test I have a feeling that default values for --psy-rd , --psy-rdoq , --aq-strength are too conservative for typical film footage. Default values in x264 give much stronger effect than those in x265.

SOURCE -> https://mega.co.nz/#!4BMXAQKC!1K_DE4rpcjGBLOxVtV6C-_L6OUIakxSelxRiOuW8j68

--pass 2 --bitrate 1024 --min-keyint 24 --keyint 240 --rd 4 --psy-rd 1.0 --psy-rdoq 1.0
http://i.cubeupload.com/b6Weps.png
http://www.mediafire.com/download/2p2lmwg1ivmpy3s/video_x265_1.mkv

--pass 2 --bitrate 1024 --min-keyint 24 --keyint 240 --rd 4 --psy-rd 2.0 --psy-rdoq 10.0
http://i.cubeupload.com/ZHaLEI.png
http://www.mediafire.com/download/n7qbgop1qgnptnb/video_x265_2.mkv

--pass 2 --bitrate 1024 --min-keyint 24 --keyint 240 --rd 4 --psy-rd 2.0 --psy-rdoq 10.0 --aq-strength 2.0
http://i.cubeupload.com/RzZIF8.png
http://www.mediafire.com/download/4vnx1uq40mbx3j3/video_x265_2_10_2.mkv

[Blue_MiSfit]

I think the middle of those 3 is actually the most visually consistent. The differences are pretty subtle, and all 3 look pretty good for 1 Mbps 1080p :)! The most aggressive version seems to pull too many bits from the moving areas - look at Morgan Freeman's face when he's talking on this clip relative to the others.

My thoughts are that this clip would be ideal with settings somewhere between the first two examples. Maybe psy-rd 1.5 and psy-rdoq 5

[xooyoozoo]

My thoughts are that this clip would be ideal with settings somewhere between the first two examples. Maybe psy-rd 1.5 and psy-rdoq 5

In the higher settings, I first noticed the extra "halo" of noise around high contrast edges before I noticed any benefits, so I definitely agree.

[Atak_Snajpera]

I agree that last example may be to extreme. I will check 1.5 , 5.0 , 1.5 variant next time.

[Atak_Snajpera]

ACHTUNG! Possible bug detected ;)
x264 https://mega.co.nz/#!xEkD2S4A!2kYRRCiZpoyJp7GaflW5mHTEtb3esPvptK6AUY88lrY
http://i.cubeupload.com/FelGgX.png

x265 https://mega.co.nz/#!1V8jyBTI!T-2vr17fYM7FY29OYBhBciWF7BWzUTJgLpX-Gdc17C8
http://i.cubeupload.com/ib5FWB.png

CMD line :
"C:\Users\Dave\Documents\Delphi_Projects\RipBot264\_Compiled\tools\avs2yuv\avs2yuv.exe" "C:\Temp\RipBot264temp\job1\job1.avs" -o - | "C:\Users\Dave\Documents\Delphi_Projects\RipBot264\_Compiled\tools\x265\x265_x64.exe" --pass 2 --bitrate 1024 --stats "C:\Temp\RipBot264temp\job1\job1.stats" --fps 24000/1001 --min-keyint 24 --keyint 240 --frames 173 --sar 8:9 --y4m --output "C:\Temp\RipBot264temp\video.265" -

Latest 8 bit build from http://builds.x265.eu/ was used.

Source -> https://mega.co.nz/#!AAUVQRAS!YRnY4zonYPFqhPke4bv9OHhiNkND_pbZYSGESFHDXns

Script
#VideoSource
LoadPlugin("C:\Users\Dave\Documents\Delphi_Projects\RipBot264\_Compiled\Tools\dgindex\DGDecode.dll")
video=MPEG2Source("C:\Temp\RipBot264temp\job1\job1.d2v")

#Deinterlace
Loadplugin("C:\Users\Dave\Documents\Delphi_Projects\RipBot264\_Compiled\Tools\AviSynth plugins\TIVTC\TIVTC.dll")
video=tfm(video,order=1)

#Decimate
Loadplugin("C:\Users\Dave\Documents\Delphi_Projects\RipBot264\_Compiled\Tools\AviSynth plugins\TIVTC\TIVTC.dll")
video=TDecimate(video)

return video

[LigH]

OK, you mean the artefacts in the lower part; I almost expected you having forgotten a SwapUV() ;)

[Atak_Snajpera]

Another one
http://i.cubeupload.com/3JP9VK.png

SOURCE -> http://www.mediafire.com/download/5bymvdfm8qyof4f/harry.mkv

[a5180007]

Same bug with MSVC build 1.3+59. It comes from the latest commit 62c4779 as 1.3+58-c5624ef is bug-free.

[chenm001]

Thanks your report.
I can reproduce it, debugging...

[x265_Project]

Thanks your report.
I can reproduce it, debugging...
Thanks Min. (chenm001 is one of our lead developers)

[Gravitator]

Maybe this bug is caused by reason non-compliance of resolution / block to the multiplicity of 64x64.

[a5180007]

@x265_Project bug solved, thanks.

EDIT : I have another problem with x265 MSVC 1.3+69:
"x265 --preset placebo park_joy_1080p50.y4m -o pj_placebo.hevc" crashes

All other presets OK. No log recorded, but when debugging with MSVC it crashes upon source/common/quant.cpp line 790 :

789 int ctx = ctxCbf[ttype][cu->getTransformIdx(absPartIdx)];
790 bestCost = totalUncodedCost + SIGCOST(estBitsSbac.blockCbpBits[ctx][0]);


cu->m_trIdx = 3 (should be 0-2), ttype = TEXT_CHROMA_V (2) => ctx = ctxCbf[2][3] undefined

EDIT 2 : seems to be solved with 1.3+114

[HotShot]

jfyi, Intel C++ 2015 is out, so the icl32/icl64 build-scripts need an update. After editing them manually, compiling the source went fine.

[Shevach]

Hi x265 community

i am working with x265 version 1.3+26-5acfb12ec5d1 . According to x265 documentation (http://x265.readthedocs.org/en/default/cli.html#quality-rate-control-and-rate-distortion-options)
the default value of aq-mode is 2 :

Adaptive Quantization operating mode. Raise or lower per-block quantization based on complexity analysis of the source image. The more complex the block, the more quantization is used. This offsets the tendency of the encoder to spend too many bits on complex areas and not enough in flat areas.

disabled
AQ enabled
AQ enabled with auto-variance (default)



However, actually the default of aq-mode is 0 (AQ disabled). Indeed, in param.cpp the following statement is executed:
param->rc.aqMode = X265_AQ_NONE;

So, pls. correct the documentation.

[x265_Project]

Hi x265 community

i am working with x265 version 1.3+26-5acfb12ec5d1 . According to x265 documentation (http://x265.readthedocs.org/en/default/cli.html#quality-rate-control-and-rate-distortion-options)
the default value of aq-mode is 2 :

Adaptive Quantization operating mode. Raise or lower per-block quantization based on complexity analysis of the source image. The more complex the block, the more quantization is used. This offsets the tendency of the encoder to spend too many bits on complex areas and not enough in flat areas.

disabled
AQ enabled
AQ enabled with auto-variance (default)



However, actually the default of aq-mode is 0 (AQ disabled). Indeed, in param.cpp the following statement is executed:
param->rc.aqMode = X265_AQ_NONE;

So, pls. correct the documentation.
Hi Shevach,
On line 185 in param.cpp we set the default value...
param->rc.aqMode = X265_AQ_AUTO_VARIANCE;

For the Ultrafast or Superfast presets we turn it off...
if (!strcmp(preset, "ultrafast"))
{
param->lookaheadDepth = 10;
param->scenecutThreshold = 0; // disable lookahead
param->maxCUSize = 32;
param->searchRange = 25;
param->bFrameAdaptive = 0;
param->subpelRefine = 0;
param->searchMethod = X265_DIA_SEARCH;
param->bEnableEarlySkip = 1;
param->bEnableCbfFastMode = 1;
param->bEnableSAO = 0;
param->bEnableSignHiding = 0;
param->bEnableWeightedPred = 0;
param->rdLevel = 2;
param->maxNumReferences = 1;
param->bEnableLoopFilter = 0;
param->rc.aqStrength = 0.0;
param->rc.aqMode = X265_AQ_NONE;
param->rc.cuTree = 0;
param->bEnableFastIntra = 1;
}
else if (!strcmp(preset, "superfast"))
{
param->lookaheadDepth = 10;
param->maxCUSize = 32;
param->searchRange = 44;
param->bFrameAdaptive = 0;
param->subpelRefine = 1;
param->bEnableEarlySkip = 1;
param->bEnableCbfFastMode = 1;
param->bEnableWeightedPred = 0;
param->rdLevel = 2;
param->maxNumReferences = 1;
param->rc.aqStrength = 0.0;
param->rc.aqMode = X265_AQ_NONE;
param->rc.cuTree = 0;
param->bEnableFastIntra = 1;
As you run x265 from the command-line you can see the AQ strength reported on the screen...

C:\Testx265>x265 --input v:\Sequences\10_chinchilla_02_3840x2160_24p.yuv --input
-res 3840x2160 --fps 24 -f 240 -o d:\BBBunny_4000_24fps.hevc --csv c:\Testx265\R
esults\2PassDemos-2014-09-07-09-21.csv --bitrate 4000 -p veryslow --ssim --psnr
--pass 2 --psy-rd 0.7 --psy-rdoq 1.0 --stats v:\DemoBitstreams\Logs\BBBunny_4000
_stats.log
yuv [info]: 3840x2160 fps 24000/1000 i420p8 frames 0 - 239 of 240
x265 [info]: HEVC encoder version 1.3+117-ed4c9acafc11
x265 [info]: build info [Windows][MSVC 1700][64 bit] 8bpp
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZ
CNT BMI2
x265 [info]: WPP streams / pool / frames : 34 / 8 / 3
x265 [warning]: --psnr used with psy on: results will be invalid!
x265 [warning]: --tune psnr should be used if attempting to benchmark psnr!
x265 [info]: Main profile, Level-6 (Main tier)
x265 [info]: CU size : 64
x265 [info]: Max RQT depth inter / intra : 3 / 3
x265 [info]: ME / range / subpel / merge : star / 57 / 4 / 4
x265 [info]: Keyframe min / max / scenecut : 24 / 250 / 40
x265 [info]: Lookahead / bframes / badapt : 40 / 8 / 2
x265 [info]: b-pyramid / weightp / weightb / refs: 1 / 1 / 0 / 5
x265 [info]: Rate Control / AQ-Strength / CUTree : ABR-4000 kbps / 1.0 / 1
x265 [info]: tools: rect amp rd=6 psy-rd=0.70 psy-rdoq=1.00 lft sao-lcu signhide
stats-read

[LigH]

After so many recent patches with speed-ups and fixes, now is probably a good time to release another build: x265 1.3+145-44cb33846e0e (https://www.mediafire.com/download/e52sw5dvxb2lsbg/x265_1.3+145-44cb33846e0e.7z)

Unfortunately, most speed-ups seem to be relevant only for AVX2 supporting CPUs, which I don't own... but a few are also rather generic.

[Daemon404]

Slightly off topic here: Is there any value in providing MinGW-w64 builds of x265 on chromashift?

If there is significant interest I will add it to the nightlies.

[SamKook]

Those are the one I use so I would say yes. They were running faster(or about equal for some) than all others on my 2600k last time I checked.

[LigH]

Not sure which kind of binaries you used to offer so far (since I build my own, I don't look much elsewhere); but at least AMD64 Windows builds are certainly of interest (Win32 not so much, 4K resolutions are hard-edge cases), and if you offer builds of the same revision by different compilers, one can even compare their speed (and you may find warnings only thrown by one of several).

[Daemon404]

Not sure which kind of binaries you used to offer so far (since I build my own, I don't look much elsewhere); but at least AMD64 Windows builds are certainly of interest (Win32 not so much, 4K resolutions are hard-edge cases), and if you offer builds of the same revision by different compilers, one can even compare their speed (and you may find warnings only thrown by one of several).

I only have offered Win64 built with ICL ans MSVC so far, nightly/morningly.

[foxyshadis]

Moved posts unrelated to x265 to a new devices thread (https://forum.doom9.org/showthread.php?t=171163).

[sneaker_ger]

Using default settings with --psy-rd 1.0 --psy-rdoq 1.0 results in the following line:
x265 [info]: tools: esd rd=2 psy-rd=1.00 lft sao-lcu signhide fast-intra stats-write

psy-rd 1.0 will also be written into the custom SEI. The docs say this should be impossible as at least rd 3 is required for psy-rd.

[Atak_Snajpera]

Using default settings with --psy-rd 1.0 --psy-rdoq 1.0 results in the following line:
x265 [info]: tools: esd rd=2 psy-rd=1.00 lft sao-lcu signhide fast-intra stats-write

psy-rd 1.0 will also be written into the custom SEI. The docs say this should be impossible as at least rd 3 is required for psy-rd.

Second or first pass?

[sneaker_ger]

It was a (fast) first pass - I overlooked that. The second pass does indeed use rd 3.

[MoSal]

typedefs are missing for the new structures in commit e5a24e5ba46e?

[x265_Project]

typedefs are missing for the new structures in commit e5a24e5ba46e?

Thanks MoSal. I've passed this along to the engineering team, but in the future it would be better if you would be able to provide software development feedback directly to the development mailing list (which all x265 developers read).

Tom

[x265_Project]

If you're in Amsterdam this weekend for the IBC show and you want to meet with us, please send me an email (tom . vaughan @ multicorewareinc.com). We've had many fantastic meetings so far, and I'm really excited for the future of x265 and UHDcode.

Tom

[a5180007]

Using default settings with --psy-rd 1.0 --psy-rdoq 1.0 results in the following line:
x265 [info]: tools: esd rd=2 psy-rd=1.00 lft sao-lcu signhide fast-intra stats-write

@sneaker_ger Beware, also no psy-rdoq when rd < 4.

[NikosD]

We've had many fantastic meetings so far, and I'm really excited for the future of x265 and UHDcode.

Tom

In a brief post, which are the main advantages of a commercial HEVC decoder (UHDcode) over free solutions like the FFmpeg based LAV filters ?

[x265_Project]

In a brief post, which are the main advantages of a commercial HEVC decoder (UHDcode) over free solutions like the FFmpeg based LAV filters ?

Our decoder is twice as fast as FFMPEG (we have done a great deal of performance optimization). This means that on a given system, our decoder can handle higher quality video (higher resolution, bit rate, frame rate). It's OpenCL accelerated, offloading much of the work to the GPU. This allows for more available CPU resources for the rest of the video application. It supports the full HEVC specification, including 10 bit video. It is very rigorously tested, and adopted by many commercial customers on a variety of platforms.

[nevcairiel]

It supports the full HEVC specification, including 10 bit video.

You keep saying that as if FFmpeg doesn't. FFmpeg supports 12-bit even, and RExt. :)
Regarding the speed, a lot of work is happening to SIMD the crucial parts, which will make FFmpeg more than twice as fast as it is now (as preliminary numbers indicate). But competition is a good thing, i hope. ;)

[x265_Project]

You keep saying that as if FFmpeg doesn't. FFmpeg supports 12-bit even, and RExt. :)
Regarding the speed, a lot of work is happening to SIMD the crucial parts, which will make FFmpeg more than twice as fast as it is now (as preliminary numbers indicate). But competition is a good thing, i hope. ;)
Sorry... I wasn't aware that it supported high bit depth.

Yes, it's takes a lot of development work to make things go as fast as possible, but I'm sure FFMPEG will get there. I don't want to sound critical of FFMPEG... we are big fans of and contributors to FFMPEG, and many other open-source projects.

[NikosD]

Our decoder is twice as fast as FFMPEG (we have done a great deal of performance optimization). This means that on a given system, our decoder can handle higher quality video (higher resolution, bit rate, frame rate). It's OpenCL accelerated, offloading much of the work to the GPU. This allows for more available CPU resources for the rest of the video application. It supports the full HEVC specification, including 10 bit video. It is very rigorously tested, and adopted by many commercial customers on a variety of platforms.

I searched a little your site and didn't find a trial or free demo of UHDcode just to test speed and compatibility.

Is it in a DS filter form ?

Do you provide a trial version that could be downloaded ?

[Gravitator]

You can take as an example to test this decoder > http://xhevc.com/en/downloads/downloadCenter.jsp
(Strongene PC OpenCL HEVC/H.265 Decoder for AMD)

Very quiet and not hear about these developments in terms of benefit / superiority on the forums.

[huhn]

You can take as an example to test this decoder > http://xhevc.com/en/downloads/downloadCenter.jsp
(Strongene PC OpenCL HEVC/H.265 Decoder for AMD)

Very quiet and not hear about these developments in terms of benefit / superiority on the forums.

he did alrady

works with nvidia and intel too.
http://forum.doom9.org/showthread.php?t=163110&page=17

newer lavfilter 64x builds can beat this openCL decoder already.

[Gravitator]

newer lavfilter 64x builds can beat this openCL decoder already.
DivX is preferable on my C2D.

[huhn]

DivX is preferable on my C2D.

so what?

[Gravitator]

so what?
Comes out that DivX a leader in decoding HEVC (at least on the weak processor).

[huhn]

I still wonder what this has to do with the x265 encoder.

[LigH]

(Back to encoders...)

Another "merge with stable" plus a few fixes — x265 1.3+185-2fb61cc75152 (https://www.mediafire.com/download/auvclatsanj1lkt/x265_1.3+185-2fb61cc75152.7z)

There was an interesting find in the VideoHelp forum, based on a quite extreme test with too little bitrate versus too much freedom (16 b, 16 ref) for a 1080p50 clip: The reconstructed video appears to introduce blends not present in the original. Is it possible that partially blending half the framerate gets preferred over encoding all frames?

[a5180007]

There was an interesting find in the VideoHelp forum, based on a quite extreme test with too little bitrate versus too much freedom (16 b, 16 ref) for a 1080p50 clip

The encoding has been done with Hybrid, filters and x265 parameters unknown (nothing in the SEI ?!?). I have not been able to reproduce these artefacts with x265 cli.

EDIT : artefact from http://forum.videohelp.com/threads/357754-%5BHEVC%5D-x265-EXE-mingw-builds?p=2346046&viewfull=1#post2346046 reproduced with [1.3+198] x265 --crf 29 --psy-rd 0.1 --b-adapt 0 --bframes 16 --ref 16 --rc-lookahead 30 --ipratio 1.7 --pbratio 1.7 --seek 395 -o pj_crf29.hevc park_joy_1080p50.y4m

[xooyoozoo]

(16 b, 16 ref) for a 1080p50 clip

Slight tangent: the spec caps 'numpoctotalcurr' (unique L0 + L1 refs per frame) at 8 for all profiles and levels. The DPB can be larger if the extra frames are for later usage, but x265 puts any frame in the DPB immediately to use in either L0 or L1.

To be honest, I'm not sure why the x265 cli should allow breaking that cap at all. It's inviting potential decoder issues for little gain.

[a5180007]

Artefact is still present (although less visible) with the following profile-compliant encoding :

x265 --crf 29 --b-adapt 0 --bframes 16 --seek 395 -o pj_crf29.hevc park_joy_1080p50.y4m

[LigH]

Even the "pacebo" preset uses only 8 consecutive B frames and 5 reference frames as maxima, according to the presets documentation (http://x265.readthedocs.org/en/default/presets.html) (provided it is current and correct).

We should call this preset "homeopathic" (= "placebo forte"). :p

[Atak_Snajpera]

What has happened to 32 bit binaries of x265? Both executables at http://builds.x265.eu/ are 64 bit
http://i.cubeupload.com/7UGeSz.png http://i.cubeupload.com/qQbs81.png

[zerowalker]

Been a while since i last checked this.
At that time Psy-rdo was being implemented and fixed etc.

So how has it been since that time?

Any highlights?

Does it still make a "blurry mess" compared to x264 in normal scenarios?(sounds harsh, but you know what i mean;P).

Thanks

[LigH]

So you want us to spend our leisure time to test for you? ... Uhm, no. You can believe us telling you that x265 keeps developing and improving, or you can doubt it and test on your own... ;) Preferably with a CPU supporting AVX2.

[foxyshadis]

zw, check the comparison thread (https://forum.doom9.org/showthread.php?t=170986). sneaker is doing a bang-up job of encoding tons of comparisons for us, though more samples could always help.

[zerowalker]

So you want us to spend our leisure time to test for you? ... Uhm, no. You can believe us telling you that x265 keeps developing and improving, or you can doubt it and test on your own... ;) Preferably with a CPU supporting AVX2.

No, not at all;P

Simply wanted a statement if something big has happened.
And your answer makes me assume it's at a similar place as before. Which of course isn't bad.

Thanks

Foxyshadis, have looked there from time to time. So guess i have kept my self updated;)

[LigH]

As far as I understood, HEVC can't break the laws of Claude Shannon's theory of information. You want less data for a similar amount of information? Then you need to reduce redundancies. But you can't go below the entropy threshold. If you have less data, you will lose information. Therefore, expect compression algorithms with arbitrary target bitrates to be lossy; but the annoyance of this loss may vary among these algorithms. Information is a matter of interpretation. There may be enough for a summary, but not enough for a complete replication.

I have done several tests with very tight bitrates. In general, at about the same bitrates, HEVC appeared to preserve the overall content better, leaving less annoying artefacts than AVC where loss was inevitable. But I did not compare how much detail HEVC and AVC preserve when the bitrate is beneficial.

Also I tested the psychovisual features a bit and found that the strong bias for simplification may be counterproductive in specific cases where areas with very much energy (high image frequencies, much contrast) and very little energy are close together (e.g. curly hair next to a flat wall), but will probably hurt less when the "energy dynamics" is not so extreme across the frame (at least some structure everywhere).

By the way, the most recent patches of version 1.3 contain a lot of speed optimizations. But mainly for AVX2 and SSE3+... a Phenom-II is way below par now.

[zerowalker]

Understandable, like Moore's law there is only so much that can be done, though luckily here you can use tricks and illusions, while a physical limit is there to stay.

From my own understanding, and probably everyone else, it's as you say. Low bitrate and the HEVC will prevail while AVC/H264 will be a mess beyond compare.

Higher though, i think HEVC quite quickly losses against AVC/H264, and that's probably what most people are "disappointed", as when you hear H265, you would think (Oh it's H264 v2) or something;P

Interesting factors you noticed though, haven't really thought about them, as i just pretty much compare and say "This is the winner".

Ah great, remember that last i checked it was quite a bit faster compared to a while back (when it was Very Slow), so speeds, no matter what instructions are used (latest and greatest is of course understandable) is something that's very welcomed:)

[LigH]

I remember a similar comparison between MPEG2 and MPEG4-ASP (DivX). Already (what seems to be) decades ago, people stated that MPEG2 is better at preserving details for high bitrate circumstances.

Well, MPEG4-ASP can achieve the same level of detail preservation when using MPEG quantization instead of H.263, and possibly even custom matrices.

So I believe HEVC may be able to be on par with AVC too, with specific tweaks.

[Atak_Snajpera]

I still do not understand why film grain reconstruction is not part of HEVC standard? Is that hard to analyze original footage in terms of grain/noise characteristics and then try to reconstruct that grain/noise during decoding? Instead of that we have to experiment like idiots with AQ strength and with psy settings. I think that reconstructed grain/noise could look as good as original and the same time we could save more bits.

[LigH]

But it is instead already part of the MPEG4-AVC (H.264) specification? So its support is more or less mandatory for decoders? ... Probably yes; searching for "Film grain modeling" in the english Wikipedia directly leads to "H.264/MPEG-4 AVC: Software encoder feature comparison (http://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Software_encoder_feature_comparison)" (Interesting: English Wikipedia reports no support for x264 despite its "--nr" parameter, so this seems to be less complex than "a visual version of Spectral Band Replication".)

Its implementation, though, seems to be very sparse, for both AVC encoders and decoders. Apparently, not even JM reference software implemented it yet for AVC, not to mention HEVC. The complexity of such algorithms is certainly quite high.

DarkShikari tried some Film Grain Optimization (I believe that was reordering of grain patterns for compressibility instead?) back in 2008.

[zerowalker]

Didn't know that, thought it was always better than MPEG2.
But AVC is always better than MPEG2 right, i mean, MPEG2 needs like 10mbps while x264 can look similar at 3mbps (or something), so it's not really comparable.
But of course if both are at 50mbps they will look the same (for SD and some HD material).

[Gravitator]

I still do not understand why film grain reconstruction is not part of HEVC standard? Is that hard to analyze original footage in terms of grain/noise characteristics and then try to reconstruct that grain/noise during decoding? Instead of that we have to experiment like idiots with AQ strength and with psy settings. I think that reconstructed grain/noise could look as good as original and the same time we could save more bits.
Hi! I have previously suggested such a method > vhelp.com (http://forum.videohelp.com/threads/360069-x265-HEVC-Encoder?p=2318174&viewfull=1#post2318174)
Approximate emulation - noise analysis and transmission of information for filter (example MadVR will use it for a more accurate noise generation - take from the stream HEVC).
+ For interest

Experiment with the settings and achieve additional visual quality.
--------
Look at the left part of the costume (dark scene - a complicated scene) > MadVR vs EVR.7z (http://forum.videohelp.com/attachments/23940-1394141284/MadVR%20vs%20EVR.7z) (source (http://forum.videohelp.com/threads/362892-Upgrading-madvr?p=2306667&viewfull=1#post2306667))

[sneaker_ger]

But it is instead already part of the MPEG4-AVC (H.264) specification? So its support is more or less mandatory for decoders? ... Probably yes; searching for "Film grain modeling" in the english Wikipedia directly leads to "H.264/MPEG-4 AVC: Software encoder feature comparison (http://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Software_encoder_feature_comparison)" (Interesting: English Wikipedia reports no support for x264 despite its "--nr" parameter, so this seems to be less complex than "a visual version of Spectral Band Replication".)

We had a short discussion here (http://forum.doom9.org/showthread.php?t=171195). Both AVC and HEVC have this model but it is optional for decoding. It's not used for references.
x264's --nr and --fgo (not in vanilla x264) are pure encoder side features AFAIK. I don't know why fgo never made the vanilla builds (superseded by psy-rd?) or if it worth looking at for the x265 devs.

[foxyshadis]

Noise analysis isn't particularly hard -- merely denoising, differencing, and analyzing the remainder is easy. Compressing, storing, and reconstructing it is hard, though, and requires a huge amount of processing power (or silicon area) to recreate the character of the noise, depending on how granular you want to be -- one value for the whole frame, all the way down to one value per macroblock. FGO applies to full frames, but has not one but two entirely different ways of emulating grain, both of which can be used; one uses frequency values and an iDCT, one is basically Tom Barry's AddGrain filter. With zero guidance in the spec on how to build such a decoder, aside from the abstract principles, it's no wonder that most don't bother.

[lotusgg]

Noise analysis isn't particularly hard -- merely denoising, differencing, and analyzing the remainder is easy. Compressing, storing, and reconstructing it is hard, though, and requires a huge amount of processing power (or silicon area) to recreate the character of the noise, depending on how granular you want to be -- one value for the whole frame, all the way down to one value per macroblock. FGO applies to full frames, but has not one but two entirely different ways of emulating grain, both of which can be used; one uses frequency values and an iDCT, one is basically Tom Barry's AddGrain filter. With zero guidance in the spec on how to build such a decoder, aside from the abstract principles, it's no wonder that most don't bother.

Why no make it a 3rd(or second in CRF cases) pass just for calculating, compressing and storing this "noise"?

[foxyshadis]

Why no make it a 3rd(or second in CRF cases) pass just for calculating, compressing and storing this "noise"?

You have to do it before or at the same time the video is encoded, because you analyze and remove the grain prior to encoding. There's no need for an extra pass. The big problem is on the decoder side, anyway, not the encoder side.

[lotusgg]

You have to do it before or at the same time the video is encoded, because you analyze and remove the grain prior to encoding. There's no need for an extra pass. The big problem is on the decoder side, anyway, not the encoder side.

I see.
This is goind to be a hard hit on mild processors.

[Parabola]

To me, the trickiest thing is that the parameters are set per-frame (OK, granted, you might be able to tile/slice to apply grain differently per set of CTUs).

You would have to check that the grain exists in the whole area to which you are applying it. Otherwise, you can imagine that, for example, if encoding a grainy old movie with modern crisp, clean, CG captions, you could easily get grainy captions at the decoder.

-John

[LigH]

Thank you all for sharing your thoughts. This supports my impression of a complex topic.

If decoder support is not mandatory, then I could imagine that encoder-only support might instead cause a flattened reproduction with decoders not supporting it, and I don't dare to imagine if it will look rather good (denoised) or bad (lowpass-quant-blurry).

[smegolas]

You have to do it before or at the same time the video is encoded, because you analyze and remove the grain prior to encoding.

Therein lies the problem. Removing noise/grain without compromising image quality is not trivial.

[a5180007]

Any news about the artefact mentionned by Ligh (piece of umbrella shown 7 frames earlier)? Is this a bug?

http://i.imgur.com/xuqj1oq.png
Animated PNG 3.58 MB

[1.3+219] x265 --b-adapt 0 --bframes 16 park_joy_1080p.y4m -o pj.hevc

Although --b-apdapt 0 --bframes 16 cannot be considered a standard encoding, x264 does not show anything like this with the same parameters.
EDIT : this might explain the amount of 'ghosting' in x265
In this excerpt, the same artefact is visible for the upper umbrella, but also for the tip of the right wing of the central man, the knee of the leftmost woman...

[lotusgg]

how to hi444p on x265?

[foxyshadis]

how to hi444p on x265?

A lot slower than 420, but otherwise working fine.

[lotusgg]

A lot slower than 420, but otherwise working fine.

Speed is no much problem.
Btw, can I upsample 4:2:0 to 4:4:4?

[LigH]

Of course you can. But it won't improve quality afterwards, once it had chroma subsampling 4:2:0. It will only decrease compressibility.

[LigH]

Another week gone, therefore: x265 1.3+240-1c172c1822e4 (https://www.mediafire.com/download/gfe2noicoaj3h2g/x265_1.3+240-1c172c1822e4.7z)

[Atak_Snajpera]

Which one looks better for you? (--rd 4 --psy-rd 1.0 --psy-rdoq 1.0 --aq-mode 1/2 --aq-strength 2 )

Sample 1 (https://mega.co.nz/#!oQEjES4Q!Wu--TwRUSm4J9L-BOIRgWzLRHCxpspnqO6wH7FG8HHk)
Sample 2 (https://mega.co.nz/#!cEkxGRia!AgbeGp6DnXrIBR2czBg7Sj8WV6U1zRN9ZIrrNm-D3o0)

[sneaker_ger]

From awful laptop display: 1 has less banding/flat blocks.

[Gravitator]

Which one looks better for you?
A! Why such a big difference?

[Atak_Snajpera]

It looks like --aq-mode 2 sucks alot. No idea why devs decided to use mode 2 as default.

[LigH]

So it seems that AQ mode 2 is currently worse in x265; but may it possibly be based on the differences between HEVC and AVC in general (so you can't take it over from x264 so easily), or may it rather just be a mistake in the specific implementation in x265? ... Do you get a similar relation with x264 and the same clip?

[a5180007]

Already mentioned months ago http://forum.doom9.org/showthread.php?p=1687406#post1687406. aq=2 increases ssim.

[ErazorTT]

Why is there no way to change the qcomp? Is this by purpose? I see that in the source code it does exist.. :confused:

[sneaker_ger]

In light of the recent aq-mode discussions I decided to try out some variations with the lighthouse sample (http://217.160.126.132/lighthouse_lossless.mp4).

The biggest problem: there are so many possible combinations - I cannot test them all.

Binaries: 1.3+330 ICL from Chromashift

All use --preset slow, 2pass and --bitrate 4000. The bitrate was not always hit but banding isn't usually affected by slight bitrate variations anyways and I was too lazy to fix the problems. The rest of the settings can be deducted from the file names:
aq1/2 == --aq-mode 1/2
rd1 == --psy-rd 1.0
rdoq1 == --psy-rdoq 1.0
str2 == --aq-strength 2.0

Output files, file sizes, screenshot package, logs: https://mega.co.nz/#F!AgdRCSjC!Dr-4__tm9xMTvUdL4I8-Zw

Source screenshot:
http://abload.de/img/290_orgqtsuz.png

8 bit:

http://abload.de/img/aq2_8bit0000002rdrz.png
http://abload.de/img/aq1_8bit000000ixcoq.png
http://abload.de/img/aq2_str2_8bit000000w0jds.png
http://abload.de/img/aq1_str2_8bit000000q2fkm.png
http://abload.de/img/aq2_rd1_8bit000000t5i70.png
http://abload.de/img/aq1_rd1_8bit0000008lizc.png
http://abload.de/img/aq2_rd1_str2_8bit0000h3j1n.png
http://abload.de/img/aq1_rd1_str2_8bit0000vofjw.png
http://abload.de/img/aq2_rd1_rdoq1_8bit0004sfdh.png
http://abload.de/img/aq1_rd1_rdoq1_8bit00060dx3.png
http://abload.de/img/aq2_rd1_rdoq1_str2_8bw6fxx.png
http://abload.de/img/aq1_rd1_rdoq1_str2_8boyeh0.png

10 bit:

http://abload.de/img/aq2_10bit0000009cdzl.png
http://abload.de/img/aq1_10bit000000rdfi2.png
http://abload.de/img/aq2_str2_10bit0000009ejnc.png
http://abload.de/img/aq1_str2_10bit000000fmf8i.png
http://abload.de/img/aq2_rd1_10bit0000003kfef.png
http://abload.de/img/aq1_rd1_10bit0000007viu7.png
http://abload.de/img/aq2_rd1_str2_10bit000y3kde.png
http://abload.de/img/aq1_rd1_str2_10bit0001ucq8.png
http://abload.de/img/aq2_rd1_rdoq1_10bit00dqdko.png
http://abload.de/img/aq1_rd1_rdoq1_10bit00jvdoc.png
http://abload.de/img/aq2_rd1_rdoq1_str2_102vefx.png
http://abload.de/img/aq1_rd1_rdoq1_str2_106wefk.png

[xxxxx]

my aq mode/strenght related tests (http://forum.videohelp.com/threads/367339-HEVC-test-samples)

[plonk420]

i've noticed some blocking @ 55 seconds of this clip as i work my way lower in crf-values

x265 settings: veryslow, 4 bframes, rd mode 4

x265 (https://mega.co.nz/#!CFoggJxS!BhQbZlu8zEwdMlkMMRJbln1O7B3Ve2tz7psQTqU1ydk) - image (http://i3.minus.com/i6tyfSWni4jBL.png) (edit: i just noticed it doesn't look as bad in MPC as it does in VLC as i was screenshotting)

x264 (https://mega.co.nz/#!OVh2nCTJ!EKGtw5tn_i1nsFWFJ2iMp-yFlVb4BO42gZsEWMJvD8g)

also, is there an equivalent of x264's --deblock -3:-3 for x265?

[LigH]

Two more builds as "last week's results". There is a lot more parallelization going on. The last version (1.3+362) has different compiler warnings by GCC, depending on the variant...

x265 1.3+331-b6d49505b179 (https://www.mediafire.com/download/su08d4em8l2jd86/x265_1.3+331-b6d49505b179.7z)
x265 1.3+362-4b7c473c3ef4 (https://www.mediafire.com/download/zk9dmh9gc0v3nu7/x265_1.3+362-4b7c473c3ef4.7z)

[BlockABoots]

I think it is time to take a look at settings used in presets. I've tested those presets with first 10 min of Drive movie (http://www.imdb.com/title/tt0780504/?ref_=nv_sr_1).
Frame size after cropping: 1920x800
My CPU: Intel Xeon E5-2690 ( 8C / 16T )
Common command line: --crf 20 --min-keyint 24 --keyint 240
NOTE: In order to achieve max cpu usage and encoding speed in x265 I was encoding two 1 min chunks at the same time. (10 chunks total)

http://i.imgur.com/rV4FQGi.png

As you can see difference in encoding speed is marginal between superfast and fast. Also there is huge drop from fast to medium (almost 2x)

and for comparison ...

http://i.imgur.com/XAFTyUj.png

Does encoding at faster speeds effect the quality or does it just effect the file size of the output file?

[Sharc]

Does encoding at faster speeds effect the quality or does it just effect the file size of the output file?
Basically, encoding at faster speeds means:
- reducing the quality for the same file size
- increasing the file size for the same quality

But keep in mind that same crf does not mean same quality.

[kotuwa]

Zones

Is there any switch or method in x265 to specify zones like --zones in x264 ?

!?

[huhn]

rule 8...

I can't find it here: http://x265.readthedocs.org/en/latest/cli.html

so I guess it is not implemented.
simple work around:
just cut the parts with a program like avisynth trim() and put them together with a muxer like mmg after encoding each part with the desired settings.

[LigH]

Another "last week's result": x265 1.3+378-f26e81eb555a (https://www.mediafire.com/download/jbaicgklf62q8ax/x265_1.3+378-f26e81eb555a.7z)

[agressiv]

How are people handling banding? x265 seems to struggle with this more than just about anything.

Without ballooning up bitrates or using 10-bit, what are you guys using that isn't the following:

--rd 4 --psy-rd 1.0 --psy-rdoq 1.0 --aq-mode 1 --aq-strength 2

If I don't use these settings (mainly --aq-mode 1 and --aq-strength 2) - banding is atrocious.

However, in some scenes, your bitrate can be greater than a comparable x264 encode, which handles banding much better it seems.

Here is a 30 second original sample (from blu-ray) I'm using:

https://mega.co.nz/#!2Aw02IbJ!zD0w6nQ4cQM5brbteu2W7QstS8uTmCRNI1Gwnz1mE3M
(https://mega.co.nz/#!2Aw02IbJ!zD0w6nQ4cQM5brbteu2W7QstS8uTmCRNI1Gwnz1mE3M)

[xkinn123]

How are people handling banding? x265 seems to struggle with this more than just about anything.

Without ballooning up bitrates or using 10-bit, what are you guys using that isn't the following:



If I don't use these settings (mainly --aq-mode 1 and --aq-strength 2) - banding is atrocious.

However, in some scenes, your bitrate can be greater than a comparable x264 encode, which handles banding much better it seems.

Here is a 30 second original sample (from blu-ray) I'm using:

https://mega.co.nz/#!2Aw02IbJ!zD0w6nQ4cQM5brbteu2W7QstS8uTmCRNI1Gwnz1mE3M
(https://mega.co.nz/#!2Aw02IbJ!zD0w6nQ4cQM5brbteu2W7QstS8uTmCRNI1Gwnz1mE3M)

have you tested it on anime?
It's the best way for me to check the banding problem.

[schweinsz]

Does encoding at faster speeds effect the quality or does it just effect the file size of the output file?
Could you list the speed of the slow configuration of the x265?

[xooyoozoo]

If I don't use these settings (mainly --aq-mode 1 and --aq-strength 2) - banding is atrocious.

However, in some scenes, your bitrate can be greater than a comparable x264 encode, which handles banding much better it seems.

Here is a 30 second original sample (from blu-ray) I'm using:

https://mega.co.nz/#!2Aw02IbJ!zD0w6nQ4cQM5brbteu2W7QstS8uTmCRNI1Gwnz1mE3M
(https://mega.co.nz/#!2Aw02IbJ!zD0w6nQ4cQM5brbteu2W7QstS8uTmCRNI1Gwnz1mE3M)

Testing that clip with x264, I think aq-mode 2 also looks worse than aq-mode 1, but of course it's not that big a deal because x264 seems to be naturally better with banding. Still, I can only assume x264 made the right decision all those years ago when they made AQ1 the default.

Increasing the aq strength in x265 made the banding much better, but it comes at the expense of detailed regions. It also feels "wrong" to do this, because the bands shouldn't need to leech precious bits from other places, as just a little bit of random noise and motion would go a long way.

Psy-rdo/rdoq doesn't seem to do much to alleviate the problem either. :/

[LigH]

Another week of patches: x265 1.3+619-7eab67ffff81 (https://www.mediafire.com/download/d255rajml4k5amo/x265_1.3+619-7eab67ffff81.7z)

[nuon]

Here a size comparison what size reduction you get when adding CPU Cycles by choosing slower presets.
Fullhd game sequence of Borderlands2, 33sec duration, quantisation strenght 28.

[LigH]

Barely interesting: The same CRF for different presets is not guaranteed to reduce the size with each step, and even more not made with this only purpose (it may be a probable side effect at most). Notice a slight exception for preset superfast, and an equal value between presets veryfast and faster.

[BadFrame]

Just tried buiding x265 and testing it for the first time in quite a while, have to say I'm impressed with the improvements both in speed and quality from when I last tried it (admittedly quite some time ago), kudos to the x265 developers !

Also did a test of building it using PGO (profile-guided optimization) and got a 7-8% performance increase compared to the standard release build, indicating that there is likely a lot more performance to be had when more c code is converted to hand-written optimized assembly.

[mchartier]

Just tried buiding x265 and testing it for the first time in quite a while, have to say I'm impressed with the improvements both in speed and quality from when I last tried it (admittedly quite some time ago), kudos to the x265 developers !

Also did a test of building it using PGO (profile-guided optimization) and got a 7-8% performance increase compared to the standard release build, indicating that there is likely a lot more performance to be had when more c code is converted to hand-written optimized assembly.

Please post this PGO build :)

[x265_Project]

We are doing some fairly major code refactoring, improving parallelization and performance. Early results are very encouraging. It will take another couple of weeks to complete the current phase of development, which started several months ago. In the meantime, it is probably a bit too early to spend too much energy on other compiler optimizations, as things are still changing fast. We'll share more details when we hit the next milestone.

Tom

[x265_Project]

Just tried buiding x265 and testing it for the first time in quite a while, have to say I'm impressed with the improvements both in speed and quality from when I last tried it (admittedly quite some time ago), kudos to the x265 developers !

Also did a test of building it using PGO (profile-guided optimization) and got a 7-8% performance increase compared to the standard release build, indicating that there is likely a lot more performance to be had when more c code is converted to hand-written optimized assembly.
With the caveats above... we really appreciate feedback like this. Can you share more details on your build/compiler environment and how you created your PGO build?

Thanks!
Tom

[BadFrame]

With the caveats above... we really appreciate feedback like this. Can you share more details on your build/compiler environment and how you created your PGO build?

Of course, let's see (from memory here), I configured with 'shared' disabled, I don't think this affects PGO in any major way but I was going to try building with LTO aswell (Link Time Optimization) and it works better on a single static binary.

Then I did a quick and dirty after doing the normal release build, and just edited CMakeCache.txt to change the following to:

CMAKE_CXX_FLAGS_RELEASE:STRING=-O3 -march=native -DNDEBUG -fprofile-generate -fprofile-dir=/mnt/ram

CMAKE_C_FLAGS_RELEASE:STRING=-O3 -march=native -DNDEBUG -fprofile-generate -fprofile-dir=/mnt/ram

CMAKE_EXE_LINKER_FLAGS_RELEASE:STRING=-O3 -march=native -DNDEBUG -fprofile-generate -fprofile-dir=/mnt/ram

did a make clean and built the binary to be used for profile gathering, this binary runs slower than a usual binary since it gathers a lot of runtime information when running, I encoded a small clip using --preset slower --crf 10 IIRC, when it was done encoding, the binary automatically dumps the runtime data in the path chosen (in my case /mnt/ram)

then another make clean, and another quick and dirty edit of CMakeCache.txt to change the following to:

CMAKE_CXX_FLAGS_RELEASE:STRING=-O3 -march=native -DNDEBUG -fprofile-use -fprofile-correction -fprofile-dir=/mnt/ram

CMAKE_C_FLAGS_RELEASE:STRING=-O3 -march=native -DNDEBUG -fprofile-use -fprofile-correction -fprofile-dir=/mnt/ram

CMAKE_EXE_LINKER_FLAGS_RELEASE:STRING=-O3 -march=native -DNDEBUG -fprofile-use -fprofile-correction -fprofile-dir=/mnt/ram

followed by 'make' to generate the final binary with optimization improvements made based upon the runtime data gathered (no more guesswork for the compiler when it comes to loop unrolling, branch prediction etc).

after that I did a benchmark against the 'normal' release build (-O3 -DNDEBUG IIRC) and the PGO build was 7-8% faster.

Oh, and this was on Arch Linux 64-bit, using GCC 4.9 toolchain on a core i5.

And thanks again for the great work you guys are doing on x265!

[BadFrame]

Please post this PGO build :)

Most people here seem to be running Windows, I'm on Linux so I don't know if there is any point to posting a 64-bit Linux binary (typically if you run Linux you can build it yourself) ?

If you are using Windows I know that Visual Studio has PGO, although IIRC it's disabled in the (free) express version.

[xxxxx]

We are doing some fairly major code refactoring, improving parallelization and performance. Early results are very encouraging. It will take another couple of weeks to complete the current phase of development, which started several months ago. In the meantime, it is probably a bit too early to spend too much energy on other compiler optimizations, as things are still changing fast. We'll share more details when we hit the next milestone.

Tom

Are you working on the banding issue too?

[LigH]

Another "weekly": x265 1.3+788-3a8f6f685436 (https://www.mediafire.com/download/l04ia05amurzn97/x265_1.3+788-3a8f6f685436.7z)

[foxyshadis]

New build v1.3+865 (https://dl.dropboxusercontent.com/u/54412753/doom9/x265-1.3%2B865.7z) with new option --deblock that works just like x264's. Now you can test --deblock -1 or -2 and see if that improves film noise. Now's your chance to play with it and see if any bugs are present before the final release. Should be pretty stable, lots of bugfixes have gone into it recently and 1.4 appears to be right around the corner! Speed and quality have both improved since 1.3.

Built with VC12, x64 only, be sure to get the 2013 runtime (http://www.microsoft.com/en-us/download/details.aspx?id=40784) if you don't already have it.

Edit: Stealth update to 1.3+865 with more little bug fixes.

[upyzl]

thx @BadFrame for sharing

for whom want to test PGO vs Normal on Windows (only 64bit, 8bpp):
https://mega.co.nz/#!Z9NDQJrI!yRTwD2BWxA8pA8McfS616f1USPnKtViIoBf3dzQc2bU

compiled by gcc 4.8.3 (msys)
without -march change (for user compatibility)
use --crf 15 --preset slow on a short clip for PGO

I think improve configure to support PGO compile should be better, like x264


BTW, I try to do it by using VS2013pro by following http://msdn.microsoft.com/en-us/library/xct6db7f.aspx "Building an Application with PGO" - Building with PGO at the Command Line (add /GL to CXX_FLAG & C_FLAG and add /ltcg:pgi to EXE_LINKER_FLAG)
but the instrumented exe cannot do encoding (of course no .pdc file created)...

[easyfab]

I try on my I2600K

compiled by gcc 4.9.1 (msys)
source 800*480 600 frames

standard build without -march : 26.5 fps
with -march=corei7-avx -mtune=corei7-avx : 26.8 fps
with -march=corei7-avx -mtune=corei7-avx + PGO : 27.5 fps

~3% better with PGO vs -march alone

[BadFrame]

I think improve configure to support PGO compile should be better, like x264

Yes, it's certainly simpler as it is automated there, just 'make fprofiled <video to be used while profiling>' and wait.

That said I don't know if it affects x264 performance in any real way these days since basically every performance hotspot in x264 has been converted in to highly optimised hand-tuned assembly (which of course the compiler can't improve, PGO or not).


BTW, I try to do it by using VS2013pro by following http://msdn.microsoft.com/en-us/library/xct6db7f.aspx "Building an Application with PGO" - Building with PGO at the Command Line (add /GL to CXX_FLAG & C_FLAG and add /ltcg:pgi to EXE_LINKER_FLAG)
but the instrumented exe cannot do encoding (of course no .pdc file created)...

Sorry, I haven't used VS for ages so I can't really help you there :/ , I just know that it has PGO support (sometimes it's called FDO 'feedback driven optimization' but it means the same thing as PGO 'profile guided optimization'), also the Intel Compiler has PGO support, Clang/LLVM however does not.

[BadFrame]

s
standard build without -march : 26.5 fps
with -march=corei7-avx -mtune=corei7-avx : 26.8 fps
with -march=corei7-avx -mtune=corei7-avx + PGO : 27.5 fps


Just a quick note, -march sets -mtune, so you can drop -mtune from the options when you use -march.

-mtune is meant to be used if you want to make binaries which will work everywhere (well, within the cpu architecture as in 32-bit or 64-bit) but be 'tuned' for a particular cpu architecture, -march however will directly target a cpu architecture and make use of it's cpu specific extensions (sse1-4, avx, etc) which will make the resulting binary incompatible with cpu's that doesn't support those extensions.

[easyfab]

To make PGO building a little more easier than editing CMakeCache.txt and as I'm not a cmake expert I created 2 folders : 1 for -fprofile-generate and 1 for -fprofile-use
and add
SET(CMAKE_C_FLAGS "-O3 -march=corei7-avx -mtune=corei7-avx -DNDEBUG -fprofile-generate -fprofile-dir=xxx " CACHE STRING "c flags" )
SET(CMAKE_CXX_FLAGS "-O3 -march=corei7-avx -mtune=corei7-avx -DNDEBUG -fprofile-generate -fprofile-dir=xxx" CACHE STRING "c++ flags")
... in toolchain folder1 and
SET(CMAKE_C_FLAGS "-O3 -march=corei7-avx -mtune=corei7-avx -DNDEBUG -fprofile-use -fprofile-correction -fprofile-dir=xxx " CACHE STRING "c flags" )
... in toolchain folder2 than a little script:

cd folder1
make-Makefiles.sh && make
x265 ....
cd folder2
make-Makefiles.sh && make

[easyfab]

Just a quick note, -march sets -mtune, so you can drop -mtune from the options when you use -march.

-mtune is meant to be used if you want to make binaries which will work everywhere (well, within the cpu architecture as in 32-bit or 64-bit) but be 'tuned' for a particular cpu architecture, -march however will directly target a cpu architecture and make use of it's cpu specific extensions (sse1-4, avx, etc) which will make the resulting binary incompatible with cpu's that doesn't support those extensions.

Thanks for the note, I will remove -mtune in the future

[upyzl]

Sorry, I haven't used VS for ages so I can't really help you there :/ , I just know that it has PGO support (sometimes it's called FDO 'feedback driven optimization' but it means the same thing as PGO 'profile guided optimization'), also the Intel Compiler has PGO support, Clang/LLVM however does not.
ah... for I did not say clearly, I just show my (should be wrong)way of doing, not your fault

and thx for the info :cool:

[plonk420]

New build v1.3+865 (https://dl.dropboxusercontent.com/u/54412753/x265-1.3%2B865.7z) with new option --deblock that works just like x264's. Now you can test --deblock -1 or -2 and see if that improves film noise. Now's your chance to play with it and see if any bugs are present before the final release. Should be pretty stable, lots of bugfixes have gone into it recently and 1.4 appears to be right around the corner! Speed and quality have both improved since 1.3.
*snip*

thanks! will have to rerip The Game after my current round of encodes to test this out, but very very happy to see this feature! :D

[Kurtnoise]

x265 1.4 is a regularly scheduled release, mostly focused on performance
enhancements. There was a large refactor of the analysis code that
exposed further parallelism without sacraficing any compression
efficiency. In general, 1.4 should have slightly better compression
efficiency than 1.3 for the same encodes.

The refactors also generally lowered the memory requirements and made
the faster presets more compute efficient.

The two most important new features are --pmode (parallel mode decision)
and --pme (parallel motion estimation).

= --pmode : param.bDistributeModeAnalysis =

This feature will distribute mode analysis for each CU. The more modes
that must be analyzed, the more effective this feature becomes. So the
slow preset that enables rectangular prediction modes benefits from
pmode more than medium preset, and the slower modes which use RD level
6 benefit from pmode even more since they enable AMP predictions and
evaluate the rate distortion cost of each mode.

The output of --pmode encodes should have slightly better compression
than those with it disabled, since certain early outs are impossible
with --pmode and thus all modes are measured naievely.

= --pme : param.bDistributeMotionEstimation =

This feature will distribute the motion estimations for each CU that has
more than 2 references. Its effectiveness is proportional to the number
of references, but this feature can often be a net performance loss as
the overhead of involving other CPU cores is often more expensive than
the parallelism benefit.

The output of the encode is completely unaffected by --pme.

Both --pme and --pmode are only useful when x265 is otherwise unable to
fully saturate the CPU cores, and both can also at times result in lower
performance on multi-socket machines (depending on the situation) since
we are not yet keeping work localized to neighbor CPUs.

= Also in 1.4 =

As a result of the refactor work, none of the original HM classes or
source files remain in x265.

Temporal motion vector predictions (previously hard-coded to always be
enabled) are now runtime selectable (param.bEnableTemporalMvp) but still
default to being enabled in all presets.

Frame based SAO analysis was removed (frame based SAO signaling did not
make it into the final HEVC spec), and --sao-lcu-bounds=<0|1> was
renamed to --[no-]sao-non-deblock (param.bSaoNonDeblocked)

Some inconsistencies in the analysis logic were fixed. --amp is now
respected in RD levels 2, 3, and 4 (previously only in 5 and 6).
--b-intra is now respected in all RD levels. --fast-cbf, which has only
ever effective at RD levels 5 and 6, is no longer enabled uselessly in
the fastest presets.

--weightb is now enabled by default at presets slower, veryslow, and
placebo.

--cu-lossless was changed to only attempt a lossless encode of the best
lossy encode method. This made --cu-lossless a much less expensive
encode option to have enabled, and hopefully made the feature more
robust and maintainable.

The upper threshold for --psy-rdoq was raised to 50 (from 10) since the
higher values were found to be beneficial for sources with high
frequency noise (film grain).

The default thread pool size logic was updated to account for the
addition of --pmode and --pme (if WPP is disabled but --pmode or --pme
are enabled, a thread pool is still allocated).

In 1.4 there also appeared an incomplete analysis re-use feature. This
will be completed and further improved in the coming weeks.

......

[foxyshadis]

Scheduling 1.4 for Halloween was awesome. :D

https://dl.dropboxusercontent.com/u/54412753/doom9/x265-jack.png

[filler56789]

build 1.4+5-eebb372eec89 @

http://forum.videohelp.com/threads/357754-%5BHEVC%5D-x265-EXE-mingw-builds?p=2354182#post2354182

[a5180007]

Hi all,

The upper threshold for --psy-rdoq was raised to 50 (from 10)

So what is the recommended --psy-rdoq value for general purpose encoding, is it still 1.0 ?

[davidsama]

That dropbox link gives me a Error (403) message when i click on it.

[LoRd_MuldeR]

So what is the recommended --psy-rdoq value for general purpose encoding, is it still 1.0 ?

The docs still say that "1.0 is a typical value. Default disabled."

Anyway, the commit message says:
api: allow --psy-rdoq values up to 50; it can be beneficial for film grain

See also:
http://x265.readthedocs.org/en/default/cli.html#cmdoption--psy-rdoq

[Romario]

x265 project, please give us OFFICIAL Change Log for 1.4. Thanks.

[lotusgg]

7 posts before. (https://www.doom9.org/showpost.php?p=1698383&postcount=1398)

[fauxreaper]

I'm trying to use x265 to encode still images, using an AVS script + avs4x265, but there's a problem when encoding one image.

The image is http://www.gulfstockphoto.com/downloads/cabs/ , with 3264x2448 pixels.

The AVS script is:

ImageSource("E:\25H.jpg",start=0,end=0,fps=24)
ConvertToYV12()

The command line is:

avs4x265 --preset placebo --crf 25.0 taxi.avs -o taxi.hevc

The x265 version is 1.3+788, 64bit 8bpp.

The output has pink blocks. I tried to decode it using LAV Video Decoder 0.63.0 and the recent version of Strongene Decoder, but the output is the same.

Screenshot taken on MPC: http://imgur.com/dgz08RO

[LoRd_MuldeR]

x265 v1.4, 32-Bit/64-Bit, 8bpp/16bpp:
http://sourceforge.net/projects/muldersoft/files/x265%20HEVC%20Encoder/x265-Windows-VC2013.2014-11-02.zip/download

[LigH]

Me too; nothing special, as usual a simple GCC 4.8.2 build: x265 1.4+5-eebb372eec89 (https://www.mediafire.com/download/g3hkp0po4koa1fm/x265_1.4+5-eebb372eec89.7z)

[YamashitaRen]

Hello,
I'm trying x265 but I have a weird chroma bug ...
There is an x offset in the red? colors.
Look at Rin's pullover : http://screenshotcomparison.com/comparison/98530

x265 version is current git.
x265 input is 16 bit piped y4m.
x265 output is 10 bit.
Preset is slow.
I did the screens with mpv --vo=image.

Any idea ? :)

[mandarinka]

This is probably not x265's fault.

To me it seems that during the decoding step, MPV uses center-mid (MPEG1) chroma placement during conversion to RGB, while for x264-encoded file, the correct MPEG2 chroma positioning is used (which is left-mid). The result is that chroma information is effectively shifted to right for x265's encode.

It could be x265's fault if it incorrectly flags the bitstream, thus making MPV to pick mpeg1 chroma positioning (btw, this might also behave differently based on what you use for rgb conversion - swscale, gpu drivers, MPV's opengl VO etc. --vo image probably uses swscale though).

Anyway, this thing should be introduced when converting 4:2:0 yuv to rgb, so it really shouldn't be x265's doing. It's more likely to be MPV (or swscale) bug. Or you somehow introduced the shift before encoding, but I find that unlikely.

[LigH]

I found that x265 does insert aspect ratio flags in its encoded video streams, but neither MediaInfo (which MPC-HC relies on) nor VLC appear to detect them and therefore don't deskew HEVC video. I created bug tasks in their respective trackers.

[Kurtnoise]

You should post a sample...that helps a lot the developers.

[LigH]

That will follow soon™...

[nevcairiel]

I found that x265 does insert aspect ratio flags in its encoded video streams, but neither MediaInfo (which MPC-HC relies on) nor VLC appear to detect them and therefore don't deskew HEVC video. I created bug tasks in their respective trackers.

MPC-HC doesn't use MediaInfo during playback for Aspect Ratio.

[LigH]

In this case, LAV Filters may be responsible (if used for decoding)? So I'll consider you notified.

Samples: foreman_cif_sar-test.7z (http://www.ligh.de/tmp/foreman_cif_sar-test.7z)

[nevcairiel]

In this case, LAV Filters may be responsible (if used for decoding)? So I'll consider you notified.

Samples: foreman_cif_sar-test.7z (http://www.ligh.de/tmp/foreman_cif_sar-test.7z)

Seems to be working fine during playback.
I get videos scaled to 385:288 (128-117), 384:288 (sar2) and 352:288 (no-ar)

[LigH]

OK, here you are right: Playback of raw *.hevc in MPC-HC 1.7.7 respects the AR; playback of *.mp4 (multiplexed with MP4Box - GPAC version 0.5.1-DEV-rev5261) does not. Maybe I should try again with a nightly MP4Box...

foreman_cif_sar-mp4s.7z (http://www.ligh.de/tmp/foreman_cif_sar-mp4s.7z) — multiplexed with MP4Box - GPAC version 0.5.1-DEV-rev5491: Always SAR 1.0. If MPC-HC prefers container AR flags, then MP4Box will probably not have recognized HEVC AR flags to repeat them in the MP4 container (if the MP4 container supports video stream AR flags at all).

Nevertheless, MediaInfo always reports AR 1.0, for raw *.hevc too. I wonder if L-SMASH supports HEVC AR flags.

[Kurtnoise]

But did you put the sar directly in the command line for the mux or not ?

[LigH]

I did not tell MP4Box manually about an AR, I expected it to detect it from the video stream... :o

[Selur]

*gig* it doesn't, never did :)

[nevcairiel]

OK, here you are right: Playback of raw *.hevc in MPC-HC 1.7.7 respects the AR; playback of *.mp4 (multiplexed with MP4Box - GPAC version 0.5.1-DEV-rev5261) does not. Maybe I should try again with a nightly MP4Box...

foreman_cif_sar-mp4s.7z (http://www.ligh.de/tmp/foreman_cif_sar-mp4s.7z) — multiplexed with MP4Box - GPAC version 0.5.1-DEV-rev5491: Always SAR 1.0. If MPC-HC prefers container AR flags, then MP4Box will probably not have recognized HEVC AR flags to repeat them in the MP4 container (if the MP4 container supports video stream AR flags at all).

Nevertheless, MediaInfo always reports AR 1.0, for raw *.hevc too. I wonder if L-SMASH supports HEVC AR flags.

By default, MPC-HC/LAV will prefer the container AR of MP4 files. You can change that mode by toggling the "Use Stream AR" option in LAV settings.

[Kurtnoise]

Nevertheless, MediaInfo always reports AR 1.0, for raw *.hevc too.
looking at the code, this part is not available yet for hevc streams...That's why it's still 1.0 as default. Maybe I should create a patch for that.

[LigH]

Looking forward to it. :)

At least it was not the fault of x265.

[YamashitaRen]

This is probably not x265's fault.

To me it seems that during the decoding step, MPV uses center-mid (MPEG1) chroma placement during conversion to RGB, while for x264-encoded file, the correct MPEG2 chroma positioning is used (which is left-mid). The result is that chroma information is effectively shifted to right for x265's encode.

You're right. I had trouble playing the hevc stream in vlc but concatenating it in a mkv solved the problem.
The chroma placement is indeed good in vlc so it should be a mpv problem (edit, ffmpeg seems to be the culprit) as you said. Using vo=opengl=chroma-location=left in mpv solved the problem too.
Now i have to fill a bugreport upstream and find how to do my screenshoots until the bug is fixed.

Thank you for the detailed explanation :)

edit : found it !
We can use vapoursynth inside mpv, so I'm using fmtconv to shift the chroma placement from MPEG2 to MPEG1.

[Kurtnoise]

Looking forward to it. :)
Basically, something like that (http://pastebin.com/vfDm2uyk)...

Before applying the patch :
General
Complete name : C:\Users\duchatl\Documents\foreman_cif_sar-test\foreman_cif_128-117.hevc
Format : HEVC
Format/Info : High Efficiency Video Coding
File size : 259 KiB
Writing library : x265 1.4+5-eebb372eec89:[Windows][GCC 4.8.2][64 bit]
Encoding settings : wpp / ctu=64 / tu-intra-depth=1 / tu-inter-depth=1 / me=1 / subme=2 / merange=57 / no-rect / no-amp / max-merge=2 / temporal-mvp / no-early-skip / no-fast-cbf / rdpenalty=0 / no-tskip / no-tskip-fast / strong-intra-smoothing / no-lossless / no-cu-lossless / no-constrained-intra / no-fast-intra / open-gop / interlace=0 / keyint=250 / min-keyint=25 / scenecut=40 / rc-lookahead=20 / bframes=4 / bframe-bias=0 / b-adapt=2 / ref=3 / weightp / no-weightb / aq-mode=2 / aq-strength=1.00 / cbqpoffs=0 / crqpoffs=0 / rd=3 / psy-rd=0.00 / psy-rdoq=0.00 / signhide / lft / sao / no-sao-non-deblock / b-pyramid / cutree / rc=crf / crf=28.0 / qcomp=0.60 / qpmin=0 / qpmax=51 / qpstep=4 / ipratio=1.40 / pbratio=1.30

Video
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main@L2.0
Width : 352 pixels
Height : 288 pixels
Display aspect ratio : 1.222
Frame rate : 29.970 fps
Standard : PAL
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Writing library : x265 1.4+5-eebb372eec89:[Windows][GCC 4.8.2][64 bit]
Encoding settings : wpp / ctu=64 / tu-intra-depth=1 / tu-inter-depth=1 / me=1 / subme=2 / merange=57 / no-rect / no-amp / max-merge=2 / temporal-mvp / no-early-skip / no-fast-cbf / rdpenalty=0 / no-tskip / no-tskip-fast / strong-intra-smoothing / no-lossless / no-cu-lossless / no-constrained-intra / no-fast-intra / open-gop / interlace=0 / keyint=250 / min-keyint=25 / scenecut=40 / rc-lookahead=20 / bframes=4 / bframe-bias=0 / b-adapt=2 / ref=3 / weightp / no-weightb / aq-mode=2 / aq-strength=1.00 / cbqpoffs=0 / crqpoffs=0 / rd=3 / psy-rd=0.00 / psy-rdoq=0.00 / signhide / lft / sao / no-sao-non-deblock / b-pyramid / cutree / rc=crf / crf=28.0 / qcomp=0.60 / qpmin=0 / qpmax=51 / qpstep=4 / ipratio=1.40 / pbratio=1.30


After applying the patch :
General
Complete name : C:\Users\duchatl\Documents\foreman_cif_sar-test\foreman_cif_128-117.hevc
Format : HEVC
Format/Info : High Efficiency Video Coding
File size : 259 KiB
Writing library : x265 1.4+5-eebb372eec89:[Windows][GCC 4.8.2][64 bit]
Encoding settings : wpp / ctu=64 / tu-intra-depth=1 / tu-inter-depth=1 / me=1 / subme=2 / merange=57 / no-rect / no-amp / max-merge=2 / temporal-mvp / no-early-skip / no-fast-cbf / rdpenalty=0 / no-tskip / no-tskip-fast / strong-intra-smoothing / no-lossless / no-cu-lossless / no-constrained-intra / no-fast-intra / open-gop / interlace=0 / keyint=250 / min-keyint=25 / scenecut=40 / rc-lookahead=20 / bframes=4 / bframe-bias=0 / b-adapt=2 / ref=3 / weightp / no-weightb / aq-mode=2 / aq-strength=1.00 / cbqpoffs=0 / crqpoffs=0 / rd=3 / psy-rd=0.00 / psy-rdoq=0.00 / signhide / lft / sao / no-sao-non-deblock / b-pyramid / cutree / rc=crf / crf=28.0 / qcomp=0.60 / qpmin=0 / qpmax=51 / qpstep=4 / ipratio=1.40 / pbratio=1.30

Video
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main@L2.0
Width : 352 pixels
Height : 288 pixels
Display aspect ratio : 4:3
Frame rate : 29.970 fps
Standard : PAL
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Writing library : x265 1.4+5-eebb372eec89:[Windows][GCC 4.8.2][64 bit]
Encoding settings : wpp / ctu=64 / tu-intra-depth=1 / tu-inter-depth=1 / me=1 / subme=2 / merange=57 / no-rect / no-amp / max-merge=2 / temporal-mvp / no-early-skip / no-fast-cbf / rdpenalty=0 / no-tskip / no-tskip-fast / strong-intra-smoothing / no-lossless / no-cu-lossless / no-constrained-intra / no-fast-intra / open-gop / interlace=0 / keyint=250 / min-keyint=25 / scenecut=40 / rc-lookahead=20 / bframes=4 / bframe-bias=0 / b-adapt=2 / ref=3 / weightp / no-weightb / aq-mode=2 / aq-strength=1.00 / cbqpoffs=0 / crqpoffs=0 / rd=3 / psy-rd=0.00 / psy-rdoq=0.00 / signhide / lft / sao / no-sao-non-deblock / b-pyramid / cutree / rc=crf / crf=28.0 / qcomp=0.60 / qpmin=0 / qpmax=51 / qpstep=4 / ipratio=1.40 / pbratio=1.30

[LigH]

Seems to be the required change. OK to reply to the bug report (https://sourceforge.net/p/mediainfo/bugs/877/) with this link?

[Kurtnoise]

sure...no problem.

[Darius510]

I see that handbrake nightly has been updated to x265 1.4, but for the life of me I can't figure out the syntax to use pmode in the extra options field. Can anyone help?

Also, is there ever a chance of x265 supporting continuing a partial encode? It can take hours to encode a video, and if I ever need to reboot, I have to start all over again.

[LigH]

1. If you want to enable "Parallel mode analysis", you probably just have to add: --pmode (it is disabled by default, which is like using --no-pmode).

2. Already discussed many times: The more complex a video format is (with lots of references between many frames, possibly even weighted ones), the harder it would be to store a whole encoder state to continue from any arbitrary position. Continuing from an IDR frame would be possible, but they are sparse. If you already knew that you don't want to encode a whole video before starting, you could of course limit the range to be encoded, and later join the partial results.

[Atak_Snajpera]

I see that handbrake nightly has been updated to x265 1.4, but for the life of me I can't figure out the syntax to use pmode in the extra options field. Can anyone help?

Also, is there ever a chance of x265 supporting continuing a partial encode? It can take hours to encode a video, and if I ever need to reboot, I have to start all over again.

Just use ripbot in distributed encoding mode. In this way you can resume encoding from last encoded chunk.

[Darius510]

1. If you want to enable "Parallel mode analysis", you probably just have to add: --pmode (it is disabled by default, which is like using --no-pmode).

I see the problem now is that even though they patched 1.4 into the codebase two days ago, they havent updated the nightly build DL with that version yet. I tried it with ripbot though and pmode is a solid 10-20% speed boost on my 5820K. Nice! Adding pme slowed things back down a bit, even though pmode itself wasnt fully saturating 100% of the time.

2. Already discussed many times: The more complex a video format is (with lots of references between many frames, possibly even weighted ones), the harder it would be to store a whole encoder state to continue from any arbitrary position. Continuing from an IDR frame would be possible, but they are sparse. If you already knew that you don't want to encode a whole video before starting, you could of course limit the range to be encoded, and later join the partial results.

I don't always know that ahead of time though. Encoding a 2 hour movie at high settings can take 20+ hours even on a overclocked hex-core haswell-E. Some method to manually pause an encode or pick up after an unfortunate crash would be incredibly useful. It doesn't have to be any arbitrary position, just some way to salvage a few hours of encoding if things don't go as planned.

[LigH]

I am not sure if it would be possible to store a kind of "encoder state file" each time an IDR (would be in H.264; there is certainly something alike in H.265) frame is to be encoded, flushing the output and keeping the bitstream byte position; not my depth of insight.

[Darius510]

I am not sure if it would be possible to store a kind of "encoder state file" each time an IDR (would be in H.264; there is certainly something alike in H.265) frame is to be encoded, flushing the output and keeping the bitstream byte position; not my depth of insight.


Couldn't it just scan a partially encoded file and find an appropriate place to pick up?

I dunno, maybe this is a job for a front end and not the encoder itself. I just dunno of any software that allows you to do this with x265 in a sane way. Considering how epic these encodes can be I think it's really important though.

[LigH]

Scanning for the last position of an IDR frame to continue from would take a lot of time too (means, the encoder would have to implement a partial decoder = HEVC parser too). If this feature would ever be implemented, then probably with a saved "last known good" position... IMHO. I am no developer here. But if, then it would have to be done in the encoder, because it needs to seek the output file to that position to overwrite and append from there. A GUI won't be able to support that.

[Darius510]

Roughly how far apart are these frames anyway?

[LigH]

Depends on the distance of scene cuts and the parameters limiting them ... but with defaults, possibly up to 300 frames (~ 10 seconds playback time for NTSC rates).

[Darius510]

Depends on the distance of scene cuts and the parameters limiting them ... but with defaults, possibly up to 300 frames (~ 10 seconds playback time for NTSC rates).

So worst case it would just have to scan the last few megabytes, how bad can that be?

[benwaggoner]

I just noticed a very large and intriguingly named commit: "refine deblocking filter"
https://bitbucket.org/multicoreware/x265/commits/65e14d5a5728a45c0c4ad6a52d2385f1cf47b6f4
Any hints as to what its impact is?

[Selur]

looks like code refactoring, so may be some speed improvement

[x265_Project]

I just noticed a very large and intriguingly named commit: "refine deblocking filter"
https://bitbucket.org/multicoreware/x265/commits/65e14d5a5728a45c0c4ad6a52d2385f1cf47b6f4
Any hints as to what its impact is?
Minor performance improvements, mostly a cleanup. Output is unchanged.

[lotusgg]

How to use deblock?
--deblock=-2
--deblock -2
--deblock=-2:-2 and
--deblock -2:-2 all gives me errors.

edit:
I was using latest stable version(1.4).
I didn't realized it had no deblocking filter yet.
Using 1.4+5 now, but it's too slow. http://prntscr.com/54298r
It usually hits 12fps.

[foxyshadis]

--deblock -2 and --deblock -2:-1 work as expected for me. Make sure you're using a 1.4 build.

[LigH]

sure...no problem.

MediaInfo accepted it.

[lotusgg]

Found a bug when testing anime.
Seems like the --rd 0 part from this cli (http://prntscr.com/54eqks) is making the CTUs go crazy and operate 64x64 only.
http://www.solidfiles.com/d/e2aab668a2/00000_4.hevc

source is 00000.m2ts from this file (http://www.nyaa.se/?page=download&tid=579873).

[a5180007]

Steve Borho on the x265 developers IRC :


2014-11-06 16:57:25 <@muggs> our default AQ mode is 2 (auto-variance); I'm not real convinced this is a good thing

[upyzl]

x265 has introduced --tune grain (http://x265.readthedocs.org/en/default/presets.html#film-grain-retention)

anyone tested? especially retain details compared to x264 :D

(also compiled latest x265 1.4+48: https://mega.co.nz/#F!Nx8GgL6Y!tlxzo_GpGmEhptwa4vKgLw contained 8bpp&16bpp
aims to fastest for me, so Win64 & CPU support AVX is needed)

[uneedme]

run encode in vmware virtual os

feasible to pause anytime

[uneedme]

Couldn't it just scan a partially encoded file and find an appropriate place to pick up?

I dunno, maybe this is a job for a front end and not the encoder itself. I just dunno of any software that allows you to do this with x265 in a sane way. Considering how epic these encodes can be I think it's really important though.

you might run encode in vmware virtual OS

it is feasible to pause anytime

and you are affordable to a little bit efficiency lose

just like hot hibernation mode

[lotusgg]

Tried to simulate this -tune grain here (https://www.doom9.org/showthread.php?p=1699083#post1699083), but without the qcomp adjustments(can't compile, latest posted here is 1.4+5).

[x265_Project]

x265 has introduced --tune grain (http://x265.readthedocs.org/en/default/presets.html#film-grain-retention)

anyone tested? especially retain details compared to x264 :D

(also compiled latest x265 1.4+48: https://mega.co.nz/#F!Nx8GgL6Y!tlxzo_GpGmEhptwa4vKgLw contained 8bpp&16bpp
aims to fastest for me, so Win64 & CPU support AVX is needed)

We're still working to improve how x265 handles film grain. We'll provide an update and suggested settings for grainy material when we're a little further along.

[LigH]

In the meantime, I uploaded x265 1.4+47-1e04e178a349 (https://www.mediafire.com/download/13xxnm6t36kb8bt/x265_1.4+47-1e04e178a349.7z) (Win32/XP+ and Win64/Vista+).

[foxyshadis]

x265-1.4+57 (https://dl.dropboxusercontent.com/u/54412753/doom9/x265-1.4%2B57.7z) (Needs VC12 runtime.) Some interesting experimental changes just since LigH's build: psy-rdo now influences mode decision and bidir decision (which frames to make b-frames and which blocks to use forward references on).

[LigH]

MediaInfo 0.7.71:

...
+ HEVC: Support of Pixel Aspect Ratio in VUI, thanks to Kurtnoise
...

[LigH]

Only loosely related to x265, but probably interesting for cross-platform developers using CMake:

I just renewed my building environment and got some warning from CMake v3.1.0-rc1. Note: CMake is going to disallow uncommon characters in identifiers.

This belongs to a detection in source/cmake/FindVLD.cmake which searches several locations for the installation of the "Visual Leak Detector". It also uses the environment variable in a 64-bit Windows which points at the common installation path of 32-bit applications: %ProgramFiles(x86)%

If such a string is included in a double-quoted string in a CMake script, it may be used as literal, but not as identifier; unfortunately, the function $ENV{} which evaluates its parameter as environment variable uses this rather as identifier than as literal, and you can probably neither escape the parentheses nor "in-string-quote" it.

The current solution is to create CMake script variables with the name of the environment variable as literals, and nest evaluation functions.

I provided a snippet which should become available as patch soon. In the meantime, CMake up to v3.0.2 won't complain (but possibly not find a VLD installation by searching the x86 path).

[NikosD]

Interesting...A little competition
http://labs.divx.com/node/127941

[Sagittaire]

Interesting...A little competition
http://labs.divx.com/node/127941

well not interessing in fact because:

1) DivXHEVC propose just constant quantizer mode or abr 1 pass mode. x264 propose crf mode and abr N pass mode by far better for rate control and metric/visual quality. at same bitrate and comparable speed, x265 outperform DivXHEVC and by far.

2) x265 introduce now HVS psy optimisation and DivXHEVC not. x265 is by far better for grain and detail retention.

3) HEVC is interessing codec with complete functionality but high speed profil for x265 and DivXHEVC don't propose complete functionality. At these high speed for HEVC, H264 produce comparable quality in slow mode. If I want compare HEVC codec, I make comparison with all functionality to have really better codec than H264: imply slow mode for x265 and DivXHEVC.

[lotusgg]

Is it normal to be this slow (http://i.imgur.com/kdGetzT.png)?

[x265_Project]

Is it normal to be this slow (http://i.imgur.com/kdGetzT.png)?
Using --preset veryslow at --crf 15, yes, I'm not surprised. The higher the quality (bit rate), the slower x265 will run, as more bits require more entropy coding (the last step in the compression process) and decoding (to create the reference pictures needed for motion prediction).

[LigH]

Furthermore, setting max. 16 consecutive B-frames and 16 reference frames is "homeopathy" (placebo forte). Presets exist for a specific reason, to suggest sane options in reasonable relations.

[Sagittaire]

Is it normal to be this slow (http://i.imgur.com/kdGetzT.png)?

your setting are simply useless:

1) 16 bframes and 16 ref spend high and really useless time, reduce at 3 pyramidals bframes and 5 refs for exemple.

2) rect and amp are usefull functionality for quality if you compare with really useless 16/16 b/ref.

3) crf 15 is really high quality (something like BD quality). Imply really high bitrate for 1080p source. Really high bitrate imply really heavy CABAC CPU cycle. Use 16/16 b/ref and preset veryslow is simply even more useless at this quality level.

Like Ligh say, if you don't know the utility for each functionality, don't touch the profil ...

[lotusgg]

your setting are simply useless:

1) 16 bframes and 16 ref spend high and really useless time, reduce at 3 pyramidals bframes and 5 refs for exemple.

2) rect and amp are usefull functionality for quality if you compare with really useless 16/16 b/ref.

3) crf 15 is really high quality (something like BD quality). Imply really high bitrate for 1080p source. Really high bitrate imply really heavy CABAC CPU cycle. Use 16/16 b/ref and preset veryslow is simply even more useless at this quality level.

Like Ligh say, if you don't know the utility for each functionality, don't touch the profil ...

I am actually encoding blu-ray, and an anime source to be more specific. 16b/ref has proven to be beneficial to this kind of source, and the point in no-rect no-amp is that its impact in speed is just too high for the little quality gain it provides.

[LigH]

Then you probably missed the warning about "level 5 and NumPocTotalCurr". 16 references are too much to be hardware compliant, whenever a HEVC consumer player may be released.

Furthermore, I doubt that you will recognize any difference between "up to 16 consecutive B frames" (think about the meaning of that video stream attribute) and a sane number at CRF 15, quality-wise. The assertion to be beneficial for cartoon content was probably made in relation to coarser quantizations.

[Sagittaire]

I am actually encoding blu-ray, and an anime source to be more specific. 16b/ref has proven to be beneficial to this kind of source, and the point in no-rect no-amp is that its impact in speed is just too high for the little quality gain it provides.

proven by what? You have test to prove that 16 ref vs 5 ref is more beneficial than rect/amp actived for anime source? IMO it's completely false. Moreover, you make HEVC encoding certainely with higher quality than your H264 BD source (max bitrate is 40 Mbps for BD and you have certainely an H264 source at 20-30 Mbps in average). Your encoding is simply waste of time ... :helpful:

Use simply crf mode at crf 18~20 with slower profil.

[LigH]

Another "weekly" build: x265 1.4+70-27d36c4b4a27 (https://www.mediafire.com/download/6bogkrbaoby1927/x265_1.4+70-27d36c4b4a27.7z); probably interesting: tuned VBV predictor factors.

[lotusgg]

proven by what? You have test to prove that 16 ref vs 5 ref is more beneficial than rect/amp actived for anime source? IMO it's completely false. Moreover, you make HEVC encoding certainely with higher quality than your H264 BD source (max bitrate is 40 Mbps for BD and you have certainely an H264 source at 20-30 Mbps in average). Your encoding is simply waste of time ... :helpful:

Use simply crf mode at crf 18~20 with slower profil.

I'm aiming for near-perfect BD rips, it's improbable the use of crf higher than 16 or anything worse than veryslow.
I did tests in the past about refs and b-frames in anime source, but I lost them.
Well, going to test again.
This time with --preset veryslow --tune grain --crf 15 --bframes 5 --ref 5 --no-b-intra, it's even slower (http://i.imgur.com/8pRbQG6.png).

[LigH]

In general — probably important to know: To get the complete help output, you have to use the following combination now:

--log-level full --help
__

@ lotusgg:

Is it important for you to change the number of B and reference frames, instead of relying on the presets' defaults?

And by the way, did you try enabling parallel motion estimation and mode decision (--pme --pmode)? In contrast to the other parameters you were interested in by now, these may optimize speed in elaborate presets.

But somehow, all your cores appear to be utilized well, already. As if there is something else calculating heavily besides x265.

[lotusgg]

In general — probably important to know: To get the complete help output, you have to use the following combination now:

--log-level full --help
__

@ lotusgg:

Is it important for you to change the number of B and reference frames, instead of relying on the presets' defaults?

And by the way, did you try enabling parallel motion estimation and mode decision (--pme --pmode)? In contrast to the other parameters you were interested in by now, these may optimize speed in elaborate presets.

But somehow, all your cores appear to be utilized well, already. As if there is something else calculating heavily besides x265.

I didn't tried --pme and --pmode because the cores are already on stress, and 98% are of x265 works. 2% are browsers and torrent client.
About specifying the numbers, it is just an habit.

[huhn]

proven by what? You have test to prove that 16 ref vs 5 ref is more beneficial than rect/amp actived for anime source? IMO it's completely false. Moreover, you make HEVC encoding certainely with higher quality than your H264 BD source (max bitrate is 40 Mbps for BD and you have certainely an H264 source at 20-30 Mbps in average). Your encoding is simply waste of time ... :helpful:

Use simply crf mode at crf 18~20 with slower profil.

Japanese anime disc have usually a AVG bit rate of 35 mbit or more a disc with AVG 39 mbit isn't rare at all.

used 8+ ref frames are not that rare in x264 encodes with animes you can see these information at the end of the encode as you most likely better know than me.

[xooyoozoo]

used 8+ ref frames are not that rare in x264 encodes with animes

Doing the same with HEVC invites compatibility problems.

If you tell the x265-cli to conform to any decoder level, it'll cap --ref to 7 or less.

.

edit: But seriously, if you go beyond the well-trodden path, please set the appropriate Profile and Level. Future you and/or customers/friends/family will appreciate it.

[lotusgg]

Seems that the CLI proposed produced slower a bigger output.
http://prntscr.com/57e915
I need to compare screenshots now, but I can't get it out of the ded. server ATM.

[huhn]

Doing the same with HEVC invites compatibility problems.

If you tell the x265-cli to conform to any decoder level, it'll cap --ref to 7 or less.

.

edit: But seriously, if you go beyond the well-trodden path, please set the appropriate Profile and Level. Future you and/or customers/friends/family will appreciate it.

i would use 10 bit anyway so hardware compatibly is nothing i would care about. my point is only that higher ref frames are not that useless.

[foxyshadis]

Yes, it's normal. I'm confused as to why someone would essentially choose preset placebo (other than rect/amp) and CRF 15, and then care about encoding time and file size. It's like the situation with x264 in 2007; we're just spoiled by how much faster CPUs have become in the meantime.

If you care about file size, pick a higher CRF. (Makes a much larger difference than slower settings.) If you care about encoding time, pick a faster preset. If you're blindly bringing your x264 settings over to x265, that's a recipe for disaster, because the CRF scale is quite different, and as you've seen, speed is much slower.

[upyzl]

seems he want to achieve very high quality (~transparency of input) [high priority], then smallest size [medium], last consider encode time for adjust a little params [low]

[kamineko]

So after all the recent and wildly different suggestions, what would be a recommended commandline with the latest x265 development version for

encoding BluRays with archival quality (near-transparent)?
encoding DVDs with archival quality (near-transparent)?


I think it would be beneficial to have different settings for 2D-animated and non-animated, normal content (standard movies or 3D-animation).

I am not striving for perfection, if, let's say, only the trained eye can spot differences under the best of circumstances, that would be good enough for me. It doesn't have to be 100% perfect.

Priorities are

Quality (near-transparency of input)
File size (differences of less than 2% can be disregarded)
Encoding time (preferably > 1 fps on current systems with a Passmark result of 15,000 or more, example Xeon E5 2640)


The whole command line should be robust enough to cope with 95 - 98% of the material, finetuning with something like -tune grain is acceptable. Fiddling with psy values for each different source would not be acceptable, since this would defeat the purpose of a broadly applicable setting.

If anyone is interested, you could also add a recommendation for mobile devices, where the priority list is reversed and the quality needs to be only good enough for a 6" - 10" screen (phone or tablet). Encoding time of at least 6 fps strongly desired here.

[Sagittaire]

I'm aiming for near-perfect BD rips, it's improbable the use of crf higher than 16 or anything worse than veryslow.
I did tests in the past about refs and b-frames in anime source, but I lost them.
Well, going to test again.
This time with --preset veryslow --tune grain --crf 15 --bframes 5 --ref 5 --no-b-intra, it's even slower (http://i.imgur.com/8pRbQG6.png).

Well the problem is that you don't know really how work x265 and certainely x264 too.

1) your (re)encoding at crf 15 with x265 will have bitrate near your H264 BD source. If you want perfect ripp, extract simply the H264 stream from BD ... it will be impossible to do more perfect.

2) crf for x264 don't work like crf for x265. The bitrate scaling is not the same.

3) crf is itself quality level based on quantizer. crf 15 in fast mode will produce equivalent quality at crf 15 in placebo mode. The difference will be simply time encoding and final average bitrate. cfr 15 with 3/5 bframes/ref will produce exactly same final quality for your eyes (and metric too) than 16/16 bframes/ref with simply little higher bitrate (IMO something like <5%).

I repeat: make encoding like that is simply waste of time.

[x265_Project]

First, choose your desired level of quality. There are 2 basic ways to do this. The easiest is to use CRF. Lower CRF=Higher Quality (but larger file sizes). Another way is to use average bit rate (--bitrate). If you use ABR, I would suggest using 2 pass encode (repeat your same command line twice, with --pass 1 on the first pass and --pass 2 on the second pass, and if desired, use --stats on both passes to specify where to write and read the stats file). Both CRF and 2 pass ABR give similar compression efficiency and overall speed. CRF is easier to use while 2 pass ABR gives you control over the resulting bit rate (file size).

Next, you need to need to decide whether you want x265 to take its time, producing more compression efficiency (bit rate at your desired quality level), or if you would like x265 to get the job done faster. This basic speed vs. efficiency tradeoff is why we have 10 performance presets (for example, --preset medium). If you want the smallest file size for your chosen CRF setting (or highest quality for your chosen --bitrate), use the --veryslow preset. If this is too slow for you, use a faster preset (slower, slow, medium, fast, faster, veryfast, superfast, or ultrafast).

[x265_Project]

You'll notice that adding --pme and --pmode can have a very positive effect at higher quality presets, but a negative effect when you're trying to use faster presets. In fact, for most people under most circumstances, --pme will just slow things down at any preset. --pmode will be beneficial at slower presets, but it will slow things down for faster presets.

We are still working to improve how we parallelize and schedule threads, and so we haven't added --pme or --pmode to our performance presets yet. Both functions are safe to use (you'll get identical or nearly identical output to what you would get without them), but only --pmode is likely to help things go faster, and generally the performance benefits from --pmode will diminish with fewer processor cores/threads, or with high pixel resolutions (UHD). To summarize, using x265 v1.4, if you're not encoding UHD/4K, and you have at least a 4 core processor, and you're using higher quality (slow, slower, veryslow) presets, you'll probably see a benefit from adding --pmode to your command line today.

[kamineko]

To summarize, using x265 v1.4, if you're not encoding UHD/4K, and you have at least a 4 core processor, and you're using higher quality (slow, slower, veryslow) presets, you'll probably see a benefit from adding --pmode to your command line today.
Thanks. This is the kind of information I am looking for. What would you recommend as -crf value for the different types of archival? In other words, what would you feel comfortable with for an archival of a BluRay or DVD?

Recommended values differ wildly already for x264; for x265, I have no idea at all.

[LigH]

It is hard to tell for every user because the subjective quality impression is different for people too. Some are satisfied with CRF 18, others complain about visible artefacts and recommend at most CRF 15 for x264.

And it is even harder to rate a relation between x264 and x265. The default values are CRF 23 for x264 and CRF 28 for x265; but that does not mean that the degree of subjective loss is comparable for the majority, because the appearance of artefacts differs, they look "differently annoying".

And it is not guaranteed that the difference of 5 is similar for another range. But if it was the case ... then you should have a quite "transparent" quality already for CRF 20 with x265. But check for yourself. Are you satisfied with CRF 20 or 18 already? Then you will not need CRF 15.

[foxyshadis]

Until you get familiar with your tastes, it's a good idea to make a collection of CRF encodes of 5 minutes apiece: 15, 18, 21, 24, 27.... Trailers are commonly used for this. It could run overnight if you use preset medium or fast, and you can assume a slower preset would be some % smaller. (Might be handy to make a chart of how much you can expect filesize to change, there are no current ones.)

Now, it's no guarantee that one preset's CRF quality will actually be comparable to another preset's CRF quality, but in general it's pretty true. Starting fast and wide should let you quickly home in on roughly where you feel size and quality are an adequate tradeoff, then you can tweak it by going as slow as you can handle to shave a few more percents off.

[Kurtnoise]

Divx265 vs x265, the last comparison (http://labs.divx.com/node/127941)... it seems like this guy doesn't tuned psnr encoding w/ the x264/x265. :rolleyes:

[LigH]

PSNR tuning doesn't make much sense if you are interested in subjectively good results; PSNR is known to be not an optimal metric. But I won't insinuate an attempt to reduce the advantage of competitors... :rolleyes:

[a5180007]

What's surprising in this comparison, is that DivX265 Balanced 8b and 10b are on par quality-wise, whereas x265 fast 10b falls well behind 8b.

[Sagittaire]

Divx265 vs x265, the last comparison (http://labs.divx.com/node/127941)... it seems like this guy doesn't tuned psnr encoding w/ the x264/x265. :rolleyes:

Well this test is correct ... in fast mode with constant quantizer mode ... !!???

Anyway x265 have actually more advanced functionality than DivX265 like crf mode. In fact x265 with crf mode outperform and by far DivX265 in all speed preset mode for metric and for eyes.

[Gravitator]

We continue to wait grain and 2-pass from DivX265 > X265-vs-DivX265 (videohelp.com) (http://forum.videohelp.com/threads/365634-X265-vs-DivX265?p=2357537&viewfull=1#post2357537)

[Kurtnoise]

We continue to wait grain and 2-pass from DivX265 > X265-vs-DivX265 (videohelp.com) (http://forum.videohelp.com/threads/365634-X265-vs-DivX265?p=2357537&viewfull=1#post2357537)
did you read carefully ? It's off-topic here...

[LigH]

Another weekly build: x265 1.4+116-3c6f703f94ea (https://www.mediafire.com/download/u7ad5ewb7b5a58m/x265_1.4+116-3c6f703f94ea.7z)

[oopsipoo]

finally the 5 day retarded rule has passed. anyway, anyone here know how to update the x265 encoder in ripbot?

[vood007]

finally the 5 day retarded rule has passed. anyway, anyone here know how to update the x265 encoder in ripbot?

Replacing the exe´s in "<ripbotdir>\Tools\x265\" while keeping the original names (ie rename your x64 build to "x265_x64.exe") should do the trick.

[oopsipoo]

Replacing the exe´s in "<ripbotdir>\Tools\x265\" while keeping the original names (ie rename your x64 build to "x265_x64.exe") should do the trick.

any idea where i can get the new files from

[HWK]

any idea where i can get the new files from

http://www.mediafire.com/download/u7ad5ewb7b5a58m/x265_1.4%2B116-3c6f703f94ea.7z
or
http://forum.doom9.org/showthread.php?p=1700654#post1700654

[Metaphor]

This very thread.

Look 5 posts up.

:confused:

[lotusgg]

or here (http://builds.x265.eu/).

[oopsipoo]

i did look into that before i registered and waited 5 days!

one of the zip has a ddl, and the other one has 8 and 10 bit.

i is confuse

[LigH]

Weekly: x265 1.4+151-5ee693e4b5fa (https://www.mediafire.com/download/k7i90t6o4rhcd9z/x265_1.4+151-5ee693e4b5fa.7z)

Has a new "cbr" tuning.
__

You are probably interested in the Win32 or Win64 EXE with 8 bit internal resolution. The higher resolution versions need high bitdepth video sources most converters don't provide.

[x265_Project]

Ara Rezaee posted on our x265 Facebook page (https://www.facebook.com/x265project)... x265 has a HUGE banding issue, you guys need to do something about that...
It's probably better to have discussions about technical issues here, where there are other users and experts who provide valuable tips and feedback.

Banding is an issue that is very dependent on the source content and how it was captured and originally encoded/processed by the camera. It shows up in areas of the picture where there are gradual color gradients (a gradual transition from one color to another), particularly in areas with low light levels. It's a challenging problem, as banding is a phenomenon that happens across large areas (spatially), and a video encoder, at its core, is designed to analyze and process video in smaller blocks. HEVC will describe your video using larger 64x64 pixel block sizes, and so there are differences in the way AVC and HEVC encoders handle different types of content. Anyhow, we agree that there is room for improvement in terms of what can be done to reduce banding in HEVC encodes.

Of course, 10-bit color sample depth largely solves the banding problem (and 12 bit puts it to rest entirely). But it's not a simple solution to say "just use 10 bit". Your source content would need to have been captured with 10 bit sample depth. 10 bit capable decoders are harder to find than 8 bit decoders, and 10 bit encoding takes longer than 8 bit.

Ara - it would be best if you could post a sample of your source content and share your x265 settings.

[ara.armagedon]

Ara Rezaee posted on our x265 Facebook page (https://www.facebook.com/x265project)...
It's probably better to have discussions about technical issues here, where there are other users and experts who provide valuable tips and feedback.

Banding is an issue that is very dependent on the source content and how it was captured and originally encoded/processed by the camera. It shows up in areas of the picture where there are gradual color gradients (a gradual transition from one color to another), particularly in areas with low light levels. It's a challenging problem, as banding is a phenomenon that happens across large areas (spatially), and a video encoder, at its core, is designed to analyze and process video in smaller blocks. HEVC will describe your video using larger 64x64 pixel block sizes, and so there are differences in the way AVC and HEVC encoders handle different types of content. Anyhow, we agree that there is room for improvement in terms of what can be done to reduce banding in HEVC encodes.

Of course, 10-bit color sample depth largely solves the banding problem (and 12 bit puts it to rest entirely). But it's not a simple solution to say "just use 10 bit". Your source content would need to have been captured with 10 bit sample depth. 10 bit capable decoders are harder to find than 8 bit decoders, and 10 bit encoding takes longer than 8 bit.

Ara - it would be best if you could post a sample of your source content and share your x265 settings.

Well hello there!

I was playing with the newest version (1.4) for the first time when I ran into this problem, I made 4 samples for you, 1. x264 fastest preset, 2. x264 slowest preset 3. x265 fastest preset and then its slowest preset.

--Now as I dug a little more into the settings I realized that the problem will (almost entirely) be solved if you just change the default aq-mode from 2 to 1 (the strength is dependent on your bit rate).
--------
Here are the samples: (The source is the physical bluray disk)

Godzilla x265 fastest default preset (http://www.mediafire.com/download/kt8upcucwb2z1o9/Godzilla+x265+fastest.mp4)

Godzilla x265 slowest default preset (http://www.mediafire.com/download/1iavx87tfx5s3ps/Godzilla+x265+slowest.mp4)

Godzilla x264 fastest default preset (http://www.mediafire.com/download/60bbyig5vjp4x2b/Godzilla+x264+fastest.mp4)

Godzilla x264 slowest default preset (http://www.mediafire.com/download/bw4gl4x3cxx62b4/Godzilla+x264+slowest.mp4)

As you can see the "x264 slowest" is much better than the x265 when it comes to banding issues, this problem is solvable if you change the default aq-mode to 1 (but sadly that would decrease the quality a bit...)

[xxxxx]

Ara Rezaee posted on our x265 Facebook page (https://www.facebook.com/x265project)...
It's probably better to have discussions about technical issues here, where there are other users and experts who provide valuable tips and feedback.

Banding is an issue that is very dependent on the source content and how it was captured and originally encoded/processed by the camera. It shows up in areas of the picture where there are gradual color gradients (a gradual transition from one color to another), particularly in areas with low light levels. It's a challenging problem, as banding is a phenomenon that happens across large areas (spatially), and a video encoder, at its core, is designed to analyze and process video in smaller blocks. HEVC will describe your video using larger 64x64 pixel block sizes, and so there are differences in the way AVC and HEVC encoders handle different types of content. Anyhow, we agree that there is room for improvement in terms of what can be done to reduce banding in HEVC encodes.

Of course, 10-bit color sample depth largely solves the banding problem (and 12 bit puts it to rest entirely). But it's not a simple solution to say "just use 10 bit". Your source content would need to have been captured with 10 bit sample depth. 10 bit capable decoders are harder to find than 8 bit decoders, and 10 bit encoding takes longer than 8 bit.

Ara - it would be best if you could post a sample of your source content and share your x265 settings.

Finally you respond this issue, it's comes up every month since this makes this superb codec unusable. I make a topic a few months ago you can find some samples there if you interested in.
http://forum.videohelp.com/threads/367339-HEVC-test-samples
I just tested the 1.4 version but the banding is still on.
I really hope you solve this issue soon:)

[ara.armagedon]

Finally you respond this issue, it's comes up every month since this makes this superb codec unusable. I make a topic a few months ago you can find some samples there if you interested in.
http://forum.videohelp.com/threads/367339-HEVC-test-samples
I just tested the 1.4 version but the banding is still on.
I really hope you solve this issue soon:)

Hi! I took a look at your link, It seems that we have found the same solution! change the aq-mode! although can't agree with you on the strength yet, I believe it is highly subjective and is dependent on the bitrate. Anyhow in your last post there, you mentioned yet another problem I've faced... Have you tried 2-pass? that made a big difference for me...

[LigH]

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).

[Atak_Snajpera]

I wonder why aqmode 2 is still default in x265? Even x264 does not use mode 2 by default and as users (me as well)say aqmode 1 gives better subtective quality.

[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

[Boulder]

This question is probably too vague to give a good answer to, but here goes: what features of x264 are still missing or are not at least as good in x265? I'd like to start testing the codec at some point for my OpenELEC media needs but I don't know which things I need to follow more closely before taking the first step.

[jlpsvk]

@Boulder....

I have ended up with OpenELEC 5.0 / KODI 14 with software decoding of HEVC (for now, until GPU with HW HEVC decode will rise up) and using 10-bit x265 1.4.244. At CRF20 it has half the size and for me better quality than x264 at CRF20. :)

[Boulder]

The same/similar settings? I was just reading about the banding issues you reported and thought that there is something to do there in x265. What about encoding performance, how much does the time increase with x265 on your rig at this point compared to x264?

[jlpsvk]

These are my actual encode settings in MeGUI (I replaced EXE and DLL in it with the 10bit recent version):

--preset medium --crf 20.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

So these are very similar to x264 i think. 10bit x265 has NO BANDING issues and I am totally satisfied with that. :)

[lotusgg]

I'm having trouble with color banding with this cli
avs4x265.exe --preset veryslow --crf 16 --tune grain --pmode --pme 00000.avs episode1.hevc
The source is anime blu-ray stream and it's bitrate is 48mbit.
How can I fix the banding and mantain the moving digital grain(just like TV noise pattern) without doubling the size?

Edit:
Forget it, it's actually on the source and I was just refusing to belive.

[Boulder]

What about encoding performance, how much does the time increase with x265 on your rig at this point compared to x264?

Out of interest, I compiled an x265 (64bit, high bit-depth) executable and compared one script I've used (1000 frames, resolution 1280x528). x264 processed about 5.6 fps while x265 managed 1.3 fps. There's room for improvement but it was not as slow as I feared. Switching from preset veryslow to slower speeded things up quite a lot over that 1.30 fps.

I run a decent i5-4670K @ 3.9GHz so it's not the fastest chip there is, there's also a motion-compensated denoising script to slow things down.

[jlpsvk]

Check my x265 settings. :) Raising preset with CRF mode gives only smaller size... (not too much smaller)...with those encode params I am getting about 7-10 fps encode with x265.

[Boulder]

Check my x265 settings. :) Raising preset with CRF mode gives only smaller size... (not too much smaller)...with those encode params I am getting about 7-10 fps encode with x265.Has anyone performed any subjective tests regarding this matter? That is, for the same CRF, do presets in the range slow-slower-veryslow just create an increasingly smaller file with approximately the same quality level?

[oopsipoo]

Regarding banding, could it be a decoder issue?

i have come across an issue where i recoded a 2.5 hour movie with quality 18 (on the scale, i dont know what its called) and default speed. The problem is seek, if i was to jump to anywhere after say 1hour into the movie, ram useage spikes and MPC freezes. this has happened with some other HD videos, but not (as yet) with sd video of long duration.

Just thought i might let you guys know

[lotusgg]

testing on small samples may be better.
Raising CRF and AQ is basic when it comes to "balancing where the bits should be" for better efficiency and visual quality.
Also, psy-rd may hurt color gradients and detail on dark scenes, so I mostly let it at 0 or at a very low value.

[dev0]

I have a question about encode times. I am encoding with x265 for some time now. When doing bluray sources with very slow preset and ~16-17 CRF or 2-pass 8000-10000 kbps, encode speed is around 12-25 times slower than x264. How much this will change before releasing the final version ? Because 4 hour encode vs 100 hours encode is a really big difference.

[Atak_Snajpera]

@dev0
What you do does not make sense. At 8-10mbps even x264 shines. You do not need x265 with insanly slow preset for this task. My advice. Use CQ mode with some reasonable high value (22-24) instead of 2pass. Use default preset.
BTW
So called final realase won't give you big difference in speed.

[jlpsvk]

That encode time at VERY SLOW is normal.

Try this command and you could change the ratefactor.

--preset medium --crf 20.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

[dev0]

That encode time at VERY SLOW is normal.

Try this command and you could change the ratefactor.

--preset medium --crf 20.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

Thanks but this is not acceptable by my eye and is not the quality of output i need.


@dev0
What you do does not make sense. At 8-10mbps even x264 shines. You do not need x265 with insanly slow preset for this task. My advice. Use CQ mode with some reasonable high value (22-24) instead of 2pass. Use default preset.
BTW
So called final realase won't give you big difference in speed.

Thank for your opinion, but i disagree and for me it makes sense. My eye can see difference between 8000 kbps and 16000 kbps encode. Maybe average Joe doesn't see any difference, but i do and people that watch my encodes do too. I didn't ask if it has sense for you. I asked if encode times at that preset will be the same in future or not.
I watched and analysed thousands of x264 encodes, i've encoded hundreds. If you can't see a difference between CRF 22-24 vs CRF 16 then you have a problem with your eyes.

[Atak_Snajpera]

@dev
You did not understand. At high bitrates like yours difference in quality between x264 and x265 is marginal. I do not understand why you use x265 at all! x265 only shines at 4k and very low bitrates. h.265/HEVC standard in general was designed for such high resolutions ( hence default CU=64 ).

Because 4 hour encode vs 100 hours encode is a really big difference.
In this case you are only wasting time, energy and money.

[x265_Project]

That encode time at VERY SLOW is normal.

Try this command and you could change the ratefactor.

--preset medium --crf 20.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
jlpsvk - I wouldn't recommend turning on --pme. At this point, it will probably slow things down. I also don't recommend --psy-rd at full 1.0 strength, but this is a matter of personal taste, and with a higher bit rate it shouldn't cause problems. I wouldn't manually set --frame-threads. On your machine it would probably end up at 3 anyhow, but on many-core servers this setting could restrict performance unnecessarily.

Tom

[foxyshadis]

Unless there's a reason you absolutely have to use HEVC, it would be more useful in this scenario as a nearly-as-good, half-the-size variant. If that isn't useful to you, stick with what's already working well.

Also remember that the slower you go, the less benefits you get. Going from slow to very slow, maybe it's worth the extra hours to save, say, 50 kbps when you're encoding to 500 kbps, but would it ever be worth saving 50 kbps at 16000? It doesn't work exactly like that, but the general principle holds.

[jlpsvk]

@x265_Project
Why not psy-rd 1.0? I am using CRF, and psy-rd and psy-rdoq should be for fine detail retention...or?

[x265_Project]

@x265_Project
Why not psy-rd 1.0? I am using CRF, and psy-rd and psy-rdoq should be for fine detail retention...or?

Personally, I find that lower values of psy-rd (0.2 or 0.3) give the best result at lower bit rates. At more generous bit rates you can use higher values. Psy-rdoq 1.0 should be fine. Feel free to run a couple of experiments to understand the effect of psy-rd and psy-rdoq and what values give you the most optimal result.

Tom

[jlpsvk]

@x265_Project
I am using it for BD backup, now using CRF 20. Is it possible to compare CRF value to x264? i.e. x265 CRF20 = x264 CRF18 or so? :) Not in matter of size and bitrate, but in matter of visual quality. CRF 18 in x264 is considered as almost transparent.

[benwaggoner]

They are ballpark similar, assuming a pretty large ballpark. Maybe +-2? Probably more in some cases. And of course this will vary with content and subjective preferences. I'd say x264 is still somewhat more consistent than x265, although the gap has shrunk a lot.

[dev0]

@dev
You did not understand. At high bitrates like yours difference in quality between x264 and x265 is marginal. I do not understand why you use x265 at all! x265 only shines at 4k and very low bitrates. h.265/HEVC standard in general was designed for such high resolutions ( hence default CU=64 ).


In this case you are only wasting time, energy and money.

You didn't understand, as i said before i didn't ask for anything more than future encode times at settings i mentioned, without your added value... But if you really ask then i will tell you, but i thought it's obvious.. AT THE MOMENT the main reason is space saving, there is NO other reason to use it, period.

[uneedme]

You didn't understand, as i said before i didn't ask for anything more than future encode times at settings i mentioned, without your added value... But if you really ask then i will tell you, but i thought it's obvious.. AT THE MOMENT the main reason is space saving, there is NO other reason to use it, period.

The efficiency will not ameliorate much on the same set, but people's hardware will be geared up gradually. X264 gets its usage popularity over decades. Should not you boost your hardware level, you will not get the results you want. Then you should stick to the x264 by now......

[LigH]

x265 1.4+304-50a2071500dc (https://www.mediafire.com/download/dx28c3g8qzzi1t1/x265_1.4%2B304-50a2071500dc.7z)

CBR is no "tuning" anymore, but a stricter ABR rate control mode. Can be enforced now with separate option "--[no-]strict-cbr". Previously published option "--ratetol" is gone again.

[STaRGaZeR]

What's the reason of the washed out results compared to x264 anyway? Noob here, but doesn't H.265 provide extra compression options on top of what H.264 did? For example, you have much larger transforms at your disposal, but you are not forced to use them. Could x265, by not using some H.265 features, approach the result of x264? Or does the extra efficiency always come together with the washed out look?

Currently x265 reminds me of a more or less pure lowpass filter. Which is nice from a signal processing standpoint, close to no artifacts other than the loss of high frequencies, but not so good as a product to be consumed by the human eye.

[LoRd_MuldeR]

What's the reason of the washed out results compared to x264 anyway? Noob here, but doesn't H.265 provide extra compression options on top of what H.264 did? For example, you have much larger transforms at your disposal, but you are not forced to use them. Could x265, by not using some H.265 features, approach the result of x264? Or does the extra efficiency always come together with the washed out look?

Currently x265 reminds me of a more or less pure lowpass filter. Which is nice from a signal processing standpoint, close to no artifacts other than the loss of high frequencies, but not so good as a product to be consumed by the human eye.

One thing that you have to keep in mind is: video encoding is all about making decisions! That's because there's an infinite number of possibilities to encode the very same source clip. Determining the "best" decision is not trivial at all! There are way too many possible combinations to test them all. So some "smart" heuristics are required. But even if you could test all possible decisions, how do you know which one is the "best"? Simply picking the one that gives the smallest "error" compared to the source clip, e.g. in terms of SAD (Sum of Absolute Differences), is no good idea. That's because the choice that gives the smallest "error" may be extremely expensive, in terms of "bit cost". Consequently, a good encoder needs to find the "best" trade-off between "error" and "bit cost". This is called RDO (Rate Distortion Optimization). Of course this is a computationally intensive task. And here we are not even talking about "Psy" optimizations and the like yet :rolleyes:

All this stuff is extremely complex. It needs years of optimization and fine-tuning, in order to get visually pleasing results. Remember how many years it took to get x264 to the point where it is now! Now, moving to a new compression standard, e.g. from AVC to HEVC, doesn't necessarily mean that you have to re-start everything from the scratch. Still, many of the "optimizations" that have been developed for AVC over all the years can not be applied to HEVC in a "1:1" fashion. Some optimizations may no longer be useful for HEVC, some optimizations may require a major overhaul/re-tuning before they can work with HEVC, and for certain HEVC-specific "challanges" it may be necessary to conceive completely new solutions.

This all doesn't happen in no time! Rome wasn't built in a day... ;)

(BTW: Having "extra compression options" available means that there are even more possibilities that you have to take into account in your decision making. And it means that there are even more ways to shoot yourself in the foot ^^)

[GrandAdmiralThrawn]

Hey,

I just tried to build x265 for the first time, and I have a simple question (I believe it to be simple at least).

Currently, I'm linking x264 against libav at compile time to be able to feed it any kind of input I like. Just like with the precompiled Windows builds available too. I have searched this thread for something similar in x265, but it seems no such option is available yet.

To make this more clear, I am not using x264 as a library, but the command line tool instead, and in the future I'd like to use x265 in the same way.

Some people suggested avs2yuv, I'm guessing to pipe decoded, raw YUV input into the x265 CLI program on Windows. I mean, that's ok I guess, haven't tried that yet.

I would still like to know if the developers are planning to make it possible in the future to link x265 against libav (or ffmpeg) directly, so you can throw pretty much any input video at it without any "unnecessary" glue layers in between?

Thanks!

[LigH]

No affirmative answer from me, I'm no developer, but ... probably yes; in a rather distant future though. First the kernel. I wouldn't expect that before, let's say, version 2.0, in their "progressive milestone" numbering.

For now, go the other way round: Use an ffmpeg which includes libx265.

[LigH]

A really whole lotta patches during the few last days:

x265 1.4+380-9d26082ca7b3 (https://www.mediafire.com/download/5lqoaqjq9j65uq0/x265_1.4+380-9d26082ca7b3.7z)

[GrandAdmiralThrawn]

I'm still happily using x264, so I don't have to hop over to x265 right now. Just curious about the long-term goals, and since x265.org doesn't really have much information, I thought I'd try here and maybe start fooling around a bit with it to check it out.

I guess I'd rather go with avs2yuv instead of linking in the other direction. Hm, may still need to do that on Linux/BSD though, not sure if I wanna do wine+AviSynth+avs2yuv there.

I guess x264 started in the same way, without anything but raw input support, right?

Thanks.

[LigH]

If your video source can be made available in YUV4MPEG format (*.y4m), x265 will prefer that, either as physical file or piped (e.g. out of ffmpeg). Just don't miss the "--y4m" parameter to tell x265 to interpret the header.

[GrandAdmiralThrawn]

My video sources are all files, which will usually be H.264/AVC, VC-1 or MPEG-2. Rarely anything else.

I haven't considered pipes though.. So I could just decode with the ffmpeg command line tool, and pipe its y4m output directly into x265, and it will get the relevant information from the y4m header?

Like frame rate, resolution, progressive/interlaced, etc?

[LigH]

That's the plan, and it already works this way in many cases, e.g. also in the "Hybrid" cross-platform video converter GUI by Selur.

[qyot27]

I guess x264 started in the same way, without anything but raw input support, right?
It would have, yes, but it also added alternative inputs really early on. AVI and AviSynth were added in March 2005, yuv4mpeg was added in March 2006, the rewritten AviSynth input was committed in October 2009, and FFMS and LAVF input were committed together in January 2010. In February 2013, the AviSynth input was extended to allow using AvxSynth on Linux and OSX.

x265's commit log starts in March 2013, which was 22 months ago. x264's SVN commit log begins in June 2004 (the CVS history is probably lost to the mists of time), so by the 22-month mark, it already supported AVI, AviSynth, and y4m.

But you also have to account for x265 having different development priorities. High bit depth was made available in x265 at an extremely early stage, it took years to get >8bit in x264.

[mandarinka]

Note that x265 really wants to run in x64 mode, which would make real avisynth support a bit limited in usefulness.

Using avs2yuv is easy enough and doesn't have much downsides, so I can understand why the dev team doesn't explore native avisynth support.

[x265_Project]

What's the reason of the washed out results compared to x264 anyway? Noob here, but doesn't H.265 provide extra compression options on top of what H.264 did? For example, you have much larger transforms at your disposal, but you are not forced to use them. Could x265, by not using some H.265 features, approach the result of x264? Or does the extra efficiency always come together with the washed out look?

Currently x265 reminds me of a more or less pure lowpass filter. Which is nice from a signal processing standpoint, close to no artifacts other than the loss of high frequencies, but not so good as a product to be consumed by the human eye.
Can you share your command line?

To increase the retention of spatial detail, add --psy-rd 0.3 --psy-rdoq 1.0 to your command line. You can experiment with higher psy-rd and psy-rdoq strengths, but at some point (depending on the bit rate and other settings), if psy-rd strength is set too high you may notice temporal artifacts (the movement/position of objects is no longer accurate). A reasonable level of psy-rd will counteract the natural tendency of the encoder to low-pass filter the content.

[jlpsvk]

@STaRGaZeR
Yes....do what x265_Project says. :) And don't forget to put --rd 4 to command line, as it's needed for --psy-rdoq.

[x265_Project]

@STaRGaZeR
Yes....do what x265_Project says. :) And don't forget to put --rd 4 to command line, as it's needed for --psy-rdoq.

You would only need to add --rd 4 if you were running --preset medium or a faster preset (fast, faster, etc.)... but this would slow down a faster preset considerably, so you might as well use --preset slow.

[foxyshadis]

One thing that you have to keep in mind is: video encoding is all about making decisions! That's because there's an infinite number of possibilities to encode the very same source clip. Determining the "best" decision is not trivial at all! There are way too many possible combinations to test them all. So some "smart" heuristics are required. But even if you could test all possible decisions, how do you know which one is the "best"? Simply picking the one that gives the smallest "error" compared to the source clip, e.g. in terms of SAD (Sum of Absolute Differences), is no good idea. That's because the choice that gives the smallest "error" may be extremely expensive, in terms of "bit cost". Consequently, a good encoder needs to find the "best" trade-off between "error" and "bit cost". This is called RDO (Rate Distortion Optimization). Of course this is a computationally intensive task. And here we are not even talking about "Psy" optimizations and the like yet :rolleyes:

All this stuff is extremely complex. It needs years of optimization and fine-tuning, in order to get visually pleasing results. Remember how many years it took to get x264 to the point where it is now! Now, moving to a new compression standard, e.g. from AVC to HEVC, doesn't necessarily mean that you have to re-start everything from the scratch. Still, many of the "optimizations" that have been developed for AVC over all the years can not be applied to HEVC in a "1:1" fashion. Some optimizations may no longer be useful for HEVC, some optimizations may require a major overhaul/re-tuning before they can work with HEVC, and for certain HEVC-specific "challanges" it may be necessary to conceive completely new solutions.

This all doesn't happen in no time! Rome wasn't built in a day... ;)

(BTW: Having "extra compression options" available means that there are even more possibilities that you have to take into account in your decision making. And it means that there are even more ways to shoot yourself in the foot ^^)
I'm kind of sick of this apologetic "it's super hard, just keep waiting!" explanation every time someone compares it to x264, when it'd be more useful to just recommend when to use x264 and how to get the most out of x265 while it is what it is. x264 didn't need years of tuning, it needed months from the introduction of its psy algorithms (aq and later psy) to mostly perfect them while x265 got to practically start with them. The years in between were mostly lack of interest. Further visual tuning isn't a given, it may never happen, since speed, memory size, and code quality are the primary goals of x265 right now. We have to evaluate the encoder as it is, not as we hope it might be someday.

I don't blame them for focusing on speed, though. That'll bring more users and more benefits to current users than a bit more detail at medium sizes.

[Tommy Carrot]

I don't blame them for focusing on speed, though. That'll bring more users and more benefits to current users than a bit more detail at medium sizes.

I'm not sure i agree. If the visual quality is not convincingly better, what's the incentive to use x265 anyway? Doesn't matter how much they improve the encoding speed, it'll still be much slower than x264, not to mention you can play h.264 basically on anything.

I believe improving the visual quality should be the most important objective. Once they conclusively beat x264 on all bitrate range, then should they spend more effort on speed optimization.

[x265_Project]

Encoding video ALWAYS involves a trade-off between efficiency and speed. Wherever you want to be on this curve, we want x265 to be the encoder of choice.

Foxyshadis - Encoding efficiency (visual quality at any target bit rate) has always been our #1 priority. It will always be our #1 priority. We want to produce the encoder that people want to use over all possible alternatives - because it produces the best encodes. So we're always working on improving encoding efficiency.

Producing the fastest encoder at any target efficiency level is our next priority. Whether you need our encoder for offline or real-time applications, everyone who uses x265 wants it to faster... much faster. We've got many parallel efforts underway to improve performance. Some people will see these performance improvements and choose to run with higher quality settings, so in some ways performance equals quality.

Lord Mulder - You're right, x265 had the advantage of using x264 (and the HM) for a head start, and this certainly helped us add valuable features much faster than we otherwise would have been able to do. But the x265 project is different than the x264 project in a number of ways. The key difference is that x265 is backed by a commercial company with multiple commercial customers funding the effort at a very significant level right from the start. This investment has enabled us to put a very large team together, greatly accelerating the pace of development. So although HEVC is significantly more complex than AVC, I think the pace of x265 development is faster than what the very talented x264 team was able to do in the early years.

x265 will celebrate it's 2nd birthday in March this year, while many of our competitors have been working on their HEVC encoders for more than 4 years. But we're getting very positive feedback from our customers and prospective customers, who tell us that we're winning the head to head shootouts against our competition.

We owe much of our success to the x264 team, both for the fantastic code base that we were able port to x265, and for their help and guidance along the way. Being open source is a key advantage. Our code is reviewed and we receive suggestions and patches from experts worldwide. Customers know that x265 is by far the most widely used HEVC encoder, and so any bugs are more likely to be found and reported, leading to a more robust encoder than commercial implementations. We have the x264 team (and VideoLAN, FFMPEG, etc) to thank for building a great reputation for open-source encoders, and for showing us the way.

[Boulder]

Foxyshadis - Encoding efficiency (visual quality at any target bit rate) has always been our #1 priority. It will always be our #1 priority. We want to produce the encoder that people want to use over all possible alternatives - because it produces the best encodes. So we're always working on improving encoding efficiency.
From what I've read and experienced myself while testing (very small tests), there seems to be a great difference between x264 and x265 what comes to retaining the noise etc. that is in the source.

I am not sure whether it is intentional, that is, people want to see a clean image instead of the analog or digital noise, or not, but it is clearly one thing which is keeping me from using x265 for now. I posted my examples in this post: http://forum.doom9.org/showthread.php?p=1705500#post1705500. Due to this, it's difficult to compare how well x265 compares to x264 regarding the actual efficiency. What I mean is to test "Can I use the same CRF value in x265 and not notice the difference to x264 and save NAS diskspace".

I have not experimented with the psy-rd or psy-rdoq options at this point. In my opinion they should be implemented in tunings like x264 does, because most of the users (including myself) should not touch the parameters at all. I also do not want to tune the parameters according to the source every time I encode something as x264 doesn't require that to provide good quality results.

Please don't mistake my post as a rant - I am merely presenting some opinions and wish to hear if there are any possibilities to improve things in the near future. I am very hopeful that x265 will be my encoder of choice at some point.

[LigH]

When comparing different video encoding algorithms, never forget: They are different. They have different purposes. It is no surprise that they create different results. There are different optimal algorithms for different purposes.

HEVC was mainly developed to be able to broadcast UHD resolutions via DVB. Video complexity must be reduced, details must vanish to achieve this goal. Any HEVC encoder will try its best to make the loss as little annoying as possible, but the bandwidth is limited, and you can't fool Claude Shannon's laws of information and entropy. Video compression is a compromise, not magic.

[Boulder]

That is what I "feared". There is no free lunch and in this case your lunch is paid by the detail loss.

Maybe the x265 team should bring this thing more to the front, the name itself implies that it is a successor to x264 while it is more like a step-brother. Of course, I understand the small Spinal Tap analogy there also is but anyone who knows the movie, knows what that means :D

However, at some point commercial encodes might not require this detail loss, especially if 4K wants to get to our home theatres to replace Blu-rays etc.

[x265_Project]

Yes, I think we're getting to the point where we will be able to add --psy-rd and --psy-rdoq to the x265 performance presets, which should mean that for most presets, as with x264, psycho-visual optimizations will be on by default. We wanted to wait until we had stabilized the algorithms, and then we needed to do assembly-code optimizations in order to insure that they don't slow down encodes too much.

[STaRGaZeR]

Can you share your command line?

To increase the retention of spatial detail, add --psy-rd 0.3 --psy-rdoq 1.0 to your command line. You can experiment with higher psy-rd and psy-rdoq strengths, but at some point (depending on the bit rate and other settings), if psy-rd strength is set too high you may notice temporal artifacts (the movement/position of objects is no longer accurate). A reasonable level of psy-rd will counteract the natural tendency of the encoder to low-pass filter the content.

I'm just messing around with several options at the moment, thanks for the suggestions.

The point of my post was that if someone had tested which options or which methods only available in HEVC give x265 its characteristic lowpass look. For example:

- More intra decision modes in HEVC vs. AVC: unlikely this would cause any washout.

- Transforms: HEVC has 4x4, 8x8, 16x16 and 32x32 transforms, AVC only 4x4 and 8x8. The bigger the transform, potentially the more washed out result. Has anybody tried to limit x265 to 8x8 transform size, if that's even possible, and see what happens? Compression efficiency would suffer for sure, but what about the image quality? I haven't seen such tests in the forum.

- The same with any other improvement in HEVC vs AVC.

[benwaggoner]

When comparing different video encoding algorithms, never forget: They are different. They have different purposes. It is no surprise that they create different results. There are different optimal algorithms for different purposes.
For different kinds of problems perhaps. But in the same class you get new algorithms that replace old ones by being better at everything. An optimal .7z LZMA2 is always smaller than an optimal a .zip Deflate file other that compatibility with stuff that can only open .zip.

I anticipate that HEVC encoders will pass the point where they always look at least as good as H.264 encoders at the same bitrate, and generally a lot better at typical bitrates. Including in detail preservation.

HEVC was mainly developed to be able to broadcast UHD resolutions via DVB. Video complexity must be reduced, details must vanish to achieve this goal. Any HEVC encoder will try its best to make the loss as little annoying as possible, but the bandwidth is limited, and you can't fool Claude Shannon's laws of information and entropy. Video compression is a compromise, not magic.
DVB may have been a scenario but certainly wasn't the primary one, if there even is one. HEVC is designed to scale from lossless archival files to <100 Kbps streams for mobile devices. It's scenarios are a slight superset of H.264.

Also, the Shannon limit only applies to lossless encoding (CABAC in H.264 and HEVC). There's no equivalent theoretical maximum for bitrate required for a given psychovisual experience. If my career has taught me one thing, is that over the long term codecs get better than I imagined was possible. <1 bbp was considered crazy talk once upon a time. Moore's Law is a wonderful thing.

By the time I retire I expect we can deliver the same quality as we have today at <<25% of current best bitrates.

In no way is HEVC designed or constrained to preserve less detail than H.264. It's just that H.264 encoders have many more years of refinement behind them. Certainly x265 today handily outperforms x264 when it was the same age.

[Tommy Carrot]

In no way is HEVC designed or constrained to preserve less detail than H.264. It's just that H.264 encoders have many more years of refinement behind them. Certainly x265 today handily outperforms x264 when it was the same age.

I think the reason some of us is a bit 'sceptical' about x265 is because the efficiency/visual quality just hasn't improved for a long time. When i compare the quality of the latest build to several month old ones, it just isn't conclusively better (with the psy-rd off, it often loses to more than a year old builds). I get that improving the visual quality of something as complex as HEVC is a very difficult task, but x264 was always steadily improving quality-wise in the first few years (albeit from a lower starting point).

[Asmodian]

I think the reason some of us is a bit 'sceptical' about x265 is because the efficiency/visual quality just hasn't improved for a long time. When i compare the quality of the latest build to several month old ones, it just isn't conclusively better (with the psy-rd off, it often loses to more than a year old builds). I get that improving the visual quality of something as complex as HEVC is a very difficult task, but x264 was always steadily improving quality-wise in the first few years (albeit from a lower starting point).

I am not sure I agree with that, my memories of the beginning years of x264 involve a lot of people worried about detail loss compared to Xvid. We also thought x264 might never be able to keep detail as well as Xvid. If is funny how these x265 vs x264 comparisons seem almost identical to how I remember the early x264 vs Xvid comparisons. Déjà Vu ;)

How many years did it take x264 to be better than Xvid at all bitrates? I remember long periods of only speed improvements for x264 as well.

[poisondeathray]

I am not sure I agree with that, my memories of the beginning years of x264 involve a lot of people worried about detail loss compared to Xvid. We also thought x264 might never be able to keep detail as well as Xvid. If is funny how these x265 vs x264 comparisons seem almost identical to how I remember the early x264 vs Xvid comparisons. Déjà Vu ;)

How many years did it take x264 to be better than Xvid at all bitrates? I remember long periods of only speed improvements for x264 as well.

I agree completely! Very close similarities.

Also with RMVB. Both h264 and RMVB in those early days had that "plastic doll" look

Remember how slow AVC was for both decoding and encoding compared to xvid? That was even before dual cores

There was no benefit to switching from xvid those early days

[Tommy Carrot]

I am not sure I agree with that, my memories of the beginning years of x264 involve a lot of people worried about detail loss compared to Xvid. We also thought x264 might never be able to keep detail as well as Xvid. If is funny how these x265 vs x264 comparisons seem almost identical to how I remember the early x264 vs Xvid comparisons. Déjà Vu ;)

How many years did it take x264 to be better than Xvid at all bitrates? I remember long periods of only speed improvements for x264 as well.
Sure, it couldn't compete with xvid for a long time, but as far as i remember it always improved bit by bit. I don't think there was such a long period of time when the efficiency/quality didn't improve at all.

[benwaggoner]

I think the reason some of us is a bit 'sceptical' about x265 is because the efficiency/visual quality just hasn't improved for a long time. When i compare the quality of the latest build to several month old ones, it just isn't conclusively better (with the psy-rd off, it often loses to more than a year old builds). I get that improving the visual quality of something as complex as HEVC is a very difficult task, but x264 was always steadily improving quality-wise in the first few years (albeit from a lower starting point).
I've found x265 get a LOT better over the last 12 months for some core scenarios of interest to me.

For example, UHD encoding of film content. Quality of encodes with heavy grain are enormously better than even three months ago with the addition of --tune grain and other lower-level improvements.

I find x265 very consistently produces substantially higher quality than x264 at the same bitrate for UHD resolutions.

[easyfab]

Ok x265 can greatly improve in future but is there also possible that H.264/x264 encoder can improve (a little) more, like mp3/lame years latter. I know x264 team doesn't commit quality improvement recently but in theory could quality be even better than current placebo preset ? is there some new approach/method from newer standard than can be backport without breaking H.264 compatibilty?

[Tommy Carrot]

I've found x265 get a LOT better over the last 12 months for some core scenarios of interest to me.

For example, UHD encoding of film content. Quality of encodes with heavy grain are enormously better than even three months ago with the addition of --tune grain and other lower-level improvements.

I find x265 very consistently produces substantially higher quality than x264 at the same bitrate for UHD resolutions.

I guess x265 benefits from the larger transform sizes the most for very high resolution content, so it's quite possible that it's capable of beating x264 there, but for usual SD/HD content, they have much lesser effect, that's why x265 is less impressive there. Things like --tune grain helps a bit in some cases, but not enough to beat x264.

I've tested x265 mainly on dvd sources, 720p videos and a few short 1080p samples (i'm using veryslow and placebo presets because i'm currently interested in what's the maximum quality/efficiency x265 is capable of, and these are very slow at higher res). And in my tests, unfortunately i didn't see any real improvement in quality for a long time.

[x265_Project]

I guess x265 benefits from the larger transform sizes the most for very high resolution content, so it's quite possible that it's capable of beating x264 there, but for usual SD/HD content, they have much lesser effect, that's why x265 is less impressive there. Things like --tune grain helps a bit in some cases, but not enough to beat x264.

I've tested x265 mainly on dvd sources, 720p videos and a few short 1080p samples (i'm using veryslow and placebo presets because i'm currently interested in what's the maximum quality/efficiency x265 is capable of, and these are very slow at higher res). And in my tests, unfortunately i didn't see any real improvement in quality for a long time.
I wouldn't interpret Ben's comments to mean that x265 is only beneficial at UHD resolutions. We see consistent benefits over H.264 encoders at all resolutions for all types of content.

The big difference between what you are doing and what Ben is doing is that a professional over-the-top streaming video service will typically receive a very high quality (lossless or near-lossless) version of each title. We work with movie studios and streaming movie services, and we often receive samples of the content they are encoding. Typically these are either very high bit rate ProRes encodes (very little compression) or losslessly encoded files (JPEG-2000 lossless still image sequence). The quality of these source files is astonishing. The file size is also astonishing.

With source content compressed (with MPEG-2 or H.264) to consumer bit rates, you will be feeding x265 a distorted version of the original. Although you can compare different encoders this way, it's not ideal, as x265 will not have the level of spatial detail and motion accuracy needed to do accurate motion-compensated prediction (where encoders get the vast majority of their efficiency). In effect, x265 will be trying to accurately encode all of the artifacts left by the first encoding process. If you want to run some x264 vs x265 comparison tests at lower bit rates, it would be best to start with higher quality material (either high bit rate content in a camera format like DV or AVCHD, or uncompressed source from a site like media.xiph.org (http://media.xiph.org/)). A Blu-ray rip wouldn't be a bad source, as it is fairly high bit rate. But the best source for testing encoders is a high quality scanned image sequence from analog film or an acquisition format straight from a high quality video camera (HDCAM SR, HDCAM, DVCPRO HD 100, XDCAM HD, XDCAM, XAVC, HDV, AVCHD, etc.).

[Tommy Carrot]

I'm using lossless y4m samples (from xiph.org and from some other sources) and fairly high quality VOBs. I don't think the quality of the sources is the problem here. X265 is artifact-free, but the fine details are smoothed out, the video looks "too clean", as Stargazer said, almost like a low-pass filter. X264 has some artifacts, but it preserves the fine details better.

Of course there are some instances where x265 is better, like cartoons (where the lack of ringing is a huge asset), or very low bitrate encodings, or, as Benwaggoner said, 4k content, but for ordinary uses, i cannot say that to be true.

But anyway, that's not my point. I'm perfectly fine with the fact that x265 in this phase cannot beat x264 in every circumstances. My issue is the lack of improvements in visual quality. I see in the changelog that x265 is very actively developed, there are hundreds of commits every week, but still, when i compare the latest build with the older ones, the quality just doesn't seem to be improving. It seems most of the efforts are going for speed/memory optimizations. Which are very good, no doubt, but i think if you want x265 to be widely used, it needs to beat x264 convincingly, so in my opinion quality/efficiency improvements should be the main priority.

[x265_Project]

I'm using lossless y4m samples (from xiph.org and from some other sources) and fairly high quality VOBs. I don't think the quality of the sources is the problem here. X265 is artifact-free, but the fine details are smoothed out, the video looks "too clean", as Stargazer said, almost like a low-pass filter. X264 has some artifacts, but it preserves the fine details better.

Of course there are some instances where x265 is better, like cartoons (where the lack of ringing is a huge asset), or very low bitrate encodings, or, as Benwaggoner said, 4k content, but for ordinary uses, i cannot say that to be true.

But anyway, that's not my point. I'm perfectly fine with the fact that x265 in this phase cannot beat x264 in every circumstances. My issue is the lack of improvements in visual quality. I see in the changelog that x265 is very actively developed, there are hundreds of commits every week, but still, when i compare the latest build with the older ones, the quality just doesn't seem to be improving. It seems most of the efforts are going for speed/memory optimizations. Which are very good, no doubt, but i think if you want x265 to be widely used, it needs to beat x264 convincingly, so in my opinion quality/efficiency improvements should be the main priority.
Hi Tommy - sorry if I misunderstood how you're doing your tests. Certainly, H.265 is a very different coding method than H.264, and we're working with larger block sizes which could have more of a tendency to reduce detail than smaller block sizes. But I think if you're using a sufficient psy-rd strength (at least 0.3), you shouldn't see any lack of detail vs. x264. Let us know if this is not the case.

[Boulder]

To me it seems that --tune grain brings x265 closer to x264 what comes to detail retention. I tested --psy-rd 0.3 --psy-rdoq 1.0 shortly with my Hot Fuzz sample but it still showed a too clean image compared to x264.

[jlpsvk]

Try --psy-rd 0.5 and --psy-rdoq 5.0, looks much better I think.

[LigH]

Coming x265 versions will support zones for bitrate distribution tuning:

--zones startframe,endframe,{q=quant|b=bitrate_factor}[/…]
__

HEVC (https://www.mediafire.com/#6lfp2jlygogwa) / x265 1.4+417-a0c084eff60f (https://www.mediafire.com/download/v5qebxazcb96eqv/x265_1.4+417-a0c084eff60f.7z)

[VelleX]

i agree to Boulder

I downloaded a lossless y4m 2160p50 sample and encoded it to 1080p50 with x264 and x265.
x264 with crf22 still has more grain at almost same bitrate than x265 with crf20 --veryslow --tune grain (which results in psy-rd=0.50 / psy-rdoq=30.00)

Also tested with my 300 Bluray with about the same result. x265 image is too clean compared to x264.

[benwaggoner]

i agree to Boulder



I downloaded a lossless y4m 2160p50 sample and encoded it to 1080p50 with x264 and x265.

x264 with crf22 still has more grain at almost same bitrate than x265 with crf20 --veryslow --tune grain (which results in psy-rd=0.50 / psy-rdoq=30.00)



Also tested with my 300 Bluray with about the same result. x265 image is too clean compared to x264.


Can you share the command lines you used for each?

And also a link to the source, if you can share that.

For noisy UHD content, I've found --pay-rd 1.0 can work better at UHD frame sizes.

Also, tune-grain is for quite noisy content, it's not the equivalent of x264 --tune film. Which would be a great addition to x265...


-Ben Waggoner (via TapaTalk)

[stax76]

I just wanted to let everybody know that StaxRip's x265 support is now completed
with 80+ GUI supported switches, it has an edge over MeGUI here. :D

http://forum.doom9.org/showthread.php?p=1707154#post1707154

[LigH]

Well, nice, but ... which x265 version do you refer to? Tomorrow there may be 2 or 3 different switches, who knows. ;)

But glad to see you are (still|again) in business. :)

[stax76]

Well, nice, but ... which x265 version do you refer to? Tomorrow there may be 2 or 3 different switches, who knows.

There is a apps dialog that lists all apps with version, I thought it would be interesting for people to know exactly what's in so for x265 currently it displays '1.4+285 - MSVC 1800 - x265.ru' and includes 4 different builds 64/32/10/8 bit, that what requested a lot. It's easy to replace the included build, the x265 page in the apps dialog has a toolbar button to open the folder where it's located, once it's replaced with identical filename StaxRip will report an issue because it validates it's date but there is a hidden feature, F12 (documented with F1) brings up a input box to modify the version string and update the stored date.

Once the GUI was completed I've saved the documentation it was based on (http://x265.readthedocs.org/en/default/cli.html) so I can use a diff tool to catch changes. Changing my code then will be simple because everything related to a switch is defined in one place, GUI, command line and help are then generated and wired together automatically. I hope to get some feedback about changes and issues and that it's not too limiting the GUI is built dynamically/automatically and not handcrafted, the x264 GUI looks good but was tedious to build with a lot more code, 5000 lines code for 66 switches, every switch has code in 8 different locations, compared to 1500 lines code for 80 switches with every switch defined in one place for x265. Building a complete handcrafted GUI with that many switches would be a boring to death task.

But glad to see you are (still|again) in business.

Glad to see many doom9 veterans still around too. :)

[Kurtnoise]

It's useless imo to give access to all available switches. This is not a job for a GUI in this case. There are presets for that. That's more simple. Period.

Also,
I thought it would be interesting for people to know exactly what's in so for x265 currently it displays '1.4+285 - MSVC 1800 - x265.ru' and includes 4 different builds 64/32/10/8 bit, that what requested a lot.
Really ? Give me a link for that or a reference please...just curious because, I'm pretty sure that people don't know exactly what this entry ['1.4+285 - MSVC 1800 - x265.ru'] means. Even if they know, it's not useful for encoding.

Moreover, if some people create some builds within 12/16 bits support, do you think you will add them alsot ? Come on, it's a wasting time.

[LigH]

Another weekly build: x265 1.4+424-2b93cf2a5ac8 (https://www.mediafire.com/download/dqcy6bc746fnmf2/x265_1.4+424-2b93cf2a5ac8.7z)

[stax76]

@Kurtnoise

Not all of this makes sense to me either but I acknowledge it might make sense to somebody else and as long as it don't hurt me I let everybody use there bits, switches, GUI, religion or whatever. Glad to see you still around too btw. though I've seen you in better mood before.

[Carpo]

How viable would you say x265 is at this time for replacing x264 for use in a personal backup work flow? I see some companies are already using it for some streams/videos, or would you be better of waiting for a few present/up coming options to be tweaked first?

I haven't looked too deeply into it yet, but did a quick test with a music video from my of my dvd's (it's short and doesn't take long to encode, even when using QTGMC) and it did look cleaner with better colour's, to my eyes anyway, is two pass implemented yet, if not any idea of when that might be?

[Farfie]

Hey there,
Using the build from builds.x265.eu, from the 25th of this month, x64 10bit:
As the scene pans down, follow the text as it crosses from the wall to the floor. This was --preset veryslow --psy-rd 1.2
https://mega.co.nz/#!aVV1WRiB!YK87AIHylNi81wODJYbqh1aHRyPh7-3JMPBLY_mmGxI

Of course, even x264 still does this to a degree, but it looked particularly bad at one point.

Cheers.

[Ge'in]

Your psy-rd value is too high at this low bitrates.
Try with lower value, something around 0.3-0.5

[foxyshadis]

How viable would you say x265 is at this time for replacing x264 for use in a personal backup work flow? I see some companies are already using it for some streams/videos, or would you be better of waiting for a few present/up coming options to be tweaked first?

I haven't looked too deeply into it yet, but did a quick test with a music video from my of my dvd's (it's short and doesn't take long to encode, even when using QTGMC) and it did look cleaner with better colour's, to my eyes anyway, is two pass implemented yet, if not any idea of when that might be?

The lower you want to push the bitrate, the more useful it'll be to you. If you're looking for visually identical to the source, my experience is that they both take up a lot of room to get there. If you're looking to save a lot of space and don't mind some artifacts, especially for HD, x265 will let you go a lot lower to look similar.

[Farfie]

Your psy-rd value is too high at this low bitrates.
Try with lower value, something around 0.3-0.5

Using .5 helped a lot, I didn't know these options mingled like this, but I'd still say it has a ways to go. Thanks though, seems like the x264 days will haunt me forever. :thanks:

[Carpo]

The lower you want to push the bitrate, the more useful it'll be to you. If you're looking for visually identical to the source, my experience is that they both take up a lot of room to get there. If you're looking to save a lot of space and don't mind some artifacts, especially for HD, x265 will let you go a lot lower to look similar.

I tend to do 2 pass encodes as I need a trade off between quality and size, most 1080p encodes I do are around the 10gb mark

[benwaggoner]

How viable would you say x265 is at this time for replacing x264 for use in a personal backup work flow? I see some companies are already using it for some streams/videos, or would you be better of waiting for a few present/up coming options to be tweaked first?

I haven't looked too deeply into it yet, but did a quick test with a music video from my of my dvd's (it's short and doesn't take long to encode, even when using QTGMC) and it did look cleaner with better colour's, to my eyes anyway, is two pass implemented yet, if not any idea of when that might be?



Decoder support is still the weakest aspect of the ecosystem, although that will change a LOT in 2015.



Also, x265 is still improving pretty rapidly in speed and quality. So I'd probably put off doing a big personal backup project for a few more months if there's no urgency. You could probably get it done a lot faster and at lower bitrates.



But definitely experiment and share your feedback!

[zerowalker]

Does x265 (at it's current state) offer improvement over x264 in 720p at around 1000 bitrate?
(Guessing not, will do tests if it's not an obvious answer).

[LigH]

Certain answer: "Depends."

There will be material where the advantage of x265 is obvious, and other material where an advantage is disputable. It also depends on the expectations. And the frame rate (720p is often broadcasted in double rate for smooth motion, which is harder to compress; the efficiency of both encoders is still not able to stay obviously below double bit rate requirement for double frame rate).

I wonder myself if a long shot of a soccer game or tennis match may work around 1 Mbps; probably to a degree that you can tell apart the players clearly, but don't expect to be satisfied with detailed lawn showing every blade of grass.

Indeed, a test with a specific sample is very recommended before guessing into the blue... Maybe today (ARD, Wolfsburg vs. München).

[zerowalker]

It's a digital recording from my 360. So it's no Noise (It's on the Menu and stuff), Clean and Sharp.

So it should be very good for the Encoder. Simple Colors, Text (some detailed stuff and gradients in the background etc, Depends on location).

Example (http://i61.tinypic.com/k48307.png) (This is the worse place, stuff going on in the back etc)

[LigH]

Mostly steady and clean content? Then x265 will probably have some advantage, being able to use larger units for low detail areas, and being more efficient in finding very similar areas. If you are able to provide a losslessly compressed sample (Ut, FFV1, lossless x264 or similar, maybe down to CRF 6), we could take part in the comparison and give hints about tweakable parameters. MEGA or MediaFire should offer a quite large storage.

[zerowalker]

Here is a short sample (UT Video Codec): https://drive.google.com/uc?export=download&id=0B_UKJFH8rbiNWXZWaG9tTTZtWXM

It shows an example of Simple stuff in the beginning, then the worse stuff later.
(Mostly i think it's simply stuff as i am going around in menus and not really at Title Menu).

Currently encoding x264 Very Slow 10bit at 1mbps to see how it looks.

[LigH]

Hehe, finally a reason to test ABR and CBR modes of x265.

ABR (1275.93 kbps):

x265 -o Xbox360_x265_abr1m.hevc --bitrate 1000

ABR + VBV (1256.46 kbps):

x265 -o Xbox360_x265_abr1mv.hevc --bitrate 1000 --vbv-maxrate 1500 --vbv-bufsize 6000

CBR + VBV (1275.18 kbps):

x265 -o Xbox360_x265_cbr1mv.hevc --bitrate 1000 --vbv-maxrate 1500 --vbv-bufsize 6000 --strict-cbr

All ABR/CBR modes seem to fill the buffer rather carefully (starting around 400 kbps), so the visual quality obviously increases during the first second.

2-pass VBR (1063.47 kbps):

x265 -o Xbox360_x265_vbr1m.hevc --bitrate 1000 --pass {1|2}

Here the visual quality is quite constant from the beginning.

Find HEVC and CSV files (log level 3) in my HEVC samples on MediaFire (https://www.mediafire.com/folder/ldwl20fppplbx/samples) (unfortunately, filtering doesn't seem to work, so use your browser's search for "Xbox").

[zerowalker]

I can't access your MediaFire i just get to my own account.

EDIT: In the original file there are a lot of still images. (I reboot and stuff which then just show "No Signal" for 10+ seconds).
And also some loading stuff are completely still i think (no hourglass and stuff, just a bar that moves at intervals).

Is Bitrate setting good at this kind of videos, or should i try to use CRF which is normally a favorite?

[LigH]

^ URL updated.

For streaming over a limited bandwidth network, a rather constant bitrate is useful.

If the video is downloaded first and later played from a faster medium, CRF is certainly recommended.

[zerowalker]

I am only reducing size for storing on my Computer.
So i guess CRF is the way to go.

Hmm, problematic as it's so slow, will do some x264 tests to see what quality i need to get "1mbps".
Then i guess i can do an x265 test with the same quality (Is there any parameter for x265 CRF X = x264 CRF X?)

EDIT:

Compared your 2pass x265 with my x264 10bit.
x265 filters out quite a bit, it looked better at first glance, but it removes details (along with some artifacts which is why it looked good at first).
Guess it's about the Block things, 720p isn't a high enough resolution to have advantage of those features.

[LigH]

It's hard to point at one specific reason why x265 reduced details a lot more; but there are still a few command line parameters not yet used to tweak the quality. To begin with, it was just a "medium" preset. And I missed a detail, I only used the 8 bit depth version of x265, unfair to compare directly against a 10 bit depth x264 with such low-detail color ramps.

Still, HEVC and AVC are quite different in their behaviour, so comparing their CRF results is meaningless, they remove a different kind of details from the video, which may look more or less annoying in different cases. So, I am sorry, but I can't take all the testing efforts from you...

[zerowalker]

Understandable, and as you say 10bit does it's thing.

I enjoyed the testing you did and it helped giving a glance of the situation.

I will most likely use x264 10bit for this as it's sure to work.
HEVC doesn't have use of it's full power in this situation i think, even if you can tweak out some details here and there.
If this was 1080p at 1mbps or lower i think there would be more of a difference, and above 1080p it's most likely a sure win.

Still interesting as this wasn't a "grain with small details" example, it did handle it quite well.
I can really see HEVC shine on Cartoons/Animé.

Many Thanks:)

[ramprasad85]

Sorry if this is not the right place to post the following compilation issue...

I downloaded the latest source code. Compilation using msvc (i tried vc9 and vc11) failed with the error
1>..\..\..\source\encoder\frameencoder.cpp(808) : error C3861: 'InterlockedAdd': identifier not found

It worked by changing InterlockedAdd to InterlockedExchangeAdd in x265/sources/common/threading.h line 67 as mentioned here (http://stackoverflow.com/questions/14603407/why-interlockedadd-is-not-available-in-vs2010).

Thanks

[LigH]

Possibly one premature patch, another should follow ... I remember that there is a very recent addition regarding VS and XP.

The best place to tell about such issues is the mailing list for developers.

[LigH]

One of the last x265 v1.4 before v1.5 will start: x265 1.4+465-e2c958ff874e (https://www.mediafire.com/download/f08ls04hu864f3c/x265_1.4+465-e2c958ff874e.7z)

Because they are fast enough in assembler, Psy-RD and Psy-RDOQ are enabled by default now (if applicable, based on the RD mode). Return codes are documented.

[x265_Project]

Although we've added some logic to reduce psy-rd strength when QP values go high (in other words, at relatively low bit rates), I think the current default psy-rd strength is about 3x too high. So if you're running a fresh build from the development tip, expect psy-rd to be toned down before we tag version 1.5. The current thinking is a default of psy-rd 0.3, psy-rdoq 1.0.

As always, we welcome your feedback (from your experience with psy-rd and psy-rdoq, especially from tests you might run with the latest development build).

Tom

[stax76]

When --psy-rd and --psy-rdoq are enabled now by default, how can they be disabled? Any other CLI and default value changes lately?

[LigH]

By setting their value to 0.0

[NikosD]

Decoder support is still the weakest aspect of the ecosystem, although that will change a LOT in 2015.


Could you explain it a little more ?

Do you compare the maturity of decoders vs encoders or something else ?

[x265_Project]

Could you explain it a little more ?

Software HEVC decoders such as MulticoreWare's UHDcode and similar offerings from all the usual suspects have matured to the point where they can run at peak performance on a variety of platforms. UHDcode, for example, is optimized for x86 (with hand-tuned assembly code for performance critical functions), accelerated with OpenCL on various GPU platforms, and is being ported to 3rd generation game consoles (PS3, XBOX 360) and ARM devices. We're working to make UHDcode available more widely... please stay tuned.

Hardware decoder designs are also maturing and shipping in many new mobile SOCs (System on a Chip - the integrated CPU+GPU+Image Signal Processor+Cell/Wifi/BlueTooth Radios, etc. in mobile devices) from Qualcomm, Samsung, MediaTek, Apple, Marvell, etc. Some of these companies design their own HEVC decoders, and some license the hardware design from one of the many companies that design hardware IP. HEVC hardware decoders are already available in many TVs, and they are starting to roll out in the latest generation cable/satellite/over-the-top set-top boxes. Samsung even has a DSLR that can encode video in HEVC (with a hardware encoder + decoder).

PC chipsets are starting to support HEVC in hardware this year. NVIDIA is already shipping a hardware HEVC encoder (Maxwell 2), and they've released APIs for a hybrid HEVC decoder. AMD has announced that their next-generation APU, Carizzo (http://www.anandtech.com/show/8855/amd-demonstrates-working-carrizo-laptop-prototype), will include a 4K hardware HEVC decoder. Intel has already released a hybrid HEVC decoder API (GPU accelerated), and there are reports (http://www.cpu-world.com/news_2014/2014060901_Some_features_of_Skylake_graphics_architecture.html)that their next generation platform, Sky Lake, will include hardware HEVC encoding and decoding. So, by the end of 2015, it wouldn't be a stretch to say that most new high-end video capable devices will have full hardware support for HEVC. Certainly, if you're in the market to buy a new PC, camera, TV, mobile phone, tablet or set-top box, it's something you should be looking for.

Tom

[nevcairiel]

NVIDIA is already shipping a hardware HEVC encoder (Maxwell 2), and they've released APIs for a hybrid HEVC decoder.

Actually, the recently released NVIDIA GTX 960 has a full hardware decoder for Main and Main10 at 4K, no more hybrid!
Its the same decoder chip the next Tegra is going to have on mobile.

[x265_Project]

Actually, the recently released NVIDIA GTX 960 has a full hardware decoder for Main and Main10 at 4K, no more hybrid!
Its the same decoder chip the next Tegra is going to have on mobile.
Yes, you're right... http://www.anandtech.com/show/8923/nvidia-launches-geforce-gtx-960

[NikosD]

x265_Project

Thanks for the thorough reply, I was just asking why the decoders are the weakest aspect of the ecosystem.

From your reply, obviously they aren't.

[x265_Project]

x265_Project

Thanks for the thorough reply, I was just asking why the decoders are the weakest aspect of the ecosystem.

From your reply, obviously they aren't.

No problem. Any new format change has a "chicken and egg problem"; which comes first, the encoders or the decoders? No one wants to encode to the new format if they (or their customers) can't easily decode the content. Decoders are required to make the ecosystem viable. HEVC decoders are quickly becoming available everywhere they are needed, but of course it takes time to roll out across the ecosystem. In some cases, devices (with programmable hardware with enough processing power) can download a software update. In other cases, we have to wait one replacement cycle for the installed base to upgrade.

[Asmodian]

x265_Project

Thanks for the thorough reply, I was just asking why the decoders are the weakest aspect of the ecosystem.

From your reply, obviously they aren't.

I do not get that from x265_Project's reply. Now that there is a reasonably mature encoder the main limiting factor for widespread use is decoder support.

There is still a lot of new hardware being sold that cannot play HEVC but can play AVC.

With only the very newest of devices having full hardware decoding and because software decoding of HEVC requires a lot of CPU power even with an optimized decoder I think it is fair to say decoder support is currently an issue for HEVC.

2015 is likely to change this, for all the reasons x265_Project mentioned, but that does not change the fact that currently HEVC is not universally or even widely supported on mobile devices or Smart TVs.

[NikosD]

The reason of low penetration of HEVC in the consumer world of TVs, Home Cinemas etc or even mobile devices, is not the immaturity of decoders.

It's the low supply of HEVC content, because of many other reasons than decoders.

The level of maturity of the encoders and decoders is about the same.

The one is following the other.

In the PC world, the ffmpeg decoder for HEVC files exists since 2013.

[Asmodian]

No one said it was due to the immaturity of the decoders, only that decoder support was the weakest aspect of the HEVC ecosystem (a lot of devices cannot play it).

[LigH]

x265 1.4+515-cd4117a34a19 (https://www.mediafire.com/download/43v73bqnwo6q320/x265_1.4+515-cd4117a34a19.7z)

Now with temporal layering (--[no-]temporal-layers), which allows video streams with up to 2 layers of temporal resolutions.

IIUC, a slower decoder may use the base layer only to decode with a reduced framerate; the sub-layer will consist of B frames which are unreferenced, to be inserted as higher rate frames when a decoder is fast enough to use them.
__

@ Asmodian + benwaggoner:

You rather mean the availability of consumer devices with HEVC decoders?

UHD via DVB is about to become available; the more UHD TV sets are sold, the more HEVC decoders you will find in consumer homes. And establishing a successor of Blu-ray is the next step. Just like introducing HD-ready and FullHD as successors of DVD Video with widescreen TV sets, carefully testing the market acceptance is always a part of the business.

[Asmodian]

@ Asmodian + benwaggoner:

You rather mean the availability of consumer devices with HEVC decoders?

UHD via DVB is about to become available; the more UHD TV sets are sold, the more HEVC decoders you will find in consumer homes. And establishing a successor of Blu-ray is the next step. Just like introducing HD-ready and FullHD as successors of DVD Video with widescreen TV sets, carefully testing the market acceptance is always a part of the business.

Right, decoder support being weak in an ecosystem does not mean the decoders are weak but that "decoder support is weak" or "decoder support is low".

At this moment HEVC support is still somewhat rare. However, as benwaggoner said, this looks to change a LOT in 2015. ;)

[x265_Project]

I recently spent some time with Matt Smith of DigitalTrends, helping him understand the state of HEVC.

http://www.digitaltrends.com/computing/h-265-hevc-encoding-explained/

[x265_Project]

OK x265 fans... we've pushed a number of changes today, making the default psy-rd strength 0.3, but we've also scaled psy-rd down at high QP values (low bit rates), and scaled psy-rd down for larger block sizes. We're anxious to hear your feedback.

[LigH]

So I'll have to schedule another build tomorrow... fine. :)

[xooyoozoo]

and scaled psy-rd down for larger block sizes.

Maybe I missed something, but I don't think that one has been applied yet?

Either way, I've previously tested that patch, and I quite like it. It seems to mitigate the most blatant artifacts.

[x265_Project]

Maybe I missed something, but I don't think that one has been applied yet?

Either way, I've previously tested that patch, and I quite like it. It seems to mitigate the most blatant artifacts.

Good eye! You're right... thanks for catching that. Steve sent the patch to x265-devel mailing list for review, but didn't commit it yet. Thanks for the feedback.

[LigH]

x265 1.4+527-d26268f9dc19 (https://www.mediafire.com/download/dta4y465s9b5oks/x265_1.4+527-d26268f9dc19.7z)

Psy-RD default is now 0.3; adaptive limit based on quantization and block sizes. Disabling with --no-psy-rd[oq] added.

[ckmox]

is it possible for x265 encoding speed to become as fast as x264? im talking about same quality output and not adjusting (trade-off) the preset of x265 for faster encoding to compare with x264 encoding speed, im sorry if this a stupid thing to ask but i do not follow this thread and googling did not answer this question of mine

thanks for the answers in advance

[LigH]

In my opinion, neither will HEVC encoders easily be as fast as AVC encoders because HEVC algorithms are significantly more elaborate (except you skip most algorithms which are more elaborate than AVC), nor will HEVC have "the same quality as" AVC because the reduction of visual complexity works in different ways in several details (except you want to use so much bitrate that the result will be "transparent", without noticable loss, in both cases).

There is still potential to speed up x265, there have been a lot of assembler optimized patches in the recent weeks and months, and there may still more follow. Nevertheless, even if any HEVC encoder used an optimal code, it would still have to calculate a magnitude more equations and decisions than any AVC encoder, if it is not specifically tuned to skip most of them and trade off quality for speed.

[Ajvar]

Hello everyone.
What is faster: 32 bit x265 or avs4x26X + 64 bit x265?

P.S. first pass with --me hex gave 12 fps while 2nd pass on the same settings but --me umh gave 4.5fps. Me range = 57, presets = slow. Is that really how ME mode differs in speed or because of first pass is always faster?
TNX.

[LigH]

Using the 64 bit x265 should be able to be faster because it can use both twice the width and twice the number of CPU internal registers in x86-64 mode, compared to x86 mode of the same CPU.

[Ajvar]

Thank you very much. Will continue using 64bit then.

People, in P.S. above I wrote about drastic performance difference between 1-st pass and 2-nd while I changed umh ot hex. It appears that for some reason even though I wrote to use HEX in 1-st pass it actually used DIA.
Here is CLI code:
--pass 1 --bitrate 2000 --preset slow --me hex --extra:
--pass 2 --bitrate 2000 --preset slow --me umh --extra:

While here is the beginning of log:
options: 1280x720 fps=25/1 bitdepth=8 wpp ctu=64 tu-intra-depth=1 tu-inter-depth=1 me=0 subme=2 merange=57 no-rect no-amp max-merge=1 temporal-mvp early-skip no-fast-cbf rdpenalty=0 no-tskip no-tskip-fast strong-intra-smoothing no-lossless no-cu-lossless no-constrained-intra fast-intra open-gop no-temporal-layers interlace=0 keyint=250 min-keyint=25 scenecut=40 rc-lookahead=25 bframes=4 bframe-bias=0 b-adapt=2 ref=1 weightp no-weightb aq-mode=1 aq-strength=1.00 cbqpoffs=0 crqpoffs=0 rd=2 psy-rd=0.30 psy-rdoq=0.00 signhide lft sao no-sao-non-deblock b-pyramid cutree rc=abr bitrate=2000 qcomp=0.60 qpmin=0 qpmax=51 qpstep=4 ipratio=1.40 pbratio=1.30
Question: is this normal? Is there some rule or something which could force it like that or it is a bug in the chain GUI>Avisynth>avs4x26x>x265-64?
Thank you.

[hector1980]

hi i need an app as pro as MeGUI for X264 to Encode my file into X265 what do yo recommend?

[LigH]

MeGUI. It already supports x265, to some degree.

[hector1980]

i know that but i wonder that is megui the best app for x265 or there is something better available?

[LigH]

Because the set of CLI options in x265 will keep changing during the continuing development, GUIs would have to keep changing just as much to keep supporting it.

But to recommend more alternatives: I believe StaxRip is a little more current and comprehensive at the moment, stax76 announced that recently. Hybrid is also quite up-to-date, usually.

[stax76]

Is there a link to the source code file which defines the default values for --tune grain?

[easyfab]

stax76 -> http://x265.readthedocs.org/en/latest/presets.html#film-grain-retention

[Selur]

@stax76: /source/common/param.cpp holds all defaults&co
else if (!strcmp(tune, "grain"))
{
param->deblockingFilterBetaOffset = -2;
param->deblockingFilterTCOffset = -2;
param->bIntraInBFrames = 0;
param->psyRdoq = 30;
param->psyRd = 0.5;
param->rc.ipFactor = 1.1;
param->rc.pbFactor = 1.1;
param->rc.aqMode = X265_AQ_VARIANCE;
param->rc.aqStrength = 0.3;
param->rc.qCompress = 0.8;
}

[stax76]

Thanks (the values for psyrd/psyrdoq have not changed there)

[Selur]

No, only the defaults changed in the last few weeks.

[foxyshadis]

Thank you very much. Will continue using 64bit then.

People, in P.S. above I wrote about drastic performance difference between 1-st pass and 2-nd while I changed umh ot hex. It appears that for some reason even though I wrote to use HEX in 1-st pass it actually used DIA.
Here is CLI code:
--pass 1 --bitrate 2000 --preset slow --me hex --extra:
--pass 2 --bitrate 2000 --preset slow --me umh --extra:

Question: is this normal? Is there some rule or something which could force it like that or it is a bug in the chain GUI>Avisynth>avs4x26x>x265-64?
Thank you.

Yes, of course it's normal. You have to pass --slow-firstpass for any of your settings to be considered in the first pass, unless you use --preset placebo. Because it's pointless to waste twice as much time encoding when a fast first pass is almost identical to a slow one.

[Ajvar]

Yes, of course it's normal. You have to pass --slow-firstpass for any of your settings to be considered in the first pass, unless you use --preset placebo. Because it's pointless to waste twice as much time encoding when a fast first pass is almost identical to a slow one.

Now I see why it is there! I thought it was some kind of typo and instead of --slow-firstpass there should be --fast-firstpass:p

Don't get why here is no Rep+ or Like buttons.

[Carpo]

Would it be brave or stupid to use x265 at the moment, I am going to change my files from 2 pass to crf19 because after many tests the files are smaller and give the same quality as the 2 pass, so if am going to re-encode them, should I give x265 a go or stay with x264?

I am going to do a test on The Dark Knight Rises to see which looks better, and will go from there, not normally an early adaptor :p

Version of x265 that I have, which I cross compiled on a linux box is 1.4.0.476

git - 1.4+476-16b2c318feb4

I heard that there may be some improvements and changes in the 1.5 release, should I wait for that?

[LoRd_MuldeR]

Version of x265 that I have, which I cross compiled on a linux box is 1.4.0.476

git - 1.4+476-16b2c318feb4

I heard that there may be some improvements and changes in the 1.5 release, should I wait for that?

Version "1.4+476" is the latest "development" version, or at least it's pretty close to the latest commit. I think they are at "+500 something" at the moment ;)

Furthermore, note that version "1.4+X" is simply going to be tagged as "1.5" as soon as they are done with the features/fixes they want to have in the "1.5" release. And then development continues as "1.5+X".

Consequently, if you currently use a recent "1.4+X" development version, then you already have most of the things that will be in "1.5" and thus the changes to the final "1.5" release will probably be rather small for you.

If, on the other hand, you sticked with the previous "1.4" release (and did not use any "1.4+X" development versions), then the upgrade from the "1.4" release to the "1.5" release would be a big step forward.

[Carpo]

cool :) will give it a test after I have done the film to x264 - 6 hours or so :p

[Ajvar]

You can also use 2 pass crf... at least some programs let you do this.

Does it give any benefit? More precise crf matching to the picked one?

[sneaker_ger]

You should be able to do a first pass CRF (i.e. create a stats file while doing crf encode) but not an nth-pass (n>1). Either --crf or --pass/--bitrate will be ignored (too lazy to test right now).

[detmek]

You can also use 2 pass crf... at least some programs let you do this.

Does it give any benefit? More precise crf matching to the picked one?

There is no such thing as 2-pass CRF, unless you mean using CRF for first pass to get stats file. And there is no such thing as "more precise CRF matching to the picked one".

There were some tests in using CRF for first pass for x264 encoding but it provide no benefit comparing to standard 1st pass. Also, using CRF to generate stats file for 1st pass may result in worse quality if bitrate obtained in 1st pass CRF differes too much compared to 2nd pass bitrate.

[RBX]

When using CRF, will slower presets result in better quality or just better compression?

[LigH]

"Maybe".

Slower presets will take more efforts in searching for "redundancies" = compressable parts of the video. That should usually return a better compression. But it is not guaranteed between every pair of presets for every video clip, there may be exceptions.

Whether it appears with higher quality to you, is not certain though. The "constant rate factor" shall limit the quality loss in a metric a computer can measure, but different presets can lose a different kind of details, so the video may appear slightly differently, which may or may not look less annoying to different people watching it.

[x265_Project]

When using CRF, will slower presets result in better quality or just better compression?

Both. Higher quality (slower) presets will definitely compress your video more efficiently, resulting in smaller files at any given bit rate or CRF setting. x265's slowest presets include multiple algorithms designed to improve visual quality, including psycho visual optimizations (psy-rd and psy-rdoq) and greater rate distortion optimization (RDO). So you end up getting both benefits by running slower.

Our tests at various CRF levels using different presets confirm this. We see both a bit rate reduction and a quality improvement at each CRF value when you use slower, higher quality presets.

[LigH]

Well, I do have clips with very slight exceptions (e.g. "medium" bigger than "fast", "placebo" bigger than "veryslow" for foreman_cif). But they are certainly not the norm. In general, you can expect more efforts leading to better efficienty ~ quality preservation per bitrate. But every rule has its exceptions, sometimes...

[Ajvar]

There is no such thing as 2-pass CRF, unless you mean using CRF for first pass to get stats file. And there is no such thing as "more precise CRF matching to the picked one".

There were some tests in using CRF for first pass for x264 encoding but it provide no benefit comparing to standard 1st pass. Also, using CRF to generate stats file for 1st pass may result in worse quality if bitrate obtained in 1st pass CRF differes too much compared to 2nd pass bitrate.
I see. Then I will contact some developers and tell them this and link to this page.
Both. Higher quality (slower) presets will definitely compress your video more efficiently, resulting in smaller files at any given bit rate or CRF setting. x265's slowest presets include multiple algorithms designed to improve visual quality, including psycho visual optimizations (psy-rd and psy-rdoq) and greater rate distortion optimization (RDO). So you end up getting both benefits by running slower.

Our tests at various CRF levels using different presets confirm this. We see both a bit rate reduction and a quality improvement at each CRF value when you use slower, higher quality presets.

But won't bigger count of b-frames for example (and refs) somewhat decrease quality of latest b-frames in a row?
I am talking about bit-rate converting now but is this differ much with CRF?

[xooyoozoo]

But won't bigger count of b-frames for example (and refs) somewhat decrease quality of latest b-frames in a row?

Every encoder decision precludes a different decision that might offer more quality per bit. The whole point of a modern encoder is to do good cost-analysis and make the best choice. In this specific case, `b-adapt` toggles how to analyze consecutive b-frames.

I am talking about bit-rate converting now but is this differ much with CRF?

CRF is heavily context-based, and changing an encoder setting also changes the context of the compressed stream.

There's literally no point in spending time dissecting CRF values.

[foxyshadis]

The only difference between P and B frames is that B frames also get forward references, and there's a separate pbratio that applies to them, making them about 25% smaller on average. (I'm not entirely convinced that this mixing forward references with heavier compression is optimal behavior, and --tune grain lowers it to ~10%, but I haven't ever seen anyone try making a patch that uses different ratios for b-ref and b-non-ref.) Merely having more B frames should only increase quality thanks to having more nearby references, although an encoder's estimation of quality is never perfect, so that isn't always the case.

If you use cu-tree (default from fast on), any referenced cu will automatically get higher quality, so the B-frame quality penalty won't matter nearly as much.

[x265_Project]

I see. Then I will contact some developers and tell them this and link to this page.

CRF rate control is doing something very different than 2 pass rate control. CRF tells x265 to maintain constant quality, regardless of the bit rate. Additional passes aren't needed to do this. It can be done in one pass.

CRF gives you constant quality - but the bit rate will vary as needed throughout the video, and you don't know how high or low the bit rate will go at any point in the video, or how large your resulting file will be.

ABR seeks to maintain a constant bit rate. Normal (single-pass) ABR knows what bits were used so far at any point in the encode, and it uses this historical information to adjust the quality level in order to end up with the overall ABR you were looking for. ABR has only limited visibility as to how many bits will be needed for the frames of video that are coming next (it gets an idea from the lookahead function, but the lookahead works on a limited number of frames in advance of the frame encoders, and it can't predict the # of bits that will be needed for the coming frames with precision). Two pass ABR can look at the statistics saved by the first pass, estimating how many bits will be needed for the coming frames with pretty good precision, factoring that in to settings used for the current frames to give the overall best quality in each section of the video, while maintaining the target average bit rate. Two pass ABR will end up giving you constant quality, at the overall average bit rate you were looking for.


But won't bigger count of b-frames for example (and refs) somewhat decrease quality of latest b-frames in a row?
I am talking about bit-rate converting now but is this differ much with CRF?
Higher quality presets don't force longer b-frame sequences. They just allow the encoder to use more b frames in a GOP if that is optimal. The optimal GOP structure depends on the content.

[benwaggoner]

The only difference between P and B frames is that B frames also get forward references, and there's a separate pbratio that applies to them, making them about 25% smaller on average. (I'm not entirely convinced that this mixing forward references with heavier compression is optimal behavior, and --tune grain lowers it to ~10%, but I haven't ever seen anyone try making a patch that uses different ratios for b-ref and b-non-ref.) Merely having more B frames should only increase quality thanks to having more nearby references, although an encoder's estimation of quality is never perfect, so that isn't always the case.
Intriguing!

Perhaps instead of pb ratio it should be a ref/non-ref ratio, with reference B-frames treated the same as P-frames. The current ratio structure would make more sense for older codecs where B-frames only had a subset of P-frame features. But when a B-frame is a P-frame that can also look in the future...

[srivani]

Hi,

What is different picture inheritance per slice in HEVC. Can anyone explain?

Thanks,
Srivani.

[xooyoozoo]

But when a B-frame is a P-frame that can also look in the future...

Nitpick, but there are no chronological requirements when choosing between P & B frames. The only difference is 1 vs 2 motion vectors allowed per block.

L0 and L1 are actually defined to implicitly include all available reference pics in each (just in different order). We don't see it because x265 signals a cap so that only "traditional" L0 and L1 refs are used.

[Ajvar]

ABR has only limited visibility as to how many bits will be needed for the frames of video that are coming next (it gets an idea from the lookahead function, but the lookahead works on a limited number of frames in advance of the frame encoders, and it can't predict the # of bits that will be needed for the coming frames with precision). Two pass ABR can look at the statistics saved by the first pass, estimating how many bits will be needed for the coming frames with pretty good precision, factoring that in to settings used for the current frames to give the overall best quality in each section of the video, while maintaining the target average bit rate. Two pass ABR will end up giving you constant quality, at the overall average bit rate you were looking for.

Well, does it mean that I can painlessly minimize rc-loockahead to the minimum (1 sec) in the 2-nd pass? If it already has the stats file for the whole video?

P.S. Thanks everybody. I always forget a phrase "you can set any amount of B-frames, encoder won't use them if it doesn't need it". Now I will try to remember this for a longer period of time.

[FranceBB]

@Ajvar... exactly. If you set -ref 16, for instance, it doesn't mean that it will use 'em if there is no need to use 'em.
But my question is addressed to xooyoozoo and srivani:
B frames are frame that are partially predicted from Intra and they can be used in order to predict others B frame - thanks to the motocompensation - and P frame are totally predicted.
So... the point is: a P frame can't look in the future (as benwaggoner said) 'cause when a GOP (Group of picture) meets a P frame, it will end and it will begin another GOP starting from an Intra frame.
But... what are L0 and L1? :confused:


Originally Posted by x265_Project
We're getting close to the v1.5 milestone. Currently, we've turned psy-rd and psy-rdoq on by default (for high quality presets), but I think we'll tone down the default value of psy-rd from 1.0 to 0.3 before we hit v1.5. We want to err on the side of less detail, but fewer artifacts (more accurate motion and color).

Well, if psy it's too high it will introduce artifacts, increasing bitrate, but on the high quality presets - with a proper strength - it's totally worth it. As to psy-rdoq, it's a good point activating it with high presets 'cause on low bitrates it could add junk, but on high bitrate - such as the one of high quality presets - it will make everything look better. My suggestion is to activate 'em only on veryslow and placebo because they use RDO Quantization and it would be great in high frequencies and it will allow me to add static grain on the source without any troubles as, for instance, Dither_add_grain16(var=0.15,soft=100) with dither tool 16 bit on avisynth.

[xooyoozoo]

But my question is addressed to xooyoozoo and srivani:
B frames are frame that are partially predicted from Intra and they can be used in order to predict others B frame - thanks to the motocompensation - and P frame are totally predicted.

I'm not sure what you mean. Prediction is prediction. Both P&B predicts from an arbitrary set of references. It doesn't matter how those references came to be as long as they exist when the decoder tries to decodes the P or B frame.

So... the point is: a P frame can't look in the future (as benwaggoner said) 'cause when a GOP (Group of picture) meets a P frame, it will end and it will begin another GOP starting from an Intra frame.

That's not how P frames are defined, and that's also not how any encoder works. You can have a multitude of P frames in an intra-period.

But... what are L0 and L1? :confused:

L0 and L1 are the reference lists. A block is only allowed 1 motion vector per list, so the reference lists become a key distinction between P and B frames, as the former can only access L0 while the latter can access L0+L1.

[x265_Project]

B frames are frame that are partially predicted from Intra and they can be used in order to predict others B frame - thanks to the motocompensation - and P frame are totally predicted.

To add to what xooyoozoo said, B and P frames aren't totally "predicted" (which sort of implies inter prediction, referencing other frames as opposed to intra prediction, referencing another block (CU) in this frame). I think the confusion comes from 2 places. First, the P in "P frames" stands for "predicted" and the B in "B frames" stands for "bi-directionally predicted". Second, I frames are Intra only. The reverse isn't true. P and B frames aren't "Inter-only". Both B and P frames can use intra-prediction when that is the best method to encode each CU (although b-intra is disabled by default in x265). The more options the encoder has, the more efficiently it can encode, but the longer it may take to evaluate all the options.



Well, if psy it's too high it will introduce artifacts, increasing bitrate, but on the high quality presets - with a proper strength - it's totally worth it. As to psy-rdoq, it's a good point activating it with high presets 'cause on low bitrates it could add junk, but on high bitrate - such as the one of high quality presets - it will make everything look better. My suggestion is to activate 'em only on veryslow and placebo because they use RDO Quantization and it would be great in high frequencies and it will allow me to add static grain on the source without any troubles as, for instance, Dither_add_grain16(var=0.15,soft=100) with dither tool 16 bit on avisynth.
psy-rd is only in effect with rd-level 3 or higher (medium preset or slower), and psy-rd is only in effect with rd-level 4 or higher (slow preset or slower). We have implemented a new algorithm to try to prevent psy-rd artifacts at low bitrates (reducing psy-rd strength automatically when QP > 42).

[LigH]

x265 1.4+544-f52d723d8c46 (http://www.mediafire.com/download/whvu8btarlikc0c/x265_1.4+544-f52d723d8c46.7z): Mostly small bug fixes, improvements and source nits (if I didn't miss any important change).

[FranceBB]

Thanks to both xooyoozoo and x265_Project, now all doubts are cleared ^_^

@LigH... tomorrow I will try it.

[x265_Project]

We're pleased to announce that x265 has reached another milestone! The v1.5 release of x265 has major improvements in Main10 compression efficiency and performance over the 1.4 release, general improvements in Main performance. Psycho-visual optimizations are now enabled by default in the presets which can support it (medium, slow, slower, veryslow and placebo).

Feature additions:

* analysis re-use features have been completed
* rate control zones have been introduced
* --tune grain introduced
* deblocking tC and Beta offsets are now configurable
* denoise is seperately configurable for inter and intra CUs
* frame based CSV logging has been improved
* New support for VTune task profiles


Presets and defaults:

ultrafast no longer disables the deblocking loop filter
psy-rd defaults to 0.3 (was 0, disabled)
psy-rdoq defaults to 1.0 (was 0, disabled)
aq-mode defaults to 1 (was 2, auto-variance)
4:2:2 and 4:4:4 encodes no longer generate compliance warnings


API changes:

param.rc.rateTolerance has been removed and replaced with a simpler param.rc.bStrictCbr flag.

--log-level debug is now --log-level 4 instead of --log-level 3. A new 'frame' log level was inserted at level 3 in order to support frame level CSV logging without also enabling frame level console logging.
Using the string name 'debug' is unambiguous as its behavior has not changed.

The online documentation has all the details:
http://x265.readthedocs.org/en/1.5/

[lotusgg]

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

[Motenai Yoda]

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

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

[foxyshadis]

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

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

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

[xooyoozoo]

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

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

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

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

[jlpsvk]

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

[LigH]

Ladies and gentlemen, this is x265 v1.5:

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

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

[jlpsvk]

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

[LigH]

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

[FranceBB]

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

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

[LigH]

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

[Boulder]

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

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

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

[Ajvar]

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

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

[LigH]

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

[foxyshadis]

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

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

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

[jlpsvk]

Congrats to x265 team. :)

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

[Ajvar]

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

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

[xooyoozoo]

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

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

[foxyshadis]

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

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

[Ajvar]

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

Aaaaah, I see. Language barrier that was.

[FranceBB]

Comparison between 1.4 and 1.5:

first of all, with a silly encoding like:

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

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

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

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

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

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

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

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

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

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

[jkauff]

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

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

[JohnAStebbins]

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

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

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

[jkauff]

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

[LigH]

Bad idea... :rolleyes:

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

[stax76]

Hi,

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

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

[uneedme]

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

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

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

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

cloud-video-encoding......


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

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


— —......

[jkauff]

Bad idea... :rolleyes:

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

[javlak]

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

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

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

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

cloud-video-encoding......

— —......

Shameless, shameless (but completely necessary!) plug:

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

[uneedme]

Shameless, shameless (but completely necessary!) plug:

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

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

[Makaveli84]

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

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

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

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

Thanks...

[LigH]

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

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

[Boulder]

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

[Makaveli84]

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

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

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

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

[uneedme]

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

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

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

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

Thanks...


- rd = 5

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

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

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


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


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

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

[Makaveli84]

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

Yes, and yes.

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

[Makaveli84]

- rd = 5

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

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

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


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


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

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

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

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

[foxyshadis]

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

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

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

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

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

[Makaveli84]

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


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



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

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

[x265_Project]

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

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

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

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

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

I hope this helps more than it confuses the subject!

[Boulder]

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

[uneedme]

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


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

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

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

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

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


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

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

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

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



Happy Chinese new year!


- -......

[Boulder]

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

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

[uneedme]

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

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



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



Happy Chinese new year!!


- -......

[Ajvar]

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

[Boulder]

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

[Tommy Carrot]

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

[Sagittaire]

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

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

[Tommy Carrot]

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

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

[x265_Project]

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

[Boulder]

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

[uneedme]

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

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

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

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

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

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

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


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

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

[Tommy Carrot]

Have you tried set the arguments to high detail preserved ones.Film grain, a special noise, can be preserved, which means the fine details can be reserved as well......
It doesn't matter which parameters i change (i've tried all kind of settings), x265 is not able reach transparency where x264 can.
x265 is designed to encode up to 4k even 8k output, the pores is no need to be detailed as much as x264 does on the common scale......
H.265 was designed to have better efficiency than h.264 in all cases. It's true it has bigger advantage at higher res, but there is no reason it should be worse at 720p or even at sd videos.
Currently, because of the hardware limitation, we compare the x265 fast-encode with x264 placebo......

All you need is to find the right tuning parameters...... to early to coffin the newbies.....
No, i compared x264 veryslow and placebo with x265 veryslow and placebo presets (or even slower settings manually). Again, it doesn't matter which settings i used, x265 cannot compete with x264 for high quality encodings. This can easily change as the development progresses, but the fact is, X265 is simply not properly tuned for high quality purposes yet.

[mandarinka]

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

It'S the other way around. Noisy/dirty picture looks natural, but as soon as you put a video through a denoising filter, everything starts to look like ass ugly plastic.

[Ajvar]

I spent hours to decide how exactly I want to encode my L4D2 gameplay library and while most of the time I compared HEVC I also made two x264 encoding and I do approve that x265 doesn't keep micro textures as good as x264.
x264 -precet placebo, CRF23, FullHD (http://i60.fastpic.ru/big/2015/0219/7b/11d0e1e8560d257a98a6bdb04695637b.png)
x265 -preset very slow, 2pass bitrate of resulted x264, PsyRD-0,7. (http://i60.fastpic.ru/big/2015/0219/7a/e5efb8d4aef0b94521e3a08ad5230b7a.png) Check the wall. x264 retained more details than x265 on same bitrate. Maybe that is because of Psy-RD?
I also encoded into CRF23 and it was WAY-WAY blurred speaking about not just micro details but almost all. However you can't see this in fast action.

Anyway I will do HEVC CRF 22.8 Psy-RD 0.7 FullHD

[foxyshadis]

That explains it then, thanks for the info!

Looks like Zeranoe is updated to 1.5 now.

[x265_Project]

The question still remains: is it even possible to tune x265 towards better grain/noise/whatever retention or is H.265 video just designed so that it is more like an alternative to x264 instead of a pure successor? There doesn't seem to be a clear answer to that anywhere.

Yes, it is possible to tune x265 towards better detail retention. Use a higher quality preset like veryslow, and increase psy-rd strength. But as others have pointed out, the best way to retain details is to use a high enough bit rate. As the bit rate goes lower, something's got to give.

I should point out that the kind of film grain that our high-end customers (movie studios, movie streaming services, etc.) see has much more detail (and energy) than anything a typical consumer user has ever seen. Some of the new 4K uncompressed content that we've seen from classic films ('90s on back to the '30s) has unbelievable levels of film grain (the higher the film scanner resolution, the more grain detail that shows up). If you're dealing with film grain from a DVD or Blu-ray rip, it's already been low-pass filtered by the first noise reduction/encoding process, and so it isn't nearly as challenging as high res film grain from freshly scanned film negatives.

[uneedme]

I spent hours to decide how exactly I want to encode my L4D2 gameplay library and while most of the time I compared HEVC I also made two x264 encoding and I do approve that x265 doesn't keep micro textures as good as x264.
x264 -precet placebo, CRF23, FullHD (http://i60.fastpic.ru/big/2015/0219/7b/11d0e1e8560d257a98a6bdb04695637b.png)
x265 -preset very slow, 2pass bitrate of resulted x264, PsyRD-0,7. (http://i60.fastpic.ru/big/2015/0219/7a/e5efb8d4aef0b94521e3a08ad5230b7a.png) Check the wall. x264 retained more details than x265 on same bitrate. Maybe that is because of Psy-RD?
I also encoded into CRF23 and it was WAY-WAY blurred speaking about not just micro details but almost all. However you can't see this in fast action.

Anyway I will do HEVC CRF 22.8 Psy-RD 0.7 FullHD


I tried and found the deblock [-3 and below] and rdoq [+30 and above] affect the deblurring much (my personal opinion......)

http://pan.baidu.com/s/1jGh5K1K

[Boulder]

Yes, it is possible to tune x265 towards better detail retention. Use a higher quality preset like veryslow, and increase psy-rd strength. But as others have pointed out, the best way to retain details is to use a high enough bit rate. As the bit rate goes lower, something's got to give.Unfortunately, the high enough bitrate is probably more than what x264 requires. I did a short test: encoded the x264 clip in CRF mode and then did a 2-pass encode with x265 with the same avg bitrate.

To me it seems that the I-frames look quite similar but the one after the I-frame is much softer with x265.

x264 : https://drive.google.com/open?id=0BzeF_1syecQwX28xMEV0aVBzZ2s&authuser=0
x265 : https://drive.google.com/open?id=0BzeF_1syecQwTHZuaXFuSlRha2M&authuser=0
x265_tunegrain : https://drive.google.com/open?id=0BzeF_1syecQwTHZuaXFuSlRha2M&authuser=0


x264 settings : c:\x264\x264.exe --stdin y4m - --sar 1:1 --level 4.1 --colormatrix "bt709" --colorprim "bt709" --transfer "bt709" --preset veryslow --crf 18.5 --output f:\temp\captures\x264.h264

x265 settings : c:\x265\x265.exe --pass 2 --y4m --input - --sar 1:1 --colormatrix "bt709" --colorprim "bt709" --transfer "bt709" --preset slow --bitrate 5403 --output f:\temp\captures\x265_tunegrain.h265

(or x265 with --tune grain)

Source cropped and resized to 1280x528 before encoding.
I guess I've been asking if it's possible to combine the grain/detail retention of x264 with the more advanced motion search etc. capabilities of x265. Is this achievable in the future or are the differences too big between the codecs?

[uneedme]

uncompressed content that we've seen from classic films ('90s on back to the '30s) has unbelievable levels of film grain (the higher the film scanner resolution, the more grain detail that shows up). If you're dealing with film grain from a DVD or Blu-ray rip, it's already been low-pass filtered by the first noise reduction/encoding process, and so it isn't nearly as challenging as high res film grain from freshly scanned film negatives.

Grain is Celluloid film's natural beauty. Alot film makers use grain as an expression. you can denoise it, but you cant kill the mood of grain effect......

[grumpy]

I should point out that the kind of film grain that our high-end customers (movie studios, movie streaming services, etc.) see has much more detail (and energy) than anything a typical consumer user has ever seen. Some of the new 4K uncompressed content that we've seen from classic films ('90s on back to the '30s) has unbelievable levels of film grain (the higher the film scanner resolution, the more grain detail that shows up). If you're dealing with film grain from a DVD or Blu-ray rip, it's already been low-pass filtered by the first noise reduction/encoding process, and so it isn't nearly as challenging as high res film grain from freshly scanned film negatives.
If a source is already compromised doesn't that only make it more important to accurately persevere the relatively little detail that it still has?

The codec will see it as more compressible, but you should force it to use more?

[Ma]

I've tested many x265 16bpp builds and I've noticed that the output file (encoded movie) isn't the same for all builds (all with the same settings with --no-info option and 10bpp output).

If you build x265 encoder with GCC with HIGH_BIT_DEPTH option and CMAKE_BUILD_TYPE=Debug (instead of Release) the encoded file is identical to output chromashift's build highbitdepth-msvc2012-64. The output (encoded movie) is indentical if you build with GCC with CMAKE_BUILD_TYPE=Release and -O2 optimize option instead of default -O3.

If you build with GCC with -O3 option the output file (encoded movie) is different and is changing with GCC versions (492-64bit != 482-64bit != 482-32bit).

Is it normal that output file (with --no-info option) differ with compiler options? Maybe the source code shouldn't be compile with -O3 option?

[LoRd_MuldeR]

I've tested many x265 16bpp builds and I've noticed that the output file (encoded movie) isn't the same for all builds (all with the same settings with --no-info option and 10bpp output).

If you build x265 encoder with GCC with HIGH_BIT_DEPTH option and CMAKE_BUILD_TYPE=Debug (instead of Release) the encoded file is identical to output chromashift's build highbitdepth-msvc2012-64. The output (encoded movie) is indentical if you build with GCC with CMAKE_BUILD_TYPE=Release and -O2 optimize option instead of default -O3.

If you build with GCC with -O3 option the output file (encoded movie) is different and is changing with GCC versions (492-64bit != 482-64bit != 482-32bit).

Is it normal that output file (with --no-info option) differ with compiler options? Maybe the source code shouldn't be compile with -O3 option?

First of all, is x265 even supposed to be deterministic (with default settings), i.e. is it supposed to always produce the bit-identical output for the same input? I know that x264 is supposed to be deterministic - but only unless you either pass the "--non-deterministic" option or you enable VBV (note that VBV is inherently nondeterministic, so this is not a bug). There also have been bugs in the past that caused nondeterminism.

Secondly, how did you determine that the outputs differ? Did you only compare the file hashes or did you actually see a difference? Or did you even get decoding errors with one version? Keep in mind that, just because two outputs differ, this doesn't necessarily mean one is "correct" and the other is "wrong". After all, there is an infinite number of "permissible" ways to encode the same source video.

Finally, higher optimization levels enable more "aggressive" optimizations. This raises the chance that something breaks. But it's also possible that, at the higher optimization levels, the compiler generates code that, while not being "wrong" or "broken", produces slightly different output! For example, floating point math is never "100% accurate", due to the limited FP precision (usually 32- or 64-Bit). Thus, in "strict" FP mode, there are tight rules on the rounding of intermediate FP results, in order to make sure that the final result is reproducible. In "fast" FP mode, however, these rules are softened in order to speed-up computations. Thus, "fast" and "strict" mode can produce different results. But, is "strict" more accurate? Not necessarily!

[Ma]

First of all, is x265 even supposed to be deterministic (with default settings), i.e. is it supposed to always produce the bit-identical output for the same input?

I don't know. I prefer deterministic behaviour. If different output it is a bug in source code, we should fight with this bug. If it is by design, I will accept that.

Secondly, how did you determine that the outputs differ? Did you only compare the file hashes or did you actually see a difference? Or did you even get decoding errors with one version?

I've binary compared output files. Output from Intel compiler build was bigger size, all others was the same size (but slightly differ). I've watched all outputs and didn't see any differences nor any decoding errors.

I want to choose the fastest build of 16bpp x265 and was surprised with the fact that the output files was different (with --no-info option).

[x265_Project]

First of all, is x265 even supposed to be deterministic (with default settings), i.e. is it supposed to always produce the bit-identical output for the same input? I know that x264 is supposed to be deterministic - but only unless you either pass the "--non-deterministic" option or you enable VBV (note that VBV is inherently nondeterministic, so this is not a bug). There also have been bugs in the past that caused nondeterminism.

Your hunch is correct. ABR (and CQP and CRF) output is expected to be deterministic with any number of frame encoders. The output of -F2 may be different than the output of -F3 but they will both be deterministic.

The only feature which is deliberately non-deterministic is VBV, which makes rate control decisions mid-frame based on the other partially completed frames. Here even with -F1 VBV is most likely non-deterministic because of WPP parallelism.


Secondly, how did you determine that the outputs differ? Did you only compare the file hashes or did you actually see a difference? Or did you even get decoding errors with one version? Keep in mind that, just because two outputs differ, this doesn't necessarily mean one is "correct" and the other is "wrong". After all, there is an infinite number of "permissible" ways to encode the same source video.

Finally, higher optimization levels enable more "aggressive" optimizations. This raises the chance that something breaks. But it's also possible that, at the higher optimization levels, the compiler generates code that, while not being "wrong" or "broken", produces slightly different output! For example, floating point math is never "100% accurate", due to the limited FP precision (usually 32- or 64-Bit). Thus, in "strict" FP mode, there are tight rules on the rounding of intermediate FP results, in order to make sure that the final result is reproducible. In "fast" FP mode, however, these rules are softened in order to speed-up computations. Thus, "fast" and "strict" mode can produce different results. But, is "strict" more accurate? Not necessarily!

Different compilers can generate different outputs. We only guarantee determinism across encodes made by the same binary, with the same command line options, and without VBV.

Output differences between compilers are likely caused by floating point math divergence in rate control, but we have not verified this.

[phate89]

Yes, it is possible to tune x265 towards better detail retention. Use a higher quality preset like veryslow, and increase psy-rd strength. But as others have pointed out, the best way to retain details is to use a high enough bit rate. As the bit rate goes lower, something's got to give.


I think what everyone is asking is not just pure grain retention. Everyone here knows that with grain you need to give something (so way higher bitrates or slower presets) to have accurate compression.
But the question is:
x265 has the same tools plus other more advanced than x264. Can we expect to get x265 at least as good as x264 with fine details and grain? what's the limit that stops x265 to be as good as x264 at the moment in this scenario?
Because right now I think everyone agree that x264 behave way better at the same bitrate with these 2 cases

[xooyoozoo]

The more precise question is probably "why hasn't x265's psy matched x264's psy".

Core prediction and content weighing tools (CUTree and AQ) perform as well versus x264's equivalence as you'd expect.

[mandarinka]

From my testing, x265 seemed to have problems keeping grain/texture in large 32x32 (it probably happened in 64x64 ones too) blocks. For some reason, in such CUs, it would code almost zero residual*. I didn't investigate it much, but interestingly the problem didn't go away if you disabled 32x32 and larger coding units. So it probably wasn't use of the large blocks as such, but something with analysis...
Damn, I'll have to look into it properly and bugreport some day.

* In stream analyzer you could see that while 16x16 and smaller blocks had normal grainy residual, 32x32 and 64x64 had the residual completely flat without grain.

[Ajvar]

x264 is like grain: gives artifacts but it contains useful details. It's like bad jpeg. While x265 blurs it, bigger bitrate - less blur but blur anyway: like downsampled and then oversampled again.
It would be good if it was possible to move slider details per X bitrate/blur per X bitrate.

Anyway x265 is BETTER for watching video in playback 24fps and above while if you want to KEEP ALL DETAILS in each frame then it's better x264 for now.

I wish new codec would mix both: give details until it is possible but if artifacts become less informative and more... well.. artifacts... it should start blurring like it does now.

[foxyshadis]

From my testing, x265 seemed to have problems keeping grain/texture in large 32x32 (it probably happened in 64x64 ones too) blocks. For some reason, in such CUs, it would code almost zero residual*. I didn't investigate it much, but interestingly the problem didn't go away if you disabled 32x32 and larger coding units. So it probably wasn't use of the large blocks as such, but something with analysis...
Damn, I'll have to look into it properly and bugreport some day.

* In stream analyzer you could see that while 16x16 and smaller blocks had normal grainy residual, 32x32 and 64x64 had the residual completely flat without grain.

Interesting, that would explain why there's so much more detail in really busy areas than simpler parts. The algorithms for testing blocks must have a pretty high threshold before they'll code a residual. It'd be nice to be able to adjust the skipping, even if that lowers quality elsewhere.

[EncodedMango]

I'm curious, is there a specific reason as to why the encoder needs to be provided YUV or Y4M files instead of managing the source itself from common containers? It has reached v1.5 and this is something that's been there for a very long time.

[x265_Project]

I'm curious, is there a specific reason as to why the encoder needs to be provided YUV or Y4M files instead of managing the source itself from common containers? It has reached v1.5 and this is something that's been there for a very long time.
Strictly speaking, a video encoder library accepts only uncompressed video frames as input. Accepting anything else would mean that the other format would first need to be decoded (to uncompressed YUV video). Combining decoder and encoder libraries you can create a transcoding application. Decoders for common input video formats are available from other open source projects. x265 is focused 100% on HEVC encoding. If you're looking for a transcoding application, there are many available that use x265 including FFMPEG, Handbrake, Hybrid, IFME, MeGUI, and StaxRip.

[benwaggoner]

If a source is already compromised doesn't that only make it more important to accurately persevere the relatively little detail that it still has?

The codec will see it as more compressible, but you should force it to use more?
The problem with old 4K masters isn't that there is relatively little detail. There's a LOT of detail. However, it's almost entirely film grain. Imagine blowing up a clean 720p movie to 3840x2160 and then layering a really strong noise synthesis filter on top of it. The energy in the frame is almost all film grain, and very little anything else.

And I'd argue this isn't an accurate experience to what the filmmakers saw or intended. Prints, projectors, and screens of the day certainly weren't capable of getting all the detail into the eyes of the viewer. We see movies with all kind of defects in special effects as well that would have been invisible in an 80's movie theater but which are painfully obvious on a 4K still frame on a high quality TV.

Remember that pausing wasn't even possible on celluloid in theaters, because the sustained heat would burn through the film.

So, the grain that a really high quality pin registered negative scan isn't grain that anyone who made the movie or saw it in theaters ever experienced.

The questions of "artistic intent" and "original experience" turn out to be complex and slippery in practice. No one would argue that we should be synthesizing projector noise or the slightly random positioning per frame caused by the pins not always lining up perfectly. Or flashing each frame three times for 1/144th of a second instead of leaving it on for the full 1/24th of a second. Etcetera.

Would David Lean have used modern fine-grain film stocks if they were available? Would he have shot day-for-night if he had access to modern CCD-based digital cameras? And should that matter? Is it more accurate for Bridge on the River Kwai to retain it's old chemical-based day-for-night shots that look very unrealistic, or to use modern digital effects to make those shots look like it was actually night, as intended?

Should The Philadelphia Story overwhelm viewers by accurately delivering all the grain in the negative, or filter out noise to what would have been seen on the fresh print at opening night at the Ziegfeld? Or something else?

[EncodedMango]

Strictly speaking, a video encoder library accepts only uncompressed video frames as input. Accepting anything else would mean that the other format would first need to be decoded (to uncompressed YUV video). Combining decoder and encoder libraries you can create a transcoding application. Decoders for common input video formats are available from other open source projects. x265 is focused 100% on HEVC encoding. If you're looking for a transcoding application, there are many available that use x265 including FFMPEG, Handbrake, Hybrid, IFME, MeGUI, and StaxRip.
Thanks.

I'm not looking into any HEVC encoders per se, I already use x265 builds provided in this thread or ffmpeg, if needed but I'm not encoding anything to H265 outside of testing yet.

Maybe I am spoiled by x264 transcoders that quietly do avs2yuv and I don't notice

[LigH]

Well, x265 is still so much in the development of the encoder kernel, that there is still "no spare time" (so to say) to add additional decoders to the binary. First the job, then the fun... ;)

Instead, x264 is already more or less "done", so it also had enough time to get some convenience additions, like a native AviSynth interface.

[mandarinka]

Well, ffm2s and libavformat (or what it is) inputs is probably one thing that could be ported over from x264 cleanly/without much changes in functionality needed, if somebody wants to make such patch.

For me, avs2yuv is enough of a solution.

[LigH]

And possibly slightly more convenient at the command line: avs4x26x.

[benwaggoner]

I got a little bored/overcaffeinated this weekend and did a x264 v. x265 test using ultra-placebo settings. It's a pretty definitive demonstration that at a low enough bitrate HEVC can blow H.264 out of the water, even with content with some detail/grain.

http://forum.doom9.org/showthread.php?p=1710758#post1710758

To push x265 beyond placebo, I added:

--cu-lossless, just in case lossless was better in some cases
-F 1, as sometimes frame parallelism can cause intra-frame rate control changes, and why risk it.
--subme 7, because placebo only uses 5
--tskip, because maybe sometimes that mode could be better
--ref 6, as that is the max for my frame size at target level, and placebo only goes up to 5
--rc-lookahead 96, as that's my max GOP duration, and placebo only goes up to 60


Unrelated to quality, I also used --pmode, so it wouldn't run glacially slow using up <20% CPU on my 16-core workstation. Killing frame parallelism is bad for parallelism, and pmode helps get some of it back (bouncing around 50-75% for me). --pme is really parallel, and didn't help throughput.

I doubt the above actually added that much improvement, but the test was all about what was theoretically possible. And I figured it might be useful to call out the knobs that go up to >11.

I saved my log file. I should probably do a straight placebo version and compare results.

[Lyris]

The problem with old 4K masters isn't that there is relatively little detail. There's a LOT of detail. However, it's almost entirely film grain. Imagine blowing up a clean 720p movie to 3840x2160 and then layering a really strong noise synthesis filter on top of it. The energy in the frame is almost all film grain, and very little anything else.

And I'd argue this isn't an accurate experience to what the filmmakers saw or intended. Prints, projectors, and screens of the day certainly weren't capable of getting all the detail into the eyes of the viewer. We see movies with all kind of defects in special effects as well that would have been invisible in an 80's movie theater but which are painfully obvious on a 4K still frame on a high quality TV.

Remember that pausing wasn't even possible on celluloid in theaters, because the sustained heat would burn through the film.

So, the grain that a really high quality pin registered negative scan isn't grain that anyone who made the movie or saw it in theaters ever experienced.

The questions of "artistic intent" and "original experience" turn out to be complex and slippery in practice. No one would argue that we should be synthesizing projector noise or the slightly random positioning per frame caused by the pins not always lining up perfectly. Or flashing each frame three times for 1/144th of a second instead of leaving it on for the full 1/24th of a second. Etcetera.

Would David Lean have used modern fine-grain film stocks if they were available? Would he have shot day-for-night if he had access to modern CCD-based digital cameras? And should that matter? Is it more accurate for Bridge on the River Kwai to retain it's old chemical-based day-for-night shots that look very unrealistic, or to use modern digital effects to make those shots look like it was actually night, as intended?

Should The Philadelphia Story overwhelm viewers by accurately delivering all the grain in the negative, or filter out noise to what would have been seen on the fresh print at opening night at the Ziegfeld? Or something else?

All very valid points, but for me, the deal breaker is that noise and grain reduction is often overdone and even done lightly, it still leaves artefacts behind. (See the otherwise great 1080p BD of Jaws and the "swimming grain" artefacts, or the "powdery grain" on The Godfather - although having said that, combining multiple film sources of various generations is a very good justification for grain reduction).

So while I fully agree that the amount (and sharpness) of grain we end up seeing isn't what was intended (and speaking of what was intended, as you touched on, nobody would vote to watch something degraded to the quality of a theatrical print), it's better than the processed alternative.

[benwaggoner]

All very valid points, but for me, the deal breaker is that noise and grain reduction is often overdone and even done lightly, it still leaves artefacts behind. (See the otherwise great 1080p BD of Jaws and the "swimming grain" artefacts, or the "powdery grain" on The Godfather - although having said that, combining multiple film sources of various generations is a very good justification for grain reduction).

So while I fully agree that the amount (and sharpness) of grain we end up seeing isn't what was intended (and speaking of what was intended, as you touched on, nobody would vote to watch something degraded to the quality of a theatrical print), it's better than the processed alternative.
There's a sliding scale from "all the grain in the 4K scan" to "all grain removed." The most accurate to creative intent and original experience is somewhere in the middle.

Also, there's a scale between "really good noise reduction that just makes it like the grain wasn't so strong" to "really bad noise reduction that leaves artifacts and throws out real non-grain detail." The optimal experience is at the first.

My go-to example for horribly jarring grain removal was the original Pinocchio Blu-ray. The algorithm wasn't properly motion adaptive, so static shots were grain free, but whenever anything moved grain popped into existence for the duration of the motion.

The culprit there wasn't that noise reduction was used, but that an inappropriate algorithm was used (perhaps one not tuned for cel animation?).

Getting back to x265 and encoding, ALL compression algorithms are in large part low-pass filters, and will soften out high-frequency spatial and temporal details like grain whenever there aren't enough bits available. How that gets tuned is a challenge. And the art is often not in "preserving" grain but in reproducing the general energy and feel of the original grain. If you do a frame-by-frame diff between source and encode, grain generally won't be identical. So codecs that are lauded for grain preservation are likely doing more grain emulation in practice. The basic idea of preserving source energy is what --psy-rdoq does in x265 sort of what psy-trellis does in x264.

Since grain is going to get removed/changed anyway, my preference is that the creative decision of what to remove and what to keep gets made at the mastering stage as much as possible, and in the codec as little as possible. And rest assured, you do NOT want all the grain in a high quality film scan. Think how noisy a RAW file shot in low light is. It's not "accurate" to the original image, creative intent, original experience, or anything. And it gets worse the better the scan.

[Fantasy]

Hello,
I use Megui to encode video.
I try to use 2nd pass with x265 with command "--pass 2" but it doesnt work.
Can I use x265 2nd pass with megui?
What have i do to encode 2nd pass with x265?
Thanks

Edit: I found out that i have to do first pass and then 2nd pass:
OK. Variables that you supply are shown in capital letters...

x265 --input SOURCEFILE --input-res RES --fps FPS --bitrate BITRATE -p PRESET --pass 1 --slow-firstpass --stats STATSFILE.LOG OUTPUT1.hevc

x265 --input SOURCEFILE --input-res RES --fps FPS --bitrate BITRATE -p PRESET --pass 2 --stats STATSFILE.LOG OUTPUT2.hevc


So, for example...
x265 --input test.yuv --input-res 1920x1080 --fps 30 --bitrate 5000 -p slow --pass 1 --slow-firstpass --stats test_stats.log test-firstpass.hevc

x265 --input test.yuv --input-res 1920x1080 --fps 30 --bitrate 5000 -p slow --pass 2 --stats test_stats.log test.hevc

I am testing now. I use medium preset for both pass. But it tooks too long for me to do first pass. So now I have questions:
If I use -p fast or -p faster for the first pass, will the quality worse or will the file bigger with constant bitrate?
What is the best way to do first pass?

[x265_Project]

Hello,
I am testing now. I use medium preset for both pass. But it tooks too long for me to do first pass. So now I have questions:
If I use -p fast or -p faster for the first pass, will the quality worse or will the file bigger with constant bitrate?
What is the best way to do first pass?
A slow first pass isn't going to buy you much. Try removing this option from your first pass, and it will automatically run much faster. This is much better than changing the performance preset for the first pass, as different presets use different parameters that can affect the GOP structure (like the max # of consecutive b-frames allowed), and the GOP structure must be identical in both passes. So, if you use a faster preset in the first pass, it could limit compression efficiency in the second pass.

[LigH]

The new builds support NUMA (http://en.wikipedia.org/wiki/Non-uniform_memory_access) thread pools (enjoy your "render farm") :D

x265 1.5+77-87173d41df87 (http://www.mediafire.com/download/uqmuc9bt4720mvk/x265_1.5+77-87173d41df87.7z)

[Fantasy]

Thanks for your answer.
I have now problem with first pass: only 50 % of the frames were encoded.
My video has 60 fps. I also try to use command
--fps 60
but it doesn't work. :(

[LigH]

The 'fps' switch will not have any impact on the number of frames encoded, it only tells the encoder about the duration each frame will be visible so it can possibly adjust psycho-visual features, and maybe flag the output if the output supports frame rate flags at all.

Does x265 detect the expected number of frames but stops unexpectedly after half the number? But ... if you feed a raw YUV file without supplying the 'frames' parameter, x265 may not be able to detect the number at all, just encode to the EOF.

[Fantasy]

Like I said I am using Megui and x265 stops by half the number and only when I add --pass 1 to command. I want to use 2nd pass because I can chose the bitrate and it is better then 1 pass (ABR Mode).

I am using "--crf" now without "--pass" and x265 still works over half the number. waiting now, 50 min to finish...

[Music Rockz]

I have error with MeGUI x265...When encodes it shows error...!

Error:
Standard Stream Error

What could be the issue?

No problem with Avs script! Checked with AvsPmod!

[LigH]

Uh, guys, you are mixing MeGUI and x265 now. If there is no error starting the conversion from a command line or in a batch file (maybe using avs4x26x in case of an AviSynth script as source), it doesn't belong to this thread, but instead there may be an issue with MeGUI.

I just tested a fast 2-pass encode of a Y4M file with x265 1.5+77 using a batch, and there is no issue, the 1st pass processes all frames.

[Fantasy]

My video is a .mp4 or a .mkv file. How can i convert to .y4m or compatible input type for x265?
I try this:
LoadPlugin ("C:\Program Files (x86)\AviSynth 2.5\plugins\DirectShowSource.dll")
file = DirectShowSource("C:\Users\...\video.mp4", fps=59.940, audio=false, convertfps=true).AssumeFPS(60000,1001)

F:\MeGUI_2418_x86\tools\x265\x64\x265.exe --input file --input-depth 8 --input-res 1920x1080 --fps 60 --bitrate 25000 -p medium --pass 1 --stats test_stats.log test-firstpass.hevc
F:\MeGUI_2418_x86\tools\x265\x64\x265.exe --input file --input-depth 8 --input-res 1920x1080 --fps 60 --bitrate 25000 -p medium --pass 2 --stats test_stats.log test.hevc
but batch not runs.

[sneaker_ger]

Script:
DirectShowSource("C:\Users\...\video.mp4", fps=59.940, audio=false, convertfps=true).AssumeFPS(60000,1001)

command:
avs2pipemod.exe -y4mp script.avs | F:\MeGUI_2418_x86\tools\x265\x64\x265.exe - --y4m --bitrate 25000 --pass 1 -o test-firstpass.hevc
avs2pipemod.exe -y4mp script.avs | F:\MeGUI_2418_x86\tools\x265\x64\x265.exe - --y4m --bitrate 25000 --pass 2 -o test.hevc
avs2pipemod download (http://www.mediafire.com/download/alg424t3kx7ak5d/avs2pipemod-0.4.2m.7z)

Or you can use a tool like ffmpeg (http://ffmpeg.zeranoe.com/builds/) if you don't need any AviSynth processing (no script file needed):
ffmpeg.exe -i "C:\Users\...\video.mp4" -f yuv4mpegpipe - | F:\MeGUI_2418_x86\tools\x265\x64\x265.exe - --y4m --bitrate 25000 --pass 1 -o test-firstpass.hevc
ffmpeg.exe -i "C:\Users\...\video.mp4" -f yuv4mpegpipe - | F:\MeGUI_2418_x86\tools\x265\x64\x265.exe - --y4m --bitrate 25000 --pass 2 -o test.hevc

(I removed some parts of your command that are not necessary)

[LigH]

That's because the first half is an AviSynth script, not a batch. The first two lines could not be executed on a command line prompt, so they can't in a batch file either.

Besides, DirectShowSource is always my last choice, only chosen if all other possible source plugins failed. DirectShow as such has a priority to play video fast, even if that means to reduce quality or even skip frames, except you really know your installed filters and how to tweak them. Instead, native AviSynth decoders (like FFMS2 / L-SMASH Source / DGDecNV / DGDecIM) have a priority to provide exact decoding results, even if that may take a bit more time.

Is it at all necessary to change the frame rate to "ntsc_double" (FPS preset (http://avisynth.nl/index.php/FPS))? Does your original video not already have that frame rate?
__

P.S.: Instead of avs2pipemod, why not avs4x26x (http://forum.doom9.org/showthread.php?t=162656)?

avs4x26x -L F:\MeGUI_2418_x86\tools\x265\x64\x265.exe --bitrate 25000 --pass 1 -o test-firstpass.hevc script.avs
avs4x26x -L F:\MeGUI_2418_x86\tools\x265\x64\x265.exe --bitrate 25000 --pass 2 -o test.hevc script.avs

It may even support the MP4 or MKV source more or less directly, creating the required script on-the-fly, based on the extension and available source plugins.

[Selur]

--pools <string>, --numa-pools <string>
Comma seperated list of threads per NUMA node. If "none", then no worker pools are created and only frame parallelism is possible. If NULL or "" (default) x265 will use all available threads on each NUMA node-

'+' is a special value indicating all cores detected on the node
'*' is a special value indicating all cores detected on the node and all remaining nodes
'-' is a special value indicating no cores on the node, same as '0'

example strings for a 4-node system:
"" - default, unspecified, all numa nodes are used for thread pools
"*" - same as default
"none" - no thread pools are created, only frame parallelism possible
"-" - same as "none"
"10" - allocate one pool, using up to 10 cores on node 0
"-,+" - allocate one pool, using all cores on node 1
"+,-,+" - allocate two pools, using all cores on nodes 0 and 2
"+,-,+,-" - allocate two pools, using all cores on nodes 0 and 2
"-,*" - allocate three pools, using all cores on nodes 1, 2 and 3
"8,8,8,8" - allocate four pools with up to 8 threads in each pool

The total number of threads will be determined by the number of threads assigned to all nodes. The worker threads will each be given affinity for
their node, they will not be allowed to migrate between nodes, but they will be allowed to move between CPU cores within their node.

If the three pool features: `--wpp`, `--pmode` and `--pme` are all disabled, then `--pools` is ignored and no thread pools are created.

If "none" is specified, then all three of the thread pool features are implicitly disabled.

Multiple thread pools will be allocated for any NUMA node with more than 64 logical CPU cores. But any given thread pool will always use at most one NUMA node.
Frame encoders are distributed between the available thread pools, and the encoder will never generate more thread pools than `--frame-threads`. The pools are used for WPP and for distributed analysis and motion search.

Default "", one thread is allocated per detected hardware thread (logical CPU cores) and one thread pool per NUMA node.
source: https://bitbucket.org/multicoreware/x265/commits/7252c10278a1e1aeddbe489180aad35196262919#chg-doc/reST/cli.rst

-> anyone played around with this and can recommend some values for normal (dual/quad/hex/octa-core) users?

[LigH]

I wonder if that is at all useful on only one PC. If I understood the Wikipedia explanation at all, NUMA is about per-CPU local memory, which is not very usual in a PC.

[xooyoozoo]

I wonder if that is at all useful on only one PC. If I understood the Wikipedia explanation at all, NUMA is about per-CPU local memory, which is not very usual in a PC.

Dual-sockets are common enough in editing/rendering rigs, and the NUMA barrier had always been a problem for most encoders. AFAIK, x264 itself never benefited from an extra CPU and was sometimes worse.

Anything with more than 2 sockets is unlikely except in a multi-user server sense, though I wouldn't mind seeing some numbers for a 8-socket Xeon-EX encode.

The only place that I've ever seen trying to benchmark both x265 and multi-socket systems is Anandtech. However, I recall them using x265 with Hybrid, both of which have rapid development cycles, without ever listing version numbers...

[LigH]

My first thoughts went into the direction of super computers with processor card slots...

[x265_Project]

I wonder if that is at all useful on only one PC. If I understood the Wikipedia explanation at all, NUMA is about per-CPU local memory, which is not very usual in a PC.
NUMA awareness is useful on multi-socket systems (workstations and servers). If your PC motherboard has only one processor socket (like all consumer PCs), this feature isn't relevant to you.

By scheduling similar work on a particular NUMA node (CPU), we can maximize the possibility that data needed by a particular thread will be found on locally (in the cache of that processor), and not on another NUMA node (which takes much longer to retrieve than if the data is in the local cache).

[Selur]

NUMA awareness is useful on multi-socket systems (workstations and servers). If your PC motherboard has only one processor socket (like all consumer PCs), this feature isn't relevant to you.
Okay,... then why remove the old '--threads X' ?
Threading, performance:
--pools <integer,...> Comma separated thread count per thread pool (pool per NUMA node)
'-' implies no threads on node, '+' implies one thread per core on node
-F/--frame-threads <integer> Number of concurrently encoded frames. 0: auto-determined by core count
--[no-]wpp Enable Wavefront Parallel Processing. Default enabled
--[no-]pmode Parallel mode analysis. Default disabled
--[no-]pme Parallel motion estimation. Default disabled
--[no-]asm <bool|int|string> Override CPU detection. Default: autosource: x265 command line help

[EncodedMango]

I was looking at an x265 encode someone made and was impressed with the results(quality:filesize ratio), unfortunately I don't know the person so couldn't ask for the commandline nor do I have a way to contact whoever made it. Is someone 'well versed' in the default parameters to discern what exactly were the arguments supplied?

Taken from MediaInfo:
Encoding settings: wpp / ctu=64 / tu-intra-depth=1 / tu-inter-depth=1 / me=3 / subme=3 / merange=57 / rect / no-amp / max-merge=3 / temporal-mvp / no-early-skip / no-fast-cbf / rdpenalty=0 / no-tskip / no-tskip-fast / strong-intra-smoothing / no-lossless / no-cu-lossless / no-constrained-intra / no-fast-intra / open-gop / interlace=0 / keyint=240 / min-keyint=24 / scenecut=40 / rc-lookahead=25 / bframes=4 / bframe-bias=0 / b-adapt=2 / ref=3 / weightp / no-weightb / aq-mode=2 / aq-strength=1.00 / cbqpoffs=0 / crqpoffs=0 / rd=4 / psy-rd=0.30 / psy-rdoq=1.00 / signhide / lft / sao / no-sao-non-deblock / b-pyramid / cutree / rc=crf / crf=25.0 / qcomp=0.60 / qpmin=0 / qpmax=51 / qpstep=4 / ipratio=1.40 / pbratio=1.30

I can obviously see it's 25 CRF and a psy-rd of 0.3 but other than that I can't say if there's any 'custom' parameters out of the ordinary.

[x265_Project]

I was looking at an x265 encode someone made and was impressed with the results(quality:filesize ratio), unfortunately I don't know the person so couldn't ask for the commandline nor do I have a way to contact whoever made it. Is someone 'well versed' in the default parameters to discern what exactly were the arguments supplied?

Taken from MediaInfo:


I can obviously see it's 25 CRF and a psy-rd of 0.3 but other than that I can't say if there's any 'custom' parameters out of the ordinary.
See http://x265.readthedocs.org/en/default/presets.html
It looks like --preset slow --aq-mode 2 --crf 25

[x265_Project]

Okay,... then why remove the old '--threads X' ?

On typical single-socket systems --pool N will do the same thing that --threads N did prior to the change, but obviously --pool can do a lot more than --threads ever could.

A large impetus to remove x265 --threads was that it has never matched the behavior of x264 --threads. x264's --threads configured frame threads, unless you were using slice threads, in which case it configured the number of slices. x265 --threads has never had the same effect as x264 --threads and we saw users were confused by this.

So now when some x264 user starts to run x265, if they try to configure the number of frame threads with x265 --threads they will learn that is not the right param, they will read the docs, and discover that our threading strategy uses --frame-threads N and --pool M,O,P. Failing the first time is better than getting a bad result with x265 while thinking that you're using optimal settings on your machine.

[LigH]

I believe this thread pooling could be a feature the x264 might be interested in for backporting. If AVC encoding would profit just as much. Who knows if there are power computers with more than 2 CPUs in a "render farm".

[benwaggoner]

I believe this thread pooling could be a feature the x264 might be interested in for backporting. If AVC encoding would profit just as much. Who knows if there are power computers with more than 2 CPUs in a "render farm".
Lots of encoding gets done in AWS. All the "8xlarge" instance types are dual socket. The new c4.8xlarge has 18 cores (36 hyperthreaded) of Broadwell, and thus AVX2.

http://aws.amazon.com/ec2/instance-types/

Generally dual socket is the sweet spot, as quad-socket systems tend to run at a lower clock speed, and are a lot more expensive in MIPS/$. But they might be useful for higher quality real-time UHD encoding or something.

FWIW, My primary workstation has been always been dual-socket since the late 90's. Even if it doesn't always make a single encoding job go faster, it helps with video processing in general, and when doing multiple encodes at once.

[LigH]

The announced "big fat AVX2 patch collection" is now included in x265 1.5+128-394c2f94a2dc (https://www.mediafire.com/download/khw7h4cocv4xm89/x265_1.5+128-394c2f94a2dc.7z)

[shinchiro]

The announced "big fat AVX2 patch collection" is now included in x265 1.5+128-394c2f94a2dc (https://www.mediafire.com/download/khw7h4cocv4xm89/x265_1.5+128-394c2f94a2dc.7z)
How much fps gained now when encoding on haswell :D More than ~3fps?

[LigH]

Depends on material, preset, resolution ... an absolute number of fps would be the least intelligent unit to measure.

From the mailing list announcement:

They give about a 6% gain in performance on AVX2 capable CPUs.

What's your experience, can you prove this estimation with your specific testing material?

[Ma]

I've made test with 16bpp x265: encoding 2401 frames with resolution 1920x800 (via MeGUI) on i5 3450S, Windows 7 64-bit.
x265 build 1.5+27 (chromashift x265-1.5.27-highbitdepth-msvc2012-64.7z) -- 979.92 s (2.08 fps)
x265 build 1.5+128 (chromashift x265-1.5.128-highbitdepth-msvc2012-64.7z) -- 1001.31 s (2.04 fps)

I have 2.2% lost in speed with new version (but my CPU is without AVX2).

[Ma]

I investigated why the new build 1.5+128 of 16bpp x265 is 2.2% slower than 1.5+27 and I noticed that this is the reason:
https://bitbucket.org/multicoreware/x265/commits/fa3fd0b3fe12453d3bf538a866e68ae4534330a0

If I revert changes to "hg update 9563" and build 16bpp x265 -- it is fast. If I revert to "hg update 9564" -- it is slow.

[evilr00t]

I've also seen a slowdown on my dual proc Sandy Bridge Xeon (8core/16thread per CPU) system. Before NUMA pools, I was able to saturate all CPUs in the system with pmode*, now no matter what, I'm unable to get a significant load on the second CPU.

I tried:
--pools +,+
--pools 8,8 (only the first CPU gets used consistently)
--pools 16,16 (only the first CPU gets used consistently)

Running Windows Server 2012 R2. Maybe this is Windows.

*With a 720p source:
1.4+527 - 6 frames per second on veryslow+pmode. CPU use is 80% CPU1, 95% CPU2.
1.5+128 - 3.5 frames per second on veryslow+pmode. CPU use is 100% CPU1, 10-20% CPU2.
Figures are approximate. The system is at work.

[Fantasy]

Script:

Or you can use a tool like ffmpeg (http://ffmpeg.zeranoe.com/builds/) if you don't need any AviSynth processing (no script file needed):
[code]ffmpeg.exe -i "C:\Users\...\video.mp4" -f yuv4mpegpipe - | F:\MeGUI_2418_x86\tools\x265\x64\x265.exe - --y4m --bitrate 25000 --pass 1 -o test-firstpass.hevc
ffmpeg.exe -i "C:\Users\...\video.mp4" -f yuv4mpegpipe - | F:\MeGUI_2418_x86\tools\x265\x64\x265.exe - --y4m --bitrate 25000 --pass 2 -o test.hevc

(I removed some parts of your command that are not necessary)
thank you, even a beginnner like me can use this code by copy paste. Now I can use x265 without megui.

That's because the first half is an AviSynth script, not a batch. The first two lines could not be executed on a command line prompt, so they can't in a batch file either.

Besides, DirectShowSource is always my last choice, only chosen if all other possible source plugins failed. DirectShow as such has a priority to play video fast, even if that means to reduce quality or even skip frames, except you really know your installed filters and how to tweak them. Instead, native AviSynth decoders (like FFMS2 / L-SMASH Source / DGDecNV / DGDecIM) have a priority to provide exact decoding results, even if that may take a bit more time.

Is it at all necessary to change the frame rate to "ntsc_double" (FPS preset (http://avisynth.nl/index.php/FPS))? Does your original video not already have that frame rate?

My original Video has already 60 fps and is progessiv format. Now I am using ffmpeg (some thing like FFMS2), thanks for your advice.

Now I have a question about 10 bit. My source file is 8 bit. I want 10 bit output. Do I have to convert it to 10 bit first or x265 will do it for me like x264?
I think for 10 bit I should use x265 win64 16 bit.

[sneaker_ger]

Now I have a question about 10 bit. My source file is 8 bit. I want 10 bit output. Do I have to convert it to 10 bit first or x265 will do it for me like x264?
It works like x264, i.e. just use the high bitdepth build of x265 and it will work automatically.

I think for 10 bit I should use x265 win64 16 bit.
Correct.

[Ajvar]

Hey people, just a quick noob question. If I do a first pass x265 encode (lets say 3000kbps), can I use those stats files for 2-nd pass with higher bitrate (like 4000) without disadvantages if I am not satisfied with quality? TNX!

P.S. Yes, I know about CRFactor mode.

[Asmodian]

No. ;)

[LigH]

I guess you may alter only the bitrate for the 2nd pass; but you should expect the result possibly not match this target well, and the achieved quality be not always optimal. But don't judge by the quality of the 1st pass result, this one is not optimal for sure.

[benwaggoner]

I guess you may alter only the bitrate for the 2nd pass; but you should expect the result possibly not match this target well, and the achieved quality be not always optimal. But don't judge by the quality of the 1st pass result, this one is not optimal for sure.
But it will be pretty close.

A first pass at 3000 Kbps will do pretty well encoding a 2000 or 4000 Kbps 2nd pass. x264 can even do okay when changing frame sizes some; I've not tried this with x265. It won't be the optimal perfect encode, but can make sense for quality @ speed scenarios, since the time saved from doing multiple first passes can be spent on higher quality second passes.

[Ajvar]

Thanks guys. I played the raw h265 file from temp directory of non finished 2nd pass and was not happy with the result. After all CRF 22.7 is the easiest way even if it takes 6000 kb/s for my FullHD videos.

On the side note... I guess I want to give my feedback. What IF there would be a hybrid CRF Pass mode with max limit bit rate? Like CRF 18 but not higher 6000 kbps where it would encode in CRF but would not exceed max bitrate for 1 sec/keint/P+consequent B frames to the max limit I set OR encode in CRF but would reencode it with all stats data automatically if it exceeds 6000 kbps limit. First method I like more.
For example, you want to set CRF X for all your videos (100) but they are all different of course and some may have some bitrate cost FX effects which actually are not necessarily to keep as transparent as over 6000kbps OR as expensive as it would increased overall video average bitrate.
What do you think, am I dreaming in stupidness?

[qyot27]

That's [essentially] CRF+VBV, isn't it? --crf-max and a defined --vbv-maxrate, or something. I've never bothered with any of that for either H.264 or HEVC.

[Ajvar]

That's [essentially] CRF+VBV, isn't it? --crf-max and a defined --vbv-maxrate, or something. I've never bothered with any of that for either H.264 or HEVC.

Wow! Cool. Just googled about it and found not much. Wil read x265 help page with commands.

[Ma]

I build x265 1.5+141 16bpp and try encoding via MeGUI -- it crashes.
I try 1.5+140 16bpp -- it works via MeGUI.

Log from MeGUI:
---[Information] [2015-03-04 20:12:04] avs4x265 [info]: "C:\MeGUI\tools\x265\x64\x265.exe" - --frames 2041 --fps 24000/1001 --input-res 1920x800 --input-csp i420 --preset slow --crf 18.5 --keyint 288 --colormatrix bt709 --no-info --output F:\m\v\0001.mkv.hevc
--[Error] [2015-03-04 20:11:44] Standard error stream
---[Information] [2015-03-04 20:11:44] yuv [info]: 1920x800 fps 24000/1001 i420p8 unknown frame count
---[Information] [2015-03-04 20:11:44] x265 [info]: HEVC encoder version 1.5+141-e212eee15e98
---[Information] [2015-03-04 20:11:44] x265 [info]: build info [Windows][GCC 4.9.2][64 bit] 16bpp
---[Information] [2015-03-04 20:11:44] x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
---[Information] [2015-03-04 20:11:44] x265 [info]: Main 10 profile, Level-4 (Main tier)
---[Information] [2015-03-04 20:11:44] x265 [info]: Thread pool created using 4 threads
---[Information] [2015-03-04 20:11:44] x265 [info]: frame threads / pool features : 2 / wpp(13 rows)
---[Information] [2015-03-04 20:11:44] x265 [info]: Internal bit depth : 10
---[Information] [2015-03-04 20:11:44] x265 [info]: Coding QT: max CU size, min CU size : 64 / 8
---[Information] [2015-03-04 20:11:44] x265 [info]: Residual QT: max TU size, max depth : 32 / 1 inter / 1 intra
---[Information] [2015-03-04 20:11:44] x265 [info]: ME / range / subpel / merge : star / 57 / 3 / 3
---[Information] [2015-03-04 20:11:44] x265 [info]: Keyframe min / max / scenecut : 23 / 288 / 40
---[Information] [2015-03-04 20:11:44] x265 [info]: Lookahead / bframes / badapt : 25 / 4 / 2
---[Information] [2015-03-04 20:11:44] x265 [info]: b-pyramid / weightp / weightb / refs: 1 / 1 / 0 / 3
---[Information] [2015-03-04 20:11:44] x265 [info]: Rate Control / AQ-Strength / CUTree : CRF-18.5 / 1.0 / 1
---[Information] [2015-03-04 20:11:44] x265 [info]: tools: rect rd=4 psy-rd=0.30 psy-rdoq=1.00 deblock sao signhide tmvp
---[Error] [2015-03-04 20:12:04] avs [error]: Error occurred while writing frame 38
---[Information] [2015-03-04 20:12:04] (Maybe x265.exe closed)
--[Error] [2015-03-04 20:12:04] Process exits with error: 0xC0000005 STATUS_ACCESS_VIOLATION (-1073741819)

[x265_Project]

I build x265 1.5+141 16bpp and try encoding via MeGUI -- it crashes.
I try 1.5+140 16bpp -- it works via MeGUI.

Log from MeGUI:
---[Information] [2015-03-04 20:12:04] avs4x265 [info]: "C:\MeGUI\tools\x265\x64\x265.exe" - --frames 2041 --fps 24000/1001 --input-res 1920x800 --input-csp i420 --preset slow --crf 18.5 --keyint 288 --colormatrix bt709 --no-info --output F:\m\v\0001.mkv.hevc
--[Error] [2015-03-04 20:11:44] Standard error stream
---[Information] [2015-03-04 20:11:44] yuv [info]: 1920x800 fps 24000/1001 i420p8 unknown frame count
---[Information] [2015-03-04 20:11:44] x265 [info]: HEVC encoder version 1.5+141-e212eee15e98
---[Information] [2015-03-04 20:11:44] x265 [info]: build info [Windows][GCC 4.9.2][64 bit] 16bpp
---[Information] [2015-03-04 20:11:44] x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
---[Information] [2015-03-04 20:11:44] x265 [info]: Main 10 profile, Level-4 (Main tier)
---[Information] [2015-03-04 20:11:44] x265 [info]: Thread pool created using 4 threads
---[Information] [2015-03-04 20:11:44] x265 [info]: frame threads / pool features : 2 / wpp(13 rows)
---[Information] [2015-03-04 20:11:44] x265 [info]: Internal bit depth : 10
---[Information] [2015-03-04 20:11:44] x265 [info]: Coding QT: max CU size, min CU size : 64 / 8
---[Information] [2015-03-04 20:11:44] x265 [info]: Residual QT: max TU size, max depth : 32 / 1 inter / 1 intra
---[Information] [2015-03-04 20:11:44] x265 [info]: ME / range / subpel / merge : star / 57 / 3 / 3
---[Information] [2015-03-04 20:11:44] x265 [info]: Keyframe min / max / scenecut : 23 / 288 / 40
---[Information] [2015-03-04 20:11:44] x265 [info]: Lookahead / bframes / badapt : 25 / 4 / 2
---[Information] [2015-03-04 20:11:44] x265 [info]: b-pyramid / weightp / weightb / refs: 1 / 1 / 0 / 3
---[Information] [2015-03-04 20:11:44] x265 [info]: Rate Control / AQ-Strength / CUTree : CRF-18.5 / 1.0 / 1
---[Information] [2015-03-04 20:11:44] x265 [info]: tools: rect rd=4 psy-rd=0.30 psy-rdoq=1.00 deblock sao signhide tmvp
---[Error] [2015-03-04 20:12:04] avs [error]: Error occurred while writing frame 38
---[Information] [2015-03-04 20:12:04] (Maybe x265.exe closed)
--[Error] [2015-03-04 20:12:04] Process exits with error: 0xC0000005 STATUS_ACCESS_VIOLATION (-1073741819)

Avoid this build... there are definite issues. We're on it.

[x265_Project]

Avoid this build... there are definite issues. We're on it.

Steve just checked in a fix that solves the slow performance I was seeing. Please give the new dev build a try, and let us know if you still see issues.

[Ma]

Steve just checked in a fix that solves the slow performance I was seeing. Please give the new dev build a try, and let us know if you still see issues.

1.5+142 16bpp works via MeGUI.
I use GCC 4.9.2 from mingw-w64 with win32threads.
Thanks for the fix.

[Ajvar]

Anybody wants to compare non-AVX2 performance of new 151 build?

[LigH]

I'll do that very briefly, just have to compile it...

[Ma]

Anybody wants to compare non-AVX2 performance of new 151 build?

16bpp with my test file:
1.5.0.0 | 975.92s | 2.09fps
1.5.0.142 | 993.40s | 2.05fps
1.5.0.151 | 998.18s | 2.04fps

[LigH]

Between v1.5+9 and v1.5+151 (also v1.5+21, v1.5+77) I see hardly any difference. Tested on AMD Phenom-II X4 (max.instruction set: SSE2)

[benwaggoner]

16bpp with my test file:
1.5.0.0 | 975.92s | 2.09fps
1.5.0.142 | 993.40s | 2.05fps
1.5.0.151 | 998.18s | 2.04fps
It would be great to see performance with AVX2 instructions turned on and off on the same AVX2 capable processor.

I expect that that speedup percentage could vary substantially between different presets, so it'd be good to provide the full command line.

[Vesdaris]

Is there any way to reduce blur at medium preset? Maybe via command line specific options?Changing to slow didn't change anything at first glance and fps was totally unacceptable.

Cheers

[jlpsvk]

I am using SLOW preset on i7-4790K....getting around 2.5fps...which is acceptable for me. :)

[Ma]

I decided to make speed test of x265 with special conditions:
- unplug network cable from router,
- turn off antivirus,
- close all other applications,
- run each test twice and take the better result.

Platform: i5 3450S, 16GB DDR3 RAM 1600MHz, Win 7 64bit.
Parametrs: --preset slow --crf 18.5 --keyint 288 --colormatrix bt709 --no-info

Results:
16bpp
1.5.0.000 | 976.53s | 2.09fps | 100.0% | gcc492 -O2 -march=corei7-avx
1.5.0.021 | 984.82s | 2.07fps | 100.8% | LigH gcc482 -O3
1.5.0.027 | 979.67s | 2.08fps | 100.3% | msvc2012
1.5.0.041 | 973.17s | 2.10fps | 99.7% | gcc492 -O2 -march=corei7-avx
1.5.0.129 | 995.47s | 2.05fps | 101.9% | gcc492 -O2 -march=corei7-avx
1.5.0.151 | 992.89s | 2.06fps | 101.7% | gcc492 -O2 -march=corei7-avx

8bpp
1.5.0.000 | 593.88s | 3.44fps | 100.0% | gcc492 -O2 -march=corei7-avx
1.5.0.021 | 603.47s | 3.38fps | 101.6% | LigH gcc482 -O3
1.5.0.027 | 605.70s | 3.37fps | 102.0% | msvc2012
1.5.0.041 | 592.65s | 3.44fps | 99.8% | gcc492 -O2 -march=corei7-avx
1.5.0.129 | 612.45s | 3.33fps | 103.1% | gcc492 -O2 -march=corei7-avx
1.5.0.151 | 610.61s | 3.34fps | 102.8% | gcc492 -O2 -march=corei7-avx

On my system GCC 4.9.2 is faster than 4.8.2, -O2 optimize option is faster than default -O3, -march=corei7-avx is faster than generic build.

My first speed test of 1.5.0.151 was on working computer and wasn't precise.

[x265.cc]

Anybody wants to compare non-AVX2 performance of new 151 build?



x265 Build:
x265 [info]: HEVC encoder version 1.5+175-45deb0125890
x265 [info]: build info [Windows][GCC 4.8.2][64 bit] 8bpp

Hardware:
Intel® Core™ i7-4710HQ Processor
(6M Cache, up to 3.50 GHz)

Test sample:
http://media.xiph.org/video/derf/y4m/720p50_parkrun_ter.y4m

With AVX2:

x265 --asm MMX2,SSE2Fast,SSSE3,SSE4.2,AVX,AVX2,FMA3,LZCNT,BMI2 720p50_parkrun_ter.y4m 720p50_parkrun_ter.hevc

y4m [info]: 1280x720 fps 50/1 i420p8 sar 1:1 frames 0 - 503 of 504
x265 [info]: HEVC encoder version 1.5+175-45deb0125890
x265 [info]: build info [Windows][GCC 4.8.2][64 bit] 8bpp
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
x265 [info]: Main profile, Level-4 (Main tier)
x265 [info]: Thread pool created using 8 threads
x265 [info]: frame threads / pool features : 3 / wpp(12 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 : 25 / 250 / 40
x265 [info]: Lookahead / bframes / badapt : 20 / 4 / 2
x265 [info]: b-pyramid / weightp / weightb / refs: 1 / 1 / 0 / 3
x265 [info]: Rate Control / AQ-Strength / CUTree : CRF-28.0 / 1.0 / 1
x265 [info]: tools: rd=3 rdoq=0 psy-rd=0.30 deblock sao signhide tmvp

x265 [info]: frame I: 4, Avg QP:29.78 kb/s: 23949.00
x265 [info]: frame P: 122, Avg QP:34.06 kb/s: 12920.50
x265 [info]: frame B: 378, Avg QP:40.38 kb/s: 472.61
x265 [info]: global : 504, Avg QP:38.77 kb/s: 3672.11
x265 [info]: Weighted P-Frames: Y:0.0% UV:0.0%
x265 [info]: consecutive B-frames: 3.2% 3.2% 7.9% 61.9% 23.8%

encoded 504 frames in 18.61s (27.08 fps), 3672.11 kb/s

Without AVX2:

x265 --asm MMX2,SSE2Fast,SSSE3,SSE4.2,AVX,FMA3,LZCNT,BMI2 720p50_parkrun_ter.y4m 720p50_parkrun_ter.hevc

y4m [info]: 1280x720 fps 50/1 i420p8 sar 1:1 frames 0 - 503 of 504
x265 [info]: HEVC encoder version 1.5+175-45deb0125890
x265 [info]: build info [Windows][GCC 4.8.2][64 bit] 8bpp
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX FMA3 LZCNT BMI2
x265 [info]: Main profile, Level-4 (Main tier)
x265 [info]: Thread pool created using 8 threads
x265 [info]: frame threads / pool features : 3 / wpp(12 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 : 25 / 250 / 40
x265 [info]: Lookahead / bframes / badapt : 20 / 4 / 2
x265 [info]: b-pyramid / weightp / weightb / refs: 1 / 1 / 0 / 3
x265 [info]: Rate Control / AQ-Strength / CUTree : CRF-28.0 / 1.0 / 1
x265 [info]: tools: rd=3 rdoq=0 psy-rd=0.30 deblock sao signhide tmvp

x265 [info]: frame I: 4, Avg QP:29.78 kb/s: 23949.00
x265 [info]: frame P: 122, Avg QP:34.06 kb/s: 12920.50
x265 [info]: frame B: 378, Avg QP:40.38 kb/s: 472.61
x265 [info]: global : 504, Avg QP:38.77 kb/s: 3672.11
x265 [info]: Weighted P-Frames: Y:0.0% UV:0.0%
x265 [info]: consecutive B-frames: 3.2% 3.2% 7.9% 61.9% 23.8%

encoded 504 frames in 21.73s (23.19 fps), 3672.11 kb/s

[LigH]

New results (http://forum.gleitz.info/showthread.php?46557&p=449921#post449921) with freshly built Mac binaries at tags 1.4, 1.5 and tip (1.5+175) on a Dual Xeon X5675 @ 3.07GHz (2 sockets × 6 physical cores × 2 HT = 24 logical cores):

CPU utilization rises from v1.4 (~1200%/24) to v1.5 (~1400%/24), but drops remarkably for the current version (~900%/24). Yet the speed still rises from v1.4 (4.46 fps) over v1.5 (5.24 fps) to the current (6.60 fps).

So with about a third of the CPU capacity taken by one running encoder, it is even possible to run three encoders in parallel to utilize the CPU well (up to 2400%/24).

[benwaggoner]

x265 Build:
With AVX2: encoded 504 frames in 18.61s (27.08 fps), 3672.11 kb/s

Without AVX2:encoded 504 frames in 21.73s (23.19 fps), 3672.11 kb/s

So, 17% faster on the same hardware by just turning on an instruction set? Pretty impressive, and significantly larger than the similar post-SSE2 instruction-set gains I remember from x265.

I wonder what the comparison would look like with --preset slower or veryslow.

[FranceBB]

Compiled builds for Windows XP either, enjoy: https://mega.co.nz/#!fFUm2KZQ!FxMu8xKqzKVG2x7HnV1FyJO0htp-5-bdUp5c_g_jctI

As to the speed, I can tell that using GCC, ICC or Visual Studio there is a slight difference. With a silly encode with preset "medium", crf 20 and everything on default, GCC build run at 9.34 fps, ICC build run at 9.43 and Visual Studio build run at 9.46 on the same video with the same settings.

Anyway, I'll keep supporting xp 'cause there are still a lot of people using that OS.

[benwaggoner]

Anyway, I'll keep supporting xp 'cause there are still a lot of people using that OS.
That said, professional and prosumer encoding really should have moved to at least Windows 7/Windows Server 2008 R2 64-bit by now. XP proper is 32-bit only, which is significantly slower in general and even a 3 GiB process isn't enough memory for decent UHD encoding (and even 3 GiB assumes a large address aware build).

Also, Windows wasn't properly NUMA aware until Vista, so modern Windows versions should get at least a 10% speed boost compared to XP on the same hardware multi-socket hardware.

Now, given my backup encoding workstation is a dual-socket 12 core Sandy Bridge with 24 GiB of RAM, I might come off as a little elitist :). But Windows 7 64-bit will definitely encode significantly faster than XP on any hardware build this millennium. And given how memory and CPU hungry x265 and HEVC are, that's going to matter more than ever. x264 may be fast enough that speed doesn't count for a lot of scenarios, but last night I got 0.13 fps encodes on my 16 core Ivy Bridge (granted, high quality UHD 10-bit encoding). Even a 10% speed boost matters! And I bet it's ~20% faster than what stock XP would do running the same hardware.

As you say, there are people on XP 32-bit still and it's good to let them play with HEVC. But we should really be encouraging everyone to upgrade.

[Khanattila]

Compiled builds for Windows XP either, enjoy: https://mega.co.nz/#!fFUm2KZQ!FxMu8xKqzKVG2x7HnV1FyJO0htp-5-bdUp5c_g_jctI

As to the speed, I can tell that using GCC, ICC or Visual Studio there is a slight difference. With a silly encode with preset "medium", crf 20 and everything on default, GCC build run at 9.34 fps, ICC build run at 9.43 and Visual Studio build run at 9.46 on the same video with the same settings.

Anyway, I'll keep supporting xp 'cause there are still a lot of people using that OS.

So, GCC 100.00%, VS 100.96%, ICC, 101.28%.
Below < 2% may be normal fluctuation.

EDIT. In addition, support an operating system dead? I do not understand why.

[jkauff]

I am using SLOW preset on i7-4790K....getting around 2.5fps...which is acceptable for me. :)
I have exactly the same setup, running at 4.7. Using Slow preset and 20 crf (defaults otherwise) on an AVC source gets me into the 3+ fps range, depending on the source material. What crf are you using?

[Ajvar]

Dear MA and x265cc, thank you very much for your benches.

Is there any way to reduce blur at medium preset? Maybe via command line specific options?Changing to slow didn't change anything at first glance and fps was totally unacceptable.

Cheers

Someone wrote this: I tried and found the deblock [-3 and below] and rdoq [+30 and above] affect the deblurring much.

[FranceBB]

@benwaggoner... indeed. I personally do my tests on Windows Server 2008 r2 on an intel i7-5960X and 16 GB of ram, anyway it was just two or three seconds in order to support xp.

Anyway, I really suggest to upgrade to win 8.1 and, of course, to a 64bit version, 'cause with x265 it should be an obligation.

@Khanattila... I see.

[x265.cc]

I wonder what the comparison would look like with --preset slower or veryslow.


x265 Build:

x265 [info]: HEVC encoder version 1.5+186-043c2418864b
x265 [info]: build info [Windows][GCC 4.8.2][64 bit] 8bpp

Hardware:

Intel® Core™ i7-4770 Processor
(8M Cache, up to 3.90 GHz)

Test sample:

http://media.xiph.org/video/derf/y4m/720p50_parkrun_ter.y4m

SLOW with AVX2:

x265 --preset slow --asm MMX2,SSE2Fast,SSSE3,SSE4.2,AVX,AVX2,FMA3,LZCNT,BMI2 720p50_parkrun_ter.y4m 720p50_parkrun_ter.hevc
y4m [info]: 1280x720 fps 50/1 i420p8 sar 1:1 frames 0 - 503 of 504
x265 [info]: HEVC encoder version 1.5+186-043c2418864b
x265 [info]: build info [Windows][GCC 4.8.2][64 bit] 8bpp
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
x265 [info]: Main profile, Level-4 (Main tier)
x265 [info]: Thread pool created using 8 threads
x265 [info]: frame threads / pool features : 3 / wpp(12 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 : star / 57 / 3 / 3
x265 [info]: Keyframe min / max / scenecut : 25 / 250 / 40
x265 [info]: Lookahead / bframes / badapt : 25 / 4 / 2
x265 [info]: b-pyramid / weightp / weightb / refs: 1 / 1 / 0 / 3
x265 [info]: Rate Control / AQ-Strength / CUTree : CRF-28.0 / 1.0 / 1
x265 [info]: tools: rect rd=4 rdoq=2 psy-rd=0.30 psy-rdoq=1.00 deblock sao signhide tmvp

x265 [info]: frame I: 4, Avg QP:29.68 kb/s: 20795.60
x265 [info]: frame P: 120, Avg QP:33.87 kb/s: 13405.47
x265 [info]: frame B: 380, Avg QP:40.42 kb/s: 443.83
x265 [info]: global : 504, Avg QP:38.77 kb/s: 3691.46
x265 [info]: Weighted P-Frames: Y:0.0% UV:0.0%
x265 [info]: consecutive B-frames: 3.2% 3.2% 8.1% 54.8% 30.6%

encoded 504 frames in 47.97s (10.51 fps), 3691.46 kb/s

SLOW without AVX2:

x265 --preset slow --asm MMX2,SSE2Fast,SSSE3,SSE4.2,AVX,FMA3,LZCNT,BMI2 720p50_parkrun_ter.y4m 720p50_parkrun_ter.hevc
y4m [info]: 1280x720 fps 50/1 i420p8 sar 1:1 frames 0 - 503 of 504
x265 [info]: HEVC encoder version 1.5+186-043c2418864b
x265 [info]: build info [Windows][GCC 4.8.2][64 bit] 8bpp
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX FMA3 LZCNT BMI2
x265 [info]: Main profile, Level-4 (Main tier)
x265 [info]: Thread pool created using 8 threads
x265 [info]: frame threads / pool features : 3 / wpp(12 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 : star / 57 / 3 / 3
x265 [info]: Keyframe min / max / scenecut : 25 / 250 / 40
x265 [info]: Lookahead / bframes / badapt : 25 / 4 / 2
x265 [info]: b-pyramid / weightp / weightb / refs: 1 / 1 / 0 / 3
x265 [info]: Rate Control / AQ-Strength / CUTree : CRF-28.0 / 1.0 / 1
x265 [info]: tools: rect rd=4 rdoq=2 psy-rd=0.30 psy-rdoq=1.00 deblock sao signhide tmvp

x265 [info]: frame I: 4, Avg QP:29.68 kb/s: 20795.60
x265 [info]: frame P: 120, Avg QP:33.87 kb/s: 13405.47
x265 [info]: frame B: 380, Avg QP:40.42 kb/s: 443.83
x265 [info]: global : 504, Avg QP:38.77 kb/s: 3691.46
x265 [info]: Weighted P-Frames: Y:0.0% UV:0.0%
x265 [info]: consecutive B-frames: 3.2% 3.2% 8.1% 54.8% 30.6%

encoded 504 frames in 54.92s (9.18 fps), 3691.46 kb/s

VERYSLOW with AVX2:

x265 --preset veryslow --asm MMX2,SSE2Fast,SSSE3,SSE4.2,AVX,AVX2,FMA3,LZCNT,BMI2 720p50_parkrun_ter.y4m 720p50_parkrun_ter.hevc
y4m [info]: 1280x720 fps 50/1 i420p8 sar 1:1 frames 0 - 503 of 504
x265 [info]: HEVC encoder version 1.5+186-043c2418864b
x265 [info]: build info [Windows][GCC 4.8.2][64 bit] 8bpp
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
x265 [info]: Main profile, Level-4 (Main tier)
x265 [info]: Thread pool created using 8 threads
x265 [info]: frame threads / pool features : 3 / wpp(12 rows)
x265 [info]: Coding QT: max CU size, min CU size : 64 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 3 inter / 3 intra
x265 [info]: ME / range / subpel / merge : star / 57 / 4 / 4
x265 [info]: Keyframe min / max / scenecut : 25 / 250 / 40
x265 [info]: Lookahead / bframes / badapt : 40 / 8 / 2
x265 [info]: b-pyramid / weightp / weightb / refs: 1 / 1 / 1 / 5
x265 [info]: Rate Control / AQ-Strength / CUTree : CRF-28.0 / 1.0 / 1
x265 [info]: tools: rect amp rd=6 rdoq=2 psy-rd=0.30 psy-rdoq=1.00 deblock sao signhide b-intra tmvp

x265 [info]: frame I: 4, Avg QP:29.61 kb/s: 21206.10
x265 [info]: frame P: 106, Avg QP:33.62 kb/s: 14368.77
x265 [info]: frame B: 394, Avg QP:40.44 kb/s: 477.05
x265 [info]: global : 504, Avg QP:38.92 kb/s: 3563.24
x265 [info]: Weighted P-Frames: Y:0.0% UV:0.0%
x265 [info]: Weighted B-Frames: Y:0.0% UV:0.0%
x265 [info]: consecutive B-frames: 3.6% 0.0% 7.3% 51.8% 16.4% 10.0% 6.4% 1.8% 2.7%

encoded 504 frames in 268.37s (1.88 fps), 3563.24 kb/s

VERYSLOW without AVX2:

x265 --preset veryslow --asm MMX2,SSE2Fast,SSSE3,SSE4.2,AVX,FMA3,LZCNT,BMI2 720p50_parkrun_ter.y4m 720p50_parkrun_ter.hevc
y4m [info]: 1280x720 fps 50/1 i420p8 sar 1:1 frames 0 - 503 of 504
x265 [info]: HEVC encoder version 1.5+186-043c2418864b
x265 [info]: build info [Windows][GCC 4.8.2][64 bit] 8bpp
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX FMA3 LZCNT BMI2
x265 [info]: Main profile, Level-4 (Main tier)
x265 [info]: Thread pool created using 8 threads
x265 [info]: frame threads / pool features : 3 / wpp(12 rows)
x265 [info]: Coding QT: max CU size, min CU size : 64 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 3 inter / 3 intra
x265 [info]: ME / range / subpel / merge : star / 57 / 4 / 4
x265 [info]: Keyframe min / max / scenecut : 25 / 250 / 40
x265 [info]: Lookahead / bframes / badapt : 40 / 8 / 2
x265 [info]: b-pyramid / weightp / weightb / refs: 1 / 1 / 1 / 5
x265 [info]: Rate Control / AQ-Strength / CUTree : CRF-28.0 / 1.0 / 1
x265 [info]: tools: rect amp rd=6 rdoq=2 psy-rd=0.30 psy-rdoq=1.00 deblock sao signhide b-intra tmvp

x265 [info]: frame I: 4, Avg QP:29.61 kb/s: 21206.10
x265 [info]: frame P: 106, Avg QP:33.62 kb/s: 14368.77
x265 [info]: frame B: 394, Avg QP:40.44 kb/s: 477.05
x265 [info]: global : 504, Avg QP:38.92 kb/s: 3563.24
x265 [info]: Weighted P-Frames: Y:0.0% UV:0.0%
x265 [info]: Weighted B-Frames: Y:0.0% UV:0.0%
x265 [info]: consecutive B-frames: 3.6% 0.0% 7.3% 51.8% 16.4% 10.0% 6.4% 1.8% 2.7%

encoded 504 frames in 299.25s (1.68 fps), 3563.24 kb/s

[mandarinka]

I thought it could be interesting comparison, so here is the same source as in the last post also with veryslow, on AMD A8-3850 (4 x 2,9 GHz K10 - no turbo - without SSE4/SSSE3). Done with builds from this post: http://forum.doom9.org/showthread.php?p=1711464#post1711464

N:\>x265 --preset veryslow 720p50_parkrun_ter.y4m 720p50_parkrun_ter.hevc
y4m [info]: 1280x720 fps 50/1 i420p8 sar 1:1 frames 0 - 503 of 504
x265 [info]: HEVC encoder version 1.5+128-394c2f94a2dc
x265 [info]: build info [Windows][GCC 4.8.2][64 bit] 8bpp
x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT
x265 [info]: Main profile, Level-4 (Main tier)
x265 [info]: Thread pool created using 4 threads
x265 [info]: frame threads / pool features : 2 / wpp(12 rows)
x265 [info]: Coding QT: max CU size, min CU size : 64 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 3 inter / 3 intra
x265 [info]: ME / range / subpel / merge : star / 57 / 4 / 4
x265 [info]: Keyframe min / max / scenecut : 25 / 250 / 40
x265 [info]: Lookahead / bframes / badapt : 40 / 8 / 2
x265 [info]: b-pyramid / weightp / weightb / refs: 1 / 1 / 1 / 5
x265 [info]: Rate Control / AQ-Strength / CUTree : CRF-28.0 / 1.0 / 1
x265 [info]: tools: rect amp rd=6 psy-rd=0.30 psy-rdoq=1.00 deblock sao signhide b-intra tmvp
x265 [info]: frame I: 4, Avg QP:29.61 kb/s: 21194.10
x265 [info]: frame P: 106, Avg QP:33.61 kb/s: 14371.58
x265 [info]: frame B: 394, Avg QP:40.43 kb/s: 489.85
x265 [info]: global : 504, Avg QP:38.91 kb/s: 3573.74
x265 [info]: Weighted P-Frames: Y:0.0% UV:0.0%
x265 [info]: Weighted B-Frames: Y:0.0% UV:0.0%
x265 [info]: consecutive B-frames: 3.6% 0.0% 8.2% 50.0% 16.4% 11.8% 5.5% 1.8% 2.7%

encoded 504 frames in 2078.31s (0.24 fps), 3573.74 kb/s

I think I'll try with Atom Z3740, maybe.

Edit: okay, this was interesting.

D:\>x265 --preset veryslow 720p50_parkrun_ter.y4m 720p50_parkrun_ter.hevc
y4m [info]: 1280x720 fps 50/1 i420p8 sar 1:1 frames 0 - 503 of 504
x265 [info]: HEVC encoder version 1.5+128-394c2f94a2dc
x265 [info]: build info [Windows][GCC 4.8.2][32 bit] 8bpp
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2
x265 [info]: Main profile, Level-4 (Main tier)
x265 [info]: Thread pool created using 4 threads
x265 [info]: frame threads / pool features : 2 / wpp(12 rows)
x265 [info]: Coding QT: max CU size, min CU size : 64 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 3 inter / 3 intra
x265 [info]: ME / range / subpel / merge : star / 57 / 4 / 4
x265 [info]: Keyframe min / max / scenecut : 25 / 250 / 40
x265 [info]: Lookahead / bframes / badapt : 40 / 8 / 2
x265 [info]: b-pyramid / weightp / weightb / refs: 1 / 1 / 1 / 5
x265 [info]: Rate Control / AQ-Strength / CUTree : CRF-28.0 / 1.0 / 1
x265 [info]: tools: rect amp rd=6 psy-rd=0.30 psy-rdoq=1.00 deblock sao signhide b-intra tmvp
x265 [info]: frame I: 4, Avg QP:29.61 kb/s: 21194.10
x265 [info]: frame P: 106, Avg QP:33.61 kb/s: 14371.58
x265 [info]: frame B: 394, Avg QP:40.43 kb/s: 489.85
x265 [info]: global : 504, Avg QP:38.91 kb/s: 3573.74
x265 [info]: Weighted P-Frames: Y:0.0% UV:0.0%
x265 [info]: Weighted B-Frames: Y:0.0% UV:0.0%
x265 [info]: consecutive B-frames: 3.6% 0.0% 8.2% 50.0% 16.4% 11.8% 5.5% 1.8% 2.7%

encoded 504 frames in 2250.35s (0.22 fps), 3573.74 kb/s


This was run on 32-bit Win8.1 with Asus Transformer T100TA, while the one before was Win8.1 64 though. So actually the Atom might even be same speed if it wasn't hampered by 32bit mode (but remember that this is due to the Llano not having SSE4). I think it ran on full turbo (1.83 GHz) on all cores during the whole test. Base clock is 1.33 GHz and that would prolly not be enough.

[birdie]

I have found a video clip x265 struggles to encode efficiently.

Here it is Megascans_Jungle.mp4 (https://d85clmw03d1co.cloudfront.net/megascans/Megascans_Jungle.mp4) (pretty much lossless considering its bitrate):

Duration: 00:01:22.05, start: 0.000000, bitrate: 53106 kb/s
Stream #0:0(eng): Video: h264 (High) (avc1 / 0x31637661), yuv420p(tv, bt709), 1920x1080 [SAR 1:1 DAR 16:9], 52812 kb/s, 30 fps, 30 tbr, 30k tbn, 60 tbc (default)

At CRF 18 (preset=veryslow crf=18, no other options used) I get 22716 kb/s bitrate which is kinda insane.

I'm not a video expert, but CRF 18 for x265 equals approximately CRF 21 for x264 and usually x264 1080p/30fps clips with this quality have a substantially lower bitrate.

[jlpsvk]

where did you get that crf calculation between x264 and x265? I think, that's simply not true. CRF 20 with x265 at SLOW preset look like CRF17-18 with x264 PLACEBO.

[x265_Project]

I have found a video clip x265 struggles to encode efficiently.

Here it is Megascans_Jungle.mp4 (https://d85clmw03d1co.cloudfront.net/megascans/Megascans_Jungle.mp4) (pretty much lossless considering its bitrate):

Duration: 00:01:22.05, start: 0.000000, bitrate: 53106 kb/s
Stream #0:0(eng): Video: h264 (High) (avc1 / 0x31637661), yuv420p(tv, bt709), 1920x1080 [SAR 1:1 DAR 16:9], 52812 kb/s, 30 fps, 30 tbr, 30k tbn, 60 tbc (default)

At CRF 18 (preset=veryslow crf=18, no other options used) I get 22716 kb/s bitrate which is kinda insane.

I'm not a video expert, but CRF 18 for x265 equals approximately CRF 21 for x264 and usually x264 1080p/30fps clips with this quality have a substantially lower bitrate.
Thanks for the tip. This is a very interesting source sequence; lots of detail and a fair amount of motion. I'm not surprised that it ends up at 22.7 Mbps with CRF 18. This is a very low CRF setting, producing much higher quality than the default value of --crf 28. As with any encoder, it's easy to produce insane bit rates if you set your quality level high enough. The law of diminishing returns applies to x265. Once you reach a high enough quality level, for each incremental improvement in quality your bit rate will increase substantially (the slope of the rate distortion curve flattens out at high quality levels).

You can either try raising your CRF value, or use 2 pass ABR to target your desired bit rate. You could also use "capped VBR" encoding (CRF with VBV to cap the max bitrate).

[VelleX]

I'm not a video expert, but CRF 18 for x265 equals approximately CRF 21 for x264 and usually x264 1080p/30fps clips with this quality have a substantially lower bitrate.

@ApTeM

With x265 and crf18 i got about 23,1mbps and with x264 and crf22 i got about the same, 22,6mbps.

As x265_Project wrote, this clip has much detail and some motion, so its not comparable to maybe a movie clip or something similar.

I Also tested this 4K Clip, resized to 1080p
https://media.xiph.org/video/derf/y4m/crowd_run_2160p50.y4m

With x265 and crf18 i got about 35mbps because of much motion in this sports clip. Also with crf20 its still above 20mbps.

[Ma]

I decided to compare today updated stable branch (1.5+9) with default branch (1.5+197).

2401 frames with resolution 1920x800, parameters: --preset slow --crf 18.5 --keyint 288 --colormatrix bt709 --no-info

16bpp
1.5.0.009 | 977.33s | 2.09fps | 100.0% | stable branch, Win64, -march=corei7-avx
1.5.0.197 | 994.44s | 2.05fps | 101.8% | default branch, Win64, -march=corei7-avx
1.5.0.009 | 1189.8s | 1.72fps | 121.7% | stable branch, Win32
1.5.0.197 | 6748.3s | 0.30fps | 690.5% | default branch, Win32

I've heard that Win32 applications are slower than Win64 and build without assembly is much slower than build with assembly, but the numbers are more convincing.

[Ajvar]

I decided to compare today updated stable branch (1.5+9) with default branch (1.5+197).

2401 frames with resolution 1920x800, parameters: --preset slow --crf 18.5 --keyint 288 --colormatrix bt709 --no-info

16bpp
1.5.0.009 | 977.33s | 2.09fps | 100.0% | stable branch, Win64, -march=corei7-avx
1.5.0.197 | 994.44s | 2.05fps | 101.8% | default branch, Win64, -march=corei7-avx
1.5.0.009 | 1189.8s | 1.72fps | 121.7% | stable branch, Win32
1.5.0.197 | 6748.3s | 0.30fps | 690.5% | default branch, Win32

I've heard that Win32 applications are slower than Win64 and build without assembly is much slower than build with assembly, but the numbers are more convincing.

Wow. If this is true and not compiler's problem then you clearly found a bug in 1.5+196 build's behavior on x86 OS which x265 devs should look at. I assume you use Snowfag's builds from http://builds.x265.eu/
Nice job anyways. Thanks.

[LigH]

This is no bug, this is either unavoidable (32 bit code is slower than 64 bit code already due to less and shorter registers) or intentional (no more assembler optimization for 32 bit code and 16 bit depth, because it's just a waste of time: Assembly with less than SSE4 is pointless for 16 bit depth, SSE4+/AVX+ capable CPUs also support 64 bit code, therefore should be used with 64 bit OS).

At least I believe that was the intention of the developers, if I interpreted the initial patch remark correctly.
__

P.S.:

After some compiling issues due to removing assembler optimization from 32 bit code with 16 bit depth, I finished another package today: x265 1.5+200-726fe4088f31 (https://www.mediafire.com/download/z22jj82m45y18na/x265_1.5+200-726fe4088f31.7z)

There is a rather new option --rdoq-level (http://x265.readthedocs.org/en/default/cli.html#cmdoption--rdoq-level) (maybe just recently published to the CLI). It uses more elaborate RD cost calculations in two steps. The second causes less impact of Psy-RDOQ on the final quantization.

The presets (http://x265.readthedocs.org/en/default/presets.html) use value 2 from "slow" on, else 0.

[Ma]

Wow. If this is true and not compiler's problem then you clearly found a bug in 1.5+196 build's behavior on x86 OS which x265 devs should look at. I assume you use Snowfag's builds from http://builds.x265.eu/
Nice job anyways. Thanks.

I use my own builds.

Now in default branch if you want to build Win32 16bpp version you must turn off assembly. I was curious how this affect encoding speed on my system. Of course this is not real comparison because I can encode with Win64 builds. If you can't use Win64 builds your CPU is probably old and can't use all assembly optimizations so the difference should be smaller.

[Motenai Yoda]

There is a rather new option --rdoq-level (http://x265.readthedocs.org/en/default/cli.html#cmdoption--rdoq-level) (maybe just recently published to the CLI). It uses more elaborate RD cost calculations in two steps. The second causes less impact of Psy-RDOQ on the final quantization.

The presets (http://x265.readthedocs.org/en/default/presets.html) use value 2 from "slow" on, else 0.
It's me or now --rdoq-level (or rdoq) 1+ is mandatory to enable psy-rdoq? rather than rd4

If I'm not wrong with --rdoq-level 1 psy-rdoq works as ever (maybe slight better), with --rdoq-level 2 it will be effective only when even the entire 4x4 coding group, and not the single block, need it, discarding so ie flat areas and so extremely less bitrate-hungry than --rdoq-level 1 (a sort of rdoq masking).

But seems enabling rdoq will now slow down more than old one (22/15fps v1.5 vs 14/13fps v1.4) maybe coz now rd3=rd4.

[LigH]

In coming versions, RD levels will be reduced to 0..4 (because 3=4 and 5=6); furthermore, ultrafast and superfast presets will be tweaked.

[stax76]

There is a rather new option --rdoq-level (maybe just recently published to the CLI). It uses more elaborate RD cost calculations in two steps. The second causes less impact of Psy-RDOQ on the final quantization.

The presets use value 2 from "slow" on, else 0.


Thanks for keeping us up to date with options and defaults, very helpful!

[x265_Project]

In coming versions, RD levels will be reduced to 0..4 (because 3=4 and 5=6)
True, but unless you manually set rdlevel (not recommended), this is mainly an internal change.
ultrafast and superfast presets will be tweaked.
The more important commit (https://bitbucket.org/multicoreware/x265/commits/c1a8eef8be143a40981ae6909c6c8c3a6b85901c) to notice is the change in the ultrafast preset. We found that restricting --merange to a value below 57 did not improve speed, but slightly reduced efficiency. We also found that --bframes 3 gave slightly higher performance than --bframes 4. We are now restricting --min-cu-size to 16 in ultrafast. This change will significantly improve encoding speed (~ 28% faster), as x265 doesn't bother to evaluate 8x8 CUs. There is a moderate impact on efficiency (depends on the content, but overall for a set of different 20 clips, this change reduced SSIM from 12.21 dB to 12.01 dB... we got back to 12.10 by changing merange and bframes). So now you'll see a bigger difference in speed between the superfast preset and ultrafast.

[Ajvar]

We found that restricting --merange to a value below 57 did not improve speed, but slightly reduced efficiency.

Speaking about I read on x265 site (http://x265.readthedocs.org/en/latest/cli.html) that 57 was due to 64-4-2 and then inus one extra pixel just in case the hex search method is used. Considering that user doubtfully with preset placebo and very slow will use HEX search method you could set 58 merange.
Also I manually set 58 for every encoding with star method, not sure if it gives any noticeable difference in efficiency.

[jlpsvk]

@Stax76
In latest beta, rdoq-level is forced to 0 even if I set the preset to SLOW (on which the default is 2). Bug or feature?

[RBX]

Is something wrong with rdoq setting? I've been using 1.5.27 with settings crf 18, preset slow, deblock -1, psy-rd 0.4, rc-lookahead 32 for some 720p vidoes on my laptop (i7 2630QM) and I used to get around 40% reduction in size at almost same visual quality as source.
Today I downloaded 1.5.245 and tried encoding a similar video with length 22m45s @575MB and noticed around 2h increase in estimated time required, and then saw param rdoq set to 2. I let the video be encoded hoping better compression, and 5.5 hours later the resultant file's size is around 3x the source's size @1.54GB. Moreover, the length was reduced to 8m9s (maybe I ran out of space in drive C).

Edit: I couldn't find an older version, so I encoded the same video using 1.5.27 16bpp vesion I had, and the same settings produced a file of size 286MB. So what does this --rdoq-level setting do to cause such huge differences in file size?

[stax76]

@Stax76
In latest beta, rdoq-level is forced to 0 even if I set the preset to SLOW (on which the default is 2). Bug or feature?

Maybe there is a bug, here it looks like this:

http://oi57.tinypic.com/szu4qx.jpg

[Ma]

I've made comparison between current x265 16bpp on stable (1.5+17) and on default (1.5+258) branch. Presets from fast to placebo, test file 720p50_parkrun_ter.y4m.

x265 --preset fast --crf 18 720p50_parkrun_ter.y4m 720p50_parkrun_ter.hevc
stable 1.5+17
x265 [info]: tools: rd=2 psy-rd=0.30 deblock sao signhide fast-intra tmvp
encoded 504 frames in 32.04s (15.73 fps), 19217.34 kb/s
default 1.5+258
x265 [info]: tools: rd=2 rdoq=0 psy-rd=0.30 deblock sao signhide fast-intra tmvp
encoded 504 frames in 32.59s (15.47 fps), 19208.64 kb/s

x265 --preset medium --crf 18 720p50_parkrun_ter.y4m 720p50_parkrun_ter.hevc
stable 1.5+17
x265 [info]: tools: rd=3 psy-rd=0.30 deblock sao signhide tmvp
encoded 504 frames in 51.48s (9.79 fps), 21811.92 kb/s
default 1.5+258
x265 [info]: tools: rd=3 rdoq=0 psy-rd=0.30 deblock sao signhide tmvp
encoded 504 frames in 52.18s (9.66 fps), 21806.25 kb/s

x265 --preset slow --crf 18 720p50_parkrun_ter.y4m 720p50_parkrun_ter.hevc
stable 1.5+17
x265 [info]: tools: rect rd=4 psy-rd=0.30 psy-rdoq=1.00 deblock sao signhide tmvp
encoded 504 frames in 147.72s (3.41 fps), 24253.88 kb/s
default 1.5+258
x265 [info]: tools: rect rd=4 rdoq=2 psy-rd=0.30 psy-rdoq=1.00 deblock sao signhide tmvp
encoded 504 frames in 146.68s (3.44 fps), 24243.95 kb/s

x265 --preset slower --crf 18 720p50_parkrun_ter.y4m 720p50_parkrun_ter.hevc
stable 1.5+17
x265 [info]: tools: rect amp rd=6 psy-rd=0.30 psy-rdoq=1.00 deblock sao signhide b-intra tmvp
encoded 504 frames in 616.85s (0.82 fps), 21859.22 kb/s
default 1.5+258
x265 [info]: tools: rect amp rd=6 rdoq=2 psy-rd=0.30 psy-rdoq=1.00 deblock sao signhide b-intra tmvp
encoded 504 frames in 615.08s (0.82 fps), 21760.06 kb/s

x265 --preset veryslow --crf 18 720p50_parkrun_ter.y4m 720p50_parkrun_ter.hevc
stable 1.5+17
x265 [info]: tools: rect amp rd=6 psy-rd=0.30 psy-rdoq=1.00 deblock sao signhide b-intra tmvp
encoded 504 frames in 924.14s (0.55 fps), 21951.46 kb/s
default 1.5+277
x265 [info]: tools: rect amp rd=6 rdoq=2 psy-rd=0.30 psy-rdoq=1.00 deblock sao signhide b-intra tmvp
encoded 504 frames in 954.37s (0.53 fps), 21952.69 kb/s

x265 --preset placebo --crf 18 720p50_parkrun_ter.y4m 720p50_parkrun_ter.hevc
stable 1.5+17
x265 [info]: tools: rect amp rd=6 psy-rd=0.30 psy-rdoq=1.00 deblock sao signhide b-intra tmvp tskip
encoded 504 frames in 1329.03s (0.38 fps), 22108.24 kb/s
default 1.5+277
x265 [info]: tools: rect amp rd=6 rdoq=2 psy-rd=0.30 psy-rdoq=1.00 deblock sao signhide b-intra tmvp tskip
encoded 504 frames in 1440.43s (0.35 fps), 22103.18 kb/s

If someone wants to choose preset that gives smallest output file with crf 18 (for example), preset slow is the worst. It is better to use preset medium or slower.

[jlpsvk]

Maybe there is a bug, here it looks like this

After I have upgraded to the new version, I had my own preset created with preset SLOW and new version automatically adds "rdoq-level 0" to command line even with preset SLOW selected. :(

[LigH]

Another "weekly" again: x265 1.5+258-6461985f33ac (https://www.mediafire.com/download/hhhxruvvefdthn9/x265_1.5+258-6461985f33ac.7z)

[sborho]

about 32bit 16bpp builds:

x265 has tried to prevent this build option outright in the cmake configs for more than a year now because it is too easy to hit memory address-space limits at slower presets and large resolutions. Disabling assembly with this build option was a way to limit having to test and maintain assembly code for an unsupported build option. We still strongly recommend against 32bit 16bpp builds.

about rdoq-level:

Before introducing --rdoq-level, --rd-level 4, 5, or 6 implied what is now --rdoq-level 2. After --rdoq-level, it's enablement is independent of --rd-level but the presets which used to enable it (>= slow) still do. --rdoq-level 1 is actually the same as --rdoq-level 2 except for two short-cuts which prevent certain decimations, which means --rdoq-level 2 can often reduce bitrate quite a bit more than --rdoq-level 1, but --rdoq-level 1 will generally be better at preserving fine detail at the same bitrate (particularly when psy-rdoq is enabled).

[hector1980]

hi
what is the best app for encoding to hevc x265 with advanced settings?

[Ma]

I couldn't find an older version, so I encoded the same video using 1.5.27 16bpp vesion I had, and the same settings produced a file of size 286MB. So what does this --rdoq-level setting do to cause such huge differences in file size?

Yes, numbers:

x265 --preset slow --crf 18 --no-rdoq-level 720p50_parkrun_ter.y4m 720p50_parkrun_ter.hevc
encoded 504 frames in 126.42s (3.99 fps), 21445.36 kb/s

x265 --preset slow --crf 18 720p50_parkrun_ter.y4m 720p50_parkrun_ter.hevc
encoded 504 frames in 148.96s (3.38 fps), 24243.95 kb/s

x265 --preset slow --crf 18 --rdoq-level 1 720p50_parkrun_ter.y4m 720p50_parkrun_ter.hevc
encoded 504 frames in 143.56s (3.51 fps), 25158.41 kb/s

[stax76]

After I have upgraded to the new version, I had my own preset created with preset SLOW and new version automatically adds "rdoq-level 0" to command line even with preset SLOW selected. :(

It's a update/init issue requiring a deeper look in my design, the preset and tuning feature adds complexity, for now you have to update your profiles, projects and templates manually, you can reset x265 options to their defaults by double-clicking the label.

[LigH]

hi
what is the best app for encoding to hevc x265 with advanced settings?

A console. At least for me. I prefer batch scripting over any mouse-driven GUI. Your preferences may be different. But I don't know yours. What is important for you? By the way, many GUI authors may not yet try to support all advanced x265 options as long as the set of options keeps changing from week to week...

[benwaggoner]

A console. At least for me. I prefer batch scripting over any mouse-driven GUI. Your preferences may be different. But I don't know yours. What is important for you? By the way, many GUI authors may not yet try to support all advanced x265 options as long as the set of options keeps changing from week to week...
I concur. There's never been a GUI that exposed all the parameters I wanted to use at the same time.

[stax76]

Have you tried StaxRip? It exposes over 80 x265 switches and has useful features like a search to quickly navigate to an option or context sensitive help.

[Ma]

hi
what is the best app for encoding to hevc x265 with advanced settings?

MeGUI

[Motenai Yoda]

If someone wants to choose preset that gives smallest output file with crf 18 (for example), preset slow is the worst. It is better to use preset medium or slower.
but slow gives better quality than medium for the same crf or size...

but --rdoq-level 1 will generally be better at preserving fine detail at the same bitrate (particularly when psy-rdoq is enabled).
As I tested, just on 2/3 anime source, -preset medium --rdoq-level 2 --psy-rdoq 1.0, gives comparable output size than w/o rdoq, and, for the same size (about a point smaller crf), even better overall quality.

[LigH]

I concur.

:o Sorry for off-topic; just found another "false friend" for a German (non-native) English speaker:
"concur" [engl.] ~ agree/contribute/cooperate; "Konkurrent" [ger./lat.?] = competitor, business rival :rolleyes:
__

Indeed, stax76 is trying to keep up closely with the x265 development.

[xooyoozoo]

It turned out that to get "generalized P/B frames" (B-frame with both motion vectors pointing in the same direction), you'd only need trivial tweaks to some of x265's conditionals. I thought these results were interesting.

Normal:

x265 --crf 20 --preset veryslow --tune ssim --bframes 3

x265 [debug]: POC:99 P QP 23.27(25) 118048 bits RF:0.250 [SSIM: 16.784dB] [L0 96 94 92 90 88 ]
x265 [debug]: POC:98 B QP 24.38(27) 39832 bits RF:0.250 [SSIM: 16.978dB] [L0 96 94 92 90 86 ] [L1 99 ]
x265 [debug]: POC:97 b QP 25.48(28) 22112 bits RF:0.250 [SSIM: 17.187dB] [L0 96 94 92 90 ] [L1 98 99 ]
x265 [info]: frame I: 1, Avg QP:17.47 kb/s: 51097.60 SSIM Mean: 0.991970 (20.953dB)
x265 [info]: frame P: 25, Avg QP:18.06 kb/s: 20091.48 SSIM Mean: 0.987548 (19.048dB)
x265 [info]: frame B: 74, Avg QP:24.62 kb/s: 1090.81 SSIM Mean: 0.981455 (17.318dB)
x265 [info]: global : 100, Avg QP:22.91 kb/s: 6341.04 SSIM Mean: 0.983084 (17.717dB)

encoded 100 frames in 94.45s (1.06 fps), 6341.04 kb/s, SSIM Mean Y: 0.9830838 (17.717 dB)


GPB:

x265 [debug]: POC:99 P QP 23.27(25) 107656 bits RF:0.250 [SSIM: 16.866dB] [L0 96 94 92 90 88 ] [L1 96 94 ]
x265 [debug]: POC:98 B QP 24.38(27) 39448 bits RF:0.250 [SSIM: 16.997dB] [L0 96 94 92 90 86 ] [L1 99 96 ]
x265 [debug]: POC:97 b QP 25.48(28) 22152 bits RF:0.250 [SSIM: 17.194dB] [L0 96 94 92 90 ] [L1 98 99 ]
x265 [info]: frame I: 1, Avg QP:17.47 kb/s: 51097.60 SSIM Mean: 0.991970 (20.953dB)
x265 [info]: frame P: 25, Avg QP:18.06 kb/s: 19455.58 SSIM Mean: 0.987614 (19.071dB)
x265 [info]: frame B: 74, Avg QP:24.62 kb/s: 1086.37 SSIM Mean: 0.981535 (17.337dB)
x265 [info]: global : 100, Avg QP:22.91 kb/s: 6178.78 SSIM Mean: 0.983159 (17.736dB)

encoded 100 frames in 104.84s (0.95 fps), 6178.78 kb/s, SSIM Mean Y: 0.9831591 (17.736 dB)


Edit: Can't seem to get this working with tune zero latency, but when trying something close with "--bframes 1 --rc-lookahead 2", the results are expectedly better:


Normal:
(1.62 fps), 1779.75 kb/s, SSIM Mean Y: 0.9652713 (14.593 dB)

GPB:
(1.58 fps), 1524.07 kb/s, SSIM Mean Y: 0.9653855 (14.607 dB


Edit 2: Diff (http://pastebin.com/Qk9FCBHZ). Probably breaks in many places, but I won't continue working on it or anything.

[jlpsvk]

@stax76
Thanks for info. :) Anyway... rdoq-level 1 is now my default choice, as it has better fine detail retention at almost same bitrate as rdoq-level 2 (according to few comments here).

My command line currently is:
--crf 20 --preset slow --rdoq-level 1 --min-keyint 23 --keyint 240 --aq-mode 1 --pmode --profile main10 --level-idc 4 --deblock -3:-3 --psy-rd 0.5

[RBX]

My command line currently is:
--crf 20 --preset slow --rdoq-level 1 --min-keyint 23 --keyint 240 --aq-mode 1 --pmode --profile main10 --level-idc 4 --deblock -3:-3 --psy-rd 0.5

You are using decoder level 4, so I assume you're not encoding SD videos. With 16bpp encoder, does your CPU not get saturated that you require pmode?

----
10 bit encoding is great. Although slow, the reduction in banding, even in real life videos is very good. I can still see some vertical slices where light starts dimming. What change can work positively to reduce this?
Current: crf 20, tune off, preset slow, bframes 3, psy-rd 0.4, deblock -1, rc-lookahead 32
----
I tried encoding a 20 sec 4K video (which took insane amount of time) and got debug level log in following file (csv renamed to txt)
I'd like to learn how to decipher this to be able to choose better option.
Also, the source file plays well but the encoded video plays very poorly (4/8 cores show 100% usage). Do I need to set a lower decoder level for smooth playback?

[benwaggoner]

10 bit encoding is great. Although slow, the reduction in banding, even in real life videos is very good. I can still see some vertical slices where light starts dimming. What change can work positively to reduce this?
--frame-threads 1 will generally fix this. Depending on frame size, cores, and preset, you'll likely need to turn on --pmode to make up for the loss of parallelism.

I tried encoding a 20 sec 4K video (which took insane amount of time) and got debug level log in following file (csv renamed to txt)
I'd like to learn how to decipher this to be able to choose better option.
What sort of improvements are you trying to make? I take the .csv into Excel and do all sorts of parsing, but it's more useful to compare different quality/speed combos and figure out what's happening in particular problem spots.

Also, the source file plays well but the encoded video plays very poorly (4/8 cores show 100% usage). Do I need to set a lower decoder level for smooth playback?
For good software playback

Always use the lowest level compatible with frame size and fps
Only use Main Tier
At the higher presets, turning off b-intra can help with software decoding.
Always set vbv-maxrate and vbv-bufsize to legal values. The legal maximums in HEVC for Main Tier are quite a bit lower than for H.264 for the same frame size and fps; 25000 for Level 5.0.
ALWAYS use WPP (which is on by default)
8-bit will be at least a little faster to decode than 16-bit
Software decoders vary a lot in how well they perform, so you might get dramatically different results with different ones.
All that said, I've never seen smooth 2160p24 playback in software using just a 4 core system. My 16 core Ivy Bridge can do it, but my 12-core Sandy Bridge couldn't (at least with decoders of a few months ago)

[RBX]

What sort of improvements are you trying to make?

I'm trying to see if the settings I'm using are actually doing any good or am I just wasting computation power. A few pages back I saw a post which described how using more B-frames was just a waste, I'm interested in more stats like that so than I can make my own optimal presets.


For good software playback

Always use the lowest level compatible with frame size and fps
Always set vbv-maxrate and vbv-bufsize to legal values. The legal maximums in HEVC for Main Tier are quite a bit lower than for H.264 for the same frame size and fps; 25000 for Level 5.0.
Software decoders vary a lot in how well they perform, so you might get dramatically different results with different ones.
All that said, I've never seen smooth 2160p24 playback in software using just a 4 core system. My 16 core Ivy Bridge can do it, but my 12-core Sandy Bridge couldn't (at least with decoders of a few months ago)

So setting decoder level selection to auto won't select the lowest level possible, and I'll have to select it manually?
Also, you're talking here about just HEVC playback, right? The ones from youtube play very smoothly. The one I encoded with x265 wasn't doing well with Potplayer's default decoder, but selecting LAV helped a bit.

[jlpsvk]

I started to get error writing frame 0 with x265? Anybody help? Build 1.5.258 by LigH.

EDIT: I realised, that the cause was THREADS parameter. Interference with PMODE or FRAME-THREADS?

[LigH]

The former "--threads" parameter is now "--pools", which also supports NUMA thread pools (e.g. dual-socket mainboards, and even more distant CPUs).

[Ajvar]

Another vote for rdoq level 1. This should be by default IMO considering how less fine detail x265 keeps on high bitrate in comparison with x264.
Level 2 is like disabled ambient occlusion and made brighter. Level 1 gives less banding/blocking, colors fit original more. Same bitrate on 720p, crf18.5, vbv-max 4000, preset slower by x265 8bpp.1.5+277-74496ce5d8ba [GCC 4.9.2][64 bit].
http://screenshotcomparison.com/comparison/116818
Original frame http://i.imgur.com/vvuEa4r.png

[sneaker_ger]

Another vote for rdoq level 1. This should be by default IMO considering how less fine detail x265 keeps on high bitrate in comparison with x264.
I think it already is the default? At least it seemed to be when I tested it the other day.

Level 2 is like disabled ambient occlusionand made brighter. Level 1 gives less banding, colors fit original more.
You are probably doing something wrong, I don't think it will affect colors that badly. This might also give a false impression of increased banding. (And your source has a lot to begin with)

[Ma]

Another vote for rdoq level 1. This should be by default IMO considering how less fine detail x265 keeps on high bitrate in comparison with x264.
Level 2 is like disabled ambient occlusionand made brighter. Level 1 gives less banding, colors fit original more. Same bitrate on 720p, crf18.5, vbv-max 4000, preset slower by x265 8bpp.1.5+277-74496ce5d8ba [GCC 4.9.2][64 bit].
http://screenshotcomparison.com/comparison/116818
Original frame http://i.imgur.com/vvuEa4r.png

Yes, impressive. Next movie I will definitely encode with --rdoq-level 1.

[Ajvar]

Yes, impressive. Next movie I will definitely encode with --rdoq-level 1.

Or maybe not. I don't get this but now video looks somewhat different and rdoq level 2 is now almost same as rdoq level 2 or even better. I will better upload 2 videos here soom so you would compare yourself.
Sorry.
Links for encoded files:
http://www.ex.ua/load/156547833?fs_id=131
http://www.ex.ua/load/156555041?fs_id=131
Don't forget that I chose CRF18.5 but with a vbv limit of 4000kbps at preset slower!

[RBX]

Or maybe not. I don't get this but now video looks somewhat different and rdoq level 2 is now almost same as rdoq level 2 or even better. I will better upload 2 videos here soom so you would compare yourself.
Sorry.

In my tests with 1.5.258 8bpp, rdoq level 1 files had more detail retention, slightly higher PSNR, and around 10% higher bitrate than rdoq level 2 files.
http://screenshotcomparison.com/comparison/116970
(The difference is much clearer with BMP screenshots, but I currently don't have access to a good connection)

[jlpsvk]

I got impressive results with RDOQ LEVEL 1. Much better fine details. Using StarRip 1.2.0.5 with DirectShow source using LAV Filters 0.64.0.11, pure CPU based, not touching rgb output levels. :)

[benwaggoner]

I'm trying to see if the settings I'm using are actually doing any good or am I just wasting computation power. A few pages back I saw a post which described how using more B-frames was just a waste, I'm interested in more stats like that so than I can make my own optimal presets.
You can turn --psnr and --ssim on so those get logged per frame, and see if you get significant differentials between those anywhere. Those aren't linear to perceptual quality by any means, but typically a P-frame with worse PSNR and SSIM is going to also look worse if all the perceptual settings are the same. But comparing the same frame number where different frame types got chosen is a whole lot harder. So comparing --slow and --slower where B-frames goes from 4 to 8 is going to be hard to do from a log file.

In the end, quantitative metrics are interesting and somewhat helpful, but in the end it all gets down to eyeballs. I mostly find it useful when I've already found a quality delta and what to see what was going on with the frames during that section.

So setting decoder level selection to auto won't select the lowest level possible, and I'll have to select it manually?
I believe if you do something like --preset veryslow that raises the ref count to 5, you'll automatically get bumped up to the level that allows that if you haven't specified a level. If you do specify a level, it'll reduce refs to the maximum legal value. x265generally gets it right, but not always, so if you need an explicit level, set it.

Also, you're talking here about just HEVC playback, right? The ones from youtube play very smoothly. The one I encoded with x265 wasn't doing well with Potplayer's default decoder, but selecting LAV helped a bit.
I'm just talking HEVC encoded with x265. H.264 normally gets a HW accelerated decode these days. And VP9 doesn't have levels, or equivalent knobs to tune perf while maintaining compatiblity with existing players.

[Ma]

Or maybe not. I don't get this but now video looks somewhat different and rdoq level 2 is now almost same as rdoq level 2 or even better. I will better upload 2 videos here soom so you would compare yourself.
Sorry.
Links for encoded files:
http://www.ex.ua/load/156547833?fs_id=131
http://www.ex.ua/load/156555041?fs_id=131
Don't forget that I chose CRF18.5 but with a vbv limit of 4000kbps at preset slower!

It is too late, I just started encoding new movie with settings:
--preset slower --crf 17.0 --rdoq-level 1 --psy-rd 0.4 @ 10-bit output

Besides I can't download your samples.

[jlpsvk]

Why you are encoding at CRF 17-18.5? I see CRF 20 sufficient? Any reason?

[Ajvar]

It is too late, I just started encoding new movie with settings:
--preset slower --crf 17.0 --rdoq-level 1 --psy-rd 0.4 @ 10-bit output

Besides I can't download your samples.

Well, unless you limit bitrate buffer to some low values, your video will be really better with level 1 and keep more fine detail. So it is even good as people above mentioned.

[zerowalker]

In my tests with 1.5.258 8bpp, rdoq level 1 files had more detail retention, slightly higher PSNR, and around 10% higher bitrate than rdoq level 2 files.
http://screenshotcomparison.com/comparison/116970
(The difference is much clearer with BMP screenshots, but I currently don't have access to a good connection)

My i ask, why not .png? (as i am guessing you did jpeg), png == bmp.

[LigH]

JPEG has lossy compression.

PNG has lossless compression.

BMP has no compression at all for RGB24, and is not even a web standard (web browsers are not expected to support it at all).

[Motenai Yoda]

If you do specify a level, it'll reduce refs to the maximum legal value. x265 generally gets it right, but not always, so if you need an explicit level, set it.
I would like to see the same thing for vbv maxrate and buffer, setted according to the tier/level specified or automatically chosen.

[Ma]

Why you are encoding at CRF 17-18.5? I see CRF 20 sufficient? Any reason?

For me CRF 17 isn't sufficient, but lower CRF gives very small quality boost and big increase of output file size. So most people here are seeking option to boost visual quality (especially for human faces and skin) without insane encoded size.

For me acceptable size for normal movies is 8 GB and for good movies -- 16 GB.

Projected file size of video part for my current encoding is 6.23 GB.

[RBX]

My i ask, why not .png? (as i am guessing you did jpeg), png == bmp.
No, they are PNG. I was able to see more detail in BMP screenshots. Maybe Potplayer doesn't capture source frame correctly, or does lossy compression on PNG, or maybe I just captured screen frame (processed by MadVR) instead of source frame in BMP.

[jlpsvk]

For me CRF 17 isn't sufficient, but lower CRF gives very small quality boost and big increase of output file size. So most people here are seeking option to boost visual quality (especially for human faces and skin) without insane encoded size.

For me acceptable size for normal movies is 8 GB and for good movies -- 16 GB.

Projected file size of video part for my current encoding is 6.23 GB.

What screen are you using? And what x265? Are you using 8bit or 10bit? On 10bit there's no problem with the banding and color gradients. On CRF20, I am getting half of bitrate of x264 and the picture looks better to me with x265. Why to use x265, whe you are using same bitrates as on x264?

[jlpsvk]

@Stax76
Hi Stax. Thanks for your great work. But I noticed, that you still missed the "--threads" parameter. It does not exist in x265 anymore. Instead of that there is "--pools".

[Selur]

that's because the x265 folks removed '--threads'

[jlpsvk]

x265 still not using 100% of my CPU. Even with --pmode, -pools 12 CPU runs only at around 90%.

[LigH]

No shit, Sherlock. On a Dual Xeon (2×12 cores with HT) it didn't even reach 50%... Maybe it just doesn't use more threads than it can handle for the given video frame dimensions?

[x265_Project]

No shit, Sherlock. On a Dual Xeon (2×12 cores with HT) it didn't even reach 50%... Maybe it just doesn't use more threads than it can handle for the given video frame dimensions?

Easy guys... let's stick to the facts, and see what's happening. We'll let you know whether your CPU utilization numbers are expected, or not. jlpsvk, can you share your full command line?

[LigH]

^ possibly plus the x265 info console output before the encode starts.

[Ma]

I've noticed that headers in output HEVC files for:
x265 --preset slower --rdoq-level 1 720p50_parkrun_ter.y4m 720p50_parkrun_ter.hevc
and
x265 --preset slower --rdoq-level 2 720p50_parkrun_ter.y4m 720p50_parkrun_ter2.hevc
are the same (1.5+363). The "rdoq-level" info is missing from header.

[Ma]

What screen are you using?

Eizo SX2262W (with 8-bit video card).

And what x265? Are you using 8bit or 10bit? On 10bit there's no problem with the banding and color gradients.

I'm using 10bit x265. Confirmed, color gradients are OK with 10bit encoding.

On CRF20, I am getting half of bitrate of x264 and the picture looks better to me with x265. Why to use x265, whe you are using same bitrates as on x264?

My bitrates with x265 encoding are also smaller that my x264 bitrates.

Some time ago I encoded movie "The Sessions", 2012. 10bit x265, preset slower, crf 18, it was 1.4+222 or older version of x265. At 11:50 time in this movie is scene when Mark told "I love you" to Amanda and there is important Amanda reaction -- only face (without words). It was epic fail with x265 encoding, the face was looking unnatural (plastic look, too much blur). It ruined whole movie. So I've changed x265 settings to crf 17, psy-rd=0.60, psy-rdoq=1.00 and re-encoded this movie. From this trauma I've never used crf 18 for my encodings.

[jlpsvk]

@LigH and @x265_Project
------------------------------------------------------------
x265
------------------------------------------------------------

"C:\StaxRip\Applications\avs4x26x\avs4x26x.exe" --x26x-binary "C:\StaxRip\Applications\x265\64-Bit 10-Bit\x265.exe" --crf 20
--preset slow --rdoq-level 1 --min-keyint 23 --keyint 240 --aq-mode 1 --pmode --deblock -3:-3 --psy-rd 0.5 --frame-threads 1
--pools 12 --input-res 1920x784 --fps 23.976000 --output "D:\movie_encode_out.hevc" "D:\movie_encode.avs"

yuv [info]: 1920x784 fps 23976/1000 i420p8 unknown frame count
x265 [info]: HEVC encoder version 1.5+258-6461985f33ac
x265 [info]: build info [Windows][GCC 4.8.2][64 bit] 16bpp
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
x265 [info]: Main 10 profile, Level-4 (Main tier)
x265 [info]: Thread pool created using 8 threads
x265 [info]: frame threads / pool features : 1 / wpp(13 rows)+pmode
x265 [info]: Internal bit depth : 10
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 : star / 57 / 3 / 3
x265 [info]: Keyframe min / max / scenecut : 23 / 240 / 40
x265 [info]: Lookahead / bframes / badapt : 25 / 4 / 2
x265 [info]: b-pyramid / weightp / weightb / refs: 1 / 1 / 0 / 3
x265 [info]: Rate Control / AQ-Strength / CUTree : CRF-20.0 / 1.0 / 1
x265 [info]: tools: rect rd=4 rdoq=1 psy-rd=0.50 psy-rdoq=1.00 deblock(tC=-3:B=-3) sao signhide tmvp

Obviously....threads are still at 8, even if pools is set to 12. --pmode is helping to get another 2-4% from CPU.

@Ma
Try to encode that scene with 10-bit x265 with this command line and let me know. I'm curious. Use x265 1.5.258 or higher. :)
--crf 20 --preset slow --rdoq-level 1 --min-keyint 23 --keyint 240 --aq-mode 1 --pmode --deblock -3:-3 --psy-rd 0.5 --frame-threads 1

[xooyoozoo]

I'm not sure if you're trying to ask about low CPU usage, but `--frame-threads 1` is almost certainly why.

[uneedme]

I was wondering that there is any chance to add the opencl support?

let the idle gpu to work along......on encoding......

or it is an available function I just dont know?



some has support opencl decoding (gpu processes parts of load)

any existed opencl mod some gui has already added for encoding side?

or opened-standard commands of opencl only support decoding side?



opencl is getting more common on pc-lineup?

Will this idea be useful?

[anonymlol]

I was wondering that there is any chance to add the opencl support?

let the idle gpu to work along......on encoding......

or it is an available function I just dont know?



some has support opencl decoding (gpu processes parts of load)

any existed opencl mod some gui has already added for encoding side?

or opened-standard commands of opencl only support decoding side?



opencl is getting more common on pc-lineup?

Will this idea be useful?

This is from 3 months ago:
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.

[uneedme]

This is from 3 months ago:

Quote:
Originally Posted by x265_Project View Post
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.






I thought opencl is an open-public-architecture any complying hardware would support？Caring free about the actual HW......using gpu as another cpu...

Need to specify chips and drivers？


Individual gpu mod？

Should this fork（branch）version work on generic gpus would be great！It means it will support no-opencl gpus as well.

Expecting~

[LigH]

@ jlpsvk:

I was already told elsewhere (possibly in the mailing list) that x265 won't use more frame threads than it calculates to be efficient. Parallelization of algorithms has its limits. Some may depend on the frame dimensions and GOP structure.

But you limiting the frame threads explicitly by a parameter will create an additional bottleneck, I guess xooyoozoo is right here.

Affirmative answers are to be expected from a developer of x265, though, not from me...

[x265_Project]

@ jlpsvk:

I was already told elsewhere (possibly in the mailing list) that x265 won't use more frame threads than it calculates to be efficient. Parallelization of algorithms has its limits. Some may depend on the frame dimensions and GOP structure.

But you limiting the frame threads explicitly by a parameter will create an additional bottleneck, I guess xooyoozoo is right here.

Affirmative answers are to be expected from a developer of x265, though, not from me...

That's correct.

"--frame-threads (http://x265.readthedocs.org/en/default/threading.html#frame-threading) 1" will force x265 to encode only one frame at a time. This turns off frame parallelism. To take advantage of many-core machines x265 needs to encode multiple frames in parallel. You would want to turn off frame parallelism if you need extremely low latency real-time encoding (typically you would also turn off B frames in this scenario). If you are encountering a tricky rate control issue (when using one-pass ABR rate control), turning off frame parallelism can help as a brute-force diagnostic test. For an offline CRF encode, there are minimal benefits to turning off frame parallelism. The only benefit is that the motion search for inter-prediction would have unlimited motion search range available in reference frames when frame parallelism is turned off. But you can protect a wider motion search range across reference frames that are being encoded in parallel by increasing --merange (add increments of the --ctu setting), and I think you'll see that this typically has very little benefit to compression efficiency. But as always, we welcome your feedback.

[NikosD]

OpenCL HEVC decoding has been implemented quite some time now by at least two decoders - Lentoid Strongene and Cyberlink's PowerDVD.

They are working quite good on both Intel and AMD the two companies that have real OpenCL drivers - not like Nvidia's pseudo-OpenCL driver.

I think OpenCL HEVC encoding is feasible.

[jlpsvk]

I switched to 1 because it was mentioned, that value 1 is helping reduce banding and encode color gradients. :)

[Ma]

Try to encode that scene with 10-bit x265 with this command line and let me know. I'm curious. Use x265 1.5.258 or higher. :)
--crf 20 --preset slow --rdoq-level 1 --min-keyint 23 --keyint 240 --aq-mode 1 --pmode --deblock -3:-3 --psy-rd 0.5 --frame-threads 1

OK, I will test deblock option. My current encoding goes to 52%, time remaining: 2 days, 13 hrs.

So there are 2 option missing in HEVC file header: rdoq-level and deblock.

[x265_Project]

I switched to 1 because it was mentioned, that value 1 is helping reduce banding and encode color gradients. :)

I would welcome examples of this.

[jlpsvk]

Originally Posted by RBX View Post
10 bit encoding is great. Although slow, the reduction in banding, even in real life videos is very good. I can still see some vertical slices where light starts dimming. What change can work positively to reduce this?

Originally Posted by benwagoner
--frame-threads 1 will generally fix this. Depending on frame size, cores, and preset, you'll likely need to turn on --pmode to make up for the loss of parallelism.

[uneedme]

I think OpenCL HEVC encoding is feasible.


Good!

[NikosD]

Feasible doesn't necessarily mean that it's going to happen.

Real hardware HEVC encoding like some of QuickSync's next version which has a tradition of fast and qualitative AVC transcodings is a more possible and interesting road to follow.

[uneedme]

Feasible doesn't necessarily mean that it's going to happen.

Real hardware HEVC encoding like some of QuickSync's next version which has a tradition of fast and qualitative AVC transcodings is a more possible and interesting road to follow.

The hardware encoding strictly comply to the embedded Instruction set, which means fixed output and not optimized result.

Through opencl is acquiring the gpu, the hardware, as an auxiliary, the program is still the main body...

It is totally different...

[NikosD]

QuickSync is using ASIC + GPU too for flexibility and it's not using ASIC only approach (fixed - function HW) like Nvidia.

[sborho]

Yes, numbers:

x265 --preset slow --crf 18 --no-rdoq-level 720p50_parkrun_ter.y4m 720p50_parkrun_ter.hevc
encoded 504 frames in 126.42s (3.99 fps), 21445.36 kb/s

x265 --preset slow --crf 18 720p50_parkrun_ter.y4m 720p50_parkrun_ter.hevc
encoded 504 frames in 148.96s (3.38 fps), 24243.95 kb/s

x265 --preset slow --crf 18 --rdoq-level 1 720p50_parkrun_ter.y4m 720p50_parkrun_ter.hevc
encoded 504 frames in 143.56s (3.51 fps), 25158.41 kb/s

This stumped me for a while until I thought it all through. CRF works by estimating the complexity of each picture (measuring average variance of each block) and setting a single slice level QP for the picture, so there is no bitrate consideration.

Within mode decision, it is making coding decisions based on the least rate-distortion cost (distortion + lambda * bits). What RDOQ is doing is making residual coded blocks have much fewer bits but slightly higher distortion, and this is making residual coded blocks much more competitive to "skip" blocks in RD cost and so the encoder is picking more residual coded blocks. This increases bitrate (and quality) substantially.

The short summary is that you cannot really compare bitrates in CRF encodes if you start messing with the functions that evaluate RD cost (the same is true of CQP).

[sborho]

I switched to 1 because it was mentioned, that value 1 is helping reduce banding and encode color gradients. :)

There are three features which are affected by frame parallelism.

1 - ABR and VBV rate control (less accuracy with higher -FN)
2 - motion search search area limited with -FN>1
3 - noise reduction (less accuracy with higher -FN)

If you add --pmode to overcome the loss of parallelism with -F1, you get improved compression because pmode disables some analysis early outs (you get exhaustive analysis for each CU). You would get this improvement even with frame parallelism enabled, but pmode might make the encode slower depending on how many cores you have

[LigH]

Next: x265 1.5+370-cc496665280f (https://www.mediafire.com/download/nbi4xnd9fj98a5n/x265_1.5+370-cc496665280f.7z)

[MeteorRain]

And my personal modification 1.5+370+8-1c84fa233a5d (https://down.7086.in/x264_Yuuki/x265-Yuuki-1.5%2B370%2B8-1c84fa233a5d.7z) compiled by mingw-w64.

[LigH]

And my personal modification

Did you document anywhere what you modified?

Ah, it seems to include the L-SMASH multiplexer to support MP4 output.

[MeteorRain]

Did you document anywhere what you modified?

Ah, it seems to include the L-SMASH multiplexer to support MP4 output.

https://bitbucket.org/msg7086/x265-yuuki

Just some cosmetic mod, and (buggy?) l-smash / haali mkv muxer patch after heavy hacking on the core.

[Vulpix]

I am also having a bit of trouble getting into the x265 / h265 thing. I use staxrip and found out that the "medium" preset of x265 is +- encoding speed-wise equal to the "slow/slower" preset of x264. The size is about 2x smaller but there is a distinct loss of visual quality (like the user "me" stated - a lot of things are blurred out so fine detail is lost). Is "rdoq=1" and psy-rd 0.5 the answer? Or will I have to go to "slower" preset for x265 no matter what? The speed becomes a lot slower at that point, which is a bit of a downer.

Thanks!

[LigH]

You said that the resulting bitrate of the x265 default (CRF 28) is a lot lower than the bitrate of the x264 default (CRF 23). So don't be surprised that the quality is also a bit lower. Even though HEVC/H.265 may be a bit more efficient than AVC/H.264 doesn't mean that half the bitrate can look just as good, especially not in every case.

Except for some issues still being developed, in general, at the same bitrate, x265 should be able to preserve more quality than x264. But to find settings where the quality is about equal, and then comparing the bitrates, is not a serious approach to compare them. Furthermore, the defaults are not tuned to be as equal as possible between x265 and x264, regarding quality. CRF 28 for x265 will probably be worse than CRF 23 for x264 in many cases, and both are far away from "visually transparent quality preservation".

[Boulder]

According to my tests, x265 still doesn't retain details like x264 does but smoothes the image quite heavily even with CRF values around 20 or less. I-frames looked quite the same but other ones were different. If I've understood correctly, this is just the way it is unless x265 adopts the same psy algorithms that x264 uses? I have not tested any recent build but one some two-three weeks ago.

[Ma]

I've made speed test of 10-bit x265 1.5+365 builds.

Contenders:
x265-MSVC.exe - Daemon404 build form http://chromashift.org/x265_builds/x265-1.5.365-highbitdepth-msvc2012-64.7z
x265-492-O2.exe - my normal build, GCC 4.9.2, -O2 optimize option, -march=corei7-avx
x265-485-O2.exe - GCC 4.8.5 dongsheng-daily build 20150323 from MinGW-w64, -O2 optimize option, -march=corei7-avx
x265-485-O3.exe - GCC 4.8.5 dongsheng-daily build 20150323 from MinGW-w64, -O3 optimize option, -march=corei7-avx
x265-493-O2.exe - GCC 4.9.3 dongsheng-daily build 20150323 from MinGW-w64, -O2 optimize option, -march=corei7-avx
...

I've executed first two contenders twice to calibrate results and to estimate the measurement error. My platform: Win 7 64-bit, i5 3450S.

Results:
i:\m\v1>x265-MSVC.exe --preset slower 720p50_parkrun_ter.y4m 720p50_parkrun_ter.hevc
encoded 504 frames in 278.16s (1.81 fps), 3473.84 kb/s
encoded 504 frames in 277.52s (1.82 fps), 3473.84 kb/s

i:\m\v1>x265-492-O2.exe --preset slower 720p50_parkrun_ter.y4m 720p50_parkrun_ter.hevc
encoded 504 frames in 268.74s (1.88 fps), 3473.84 kb/s
encoded 504 frames in 268.47s (1.88 fps), 3473.84 kb/s

i:\m\v1>x265-485-O2.exe --preset slower 720p50_parkrun_ter.y4m 720p50_parkrun_ter.hevc
encoded 504 frames in 273.19s (1.84 fps), 3473.84 kb/s

i:\m\v1>x265-485-O3.exe --preset slower 720p50_parkrun_ter.y4m 720p50_parkrun_ter.hevc
encoded 504 frames in 275.76s (1.83 fps), 3473.84 kb/s

i:\m\v1>x265-493-O2.exe --preset slower 720p50_parkrun_ter.y4m 720p50_parkrun_ter.hevc
encoded 504 frames in 266.67s (1.89 fps), 3473.84 kb/s

i:\m\v1>x265-493-O3.exe --preset slower 720p50_parkrun_ter.y4m 720p50_parkrun_ter.hevc
encoded 504 frames in 270.63s (1.86 fps), 3473.84 kb/s

i:\m\v1>x265-500-O2.exe --preset slower 720p50_parkrun_ter.y4m 720p50_parkrun_ter.hevc
encoded 504 frames in 325.87s (1.55 fps), 3473.84 kb/s

i:\m\v1>x265-500-O3.exe --preset slower 720p50_parkrun_ter.y4m 720p50_parkrun_ter.hevc
encoded 504 frames in 314.20s (1.60 fps), 3473.84 kb/s

So GCC 4.9.3 rules, GCC 4.8.5 weak, GCC 5.0.0 crap, crap and ones more crap.

If someone wants to repeat this test:
contenders - http://www.msystem.waw.pl/x265/test.7z
video - http://media.xiph.org/video/derf/y4m/720p50_parkrun_ter.y4m

[MeteorRain]

For now 5.0.0 isn't aiming at speed, is it? GCC 4.9 should be the fastest among its family.
However very interesting to see GCC beating MSVC. How about ICL?

[anonymlol]

edit: Nevermind, I compared them myself.


CPU: i7-2700k (4.8 GHz)
settings: --preset slower 720p50_parkrun_ter.y4m 720p50_parkrun_ter.hevc

x265-MSVC.exe 2.30 fps
x265-MSVC.exe 2.30 fps
x265-492-O2.exe 2.37 fps
x265-492-O2.exe 2.40 fps

x265-485-O2.exe 2.36 fps
x265-485-O3.exe 2.30 fps
x265-493-O2.exe 2.41 fps
x265-493-O3.exe 2.36 fps
x265-500-O2.exe 2.01 fps
x265-500-O3.exe 2.09 fps

My own build (492 O3 fprofiled, 1.5+370)
x265.exe 2.41 fps
x265.exe 2.41 fps

[Vulpix]

I tested this on my i7-4765T (bit of a crazy cpu -> http://ark.intel.com/products/75121/Intel-Core-i7-4765T-Processor-8M-Cache-up-to-3_00-GHz ). Also Win7 x64.

I cannot really see much difference between the versions. The 4.9.3 O2 is the fastest... but by very little (3.6% in comparison with the slowest, MSVC compilation)

d:\Transcode\TEST>x265-MSVC.exe --preset slower 720p50_parkrun_ter.y4m 720p50_parkrun_ter.hevc

encoded 504 frames in 308.40s (1.63 fps), 3473.84 kb/s

d:\Transcode\TEST>x265-MSVC.exe --preset slower 720p50_parkrun_ter.y4m 720p50_parkrun_ter.hevc

encoded 504 frames in 308.52s (1.63 fps), 3473.84 kb/s

d:\Transcode\TEST>x265-492-O2.exe --preset slower 720p50_parkrun_ter.y4m 720p50_parkrun_ter.hevc

encoded 504 frames in 298.35s (1.69 fps), 3473.84 kb/s

d:\Transcode\TEST>x265-492-O2.exe --preset slower 720p50_parkrun_ter.y4m 720p50_parkrun_ter.hevc

encoded 504 frames in 299.62s (1.68 fps), 3473.84 kb/s

d:\Transcode\TEST>x265-485-O2.exe --preset slower 720p50_parkrun_ter.y4m 720p50_parkrun_ter.hevc

encoded 504 frames in 304.52s (1.66 fps), 3473.84 kb/s

d:\Transcode\TEST>x265-485-O3.exe --preset slower 720p50_parkrun_ter.y4m 720p50_parkrun_ter.hevc

encoded 504 frames in 306.14s (1.65 fps), 3473.84 kb/s

d:\Transcode\TEST>x265-493-O2.exe --preset slower 720p50_parkrun_ter.y4m 720p50_parkrun_ter.hevc

encoded 504 frames in 297.95s (1.69 fps), 3473.84 kb/s

d:\Transcode\TEST>x265-493-O3.exe --preset slower 720p50_parkrun_ter.y4m 720p50_parkrun_ter.hevc

encoded 504 frames in 299.59s (1.68 fps), 3473.84 kb/s

d:\Transcode\TEST>x265-500-O2.exe --preset slower 720p50_parkrun_ter.y4m 720p50_parkrun_ter.hevc

encoded 504 frames in 305.28s (1.65 fps), 3473.84 kb/s

d:\Transcode\TEST>x265-500-O3.exe --preset slower 720p50_parkrun_ter.y4m 720p50_parkrun_ter.hevc

encoded 504 frames in 305.28s (1.65 fps), 3473.84 kb/s

[RBX]

For now 5.0.0 isn't aiming at speed, is it? GCC 4.9 should be the fastest among its family.
However very interesting to see GCC beating MSVC. How about ICL?
I'd like to know this as well. I use the ones compiled by Intel compiler hoping that Intel might have enabled some exclusive optimizations for intel processors.

[Vulpix]

Hmm.

Would the general consensus then be that instead of trying to get the same quality and then compare the bitrates, I should rather get the same bitrates?

I.e. using h265 not to improve my encoded filesize but to improve the amount of retained detail / overall quality (as from what I'm gathering, the x265 encode should yield better results than x264 one at the same bitrate) ?

I agree I was maybe asking a bit much from the encodes when I ended up with a file that was 2x smaller using the same "quality" preset from staxrip ...

[MoSal]

According to my tests, x265 still doesn't retain details like x264 does but smoothes the image quite heavily even with CRF values around 20 or less. I-frames looked quite the same but other ones were different. If I've understood correctly, this is just the way it is unless x265 adopts the same psy algorithms that x264 uses? I have not tested any recent build but one some two-three weeks ago.

I came to the same conclusion.
x265 (and libvpx/vp9 btw) are no match to x264 when it comes to detail preservation.

Optimizing (and micro-optimizing) for the human eye is not expected to become a top priority for sponsors. So, we might never have an HEVC encoder that is better than x264 at preserving details.

---

Although they are not even close to a finalized spec. It seems the Daala team is the only one primarily optimizing for the human eye. So, let's wish them success.

[LigH]

Would the general consensus then be that instead of trying to get the same quality and then compare the bitrates, I should rather get the same bitrates?

Well, somehow ... yes, and on top, let's have thousands of probands participate in the comparison in "ABX tests". This way we can statistically measure how good it works subjectively, means, if x265 will be able to actually "look better" for the average audience than other encoders, at the same bitrates.

That will hopefully show if detail retention is for nitpickers only, or indeed a crucial attribute. :rolleyes: :devil:

[benwaggoner]

I came to the same conclusion.
x265 (and libvpx/vp9 btw) are no match to x264 when it comes to detail preservation.
I think the new --rdoq-level setting may be helpful in this regard. There's an innate tension between accuracy and verisimilitude in encoding; making something with the same feel as the original takes a lot fewer bits than encoding every little detail exactly as it was before.

Optimizing (and micro-optimizing) for the human eye is not expected to become a top priority for sponsors. So, we might never have an HEVC encoder that is better than x264 at preserving details.
Why would you think that wouldn't be important to sponsors?

There is also work going on to use HEVC for mezzanine files, which today are normally MPEG-2 (quality issues, 8-bit only or ProRes (huge, not great interoperability). Excellent detail preservation is critical for that use case. HEVC offers way better compression than MPEG-2 and with range extensions all the color space modes of ProRes.

Go down to --crf 10 and you'll get a perfect reproduction at very competitive bitrates.

Although they are not even close to a finalized spec. It seems the Daala team is the only one primarily optimizing for the human eye. So, let's wish them success.
HEVC architecturally has tons of optimizations for human vision. Of course, pretty much everything in codecs are psychovisual optimizations, except for entropy encoding. Even fundamental stuff like gamma and frequency-based transforms are psychovisual optimizations.

[Boulder]

Well, I'm going to give x265 another go as soon as I get the spare CPU time. I do enjoy trying it out and who knows, some day I might be very pleasantly surprised :)

[x265_Project]

I came to the same conclusion.
x265 (and libvpx/vp9 btw) are no match to x264 when it comes to detail preservation.

Optimizing (and micro-optimizing) for the human eye is not expected to become a top priority for sponsors. So, we might never have an HEVC encoder that is better than x264 at preserving details.

Nonsense. Optimizing visual quality (including spatial detail) is our top priority. If you have an example where x264 has higher spatial detail than x265, please share. But spatial detail isn't the only thing that video encoders need to preserve. You can crank up psy-rd in x264 or x265 and get higher spatial detail at the expense of motion accuracy. In other words, if you don't mind lots of motion artifacts, you can get more spatial detail. But motion artifacts can be just as disturbing as a lack of spatial detail. HEVC generally has much better motion accuracy, and since we're encoding video and not just still images, we don't want to compromise this unnecessarily.

You also need to be careful when it comes to looking for spatial detail not to confuse noise with picture detail. H.264 tends to have "macroblocking" noise, where H.265 doesn't. This noise adds energy and texture to decoded frames. Looking at individual decoded frames, you might think that this texture was part of the original picture, and conclude that the H.264 encoder did a better job. But if you overlay the source frame with your decoded H.264 and H.265 frame, and wipe back and forth, it's easier to see what is picture and what is noise. We have a special player that we've built to do this. It's hard to do accurate video analysis without such a tool.

It's been a long time since I've seen an x264 encode that looked better at identical bit rate to the x265 encode. If you have publicly available source content and your x264 and x265 settings to share, we would be happy to look at your results.

[Boulder]

I just did a test and here are my results.

Video:
x264 @ CRF 18.5 : https://drive.google.com/file/d/0BzeF_1syecQwYzB0aFYtVFI5V2s/view?usp=sharing
x265 @ CRF 20.3 : https://drive.google.com/file/d/0BzeF_1syecQwM2RUcWptdU1hZXM/view?usp=sharing

Screenshots to show the difference:
x264 : https://drive.google.com/file/d/0BzeF_1syecQwTXRDVXpkQ2lkUms/view?usp=sharing
x265 : https://drive.google.com/file/d/0BzeF_1syecQwQS10RUtLclZHTzA/view?usp=sharing

Settings:

c:\x264\x264.exe --stdin y4m - --sar 1:1 --level 4.1 --colormatrix "bt709" --colorprim "bt709" --transfer "bt709" --tune film
--preset veryslow --crf 18.5 --output c:\x265\x264_crf18.5.h264
c:\x265\x265.exe --y4m --input - --sar 1:1 --colormatrix "bt709" --colorprim "bt709" --transfer "bt709"
--preset slow --tune grain --crf 20.3 --output c:\x265\x265_crf20.3.h265

I have cropped and resized the image and used a custom denoiser to press down the noise slightly. The reason for this is that I like to test real-life situations to see if I should use x265 or not.

The filesizes of the screenshots already reveal that x265 has smoothed the image quite a lot as it's also smaller as a png file. It's not just noise that the encoder has removed, it's actual detail from the field. If I remember correctly, Hot Fuzz is considered a very good quality source so I've been using the scene in my tests.

If you need me to test anything, just let me know.

[Tommy Carrot]

Boulder's screenshots demonstrate quite well what i was saying about x265. X265 smoothes the fine details out in places where the luma or chroma deviation between the neightboring pixels is fairly small. X264 retains these details considerably better at similar bitrates. Psy-rd helps a bit, but even at very high settings it still blurs significantly more than x264.

[x265_Project]

I just did a test and here are my results.

Video:
x264 @ CRF 18.5 : https://drive.google.com/file/d/0BzeF_1syecQwYzB0aFYtVFI5V2s/view?usp=sharing
x265 @ CRF 20.3 : https://drive.google.com/file/d/0BzeF_1syecQwM2RUcWptdU1hZXM/view?usp=sharing

Boulder - I would need a link to your source file, in order to see what is going on here, but I don't think you should be using --tune grain. Can you repeat the test without --tune grain?

[Boulder]

Yes, I'll test it tomorrow but you can get the original sample clip here : https://drive.google.com/file/d/0BzeF_1syecQwakhsX3RuZGhWcjA/view?usp=sharing . I'm assuming this is fair use even though the clip is over a thousand frames long.

[Ajvar]

@Boulder, what's the point of using x265 at bigher CRF like 20 and compare it to x264 at CRF18 if it should be opposite because x265 can give higher quality at the same bitrate?

The best would be 2pass encode at high bitrate like 10000 kbit/s for x265 and x264. Although I still believe that x265 blurrs picture more or x264's macroblock noise gives more details, whatever it is called.

[sneaker_ger]

He chose the CRF values to make both encodes identical bitrate so the quality can be compared.

[Ajvar]

He chose the CRF values to make both encodes identical bitrate so the quality can be compared.

That wouldn't be true because of nonlinear bitrate/crf curve even if increasing CRF for x265 would anyhow give closer bitrate to lower CRF of 264 which is OPPOSITE.
I just did a test and here are my results.
Video:
x264 @ CRF 18.5 :
x265 @ CRF 20.3 :

At equal CRFX x265's file will have lower bitrate than x264's so to make it equal you need to lower CRF value (to CRFX-1 or CRFX-2) of x265, not x264.

[sneaker_ger]

Your assumptions about crf are wrong. Just download the files and you will see they are both the same size.

[Ma]

I tested this on my i7-4765T (bit of a crazy cpu -> http://ark.intel.com/products/75121/Intel-Core-i7-4765T-Processor-8M-Cache-up-to-3_00-GHz ). Also Win7 x64.

d:\Transcode\TEST>x265-493-O2.exe --preset slower 720p50_parkrun_ter.y4m 720p50_parkrun_ter.hevc
encoded 504 frames in 297.95s (1.69 fps), 3473.84 kb/s

d:\Transcode\TEST>x265-500-O2.exe --preset slower 720p50_parkrun_ter.y4m 720p50_parkrun_ter.hevc
encoded 504 frames in 305.28s (1.65 fps), 3473.84 kb/s

d:\Transcode\TEST>x265-500-O3.exe --preset slower 720p50_parkrun_ter.y4m 720p50_parkrun_ter.hevc
encoded 504 frames in 305.28s (1.65 fps), 3473.84 kb/s

Quite interesting result. On 4-cores/8-threads CPU the difference between GCC 5.0.0-O2/O3 and GCC 4.9.3-O2 is 2.46%. On my 4-cores/4-threads CPU GCC 5.0.0-O2 time is 22.2% longer than GCC 4.9.3-O2 and GCC 5.0.0-O3 -- 17.8%. Maybe GCC 5.0.0 on 8-cores/16-threads CPU will be faster than GCC 4.9.3.

[Ma]

New speed test of 10-bit x265 1.5+370 builds. Now with ICL, LigH and anonymlol builds. I also included my generic build (without "-march=corei7-avx" option). Calibration on MSVC and my AVX builds.

Win 7 64-bit, i5 3450S (4-cores/4-threads @ 3.5GHz):
i:\m\v1>x265-MSVC.exe --preset slower 720p50_parkrun_ter.y4m 720p50_parkrun_ter.hevc
encoded 504 frames in 277.29s (1.82 fps), 3473.84 kb/s
encoded 504 frames in 277.68s (1.82 fps), 3473.84 kb/s

i:\m\v1>x265-AVX.exe --preset slower 720p50_parkrun_ter.y4m 720p50_parkrun_ter.hevc
encoded 504 frames in 267.28s (1.89 fps), 3473.84 kb/s
encoded 504 frames in 267.91s (1.88 fps), 3473.84 kb/s

i:\m\v1>x265-anonymlol.exe --preset slower 720p50_parkrun_ter.y4m 720p50_parkrun_ter.hevc
encoded 504 frames in 267.78s (1.88 fps), 3473.84 kb/s

i:\m\v1>x265-GEN.exe --preset slower 720p50_parkrun_ter.y4m 720p50_parkrun_ter.hevc
encoded 504 frames in 271.49s (1.86 fps), 3473.84 kb/s

i:\m\v1>x265-ICL.exe --preset slower 720p50_parkrun_ter.y4m 720p50_parkrun_ter.hevc
encoded 504 frames in 283.50s (1.78 fps), 3473.42 kb/s

i:\m\v1>x265-LigH.exe --preset slower 720p50_parkrun_ter.y4m 720p50_parkrun_ter.hevc
encoded 504 frames in 278.50s (1.81 fps), 3473.84 kb/s

ICL build produces significant different output (with different bitrate). It is slow (on my 4-cores/4-threads CPU).

Anonymlol build is very impressive -- generic profiled build is equal fast as my AVX build. It will be clear winner with additional "-march=corei7-avx" option.

Contenders -- http://www.msystem.waw.pl/x265/test2.7z

[Boulder]

He chose the CRF values to make both encodes identical bitrate so the quality can be compared.Exactly, as that was requested. The x264 CRF value was chosen to represent my real-life situations, otherwise it wouldn't make sense to compare.

Here's the x265 file without --tune grain:

https://drive.google.com/file/d/0BzeF_1syecQwSmlDRlFnS2FiZVE/view?usp=sharing

This probably isn't the exact same frame as the previous x265 screenshot, but smoothing is clearly visible:
https://drive.google.com/file/d/0BzeF_1syecQwTkpNWFR4Qk84cUE/view?usp=sharing

c:\x265\x265.exe --y4m --input - --sar 1:1 --colormatrix "bt709" --colorprim "bt709" --transfer "bt709"
--preset slow --rdoq-level 1 --crf 17.25 --output c:\x265\x265_crf17.25.h265

[MeteorRain]

i:\m\v1>x265-ICL.exe --preset slower 720p50_parkrun_ter.y4m 720p50_parkrun_ter.hevc
encoded 504 frames in 283.50s (1.78 fps), 3473.42 kb/s

ICL build produces significant different output (with different bitrate). It is slow (on my 4-cores/4-threads CPU).


Just want to confirm with you that I also observed non binary identical on ICL build from chromashift's build.

[MeteorRain]

And 1.5+380 (https://down.7086.in/x264_Yuuki/x265-Yuuki-1.5%2B380-7b66c36ed9ef%2B10%402d6d5c99324f.7z) 1.5+395 (https://down.7086.in/x264_Yuuki/x265-Yuuki-1.5%2B395-e637273e2ae6%2B10%402d6d5c99324f.7z)

[Vulpix]

Quite interesting result. On 4-cores/8-threads CPU the difference between GCC 5.0.0-O2/O3 and GCC 4.9.3-O2 is 2.46%. On my 4-cores/4-threads CPU GCC 5.0.0-O2 time is 22.2% longer than GCC 4.9.3-O2 and GCC 5.0.0-O3 -- 17.8%. Maybe GCC 5.0.0 on 8-cores/16-threads CPU will be faster than GCC 4.9.3.

I noticed that during the tests, the CPU utilization never reached 100%. It was hovering around 60-80%, so I think seeing as your "threads" are real, physical cores (whereas half of mine are the HTs), the difference is more palpable.

[JohnLai]

Seems to me, most people prefer to use CRF.
On the other hand, I prefer to use CQP.

I would like to know what is the recommended value for x265 CQP?

[YamashitaRen]

Well, somehow ... yes, and on top, let's have thousands of probands participate in the comparison in "ABX tests". This way we can statistically measure how good it works subjectively, means, if x265 will be able to actually "look better" for the average audience than other encoders, at the same bitrates.

That will hopefully show if detail retention is for nitpickers only, or indeed a crucial attribute. :rolleyes: :devil:

I would gladly take part in such a test :)

[RBX]

In my tests, Intel builds are faster than GCC (4.9.2) builds. The difference is greater with psychovisual options and adaptive quantisation turned off (maybe because of assembly code).

Machine: i7-2630QM (4 cores + HT), not 100% utilisation.
Video: 1280x720
Edit: Tested only x265 8bpp

[jlpsvk]

Sorry to all. But I don't understand to frame comparing x265 vs x264 and looking for fine details. I don't care, if there are 2 little dots, or 1, when in real movie watching scenario, you even won't notice, that there are some dots, because you are focusing on something completely different...in real movie watching, crf20 in x265 gives me much small file size with the same visual quality, than with x264 with crf20. and that's important to me...lower bitrate, same resolution, same visual quality while watching (not meaningless frame comparing)... :)

[x265_Project]

Seems to me, most people prefer to use CRF.
On the other hand, I prefer to use CQP.

I would like to know what is the recommended value for x265 CQP?
We don't recommend using constant QP. You will get better visual quality using CRF or 2 pass ABR.

[RBX]

when in real movie watching scenario, you even won't notice, that there are some dots, because you are focusing on something completely different...
With a good source and a big enough screen, even little changes are visible. Doesn't matter much if you intend to watch on something like a laptop.

[Ma]

I noticed that during the tests, the CPU utilization never reached 100%. It was hovering around 60-80%, so I think seeing as your "threads" are real, physical cores (whereas half of mine are the HTs), the difference is more palpable.

Anonymlol results http://forum.doom9.org/showthread.php?p=1714309#post1714309 look similar to my results (difference GCC 5.0.0 vs 4.9.3), but fps are higher. It could be i7 CPU. Maybe your CPU works up to 35 W and this reduces the speed differences.

[xooyoozoo]

I was looking through libvpx's (http://git.chromium.org/gitweb/?p=webm/libvpx.git;a=commit;h=9a1ce7be7d4a3056b9da1df64cb7d5115a513dd9) (initial) interpretation of psy-rd and comparing it to it to x265's.

What immediately stuck out was that for both AQ and Psy, libvpx only considers the Luma plane, which makes obvious sense in a perceptual feature. In contrast, x265 equally weighs all three planes for both AQ and Psy, which has non-obvious implications.

What is "energy" in a Cb/Cr plane, and why should a human care? Is there any research that relates higher chroma complexity to better subjective responses? As far as I know, the answer to "should we consider Chroma as a perceptual estimator" is almost always "make a better Luma estimator".

[LigH]

Daala even tries to derive chrominance from luminance.

[jlpsvk]

With a good source and a big enough screen, even little changes are visible. Doesn't matter much if you intend to watch on something like a laptop.

what do you mead by big screen? have 50" 1080p plasma watching from 3-4 meters and everything is OK.

Anonymlol results http://forum.doom9.org/showthread.php?p=1714309#post1714309 look similar to my results (difference GCC 5.0.0 vs 4.9.3), but fps are higher. It could be i7 CPU. Maybe your CPU works up to 35 W and this reduces the speed differences.

Didi you tried my encode settings?

[anonymlol]

jlpsvk, could you please run Ma's test as well? I'm curious about how much speed difference there is between your AVX2 capable i7-4790k (4.8GHz) and my AVX capable i7-2700k (4.8 GHz).

[Boulder]

what do you mead by big screen? have 50" 1080p plasma watching from 3-4 meters and everything is OK.Everything is OK as you are looking at the screen from quite a big distance :devil:

http://s3.carltonbale.com/resolution_chart.html

My viewing distance (from a 50" plasma) is something like 3.5 meters and I would definitely like to move at least one meter closer but it's not possible at this moment but possibly in the future. Then again, I encode 99% of the time at 720p or lower, depending on the source.

THX even recommends that you sit less 5.6 feet away from the 50" TV :eek:

[jlpsvk]

Yeah....when using 720p, then CRF 17-18 will be OK. :)

[jlpsvk]

jlpsvk, could you please run Ma's test as well? I'm curious about how much speed difference there is between your AVX2 capable i7-4790k (4.8GHz) and my AVX capable i7-2700k (4.8 GHz).

I will, but no earlier than in 13-14 hours. Must wait until current encode will finish. Hmm...I now realised, that after BIOS update I forgot to set the CPU back to 4.8GHz, so now encoding only at 4.2GHz. :(

[Ma]

Didi you tried my encode settings?

I had to stop my previous encoding and start from beginning (sound card driver failure), but now my encoding options are closer to your proposition:
--preset slower --crf 17.0 --rdoq-level 1 --psy-rd 0.4 --deblock -1

If there will be too much blur I will try something stronger (maybe exactly your proposition). I want more details and less blur, but I don't want to destroy quite good and balanced 10-bit x265 default output.

[RBX]

what do you mead by big screen? have 50" 1080p plasma watching from 3-4 meters and everything is OK.


I said "and", that means you need a good source as well. Re-encoding a poorly encoded file does't change much.

[MoSal]

Daala even tries to derive chrominance from luminance.

It's the other way around.

[Ajvar]

Your assumptions about crf are wrong. Just download the files and you will see they are both the same size.
My assumption about CRF is 100% solid truth. And about those 2 files, one was encoded with --tune-film (x264) and second was encoded with --tune-grain (x265) and that's not how proper comparison is made.
jlpsvk, could you please run Ma's test as well? I'm curious about how much speed difference there is between your AVX2 capable i7-4790k (4.8GHz) and my AVX capable i7-2700k (4.8 GHz).

Are you totally sure that AVX Ivy Bridge is actually using AVX for everything and not SSE4 fo some part of work for example? I don't know this but have a feeling that AVX2 CPUs use AVX2 instructions for more work than older processors. This is just speculation though because I am not an expert, just a feeling because how big performace boost it gives.

[benwaggoner]

Are you totally sure that AVX Ivy Bridge is actually using AVX for everything and not SSE4 fo some part of work for example? I don't know this but have a feeling that AVX2 CPUs use AVX2 instructions for more work than older processors. This is just speculation though because I am not an expert, just a feeling because how big performace boost it gives.
In comparisons between the Ivy Bridge cc3.8xlarge instances and the Broadwell cc4.8xlarge instances, we see a healty double-digit encoding speed improvement per clock/core. And the gap has been growing substantially as more AVX2 instructions get checked in. The differential is bigger with faster presets

Some of that is due to other microarchitectural changes, but I think the majority has been from AVX2 for a while now.

And yes, SSE4 and straight assembler gets used for lots of algorithms even with AVX and AVX2. Although there are now lots of AVX2 optimized functions that don't have an AVX function.

Checking the commits is pretty amazing to see the pace of AVX2 optimizations going in over the last month.

[Stereodude]

what do you mead by big screen? have 50" 1080p plasma watching from 3-4 meters and everything is OK.
Perhaps because you're too far away from a screen that size to notice. It's not just a function of screen size or just seating distance. Ignoring potential differences in visual acuity, it's a function of the ratio between screen size is and how far away you are from it.

[Boulder]

My assumption about CRF is 100% solid truth. And about those 2 files, one was encoded with --tune-film (x264) and second was encoded with --tune-grain (x265) and that's not how proper comparison is made.Unfortunately there is no equivalent for --tune film in x265, I would have used it if there were. --tune grain was used to retain as much detail as possible and as you can see from my later post, I also tried without any tuning and --rdoq-level 1 but it still smoothes the image much more than x264.

I'm not looking to compare identical settings, I'm looking to get x265's detail retention level as close as possible to x264's and thus possibly benefit from the more advanced techniques it uses.

[jlpsvk]

jlpsvk, could you please run Ma's test as well? I'm curious about how much speed difference there is between your AVX2 capable i7-4790k (4.8GHz) and my AVX capable i7-2700k (4.8 GHz).

Running now at 4.2GHz only, as I am not by PC. But I noticed something interesting.... --pmode slows down encoding by about 0.3fps. Even if with --pmode, the CPU usage is at 98-100%, the encoding fps is slower. Without --pmode, CPU usage is about 80-85% but encoding fps is higher..

[LigH]

I remember this being mentioned already when it was introduced several months ago: Parallelizing mode decisions may be only useful under specific conditions. Possibly mainly for large dimensions. In my tests with smaller dimensions (up to 720p) and rather outdated CPUs, --pmode always slowed down the encoding.

Instead, parallelizing motion estimation (--pme) can speed up results, depending on the complexity of the encoding (a.k.a. preset).
__

Out-of-schedule, here are some additional builds, experimenting with jb_alvarado's media-autobuild_suite.

x265_1.5+420-24fdb661bb57.7z (https://www.mediafire.com/download/jne4nzav92hl972/x265_1.5+420-24fdb661bb57.7z) (MSYS, MinGW32, GCC 4.8.2, package from xhmikosr + 4x cross compile script, EXE+DLL)
x265_1.5+420-24fdb661bb57.GCC492.7z (http://www.mediafire.com/download/c57rpnqaz8na5bb/x265_1.5+420-24fdb661bb57.GCC492.7z) (MSYS2, MinGW64, GCC 4.9.2, media-autobuild_suite, EXE only, stripped and UPX'ed)

[jlpsvk]

Yep.... Removing --pmode and adding --pme make 1fps difference on my CPU.

[LazyNcoder]

I have a dual-cpu (6core/12thread each) machine and it's killing me (33% - 720p - slow preset - --aq-mode 2 --aq-strength 1.0). I'm using --pmode --pme --threads 48. it makes the final size a bit larger though(I think it lowers the quality too/not sure yet). Now I'll try it without --pmode to see what happens.

There's something I need to know though. someone mentioned that --frame-threads 1 would lower/remove the banding problem. I don't know if it's true or not( I mean I didn't test it yet) but I wonder if using options I mentioned above would increase the banding problem.

[jlpsvk]

@LigH
GCC 4.9.2 added another 0.4fps speed increase!!! Thanks for that build.

[jlpsvk]

I have a dual-cpu (6core/12thread each) machine and it's killing me (33% - 720p - slow preset - --aq-mode 2 --aq-strength 1.0). I'm using --pmode --pme --threads 48. it makes the final size a bit larger though(I think it lowers the quality too/not sure yet). Now I'll try it without --pmode to see what happens.

There's something I need to know though. someone mentioned that --frame-threads 1 would lower/remove the banding problem. I don't know if it's true or not( I mean I didn't test it yet) but I wonder if using options I mentioned above would increase the banding problem.

If you're using 10-bit x265, banding isn't issue. :) So --frame-threads 1 isn't necessary. Tested by myself. Remove --pmode and replace --threads by --pools

[LigH]

Allowing more and more threads (via --pools) doesn't guarantee that more are eventually used: x265 doesn't use more frame threads than it calculates to be efficient.

[jlpsvk]

LigH...on the GCC 4.9.2 video does not play smoothly? Will test again...just first thoughts.

[Motenai Yoda]

Out-of-schedule, here are some additional builds, experimenting with jb_alvarado's media-autobuild_suite.

Did you know how to set it to compile for a specific march or native?
Edit: I'm trying to replace -mtune=generic with -march=native -O2 into media-autobuild_suite.bat

[RBX]

I have a dual-cpu (6core/12thread each) machine and it's killing me (33% - 720p - slow preset - --aq-mode 2 --aq-strength 1.0). I'm using --pmode --pme --threads 48. it makes the final size a bit larger though(I think it lowers the quality too/not sure yet). Now I'll try it without --pmode to see what happens.


I once did tests for pmode and the size was a little bit higher than without it. I also once tried aq-mode 2, and resulting file size was larger than source file size with the settings I normally use. It might have been some minor bug, or source file problem. How well does it work for you?

[LazyNcoder]

I once did tests for pmode and the size was a little bit higher than without it. I also once tried aq-mode 2, and resulting file size was larger than source file size with the settings I normally use. It might have been some minor bug, or source file problem. How well does it work for you?

With pmode, it uses more CPU than without it. But I didn't test if it really helps the speed or not. I always thought more CPU utilization = faster encode.

aq-mode 2 was default in previous versions of x265, and I did lots of encodes with it, and it's still my favorite. I like it better than aq-mode 1. maybe a little larger output sometimes(depends on the content) and the thing you said, never happened for me. (I'm using x265 since v1.2)

[Ma]

Now there is default branch merged with stable but the options "--rdoq-level 1" and "--deblock -1" are still missing from text information at beginning of output HEVC file.

Info in HEVC file after this 2 different encodings is the same:
x265 --preset slow input output
x265 --preset slow --rdoq-level 1 --deblock -1 input output

[LigH]

Did you know how to set it to compile for a specific march or native?

I am already happy when it passes. Modifying? Not me...

jb_alvarado is looking for a new project host, running out of time.

[MeteorRain]

Now there is default branch merged with stable but the options "--rdoq-level 1" and "--deblock -1" are still missing from text information at beginning of output HEVC file.

A quick patch here (https://gist.github.com/msg7086/192b89bcc45c3d3b03ce). Don't know how to reach them to put the patch in though.

[x265_Project]

A quick patch here (https://gist.github.com/msg7086/192b89bcc45c3d3b03ce). Don't know how to reach them to put the patch in though.
Thanks MeteorRain. See https://bitbucket.org/multicoreware/x265/wiki/Contribute for all the details on how to contribute to the x265 project.

We always welcome contributions from talented developers!

[MeteorRain]

Thanks MeteorRain. See https://bitbucket.org/multicoreware/x265/wiki/Contribute for all the details on how to contribute to the x265 project.

We always welcome contributions from talented developers!
I have put the patch under public domain. You should be able to merge it without any problem. I also post on the mailing list.
If you are still looking for a signed agreement, please let me know.

[x265_Project]

I have put the patch under public domain. You should be able to merge it without any problem. I also post on the mailing list.
If you are still looking for a signed agreement, please let me know.
Hi MeteorRain,
No problem. To clarify, we don't want to make anyone jump through hoops to contribute a quick fix for something fairly trivial (a couple of missing parameters in the SEI message string). For trivial fixes, you can just email the x265-devel mailing list and say anything to the effect of "I contribute this". We only need a signed contributor agreement if you want to contribute a more significant patch (optimization, new feature or algorithm improvement, etc.), and you want to be credited as the author.

[legend]

Is there have any good software for x265 encoding.

[Ma]

A quick patch here (https://gist.github.com/msg7086/192b89bcc45c3d3b03ce). Don't know how to reach them to put the patch in though.

Thanks! After work I will try this code.

[LigH]

@ legend:

x265 is software for encoding to HEVC video. If you need a user interface to handle it in an easier way than using a console, you may try: StaxRip, Hybrid, MeGUI, ...

[Ma]

A quick patch here (https://gist.github.com/msg7086/192b89bcc45c3d3b03ce). Don't know how to reach them to put the patch in though.

Now there is much better. There are differences between stderr output and yours new header format: in stderr x265 displays deblock right before sao, numbers are written in form deblock(tC=-1:B=-1).

So my proposition is small modification to your code:
s += sprintf(s, " psy-rd=%.2f", p->psyRd);
s += sprintf(s, " rdoq=%d", p->rdoqLevel);
s += sprintf(s, " psy-rdoq=%.2f", p->psyRdoq);
BOOL(p->bEnableSignHiding, "signhide");
BOOL(p->bEnableLoopFilter, "lft");
if (p->bEnableLoopFilter)
{
BOOL(true, "deblock");
if (p->deblockingFilterBetaOffset || p->deblockingFilterTCOffset)
s += sprintf(s, "(tC=%d:B=%d)", p->deblockingFilterTCOffset, p->deblockingFilterBetaOffset);
}
BOOL(p->bEnableSAO, "sao");

I think we should print information in stderr and header in similar form.

[sborho]

the string emitted by param2string() and included in the info SEI is also used in two-pass stats files and analysis load/save files and it must be parse-able by x265_param_parse, so it must match the command line format. I'm removing 'lft' which is now deprecated, and using "deblock=%d,%d", which is parseable

[Ma]

the string emitted by param2string() and included in the info SEI is also used in two-pass stats files and analysis load/save files and it must be parse-able by x265_param_parse, so it must match the command line format. I'm removing 'lft' which is now deprecated, and using "deblock=%d,%d", which is parseable

Thanks for commit https://bitbucket.org/multicoreware/x265/commits/2da2b9dd7eb3bb724a2436d848921251a69d11e5

[Ma]

There is new header in output HEVC file in x265, but on my favorite site http://chromashift.org/x265_builds/ there is the version 1.5+443, which is the last version with old header (without rdoq-level and deblock).

If someone wants to check new builds (from 1.5+444) I put them on page http://msystem.waw.pl/x265/

[MeteorRain]

Thanks for the builds.

I also put my mod in my signature for those who want. Compiled with lavf and l-smash.

[stax76]

I made a snapshot of the x265 documentation when I've built StaxRip's x265 support and I've found a online diff application showing me what has changed meanwhile:

https://www.diffchecker.com/fk4vsibm

I've a problem now having not enough space in the Analysis section, I'll have to move a few options to a new tab because the tab is full, does anybody have a idea which options could be moved?

http://x265.readthedocs.org/en/latest/cli.html#mode-decision-analysis

Maybe somebody can also look if the order and captions make sense, it looks like this currently:

http://oi59.tinypic.com/jqorv8.jpg


Property RD As New OptionParam With {
.Switch = "--rd",
.Text = "RD:",
.Options = {"0 - SA8D mode and split decisions, intra w/ source pixels",
"1 - Recon generated (better intra), RDO merge/skip selection",
"2 - RDO splits and merge/skip selection",
"3 - RDO mode and split decisions, chroma residual used for sa8d",
"4 - Adds RDO Quant",
"5 - Adds RDO prediction decisions",
"6 - Currently same as 5"},
.Expand = True,
.Help = "Level of RDO in mode decision. The higher the value, the more exhaustive the analysis and the more rate distortion optimization is used. The lower the value the faster the encode, the higher the value the smaller the bitstream (in general)." + CrLf2 + "Default 3."}

Property MinCuSize As New OptionParam With {
.Switch = "--min-cu-size",
.Text = "Minimum CU size:",
.Options = {"64", "32", "16", "8"},
.Values = {"64", "32", "16", "8"},
.Help = "Minimum CU size (width and height). By using 16 or 32 the encoder will not analyze the cost of CUs below that minimum threshold, saving considerable amounts of compute with a predictable increase in bitrate. This setting has a large effect on performance on the faster presets." + CrLf2 + "Default: 8 (minimum 8x8 CU for HEVC, best compression efficiency)"}

Property MaxCuSize As New OptionParam With {
.Switch = "--ctu",
.Text = "Maximum CU size:",
.Options = {"64", "32", "16"},
.Values = {"64", "32", "16"},
.Help = "Maximum CU size (width and height). The larger the maximum CU size, the more efficiently x265 can encode flat areas of the picture, giving large reductions in bitrate. However this comes at a loss of parallelism with fewer rows of CUs that can be encoded in parallel, and less frame parallelism as well. Because of this the faster presets use a CU size of 32." + CrLf2 + "Default: 64"}

Property TUintra As New NumParam With {
.Switch = "--tu-intra-depth",
.Text = "TU Intra Depth:",
.Help = "The transform unit (residual) quad-tree begins with the same depth as the coding unit quad-tree, but the encoder may decide to further split the transform unit tree if it improves compression efficiency. This setting limits the number of extra recursion depth which can be attempted for intra coded units." + CrLf2 + "Default: 1, which means the residual quad-tree is always at the same depth as the coded unit quad-tree." + CrLf2 + "Note that when the CU intra prediction is NxN (only possible with 8x8 CUs), a TU split is implied, and thus the residual quad-tree begins at 4x4 and cannot split any futhrer.",
.MinMaxStep = {1, 4, 1}}

Property TUinter As New NumParam With {
.Switch = "--tu-inter-depth",
.Text = "TU Inter Depth:",
.Help = "The transform unit (residual) quad-tree begins with the same depth as the coding unit quad-tree, but the encoder may decide to further split the transform unit tree if it improves compression efficiency. This setting limits the number of extra recursion depth which can be attempted for inter coded units." + CrLf2 + "Default: 1. which means the residual quad-tree is always at the same depth as the coded unit quad-tree unless the CU was coded with rectangular or AMP partitions, in which case a TU split is implied and thus the residual quad-tree begins one layer below the CU quad-tree.",
.MinMaxStep = {1, 4, 1}}

Property rdoqLevel As New NumParam With {
.Switch = "--rdoq-level",
.Text = "RDOQ Level:",
.Help = "Specify the amount of rate-distortion analysis to use within quantization:" + CrLf2 + "At level 0 rate-distortion cost is not considered in quant" + CrLf2 + "At level 1 rate-distortion cost is used to find optimal rounding values for each level (and allows psy-rdoq to be effective). It trades-off the signaling cost of the coefficient vs its post-inverse quant distortion from the pre-quant coefficient. When --psy-rdoq is enabled, this formula is biased in favor of more energy in the residual (larger coefficient absolute levels)" + CrLf2 + "At level 2 rate-distortion cost is used to make decimate decisions on each 4x4 coding group, including the cost of signaling the group within the group bitmap. If the total distortion of not signaling the entire coding group is less than the rate cost, the block is decimated. Next, it applies rate-distortion cost analysis to the last non-zero coefficient, which can result in many (or all) of the coding groups being decimated. Psy-rdoq is less effective at preserving energy when RDOQ is at level 2, since it only has influence over the level distortion costs.",
.MinMaxStep = {0, 2, 1}}

Property Rect As New BoolParam With {
.Switch = "--rect",
.NoSwitch = "--no-rect",
.Text = "Enable analysis of rectangular motion partitions Nx2N and 2NxN",
.Help = "Enable analysis of rectangular motion partitions Nx2N and 2NxN (50/50 splits, two directions)." + CrLf2 + "Default disabled."}

Property AMP As New BoolParam With {
.Switch = "--amp",
.NoSwitch = "--no-amp",
.Text = "Enable analysis of asymmetric motion partitions",
.Help = "Enable analysis of asymmetric motion partitions (75/25 splits, four directions). At RD levels 0 through 4, AMP partitions are only considered at CU sizes 32x32 and below. At RD levels 5 and 6, it will only consider AMP partitions as merge candidates (no motion search) at 64x64, and as merge or inter candidates below 64x64. The AMP partitions which are searched are derived from the current best inter partition. If Nx2N (vertical rectangular) is the best current prediction, then left and right asymmetrical splits will be evaluated. If 2NxN (horizontal rectangular) is the best current prediction, then top and bottom asymmetrical splits will be evaluated, If 2Nx2N is the best prediction, and the block is not a merge/skip, then all four AMP partitions are evaluated. This setting has no effect if rectangular partitions are disabled." + CrLf2 + "Default disabled."}

Property EarlySkip As New BoolParam With {
.Switch = "--early-skip",
.NoSwitch = "--no-early-skip",
.Text = "Early Skip",
.Help = "Measure full CU size (2Nx2N) merge candidates first; if no residual is found the analysis is short circuited." + CrLf2 + "Default disabled."}

Property FastIntra As New BoolParam With {
.Switch = "--fast-intra",
.NoSwitch = "--no-fast-intra",
.Text = "Fast Intra",
.Help = "Perform an initial scan of every fifth intra angular mode, then check modes +/- 2 distance from the best mode, then +/- 1 distance from the best mode, effectively performing a gradient descent. When enabled 10 modes in total are checked. When disabled all 33 angular modes are checked. Only applicable for --rd levels 4 and below (medium preset and faster)."}

Property BIntra As New BoolParam With {
.Switch = "--b-intra",
.NoSwitch = "--no-b-intra",
.Text = "Evaluate intra modes in B slices",
.Help = "Enables the evaluation of intra modes in B slices." + CrLf2 + "Default disabled."}

Property FastCBF As New BoolParam With {
.Switch = "--fast-cbf",
.Text = "Short circuit analysis if a prediction is found that does not set the coded block flag",
.Help = "Short circuit analysis if a prediction is found that does not set the coded block flag (aka: no residual was encoded). It prevents the encoder from perhaps finding other predictions that also have no residual but require less signaling bits or have less distortion. Only applicable for RD levels 5 and 6." + CrLf2 + "Default disabled."}

Property CUlossless As New BoolParam With {
.Switch = "--cu-lossless",
.Text = "CU Lossless",
.Help = "For each CU, evaluate lossless (transform and quant bypass) encode of the best non-lossless mode option as a potential rate distortion optimization. If the global option --lossless has been specified, all CUs will be encoded as lossless unconditionally regardless of whether this option was enabled. Default disabled. Only effective at RD levels 3 and above, which perform RDO mode decisions."}

Property Tskip As New BoolParam With {
.Switch = "--tskip",
.Text = "Enable evaluation of transform skip coding for 4x4 TU coded blocks",
.Help = "Enable evaluation of transform skip (bypass DCT but still use quantization) coding for 4x4 TU coded blocks. Only effective at RD levels 3 and above, which perform RDO mode decisions." + CrLf2 + "Default disabled."}

Property TskipFast As New BoolParam With {
.Switch = "--tskip-fast",
.Text = "Only evaluate transform skip for NxN intra predictions (4x4 blocks)",
.Help = "Only evaluate transform skip for NxN intra predictions (4x4 blocks). Only applicable if transform skip is enabled. For chroma, only evaluate if luma used tskip. Inter block tskip analysis is unmodified." + CrLf2 + "Default disabled."}

[MeteorRain]

From my point of view, I'm completely confused by these options.
For most users using a GUI, balance between encoding efficiency and speed should be well grouped into a slide bar, from very fast to very slow, and that's it.
It's not very possible that users toggle and test every option to find the optimistic settings before they start encoding.

[stax76]

Presets is the first thing that every GUI supports I guess. In my case there are some things I don't like about trackbars/sliders and radioboxes, I'm not saying they are bad for users, I like to use them myself in other applications, I just don't happen to use them as programmer in my applications.

[Ajvar]

Huyston, we have a problem. Using LAV 0.64 (12-30) with CUDA decoder trying to play a file encoded with 444 and up I get player crach and info says it's because of cuvid.dll crash. With LAV 0.63 all is OK but HEVC decoding made a leap in 64 version.
Files encoded in 439 and before play super fine.

I use GUI software (Hybrid) but really doubt that it has something to that.
I used many different builds sources: snowfag, MA's, Yuuki's to doublecheck.
Presets medium and slow. CRF and 2pass bitrate.
"C:\PROGRA~1\Hybrid\x265-8b.exe" --pmode --input - --input-res 1920x1080 --fps 30 --no-high-tier --min-cu-size 16 --no-open-gop --crf 22.7 --no-rdoq-level --no-psy-rdoq --vbv-maxrate 8000 --vbv-bufsize 8000 --deblock=-1:-1 --colormatrix bt470bg
439 - http://fs8.www.ex.ua/load/6ca2e6560a09a8e09df9ebe3026c54e4/158030847/439.mkv
445 - http://fs8.www.ex.ua/load/1dce5ce570740508b2a882ccceb91a76/158030905/445%20bug.mkv

[MeteorRain]

Huyston, we have a problem. Using LAV 0.64 (12-30) with CUDA decoder trying to play a file encoded with 444 and up I get player crach and info says it's because of cuvid.dll crash. With LAV 0.63 all is OK but HEVC decoding made a leap in 64 version.
Files encoded in 439 and before play super fine.

I use GUI software (Hybrid) but really doubt that it has something to that.
I used many different builds sources: snowfag, MA's, Yuuki's to doublecheck.
Presets medium and slow. CRF and 2pass bitrate.
"C:\PROGRA~1\Hybrid\x265-8b.exe" --pmode --input - --input-res 1920x1080 --fps 30 --no-high-tier --min-cu-size 16 --no-open-gop --crf 22.7 --no-rdoq-level --no-psy-rdoq --vbv-maxrate 8000 --vbv-bufsize 8000 --deblock=-1:-1 --colormatrix bt470bg
439 - http://www.ex.ua/load/158030847?fs_id=8
445 - http://www.ex.ua/load/158030905?fs_id=8

The file storage is quite confusing as I'm seeing Japanese and Russian mixing on a single web page.

But anyway I'll try with your settings and see what I can do.

= EDIT =

Switched to English and still have no idea how to get the files. Would you mind using some other storages?

And I tried with your settings. They just produced same files, binary identical on the video data part.

[Ajvar]

The file storage is quite confusing as I'm seeing Japanese and Russian mixing on a single web page.

But anyway I'll try with your settings and see what I can do.

= EDIT =

Switched to English and still have no idea how to get the files. Would you mind using some other storages?

And I tried with your settings. They just produced same files, binary identical on the video data part.

My bad. Updated with direct links now, sorry.
Settings is nothing. It's about different encoder version.