x265 HEVC Encoder

[jlpsvk]

psy-rd is beneficial and is not related to intra smoothing. I find a value of 3.5 to be "optimal"

interesting....with --psy-rd 3.5 the encode is actualy about 1fps faster...wonder why...

[LigH]

1 fps faster than ... 2 fps or 20 fps without? Please get used to percentages.

[qtwigg]

ME's 3, 4, and 5 compared.

Commands used:
--crf 22 --preset slow --tune ssim --profile main10 --output-depth 10 --min-cu-size 16 --ctu 32 --no-strong-intra-smoothing --no-constrained-intra --ssim

Star

encoded 4329 frames in 1138.22s (3.80 fps), 4239.98 kb/s, Avg QP:26.59, SSIM Mean Y: 0.9778734 (16.551 dB)

Start: 8:13:58 PM
End: 8:32:57 PM
Duration: 00:18:58

HEVC : 91.3 MiB 1920*1080 (16:9), at 23.976 (24000/1001) FPS, HEVC (Main 10@L4@Main)

SEA

encoded 4329 frames in 3069.85s (1.41 fps), 4236.64 kb/s, Avg QP:26.58, SSIM Mean Y: 0.9778637 (16.549 dB)

Start: 2:55:52 PM
End: 3:47:03 PM
Duration: 00:51:10

HEVC : 91.2 MiB 1920*1080 (16:9), at 23.976 (24000/1001) FPS, HEVC (Main 10@L4@Main)

Full

encoded 4329 frames in 15629.88s (0.28 fps), 4237.87 kb/s, Avg QP:26.59, SSIM Mean Y: 0.9778782 (16.552 dB)

Start: 3:51:22 PM
End: 8:11:53 PM
Duration: 04:20:30

HEVC : 91.2 MiB 1920*1080 (16:9), at 23.976 (24000/1001) FPS, HEVC (Main 10@L4@Main)

Sample Clips
Star - https://mega.nz/#!t8tAVIxB!ymjIIy21Ul2fgxJWc3SyXQATQs1I9ZO_4JS1U2P1ZwM
SEA - https://mega.nz/#!og80HBia!gpV7atvaBIJeg9gVcVh23-qq1M7AAbHZANPw7dFV2TU
Full - https://mega.nz/#!J48T3YaR!QSm3uVZTNiVT3KcvGLbBMiDJICalmBPWwl3ZbnxCLaU

Not worth it. In all scenarios for best results/encoding times, continue use me star on. Thanks.

[jlpsvk]

1 fps faster than ... 2 fps or 20 fps without? Please get used to percentages.

--crf 20 --output-depth 10 --preset slow --rd 6 --tu-intra-depth 4 --tu-inter-depth 4 --amp --qpstep 8 --bframes 8 --rc-lookahead 60 --min-keyint 24 --keyint 240 --no-open-gop --colorprim bt709
--colormatrix bt709 --transfer bt709 --deblock -3:-3 --psy-rdoq 10 --no-sao --high-tier --qg-size 8 --aq-motion --rd-refine --ssim-rd --aq-mode 3 --no-strong-intra-smoothing

This command gives me about 3.9fps encode speed. With --psy-rd 3.5 it's about 1fps faster. :) So about 20-25% faster. Don't really know why. :)

[littlepox]

ME's 3, 4, and 5 compared.

Commands used:
--crf 22 --preset slow --tune ssim --profile main10 --output-depth 10 --min-cu-size 16 --ctu 32 --no-strong-intra-smoothing --no-constrained-intra --ssim

Star

encoded 4329 frames in 1138.22s (3.80 fps), 4239.98 kb/s, Avg QP:26.59, SSIM Mean Y: 0.9778734 (16.551 dB)

Start: 8:13:58 PM
End: 8:32:57 PM
Duration: 00:18:58



HEVC : 91.3 MiB 1920*1080 (16:9), at 23.976 (24000/1001) FPS, HEVC (Main 10@L4@Main)

SEA

encoded 4329 frames in 3069.85s (1.41 fps), 4236.64 kb/s, Avg QP:26.58, SSIM Mean Y: 0.9778637 (16.549 dB)

Start: 2:55:52 PM
End: 3:47:03 PM
Duration: 00:51:10

