x265 HEVC Encoder

[Jamaika]

Originally Posted by vivan

Unknown? How about 3x lower bitrate?

You can change HEVC data losslessly and freely from the container BPG to MP4.
https://www.sendspace.com/filegroup/...%2FqPYg50Alend

Elecard StreamEye4 info files BPG & X265:

Size and bitrate files:

swimming_x265_yuv444.mp4 10420204 |  7550 Kbps
swimming_yuv444.bpg      13212111 |  9572 Kbps
swimming_rgb.bpg         17994215 | 13037 Kbps
swimming_rgba.bpg        18040885 | 13037 Kbps

Bitrate bpg for yuv444 is 1.25x higher. However, I am not convinced that this significantly affect the appearance of the film.

Edit:
Inactive functions or don't know the application:
x265 --crf-max 37 --crf-min 34 --level-idc 4.0

[LigH]

@ Ma + sirt:

I would still not recommend any preset slower than "slower" if you want to live to see the result.

Again, and again, and again: "placebo" is not a practically useful preset, it is "the bad example" of all the slowest possible options, some won't even provide better quality despite wasting more time.

[Ma]

Originally Posted by LigH

I would still not recommend any preset slower than "slower" if you want to live to see the result.

I partially agree. For hi-res encoding '--preset placebo' is slow, but '--preset veryslow' is quite interesting.

You can see how big is the difference in encoding quality between '--preset slower --crf 15' and '--preset veryslow --crf 15' with small sample (only 177 frames)
http://www.msystem.waw.pl/x265/uhd177.y4m

Look for smooth movement of objects.

[ndkamal]

I do some tests with two version of x265 on my laptop with a Core I5-4200, the V18R186 and the V18R188, and the speed increase is very good, with an increase of 71 % on a video with resolution of 1920x1038.

Very good progress. Moreover the quality of picture is a bit better.

x265 V18R186 preset slow :
Neou (672x272) (1.4 Mbps) : 32.21/8.31
24 (672x368) (1.4Mbps) : 31.11/7.44
Alliance (1280x544) (3 Mbps) : 13.08/3.75
Prete (1920x1038) (6 Mbps) : 4.16/1.06

x265 V18R188 preset slow :
Neou (672x272) (1.4 Mbps) : 33.36/13.79
24 (672x368) (1.4 Mbps) : 32.02/12.44
Alliance (1280x544) (3 Mbps) : 13.56/5.43
Prete (1920x1038) (6 Mbps) : 4.45/1.82

Speed increase :
Neou: 65 %
24 : 67 %
Alliance : 45 %
Prete : 71 %

[Boulder]

Originally Posted by Ma

I partially agree. For hi-res encoding '--preset placebo' is slow, but '--preset veryslow' is quite interesting.

It would be interesting to see a comprehensive comparison between medium - slow - slower - veryslow. Veryslow tends to take a very long time even with 720p sources and --limit-modes + --limit-refs 3.

[Nullack]

Hi, Im learning from the "read the docs" and experimenting. SOme Q's pls:

1. Do I assume right that -CRF 0 is not lossless, only -lossless is? -CRF 0 encodes are smaller than -lossless encodes with the same input.
2. Is two pass CRF worthwhile?
3. ffmpeg muxing into mp4 is saying the content is variable framerate in mediainfo. I see there is no constant frame rate option like in x264? So is it all constant frame rate but mediainfo isnt reporting it correctly?

Thanks

[sirt]

Originally Posted by Ma

It will not work.
You can start with this:

ffmpeg -i rob.h264 -loglevel warning -f yuv4mpegpipe - | x265 --y4m - --preset fast --sar 1:1 --profile main --level 5.1 --subme 7 --merange 32 --bitrate 10000 --pass 1 -o NUL
ffmpeg -i rob.h264 -loglevel warning -f yuv4mpegpipe - | x265 --y4m - --preset fast --sar 1:1 --profile main --level 5.1 --subme 7 --merange 32 --bitrate 10000 --pass 2 -o rob_pass2.hevc
mkvmerge rob_pass2.hevc -o rob_pass2.mkv

