x265 HEVC Encoder

[sirt]

Hi,

Well I really don't know almost anything about HEVC ! I did some random search but I can't find anything clear...is it possible to encode in command line mode ? Can I recode a .264, .mkv, .avs script ?

For example, with a .264, I tried that :


x265.exe --preset placebo --sar 1:1 --profile main --level 5.1 --me 4 --subme 7 --merange 32 --bitrate 10000 --pass 1 -width 1920 --height 1080 -fps 24 rob.h264 -o rob_pass1.mkv
x265.exe --preset placebo --sar 1:1 --profile main --level 5.1 --me 4 --subme 7 --merange 32 --bitrate 10000 --pass 2 -width 1920 --height 1080 -fps 24 rob.h264 -o rob_pass2.mkv
pause


I don't know what happens, probably nothing (I get something similar to --help for example).

I tried something like that one year ago and it seems it is still the same : it is requiered to set widt, height, fps and it doesn't work (apparently). Still can't something else than .yuv be encoded ?

[Boulder]

x265 works just like x264 what comes to command line encoding.

In your example, the fps parameter needs two dashes so it should be --fps 24. But you don't need the parameter if the source and destination fps is the same. Also there's no width or height parameter, at least according to https://x265.readthedocs.org/en/default/index.html.

[sirt]

x265 works just like x264 what comes to command line encoding.

In your example, the fps parameter needs two dashes so it should be --fps 24. But you don't need the parameter if the source and destination fps is the same. Also there's no width or height parameter, at least according to https://x265.readthedocs.org/en/default/index.html.

Thanks Boulder : if I set width, height, fps with "--", same it doesn't work : x265 help comes.

If I don't set anyone :


x265 [error] : yuv : width, height, and FPS must be specified
x265 [error] : unable to open input file <rob.64>


Well I never managed to encode anything with that and it is NOT a yuv video. Just a .264 demuxed from an mkv.

[Boulder]

The parameter for width and height is "input-res"

https://x265.readthedocs.org/en/default/cli.html?highlight=input#cmdoption--input-res

[sirt]

The parameter for width and height is "input-res"

https://x265.readthedocs.org/en/default/cli.html?highlight=input#cmdoption--input-res

Indeed, thanks, something has started with that :


x265.exe --preset placebo --sar 1:1 --profile main --level 5.1 --me 4 --subme 7 --merange 32 --bitrate 10000 --pass 1 --input-res 1920x1080 --fps 24 rob.h264 -o rob_pass1.mkv
x265.exe --preset placebo --sar 1:1 --profile main --level 5.1 --me 4 --subme 7 --merange 32 --bitrate 10000 --pass 2 --input-res 1920x1080 --fps 24 rob.h264 -o rob_pass2.mkv

pause

[LigH]

In general, x265 won't be able to read raw AVC (*.h264), and won't create MKV either. It won't contain libavcodec decoders and multiplexers (except you have a special patched build). Pure x265 builds will only read raw YUV (planar 4:2:0) or Y4M (YUV4MPEG, that's basically raw YUV with a very basic text line as header describing resolution, frame rate, and pixel format), not even AviSynth scripts are supported yet. Using a raw AVC bitstream as input may result in encoded noise because x265 will read it as if it were raw YUV.

To feed an AviSynth script decoding an encoded source format into x265, you can use e.g. avs4x26x. But it will still create only an elementary HEVC stream (except it's compiled with additional multiplexers like L-SMASH MP4). You will usually multiplex it afterwards into an MP4 using MP4Box or L-SMASH, or into an MKV using mkvmerge.

Furthermore, do yourself (and your electricity bill) a favour and don't assume "--preset placebo" to be a sensible setup for x256. It's even more a waste of time than you may know from x264.

[benwaggoner]

--merange 121 slowed performance by 13%, but I didn't really see a difference in the output bitstream.
Did you test that with a variety of frame sizes? I would think you'd be more likely to see an improvement with higher --merange at 4K?

Still, it's not surprising; anything moving fast enough to need that much motion search would be so distorted by motion blur that a good match would be hard to find, and the remaining frequencies would be so low as to be easy to encode. It might take something without motion blur like 4K cel animation to really find good matches at the largest search ranges. I don't know if anyone has ever actually made any 4K cel animation to test that with, though.

[sirt]

In general, x265 won't be able to read raw AVC (*.h264), and won't create MKV either. It won't contain libavcodec decoders and multiplexers (except you have a special patched build). Pure x265 builds will only read raw YUV (planar 4:2:0) or Y4M (YUV4MPEG, that's basically raw YUV with a very basic text line as header describing resolution, frame rate, and pixel format), not even AviSynth scripts are supported yet. Using a raw AVC bitstream as input may result in encoded noise because x265 will read it as if it were raw YUV.

