x265 HEVC Encoder

[Atak_Snajpera]

Well I confirm that my x265 encoding is better than your x264 encoding ... and by far. Make screenshoot if you want tak_Snajpera (And buy a white cane or dog)

In order:
- More temporal stability for x265 and by far
- Less mosquito noise for x265 and by far
- less blocking for x265 and by far
- more high frequency retention (detail) for x265 and by far

Mosquito noise and detail retention are not the same thing ... !!!

And ofcourse you have forgotten about the most important thing. DETAILS ;) x265 blurs everything like crazy. See grass , see water , see leaves. They must pay you for spreading those lies no doubt!

x264 frame 100
http://i.cubeupload.com/mVSONo.png

x265 frame 100
http://i.cubeupload.com/Oc3H1z.png

[a5180007]

First frame : http://screenshotcomparison.com/comparison/82931

EDIT :
Although overall movie sizes are the same
x264 1st I-frame is 90,534 bytes, avg QP 34
x265 1st I-frame is 47,600 bytes, avg QP 40

Very different decisions... @Sagittaire : what are the encoding parameters?

Funny to see how the "banding artefacts" are related to the CTUs.
There is definitely something borked with psy-rd reconstruction.

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

[fumoffu]

How about my x264 encode: http://a.pomf.se/onaaol.mkv (ugh.. sry filehost changes file names)
It looks similar to x265 but water is much better.

[Sagittaire]

And ofcourse you have forgotten about the most important thing. DETAILS ;) x265 blurs everything like crazy. See grass , see water , see leaves. They must pay you for spreading those lies no doubt!

x264 frame 100
http://i.cubeupload.com/mVSONo.png

x265 frame 100
http://i.cubeupload.com/Oc3H1z.png

Well, I don't like Screenshoot but like your eyes are really strange I will make that with the same frame 100:

http://jfl1974.free.fr/Comparison_100.png

Like you can see, x265 high frequency retention is by far better for x265. You say "more detail for x264" and I say "hard mosquito noise for x264" (and I prove that with your screen).

When I compare x265 vs x264 encoding I see:
- Hard temproral instability for x264
- Major blocking hellfest for x264
- Major Ringing hellfest for x264

For last time MOSQUITO NOISE IS NOT DETAIL RETENTION ... !!!

[Atak_Snajpera]

My eyes are fine. The problem is with your damaged brain. For some odd reason it prefers blured image instead of sharper with higher complexity. I hope they pay you well atleast for your trolling...

[poisondeathray]

Some strange issues with that red umbrella ghosting / echo image?

[Sagittaire]

My eyes are fine. The problem is with your damaged brain. For some odd reason it prefers blured image instead of sharper with higher complexity. I hope they pay you well atleast for your trolling...


Seriousely, In YOUR screen you prefer x264 ... ???

It's Ringing and Blocking hellfest ... lol

I can't even see some head on x264 encoding. For you, good detail prevervation must cut the head ... :eek:

And I use the same frame 100 than your screenshoot. Really easy for me to find other frame with really bad quality for x264 and bad detail preservation.

[a5180007]

@Sagittaire: could you please give the encoding parameters.

EDIT : will x265 write the encoding parameters in the SEI like x264 does in a near future?
I find it very annoying not to be able to see these parameters when downloading a x265 encoding.

@Atak_Snajpera : the x264 image is a Degas painting, the x265 is a Monet painting. Some like Monet, some others prefer Degas.
At this level of compression it is impressionism rather than reflecting reality. What is the point of testing at those crf when lower resolutions give better quality?

[Atak_Snajpera]

at low bitrate both encodes look bad. x264 is at least sharper. Grass , leaves ,water in x265 is noticable less detailed. I imediatelly notice that in motion.

[Sagittaire]

Some strange issues with that red umbrella ghosting / echo image?

Yes I see that for x265. It's certainely temporal artefact because here the quantification is really high. Anyway I find temporal stability and global quality really better for x265. There are major flicking in x264 encoding for I-P-B frame transition.

[Sagittaire]

at low bitrate both encodes look bad. x264 is at least sharper. Grass , leaves ,water in x265 is noticable less detailed. I imediatelly notice that in motion.