If you succeed you can change '--preset fast' to '--preset placebo' (and you should forget about '--me 4').

Ma, thanks. Then what would be the command line for an avisynth script (.avs) ?

[shinchiro]

Originally Posted by Boulder

Veryslow tends to take a very long time even with 720p sources and --limit-modes + --limit-refs 3.

Disabling these setting when using preset veryslow will cut down encoding time by half probably.

--no-rect --no-amp --no-b-intra --no-weightb --no-strong-intra-smoothing --no-sao

The quality probably negligible to notice compare to default veryslow settings.

[rack04]

Originally Posted by sirt

Ma, thanks. Then what would be the command line for an avisynth script (.avs) ?

Change "rob.h264" to "rob.avs"

[LigH]

Originally Posted by Nullack

1. Do I assume right that -CRF 0 is not lossless, only -lossless is? -CRF 0 encodes are smaller than -lossless encodes with the same input.

CRF will in general not have a constant quantization, it tries to find the quantizer where the loss of quality is below a threshold related to the "rate factor". Only a forced quantization mode can guarantee lossless encoding; CRF will not guarantee that.

The parameter --lossless will enforce lossless encoding by a special mode bypassing several encoding steps. It seems to do even more than you would expect from a parameter -q 0 for constant quantization; both parameters can only be found in the "full help" of the CLI encoder (--log-level full --help) or in the online documentation.

The parameter --cu-lossless does not mean enforcing lossless encoding. It only allows to consider lossless encoding per coding unit.

Originally Posted by Nullack

2. Is two pass CRF worthwhile?

"2-pass CRF" is not really 2-pass in the meaning of running two separate passes; it is rather a per-GOP refinement to ensure that CRF encoding will respect VBV constraints. It is indeed useful for a fast yet rather optimal encoding where you have no specific target size, VBV constraints are most important, and the bitrate may only vary according to the rate factor where you have enough overhead due to a not completely filled decoding buffer.

Originally Posted by Nullack

3. ffmpeg muxing into mp4 is saying the content is variable framerate in mediainfo. I see there is no constant frame rate option like in x264? So is it all constant frame rate but mediainfo isnt reporting it correctly?

MediaInfo already reports VFR at the slightest hint that a container supports a duration per frame. It won't check if all frames have the same duration. Just the fact "the container may support VFR" seems to be relevant enough for MediaInfo.

[sirt]

With an .avi (lossless Lagarith), example :

ffmpeg -i rob.avi -loglevel warning -f yuv4mpegpipe - | x265 --y4m - --preset slower --sar 1:1 --profile high --level 4.1 --subme 7 --merange 32 --bitrate 5000 --pass 1 -o NUL
ffmpeg -i rob.avi -loglevel warning -f yuv4mpegpipe - | x265 --y4m - --preset slower --sar 1:1 --profile high --level 4.1 --subme 7 --merange 32 --bitrate 5000 --pass 2 -o rob_pass2.hevc

pause

I get an error or perhaps a warning

[yuv4mepgpip@054a3d00] Encoder did not produce proper pts, making some up.

Then, it seems it starts (I will let it go and see if it works until the end). Is that important ?

Moreover, am I really forced to use ffmpeg to encode in command line ? I don't understand why we use ffpmeg and a pipe (perhaps, because we don't use yuv and we want to force x265 encode a non yuv stream).

[LigH]

"No proper PTS" is not a serious warning. Not all containers support very detailed per-frame values and assume a contiguous progression of a default value.

[Nullack]

Thanks allot Ligh

[benwaggoner]

Originally Posted by Jamaika

You can change HEVC data losslessly and freely from the container BPG to MP4.
Bitrate bpg for yuv444 is 1.25x higher. However, I am not convinced that this significantly affect the appearance of the film.

You could probably increase the cbqpoffs/crqpoffs values some when encoding to 4:4:4 to get back some of the bitrate v. 4:2:0 without visual loss in quality. With 4x the samples, you can almost certainly afford some higher quantization.

