x265 vs x264

[deadrats]

tom's has done a nice comparison between the two and as expected x265 wins hands down:

http://www.tomshardware.com/reviews/x265-hevc-encoder,3565.html

the important points to take away from the article are these:

It’s currently x86-only (albeit with support for advanced instruction sets like AVX2), lacks B-frame support (preventing it from achieving maximum compression), and doesn’t yet include some of the optimizations taken from x264 (like look-ahead and rate control).

With that in mind, let’s take a quick peek at how pre-alpha x265 stacks up against the well-optimized x264. For this one, we're using the following command: x264 --preset placebo --sar 1920:1080 --fps 24 --frames 500 --psnr -o x264Kimonoq24.264 Kimono1_1920x1080_24.yuv, again with quantization parameters between 24 and 42. We could have used the --tune psnr switch to generate higher values, though this negatively affects subjective quality compared to the settings used here.

x265 --input Kimono1_1920x1080_24.yuv --width 1920 --height 1080 --rate 24 -f 240 -o q24_Kimono1.out --rect --max-merge 1 --hash 1 --wpp --gops 4 --tu-intra-depth 1 --tu-inter-depth 2 --no-tskip, with quantization parameters between 24 and 42. It's notable that we're employing GOP (Group Of Picture)-level parallelism to keep our quad-core -4770K busy. I'm also adding the --cpuid switch to control the instruction sets being used.

performance is abysmal as the moment, i think they said they are getting 4 fps on a 4770k though the guys behind x265 hope to be able to see real time 1080p30 encodes on xeon based server with 16 physical cores by next month.

the good thing is that tom's didn't skimp on the x264 settings, they could have used somewhat more aggressive settings but "placebo" should leave little wiggle room for x264 apologists to moan about.

i can't help but think that this would be a perfect time for nvidia to strike with a cuda based h265 reference encoder of their own; at 4 fps with the fastest quad core haswell, a gpu powered h265 encoder that can hit say half real time speed on a mid range video card would certainly be a big selling point for nvidia.

edit: extremetech also did a comparison and in there's x265's win was by a larger margin:

http://www.extremetech.com/computing/162027-h-265-benchmarked-does-the-next-generation...o-expectations

[jagabo]

Extremetech didn't say which h.264 encoder they used. Or what settings beyond constant quantizer values.

Oh, nevermind. I see in the reader comments the author reported that he used (x264). That wasn't there this morning when I read the story. I don't know why they started with such a poor source (full of macroblocks).

Of course, everybody expects h.265 to do better than h.264. It uses more advanced techniques.

Anyone seen MulticoreWare's OpenCL-accelerated version of x264?

[El Heggunte]

Apologies for the semi-OT, but could someone please get the .265 Windows binary from

https://mega.co.nz/#!fF51VYiD!VBnffARHirnKbDI7GrP9aAdKzEBU5Dl-7-BUjzChlwE

and upload a copy to this thread?

The stupid mega.co.nz does not work with Opera. With Seamonkey, it does attempt to install some sort of spyware on my machine.

[jagabo]

Attached...

[El Heggunte]

One million THANKS, jagabo

[deadrats]

reading through the evaluators guide makes it seem like x265 already supports a tons of advanced encoding features, i don't know what tom's means by "doesn't support b frames", the documentation makes it clear that it not only supports b-frames but weighted p, weighted b, rdo and a slew of other image enhancing features.

[El Heggunte]

Just perusing the docs for the time being... hmmmmm........

Still am not sot sure if this crude binary is worth the hassle, certainly it is so half-assed as the Microsoft VC-1 SDK sample-code , and even worse than ffmpeg2theora --- which at least accepts being "piped" with avs2yuv

IMPORTANT:

**INPUT FILE must be a raw video – 8bit I420 planar in either YUV or Y4M format.

But fear not --- if I don't manage to create some sample encodes with this sub-pre-alpha x265,

vhelp will, granted

[enim]

This thread is titled ¨ x265 vs x264¨ and everybody so far talked blah... blah... blah... too much!
Nobody actually posted what are the exact differences between x264 and x 265.

Out many differences I will cite only two differences...
1) There are two loop-filters in H265 for reducing macroblock artifacts, and to achieve higher compression.
2) H265 does not support Context Adaptive Variable Length Coding (CAVLC)
Rest differences I leave up to readers.

