x265 HEVC Encoder

Originally Posted by x265_Project

If x265 fails it should fail gracefully, with an error message explaining why it couldn't complete the encode.

Starting with https://media.xiph.org/video/derf/y4m/flower_cif.y4m... scale to 32x32 with FFMPEG...

ffmpeg -s 352x288 -r 25.0 -pix_fmt yuv420p -i flower_cif_352x288.yuv -vf scale=32:32 flower_cif_32x32.yuv

x265 fails gracefully if you use default settings...

C:\Testx265>x265 --input v:\Sequences\flower_cif_32x32.yuv --input-res 32x32 --fps 30 -o 32x32.hevc
yuv  [info]: 32x32 fps 30000/1000 i420p8 frames 0 - 249 of 250
x265 [info]: HEVC encoder version 1.2+54-e3e077965c39
x265 [info]: build info [Windows][MSVC 1700][64 bit] 8bpp
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZ CNT BMI2
x265 [error]: Picture size must be at least one CTU
x265 [error]: failed to open encoder

Encoding hangs with --ctu 32
I was able to reproduce the crash with --ctu 32 --threads 1 (thanks for reporting... we'll find and fix both of the above).

Encoding is successful with --ctu 16

C:\Testx265>x265 --input v:\Sequences\flower_cif_32x32.yuv --input-res 32x32  --
ctu 16 --fps 30 -o 32x32.hevc
yuv  [info]: 32x32 fps 30000/1000 i420p8 frames 0 - 249 of 250
x265 [info]: HEVC encoder version 1.2+54-e3e077965c39
x265 [info]: build info [Windows][MSVC 1700][64 bit] 8bpp
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZ CNT BMI2
x265 [info]: WPP streams / pool / frames         : 2 / 8 / 3
x265 [info]: Main profile, Level-1 (Main tier)
x265 [info]: CU size                             : 16
x265 [info]: Max RQT depth inter / intra         : 1 / 1
x265 [info]: ME / range / subpel / merge         : hex / 57 / 2 / 2
x265 [info]: Keyframe min / max / scenecut       : 25 / 250 / 40
x265 [info]: Lookahead / bframes / badapt        : 20 / 4 / 2
x265 [info]: b-pyramid / weightp / weightb / refs: 1 / 1 / 0 / 3
x265 [info]: Rate Control / AQ-Strength / CUTree : CRF-28.0 / 1.0 / 1
x265 [info]: tools: rd=3 lft sao-lcu signhide

x265 [info]: frame I:      1, Avg QP:35.75  kb/s: 60.72
x265 [info]: frame P:     86, Avg QP:36.65  kb/s: 19.43
x265 [info]: frame B:    163, Avg QP:44.70  kb/s: 3.73
x265 [info]: global :    250, Avg QP:41.89  kb/s: 9.36
x265 [info]: Weighted P-Frames: Y:1.2% UV:0.0%
x265 [info]: consecutive B-frames: 29.9% 9.2% 5.7% 54.0% 1.1%

encoded 250 frames in 0.07s (3846.15 fps), 9.36 kb/s

A new speed record for HEVC encoding! I'm going to put out a press release now.

[a5180007]

Originally Posted by x265_Project

A 32x32 video? Is this a real use-case? What are you trying to encode, animated icons

Hi Tom,

Yeah, something like that Seriously, I was playing with 64x64 and 32x32 single frame yuv for Visual Studio step-by-step tracing purpose -to reduce number of encoded CTUs, and understand the process better. I agree this is not a likely situation for HEVC, but I also agree all cases should be considered for robustness.

And who knows, this Schrödinbug might help in solving the Heisenbugs
Note that --threads >1 case should hang only for 0xFFFFFFFF mseconds, but I didn't have the patience to wait and see what would happen next...


EDIT : the encoding parameters are now in the SEI, thanks for this, very useful.

x265 (build 26) - 1.2+81-454a2fc37fee:[Windows][MSVC 1800][32 bit] 8bpp - H.265/HEVC codec - Copyright 2013-2014 (c)
Multicoreware Inc - http://x265.org - options: 32x32 fps=25000/1000 bitdepth=8 wpp ctu=16 tu-intra-depth=1 tu-inter-depth=1 me=1
subme=2 merange=57 no-rect no-amp max-merge=2 no-early-skip no-fast-cbf rdpenalty=0 no-tskip no-tskip-fast strong-intra-smoothing
no-lossless no-cu-lossless no-constrained-intra open-gop interlace=0 keyint=250 min-keyint=25 scenecut=40 rc-lookahead=20 bframes=4
bframe-bias=0 b-adapt=2 ref=3 weightp no-weightb aq-mode=2 aq-strength=1.00 cbqpoffs=0 crqpoffs=0 rd=3 signhide lft sao
sao-lcu-bounds=0 sao-lcu-opt=1 b-pyramid cutree rc=crf crf=28.0 qcomp=0.60 qpmin=0 qpmax=51 qpstep=4 ipratio=1.40 pbratio=1.30

But the build is still shown as build 26 -which I understand is the default build only in the case the cloning has not been made with Mercurial.
Shouldn't this be changed to the changeset revision number (in this case 7329)?

Also, it does not show the number of detected threads, which is important for reproducibility.

[LigH]

Despite a few compiler warnings, I uploaded x265 v1.2+82-6055baa75085 as another merge-with-stable release.

[upyzl]

waiting for MediaInfo to support the new SEI

Originally Posted by a5180007

But the build is still shown as build 26 -which I understand is the default build only in the case the cloning has not been made with Mercurial.
Shouldn't this be changed to the changeset revision number (in this case 7329)?

maybe that's similar as x264 core number, not total rev number?

Originally Posted by a5180007

Also, it does not show the number of detected threads, which is important for reproducibility.

agreed

[Kurtnoise]

Originally Posted by a5180007

But the build is still shown as build 26 -which I understand is the default build only in the case the cloning has not been made with Mercurial.
Shouldn't this be changed to the changeset revision number (in this case 7329)?

The number here corresponds to the current API version, not the hash from the repository...

[a5180007]

Originally Posted by Kurtnoise

The number here corresponds to the current API version, not the hash from the repository...

Indeed, it makes sense! Thanks Kurtnoise.

[Sagittaire]

Originally Posted by a5180007

Park Joy CRF encoding, really?

Well you have source and encoding setting. It's easy to reproduce.

Anyway you make major error interpretation with your graph. CRF mode mean (for the encoder) constant quality (or constant quantizer with P-B ratio, AQ-PSY correction, AQ-RD correction, qcomp correction ... etc) and certainely not constant size for Pframe. Really better to check overall quantizer in your graph, no?

x265 [info]: frame I: 1 Avg QP:39.66 kb/s: 22466.80 PSNR Mean: Y:29.689 U:33.834 V:36.805
x265 [info]: frame P: 13 Avg QP:39.51 kb/s: 13403.75 PSNR Mean: Y:28.313 U:31.299 V:35.122
x265 [info]: frame B: 36 Avg QP:41.79 kb/s: 2440.41 PSNR Mean: Y:27.818 U:31.446 V:35.230
x265 [info]: global : 50 Avg QP:41.16 kb/s: 5691.41 PSNR Mean: Y:27.984 U:31.456 V:35.234

[LigH]

As far as I understood, "Constant Rate Factor" works like a threshold of maximum distortion (loss of detail) between original and reconstructed encoded video. From scene to scene, there are different requirements to stay below a maximum distortion. When there is little detail (blurred original), already a slightly more coarse quantization can guarantee enough detail preservation; this scene is "more compressible".

[a5180007]

Originally Posted by Sagittaire

Well you have source and encoding setting. It's easy to reproduce.

You are right, although the low I-frame size and the slope on the first 80 frames made me think it was ABR, the Park Joy CRF encodings have the same characteristics.

I am still bemused by the "scars" created by the psyrd 0.5, very visible on the bigger CTUs. I hope this can be solved.
EDIT : Might be we don't see the same artefacts with x264 psyrd simply because the macroblocks are small. Maybe the psyrd strength has to be tweaked according to the CTU size: a bigger CTU has less energy/pixel and might require less psyrd change.

Also, any reason why AQ auto-variance is still experimental in x264 but default in x265?

[Audionut]

Well the entire codebase is still somewhat experimental, right?

[fumoffu]

btw. I was wondering how does AQ auto-variance work - both in x264 and x265. It chooses some AQ value per every frame, right? But how does it chooses the value? Does it look for edges or smooth areas, measure picture "complexity"?
From what I understand AQ is sort of trade off between sharp edges and detail in relatively flat textured. So how does it decide what is more important in given frame?
Can the algorithm can be summarized in few sentences?

[a5180007]

AQ=1 : the aq-strength for all frames is the same.
AQ=2 : will adapt the aq-strength for each frame, based on its energy (ie complexity).

For the moment x265 is still oriented towards maximum ssim (default no-psyrd, aq=2). I haven't read anywhere that aq=2 would increase subjective quality.

[fumoffu]

Originally Posted by a5180007

AQ=2 : will adapt the aq-strength for each frame, based on its energy (ie complexity).

this doesn't really answer my question fully. lets say the complexity is high - does adaptive AQ lowers or increases AQ value? One way saves bitrate the other improves quality (with crf encoding). What if the picture is 50/50 for example, the bottom is grass and top half is clear blue sky? I guess it uses average complexity of the whole picture... Would it be possible to auto change AQ value for every CTU?

[LigH]

Result of last week: x265 1.2+239-eb983d29c11a supports embedded encoding options and is supposed to speed up encodes on some AMD processors (amount yet untested).

[a5180007]

Originally Posted by fumoffu

this doesn't really answer my question fully. lets say the complexity is high - does adaptive AQ lowers or increases AQ value? One way saves bitrate the other improves quality (with crf encoding). What if the picture is 50/50 for example, the bottom is grass and top half is clear blue sky? I guess it uses average complexity of the whole picture... Would it be possible to auto change AQ value for every CTU?

In both cases AQ=1 or AQ=2, the quantizer varies for each CTU. This is the purpose of AQ.
AQ=2 strength is increased when frame average complexity increases, which means for each CTU the quantizer offsets from the frame average quantizer are increased. In other words, with AQ=2 in a complex frame there is a bigger difference between higher and lower quantizers than with AQ=1.

[fumoffu]

Originally Posted by a5180007

In both cases AQ=1 or AQ=2, the quantizer varies for each CTU. This is the purpose of AQ.
AQ=2 strength is increased when frame average complexity increases, which means for each CTU the quantizer offsets from the frame average quantizer are increased. In other words, with AQ=2 in a complex frame there is a bigger difference between higher and lower quantizers than with AQ=1.

OK I think I get it now. So if I understand correctly if the average complexity lowers the AQ strength is decreased. But that would mean that flat areas are getting less bits. What if those flatter areas are really important to me? I need as much detail there as possible? Would I be better off setting AQ mode to 1 and maybe even increasing AQ strength manually?

[Asmodian]

Originally Posted by fumoffu

OK I think I get it now. So if I understand correctly if the average complexity lowers the AQ strength is decreased. But that would mean that flat areas are getting less bits. What if those flatter areas are really important to me? I need as much detail there as possible? Would I be better off setting AQ mode to 1 and maybe even increasing AQ strength manually?

Does't it mean that in complex frames flat areas get more of a boost than they do in simple frames? So if 50% grass 50% sky is "normal" AQ then in all sky AQ is weak while in all grass any simple CTUs get a larger boost.

This makes sense to me, a smooth red ball in the middle of a field of grass should get an extra boost vs the field while in a sky shot everything should be compressed pretty much the same.

I think?

[upyzl]

is it normal when see settings from SEI?
head contains junk words:

D:\enc>strings test_info.hevc | head
Nx265 (build 27) - 1.2+261-d303b4d860e9:[Windows][ICC 1400][64 bit] 8bpp - H.265
/HEVC codec - Copyright 2013-2014 (c) Multicoreware Inc - http://x265.org - opti
ons: 1920x1080 fps=24000/1001 bitdepth=8 wpp ctu=64 tu-intra-depth=1 tu-inter-de
pth=1 me=1 subme=2 merange=57 no-rect no-amp max-merge=2 no-early-skip no-fast-c
bf rdpenalty=0 no-tskip no-tskip-fast strong-intra-smoothing no-lossless no-cu-l
ossless no-constrained-intra open-gop interlace=0 keyint=250 min-keyint=23 scene
cut=40 rc-lookahead=20 bframes=4 bframe-bias=0 b-adapt=2 ref=3 weightp no-weight
b aq-mode=2 aq-strength=1.00 cbqpoffs=0 crqpoffs=0 rd=3 signhide lft sao sao-lcu
-bounds=0 sao-lcu-opt=1 b-pyramid cutree rc=crf crf=26.0 qcomp=0.60 qpmin=0 qpma
x=51 qpstep=4 ipratio=1.40 pbratio=1.30
RdN(
L8rx{
(.m`D4(!
kiKE
7<yQ
+20u
m;D-
>1.g
_/GT3K

D:\enc>strings test_no-info.hevc | head
RdN(
L8rx{
(.m`D4(!
kiKE
7<yQ
+20u
m;D-
>1.g
_/GT3K
Yt^5

compare: https://bitbucket.org/multicoreware/...a9fbd8047dd5fc

[LigH]

It is absolutely normal that data in the header consists of byte values which correspond to a few readable characters in ASCII code. It also consists of non-printable characters, but those are ignored by "strings", like shorter sequences of readable characters.

Computer scientists who know some basics about Claude Shannon's theory about information and entropy won't be surprised about this result.

You just discovered the "semantic gap": A HEVC decoder sees no meaning in the SEI info which a human can read; a human sees no meaning in the header data which a HEVC decoder can interpret.

[upyzl]

@LigH

oh, that's it... I thought the cmd would just output only the human-readable info, and if that it could be saved by a string variable directly for other usage...