x265 HEVC Encoder

To see the changes, see this commit... https://bitbucket.org/multicoreware/...347e40e30debce

• increased the number of reference frames for slower, slow, fast, faster and veryfast
• turned on --limit-refs for veryslow, slower, slow, medium, fast, faster, and veryfast
• turned on --limit-modes for veryslow, slower and slow
• turned on --cutree for faster, veryfast, superfast and ultrafast
• increased max CTU size to --ctu 64 for veryfast

[Jamaika]

Updating presets for x265 v1.8.0.188 to improve coding efficiency and speed.

|                 |ultrafast |superfast |veryfast |faster |fast |medium |slow |slower |veryslow |placebo |
| ctu             |    32    |    32    |   64    |  64   | 64  |  64   | 64  |  64   |   64    |  64    | 
| ref             |     1    |     1    |    2    |   2   |  3  |   3   |  4  |   4   |    5    |   5    | 
| cuTree          |     1    |     1    |    1    |   1   |  1  |   1   |  1  |   1   |    1    |   1    |
| limit-refs      |     0    |     0    |    3    |   3   |  3  |   3   |  3  |   2   |    1    |   0    |
| limit-modes     |     0    |     0    |    0    |   0   |  0  |   0   |  1  |   1   |    1    |   0    |

Who knows why the placebo preset is disabled features "limit-refs/modes"? Could they not have been perfect?
When you expect the implementation of the "psy-rdoq = 50.0" for veryslow?
Who can explain to me what are the features "sao, amp, temporal-MVP, signhide, strong-intra-smoothin"? If you don't apply them for quick shots even playing the movie better presented.

[nevcairiel]

Originally Posted by Jamaika

Who knows why the placebo preset is disabled features "limit-refs/modes"? Couldn't they have been perfect?

Placebo is meant to be the ultimate preset with 100% of all quality options turned on, irregardless of speed. The two limit options can slightly cost efficiency to gain substantial speed improvements, which is not something you want in placebo.

[Boulder]

Originally Posted by x265_Project

To see the changes, see this commit... https://bitbucket.org/multicoreware/...347e40e30debce

• increased the number of reference frames for slower, slow, fast, faster and veryfast
• turned on --limit-refs for veryslow, slower, slow, medium, fast, faster, and veryfast
• turned on --limit-modes for veryslow, slower and slow
• turned on --cutree for faster, veryfast, superfast and ultrafast
• increased max CTU size to --ctu 64 for veryfast

After these changes, what it the recommended range for psy-rd and psy-rdoq if detail/noise/etc. retention is the goal? I've got one particularly difficult movie to encode (The Big Red One), with x264 and CRF18 it's ending up at ~9MBps at 1280x720 even with some denoising. I'd like to test to see what x265 can come up with.

[Jamaika]

Originally Posted by nevcairiel

Placebo is meant to be the ultimate preset with 100% of all quality options turned on, irregardless of speed. The two limit options can slightly cost efficiency to gain substantial speed improvements, which is not something you want in placebo.

Maybe it's the truth. For which CPUs was executed test presets. I use for veryslow "limit-ref = 3" because faster converts video.

PS Why does X265 v1.8.0.188 not retain the bitrate?
x265 x1.8.0.86 --bitrate 4500 --vbv-bufsize 10000 --vbv-maxrate 10000

Bit rate                                 : 4 595 Kbps
Maximum bit rate                         : 6 030 Kbps

x265 x1.8.0.188 --bitrate 4500 --vbv-bufsize 10000 --vbv-maxrate 10000

Bit rate                                 : 3 680 Kbps
Maximum bit rate                         : 4 923 Kbps

[Atak_Snajpera]

What do you think about increasing default --psy-rd value from very low 0.3 to 2?
According to my tests if you want to achieve similar level of details with x264 this must be increased in first place. Default 0.3 value can produce nasty banding effects in dark areas. (see jaw)

Source
http://i.cubeupload.com/AhAG58.png

