x265 HEVC Encoder

[Magik Mark]

Guys,

I just would like to confirm if I need to turn off cutree if I'll be using and of the ff CLI:

--multi-pass-opt-rps
--multi-pass-opt-analysis
--multi-pass-opt-distortion

[burfadel]

Here's the results of my comparison test. I used pretty much my standard settings for the test, but with SSIM and PSNR stats enabled. I realise that psy-rd etc affects the SSIM and PSNR stats such that they become 'invalid', but I wanted to do a 'real world' encode comparison, not one with settings that I would never use (basically with psy-rd etc turned off). Differences in the motion estimation will affect all things down stream from it, such as AQ, psy-rd etc, by leaving them enabled even though the results are 'inaccurate' it does potentially show how changes in the settings affect these features.

Settings used, apart from the ME, and where applicable the ME range:
--crf 20 --output-depth 10 --rd 4 --tu-intra-depth 4 --tu-inter-depth 4 --rdoq-level 2 --b-intra --limit-modes --aq-mode 2 --nr-intra 400 --nr-inter 400 --ipratio 1.38 --pbratio 1.28 --max-merge 4 --weightb --analyze-src-pics --bframes 6 --rc-lookahead 45 --ref 6 --keyint 600 --psy-rdoq 1.28 --no-sao --qg-size 8 --limit-tu 3 --ssim-rd --psy-rd 2.00 --ssim --psnr

No avisynth filters were used for the comparison apart from the source filter.

HEX

x265 [info]: frame I:     33, Avg QP:17.37  kb/s: 5382.71   PSNR Mean: Y:46.296 U:49.536 V:50.818  SSIM Mean: 0.982813 (17.648dB)
x265 [info]: frame P:    474, Avg QP:19.67  kb/s: 1342.77   PSNR Mean: Y:45.543 U:49.001 V:49.778  SSIM Mean: 0.982113 (17.475dB)
x265 [info]: frame B:   1493, Avg QP:25.19  kb/s: 225.04    PSNR Mean: Y:45.006 U:48.783 V:49.559  SSIM Mean: 0.980893 (17.188dB)
x265 [info]: Weighted P-Frames: Y:1.1% UV:0.0%
x265 [info]: Weighted B-Frames: Y:0.4% UV:0.0%
x265 [info]: consecutive B-frames: 9.7% 0.6% 7.1% 61.5% 10.5% 10.7% 0.0%

encoded 2000 frames in 73.53s (27.20 fps), 575.05 kb/s, Avg QP:23.75, Global PSNR: 46.176, SSIM Mean Y: 0.9812134 (17.262 dB)

STAR

x265 [info]: frame I:     33, Avg QP:17.37  kb/s: 5377.76   PSNR Mean: Y:46.294 U:49.532 V:50.819  SSIM Mean: 0.982812 (17.648dB)
x265 [info]: frame P:    474, Avg QP:19.67  kb/s: 1340.51   PSNR Mean: Y:45.545 U:49.001 V:49.772  SSIM Mean: 0.982131 (17.479dB)
x265 [info]: frame B:   1493, Avg QP:25.19  kb/s: 225.26    PSNR Mean: Y:45.010 U:48.782 V:49.552  SSIM Mean: 0.980912 (17.192dB)
x265 [info]: Weighted P-Frames: Y:1.1% UV:0.0%
x265 [info]: Weighted B-Frames: Y:0.4% UV:0.0%
x265 [info]: consecutive B-frames: 9.7% 0.6% 7.1% 61.5% 10.5% 10.7% 0.0%

encoded 2000 frames in 89.92s (22.24 fps), 574.59 kb/s, Avg QP:23.75, Global PSNR: 46.177, SSIM Mean Y: 0.9812321 (17.266 dB)

STAR24 for interest, me range changed to 24 from default 57

x265 [info]: frame I:     33, Avg QP:17.37  kb/s: 5374.91   PSNR Mean: Y:46.289 U:49.532 V:50.813  SSIM Mean: 0.982800 (17.645dB)
x265 [info]: frame P:    474, Avg QP:19.67  kb/s: 1344.30   PSNR Mean: Y:45.558 U:49.008 V:49.782  SSIM Mean: 0.982175 (17.490dB)
x265 [info]: frame B:   1493, Avg QP:25.20  kb/s: 226.28    PSNR Mean: Y:45.018 U:48.789 V:49.563  SSIM Mean: 0.980951 (17.201dB)
x265 [info]: Weighted P-Frames: Y:1.1% UV:0.0%
x265 [info]: Weighted B-Frames: Y:0.4% UV:0.0%
x265 [info]: consecutive B-frames: 9.7% 0.6% 7.1% 61.5% 10.5% 10.7% 0.0%