To feed an AviSynth script decoding an encoded source format into x265, you can use e.g. avs4x26x. But it will still create only an elementary HEVC stream (except it's compiled with additional multiplexers like L-SMASH MP4). You will usually multiplex it afterwards into an MP4 using MP4Box or L-SMASH, or into an MKV using mkvmerge.

Furthermore, do yourself (and your electricity bill) a favour and don't assume "--preset placebo" to be a sensible setup for x256. It's even more a waste of time than you may know from x264.

Hi,

Thanks for your answer. I was not planning to encode that anyway, I just gave a try to an old command line. From what you say, I understand it is not possible to encode anything properly with x265.

What am I supposed to do then ? I extracted some of my BluRay of which video streams are AVC or VC-1. Imagine I want to reenode corresponding extracted .264/.h264 stream in HEVC. How can I proceed ? What strikes me is that I read a couple of things about Handbrake and similar *1-click* solutions. It seems you can really encode BluRay video stream with that (using x265). In my case, I don't want to use such things but rather command lines. Unfortunately, from what you say, it seems doing what I want is not possible (you talk about "encoded noise" (?)). I don't even talk about avisynth scripts.

[LigH]

No, at the moment, you won't be able to simply convert anything else than uncompressed YUV video with the single x265 encoder. But you may use ffmpeg including libx265 to convert a compressed source format, as it is able to decode it before feeding the decompressed result to the x265 encoder library inside ffmpeg, and even multiplex the result into a container. The command line with parameters will then be a little more complex. And it scratches the borders of this thread's topic...

The alternative may be to create an AviSynth script and pipe its output into the x265 encoder. Tools like MeGUI or StaxRip may help you doing so. Handbrake or Hybrid may be useful to support encoding with ffmpeg, I believe.

[Ma]

x265.exe --preset placebo --sar 1:1 --profile main --level 5.1 --me 4 --subme 7 --merange 32 --bitrate 10000 --pass 1 --input-res 1920x1080 --fps 24 rob.h264 -o rob_pass1.mkv
x265.exe --preset placebo --sar 1:1 --profile main --level 5.1 --me 4 --subme 7 --merange 32 --bitrate 10000 --pass 2 --input-res 1920x1080 --fps 24 rob.h264 -o rob_pass2.mkv

pause


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').

[Jamaika]

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/sWTMhCdLGFMoNz6blH0K%2FqPYg50Alend

Elecard StreamEye4 info files BPG & X265:
http://i64.tinypic.com/2djp0f9.pnghttp://i63.tinypic.com/28030gi.png
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]

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]

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]

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]

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]

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

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

[LigH]

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.

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.

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]

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]

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.

[x265_Project]

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.

[x265_Project]

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?

[nevcairiel]

Even software decoders will be slower on 12-bit (or even incompatible), unless you have a proper reason to use it, I personally wouldn't.

[me7]

No proper reason, just remembering how going from 8-bit to 10-bit helped x264 alleviate banding.

[Atak_Snajpera]

Just add --psy-rd 2 to your command line. You do not need 10/12 bit at all.

Default
http://i.cubeupload.com/FzFWFZ.png

--psy-rd 2
http://i.cubeupload.com/DKDrIR.png

[Ma]

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.

I encoded 5 samples on i5 3450S, Win7 64-bit, 10-bit output, with options:
--crf 17 --rdoq-level 1 --psy-rd 1 --deblock -1 --keyint 288 --colormatrix bt709
at presets: slow, slower, veryslow, placebo (only first sample).

Relative encoding time of different samples related to '--preset slower' (=100%):

----------------------| slow slower verysl placebo
1920x800-hob.y4m 28,3% 100,0% 158,1% 423,7%
1920x800-ret.y4m 33,6% 100,0% 147,1% --
720p50_parkrun_ter.y4m 24,9% 100,0% 153,3% --
ducks_take_off_1080p50 28,3% 100,0% 150,9% --
park_joy_1080p50.y4m 25,8% 100,0% 154,4% --


Relative encoding time of different samples related to '--preset veryslow':

----------------------| slow slower verysl placebo
1920x800-hob.y4m 17,9% 63,2% 100,0% 268,0%
1920x800-ret.y4m 22,9% 68,0% 100,0% --
720p50_parkrun_ter.y4m 16,2% 65,2% 100,0% --
ducks_take_off_1080p50 18,8% 66,3% 100,0% --
park_joy_1080p50.y4m 16,7% 64,8% 100,0% --


Encoding speed in frames per second (fps) of different samples:

