x265 HEVC Encoder

[_kermit]

yes... it is bad... you need to enter correct values to to source... read the x265 documentation...

--master-display "G(8500,39850)B(6550,2300)R(35400,14600)WP(15635,16450)L(10000000,1)" are correct values for your source

are those values depending on source?
I noticed with other files they are all correct.
It seems that this one was different. Is this common?

[MeteorRain]

Just wondering how and why they (MCW) approve the commits without testing the commits...

I'm guessing because they are still using CVS style committing and branching. If they start using Git style branching bad things would be easier to catch after they commit but before they merge.

[Patman]

I'm guessing because they are still using CVS style committing and branching. If they start using Git style branching bad things would be easier to catch after they commit but before they merge.I used the x265_git and it happened too. Or is it a mirror in preparation for git usage?

[foxyshadis]

And the problem hasn't been fixed yet :scared:

Just wondering how and why they (MCW) approve the commits without testing the commits...

After Steve Borho left, essentially all code review went with him; they just commit every submission and clean up later now. Except assembly; chen still reviews that harshly.

[benwaggoner]

are those values depending on source?
I noticed with other files they are all correct.
It seems that this one was different. Is this common?
The values are specific to the professional grading monitor that was used to master the HDR. The premise is that the content will have no visible-by-creative-intent values outside of what the mastering monitor was capable of.

You need to use the values that are appropriate to the mastering monitor, which isn't something you can know from anything in the source other than this metadata. So, copy it if you have it. Otherwise leave it blank rather than specifying an incorrect value.

[MeteorRain]

I used the x265_git and it happened too. Or is it a mirror in preparation for git usage?

That's not what I mean. Note the word style.

[Patman]

That's not what I mean. Note the word style.

My fault. I only read your entry quickly when I was on the road and read it correctly again this evening :rolleyes: You could be right about that.

[_kermit]

The values are specific to the professional grading monitor that was used to master the HDR. The premise is that the content will have no visible-by-creative-intent values outside of what the mastering monitor was capable of.

You need to use the values that are appropriate to the mastering monitor, which isn't something you can know from anything in the source other than this metadata. So, copy it if you have it. Otherwise leave it blank rather than specifying an incorrect value.

Not defining it in the command line would re-use what's in the source then?

to add: If so, is that also true for --max-cll ?

[Blue_MiSfit]

Not defining it in the command line will simply not set it. x265 has no vision into the source metadata.

Also yes, this is true for --max-cll.

[dREV]

I suppose it's as somebody wrote few posts ago about things breaking when grabbing the latest as I tried the latest build Barough shares x265 v3.3+17-gdf2ac512d https://forum.doom9.org/showthread.php?p=1905930#post1905930 appears both --profile main444-12 --input-csp i444 and --profile main444-10 --input-csp i444 are broken (if somebody else can also confirm) and may include 4:2:0 10 bit equivalent. 8 bit works fine.

Hope Barough will see this post.

----------------------------------------------

I don't know if it's related but as of far as I've tested x265 v3.3+2-gbe2d82093 (https://forum.doom9.org/showthread.php?p=1901894#post1901894) has stopped working telling me Error message for your references: System exception - Access violation when Prefetch(1) is in the end of the script of AviSynth+ 3.5 but runs when (I think its disabled) Prefetch(0) is set. No issues with x265 v3.2+22-a8a2c4c37267 (https://forum.doom9.org/showthread.php?p=1893257#post1893257).

I'm just writing this in case they may be related or not. I really do not know if Prefetch is even worth using since the AviSynth thread is of no help neither the documentation.

----------------------------------------------

Another question in regards to an interest in figuring out if a speed in my encoding with AviSynth+ is possible.

As I recall the settings for slow and veryslow were changed sometime ago and prior my encodes were a bit faster with my settings which have hardly changed since that implementation (likewise with my AviSynth filtering) but I dunno if choosing slower is the same as veryslow as I cannot tell just doing several encode tests at my end.

