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 ... !!!