x265 HEVC Encoder

[foxyshadis]

I could see a use for Quicksync as a superspeed first pass, which can be analyzed to derive a stats file, but I can't think of any other way you could effectively use it as part of x265. The actual encoding is most of what makes it x265.

Originally Posted by foxyshadis

I could see a use for Quicksync as a superspeed first pass, which can be analyzed to derive a stats file, but I can't think of any other way you could effectively use it as part of x265. The actual encoding is most of what makes it x265.

We think about how to accelerate x265 constantly. But as LiGH and Foxyshadis noted, we don't want x265 to simply call someone else's encoder, or part of another encoder. Where there are fixed function capabilities in new hardware HEVC encode pipelines that we can leverage, we will.

We don't feel like we compete with proprietary encoder APIs. While we don't disagree that it makes sense for semiconductor companies to offer their own proprietary encoder APIs, customers worldwide vastly prefer the quality, features, flexibility and cross platform capability of open source encoder libraries like x264 and x265. It makes sense for semiconductor companies to give us access to the full power of their new architectures. Unfortunately, these hardware pipelines aren't designed as a set of addressable fixed function units that we can quickly and efficiently access. But we're investigating all of the possibilities.

[LigH]

Another "merge with stable", including several bug fixes and some even faster AVX2 routines.

x265 1.7+470-86e9bd7dd192 (GCC 4.9.2)
x265 1.7+470-86e9bd7dd192 (GCC 5.2.0)

[divxmaster]

Interesting results here from 1.7+470 (vs 1.7.382), one 1000 frame test was 9.5% faster and 3% smaller file (lots of panning)
another 1000 frame sample was 5.6% SLOWER than .382, and the same size (.16% smaller) (no panning).

4770K@3.9, 480p sample. Tests run multiple times.

Edit: On a 10000 frame test, 470 was 3.5% slower and a 1% BIGGER file. Will test entire encode now.

CHeers,
Divxmaster

[jhughy2010]

I've been experimenting with Handbrake and x265 re-encoding. I find that the quality (for my purposes) is as good if not better (for same file size if not smaller) as x264. Obviously it takes much longer to re-encode, however, I have noticed the resulting file size is much more appealing than an x264 re-encode.

What exactly is the "x265 HEVC Upgrade"? I noticed it costs $29.95, is this an application like Handbrake or is it an extension of some other piece of software?

Is Handbrake a good tool to use to re-encode to x265? I am taking full MKV files to MP4 and using default x265 settings in Handbrake ATM.

[LigH]

Originally Posted by jhughy2010

What exactly is the "x265 HEVC Upgrade"? I noticed it costs $29.95, is this an application like Handbrake or is it an extension of some other piece of software?

This is mainly UHDcode, a quite fast and comprehensive HEVC decoder as DirectShow filter, along with a basic recoder for AVC-in-MP4 source files. Not really necessary for most cases, LAV Filters have a good decoder implementation as well, and there are free converters in all different flavours.

Originally Posted by jhughy2010

I've been experimenting with Handbrake and x265 re-encoding. I find that the quality (for my purposes) is as good if not better (for same file size if not smaller) as x264. Obviously it takes much longer to re-encode, however, I have noticed the resulting file size is much more appealing than an x264 re-encode.

What exactly is the "x265 HEVC Upgrade"? I noticed it costs $29.95, is this an application like Handbrake or is it an extension of some other piece of software?

Is Handbrake a good tool to use to re-encode to x265? I am taking full MKV files to MP4 and using default x265 settings in Handbrake ATM.

The x265 HEVC Upgrade includes 2 things; the x265 Encoder (Windows application), and UHDcode (Windows DirectShow filter).

The x265 Encoder is a simple Windows 64 bit application designed to make it easy for anyone to use x265. It accepts MP4 files as input, and it will transcode the H.264 video to H.265, passing the audio through to the target MP4 file. There is a basic mode which makes it really easy for non-technical people to use. The advanced mode includes full access to all x265 settings.

The UHDcode DirectShow filter allows Windows Media Player to play video files containing HEVC.

The x265 HEVC Upgrade is available for $14.98 (50% off the MSRP) for a limited time. We hope to be able to make trial versions available, but we're still waiting to hear if the HEVC Advance patent portfolio will allow for trial software without charging an exorbitant royalty (MPEG-LA allows for trial software with no royalty).

