x265 HEVC Encoder

[-Habanero-]

Don't get me wrong, I'm not really complaining, just reporting what I observe.
As a non-programmer amateur video hobbyist, beta testing is all I can contribute.

[x265]

Ok x265's CRF is unpredictable. I'm encoding the credits of a movie and the bitrates are much higher than its x264 counterpart. x264 at CRF20 outputs 264 kb/s, x265 CRF20 440 kb/s, x264 CRF30 60 kb/s and x265 CRF30 86 kb/s.

x265's CRF is so unintuitive. Is it not supposed to produce the same filesize as x264 (but better quality)? With x264 keeping it at 18 provides consistent quality with any type of video. With x265 I have to experiment between 18-26.

Habenero - x265 is a totally different encoder than x264. HEVC is a totally different encoding standard than AVC. You shouldn't expect x265 settings to produce similar results to x264 with the same settings. We don't look at that, and we don't try to "normalize" x265 to x264. The command syntax is similar to enable x264 users to more easily adopt x265, but the behavior and results are quite different.

[sophisticles]

a. crf will produce the same objective quality for different inputs, is simply wrong

Actually this is exactly what the x264 developers who first introduced CRF led everyone to believe and has been the "selling point" of this rate control mode from the beginning.

The Pepper Lover (get it?) can be forgiven for assuming that CRF 18 or whatever value will produce the same objective quality for different inputs because that's exactly what CRF is supposed to do, you choose a supposed quality and the encoder uses the amount of bit rate it needs to achieve that quality.

And he is also correct in concluding that if CRF 18 with x264 results in a given quality then x265, who MCW claims is up to 50% more efficient than x264 with regards to bit rate / quality ratio, must be able to achieve the same quality at a higher CRF.

As I have stated before, I would rather use a 2 pass encode, choose the bit rate that I can live with for a given resolution and be done with it.

To me it always seemed absurd that people were happy encoding 2 different 720p files, one would use double the bit rate of the other but so long they both used the same CRF value then everything was cool. Doesn't make any sense to me.

[poisondeathray]

a. crf will produce the same objective quality for different inputs, is simply wrong

Actually this is exactly what the x264 developers who first introduced CRF led everyone to believe and has been the "selling point" of this rate control mode from the beginning.

No developer has said anything about OBJECTIVE quality using CRF. The "selling point" is roughly constant perceptual quality, which is SUBJECTIVE.

"Objective" implies repeatable verifiable metrics, like PSNR, SSIM .

Modelling human perception is difficult. But some simple concepts can be applied and are probably valid - e.g. in a competely static scene / locked off camera - it's easier to see detail, than if you have a whip pan or fast motion. You can "cheat" and reduce the quality on the fast motion, because no "regular" human can see the artifacts in quick motion (only if you slow it down, or go frame by frame and examine)

And he is also correct in concluding that if CRF 18 with x264 results in a given quality then x265, who MCW claims is up to 50% more efficient than x264 with regards to bit rate / quality ratio, must be able to achieve the same quality at a higher CRF.

This would be incorrect. You cannot compare CRF across different encoding settings, let alone different encoders.

As I have stated before, I would rather use a 2 pass encode, choose the bit rate that I can live with for a given resolution and be done with it.

To me it always seemed absurd that people were happy encoding 2 different 720p files, one would use double the bit rate of the other but so long they both used the same CRF value then everything was cool. Doesn't make any sense to me.

The problem with that is you don't "know" what is an appropriate bitrate for that content. You might have a rough idea, but that's it . Even a very highly experienced person cannot reliably determine this

You can have a rough idea e.g. obviously an action movie with explosions, high content complexity will require more bitrate than a slow moving drama - but how much more ? How do you determine what is "appropriate" ?

Neither rate control method is "perfect". There are pros/cons to each method, but that's the main rationale for using CRF.

[-Habanero-]

[QUOTE=x265;2386308]

Habenero - x265 is a totally different encoder than x264. HEVC is a totally different encoding standard than AVC. You shouldn't expect x265 settings to produce similar results to x264 with the same settings. We don't look at that, and we don't try to "normalize" x265 to x264. The command syntax is similar to enable x264 users to more easily adopt x265, but the behavior and results are quite different.