encoded 2000 frames in 76.64s (26.09 fps), 576.20 kb/s, Avg QP:23.76, Global PSNR: 46.186, SSIM Mean Y: 0.9812714 (17.275 dB)

STAR35 as above, but 35

x265 [info]: frame I:     33, Avg QP:17.37  kb/s: 5380.92   PSNR Mean: Y:46.297 U:49.528 V:50.828  SSIM Mean: 0.982821 (17.650dB)
x265 [info]: frame P:    474, Avg QP:19.67  kb/s: 1343.05   PSNR Mean: Y:45.550 U:48.998 V:49.775  SSIM Mean: 0.982151 (17.484dB)
x265 [info]: frame B:   1493, Avg QP:25.20  kb/s: 225.62    PSNR Mean: Y:45.014 U:48.781 V:49.559  SSIM Mean: 0.980931 (17.197dB)
x265 [info]: Weighted P-Frames: Y:1.1% UV:0.0%
x265 [info]: Weighted B-Frames: Y:0.4% UV:0.0%
x265 [info]: consecutive B-frames: 9.7% 0.6% 7.1% 61.5% 10.5% 10.7% 0.0%

encoded 2000 frames in 82.48s (24.25 fps), 575.52 kb/s, Avg QP:23.76, Global PSNR: 46.181, SSIM Mean Y: 0.9812514 (17.270 dB)

UMH

x265 [info]: frame I:     33, Avg QP:17.37  kb/s: 5374.79   PSNR Mean: Y:46.290 U:49.529 V:50.821  SSIM Mean: 0.982806 (17.646dB)
x265 [info]: frame P:    474, Avg QP:19.67  kb/s: 1341.79   PSNR Mean: Y:45.541 U:48.998 V:49.775  SSIM Mean: 0.982107 (17.473dB)
x265 [info]: frame B:   1493, Avg QP:25.19  kb/s: 224.90    PSNR Mean: Y:45.007 U:48.781 V:49.558  SSIM Mean: 0.980894 (17.188dB)
x265 [info]: Weighted P-Frames: Y:1.1% UV:0.0%
x265 [info]: Weighted B-Frames: Y:0.4% UV:0.0%
x265 [info]: consecutive B-frames: 9.7% 0.6% 7.1% 61.5% 10.5% 10.7% 0.0%

encoded 2000 frames in 100.11s (19.98 fps), 574.58 kb/s, Avg QP:23.75, Global PSNR: 46.175, SSIM Mean Y: 0.9812131 (17.261 dB)

SEA

x265 [info]: frame I:     33, Avg QP:17.37  kb/s: 5378.57   PSNR Mean: Y:46.289 U:49.529 V:50.817  SSIM Mean: 0.982796 (17.644dB)
x265 [info]: frame P:    474, Avg QP:19.67  kb/s: 1341.23   PSNR Mean: Y:45.539 U:49.005 V:49.779  SSIM Mean: 0.982106 (17.473dB)
x265 [info]: frame B:   1493, Avg QP:25.19  kb/s: 224.58    PSNR Mean: Y:45.005 U:48.785 V:49.561  SSIM Mean: 0.980891 (17.188dB)
x265 [info]: Weighted P-Frames: Y:1.1% UV:0.0%
x265 [info]: Weighted B-Frames: Y:0.4% UV:0.0%
x265 [info]: consecutive B-frames: 9.7% 0.6% 7.1% 61.5% 10.5% 10.7% 0.0%

encoded 2000 frames in 245.39s (8.15 fps), 574.27 kb/s, Avg QP:23.75, Global PSNR: 46.175, SSIM Mean Y: 0.9812103 (17.261 dB)

SEA was by far the slowest and also had the lowest rated stats. HEX was the fastest, followed by STAR (and of the ME range settings), and UMH.

I thought I'd throw in STAR with different ME ranges to show the difference in speed versus the quality output. I wasn't expecting the lower the ME range the higher the PSNR and SSIM, but there is also a slight increase in bitrate so it make sense. The results for fast motion scenes may be different, and higher resolutions a higher ME range is more important. The video encoded was 712x480, encoding to 2160 the same motion has to travel across significantly more pixels which I would assume would necessitate a higher ME range setting for the same detection.