x264 --veryslow --2pass --bitrate 2048
http://i.cubeupload.com/rKB3Sq.png

x265 --medium --2pass --bitrate 2048
http://i.cubeupload.com/FzFWFZ.png

x265 --medium --2pass --bitrate 2048 --psy-rd 2
http://i.cubeupload.com/DKDrIR.png

x265 --medium --2pass --bitrate 2048 --psy-rd 2 --aq-strength 2
http://i.cubeupload.com/nLhSxJ.png


I've also uploaded whole 10 min samples if you want to check how other scenes look like. (Use staxrip's video comparison tool)
https://mega.nz/#!pJFiHRaS!zxYtdhj4O...6Ia8n6HIHYGDwo

Originally Posted by nevcairiel

Placebo is meant to be the ultimate preset with 100% of all quality options turned on, irregardless of speed.

That's generally the idea, although there are more things we could do to sacrifice performance for that last little bit of possible quality. We wouldn't want to slow x265 to the point where it is absolutely unusable under any reasonable circumstances. Some extreme quality-centric x265 users might be ok waiting a couple of days for their encode to finish, but not for weeks or months.

--me 4 slows performance by 13X, and I couldn't see a noticeable improvement in quality

--subme 7 slows performance by about 9%, and visually you may see a difference in quality, so we may still consider adding this to placebo

--merange 121 slowed performance by 13%, but I didn't really see a difference in the output bitstream

Of course, you're free to tweak any parameters you would like in an attempt to improve speed or quality. For example, you could also try --preset placebo with --limit-refs and/or --limit-modes, and it would run much faster.

Originally Posted by Atak_Snajpera

What do you think about increasing default --psy-rd value from very low 0.3 to 2?
According to my tests if you want to achieve similar level of details with x264 this must be increased in first place. Default 0.3 value can produce nasty banding effects in dark areas. (see jaw)

Source
http://i.cubeupload.com/AhAG58.png

x264 --veryslow --2pass --bitrate 2048
http://i.cubeupload.com/rKB3Sq.png

x265 --medium --2pass --bitrate 2048
http://i.cubeupload.com/FzFWFZ.png

x265 --medium --2pass --bitrate 2048 --psy-rd 2
http://i.cubeupload.com/DKDrIR.png

x265 --medium --2pass --bitrate 2048 --psy-rd 2 --aq-strength 2
http://i.cubeupload.com/nLhSxJ.png


I've also uploaded whole 10 min samples if you want to check how other scenes look like. (Use staxrip's video comparison tool)
https://mega.nz/#!pJFiHRaS!zxYtdhj4O...6Ia8n6HIHYGDwo

I think that psy-rd has been improved to the point where it can probably stand a higher default value, and possibly a higher upper limit. We plan to take another look at this.

[Jamaika]

I don't know why there are such differences in image quality in my results. The file size of CRF=37:qcomp=1.00 x264 is three times higher than for CRF=37:qcomp=1.00 X265. Is this correct result? I will present your findings to the X265 CRF=37. The two supposedly identical commands for X265 and two different results from the original.

Test 1

ffmpeg.exe -loglevel info -i "swimming.avi" -s 1920x1080 -r 50000/1000 -an -sn -f image2 -c:v png -pix_fmt rgba "swimming%%003d.png"
bpgenc.exe -v -a -e x265 -c rgb -q 37 -alphaq 37 -m 9 -fps 50 "swimming%%003d.png" -o "swimming_rgba.bpg"
Edit: bpgenc.exe -v -a -e x265 -b 8 -f 444 -c rgb -q 37 -m 9 -fps 50 (only 25) "swimming%%003d.png" -o "swimming_rgb.bpg"
Edit: bpgenc.exe -v -a -e x265 -b 8 -f 444 -c ycbcr -q 37 -m 9 -fps 50 (only 25) "swimming%%003d.png" -o "swimming_yuv444.bpg"