----------------------| slow slower verysl placebo
1920x800-hob.y4m 3,09 0,87 0,55 0,21
1920x800-ret.y4m 2,58 0,87 0,59 --
720p50_parkrun_ter.y4m 5,84 1,45 0,95 --
ducks_take_off_1080p50 1,38 0,39 0,26 --
park_joy_1080p50.y4m 1,89 0,49 0,31 --


Preset 'slow' is much faster than 'slower', preset 'placebo' is much slower than 'veryslow'. Full data in attached file screen.txt

[sneaker_ger]

Just add --psy-rd 2 to your command line. You do not need 10/12 bit at all.

Default
http://i.cubeupload.com/FzFWFZ.png

--psy-rd 2
http://i.cubeupload.com/DKDrIR.png
>=10 bit can still be useful.

x265 1.8+191

source
http://abload.de/img/source_ewsvl.png

8 bit (default)
http://abload.de/img/8bitbyzbv.png

8 bit (--psy-rd 2)
http://abload.de/img/8bit-psy-rd2eolk2.png

10 bit (default)
http://abload.de/img/10bito3zd2.png

12 bit (default)
http://abload.de/img/12bit46zh3.png

In fades it's way more pronounced:
output videos (https://mega.nz/#F!QhEhxb5T!Q8Zkgb1x3CK4RO3rKdoIWQ)
(source (https://mega.co.nz/#!osdxQbCR!vim8f5gAD5nf0w0jf-vEAA3mGySmEOoZQOH_GE3Z2uw), mirror (http://217.160.126.132/lighthouse_lossless.mp4))

[Blowis]

Hi, Happy new year,
I wanted to know if I use vbv-maxrate, vbv-bufsize and I chose Crf: 21. Does the crf-max: 51 is active by default?
If I put crf-max: 30 is the active or not?
If it is active and I put a smaller value than the crf it changes anything?
Thank you

[LoRd_MuldeR]

CRF and VBV operate "side by side".

Simply put, first CRF RC will determine the "desired" bitrate for the current frame (based on the selected CRF and CRF-Max value), and then VBV will check whether that bitrate is currently "acceptable" or whether it has to be "capped".

So, if you only set the VBV limits high enough, you get perfectly "unaffected" CRF. If, on the other hand, you set the VBV limits very low, you will be running into the VBV limits all the time, effectively "overriding" CRF altogether.

Usually, if you make a "reasonable" choice of the CRF value and the VBV limits, you should get more or less "normal" CRF, with VBV kicking in here and there to "attenuate" the biggest bitrate peaks. But it really depends on the source ;)

[Nullack]

Hey guys. Im trying to get my head around an experiment I did. I took a sample cut from a DVD, thats around 125 MB. Then I used ffmpeg to convert it into Y4M for input into x265. Even when I do a recent build of x265 on the placebo and lossless settings Im still around 500 MB encoded in HEVC. Whats happening here? I suspect its something that should be apparent to me but after the excesses of the XMAS break the brain cells need time to work :)

[Atak_Snajpera]

you are converting lossy mpeg2 to lossless x265. It is like converting jpeg to bmp and then to lossless png.

[LigH]

On top, you don't understand that "placebo" is no sensible preset; its purpose is to waste as much time as possible. Even more on lossless results which skip most of the encoding steps a preset would affect at all. ;)

[Nullack]

Im experimenting with format shift from mpeg / dvd transport stream into hevc without quality loss. I only did the y4m step due to x265s needs. Ill try to do some research but any hints on command lines is welcome.

[foxyshadis]

Hey guys. Im trying to get my head around an experiment I did. I took a sample cut from a DVD, thats around 125 MB. Then I used ffmpeg to convert it into Y4M for input into x265. Even when I do a recent build of x265 on the placebo and lossless settings Im still around 500 MB encoded in HEVC. Whats happening here? I suspect its something that should be apparent to me but after the excesses of the XMAS break the brain cells need time to work :)

x265 doesn't know what you started with and just encodes as fancy as you tell it to, even if it's much more than the original, because DVD artifacts create artificial difficulty. Set quality (--crf) higher to reduce the size; default is 28. You'll never get no quality loss; you're better off removing DVD artifacts and then re-encoding at as much bitrate as you need.

btw, you can use ffmpeg and other tools to send y4m directly to x265, without writing a huge file.

[Nullack]

Aha! Now its clear thats a brilliant explanation thanks very much Foxyshadis. Artificial difficulty I like that for what the issue is

[Blowis]

CRF and VBV operate "side by side".

Simply put, first CRF RC will determine the "desired" bitrate for the current frame (based on the selected CRF and CRF-Max value), and then VBV will check whether that bitrate is currently "acceptable" or whether it has to be "capped".

