x265 HEVC Encoder

[Skankee]

Yes, Encode.
108Mbps is higher than a typical Blu Ray with 30Mbps.
If you have anything higher than 108Mbps it will be of help.


You could try the movie "sita sings the blues" (1080p, 31,1 GB y4m file)

With x264.2345.x86.exe and "--preset placebo --tune animation --crf 18 --keyint infinite --open-gop --threads 2"

there was a 128 Mbps peak between 1min 50s - 2min 05s. Maybe this is what you need to do you HEVC-decoding test.

The closest lossless source to "reality" I have is "Tears of Steel"...And due to the efficiency of HEVC, it is not easy to pass the target of 30 Mbps (without padding)...

Just for fun i encoded Tears of Steel with extreme settings with x264 at crf 18 and got an average bitrate of 6890 kbps, so 30 Mbps seems to be a little bit too much for me when you (James Freeman) expect "big" differences between h264 and HEVC.

C:\x264.2358.10bit.x86.exe --video-filter resize:width=1920,height=804,method=bicubic --profile high10 --preset placebo --crf 18 --tune film --threads 1 --keyint infinite --open-gop --colormatrix bt709 --output ...

[zerowalker]

Where can i get builds?
I am unable to build them myself, don´t understand, i used Cygwin64, and it says something about Cmake 32bit, seems to be different from normal git stuff.

So hoping someone is building and have it to share, or perhaps know a easy way to build it?

[x265_Project]

Where can i get builds?
I am unable to build them myself, don´t understand, i used Cygwin64, and it says something about Cmake 32bit, seems to be different from normal git stuff.

So hoping someone is building and have it to share, or perhaps know a easy way to build it?

It's not too difficult to get your system configured to clone the source code repository, or later just pull updated source code with mercurial, make a solution with cmake, then build the solution with your favorite compiler. Instructions are here... https://bitbucket.org/multicoreware/x265/wiki/Home.

To clone the repo, run the following command after installing mercurial (edit the destination directory if you want something other than c:\x265)...
hg clone https://bitbucket.org/multicoreware/x265 c:\x265
After you've cloned the repo, you can just write a script that allows you to pull updates, make and build.

For example, on my Windows 64 system I have a batch file that automates the process...
c:
cd c:\x265
hg pull -u https://bitbucket.org/multicoreware/x265
@echo on
ECHO Generate the solution, then continue
cmake-gui C:\x265\source --build C:/x265/build/vc11-x86_64
pause

ECHO Building the solution
C:\x265\build\vc11-x86_64\x265.sln /t:rebuild /p:configuration=release
pause
Of course, you may need to edit this to point it to your local copy of the x265 source code, or to use a different compiler.

The script above utilizes the cmake and Visual Studio GUIs (which will allow you to set CMAKE options, or build a debug build, for example). Here is a similar script that avoids the CMAKE and Visual Studio GUIs (using the built-in Windows compiler... you may need to edit this to find your compiler)
c:
cd c:\x265
hg pull -u https://bitbucket.org/multicoreware/x265
pause
@echo on
ECHO Generate the solution
cmake -G "Visual Studio 11 Win64" C:\x265\source --build C:/x265/build/vc11-x86_64

ECHO Building the solution
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\msbuild.exe C:\x265\build\vc11-x86_64\x265.sln /m /t:build /p:configuration=release
xcopy C:\x265\build\vc11-x86_64\release\x265.exe c:\Testx265\x265.exe /Y

Note that the above scripts will default to the development tip. If you want to build the latest stable version, run the following command (after you pull the latest code with hg pull)...
hg up stable
... then make the solution and build.

I hope this helps.

Tom
MulticoreWare

[filler56789]

Where can i get builds?

https://x265.cc/

...perhaps know a easy way to build it?

http://forum.videohelp.com/threads/357754-%5BHEVC%5D-x265-EXE-mingw-builds?p=2259093&viewfull=1#post2259093

[zerowalker]

Thanks!

[Kurtnoise]

Does anybody confirm that the latest x265 builds (with the latest commits from today) are broken using the pipeline ?

I tested my own builds and the ones from x265.cc, all fail...at least with yuv.
ok, it has been fixed...