These are my current settings:
--level 4.1 --crf 16.0 --aq-mode 3 --aq-strength 0.80 --deblock=-1:-1 --me sea --merange 57 --psy-rd 1.00 --rc-lookahead 40 --bframes 16 --ref 6 --subme 7 --qcomp=0.75 --fades --limit-refs=0 --no-limit-modes --rd 6 --psy-rdoq 5 --rdoq-level 1 --tu-intra-depth 4 --tu-inter-depth 4 --ipratio 1.4 --pbratio 1.3 --max-tu-size 32 --ctu 64 --qg-size 64 --limit-tu 0 --max-merge 5 --no-rect --colorprim bt709 --transfer bt709 --colormatrix bt709 --preset veryslow --sar 1:1 --input-depth 16 --profile main444-12 --input-csp i444 --tune animation --no-sao --no-amp --no-strong-intra-smoothing --dither

In 720p if that matters and yeah I am going overboard on some settings. I'm attempting to modify to shorten it some and just found out --ref 8 exists or I wasn't paying much attention to the documentation but doesn't seem to work at this resolution.

Wish the developers would give why the encoder stops to work on some settings instead of just stopping it with no explanation. Well, thanks if anybody gives any suggestions or critique.

[_kermit]

Not defining it in the command line will simply not set it. x265 has no vision into the source metadata.

Also yes, this is true for --max-cll.

now I'm confused, sorry that I keep asking: :o
if used, the correct values must be provided
or
it doesn't matter and they should not be provided?

(for both)

Actually there is more to it:
If I don't provide in particular max-cll, that metadata is missing in the mkv and that data is for example used by the Radiance Pro.
So I think this should be in the new, at least, file since it was in the original?

[MythCreator]

now I'm confused, sorry that I keep asking: :o
if used, the correct values must be provided
or
it doesn't matter and they should not be provided?

(for both)

Actually there is more to it:
If I don't provide in particular max-cll, that metadata is missing in the mkv and that data is for example used by the Radiance Pro.
So I think this should be in the new, at least, file since it was in the original?

It doesn't matter if you provided it or not, because the thing without those preferences is still playable, but if you want to enjoy the "correct" color and light, then you must provide them in command line.

and for the last question, to be honest, I don't know if I need those preferences, why export a new file or something else instead of set them in command line?

[_kermit]

It doesn't matter if you provided it or not, because the thing without those preferences is still playable, but if you want to enjoy the "correct" color and light, then you must provide them in command line.

and for the last question, to be honest, I don't know if I need those preferences, why export a new file or something else instead of set them in command line?

Ok, I stick with providing the parameters then.
If that information isn't there, the Radiance Pro is using default values
(AFAIK), so they are rather important and can not be provided otherwise.
And since I provide max-cll in the command line as parameters, that is fine.
The primaries seem only to have two variants so far:

R: x=0.708000 y=0.292000, G: x=0.170000 y=0.797000, B: x=0.131000 y=0.046000, White point: x=0.312700 y=0.329000

and

R: x=0.680000 y=0.320000, G: x=0.265000 y=0.690000, B: x=0.150000 y=0.060000, White point: x=0.312700 y=0.329000

thank you all!

[onekmilesbehind]

The primaries seem only to have two variants so far:

R: x=0.708000[...]
and
R: x=0.680000[...]

