x265 HEVC Encoder

[x265]

Announced in the mailing list, quoted in the doom9 forum, yet forgotten here:

Thanks. Sorry for not sharing this announcement here on Friday last week. I was out of the office.

--pmode and --pme are designed to enable much higher levels of parallelism, allowing for better utilization of many-core machines (dual socket servers, for example). We are seeing anywhere from 2x to 3x higher performance on a dual Xeon server (AWS instance) when used with --preset veryslow.

Even on a smaller machine you may find that --pmode in particular can result in higher performance with slower, high quality settings. I observed 80% faster performance on a quad-core notebook using --pmode with --preset veryslow.

If you are using the default settings or faster settings, I wouldn't bother with --pme or --pmode.

Tom

[LigH.de]

I re-made my speed chart (lower height is faster). Lacking of AVX2 capable CPUs, this does not show the whole story, though...

"v1.4+70p" is a hint to having added "--pme --pmode"; all the other results were simply a "best of 3 runs" with only the preset and some logging parameters.

[Selur]

hmm,.. is it that wise to use the presets (and not a non-minized command line) as a basis for a speed comparison?
I mean the presets did change quite a bit from 1.0 to the latest release,..

[LigH.de]

It was not my intention to benchmark the code, but to visualize the efforts of all kinds of tunings, including the changing of presets. Yes, some presets will have changed from one version to another, and you will probably be able to see that the relation between presets changed since then.

[x265]

I re-made my speed chart (lower height is faster). Lacking of AVX2 capable CPUs, this does not show the whole story, though...

"v1.4+70p" is a hint to having added "--pme --pmode"; all the other results were simply a "best of 3 runs" with only the preset and some logging parameters.

Interesting. You'll notice that adding --pme and --pmode can have a very positive effect at higher quality presets, but a negative effect when you're trying to use faster presets. In fact, for most people under most circumstances, --pme will just slow things down at any preset. --pmode will be beneficial at slower presets, but it will slow things down for faster presets. You might want to try another test run with --pmode only, to see where this will bring you benefits.

We are still working to improve how we parallelize and schedule threads, and so we haven't added these functions to our performance presets yet. Both functions are safe to use (you'll get identical or nearly identical output to what you would get without them), but only --pmode is likely to help things go faster, and generally the performance benefits from --pmode will diminish with fewer processor cores/threads, or with high pixel resolutions (UHD). So, x265 v1.4, if you're not encoding UHD/4K, and you have at least a 4 core processor, and you're using higher quality (slow, slower, veryslow) presets, you'll probably see a benefit from adding --pmode to your command line today.

[LigH.de]

Brief test with v1.4+95:

--preset slow
encoded 300 frames in 74.78s (4.01 fps), 178.64 kb/s, SSIM Mean Y: 0.9311898 (11.623 dB)

--preset slow --pmode
encoded 300 frames in 51.85s (5.79 fps), 177.96 kb/s, SSIM Mean Y: 0.9312976 (11.630 dB)

--preset slow --pmode --pme
encoded 300 frames in 50.90s (5.89 fps), 177.96 kb/s, SSIM Mean Y: 0.9312976 (11.630 dB)

My CPU utilization without --pmode is only about 70%, with --pmode about 90%, with additional --pme about 95%.
__

--preset medium
encoded 300 frames in 17.86s (16.80 fps), 190.18 kb/s, SSIM Mean Y: 0.9296106 (11.525 dB)

--preset medium --pmode
encoded 300 frames in 17.39s (17.25 fps), 190.95 kb/s, SSIM Mean Y: 0.9295186 (11.519 dB)

--preset medium --pmode --pme
encoded 300 frames in 14.85s (20.20 fps), 190.95 kb/s, SSIM Mean Y: 0.9295186 (11.519 dB)

Not worse, not at all... And also great with preset fast. Maybe it's a bit lucky to have only CIF resolution. I'll try a bigger video dimension too.

[El Heggunte]

{{
d e l e t e d
}}

[athukoralakasun]

Hi,

I want to use the x265 encoder to encode a raw video stream received through SDI. How can i configure the encoder to input a continuous stream rather than a file??


Thank you

[LigH.de]

I doubt that x265 would be fast enough to encode an incoming stream with SD dimensions in realtime.

[Selur]

@athukoralakasun: x265 only supports input video file or std::in so if you can redirect your SDI input to sdt::in you can feed that to x265 (input needs to be set to '-' in x265 to accept input via std::in).

[athukoralakasun]

First of all thank you for replying me.

@Selur Is that possible to do? Can i directly use the x265 exe and set it's input as a output of a another exe which will output yuv frames?

And if anyone else knows about this please help.

Thank you.

[Selur]

Can i directly use the x265 exe and set it's input as a output of a another exe which will output yuv frames?

If your other exe can output those frames to stdOut it should be possible.
I normally use this functionality to decode stuff with ffmpeg/mencoder/mplayer and feed their output to x265.

[athukoralakasun]

Thanks Selur

@Selur Do you have a such a example code where you feed ffmpeg out put to x265 via Stdin?? If you have, then is it possible to share that with me?


Thank you.

[Selur]

Here's an example which uses ffmpeg to decode test.avi and send the video to x265, which then encodes the video to test.265.

ffmpeg -y -loglevel fatal -threads 8 -i "F:\TestClips&Co\test.avi" -map 0:0 -an -sn -vsync 0 -r 25000/1000 -pix_fmt yuv420p -f rawvideo - | x265 --pmode --pme --input - --input-res 640x352 --fps 25 --no-high-tier --no-open-gop --output "H:\Temp\test.265"