[LigH]

Just for fun i encoded Tears of Steel with extreme settings with x264 at crf 18 and got an average bitrate of 6890 kbps, so 30 Mbps seems to be a little bit too much for me when you (James Freeman) expect "big" differences between h264 and HEVC.

Preset "placebo" is mainly a waste of time. Any faster preset would take less efforts to remove redundancies and return more bitrate.

If you want higher bitrate, don't encode slower. Instead, encode more exactly, decrease the CRF value.

I just encoded a 1 minute snippet from "Tears of Steel" using x265 with CRF 12, but still a slower preset to ensure a high complexity to stress decoders. It has an average of ~31.3 Mbps video bitrate. Peaks are around 100 Mbps (if I can use the bits-per-frame log as reliable presentation base).

tos_60s_hevc.mp4 (http://www.mediafire.com/download/zb8tbcr5v2tu31z/tos_60s_hevc.mp4) on MediaFire (224 MB)

http://www.ligh.de/pics/tos_60s_hevc.png

[LigH]

To keep the bitrate in a closer range, x265 would require a VBV like regulation, though.

And just that was mentioned in the developer mailinglist, regarding a source patch.

Soon™. :)

[James Freeman]

@LigH

Thank you for this sample.
I takes about 2-3 times the CPU load across all cores (no GPU decoding) compared to a 30Mbps Blu ray.

[x265_Project]