Even though original source code is released under BSD, Mac users are not able to compile it successfully. At this time of writing only MSVS 2010+SP1 or later supports Advanced Vector Extensions (AVX). The people who do not have Hanswell, SandyBridge, AMD Bulldozer, or later are out of HEVC game here. First upgrade your system, we will talk. And, Here I AM to talk.

[vhelp]

sorry, was busy working on dev project and finally figure out the problem there. anyway. too tired now and going to bed.

enim, the only way for anyone to "compare" 265 to 264 is by first doing their own 265 encodes, based on the said h265 (hevc) encoder. then, compare that to an h264 encoder of their choice. that's why all the talk. anyway.

i can't be bothered with the x265.exe (x265 23.07.2013 (x86).zip) app because it is not a 32 bit, ..it is 64bit. won't load on my machine, gives me error message:

"the procedure entry point interlockedcomparedexchange64 could not be located in the dynamic link library KERNEL32.dll"

i guess they (or some entities) are excluding 32bit os's now. so i'm out of this one.

[enim]

When I said...

and everybody so far talked blah... blah... blah... too much!

I am not addressing it to any forum members here, but it is in general, there is too much blah... blah... blah... on web without knowing technical details. At one point, I tried to bring it to the notice with humor that I am extending current HEVC to SDHEVC on IBMPC-AT with WordStar4 and Hanswell, SandyBridge or AMD Bulldozer PCs with MSVS2010SP1 are given out for the free to the volunteers, some missed the whole point and some considered it as a troll. Some one told me that you can only talk and understand the people are on same level. I can not help people with many barriers.

i can't be bothered with the x265.exe (x265 23.07.2013 (x86).zip) app because it is not a 32 bit, ..it is 64bit. won't load on my machine, gives me error message:

According to your feedback, the people with 32 bit OS are also out of HEVC game.
Even though I am on 64 bit OS, I need to get latest update to compile. For which I do not see any possibilities. Itś also too late here and time to go.

[El Heggunte]

sorry, was busy working on dev project and finally figure out the problem there. anyway. too tired now and going to bed.

enim, the only way for anyone to "compare" 265 to 264 is by first doing their own 265 encodes, based on the said h265 (hevc) encoder. then, compare that to an h264 encoder of their choice. that's why all the talk. anyway.

i can't be bothered with the x265.exe (x265 23.07.2013 (x86).zip) app because it is not a 32 bit, ..it is 64bit. won't load on my machine, gives me error message:

"the procedure entry point interlockedcomparedexchange64 could not be located in the dynamic link library KERNEL32.dll"

i guess they (or some entities) are excluding 32bit os's now. so i'm out of this one.

Someone please correct me if I'm wrong this time ---

--- it's not a matter of 32-bit OS versus 64-bit OS, it's because the application was written/compiled without support for Windows XP

Up-to-date versions of VisualStudio do not have this stupid artificial limitation anymore, BUT when the programmers themselves have a blind faith in the greatest and latest MISTAKES of Microsoft, there ain't much we can do (except call them bad names, of course).

[Selur]

Someone please correct me if I'm wrong this time --- ...

just making it WinXP compatible wouldn't be enough, from the "x265 Evaluation Guide 07-23-13.pdf":

SYSTEM REQUIREMENTS
Hardware: AVX capable CPU recommended
At least 8GB of RAM
Software: Win7/8 x86_64
Microsoft Visual C++ Redistributable Update 3

-> assuming this is correct, anything with a CPU from before 2011 or Windows XP and at least 8GB RAM is out.

[enim]

The H265 whole game is based on to support bit depth more than 8bits at least 10bits, upto 12bits.

This release does not even supports all aspects of Main 10 HEVC profile and Rec. 2020 color space in full. As the Main 10 profile allows for a bit depth of 8-bits to 10-bits per color with 4:2:0 chroma sub-sampling. The readers of this post who are on 64bit OS can try to encode 10bit sample with this release to verify my claim. Forget that you can ever encode HEVC Ultra HD (4K) with this release. There is a long...very long.. way to go and rocky road ahead. I am too tired and I have no more energy and time to join the team of .....
---------------------------------------------------------------------------------------------------------------------------------------------------
Today morning when I was jogging with my better (sometimes bitter) half, we passed by a backyard of holy place, where a priest was preaching to the buffalo. Out of curiosity I asked the priest who is the buffalo here? He replied ¨You¨. I was really confused and amused. I asked by bitter-half ¨Do You Think So?¨ The reply was ¨NO, I think you are stupid.¨ I asked ¨Why?¨. The reply was ¨You nerd, fallen for me, I am smarter than you.¨ Not too far, I pretended I fall down while jogging, my better-bitter half rushed to me and said "Grab my hand, I will help you." I looked in to the eyes and smirked. The reply was I got it, idiot.