Whatever you think is best. But I hope you understood my point. x265 CRF30 produces crappy results on most videos which is expected but the quality was excellent with some content like credits. This shouldn't happen. The quality should be more or less constant.
x264 I only need to use values between 18-20 as it's fairly consistent, x265 I need to pick between 18-26. So far I have a general clue what works for what: lower for film, a bit higher for animation and much higher for more linear animation which I guess credits fall under.

sophisticles, the problem with 2pass is that you have to be able to guess in advance how much bitrate you need or how much to downsample if you're aiming for fixed filesize. My friend has a talent for this and always knows exactly how much bitrate each video needs but I don't. It's not as simple as "more action more bitrate". Degradation is less noticeable in films with lots of action while less dynamic films need stricter quality control because loss will be more noticeable, especially the fine contours of people's faces that the camera is focused on.

And he is also correct in concluding that if CRF 18 with x264 results in a given quality then x265, who MCW claims is up to 50% more efficient than x264 with regards to bit rate / quality ratio, must be able to achieve the same quality at a higher CRF.

That's true but not the point. The point was the obvious variability in quality the same CRF produces which makes encoding unintuitive when you can't trust it to be consistent.

This would be incorrect. You cannot compare CRF across different encoding settings, let alone different encoders.

Why not? x264 with weak settings at CRF18 will produce a file with a higher bitrate but same quality as CRF18 with stronger settings.

[poisondeathray]

This would be incorrect. You cannot compare CRF across different encoding settings, let alone different encoders.

Why not? x264 with weak settings at CRF18 will produce a file with a higher bitrate but same quality as CRF18 with stronger settings.

This trend in filesize occurs in general (but not always), BUT it absolutely DOES NOT mean same "quality" when you use different settings. Just search there are posts about this and examples where the trend is reversed for some presets and settings, both in terms of filesize and where "quality" was defined as SSIM . Go prove it yourself, encode with crappy settings and one run with slower settings. The crappy settings will look worse 99% of the time (visually a lot worse, forget about metrics). I'll say it again - it absolutely does not mean same quality when different settings are used. It's a huge misconception , I don't know who started that idea, but they should be shot

You cannot compare CRF with different settings within the same encoder, because different settings at the same CRF for the same encoder will yield different results - you said so yourself. Thus the idea that it might represent a rough indication of "quality" is invalidated when you use different encoding settings (let alone different standards). Therefore, the idea that x265 at a given CRF would produce something similar to x264 doesn't make any sense. x264 doesn't even have many things like CTU's etc... How on earth would you expect them to be comparable ? They aren't same settings obviously, they aren't even the same encoder or even the same standard . The weighting isn't the same across different encoders or standards. x262 (yes, not a typo), the MPEG2 encoder has CRF encoding as well did you expect the same results as well? CRF isn't some immutable standard - all it is about is rate control. It's just "easy" to say, or tell people that it's a rough approximation of "quality" when the encoding settings are the same

Also , there isn't a 1:1 consistent mappable CRF relationship even within the same encoder. Did you know CRF is an arbitrary scale that was rescaled several times in x264 development over the years? ie. CRF "18" (or whatever number) meant something different at different times over the years - so how do you expect CRF 18 to "mean" the same thing between different encoders and completely different standards ?

[LigH.de]

Most of all, please don't use the term "quality" like an objective metric of your subjective impression. Humans may imagine "good quality" as "few distortions from the recognizable content", whereas computer software can only measure the difference between an original image and an encoded-and-reconstructed image by a technical metric which is not equal to the human recognition.

CRF tries to limit a difference. But it is unable to guarantee satisfaction. Especially not when the original material was not already satisfying.

[_Al_]

CRF {whatever} is just a made up thing, x264 developers use a number regarding used quantizer, but other encoder could choose whatever number between 0 and 1 (like MainConcept if I remember correctly), other encoder could choose alphabet letters from a to z, whatever.