For last time it's not more detailled. It's mosquito noise like I prove that with your screen.

With your screen I see more sharp contour on tree or on character. It's really simple to see that.

Change your eyes .... really now.

[Atak_Snajpera]

you can easily tune x264 for the same result. Tomorrow i will try with preset anime ;)

btw what's the story with that funny deblocking effect on trees in first plane ;) ?

[Sagittaire]

you can easily tune x264 for the same result. Tomorrow i will try with preset anime ;)

No because I already try. x264 is not able at this quality level to have good temporal quality. A this level quality, you have major blocking and major ringing on moving object for x264 and not for x265.

Moreover your eyes see detail retention for x264 but it's not that. It's simply hard ringing and mosquito noise (temporal instability is easy to notice) but It reproduce no existing detail if you compare with the source ... :eek:

[poisondeathray]

Yes I see that for x265. It's certainely temporal artefact because here the quantification is really high. Anyway I find temporal stability and global quality

really better for x265. There are major flicking in x264 encoding for I-P-B frame transition.

I don't recall seeing that on previous x265 snaphots with the same test source with high quantizers. Please post the full x265 parameters

Other "echo/ghosts" as well - the 1st person has some "ghost" trailing him

I agree temporal stability is a major strength with x265 and other HEVC implementations - much more stable than x264, but this "echo/ghosting" temporal artifact is worrisome

"Global quality" however , is debatable, as you can see there seems to be some disagreement on subjective quality . Like all things, there are pros/cons

[Sagittaire]

http://forum.doom9.org/showthread.php?p=1686027#post1686027

I reduce ratio on I-P-B frame transition because:
- Reduce block flicking
- Reduce artecfact with high PSY-RDO value

[poisondeathray]

EDIT : will x265 write the encoding parameters in the SEI like x264 does in a near future?
I find it very annoying not to be able to see these parameters when downloading a x265 encoding.


Yes this would be very helpful for debugging, providing feeback, testing

[Atak_Snajpera]

Sagittaire

Good lossy codecs by default are designed to fool your brain. I don't care if those details are real or not. My brain prefers higher complexity. It is the same with audio. HE-AAC 64 kbps with fake half bandwidth (SBR) sounds much better than LC-AAC with the same bitrate.

[a5180007]

btw what's the story with that funny deblocking effect on trees in first plane ;) ?

Yes, that and the fact that the I-frame is half the size of the x264 one -about the same byte size as the following P-frames.
That's why it would be nice to have the encoding parameters to be able to reproduce *. I remember reading no so long ago in this post a moderator requesting the parameters to be given for all posted videos.
Hopefully I will get more luck when things have cooled down between you two ;)

* EDIT : E.g. if the number of B frames is not the same, I would not call this a fair comparison. I saw there was already a difference in --keyint (x265 is 250, x264 is 500).

[Sagittaire]

Yes, that and the fact that the I-frame is half the size of the x264 one -about the same byte size as the following P-frames.
That's why it would be nice to have the encoding parameters to be able to reproduce. I remember reading no so long ago in this post a moderator requesting the parameters to be given for all posted videos.
Hopefully I will get more luck when things have cooled down between you two ;)

http://forum.doom9.org/showthread.php?p=1686027#post1686027

[a5180007]

Thanks Sagittaire.


x265.exe --input hp.yuv --output crf23aq.265 --input-res 720x304 --fps 25 --crf 24 --preset veryslow --aq-mode 2 --aq-strength 1.0
--psy-rd 0.5 --bframes 3 --min-keyint 1 --ipratio 1.1 --pbratio 1.1 --psnr

With all respect, how is it related to your 1080p50 park-joy encoding? Which parameters are relevant?
With --crf 24 --preset veryslow --aq-mode 2 --aq-strength 1.0 --psy-rd 0.5 --bframes 3 --min-keyint 1 --ipratio 1.1 --pbratio 1.1 (x265_1.1+258), the first I-frame is 212,278 bytes, four times the size of the one in your encoding. Your encoding is likely 1 pass ABR, not --crf.

[foxyshadis]