[Jamaika]

Thanks for the answer. It's good that there are such functions. Where to begin? Is HEVC analyzer which can the values display of these functions cbqpoffs/crqpoffs?
I see that the values can be from -12 to 12.

[sirt]

Just for your information, I tried above command lines and my (old ?) computer simply shut down after pass 1 started, even with preset "fast". I'm encoding a sample of 4 minutes. It has never happened with x264 before though (I encoded same sample with slow presets, in command line and without ffmpeg). I have no idea what happens as there is no log or error message. Actually I have a problem with my ventilator unit : each time a lot of CPU is requested, this ventilator heats (I hear a lot of noise). It is just disturbing but nothing more. I guess it is due to x265 (I am on a 32 bit Windows vista engine).

[foxyshadis]

Originally Posted by sirt

Just for your information, I tried above command lines and my (old ?) computer simply shut down after pass 1 started, even with preset "fast". I'm encoding a sample of 4 minutes. It has never happened with x264 before though (I encoded same sample with slow presets, in command line and without ffmpeg). I have no idea what happens as there is no log or error message. Actually I have a problem with my ventilator unit : each time a lot of CPU is requested, this ventilator heats (I hear a lot of noise). It is just disturbing but nothing more. I guess it is due to x265 (I am on a 32 bit Windows vista engine).

Hardware stability problems aren't x265's problem. While there's a hardware subforum here, you'd probably be better off asking at an overclocking enthusiast forum to track down where your hardware problem is and how to fix it. x264 was the best stress test of hardware five years ago for the same reason.

Originally Posted by sirt

Just for your information, I tried above command lines and my (old ?) computer simply shut down after pass 1 started, even with preset "fast". I'm encoding a sample of 4 minutes. It has never happened with x264 before though (I encoded same sample with slow presets, in command line and without ffmpeg). I have no idea what happens as there is no log or error message. Actually I have a problem with my ventilator unit : each time a lot of CPU is requested, this ventilator heats (I hear a lot of noise). It is just disturbing but nothing more. I guess it is due to x265 (I am on a 32 bit Windows vista engine).

It doesn't surprise me to hear reports like this. x265 is more CPU intensive than any application you can find. Overclockers are finding that x265 is the ultimate test of whether an overclocked system is stable. Even when a system proves to be stable with every other overclocking benchmark, it may not be stable when it tries to run x265. This is because of the very high levels of parallelism in our code, and because the code is highly optimized, including vectorization with all of the latest SIMD instruction sets (SSE, SSE2, SSE3, AVX, AVX2, etc.).

You can monitor your CPU temperatures with a utility like http://www.cpuid.com/softwares/hwmonitor.html.

How to fix this? First, if you know what you're doing, you should clean your PC by carefully vacuuming out all of the dust you can get to. A can of compressed air can blow out any remaining dust from your CPU heatsink... but be careful not to damage anything! If your CPU temperature is still soaring (above 60 degrees C or worse) on a desktop PC you can try to remove and reset your heat sink with fresh thermal paste (heat sink compound). Don't spread the paste out, as this will trap air bubbles when you remount the heat sink. Apply the paste in two lines, in an X pattern, as shown at the end of this video (except your lines should be nice and smooth and even, like little wires lying on your CPU) https://www.youtube.com/watch?v=EyXLu1Ms-q4. If you do it right you'll see your CPU temperatures come down quite a bit from where they were before, and hopefully your PC won't crash when you do x265 encodes.

If you have a laptop, and you can't take the steps above, you can also try to go into your system BIOS and manually reduce the clock speed, or you can tell x265 to use fewer CPU threads using the --pools command, which controls the number of software threads in the thread pool. You would have to tell us your CPU type before we could tell you the values to try with the --pools command.

I just posted a new blog post with more details about our new performance presets.

http://x265.org/performance-presets/

[me7]

Is the grain tuning recommended for regular film? Particularly for CRF encodes that are not bitrate starved.
If I don't care for hardware decoding, should I just use a 12-bit build?