You cannot compare anything between encoders, you just find "your number" in x265 as you had found in x264 (number 18). And who says that even steps would be the same like in x264 , for one step in x264 you might need 1.2 steps in x265 (I don't know I made this up as an example). It is all made up to some scale that you should get slowly familiar with.

[LigH.de]

CRF {whatever} is just a made up thing...

Not really. The "rate factor" is a measurable value in the encoding process. It may be scaled to a value close to the average quantization factor so that humans can imagine it. Still, it is not completely arbitrary.

[-Habanero-]

This would be incorrect. You cannot compare CRF across different encoding settings, let alone different encoders.

Why not? x264 with weak settings at CRF18 will produce a file with a higher bitrate but same quality as CRF18 with stronger settings.

This trend in filesize occurs in general (but not always), BUT it absolutely DOES NOT mean same "quality" when you use different settings. Just search there are posts about this and examples where the trend is reversed for some presets and settings, both in terms of filesize and where "quality" was defined as SSIM . Go prove it yourself, encode with crappy settings and one run with slower settings. The crappy settings will look worse 99% of the time (visually a lot worse, forget about metrics). I'll say it again - it absolutely does not mean same quality when different settings are used. It's a huge misconception , I don't know who started that idea, but they should be shot

You cannot compare CRF with different settings within the same encoder, because different settings at the same CRF for the same encoder will yield different results - you said so yourself. Thus the idea that it might represent a rough indication of "quality" is invalidated when you use different encoding settings (let alone different standards). Therefore, the idea that x265 at a given CRF would produce something similar to x264 doesn't make any sense. x264 doesn't even have many things like CTU's etc... How on earth would you expect them to be comparable ? They aren't same settings obviously, they aren't even the same encoder or even the same standard . The weighting isn't the same across different encoders or standards. x262 (yes, not a typo), the MPEG2 encoder has CRF encoding as well did you expect the same results as well? CRF isn't some immutable standard - all it is about is rate control. It's just "easy" to say, or tell people that it's a rough approximation of "quality" when the encoding settings are the same

Also , there isn't a 1:1 consistent mappable CRF relationship even within the same encoder. Did you know CRF is an arbitrary scale that was rescaled several times in x264 development over the years? ie. CRF "18" (or whatever number) meant something different at different times over the years - so how do you expect CRF 18 to "mean" the same thing between different encoders and completely different standards ?

I did a test just now, CRF18 with good and crappy settings. Both look the same quality to me. What do you think?

Yes the CRF was rescaled several times but you are missing the point. I never said x264 CRF18 and x265 CRF18 should output the same quality. I said the number should be quality-consistent within the same encoder. CRF30 should not, under any circumstances output great quality for one scene but really crappy for another.
So yeah, x264 CRF was rescaled, from 18 to 16 to now 17 but it still outputted consistent quality.

[LigH.de]

You still misunderstand the meaning of "quality" in terms of "rate factor".

A constant rate factor does not mean a "constantly good looking result". No encoder is able to measure how convenient the result looks to a human.

It can only try to keep a difference between an original and a reconstructed frame, measured in a specific metric, below a specific threshold; a similar numerical difference may still look more or less annoying to a human, depending on the video content of each scene.

[-Habanero-]

Yes and a higher rate factor = more loss of the original signal which should correlate exactly with an increasingly diminished quality, no?
It shouldn't depend on video content because even a video of a small moving rectangle on a black background would have its only noticeable content visibly degraded with a high CRF.

[poisondeathray]

I did a test just now, CRF18 with good and crappy settings. Both look the same quality to me. What do you think?

Yes the CRF was rescaled several times but you are missing the point. I never said x264 CRF18 and x265 CRF18 should output the same quality. I said the number should be quality-consistent within the same encoder. CRF30 should not, under any circumstances output great quality for one scene but really crappy for another.
So yeah, x264 CRF was rescaled, from 18 to 16 to now 17 but it still outputted consistent quality.

Sorry - all the other stuff was to cover whatever sophisticles was rambling about which preceded your post - he was the one making some inferences about your statement regarding the relationship of x264 to x265. But the main point was to reiterate that you cannot compare CRF using different encoding settings.

Your tests used x264 - did you realize this is a x265 thread? But I would say in your example, there are only minor differences in terms of subjective quality. But the more tests you do, you will eventually come to realize there are differences, and they are not the same. This is one of those things that has been established many years ago. Whether or not you can clearly "see" it or not depends on several factors. But for every test that you show only minor subjective perceptual differences, I can show you 10 that show significant differences. Maybe your short sample is that 1 in 10 that show minor differences. (And I'm not talking about "ultrafast" only which disables deblocking). You can search for the discussion in older threads. This question was also revisted recently in a thread at videohelp , and some videos were posted IIRC. Whether or not this applies to x265 remains to be seen, but I suspect it is the case as well

[-Habanero-]

I realize its an x265 thread but the whole point I'm trying to illustrate was x265's volatility vs. x264's consistency.
I welcome your examples that prove the opposite though.

[poisondeathray]

x265 is still in rapid development with frequent commits, so a lot is changing. Maybe there was a problem with the snapshot you used ?

x264 consistency ? It's consistent only because it's very mature and people that use it know how it "behaves" with different types of conditions. The only consistency you can say about CRF is smaller values yield larger filesize. You can't say anything about "quality" if you used different encoding settings . You cannot compare CRF with different encoding settings - it does NOT mean same quality.

Examples of same CRF with different settings ? Here is a recent one jagabo posted at videohelp:
https://forum.videohelp.com/threads/368914-24-fps-and-very-fast-STELLAR-DVD-rips-in-Han...=1#post2363323

You have to go back a few years for the old discussion. If you still can't see difference, I'll try to point differences out on other examples.

[-Habanero-]

That example was not a typical case and something went wrong because the one with stronger settings was a larger filesize so no wonder it looked better. That video was nothing but blur and noise which I don't think many people encode. You might say film credits don't represent a typical video but they are present in every film.
So yeah, do you have a more typical example?

[poisondeathray]

That's what you call "consistent", right? That's why it's inconsistent as well. So what do you think will happen in a dark grainy movie ? As I said before - there are many examples posted where the trend flips (larger filesize at slower settings). Or it only flips at 1 setting like superfast. The only "consistent" thing, is at the same settings, you will usually get larger filesizes at lower CRF values. You cannot say anything when you use different settings.

You could argue that your example wasn't typical either - it looked like a re-encode of a re-encode and lacked any details. The details are where you will typically see the differences.

I'll go look at some of my old HDD's when I have time, but this is stuff that has been conclusively proven already (years ago). Nothing has changed. You cannot compare CRF with different settings. The developers even reiterate this again and again. In the meantime, why don't you try some encodes and if they are very similar, post them - and you should move x264 discussion to another thread (so post them in another thread)

[poisondeathray]

@-Habanero-

please carry on the x264 discussion here, and keep this thread on topic with x265
https://forum.videohelp.com/threads/371760-Reposting-some-old-x264-tests-crf-vs-settings?p=2389316

[-Habanero-]

Keep on topic? Okay:

x264_10 --crf 18.0 --deblock 1:1 --bframes 16 --b-adapt 2 --ref 16 --qpmin 10 --qpmax 51 --qcomp
0.7 --rc-lookahead 50 --aq-mode 2 --merange 24 --me umh --direct auto --subme 11 --partitions all -
-trellis 2 --no-fast-pskip --no-psy --output "dbz intro.mkv" "dbz intro.avs"
avs [info]: 1600x900p 0:0 @ 24000/1001 fps (cfr)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2
x264 [info]: profile High 10, level 5.0, 4:2:0 10-bit
x264 [info]: frame I:17 Avg QP:27.84 size: 68507
x264 [info]: frame P:906 Avg QP:32.19 size: 27560
x264 [info]: frame B:1717 Avg QP:34.38 size: 6314
x264 [info]: consecutive B-frames: 11.8% 13.9% 14.2% 23.5% 9.1% 17.0% 0.5% 0.9% 0.7% 1.1% 0.0%
7.3% 0.0% 0.0% 0.0% 0.0% 0.0%
x264 [info]: mb I I16..4: 40.7% 40.2% 19.1%
x264 [info]: mb P I16..4: 26.7% 14.5% 9.5% P16..4: 21.4% 9.2% 3.1% 0.6% 0.0% skip:14.8%
x264 [info]: mb B I16..4: 2.9% 1.1% 0.8% B16..8: 24.7% 5.1% 0.8% direct: 0.8% skip:63.8% L
0:46.0% L1:47.1% BI: 6.9%
x264 [info]: 8x8 transform intra:28.2% inter:62.3%
x264 [info]: direct mvs spatial:99.6% temporal:0.4%
x264 [info]: coded y,uvDC,uvAC intra: 17.0% 37.8% 12.6% inter: 6.7% 6.9% 0.7%
x264 [info]: i16 v,h,dc,p: 24% 17% 13% 45%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 18% 10% 47% 4% 4% 4% 4% 4% 5%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 14% 9% 61% 3% 3% 3% 3% 3% 3%
x264 [info]: i8c dc,h,v,p: 18% 34% 16% 32%
x264 [info]: Weighted P-Frames: Y:4.6% UV:3.6%
x264 [info]: ref P L0: 46.8% 12.5% 8.5% 3.3% 4.3% 7.7% 5.4% 2.0% 1.4% 1.3% 1.2% 1.5% 1.7%
1.1% 0.9% 0.5%
x264 [info]: ref B L0: 77.7% 8.9% 4.0% 2.3% 1.5% 1.7% 0.9% 0.7% 0.5% 0.5% 0.6% 0.3% 0.2%
0.2% 0.1%
x264 [info]: ref B L1: 94.1% 5.9%
x264 [info]: kb/s:2686.47

encoded 2640 frames, 1.65 fps, 2686.52 kb/s

avs4x26x.exe --x26x-binary x265.exe "dbz intro.avs" --crf 20 --preset veryslow --ref 6 --bframes
16 --no-psy-rd --no-psy-rdoq --rc-lookahead 40 --qcomp 0.7 --allow-non-conformance -o "dbz intro.he
vc"
avs [info]: AviSynth 2.60, build:Mar 31 2015 [16:38:54]
avs [info]: Video colorspace: YV12
avs [info]: Video resolution: 1600x900
avs [info]: Video framerate: 24000/1001
avs [info]: Video framecount: 2640
avs4x26x [info]: "x265.exe" - --crf 20 --preset veryslow --ref 6 --bframes 16 --no-psy-rd --no-psy-r
doq --rc-lookahead 40 --qcomp 0.7 --allow-non-conformance -o "dbz intro.hevc" --frames 2640 --fps 24
000/1001 --input-res 1600x900 --input-csp i420
yuv [info]: 1600x900 fps 24000/1001 i420p8 unknown frame count
raw [info]: output file: dbz intro.hevc
x265 [info]: HEVC encoder version 1.6+298-4a7176bab742
x265 [info]: build info [Windows][GCC 4.8.2][32 bit] 16bpp
x265 [warning]: Assembly not supported in this binary
x265 [info]: using cpu capabilities: none!
x265 [info]: Main 10 profile, Level-4 (Main tier)
x265 [info]: Thread pool created using 8 threads
x265 [info]: frame threads / pool features : 3 / wpp(15 rows)
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 / 3 inter / 3 intra
x265 [info]: ME / range / subpel / merge : star / 57 / 4 / 4
x265 [info]: Keyframe min / max / scenecut : 23 / 250 / 40
x265 [info]: Lookahead / bframes / badapt : 40 / 16 / 2
x265 [info]: b-pyramid / weightp / weightb / refs: 1 / 1 / 1 / 6
x265 [info]: AQ: mode / str / qg-size / cu-tree : 1 / 1.0 / 64 / 1
x265 [info]: Rate Control : CRF-20.0
x265 [info]: tools: rect amp rd=6 rdoq=2 signhide tmvp b-intra
x265 [info]: tools: strong-intra-smoothing deblock sao
x265 [info]: frame I: 15, Avg QP:15.42 kb/s: 8842.92
x265 [info]: frame P: 864, Avg QP:17.88 kb/s: 4460.43
x265 [info]: frame B: 1761, Avg QP:20.70 kb/s: 830.47
x265 [info]: global : 2640, Avg QP:19.75 kb/s: 2063.98
x265 [info]: Weighted P-Frames: Y:5.2% UV:4.4%
x265 [info]: Weighted B-Frames: Y:6.4% UV:4.9%
x265 [info]: consecutive B-frames: 31.9% 16.8% 18.0% 17.7% 3.8% 5.9% 1.9% 1.3% 0.2% 0.5% 0.0% 1.7% 0
.0% 0.1% 0.2% 0.0% 0.0%

encoded 2640 frames in 60127.23s (0.04 fps), 2063.98 kb/s

I decided to test a high resolution video with 10-bit with both encoders. Goal was high quality. According to SSIM, x265 video is slightly lower quality but I couldn't tell the difference. 30% more efficiency. This is pretty good. 900p at 2 Mb/s.
This wasn't a fair comparison, though. x264 used 16 refs while x265 used only 6. But considering this short one-minute video took 18 hours to encode, I really couldn't use max refs.

www.sendspace.com/file/y4nnih

[Selur]

Comparing ssim/psnr/... while the output files have different sizes makes no sense. (small size derivations are okay, but not the in the magnitude you are describing here)
Either the ssim/psnr/... value or the file size have to be fixed to make reasonable assumptions about quality of the output.

[-Habanero-]

SSIMs are 0.99459 and x265 0.99397. Not too much of a difference. If I used 16 refs in x265 I bet it would beat x264 SSIM.

[LigH.de]

Try to calculate the SSIM values (more exactly, their difference to 1.0) in dB, and you may be surprised about the difference. This logarithmical value is closer to the human recognition than the original SSIM value.

Based on energy calculation formula, I get: 22.2 vs. 22.6 dB; still little, but hopefully more obvious that it can easily be spoiled by comparing results of too different circumstances.

[x265]

x265 version 1.7 has been released. This release contains a large amount of assembly code optimizations, some preliminary support for high dynamic range content, improvements for multi-library support, and some new quality features.

Full documentation at: http://x265.readthedocs.org/en/1.7/

This release simplifies the multi-library support introduced in version 1.6. Any libx265 can now forward API requests to other installed libx265 libraries (by name) so applications like ffmpeg and the x265 CLI can select between 8bit and 10bit encodes at runtime without the need of a shim library or library load path hacks. See --output-depth, and http://x265.readthedocs.org/en/1.7/a...rary-interface

For quality, x265 now allows you to configure the quantization group size smaller than the CTU size (for finer grained AQ adjustments). See --qg-size.

x265 now supports limited mid-encode reconfigure via a new public method: x265_encoder_reconfig()

For HDR, x265 now supports signaling the SMPTE 2084 color transfer function, the SMPTE 2086 mastering display color primaries, and the content light levels. See --master-display, --max-cll

x265 will no longer emit any non-conformant bitstreams unless --allow-non-conformance is specified.

The x265 CLI now supports a simple encode preview feature. See --recon-y4m-exec.

The AnnexB NAL headers can now be configured off, via x265_param.bAnnexB This is not configurable via the CLI because it is a function of the muxer being used, and the CLI only supports raw output files. See --annexb

Misc:
* --lossless encodes are now signaled as level 8.5
* --profile now has a -P short option
* The regression scripts used by x265 are now public, and can be found at: https://bitbucket.org/sborho/test-harness
* x265's cmake scripts now support PGO builds, the test-harness can be used to drive the profile-guided build process.

[aymanalz]

Quick question: Is x265 encoding expected to become significantly faster in future?

Long version: I know that it is well understood that as of now, HEVC encoding takes much longer than AVC. I'm just wondering if this will change as the code gets more optimized. Even on my quad core i7 system, encoding with x265 is impossibly slow - often less than 1 fps. It is at least an order of magnitude (sometimes two orders of magnitude) slower than encoding with x264 at the same bit rate, and settings that I feel gives comparable visual quality. From what I see so far, x265 does have better quality for the same bitrate. But the speed is prohibitively slow. "Medium" or slower settings are impossibly slow for x265. And increasing the RDO has a huge speed penalty. So is encoding speed something that the developers are looking to improve, or will it always be the case that x265 is this slow in comparison to x264?

I'm using handbrake for both x264 and x265.

[Selur]

Atm. I'm got ~14fpps for reencoding 1920x1080 AVC content using the 'medium' preset , so I doubt that I will hit realtime encoding with my current cpu.

x265 --pmode --pme --input - --input-res 1920x1080 --fps 23.976 --no-high-tier --no-open-gop --qpfile GENERATED_QP_FILE --no-rdoq-level --no-psy-rdoq --colormatrix bt709 --output "h:\Temp\Transformers - Age of Extinction 2014 1080P-003.265"

using x264 at 'medium' preset and:

x264 --crf 32 --profile high --level 4.1 --vbv-maxrate 62500 --vbv-bufsize 78125 --qpfile GENERATED_QP_FILE --non-deterministic --colormatrix bt709 --input-csp i420  --fps 24000/1001 --input-res 1920x1080 --output "h:\Temp\Transformers - Age of Extinction 2014 1080P-003.264" -

I get ~49fps.

Since the x265 folks are constantly adding assembler optimization encoding will get faster, but "significantly" like 50% or me hitting real time encoding under the mentioned conditions, I doubt it.

Cu Selur

Ps.: using a i7 4770k.

[sophisticles]

MCW, the company behind x265, claims that it's newest builds can do 10bit 4k encoding on a dual xeon system at 60fps:

http://www.multicorewareinc.com/multicoreware-demonstrates-high-quality-4k-10-bit-real...ing-with-x265/

One thing to keep in mind is that MCW seems to have at least 2 different x265 code bases, the one that is publicly available that apps like Handbrake use and a second one only available under a licensing agreement.

MCW reps have publicly stated that the non-public code base, the one which is funded by corporate sponsorships and licensing agreements, gets priority with regard to development, bug fixes and new features and at some point down the road some of the improvements may be pushed into the public branch.

I personally wouldn't hold my breathe waiting, MCW claims to have an OCL accelerated OCL variant that has been used in a broadcast environment, such as the Olympics, but they also state that this variant is only available via a licensing agreement and it certainly seems that it is a different code base from the OCL patch that's publicly available for x264.

In short, I wouldn't wait for the public version of x265 to reach real time encoding with HD and UHD on regular desktop hardware anytime soon; I figure it will be at least 2-3 years before we have $200 cpu's fast enough to do 1080p x265+medium at 30fps or faster.

It's not going to matter much anyway, Google is hard at work on VP10, Intel is getting ready to release a QS version with HEVC support and once someone finally write the code to fully utilize Nvidia's nvenc chip I doubt that too many people will be bothering with any software based hevc encoder, be it x265, DivX, f265 or Strongene.

[LigH.de]

MultiCoreWare spent a lot of development already in implementing fast assembly routines, especially using SSE4 and AVX2 on modern CPUs, so I doubt there are any more significant speed-ups to be expected just by optimizing the code. And the main reason for x265 taking a lot more time than x264 in reasonable presets will be the much more complex design of the encoder, trying a lot more different techniques to find similar video parts to be reduced in size.

You can configure x265 to work faster by selecting a faster preset; but that means that x265 will take less efforts in preserving good quality by searching for reducible similarities. You may not be able to spare bitrate, compared to x264, if both are running at the same speed, to preserve enough quality to be satisfied.

[aymanalz]

Atm. I'm got ~14fpps for reencoding 1920x1080 AVC content using the 'medium' preset , so I doubt that I will hit realtime encoding with my current cpu.

x265 --pmode --pme --input - --input-res 1920x1080 --fps 23.976 --no-high-tier --no-open-gop --qpfile GENERATED_QP_FILE --no-rdoq-level --no-psy-rdoq --colormatrix bt709 --output "h:\Temp\Transformers - Age of Extinction 2014 1080P-003.265"

using x264 at 'medium' preset and:

x264 --crf 32 --profile high --level 4.1 --vbv-maxrate 62500 --vbv-bufsize 78125 --qpfile GENERATED_QP_FILE --non-deterministic --colormatrix bt709 --input-csp i420  --fps 24000/1001 --input-res 1920x1080 --output "h:\Temp\Transformers - Age of Extinction 2014 1080P-003.264" -

I get ~49fps.

Since the x265 folks are constantly adding assembler optimization encoding will get faster, but "significantly" like 50% or me hitting real time encoding under the mentioned conditions, I doubt it.

Cu Selur

Ps.: using a i7 4770k.

I don't need real time encoding, just reasonable times would do. Mine is a laptop CPU (3612QM), so it's not exactly the most powerful thing out there - but x265 encoding is the only issue where I have felt the inadequacy. It can play any modern game with ease, without even using 20% of the CPU.

That's why I want to know this, whether x265 will improve in speed in future, by significant amounts. If not, there is no point in waiting for x265 to get better, to transcode the 100s of GB of video that I have.

In general, I feel that x265 would not be worth the effort, if it will always remain this slow. One might as well use x264.

[aymanalz]

It's not going to matter much anyway, Google is hard at work on VP10, Intel is getting ready to release a QS version with HEVC support and once someone finally write the code to fully utilize Nvidia's nvenc chip I doubt that too many people will be bothering with any software based hevc encoder, be it x265, DivX, f265 or Strongene.

But that didn't apply so far to x264, right? Despite quicksync being much (,much) faster, software based encoding was still worth the time spent, to get better quality. Also because we could fine tune so many options when using software based encoding, as opposed to quicksync.

Would that be any different for x265? I mean, would hardware based encoding using video cards have the same quality as software based ones?

[aymanalz]

MultiCoreWare spent a lot of development already in implementing fast assembly routines, especially using SSE4 and AVX2 on modern CPUs, so I doubt there are any more significant speed-ups to be expected just by optimizing the code.

That's what I am afraid of, and that's what I want clarified. If it cannot be sped up significantly, I doubt that it would be as great and succesful a format as x264 is.