Geez guys, you said exactly the same things and had just as much luck convincing each other last time. Like I said then, duke it out in another thread if you really care that much, and keep it civil.

[Sagittaire]

Thanks Sagittaire.


x265.exe --input hp.yuv --output crf23aq.265 --input-res 720x304 --fps 25 --crf 24 --preset veryslow --aq-mode 2 --aq-strength 1.0
--psy-rd 0.5 --bframes 3 --min-keyint 1 --ipratio 1.1 --pbratio 1.1 --psnr

With all respect, how is it related to your 1080p50 park-joy encoding? Which parameters are relevant?
With --crf 24 --preset veryslow --aq-mode 2 --aq-strength 1.0 --psy-rd 0.5 --bframes 3 --min-keyint 1 --ipratio 1.1 --pbratio 1.1 (x265_1.1+258), the first I-frame is 212,278 bytes, four times the size of the one in your encoding. Your encoding is likely 1 pass ABR, not --crf.

No ... x265 reported same quantizer and really higher size for IFrame (and really higher quality for psnr) than PFrame. Defaut ratio mean Oversized IFrame and too high quality flicking for my eyes. Same quantizer for I-P-B mean same quality level for all codec.

E:\Mes Logiciels\Codec\x265>x265.exe --input park_joy_1080p50.y4m --output crf24aq.265 --input-res 1920x1080 --fps 50 --
crf 35 --preset veryslow --aq-mode 2 --aq-strength 1.0 --psy-rd 1.0 --bframes 3 --min-keyint 1 --ipratio 1.1 --pbratio 1
.1 --weightp --psnr --frames 50 --recon x265.y4m
y4m [info]: 1920x1080 fps 50000/1000 i420p8 sar 1:1 frames 0 - 49 of 500
y4m [info]: reconstructed images 1920x1080 fps 50000/1000 i420
x265 [info]: HEVC encoder version 1.1+253-11c808e562b894d8
x265 [info]: build info [Windows][GCC 4.8.3][64 bit] 8bpp
x265 [info]: Compiling by snayper [x265.ru]
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64 SlowShuffle
x265 [warning]: --psnr used with psy on: results will be invalid!
x265 [warning]: --tune psnr should be used if attempting to benchmark psnr!
x265 [info]: WPP streams / pool / frames : 17 / 4 / 2
x265 [info]: Main profile, Level-5 (Main tier)
x265 [info]: CU size : 64
x265 [info]: Max RQT depth inter / intra : 3 / 3
x265 [info]: ME / range / subpel / merge : star / 57 / 4 / 4
x265 [info]: Keyframe min / max / scenecut : 1 / 250 / 40
x265 [info]: Lookahead / bframes / badapt : 40 / 3 / 2
x265 [info]: b-pyramid / weightp / weightb / refs: 1 / 1 / 0 / 5
x265 [info]: Rate Control / AQ-Strength / CUTree : CRF-35.0 / 1.0 / 1
x265 [info]: tools: rect amp rd=6 psy-rd=1.0 lft sao-lcu signhide
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
x265 [info]: Weighted P-Frames: Y:0.0% UV:0.0%
x265 [info]: consecutive B-frames: 14.3% 0.0% 0.0% 85.7%

encoded 50 frames in 434.37s (0.12 fps), 5691.41 kb/s, Global PSNR: 29.324

[SeeMoreDigital]

Geez guys, you said exactly the same things and had just as much luck convincing each other last time. Like I said then, duke it out in another thread if you really care that much, and keep it civil.Agreed...

Indeed, you might be better off creating the new topic by splitting out the non-relevant posts from this topic ;)

[a5180007]

http://i.imgur.com/EubXIDn.png
Park Joy CRF encoding, really?

@x265 Tom, do you have plans to add the encoding parameters to the SEI? I guess it is a very easy change, more likely a commercial decision.
EDIT : maybe you could add a switch eg --info to add parameters to SEI.

[Romario]

So, where are Changelog for x265 1.2 ? Please. :)

[foxyshadis]

@x265 Tom, do you have plans to add the encoding parameters to the SEI? I guess it is a very easy change, more likely a commercial decision.
EDIT : maybe you could add a switch eg --info to add parameters to SEI.