[divxmaster]

Originally Posted by divxmaster

Interesting results here from 1.7+470 (vs 1.7.382), one 1000 frame test was 9.5% faster and 3% smaller file (lots of panning)
another 1000 frame sample was 5.6% SLOWER than .382, and the same size (.16% smaller) (no panning).

4770K@3.9, 480p sample. Tests run multiple times.

Edit: On a 10000 frame test, 470 was 3.5% slower and a 1% BIGGER file. Will test entire encode now.

CHeers,
Divxmaster

Trend continued, an entire encode was 13.49fps for 382 and 13.35fps for 470. The 470 file was a little bigger. Seems somewhat odd, but just an observation.

Cheers,
Divxmaster

[downloadhub]

any buddy help me which method to encode x265 HEVC small size mobile rip i am try many of encoders but i am not manage it size if any buddy know please help me which encoder i am use for good quality with small size minimum 200MB

[jhughy2010]

Originally Posted by x265_Project

The x265 HEVC Upgrade includes 2 things; the x265 Encoder (Windows application), and UHDcode (Windows DirectShow filter).

The x265 Encoder is a simple Windows 64 bit application designed to make it easy for anyone to use x265. It accepts MP4 files as input, and it will transcode the H.264 video to H.265, passing the audio through to the target MP4 file. There is a basic mode which makes it really easy for non-technical people to use. The advanced mode includes full access to all x265 settings.

The UHDcode DirectShow filter allows Windows Media Player to play video files containing HEVC.

The x265 HEVC Upgrade is available for $14.98 (50% off the MSRP) for a limited time. We hope to be able to make trial versions available, but we're still waiting to hear if the HEVC Advance patent portfolio will allow for trial software without charging an exorbitant royalty (MPEG-LA allows for trial software with no royalty).

Ok thanks. You mentioned transcoding. So the windows application does on the fly transcoding but does it re-encode like Handbrake? Does it accept MKV files?

How does the application compare to Handbrake? If it is as functional and/or better I would be will to pay (heck I'd pay for Handbrake if it wasn't free).

[LigH]

@ downloadhub:

1. "anybody"

2. There are no miracles. And there are no crystal balls. Good quality requires a minimum bitrate per image area. If you need a small size, reduce the resolution. Use a 2-pass encoding method to bring your copy down to a desired target size. And stay with H.264 (AVC) for mobile devices, because H.265 (HEVC) requires much more computing power and will drain your battery faster. For better help, post more details; but not in this thread, this is about the development of x265, not a beginners' guide how to use any converter.
__

@ jhughy2010:

I did not use it yet, but according to the description: MP4 to MP4 only. And probably no filters, just straight video conversion with audio pass-through, certainly not as flexible as Handbrake or StaxRip or MeGUI or Hybrid.

[Jamaika]

Originally Posted by downloadhub

any buddy help me which method to encode x265 HEVC small size mobile rip i am try many of encoders but i am not manage it size if any buddy know please help me which encoder i am use for good quality with small size minimum 200MB

I think you can use Cyberlink Powerdiector 13. Editor AVC decoder is poor, but when you use Cineform codec you can get an interesting result HEVC output.
HEVC FullHD 4500kbps i420 8bit 30fps progressive High Quality

[LigH]