[El Heggunte]

reading through the evaluators guide makes it seem like x265 already supports a tons of advanced encoding features, i don't know what tom's means by "doesn't support b frames", the documentation makes it clear that it not only supports b-frames but weighted p, weighted b, rdo and a slew of other image enhancing features.

Then please feel free to edit the Wikipedia article about x265

x265 is currently limited to x86 CPUs, a bit depth of 8-bits per color, and does not support B-frames.[1][2][3] x265 does not currently support some of the optimizations that were made with x264 such as lookahead, multi-pass encoding, and rate control.[1][2][3] MulticoreWare has said that based on peak signal-to-noise ratio (PSNR) the decrease in bit rate when going from x264 to x265 will be between 25% and 35% and that coding efficiency for x265 will increase as improvements are made to the encoder.[2] In a video comparison done in July 2013 by ExtremeTech with an encoding preset of veryslow it took 129 seconds to encode a video clip with x264 and 247 seconds to encode it with x265.[1]

{
http://en.wikipedia.org/wiki/X265#Technical_details
}

[El Heggunte]

[ place commercial here ]

[pandy]

Issue is not in encoding performance as encoding is performed only once - issue is how decoding is performed compared to existing H.264 decoders.

Is there any decent H.265 decoder that will run on 1080p30 with for example Core2Duo?

[El Heggunte]

Time for an overdue reply... Better late than jamais, I hope
enim, apologies for the looooong delay, but your name was on my Ignore List

...........
Even though original source code is released under BSD, Mac users are not able to compile it successfully.

At this time of writing only MSVS 2010+SP1 or later supports Advanced Vector Extensions (AVX).

The people who do not have Hanswell, SandyBridge, AMD Bulldozer, or later are out of HEVC game here.

BOOLSHEET --- and here is the proof:

Yasm 1.2.0 Release Notes

Features

Changes from 1.1.0 to 1.2.0:

Add AVX2 instructions (rev 11 of Intel AVX reference) (#227).
Allow 64-bit LFS/LGS/LSS.
Improve LAR instruction support (#224).
Default win64 .xdata to nobase, add support for “..imagebase” (#135).
Fix “TIMES” relocation handling.
Fix no-suffix push and pop in GAS mode (#212).
See the bug tracker for a full list of bug fixes.

Besides, from http://en.wikipedia.org/wiki/Advanced_Vector_Extensions#Compiler_and_assembler_support ,

Compiler and assembler support

Recent releases of GCC starting with version 4.6 (although there was a 4.3 branch with certain support) and the Intel Compiler Suite starting with version 11.1 support AVX.

And finally,

Operating system support

AVX adds new register-state through the 256-bit wide YMM register file, so explicit operating system support is required to properly save & restore AVX's new registers between context switches. The following operating system versions will support AVX:

Apple OS X: Support for AVX added in 10.6.8 (Snow Leopard) update released on June 23, 2011.
Linux: supported since kernel version 2.6.30, released on June 9, 2009.
Windows: supported in Windows 7 SP1 and Windows Server 2008 R2 SP1; hotfix 2517374 available for non-SP1 version of Windows Server 2008 R2.; Windows 8
Windows Server 2008 R2 SP1 with Hyper-V requires a hotfix to support AMD AVX (Opteron 6200 and 4200 series) processors, kb 2568088
FreeBSD in a patch submitted on 21 January 2012, which was included in the 9.1 stable release
DragonFly BSD added support in early 2013.
Solaris 10 Update 10 and Solaris 11

{
http://en.wikipedia.org/wiki/Advanced_Vector_Extensions#Operating_system_support
}

[pandy]

Time for an overdue reply... Better late than jamais, I hope
enim, apologies for the looooong delay, but your name was on my Ignore List

...........
Even though original source code is released under BSD, Mac users are not able to compile it successfully.

At this time of writing only MSVS 2010+SP1 or later supports Advanced Vector Extensions (AVX).

The people who do not have Hanswell, SandyBridge, AMD Bulldozer, or later are out of HEVC game here.

BOOLSHEET --- and here is the proof:

Is there any AVX code inside x265? If not there whole discussion about compilers is irrelevant.
Without inline-manual asm code that explicitly use AVX, code after compilation should be capable to run on AVX and non-AVX capable CPU's.

[El Heggunte]

................
Is there any AVX code inside x265?

Yes, lots of AVX code which take ages to compile

Without inline-manual asm code that explicitly use AVX,

code after compilation should be capable to run on AVX and non-AVX capable CPU's.

Wrong. Just like x264, x265 will use the CPU-optimizations available on the host machine. If this latter supports AVX, then AVX will be used as necessary; otherwise, SSE2, SSE3, SSSE3, SSE4.1, or SSE4.2 will be used instead.

[pandy]

................
Is there any AVX code inside x265?

Yes, lots of AVX code which take ages to compile

Without inline-manual asm code that explicitly use AVX,

code after compilation should be capable to run on AVX and non-AVX capable CPU's.

Wrong. Just like x264, x265 will use the CPU-optimizations available on the host machine. If this latter supports AVX, then AVX will be used as necessary; otherwise, SSE2, SSE3, SSSE3, SSE4.1, or SSE4.2 will be used instead.

This is contradictory - OR AVX is used explicitely or NOT? And optimization is up to the compiler - from my point of view there is huge and cardinal difference for plain C(+,++,# etc) code is optimized by compiler and C(+,++,# etc) with INLINE ASM and/or other PRAGMA's compiled by compiler.

[El Heggunte]

.......This is contradictory

Why would it be "contradictory"

[pandy]

.......This is contradictory

Why would it be "contradictory"

Because it is different to leave compiler decision how to perform procedure or function with particular command extension (MMX,SSE,AVX) from explicitly create procedure or function in ASM and use it later automatically later based on capabilities (supported extensions) reported by CPU like this

;-----------------------------------------------------------------------------
; void mbtree_propagate_cost( int *dst, uint16_t *propagate_in, uint16_t *intra_costs,
;                             uint16_t *inter_costs, uint16_t *inv_qscales, float *fps_factor, int len )
;-----------------------------------------------------------------------------
%macro MBTREE 0
cglobal mbtree_propagate_cost, 7,7,7
    add        r6d, r6d
    lea         r0, [r0+r6*2]
    add         r1, r6
    add         r2, r6
    add         r3, r6
    add         r4, r6
    neg         r6
    pxor      xmm4, xmm4
    movss     xmm6, [r5]
    shufps    xmm6, xmm6, 0
    mulps     xmm6, [pf_inv256]
    movdqa    xmm5, [pw_3fff]
.loop:
    movq      xmm2, [r2+r6] ; intra
    movq      xmm0, [r4+r6] ; invq
    movq      xmm3, [r3+r6] ; inter
    movq      xmm1, [r1+r6] ; prop
    punpcklwd xmm2, xmm4
    punpcklwd xmm0, xmm4
    pmaddwd   xmm0, xmm2
    pand      xmm3, xmm5
    punpcklwd xmm1, xmm4
    punpcklwd xmm3, xmm4
%if cpuflag(fma4)
    cvtdq2ps  xmm0, xmm0
    cvtdq2ps  xmm1, xmm1
    fmaddps   xmm0, xmm0, xmm6, xmm1
    cvtdq2ps  xmm1, xmm2
    psubd     xmm2, xmm3
    cvtdq2ps  xmm2, xmm2
    rcpps     xmm3, xmm1
    mulps     xmm1, xmm3
    mulps     xmm0, xmm2
    addps     xmm2, xmm3, xmm3
    fnmaddps  xmm3, xmm1, xmm3, xmm2
    mulps     xmm0, xmm3
%else
    cvtdq2ps  xmm0, xmm0
    mulps     xmm0, xmm6    ; intra*invq*fps_factor>>8
    cvtdq2ps  xmm1, xmm1    ; prop
    addps     xmm0, xmm1    ; prop + (intra*invq*fps_factor>>8)
    cvtdq2ps  xmm1, xmm2    ; intra
    psubd     xmm2, xmm3    ; intra - inter
    cvtdq2ps  xmm2, xmm2    ; intra - inter
    rcpps     xmm3, xmm1    ; 1 / intra 1st approximation
    mulps     xmm1, xmm3    ; intra * (1/intra 1st approx)
    mulps     xmm1, xmm3    ; intra * (1/intra 1st approx)^2
    mulps     xmm0, xmm2    ; (prop + (intra*invq*fps_factor>>8)) * (intra - inter)
    addps     xmm3, xmm3    ; 2 * (1/intra 1st approx)
    subps     xmm3, xmm1    ; 2nd approximation for 1/intra
    mulps     xmm0, xmm3    ; / intra
%endif
    cvtps2dq  xmm0, xmm0
    movdqa [r0+r6*2], xmm0
    add         r6, 8
    jl .loop
    RET
%endmacro

https://bitbucket.org/multicoreware/x265/src/de3e6c30815ccc11ed6a33835f7d0c0d13e07f8c/...asm?at=default


You have detection of the CPU capabilities and explicitly, manually tuned code that use best possible combination available - later for compiler decision is limited to select particular implementation, not invent own that can be (and probably it will be) suboptimal - this is main difference between plain and PRAGMA coding - there is no justification for much longer compilation with such thing as AVX (probably just compiler is not optimized yet and do some exhaustive search - probably can be improved later (or not) - compiler is smart only as compiler creator can be and compiler creator can be less smart(experienced) from guy that doing inline asm).

But im not a software guy and for all differences you should ask a good coder.

Quote for today - "program right down on the bare metal!" http://www.cs.utah.edu/~elb/folklore/mel.html

http://en.wikipedia.org/wiki/Intrinsic_function

[El Heggunte]

Thanks for the clarification The problem was, we used different "wordings" to express the same idea (and your wording is clearer than mine, granted).

FWIW: I only download the source-code from the MCW site, run Msys, then cmake, and make. From the little that I understand of the subject, and I may be understanding it all wrong, x265 DOES contain assembly-optimizations for SSE2, blah-blah-blah, and AVX. None of my three computers support AVX, and still they all run x265.exe without a complaint.

[pandy]

Thanks for the clarification The problem was, we used different "wordings" to express the same idea (and your wording is better than mine, I admit).

Anyway, it still seems to me that you think/believe that,
if a program supports AVX instructions, then it cannot run on a machine that doesn't have AVX support

Without inline-manual asm code that explicitly use AVX, [ then ]

code after compilation should be capable to run on AVX and non-AVX capable CPU's.

FWIW: I only download the source-code from the MCW site, run Msys, then cmake, and make. From the little that I understand of the subject, x265 DOES contain assembly-optimizations for SSE2, blah-blah-blah, and AVX. None of my three computers support AVX, and still they all run x265.exe without a complaint.

OK i see - sorry for not being precise - my point was - if code will use only AVX instructions and will provide no substitute for this coded AVX function but without AVX then probably such code will be not useable on machines without AVX - however if code provide various functions that use various ecxtensions and if AVX coded functions can be substitued with for example SSE then such code will run perfectly on all type machines with AVX and SSE, only SSE and only AVX.
However not sure if x265 will run for example on Pentium 1 or 386 without FPU - as there can be no substitutes for particular functions.
I hope that now my point is clear - previously i didn't check source for x265 so i was not sure is there any AVX code inside - now it is clear that AVX is supported but not mandatory (there are substitutes for AVX - SSE at least) - so AVX code will be probably faster but on AVX machines it will be still usable.

[rtpriya]

For greater performance with x265, pls turn on the --no-rdo parameter and try it out. there is a slight increase in bit rates but performance gains are good

[jamespoo]

is there anything out there yet to convert videos to x265

[Selur]

doesn't make sense to convert anything to H.265 atm. since all implementations are still to new to be sure that they are really standard conform.

[El Heggunte]

The title of this thread is x265 vs x264, so me thinks this attachment is 100% On-Topic,

freenode-x265-log.txt, downloaded from akuvian.org,
which belongs to pengvado / akupenguin / Loren Merritt / The X264 Man

[deadrats]

The title of this thread is x265 vs x264, so me thinks this attachment is 100% On-Topic,

freenode-x265-log.txt, downloaded from akuvian.org,
which belongs to pengvado / akupenguin / Loren Merritt / The X264 Man

i fail to see how this adds to the topic at hand, the penguin barely says 3 words and they add nothing to the discussion.

did you link to the wrong irc?

[pandy]

i fail to see how this adds to the topic at hand, the penguin barely says 3 words and they add nothing to the discussion.
did you link to the wrong irc?

I think that point is clear - there is no x265 vs x264 - x265 is in stage not even pre-alfa thus comparing it to x264 is simply unfair (for x265). We need more time, x265 need lot of work then perhaps thread like such can be reborn. For today x265 can't be compared to mature x264.