A patch to do so was just posted to the mailing list, should hit the repo soon. No switches, it'll be always on. Cool!

[x265_Project]

A patch to do so was just posted to the mailing list, should hit the repo soon. No switches, it'll be always on. Cool!

Thanks for the suggestion a5180007. This was on our todo list. We talked about this today, and after some discussion we agreed it should be even higher on our todo list. So, there you have it.... a patch was developed and is queued for testing.

[x265_Project]

x265 release 1.2 was tagged on Wednesday. This was a regularly scheduled release with improvements in performance, major improvements in memory usage, and improved psy-rd behavior.

There were a few of new options introduced:

--cu-stats, x265_param.bLogCuStats - enabling logging of CU stats (for R&D purposes only)

--hrd, x265.bEmitHRDSEI - enable HRD SEI signaling (use this option to add Hypothetical Reference Decoder information into the HEVC bitstream, in order to comply with HRD specifications)

--ipratio/--pbratio were exposed to the CLI

--lambda-file - allows experimentation with lambda tables (for R&D purposes only - this should not be needed for normal production encoding purposes)

Plus a number of options added for multi-pass encoding (incomplete). We will document those in the next release after the feature is complete.

Full documentation for the features supported in the release can be found at http://x265.readthedocs.org/en/1.2/.

[a5180007]

@x265 When trying to encode a video the same size as max CTU

(e.g. fill 1,536 "a" chars in an editor and save the file as 32x32.yuv) :
"x265 --input-res 32x32 --fps 25 --ctu 32 --threads 1 32x32.yuv -o 32x32.hevc" crashes.
"x265 --input-res 32x32 --fps 25 --ctu 32 --threads 2 32x32.yuv -o 32x32.hevc" hangs

Is this expected? I mean, surely the max ctu is supposed to be smaller than the video size, but shouldn't the exception be caught?
EDIT : x265 8bpp 1.2+76-6e116af on W8.1 32bits

[x265_Project]

@x265 When trying to encode a video the same size as max CTU

(e.g. fill 1,536 "a" chars in an editor and save the file as 32x32.yuv) :
"x265 --input-res 32x32 --fps 25 --ctu 32 --threads 1 32x32.yuv -o 32x32.hevc" crashes.
"x265 --input-res 32x32 --fps 25 --ctu 32 --threads 2 32x32.yuv -o 32x32.hevc" hangs

Is this expected? I mean, surely the max ctu is supposed to be smaller than the video size, but shouldn't the exception be caught?
EDIT : x265 8bpp 1.2+76-6e116af on W8.1 32bits
A 32x32 video? Is this a real use-case? What are you trying to encode, animated icons?

A crash is never "expected". We work hard to make x265 robust, and a crash is never acceptable, regardless of the command-line syntax or the input video. Yes - exceptions should be caught. If x265 fails it should fail gracefully, with an error message explaining why it couldn't complete the encode. I'll have to check with our engineers, but I suspect that a 32x32 video may be beyond the limits of the HEVC specifications.

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

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 (https://www.mediafire.com/download/tduyyhjribgyblb/x265_1.2_82-6055baa75085.7z) as another merge-with-stable release.

[upyzl]

waiting for MediaInfo to support the new SEI :)

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?
Also, it does not show the number of detected threads, which is important for reproducibility.
agreed

[Kurtnoise]

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 (http://en.wikipedia.org/wiki/Application_programming_interface) version, not the hash from the repository...

[a5180007]

The number here corresponds to the current API (http://en.wikipedia.org/wiki/Application_programming_interface) version, not the hash from the repository...

Indeed, it makes sense! Thanks Kurtnoise.

[Sagittaire]

http://i.imgur.com/EubXIDn.png
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]

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? :p

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

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 (https://www.mediafire.com/download/0q8gnzcy6cznyd6/x265_1.2+239-eb983d29c11a.7z) supports embedded encoding options and is supposed to speed up encodes on some AMD processors (amount yet untested).

[a5180007]

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]

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]

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? :p

[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/x265/commits/6af56f7c870355152c9897a7bca9fbd8047dd5fc

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