NUMA, NUMA, yeah: x265 1.7+474-e1adac00dce8 (GCC 4.9.2 / 5.2.0) (multilib EXE's only) with a changed NUMA pool strategy

[x265.cc]

Originally Posted by LigH

NUMA, NUMA, yeah: x265 1.7+474-e1adac00dce8 (GCC 4.9.2 / 5.2.0) (multilib EXE's only) with a changed NUMA pool strategy

revision is bugged and just utilize one cpu core (on my hardware). Better stick with rev x265_1.7+470 (until tomorrow)

[benwaggoner]

Originally Posted by x265.cc

revision is bugged and just utilize one cpu core (on my hardware). Better stick with rev x265_1.7+470 (until tomorrow)

I get the same thing on my 16-core dual Xeon. Manually trying to force multithreading via --pools didn't work either.



Semi-relatedly, what's the current thinking on gcc 4.9 v. 5.2 builds?

[Ma]

Originally Posted by benwaggoner

Semi-relatedly, what's the current thinking on gcc 4.9 v. 5.2 builds?

I think that code generated by GCC 5.2 is faster but bigger. Size of code does matter because L1 cache is very small (32 KB) and there are huge speed differences between L1/L2/L3 cache/memory access.

For GCC 4.9 there is a problem that MS gives VS 2015 for free and code generated by VS 2015 is smaller than code generated by GCC 4.9.

GCC 4.9 build will be probably slower than the fastest build from GCC 5.2 & VS 2015.

[burfadel]

The question then of course, is how the VS 2015 speed compares to the GCC 5.2 speed.

[Ma]

Originally Posted by burfadel

The question then of course, is how the VS 2015 speed compares to the GCC 5.2 speed.

At AVX level (i5 3450S) there was: VS 2015 builds was faster in 8 and 10-bit encoding, much slower in 12-bit encoding.

After x265 team turn off AVX assembly code that was 10% faster than SSE4, VS 2015 builds are at the same speed in 8 & 10-bit encoding, much slower in 12-bit encoding.

I try to make tables for tomorrow @ AVX level and SSSE3 level.

[benwaggoner]

Originally Posted by benwaggoner

I get the same thing on my 16-core dual Xeon. Manually trying to force multithreading via --pools didn't work either.

Looks like a fix should be coming today:

https://bitbucket.org/multicoreware/...eral-comments:

Pradeep Ramachandran author
Thanks. I see the error in my logic. I'll push in a fix tomorrow.

[Ma]

Speed test VS 2015 build vs. GCC 5.2.

Platform: Win7 64-bit, i5 3450S
Options: --crf 17.5 --rdoq-level 1 --psy-rd 0.4 --deblock -1 --keyint 288 --colormatrix bt709
Builds: 1.7+473 from site www.msystem.waw.pl/x265

Encoding time in seconds (first table 8-bit, second 10-bit, third 12-bit):

		fast	medium	slow	slower	verysl	placebo
vs2015-AVX	69,69	108,21	274,78	368,5	393,92	400,4
msvcr120-AVX	70,3	108,24	274,73	371,23	396,06	403,91
gcc52-AVX	70,14	108,41	274,7	374,19	396,14	405,53
msvcr120-SSSE3	70,71	109,39	298,93	374,42	398,36	407,44
vs2015-SSE2	70,66	110,11	277,19	375,48	399,6	404,15
						
vs2015-AVX	87,89	132,82	413.04	515.14	552.64	574.87
msvcr120-AVX	88,83	133,81	413.77	518.28	555.17	580.92
gcc52-AVX	89,33	134,45	415.41	519.76	556.77	582.68
msvcr120-SSSE3	89,34	135,18	416.71	521.65	557.83	581.81
vs2015-SSE2	88,89	134,67	413.64	517.96	555.26	576.48						

msvcr120-AVX	109,19	168,07	455,76	574,88		
gcc52-AVX	109,69	168,56	457,26	576,78		
msvcr120-SSSE3	111,96	172,47	461,8	585,26		
vs2015-AVX	166,03	250,06	714,95			
vs2015-SSE2	167,82	253,73	719,64

Unfortunately I took to many binaries to compare and too long samples and didn't finish. There was only 1 repeat and my Win7 in the night like to do something which affect results. Anyway vs2015-AVX build is the fastest @ 8-bit & 10-bit.

On CPU with only SSSE3 result was (encoding time in seconds, first table 8-bit, second 10-bit):

msvcr120-SSSE3	487,42	716,34	991,49	1068,54	1055,51	985,84
gcc52-SSSE3	490,43	729,44	991,58	1055,89	1057,93	983,03
gcc52-SSE2	498,47	768,78	1003,16	1053,75	1194,48	1010,54
vs2015-SSE2	608,29	873,99	1181,09	1267,78	1255,51	1153,93
						
msvcr120-SSSE3	618,49	899,64				
gcc52-SSSE3	620,4	895,69				
gcc52-SSE2	647	915,41				
vs2015-SSE2	707,55	1004,47

On weak CPU vs2015 build is slow.