The weight p and b frames are usually different to those from the clip. I guess it depends on what is in the clip. A full encode is like this (from an full encode):
x265 [info]: Weighted P-Frames: Y:6.4% UV:4.0%
x265 [info]: Weighted B-Frames: Y:4.9% UV:2.5%

Of course, with the figures being different in each encode.

[aymanalz]

Originally Posted by Selur

you could simply enable 'x265->Misc->Metrics->PSNR' and 'x265->Misc->Metrics->SSIM' (or add the options under 'x265->Misc->Custom command line addition') both work fine here, if it doesn't for you create a proper bug report inside the Hybrid thread,...

I'm getting values reported when I tick those options.

I'll run tests with those checked and report back.

[mandarinka]

Seems that next-gen HEVC has been researched for some time: https://forum.doom9.org/showthread.php?t=174245
I wonder if this time, it'll be viable to extend x265 to support the new format instead of starting from scratch (or from the reference encoder), or if the differences will be too big again.

[Barough]

x265 v2.2+23-58dddcf01b7d (MSYS/MinGW, GCC 6.3.0, 32 & 64bit 8/10/12bit multilib EXEs)

[Motenai Yoda]

Originally Posted by burfadel

I wanted to do a 'real world' encode comparison, not one with settings that I would never use (basically with psy-rd etc turned off).
[...]
Settings used, [...] --ssim-rd

but doesn't ssim-rd disable psy-rd?
also as it is still an experimental feature I'd not use it in a real encode.

nr-intra & nr-inter 400 ? + qg-size 8??

also I suspect analyze-src-pics can do something on how metrics are computed...

[davidsama]

This is the AVX2 build

[burfadel]

Originally Posted by Motenai Yoda

but doesn't ssim-rd disable psy-rd?
also as it is still an experimental feature I'd not use it in a real encode.

nr-intra & nr-inter 400 ? + qg-size 8??

also I suspect analyze-src-pics can do something on how metrics are computed...

ssim-rd does disable psy-rd, it does this by using a default of 0.00, at least during testing. If you specify it manually*you can still use it. I use 400 for nr*as it isn't really noticeable but saves bitrate. I can therefore use a lower CRF*so the result is higher quality output.

[greenfountain]

Originally Posted by burfadel

SEA was by far the slowest and also had the lowest rated stats. HEX was the fastest, followed by STAR (and of the ME range settings), and UMH.

I thought I'd throw in STAR with different ME ranges to show the difference in speed versus the quality output. I wasn't expecting the lower the ME range the higher the PSNR and SSIM, but there is also a slight increase in bitrate so it make sense. The results for fast motion scenes may be different, and higher resolutions a higher ME range is more important. The video encoded was 712x480, encoding to 2160 the same motion has to travel across significantly more pixels which I would assume would necessitate a higher ME range setting for the same detection.

The weight p and b frames are usually different to those from the clip. I guess it depends on what is in the clip. A full encode is like this (from an full encode):
x265 [info]: Weighted P-Frames: Y:6.4% UV:4.0%
x265 [info]: Weighted B-Frames: Y:4.9% UV:2.5%

Of course, with the figures being different in each encode.

Thanks for making that comparison burfadel. Actually the focus of SEA is to make FULL faster but we cannot expect it to be faster than other motion search algorithms like HEX/STAR.

[Midzuki]

x265 2.2+25-3737c70c3308

add support for aq-motion even when aq-mode is disabled

http://www.mediafire.com/file/4npram...737c70c3308.7z

[jlpsvk]

is it a bug? when I set --high-tier but not --level-idc, it still encodes in main tier...

[x265_Project]

Originally Posted by mandarinka

Seems that next-gen HEVC has been researched for some time: https://forum.doom9.org/showthread.php?t=174245
I wonder if this time, it'll be viable to extend x265 to support the new format instead of starting from scratch (or from the reference encoder), or if the differences will be too big again.

Anything is possible with enough time, money and motivation. The question of whether to start with the reference or with x265 depends on your software development philosophy. We like to use an agile software development methodology, which stresses the need to always have a stable build that works. With a new coding standard, the reference encoder gives you a stable build that works (can encode valid bitstreams for that standard). So we would likely start there, and then slowly replace every piece of the reference encoder with our own code, just as we did with x265.