So, if you only set the VBV limits high enough, you get perfectly "unaffected" CRF. If, on the other hand, you set the VBV limits very low, you will be running into the VBV limits all the time, effectively "overriding" CRF altogether.

Usually, if you make a "reasonable" choice of the CRF value and the VBV limits, you should get more or less "normal" CRF, with VBV kicking in here and there to "attenuate" the biggest bitrate peaks. But it really depends on the source ;)

Thank you for your reply.
I just see if I let Crf-Max: 51 (default) after encoding with MediaInfo I read crf-max = 0.0 (that means it's off). If I change as crf-max = 30 I read the crf-max = 30.0 (as it means it is active).
I say its because the X265 site for crf-max it is said:
Specify an upper limit to the rate factor qui May be Assigned to Any Given frame (max Ensuring a QP). This is dangerous When CRF is used in combination with LSV as it May result in buffer underruns. Default disabled.

Cfr mode it is better to leave then disable crf-max: 51.
For I the modified crf-max: 30 so I activated.

[LoRd_MuldeR]

I say its because the X265 site for crf-max it is said:
Specify an upper limit to the rate factor qui May be Assigned to Any Given frame (max Ensuring a QP). This is dangerous When CRF is used in combination with LSV as it May result in buffer underruns. Default disabled.

Well, I think if you set an upper limit for the rate-factor, it may happen that VBV needs to lower the bitrate in order to prevent an imminent buffer underflow, but it simply can't do so, because the rate-factor already reached its limit.

(Actually I don't know why you would want to limit the max. rate-factor)

[Nullack]

On top, you don't understand that "placebo" is no sensible preset; its purpose is to waste as much time as possible. Even more on lossless results which skip most of the encoding steps a preset would affect at all. ;)

According to the read the docs doco on x265 cli for the lossless option:

"Slower presets will generally achieve better compression efficiency (and generate smaller bitstreams)"

So I figured since its a short sample clip I might as well do placebo to see how small it could make the test file wjile also using lossless

Thoughts?

[LoRd_MuldeR]

According to the read the docs doco on x265 cli for the lossless option:

"Slower presets will generally achieve better compression efficiency (and generate smaller bitstreams)"

So I figured since its a short sample clip I might as well do placebo to see how small it could make the test file wjile also using lossless

Thoughts?

Yes, generally, using a "slower" presets gives better compression efficiency, i.e. it results in better "quality per bit" ratio. How the total size will be effected (at a fixed CRF), that's undefined. Might become smaller or bigger.

However, the slower the preset is that you are already using, the less additional improvement can be gained by using an even slower one! Or, in other words: The additional improvements becomes increasingly expensive (in terms of CPU cycles).

Thus going from "veryslow" to "placebo" will slow things down quite a lot... for a very minimal improvement.

(So, if you don't care about encoding time or about your electricity bill, then cranking everything up to "placebo" doesn't hurt. But, under normal circumstances, it's just not worth it)

[Blowis]

Well, I think if you set an upper limit for the rate-factor, it may happen that VBV needs to lower the bitrate in order to prevent an imminent buffer underflow, but it simply can't do so, because the rate-factor already reached its limit.

(Actually I don't know why you would want to limit the max. rate-factor)


I thought if I put crf-max lower than 51 I would have a better quality.
For example I use crf: 21 and I put crf-max: 30 I would have a better quality than crf-max: 51

After I saw that if I put the same parameter of the Medium profile to Profile Faster I faster encoding except that I have exactly the same info with MediaInfo.
I thought if we put the same parameter regardless profile had the same encoding.
It means that there are hidden parameter that belongs to each profile.

[LigH]

@ Nullack:

In addition to LoRd_MuldeR, a little more specific: The "placebo" preset uses the most elaborate set of options, it does not even use "shortcuts" which would usually cause no visually noticable difference but a quite noticable speedup of the encoding. It calculates every case, even the most improbable to affect encoding efficiency.

[foxyshadis]

I thought if I put crf-max lower than 51 I would have a better quality.
For example I use crf: 21 and I put crf-max: 30 I would have a better quality than crf-max: 51
Better quality and a larger file size. You could just lower the crf slightly and get about the same effect. With a crf of 21, QPs over 30 will rarely be used anyway, but when they are, you shouldn't see a difference.

After I saw that if I put the same parameter of the Medium profile to Profile Faster I faster encoding except that I have exactly the same info with MediaInfo.
I thought if we put the same parameter regardless profile had the same encoding.
It means that there are hidden parameter that belongs to each profile.

At the very least, rd, ref, and b-adapt should change. Are you sure they're the same?