HEVC : 91.2 MiB 1920*1080 (16:9), at 23.976 (24000/1001) FPS, HEVC (Main 10@L4@Main)

Full

encoded 4329 frames in 15629.88s (0.28 fps), 4237.87 kb/s, Avg QP:26.59, SSIM Mean Y: 0.9778782 (16.552 dB)

Start: 3:51:22 PM
End: 8:11:53 PM
Duration: 04:20:30

HEVC : 91.2 MiB 1920*1080 (16:9), at 23.976 (24000/1001) FPS, HEVC (Main 10@L4@Main)

Sample Clips
Star - https://mega.nz/#!t8tAVIxB!ymjIIy21Ul2fgxJWc3SyXQATQs1I9ZO_4JS1U2P1ZwM
SEA - https://mega.nz/#!og80HBia!gpV7atvaBIJeg9gVcVh23-qq1M7AAbHZANPw7dFV2TU
Full - https://mega.nz/#!J48T3YaR!QSm3uVZTNiVT3KcvGLbBMiDJICalmBPWwl3ZbnxCLaU

Not worth it. In all scenarios for best results/encoding times, continue use me star on. Thanks.


impressive, would you please add the comparison for umh?

[burfadel]

I found the same thing. I'm currently encoding so won't do another comparison, but from the testing I did a while back STAR was beneficial over UMH in quality and the speed difference was very minimal. You almost get Full search quality at an encode speed similar to UMH. In theory you would expect SEA to be better than STAR. I also did some tests comparing the subpel refinement. Basically for the clip tested 2 was the ideal choice.

Level of RDO is an area for improvement I think. I use 4 because it has a good speed/quality tradeoff (yes I know 4 is basically the same as 3 currently). RD level 5 produces nice results but there is a massive performance hit. Combine --rd 5 with --rd-refine and --opt-cu-delta-qp and it produces a nice result. --rd-refine and --opt-cu-delta-qp are only available in RD 5 and 6.

I'm assuming it's possible to shortcut the extra calculations in --rd 5 as has been done with TU intra and enabled with --limit-tu 3 (for example), and like with --limit-modes and using --amp (which then has a negligible performance impact). I think if something along those lines could be done with --rd 5 and made the new -rd 4, it would be great. Likewise, using --rd-refine and --opt-cu-delta-qp as default options in this mode. The --rd-refine I'm assuming could also be shortcut (and use the shortcut from the rd level). By shortcut I mean like --limit-modes, --limit-refs etc.

I believe this new --rd 4 level if it could be achieved with minimal performance penalty over --rd 3 would be great!

Also a much more mild Sample Adaptive Offset loop filter would be good because currently (as discussed previously by others and myself) it loses detail with no real benefit. I can see in theory it should be better to have enabled, I think having it at a strength of say, 30 percent of what it currently is would be good. Hey, why not give the option to specify a strength, with 1.0 being the current strength and 0.3 (or whatever is found to be the most subjectively appealing) being the default strength?

Another idea is --strong-intra-smoothing. The help states 'This flag performs bi-linear interpolation of the corner reference samples for a strong smoothing effect.'. How about bicubic interpolation?

[Winston_Smith_101]

Can we expect some large steps in terms of x265 encoding quality in general and necessary bitrate for a given visual quality in the coming months? I ask because I have a lot of material to encode and would like to choose a good moment for that. :) Is there an overview of the improvements in the x265 codec in form of a graph or a chart? With build "a" bitrate "xxxx" was required to reach quality level "q"... and so on?

[LigH]

How do you measure visual quality?

[jlpsvk]

anybody can explain, why the same command with psy-rd is 20% faster the the same without psy-rd?

[sneaker_ger]

How much did the bitrate in your encode change? Entropy coding could be a factor.

[jlpsvk]