I've just published an updated version of the x265 Evaluator's Guide (https://bitbucket.org/multicoreware/x265/downloads/x265%20Evaluators%20Guide%2011-07-13.pdf).

Let me know if anything is unclear, or if you have any suggestions for improvement.

Thanks!

Tom
MulticoreWare

[vood007]

Is there anything special to take care of when using --aq-mode 1 ? As LigH said it breaks video when used with a preset faster than "slower".

Using VDub with "--input-res %(width)x%(height) --fps %(fps) --preset faster --crf 24 --aq-mode 1 --no-progress - -o "%(tempvideofile)"
and latest MPCHC/LAV for playback.

Anyway thanks to all x265 devs out there, you do a fantastic job!

[LigH]

As LigH said it breaks video when used with a preset faster than "slower".

I did not say it this way; but if your observation is correct, then it may be related to slower presets initializing some specific options which faster presets might miss. This is certainly worth an investigation.
__

P.S.:

The preset "slower" is the fastest with full RDO analysis in mode decision (--rd 2), all faster presets use a limited RDO analysis. This is probably not yet supported well by AQ, according to Steve Borho (in the developer mailinglist).

[professor_desty_nova]

Is there a problem with --rd? Because now the "slower" and "veryslow" presets have it at rd=0. Or is it that with these presets it's too slow?

[Selur]

looking at the code (https://bitbucket.org/multicoreware/x265/src/45c5ba1dc340fe59a91b5397adb769e5ba8e2fde/source/common/common.cpp?at=default) it seems like they changed the defaults and removed all 'rdLevel' entries > 0 from the presets
-> small correction, the whole presets are a mess atm. since they have not been adjusted alongside the defaults,...
in example, new defaults state:
maxNumReferences = 3
veryfast, superfast, ultrafast -> maxNumReferences not defined -> maxNumReferences = default = 3
faster, fast preset -> maxNumReferences = 2
slow preset -> maxNumReferences = 3
.....

[Blue_MiSfit]

The latest 8 bit Windows x64 build from x265.cc seems to be doing something strange. I'm getting nasty corruption when playing in mpc-hc and the latest mp4box is refusing to mux it saying the following:


Unknown input file type
Unknown input file type
Error importing x265_20000.h265:fps=50: Corrupted Data in file/stream

[easyfab]

The latest 8 bit Windows x64 build from x265.cc seems to be doing something strange. I'm getting nasty corruption when playing in mpc-hc and the latest mp4box is refusing to mux it saying the following:


Unknown input file type
Unknown input file type
Error importing x265_20000.h265:fps=50: Corrupted Data in file/stream


Try with .265 or .hevc extension or add FMT=HEVC

[Blue_MiSfit]

Got it -that worked.

Still some horrible strangeness in MPC. I wonder if this is just a corner case? I'm trying to encode parkjoy in 1080p50 at 8 Mbps and 20 Mbps, and even at 20 Mbps the whole scene is extremely bright, blocky, and smeared in the first GOP. The brightness issue is fixed in the second GOP but it's still blocky and smeared.

x264 is almost perfect at this bitrate.

http://imgur.com/a/KEYSj#0

The images got reversed. Image 0 is the second GOP and image 1 is the first GOP.

[filler56789]

@ Blue_MiSfit: how about posting the exact command-line you used?
Keep in mind that currently some of the options do produce weird results when used together.

Also, when using avs2yuv without the option "-raw", x265 must use the --y4m switch.

[Blue_MiSfit]

Mostly defaults, just tuning for SSIM and measuring it, plus a 20 Mbps ABR target


x265 --bitrate 20000 --tune ssim --ssim --csv x265_20000.csv --output x265_20000.h265 parkjoy.y4m

[filler56789]

Mostly defaults, just tuning for SSIM and measuring it, plus a 20 Mbps ABR target


x265 --bitrate 20000 --tune ssim --ssim --csv x265_20000.csv --output x265_20000.h265 parkjoy.y4m


Which translates as something like:
x265 [info]: CU size : 64
x265 [info]: Max RQT depth inter / intra : 1 / 1
x265 [info]: ME / range / subpel / merge : star / 60 / 5 / 3
x265 [info]: Keyframe min / max : 250 / 250
x265 [info]: Rate Control : ABR-***** kbps
x265 [info]: Lookahead / bframes / badapt : 40 / 3 / 1
x265 [info]: tools: rect amp rd=0 ref=3 lft sao-lcu sign-hide aq

Therefore, thanks for confirming what I had said :)

currently some of the options do produce weird results when used together

For relevant and more up-to-date info, you'd better start following the thread http://forum.videohelp.com/threads/357754-%5BHEVC%5D-x265-EXE-mingw-builds

Yes, it has a lot of "noise" :rolleyes: , but that's not the point ;)

[benwaggoner]

I've been playing around with quality and scenario tuning of x265 (using 0.5+259-9d74638c3640). I have a few questions I haven't seen answered yet.


Does x265 CRF generally match the perceptual quality of x264 CRF? Or are they on a different visual scale due to QP being handled differently or anything? I note the default is 28, which is higher than x264's.
When using CRF, should --tune be left alone to let Rate Factor work, or will it still try to default to --tune PSNR, in which case using --tune SSIM will probably offer better VQ?
Was --weightp turned on by default? The Evaluator's guide suggests no, but the --preset parameters suggest yes
Does --aq-mode default to off due to quality concerns or what?
is --merange in pixels of final frame, or a half-size frame, or what?

[Blue_MiSfit]

:D go figure - the second I sit down to start messing around and the presets are wonky :D

[Hiritsuki]

well, I try to compile the default version in source code and test it....

http://i.minus.com/jvpiFisuI2r4G.png (http://minus.com/lvpiFisuI2r4G)

seems have some blur?

BD Source
http://i.minus.com/jbczilqQ9TWeKt.png (http://minus.com/lbczilqQ9TWeKt)

x265 -q 17
http://i.minus.com/jbdzO6RLxwUCWr.png (http://minus.com/lbdzO6RLxwUCWr)

[Hiritsuki]

Round 2

try to Disable SAO

http://i.minus.com/jbrLLhJeEFj8n0.png (http://minus.com/lbrLLhJeEFj8n0)

[Blue_MiSfit]

Good lord. Is that a quad socket system with all 8 core CPUs? Running 2012 R2? Being used for home stuff? What fun ;)

To be on-topic, I would expect some softness. x265 is still quite young.

[x265_Project]

I've been playing around with quality and scenario tuning of x265 (using 0.5+259-9d74638c3640). I have a few questions I haven't seen answered yet.
Ben,
Answers from our lead developer inline below...