Using x265 preset: placebo
x265 [info]: HEVC encoder version unknown
x265 [info]: build info [Windows][GCC 4.9.2][64 bit] 8bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
x265 [info]: Main 4:4:4 profile, Level-4 (Main tier)
x265 [info]: Thread pool created using 4 threads
x265 [info]: frame threads / pool features       : 2 / wpp(17 rows)
x265 [info]: Coding QT: max CU size, min CU size : 64 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 4 inter / 4 intra
x265 [info]: ME / range / subpel / merge         : star / 92 / 5 / 5
x265 [info]: Keyframe min / max / scenecut       : 25 / 250 / 40
x265 [info]: Lookahead / bframes / badapt        : 60 / 0 / 2
x265 [info]: b-pyramid / weightp / weightb       : 0 / 1 / 1
x265 [info]: References / ref-limit  cu / depth  : 1 / 0 / 0
x265 [info]: Rate Control                        : CQP-37
x265 [info]: tools: rect amp rd=6 rdoq=2 tskip signhide tmvp b-intra
x265 [info]: tools: strong-intra-smoothing deblock sao

Test 2

ffmpeg.exe -loglevel info -y -i "swimming.avi" -s 1920x1080 -r 50000/1000 -an -sn -f yuv4mpegpipe -strict experimental -pix_fmt yuv444p - | 
x265.exe --y4m --input-csp i444 --preset placebo --high-tier --crf 37 --ref 1 --bframes 0 --qcomp 1.00 --no-open-gop --no-psy-rd --no-psy-rdoq --no-info --limit-modes --limit-refs 3 --range full - -o "swimming.h265"

y4m  [info]: 1920x1080 fps 50/1 i444p8 unknown frame count
raw  [info]: output file: swimming.h265
x265 [info]: HEVC encoder version 1.8+188-
x265 [info]: build info [Windows][GCC 5.2.0][64 bit] 8bit+10bit+12bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
x265 [info]: Main 4:4:4 profile, Level-4.1 (Main tier)
x265 [info]: Thread pool created using 4 threads
x265 [info]: frame threads / pool features       : 2 / wpp(17 rows)
x265 [info]: Coding QT: max CU size, min CU size : 64 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 4 inter / 4 intra
x265 [info]: ME / range / subpel / merge         : star / 92 / 5 / 5
x265 [info]: Keyframe min / max / scenecut       : 25 / 250 / 40
x265 [info]: Lookahead / bframes / badapt        : 60 / 0 / 2
x265 [info]: b-pyramid / weightp / weightb       : 0 / 1 / 1
x265 [info]: References / ref-limit  cu / depth  : 1 / 1 / 1
x265 [info]: AQ: mode / str / qg-size / cu-tree  : 1 / 1.0 / 32 / 1
x265 [info]: Rate Control / qCompress            : CRF-37.0 / 1.00
x265 [info]: tools: rect amp limit-modes rd=6 rdoq=2 tskip signhide tmvp
x265 [info]: tools: b-intra strong-intra-smoothing deblock sao

View single frames I/P:

BPG x265 v0.9.6

x265 v1.8.0.188

Summary: Codec X265 with the same parameters fell much worse. The colors and sharpness are not the same. The cause is unknown.

[vivan]

Originally Posted by Jamaika

The file size of CRF=37:qcomp=1.00 x264 is three times higher than for CRF=37:qcomp=1.00 X265. Is this correct result?

Why it shouldn't? Those are completely different encoders.

Originally Posted by Jamaika

Summary: Codec X265 with the same parameters fell much worse. The colors and sharpness are not the same. The cause is unknown.

Unknown? How about 3x lower bitrate?

[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]

Originally Posted by 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.

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/defa...ion--input-res

[sirt]

Originally Posted by Boulder

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

https://x265.readthedocs.org/en/defa...ion--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]

Originally Posted by x265_Project

--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]

Originally Posted by 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.

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]

Originally Posted by sirt

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