about 1mbit/s more (from 3100 to 4100kbps - so about 33% more...with CRF20. with CRF21 i am back at CRF20 bitrate without psy-rd...but image is better i think...can post screenshots) with --psy-rd 3.5. clean BD source without grain (miss peregrin's home for peculiar children).

[WhatZit]

Can we expect some large steps in terms of x265 encoding quality in general and necessary bitrate for a given visual quality in the coming months?

http://x265.readthedocs.io/en/default/releasenotes.html

Stable releases come, on average, every 6 months. Every one brings some sort of "quality" improvement, especially v2.0. If you don't like x265's output now, wait 6 months.

I ask because I have a lot of material to encode and would like to choose a good moment for that.

Using the absolute latest x265 build, run some short test encodes of different sources at a simple baseline of CRF20, Preset Medium, Profile Main10, Tune Grain and see what you get.

Don't like the quality? Try CRF19 Preset Slow.

Don't like the size? Try CRF21 Preset Fast.

Don't like any of it? Wait 6 months.

Only YOU can decide what you want.

[jlpsvk]

Any reason to be PSY-RD by default 0.0?

[x265_Project]

http://x265.readthedocs.io/en/default/releasenotes.html

Stable releases come, on average, every 6 months.

We're on our 22nd release in about 44 months. We've been slower to tag new versions in the last 2 years, but we are striving to get back to a new version every 2 months.

[jlpsvk]

Can anybody explain please? According to x265 online documentation, psy-rd is 2.0 by default.

But with:
--output-depth 10 --preset slow --rd 6 --tu-intra-depth 4 --tu-inter-depth 4 --amp --qpstep 8 --bframes 8 --rc-lookahead 60 --min-keyint 24 --keyint 240 --no-open-gop --colorprim bt709
--colormatrix bt709 --transfer bt709 --deblock -3:-3 --psy-rdoq 10 --no-sao --high-tier --qg-size 8 --aq-motion --rd-refine --ssim-rd --aq-mode 3 --no-strong-intra-smoothing

I am getting psy-rd=0.0 in MediaInfo....

Writing library : x265 2.2+22-20217c8af8ac:[Windows][GCC 6.2.0][64 bit] 10bit
Encoding settings : cpuid=1173503 / frame-threads=3 / numa-pools=8 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=1920x1024 /
interlace=0 / total-frames=1429 / level-idc=0 / high-tier=1 / uhd-bd=0 / ref=4 / no-allow-non-conformance / no-repeat-headers / annexb / no-aud / no-hrd / info / hash=0 / no-temporal-layers
/ no-open-gop / min-keyint=24 / keyint=240 / bframes=8 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=60 / lookahead-slices=4 / scenecut=40 / no-intra-refresh / ctu=64
/ min-cu-size=8 / rect / amp / max-tu-size=32 / tu-inter-depth=4 / tu-intra-depth=4 / limit-tu=0 / rdoq-level=2 / signhide / no-tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra
/ no-strong-intra-smoothing / max-merge=3 / limit-refs=3 / limit-modes / me=3 / subme=3 / merange=57 / temporal-mvp / weightp / no-weightb / no-analyze-src-pics / deblock=-3:-3 / no-sao
/ no-sao-non-deblock / rd=6 / no-early-skip / rskip / no-fast-intra / no-tskip-fast / no-cu-lossless / no-b-intra / rdpenalty=0 / psy-rd=0.00 / psy-rdoq=10.00 / rd-refine / analysis-mode=0
/ no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=crf / crf=20.0 / qcomp=0.60 / qpstep=8 / stats-write=0 / stats-read=0 / ipratio=1.40 / pbratio=1.30 / aq-mode=3 / aq-strength=1.00 / cutree /
zone-count=0 / no-strict-cbr / qg-size=8 / no-rc-grain / qpmax=69 / qpmin=0 / sar=1 / overscan=0 / videoformat=5 / range=0 / colorprim=1 / transfer=1 / colormatrix=1 / chromaloc=0 /
display-window=0 / max-cll=0,0 / min-luma=0 / max-luma=1023 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / slices=1 / opt-qp-pps / opt-ref-list-length-pps / no-multi-pass-opt-rps
/ scenecut-bias=0.05 / no-opt-cu-delta-qp / aq-motion

[LigH]

No certain explanation, just a guess ... the "encoding settings" are a plain text string. So the reason is most probably either in a wrong assignment of a default value, or a wrong conversion of the current float value to the text contained in this string. If it appears correctly when you add a custom value for this parameter, then it is probably a mistake in the defaults for the specific preset(s). Or it is overridden by a following parameter.

[jlpsvk]

When I was testing --psy-rd 3.5, it appears correctly.

[nevcairiel]

--ssim-rd sets --psy-rd to 0.0

[burfadel]

Forget my post if you already read it, I just remembered what nevcairiel said. For now it is disabled with --ssim-rd whilst an experimental feature, but at least you can set it manually!

[aymanalz]

ME's 3, 4, and 5 compared.

...

Not worth it. In all scenarios for best results/encoding times, continue use me star on. Thanks.

To second another person above's request, could you please try ME 2 (umh) and add the results to the comparison?

[aymanalz]

^^ To answer my own request, I did encodes using the same settings that @qtwigg did, and here are the results:

UMH:

Final size: 87.433 MB
Bitrate: 6419.42 kb/s
Avg QP:26.42
FPS: 2.36

STAR:

Final size: 87.491 MB
Bitrate: 6423.67 kb/s
Avg QP:26.42
FPS: 3.34

SEA:

Final size: 87.5992 MB
Bitrate: 6431.62 kb/s
Avg QP:26.41
FPS: 0.72

Did not do Full.

Is there a GUI tool that can measure SSIM for clips encoded with 10 bit x265? I'd like to add that info as well. Visually, I can't tell the difference between any of the above.

[littlepox]

looks like star is still the best way to go.

[Motenai Yoda]

Is there a GUI tool that can measure SSIM for clips encoded with 10 bit x265? I'd like to add that info as well. Visually, I can't tell the difference between any of the above.
--ssim --psnr to x265 command line

[ChaosKing]

I get some kind of strange banding with the latest x265 version.
input/output is 10bit. It is a high motion scene and the difference in bitrate/filesize is about 16% (the x265 encode is smaller)
But this "banding" appears also (less visible) in static scenes where is no movement.

Is there something to reduce the "banding"?

x265 2.2+22-20217c8af8ac:[Windows][GCC 6.3.0][64 bit] 10bit
--crf 18 --no-strong-intra-smoothing --rd 6 --rd-refine --psy-rd 2.6 --aq-motion --me star --psy-rdoq 2 --opt-cu-delta-qp --tu-inter-depth 4 --tu-intra-depth 4 --preset veryslow --output-depth 10 --deblock -3:-3 --qpstep 6 --min-keyint 1 --ref 6 --bframes 12 --subme 5 --limit-refs 3 --aq-mode 3 --aq-strength 0.8 --ctu 64 --min-cu-size 8 --rect --amp

http://i.imgur.com/gL8hyOV.png






It's also visible with --medium, but also very blurry compared to the x264 version on the left.

--crf 18 --preset medium --output-depth 10 --input-depth 10
http://i.imgur.com/HkxjvjX.png

[LigH]

These images are huge. Please try to link them via thumbnails, or URLs only...

If this issue appears suddenly, from a specific version on, it may be a regression or a newly introduced bug to be investigated.

But your command line is a bit nonsensical. First of all, if you start with simple parameters, and then use a preset meta-parameter in the middle, this will probably override several previous simple parameters with preset defaults. Furthermore, why so many, do you need a preset at all if you define more or less every single option? And their relation to each other and the video content ... you mostly disable smoothing to retain details – for anime content?! That's paradox.

In this case, your nickname is quite matching ... :sly:

[ChaosKing]

Yes some are redundant bcs I started without the preset parameter. :D
I'm still testing out different parameters.
Not all animes look like cartoons and x265 tends to smooth the image/details.

I will test out an older version and report back.

[sneaker_ger]

I have seen this kind of banding happen for a long time. Sometimes it looks like an oil painting. Don't know any solution, unfortunately.

[Leo 69]

@ChaosKing --can you give me a link to the source via PM or provide a link to a problematic sequence? I'd like to test it with my settings, since I don't see much added banding in my own encodes even at higher CRF.

[ChaosKing]

I tested with some older build 2.2+7 & 2.1+74, but I can see banding artefacts here too. I used just the --preset veryslow paramter (10bit) & then slightly increased rsy-rd and rdoq.
It seems that the higher rd-psy/rdoq is set, the sharper the image looks and the more banding is visible. (But it was just a quick test, will make furher tests with different scenes)

@Leo 69 I've send you a pm.

[LigH]

Sounds rather credible to me... psychovisual RD enhancements were described as taking energy from some areas with higher energy (edges and other details) and distributing it to the surrounding areas with lower energy (little detail). For cartoons, this would probably mean to take the energy from the edges of black lines and distribute it into the flat color areas. So they get undesired stripes in the same direction as close black lines.

As useful as a feature may be for natural video content, as inadequate it may turn out for artifical content. There is never one perfect set of parameters for all video content.

[littlepox]

Even worse, those worm-like colour bandings are encouraged by high psy values coz they are considered with "high visual complexity"

[LigH]

I believe that cartoons should prefer rather higher than lower deblocking parameters, and rather enabled smoothing. But that will have to be tested. There is no "animation tuning" yet. But I believe there have been proposals already...?

[ChaosKing]

I did some more testing, but still have some banding in my encodes.

x264 bitrate ~6000 kb/s
--preset veryslow --crf 18 --psy-rd 0.7 --aq-mode 3

x265 bitrate ~5750 kb/s
--preset veryslow --crf 15 --psy-rd 0.5 --aq-mode 3

result:
http://i.imgur.com/AyO8lHu.png



I also tried ssim-rd, 5777kb/s
--preset veryslow --crf 15.5 --rd 6 --ssim-rd --aq-mode 3
http://i.imgur.com/D1bJDGb.png

with more contrast for whose with bad monitors :D
http://i.imgur.com/dH4c99b.png
(http://i.imgur.com/dH4c99b.png)
@LigH From that I read in all the threads and forums -> use -1,-2 or -3 deblocking and higher psy values, so that the image will remain sharp similar to x264 encodes. (also for animes)

[microchip8]

ChaosKing,

I think you are obsessing at this point. These are barely visible. Do you watch your anime frame by frame or do you sit back and enjoy?

[ChaosKing]

No I'm not obsessed. I just want to show which "problems" I found so maybe the devs can look into it and hopefully fix or improve it.
I just find it a bit strange what a bit higher psy/rdoq values causes visible worm/banding like artifacts. ok, perhaps the paramter is also just very sensitive, but I just think there is room for improvement.

Maybe it is not that much visible on your screen, but on my Dell U2515H (factory calibrated) I can clearly see them. Of course much less than in my first encode with higher psy settings.

The thing is I was so happy with the quality at first, because it looked very good and the image was not blurry at all, like in my previous encode (compared to x264). But after watching some minutes I saw weird looking edges and color gradients ...

[Leo 69]

ChaosKing,

I think you are obsessing at this point. These are barely visible. Do you watch your anime frame by frame or do you sit back and enjoy?

HEVC has to be on par in visual quality with AVC, requiring less bitrate. That's, I assume, what development team is working on.

Your point is ridiculous.

[aymanalz]

--ssim --psnr to x265 command line

I added that, where can I see the result? The program "Hybrid"'s log file does not give that info.

Sorry if the question is noobish.

[microchip8]

No I'm not obsessed. I just want to show which "problems" I found so maybe the devs can look into it and hopefully fix or improve it.
I just find it a bit strange what a bit higher psy/rdoq values causes visible worm/banding like artifacts. ok, perhaps the paramter is also just very sensitive, but I just think there is room for improvement.

Maybe it is not that much visible on your screen, but on my Dell U2515H (factory calibrated) I can clearly see them. Of course much less than in my first encode with higher psy settings.

The thing is I was so happy with the quality at first, because it looked very good and the image was not blurry at all, like in my previous encode (compared to x264). But after watching some minutes I saw weird looking edges and color gradients ...

Report the problem to the x265 bug tracker, then. x265 devs don't fully follow everything in here

[Selur]

The program "Hybrid"'s log file does not give that info.
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,...

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

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 (http://ge.tt/50BOQTi2) (MSYS/MinGW, GCC 6.3.0, 32 & 64bit 8/10/12bit multilib EXEs)

[Motenai Yoda]

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 (https://tinyvpn.net/d/6/e/d6ed65b615780e5de03008921986e600.7z)

[burfadel]

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]

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/4npramvjya92aj4/x265_2.2+25-3737c70c3308.7z

[jlpsvk]

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