* Does x265 CRF generally match the perceptual quality of x264 CRF? Or are they on a different visual scale due to QP being handled differently or anything? I note the default is 28, which is higher than x264's.
CRF is a feature contributed by an open-source developer, back-porting this from x264, so we are roughly the same. However in general, I believe CRF really wants a decent adaptive quant feature and ours is still incomplete. It would really benefit from mb-tree but that is not even started yet.
* When using CRF, should --tune be left alone to let Rate Factor work, or will it still try to default to --tune PSNR, in which case using --tune SSIM will probably offer better VQ?
the --tune PSNR and --tune SSIM switches currently do nothing. We are still working through this as part of the AQ work.
* Was --weightp turned on by default? The Evaluator's guide suggests no, but the --preset parameters suggest yes

It is not, yet. We're waiting for weightp lookahead analysis before turning it on by default. We're currently *also* turning it off for ultrafast preset just to make sure when the default is switched on, the ultrafast preset still disables it. I expect this to be switched on by default this week.

* Does --aq-mode default to off due to quality concerns or what?
Basically, AQ, CRF, --tune SSIM and --weightp are all unfinished features in the middle of construction

* is --merange in pixels of final frame, or a half-size frame, or what?

It is in pixels of the final frame.

Tom

[Hiritsuki]

SAO will blur some color

Enable SAO 687MB
http://i.minus.com/jm9FR88Be2AcY.png (http://minus.com/lm9FR88Be2AcY)

Disable SAO 695MB
http://i.minus.com/j1Sq5zisRIjS7.png (http://minus.com/l1Sq5zisRIjS7)

[Kurtnoise]

Which decoder did you use ?

[Hiritsuki]

Lav :d

[Hiritsuki]

BTW

x264 10bit --preset Placebo --ref 8 --bframe 8 --pass 2pass --bitrate 5000 (0.99GB)

http://i.minus.com/jbNkIeHypsYTV.png (http://minus.com/lbNkIeHypsYTV)

[Hiritsuki]

hi, is there have any way to mux .h265 to other fomat with audio and change fps to 23.976?

[microchip8]

hi, is there have any way to mux .h265 to other fomat with audio and change fps to 23.976?

use mkvmerge

[filler56789]

use mkvmerge

Is there any HEVC-capable build of MKVtoolnix besides the non-compliant versions from the DivX Labs? :)

Otherwise, there are the alpha builds of MP4Box and mp42ts ;)

[easyfab]

DivX mkvmerge or mp4box, but this is experimental as the final specification is not out yet.
So your file could be incompatible in the future

[James Freeman]

@Hiritsuki

The x264 video is 5kbps and 990MB.
What is the kbps for the HEVC 695MB?


Disable SAO looks a lot better.

[mandarinka]

I've been playing around with quality and scenario tuning of x265 (using 0.5+259-9d74638c3640). I have a few questions I haven't seen answered yet.


Does x265 CRF generally match the perceptual quality of x264 CRF? Or are they on a different visual scale due to QP being handled differently or anything? I note the default is 28, which is higher than x264's.
When using CRF, should --tune be left alone to let Rate Factor work, or will it still try to default to --tune PSNR, in which case using --tune SSIM will probably offer better VQ?
Was --weightp turned on by default? The Evaluator's guide suggests no, but the --preset parameters suggest yes
Does --aq-mode default to off due to quality concerns or what?
is --merange in pixels of final frame, or a half-size frame, or what?


x265 doesn't have psyrdo, which means that the visual quality isn't quite as good as with x264 - it will still smooth out texture or grain, although less so now that you can use adaptive quantization (it really helps in this). It seemed to me though that the crf "number" isn't that different from x264 when I tried it with placeboish options (everybody needs to try how it works out for them, though).

[Hiritsuki]

@James Freeman

Yes, disable SAO is looks better than enable.
I set x265 -q 17
28min22s and 695MB so...it's AVG 3345kbps
It's encode over 2.5hours.

final I use mp4box (beta ver?) to mux video,audio and change fps frome friend.

[sneaker_ger]