Took me too long to realize those correspond with BT.2020 (https://en.wikipedia.org/wiki/Rec._2020#System_colorimetry) (top) and DCI-P3 (https://en.wikipedia.org/wiki/DCI-P3#System_colorimetry) (bottom), both very common with HDR media.

[_kermit]

Took me too long to realize those correspond with BT.2020 (https://en.wikipedia.org/wiki/Rec._2020#System_colorimetry) (top) and DCI-P3 (https://en.wikipedia.org/wiki/DCI-P3#System_colorimetry) (bottom), both very common with HDR media.

ah, that's good to know :)

thanks.

[Patman]

And the problem hasn't been fixed yet :scared:

Just wondering how and why they (MCW) approve the commits without testing the commits...

They could fix the problem. Look here (https://bitbucket.org/multicoreware/x265/issues/539/error-when-starting-encode#comment-56872276). I think there will be an official fix soon.

[filler56789]

They could fix the problem. Look here (https://bitbucket.org/multicoreware/x265/issues/539/error-when-starting-encode#comment-56872276). I think there will be an official fix soon.

Thanks!

https://bitbucket.org/multicoreware/x265/commits/6bb2d88029c2e13fa13b5b053aa725d4fa84a084

[tuanden0]

Unable to finish encode after using x265 version 3.3+19 and 3.3+21 on http://msystem.waw.pl/x265/

So i have to turn back on version 3.3+10

I got stuck after they encode to last frame
https://i.imgur.com/CvIgQHX.png

[filler56789]

Unable to finish encode after using x265 version 3.3+19 and 3.3+21 on http://msystem.waw.pl/x265/

So i have to turn back on version 3.3+10

I got stuck after they encode to last frame
https://i.imgur.com/CvIgQHX.png

Thanks for the useful information,
I have just reported the latest-and-greatest problem to the x265 devils.

[MythCreator]

My encoding work stuck on 3.3.19 & 3.3.21 too. It won't stuck on 3.3.10 with exact same settings, video and compiler. And it doesn't matter what compiler is, GCC or VS stuck on 3.3.19 and all goes well on 3.3.10. So the problem has to be in those commits between 3.3.19 and 3.3.10.

vspipe 2>NUL "RAW.vpy" - | C:\Encoder\x265_64_10bpp.exe --input-res 1280x720 --fps 29.970 --input-depth 16 --force-flush 0 --ctu 32 --no-strong-intra-smoothing --selective-sao 0 --no-sao --bframes 8 --weightb --no-open-gop --ref 6 --rc-lookahead 48 --aq-strength 1.0 --psy-rd 2.5 --rd 6 --aq-mode 1 --aq-motion --hme --hme-search "2,2,3" --hme-range "24,24,36" --me star --subme 6 --merange 64 --crf 18 --output “RAW.hevc" -

here's the command line that I'm using.

[Patman]

Thanks for the useful information,

I have just reported the latest-and-greatest problem to the x265 devils.I think all the problems are caused by the implantation of the abrEncApp.

EDIT: Here (http://www.mediafire.com/folder/arv5xmdqyiczc/x265_by_Patman) is a link to version 3.3+15 (multilib exe). This version is the last one without implementation of the abrEncApp. Please test if there are any problems with encoding.

[MythCreator]

I think all the problems are caused by the implantation of the abrEncApp.

EDIT: Here (http://www.mediafire.com/folder/arv5xmdqyiczc/x265_by_Patman) is a link to version 3.3+15 (multilib exe). This version is the last one without implementation of the abrEncApp. Please test if there are any problems with encoding.

I tested this version, the encoding ends well.

[Patman]

I tested this version, the encoding ends well.

Thank you very much, this confirms my suspicion that it has to do with the implementation of the abrEncApp.

[tuanden0]

I think all the problems are caused by the implantation of the abrEncApp.

EDIT: Here (http://www.mediafire.com/folder/arv5xmdqyiczc/x265_by_Patman) is a link to version 3.3+15 (multilib exe). This version is the last one without implementation of the abrEncApp. Please test if there are any problems with encoding.

I tested your x265 version and it work! Thank you!
:thanks:

[LigH]

the x265 devils.

:devil:

You slipped.

[dREV]

Is it possible to customize --total-frames to show total-frames=0 ? I'm asking as I've seen some mediainfo's containing such information and wanted to know if there's some other vodoo than typing --total-frames 0 or simply --total-frames as these gets the encoder to stop altogether.

The documentation says almost nothing on this https://x265.readthedocs.io/en/latest/cli.html#cmdoption-uhd-bd (and scroll down a notch or two).

I'm also asking as I heavily use film.trim() so it looks odd seeing only a certain number of frames in mediainfo when the total frames are much larger after appending the files. Thanks if someone answers it unlike my prior post above where it was completely ignored.

[Selur]

are much larger after appending the files
How are you appending the files? Sound like the file headers are not properly adjusted during the appending,...

[dREV]

How are you appending the files? Sound like the file headers are not properly adjusted during the appending,...

I am appending using mkvmerge portable version 45.0 (Heaven's in Pennies) 64 bit under "Add source files" > "Append files". https://www.fosshub.com/MKVToolNix.html After muxing like usual only identifies the first video's cut frames.

I've asked the mkvmerge creator and said this is a non-issue and won't affect video playback several versions ago.

I just wanna know these guys are getting total-frames to read 0. Must be some trick I do not know. Likewise when they somehow cut out encoding settings altogether too but I don't really care about that one. :scared:

Not sure what you mean by headers. I am also using HEVC through MeGUI's one click (and its command line) if that helps.

[Selur]

@dREV: you could try whether appending files with ffmpeg has the same issue
--
Any news about the encoding gets stuck with current x265 versions ?

[Patman]

Any news about the encoding gets stuck with current x265 versions ?

The dev has linked a patch in the issue tracker. I'm now compiling x265.exe with these changes. When the building process is complete, I edit this post and add a link.

EDIT: Here (http://www.mediafire.com/folder/arv5xmdqyiczc/x265_by_Patman) is the link, version x265-3.3+19-..._patched contains with the changes. Pls give me feedback on this version.

[filler56789]

EDIT: Here (https://www.mediafire.com/#arv5xmdqyiczc) is the link, version x265-3.3+19-..._patched contains with the changes. Pls give me feedback on this version.

Wrong link, this is the correct one:

https://www.mediafire.com/folder/arv5xmdqyiczc

I will test the binary A.S.A.P. :thanks:

[Patman]

Wrong link, this is the correct one:

https://www.mediafire.com/folder/arv5xmdqyiczc

I will test the binary A.S.A.P. :thanks:

Ops, now correct. :thanks:

EDIT: I tested this binary and it doesn't work (for me). The encoding process hangs at startup ... :confused: :scared:

[filler56789]

EDIT: I tested this binary and it doesn't work (for me). The encoding process hangs at startup ... :confused: :scared:

I confirm that, the encoding doesn't even start -_-

avs2yuv hc500.avs -o -|z265 --input - --y4m --output C:\hp\test.hevc --crf 22 --no-sao
--subme 3 --no-open-gop --keyint 150 --min-keyint 1 --ctu 32
hc500.avs: 1280x720, YV12, 8-bits, progressive, 30 fps, 4064 frames
y4m [info]: 1280x720 fps 30/1 i420p8 unknown frame count
raw [info]: output file: C:\hp\test.hevc
x265 [info]: HEVC encoder version 3.3+19-gcaf9d4dbe
x265 [info]: build info [Windows][GCC 10.0.1][64 bit] 8bit+10bit+12bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.1 Cache64
x265 [info]: Main profile, Level-3.1 (Main tier)
x265 [info]: Thread pool created using 4 threads
x265 [info]: Slices : 1
x265 [info]: frame threads / pool features : 2 / wpp(23 rows)
x265 [info]: Coding QT: max CU size, min CU size : 32 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 1 inter / 1 intra
x265 [info]: ME / range / subpel / merge : hex / 57 / 3 / 3
x265 [info]: Keyframe min / max / scenecut / bias : 1 / 150 / 40 / 5.00
x265 [info]: Lookahead / bframes / badapt : 20 / 4 / 2
x265 [info]: b-pyramid / weightp / weightb : 1 / 1 / 0
x265 [info]: References / ref-limit cu / depth : 3 / off / on
x265 [info]: AQ: mode / str / qg-size / cu-tree : 2 / 1.0 / 32 / 1
x265 [info]: Rate Control / qCompress : CRF-22.0 / 0.60
x265 [info]: tools: rd=3 psy-rd=2.00 early-skip rskip mode=1 signhide tmvp
x265 [info]: tools: b-intra strong-intra-smoothing lslices=4 deblock
^C^C

[Selur]

here too,...

[Patman]

Please test again, an error occurred while implementing the patch. Corrected this now and the binary works for me. I've updated the files.

[filler56789]

Please test again, an error occurred while implementing the patch. Corrected this now and the binary works for me. I've updated the files.

Thanks, now the .EXE works as expected (finally!)

[MythCreator]

Please test again, an error occurred while implementing the patch. Corrected this now and the binary works for me. I've updated the files.

This version works for me too.

[tuanden0]

Please test again, an error occurred while implementing the patch. Corrected this now and the binary works for me. I've updated the files.

This version work for me :D

Edited:
I got some strange output when the encoding almost done
https://i.imgur.com/nrBaf9m.png

[Patman]

Can you post your command line? These are my results...

Avisynth
D:\StaxRip\Apps\Support\avs2pipemod\avs2pipemod64.exe -y4mp "G:\Movie\x264\test\Sonic The Hedgehog Trailer_temp\Sonic The Hedgehog Trailer_new.avs" |
D:\StaxRip\Apps\Encoders\x265\x265.exe --crf 18 --profile main10 --output-depth 10 --frames 4115 --y4m --output "G:\Movie\x264\test\Sonic The Hedgehog Trailer_temp\Sonic The Hedgehog Trailer_new_out.hevc" -

avs2pipemod[info]: writing 4115 frames of 24000/1001 fps, 720x304,
sar 0:0, YUV-420-planar-8bit progressive video.
y4m [info]: 720x304 fps 24000/1001 i420p8 unknown frame count
raw [info]: output file: G:\Movie\x264\test\Sonic The Hedgehog Trailer_temp\Sonic The Hedgehog Trailer_new_out.hevc
x265 [info]: HEVC encoder version 3.3+19-gcaf9d4dbe
x265 [info]: build info [Windows][GCC 10.0.1][64 bit] 10bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
x265 [info]: Main 10 profile, Level-2.1 (Main tier)
x265 [info]: Thread pool created using 16 threads
x265 [info]: Slices : 1
x265 [info]: frame threads / pool features : 4 / wpp(5 rows)
x265 [warning]: Source height < 720p; disabling lookahead-slices
x265 [info]: Coding QT: max CU size, min CU size : 64 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 1 inter / 1 intra
x265 [info]: ME / range / subpel / merge : hex / 57 / 2 / 3
x265 [info]: Keyframe min / max / scenecut / bias : 23 / 250 / 40 / 5.00
x265 [info]: Lookahead / bframes / badapt : 20 / 4 / 2
x265 [info]: b-pyramid / weightp / weightb : 1 / 1 / 0
x265 [info]: References / ref-limit cu / depth : 3 / off / on
x265 [info]: AQ: mode / str / qg-size / cu-tree : 2 / 1.0 / 32 / 1
x265 [info]: Rate Control / qCompress : CRF-18.0 / 0.60
x265 [info]: tools: rd=3 psy-rd=2.00 early-skip rskip mode=1 signhide tmvp
x265 [info]: tools: b-intra strong-intra-smoothing deblock sao
avs2pipemod[info]: finished, wrote 4115 frames [100%].
avs2pipemod[info]: total elapsed time is 44.602 sec.

x265 [info]: frame I: 153, Avg QP:16.30 kb/s: 4090.80
x265 [info]: frame P: 1226, Avg QP:19.30 kb/s: 1643.85
x265 [info]: frame B: 2736, Avg QP:23.93 kb/s: 545.73
x265 [info]: Weighted P-Frames: Y:2.9% UV:2.3%
x265 [info]: consecutive B-frames: 29.7% 8.7% 16.5% 23.8% 21.3%
encoded 4115 frames in 46.71s (88.09 fps), 1004.71 kb/s, Avg QP:22.27

Vapoursynth
"C:\Program Files\VapourSynth\core\vspipe.exe" "G:\Movie\x264\test\Sonic The Hedgehog Trailer_temp\Sonic The Hedgehog Trailer_new.vpy" - --y4m |
D:\StaxRip\Apps\Encoders\x265\x265.exe --crf 18 --profile main10 --output-depth 10 --frames 4115 --y4m --output "G:\Movie\x264\test\Sonic The Hedgehog Trailer_temp\Sonic The Hedgehog Trailer_new_out.hevc" -

y4m [info]: 720x304 fps 24000/1001 i420p8 unknown frame count
raw [info]: output file: G:\Movie\x264\test\Sonic The Hedgehog Trailer_temp\Sonic The Hedgehog Trailer_new_out.hevc
x265 [info]: HEVC encoder version 3.3+19-gcaf9d4dbe
x265 [info]: build info [Windows][GCC 10.0.1][64 bit] 10bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
x265 [info]: Main 10 profile, Level-2.1 (Main tier)
x265 [info]: Thread pool created using 16 threads
x265 [info]: Slices : 1
x265 [info]: frame threads / pool features : 4 / wpp(5 rows)
x265 [warning]: Source height < 720p; disabling lookahead-slices
x265 [info]: Coding QT: max CU size, min CU size : 64 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 1 inter / 1 intra
x265 [info]: ME / range / subpel / merge : hex / 57 / 2 / 3
x265 [info]: Keyframe min / max / scenecut / bias : 23 / 250 / 40 / 5.00
x265 [info]: Lookahead / bframes / badapt : 20 / 4 / 2
x265 [info]: b-pyramid / weightp / weightb : 1 / 1 / 0
x265 [info]: References / ref-limit cu / depth : 3 / off / on
x265 [info]: AQ: mode / str / qg-size / cu-tree : 2 / 1.0 / 32 / 1
x265 [info]: Rate Control / qCompress : CRF-18.0 / 0.60
x265 [info]: tools: rd=3 psy-rd=2.00 early-skip rskip mode=1 signhide tmvp
x265 [info]: tools: b-intra strong-intra-smoothing deblock sao
Output 4115 frames in 45.41 seconds (90.61 fps)

x265 [info]: frame I: 154, Avg QP:16.33 kb/s: 4051.93
x265 [info]: frame P: 1218, Avg QP:19.31 kb/s: 1646.53
x265 [info]: frame B: 2743, Avg QP:23.93 kb/s: 547.57
x265 [info]: Weighted P-Frames: Y:3.3% UV:2.5%
x265 [info]: consecutive B-frames: 28.6% 9.4% 16.9% 23.5% 21.6%
encoded 4115 frames in 47.49s (86.66 fps), 1004.00 kb/s, Avg QP:22.28

My logs are clean. I use Avisynth+ 3.5.1 and Vapoursynth R49 + Python 3.8.2.

[tuanden0]

Can you post your command line? These are my results...

My logs are clean. I use Avisynth+ 3.5.1 and Vapoursynth R49 + Python 3.8.2.

I tried to write encode command on my CMD then it OK, maybe my output of my encode script has problem.

Thank you!

[Sagittaire]

There are test in progess for new option like --aq-hevc?

In my historical test sample (harry potter trailer, 720x304x24 at 450 Kbps and 900 kbps), I have new absolute record (all codec tested and AV1 too) with Overall PSNR

For the first time I have similar score for x264 at 900 kbps and x265 at 450 kbps (at max quality for x264 and x265).

Really impressive ... !!!

[MythCreator]

There are test in progess for new option like --aq-hevc?

In my historical test sample (harry potter trailer, 720x304x24 at 450 Kbps and 900 kbps), I have new absolute record (all codec tested and AV1 too) with Overall PSNR

For the first time I have similar score for x264 at 900 kbps and x265 at 450 kbps (at max quality for x264 and x265).

Really impressive ... !!!

hevc aq is saving bitrates, but in some cases (for me, a scene in snowscape), frames were blur like hell and a lot of block on moving tiny things.

[vpupkind]

hevc aq is saving bitrates, but in some cases (for me, a scene in snowscape), frames were blur like hell and a lot of block on moving tiny things.
What were the resolutions and CTU sizes you were using?
Can you please post an example?
Really interested in seeing whether more edge-oriented modes (hevc-aq, aq=4 and aq=5) can outperform aq=2.

[MythCreator]

What were the resolutions and CTU sizes you were using?
Can you please post an example?
Really interested in seeing whether more edge-oriented modes (hevc-aq, aq=4 and aq=5) can outperform aq=2.

Don't bother lol. I cannot reproduce the same problem with newest x265 with same segment:p

[MeteorRain]

Edited:
I got some strange output when the encoding almost done
1.30 seconds (10.21 fps) fp2s1,5 71 8f1r6a.m8e2s kibn/ s 2 1\r

"fps, 1816.82 kb/s \r"
"2157 frames in 211.30 seconds (10.21 fps)"

Sounds correct to me.

[Boulder]

What were the resolutions and CTU sizes you were using?
Can you please post an example?
Really interested in seeing whether more edge-oriented modes (hevc-aq, aq=4 and aq=5) can outperform aq=2.

I did a small test yesterday, comparing the different aq-modes (5 doesn't exist?) looking frame by frame with 2-pass encodes matching the average bitrate of an AQ1 encode. In CGI content (a scene from the first The Hobbit movie), hevc-aq looked quite good. I remember it was a smoothing disaster when it was introduced so something must have happened during this time.

I'll try to create some more test material to watch in motion and preferably on the TV. The swimming noise anomaly in flat areas is something I want to particularly check.

[Sagittaire]

I did a small test yesterday, comparing the different aq-modes (5 doesn't exist?) looking frame by frame with 2-pass encodes matching the average bitrate of an AQ1 encode. In CGI content (a scene from the first The Hobbit movie), hevc-aq looked quite good. I remember it was a smoothing disaster when it was introduced so something must have happened during this time.

I'll try to create some more test material to watch in motion and preferably on the TV. The swimming noise anomaly in flat areas is something I want to particularly check.

yes... I confirm that --aq-hevc produce the highest OPSNR score I have ever see.

With me little sample test, HEVC outperform AV1 with OPSNR too and by far.

[Boulder]

I tested a rather noisy snippet from Star Trek TNG. Lots of noise in the backgrounds, which was already swimming slightly in the source. It's a nice little trap for any encoder to fall in..

The black borders were cropped, very slight denoising applied and the result downscaled to 720p, all based on my normal process. I tried watching the clips on the 65" TV rather close, at 1.5m or so and also on my monitor but I cannot tell which one looks better or worse in motion. All have problems with the background. And while testing, I remembered why hevc-aq looked like crap -- it was simply dropping the bitrate to about half at the same CRF, so you need to compensate quite a bit to make it look normal.

Out of interest, I ran VMAF at model=1 (4K) against a lossless encode.

# 92.079134 -- aq1
# 93.278654 -- aq2
# 92.794155 -- aq3
# 92.670808 -- aq4
# 93.587815 -- hevc-aq
# 93.539299 -- hevc-aq + selective-sao 2

I have some other clips of varying quality collected which I will also run through the same procedure when I have the time.

You can take a look at the results yourself:
AQ-mode 1 : https://drive.google.com/open?id=17LBbaPn_p7lrISFNUSDQlxgWtI7ki48K
AQ-mode 2 : https://drive.google.com/open?id=1DSIFqbljT9j6jcijOU3fcwDSbIgrNuzM
HEVC-AQ : https://drive.google.com/open?id=1aDhKsaX2Jv9RDGbNy4ErqAtUR5wy_VIa

[benwaggoner]

yes... I confirm that --aq-hevc produce the highest OPSNR score I have ever see.

With me little sample test, HEVC outperform AV1 with OPSNR too and by far.
PSNR is known to be pretty useless for estimating subjective quality of adaptive quantization. Lots of techniques are known to improve subjective ratings while reducing PSNR.

I had it in my head that --hevc-aq was a prototype of what became --aq-mode 4. Are they actually orthogonal? That would suggest 9 aq modes: 0, and 1-4 with and without --hevc-aq.

I note that --hevc-aq is also not listed as "experimental" anymore.

[Boulder]

That would suggest 9 aq modes: 0, and 1-4 with and without --hevc-aq.

All other aq-modes are switched off if hevc-aq is enabled, so there's 5 modes to use (or 6 if you count --aq-mode 0 as one).