Note that the x264 contains: '--input - --input-res 640x352 --fps 25' which specifies that:
a. input comes via stdIn
b. the input resolution is 640x352
c. the output fps for the video should be 25fps
Also note the pipe symbol ' | ' which is used to combine the two calls and which connects the stdOut output of ffmpeg to the stdIn Output of x265.


Cu Selur

[athukoralakasun]

@selur thanks for your support.. ill test this code. Thank you very much.

[LigH.de]

I did another brief speed comparison with x265 v1.4+380 with different combinations of --pmode and --pme. My conclusion on a Phenom-II X4, testing a small video (foreman_cif):

• You can safely use --pme, it will usually speed up.
• It does not make sense to use --pmode in presets faster than "faster", that may slow down.

There will probably be different conclusions for other CPUs and videos with larger dimensions.

[Selur]

I normally enable both on my i7 4770k.

[LigH.de]

Well, OK, but ... did you test if it is worth it, regarding your test material and parameters?

[Selur]

Yup, it was always faster for me.

[LigH.de]

I found that '--pme' only can be even faster than both '--pmode --pme', but it depends a lot on the preset. I'm testing again with another CPU too.

[LigH.de]

Coming x265 versions will support zones for bitrate distribution tuning:

--zones startframe,endframe,{q=quant|b=bitrate_factor}[/…]
__

HEVC / x265 1.4+417-a0c084eff60f

[srivani]

Hi,

How can we enable NAL_UNIT_ACCESS_DELIMETER,NAL_UNIT_FILLER_DATA in hevc encoder?

[Selur]

x265 offers:

Bitstream options:
   --[no-]info                   Emit SEI identifying encoder and parameters. Default enabled
   --[no-]aud                    Emit access unit delimiters at the start of each access unit. Default disabled
   --[no-]hrd                    Enable HRD parameters signaling. Default disabled
   --[no-]repeat-headers         Emit SPS and PPS headers at each keyframe. Default disabled
   --hash <integer>              Decoded Picture Hash SEI 0: disabled, 1: MD5, 2: CRC, 3: Checksum. Default 0

NAL_UNIT_ACCESS_DELIMETER -> '--aud'

[Selur]

seeing:

--[no-]psy-rd <0..2.0>        Strength of psycho-visual rate distortion optimization, 0 to disable.
--[no-]psy-rdoq <0..50.0>     Strength of psycho-visual optimization in quantization, 0 to disable.

I wanted to make sure:
'--psy-rd 0' is the same as '--no-psy-rd'
'--psy-rdoq 0' is the same as '--no-psy-rdoq'
right? (so this is only syntactic sugar?)

[LigH.de]

I would agree to this opinion, Selur. "Setting to value 0" was the primary way to disable it; inserting 'no-' was added later for convenience and consequent syntax.

[x265]

We're pleased to announce that x265 has reached another milestone! The v1.5 release of x265 has major improvements in Main10 compression efficiency and performance over the 1.4 release, general improvements in Main performance. Psycho-visual optimizations are now enabled by default in the presets which can support it (medium, slow, slower, veryslow and placebo).

Feature additions:

* analysis re-use features have been completed
* rate control zones have been introduced
* --tune grain introduced
* deblocking tC and Beta offsets are now configurable
* denoise is seperately configurable for inter and intra CUs
* frame based CSV logging has been improved
* New support for VTune task profiles


Presets and defaults:

ultrafast no longer disables the deblocking loop filter
psy-rd defaults to 0.3 (was 0, disabled)
psy-rdoq defaults to 1.0 (was 0, disabled)
aq-mode defaults to 1 (was 2, auto-variance)
4:2:2 and 4:4:4 encodes no longer generate compliance warnings


API changes:

param.rc.rateTolerance has been removed and replaced with a simpler param.rc.bStrictCbr flag.

--log-level debug is now --log-level 4 instead of --log-level 3. A new 'frame' log level was inserted at level 3 in order to support frame level CSV logging without also enabling frame level console logging.
Using the string name 'debug' is unambiguous as its behavior has not changed.

The online documentation has all the details:
http://x265.readthedocs.org/en/1.5/

[newpball]

Okay, so maybe I should start 'doing' H.265.

So I checked the homepage. Looks good!
Source code available! OK!

But eh, silly question I am sure, how do you download and use it?

[vhelp]

i test x265 builds* under windows xp home. but most seem testing with the 64bit builds under win7/8 os's. also, some compiles may include 8bit or 16bit color feature or both in the zip/7z file depending on where you download from)

x265 lives in the tools/download page, just scroll down to this section for the first three links, pick which you want to download from regularly:

More information and other downloads:
More x265 Encoder mirror downloads:
http://chromashift.org/x265_builds/
http://builds.x265.eu/
http://x265.ru/en/

x265.exe can be compiled with different compilers but some give problems and some of the compiling rules change from time to time, so it can be a messy and laborous endeavor. use the links above or below to skip the compiling headaches.

x265.exe 32/64 bit builds are compiled by LigH (8bit/16bit) and el huggente (8bit) on this forum. visit this link for regular weekly or bi-weekly builds, here:

*[HEVC] x265.EXE: mingw builds -- hint, just follow the last page on this link for the latest builds.

have fun.

[LigH.de]

Several GUIs already support x265 as command line encoder (separate executable or linked library in ffmpeg) to some degree (despite its still often changing set of parameters and default values): MeGUI / StaxRip / Hybrid ...

[LigH.de]

Current builds support NUMA thread pools.

As far as I learned, thread pooling is about controlling the distribution of threads between physically multiple CPUs which have their own memory (at least cache and registers), therefore sharing information among them is not as easy as among cores inside one multi-core CPU.

Not very common in consumer PCs. Possibly more interesting on dedicated server boards. And NUMA seems to lead further into the direction of super computers with processor board slots, I guess...