final I use mp4box (beta ver?)
Yes, get a nightly from here (http://gpac.wp.mines-telecom.fr/downloads/gpac-nightly-builds/#Windows 32 bits).

Not sure if it is ok to just change the frame rate in mp4box or if you should use the correct frame rate in x265 using the --fps parameter already.

[fumoffu]

http://i.minus.com/ibwKpR4gi1WDk8.png http://i.minus.com/i9ZZMdX4hwGt.png

the lines in HEVC look much nicer, pretty much ideally while there is a lot of jaggies and ringing in x264

although this might be due to default psy.

x264 10bit --preset Placebo --ref 8 --bframe 8 --pass 2pass --bitrate 5000 (0.99GB)
--tune animation sets --psy-rd 0.4:0 I prefer even lower like --psy-rd 0.3:0
btw. tune animation also sets --aq-strength 0.6 which I find puzzling because it seems high values like --aq-strength 1.3 or 1.4 prevent artifacts on smooth areas and gradients
it's also recommended to disable trellis for animation --trellis 0

[Hiritsuki]

use the correct frame rate in x265 using the --fps parameter already.

x265 using --fps is means input source's fps is:scared:

[Hiritsuki]

in my test .. 8bpp have little better quality than 16bpp
i thought because that 16bpp is use for 10,12,16bit input.


@fumoffu

x264 have to set tune but x265 have not and file size is smaller.
but encode time is more than x264 4 times...

[zerowalker]

does x265 support 16bit output?
Or is it only input up to 16bit or something?

[LigH]

It is not related to the resolution of the visible image components (RGB or YUV), only to the internal representation of coefficients after a transformation into a frequency domain (prior to H.264, a Discrete Cosine Transform with 8×8 sample partitions – blocks and macroblocks – was commonly used; since H.264, additional integer transforms with different partition sizes are more common).

The support of "deep-color video" is not yet implemented. If it will be, is guesswork...

[Selur]

does x265 support 16bit output?
Or is it only input up to 16bit or something?
from what I see atm. both input and output should be 8bit (only internal calculation precision can be changed to 16bit and it's unclear if that is working properly)

[qyot27]

Actually, you can output 10-bit if you give it YUV and use --input-depth 10. mediainfo detects it as 10-bit, and it can be played back by the HEVC decoder in libavcodec (ffmpeg detects it as yuv420p10le too). But it seems that many parts of the encoding chain haven't been made high bit depth aware, since to avoid macroblocking you have to use a lower crf value than for 8-bit (or we're just seeing the return of crf value skew between bit depths like right after 10-bit was added to x264).

It'd be nice if the y4m support would include the extended format that FFmpeg uses (VapourSynth also uses it, and x264 can recognize it). That'd allow for piping in high bit depth video in y4m. Currently, it complains about missing headers if you try it.

[zerowalker]

I see well 16bit internal processing should be advantageous, especially in dark areas.
Still i would like it to have output support to 10bit, above would be nice as well though it has dimishing return.

Has anyone tried Lossless btw, and compare it to x264 in size?
If x265 has lossless support yet that is.

Have tried some tests myself, but it doesn´t seem to go my way, and crash or just turn out to look really crappy for some reason.
Not sure if it´s suppose to look like 500bitrate when it´s at 2k, even if it is in Beta.

[Kurtnoise]

x265 doesn't have a lossless mode yet...:rolleyes:

[zerowalker]

Ah, hope it comes, x264 is amazing.
Though i do prefer Lagarith and UT Video Codec cause of the Key Frames i think, x264 messes up Seek ability when editing.

though about x265, is Decoding lagish for you?
It seems to lag for me even though it doesn´t use 100% of the CPU (or 50% in my case as i think it only has 2 threads supported).

And also did some tests, and x265 very similar in quality to x264 as it is now, a bit worse. But in it´s development stage i think that´s to be expected as x264 has been developed for as long as one can remember.

[pieter3d]

It is not related to the resolution of the visible image components (RGB or YUV), only to the internal representation of coefficients after a transformation into a frequency domain (prior to H.264, a Discrete Cosine Transform with 8×8 sample partitions – blocks and macroblocks – was commonly used; since H.264, additional integer transforms with different partition sizes are more common).

The support of "deep-color video" is not yet implemented. If it will be, is guesswork...

HEVC's transforms are bit-depth agnostic. They are always 16-bit signed. Only the quantization is adjusted for bitdepth.

[Hiritsuki]

why new version 0.5+414-1449a1a2041f I get error crash?