[Midzuki]

x265.exe 2.2+26-d1f6d9b8d6be

Add filler bits when frame bits < vbv target in strict-cbr

http://www.mediafire.com/file/j1ouck...1f6d9b8d6be.7z

[cojj]

Originally Posted by jlpsvk

is it a bug? when I set --high-tier but not --level-idc, it still encodes in main tier...

According to the documentation:
"high-tier allows the support of high tier at that level. The encoder will first attempt to encode at the specified level, main tier first, turning on high tier only if necessary and available at that level."

Pretty self-explanatory => even if you set the flag, it will attempt main tier first and only use high-tier if necessary.

[burfadel]

Originally Posted by greenfountain

Thanks for making that comparison burfadel. Actually the focus of SEA is to make FULL faster but we cannot expect it to be faster than other motion search algorithms like HEX/STAR.

That makes sense .*STAR seems the most efficient,*it would be interesting to know whether it could be improved further.

[LigH]

x265 2.2+29-2f075fe8d4c5

   --complex-analysis <0..4.0>   Strength of complex analysis, 0 to disable. Default 0.0

Increases the RD-level at points where the bitrate drops due to vbv. The number of CUs for which the RD is reconfigured is determined based on the strength. Strength 1 gives the best FPS, strength 4 gives the best SSIM. Strength 0 switches this feature off. Default: 0.

Effective for RD levels 4 and below.

A developers' functionality test runs with strength 1.53, FYI.

[burfadel]

Originally Posted by LigH

x265 2.2+29-2f075fe8d4c5

   --complex-analysis <0..4.0>   Strength of complex analysis, 0 to disable. Default 0.0

A developers' functionality test runs with strength 1.53, FYI.

You need to update your build, looks like the patches were resubmitted due to bugs and your build uses the old patches.

I also guess that for non restricted VBV like normal encoding with ABR, the function serves little use. I wonder whether it could be adopted to apply based on complexity rather than stating actual numbers, which would vary from encode to encode. For instance, a particular video might have scenes where there is low complexity, and there is plentiful use of P and B frames. There could be points in the video where the complexity increases such that fewer P and B frame could be utilised, resulting in a higher bitrate. When this occurs a higher complex-analysis seting can be used, 0.5 (variable strength) could be used there and scales upwards further with higher complexity. The setting would therefore be the scaling rate, such that a lower setting would be more constrained in the scaling, and not a fixed rate, based on perceived complexity of the current run of frames. This would make it useful for normal use and not a per-encode use that is required with the existing code due to stating VBV limitations that varies with content, complexity, and resolution.

I realise this isn't the purpose of it spefically, it's just an interesting concept that could be repurposed. Just an idea .

[LigH]

How do I? TortoiseHg Workbench does not report any changes since. The commit log on bitbucket neither.

[burfadel]

Probably not committed to the development branch yet, patches are here:

https://patches.videolan.org/project/x265-devel/list/

[x265_Project]

Originally Posted by burfadel

You need to update your build, looks like the patches were resubmitted due to bugs and your build uses the old patches.

I also guess that for non restricted VBV like normal encoding with ABR, the function serves little use. I wonder whether it could be adopted to apply based on complexity rather than stating actual numbers, which would vary from encode to encode. For instance, a particular video might have scenes where there is low complexity, and there is plentiful use of P and B frames. There could be points in the video where the complexity increases such that fewer P and B frame could be utilised, resulting in a higher bitrate. When this occurs a higher complex-analysis seting can be used, 0.5 (variable strength) could be used there and scales upwards further with higher complexity. The setting would therefore be the scaling rate, such that a lower setting would be more constrained in the scaling, and not a fixed rate, based on perceived complexity of the current run of frames. This would make it useful for normal use and not a per-encode use that is required with the existing code due to stating VBV limitations that varies with content, complexity, and resolution.

I realise this isn't the purpose of it spefically, it's just an interesting concept that could be repurposed. Just an idea .

Sure, we can extend this technique to wider applications. This initial function was developed for those who use "capped VBR" rate control (CRF, with VBV). In this scenario, quality is constant until you reach a place where VBV kicks in to enforce decoder parameters. In these places, quality will take a dip. To counteract that, we allow x265 to dynamically increase encoding efficiency in these areas (similar to using a slower, higher quality performance preset). But yes, the concept could be extended to general ABR or CRF encoding.