x265 HEVC Encoder

[almanteka]

this is my problem: an already encoded HEVC video i try to re-encode using x265 always renders a green screen on the re-encoded version. i just re-encode to shrink the file, but i test it out in placebo preset with the same results! any ideas? thanks in advance for any suggestion.

[Boulder]

Ok, I did some more tests. Not visuals yet, I'll probably get to that later today.

Five different clips:
1) Hot Fuzz, 1220 frames. Lots of movement, bright throughout the clip. Amount of grain or noise on scale 1-10, maybe 8. As with the name, a bit fuzzy with noise but quite detailed-looking (fake detail?)
2) The Hobbit (1st movie), 1286 frames. CGI scene with some camera rotation and lots of tiny shapes as there's a big group of orcses (sic!) moving occasionally. Quite bright and grain maybe 4. Sharpish but a little flat in my opinion.
3) Black Sails, 2748 frames. Handheld camera so constant motion (I hate that myself), both bright and darker parts. Grain maybe low 7. Sharp and detailed.
4) Airwolf, 2246 frames. Very dark, quite static scene. Grain 10. Low detail and sharpness.
5) Star Trek TNG, 972 frames. Mostly static, normal TNG scene without CGI with mid indoor brightness. Grain 9. Average details and sharpness.

(In my VMAF calcs, both lossless and encoded result were upscaled to 4K using a neutral bicubic scaler)

Clip 1, VMAF:
# 98.505242 -- aq1
# 98.706121 -- aq2
# 98.613398 -- aq3
# 98.380210 -- aq4
# 98.959994 -- hevc-aq
# 98.960424 -- hevc-aq + selective-sao 2

Clip 2
# 97.728850 -- aq1
# 97.956894 -- aq2
# 97.853706 -- aq3
# 97.565054 -- aq4
# 98.184379 -- hevc-aq
# 98.008400 -- hevc-aq + selective-sao 2

Clip 3
# 95.415750 -- aq1
# 96.473963 -- aq2
# 96.091077 -- aq3
# 95.763069 -- aq4
# 96.882003 -- hevc-aq
# 96.792992 -- hevc-aq + selective-sao 2

Clip 4
# 93.521912 -- aq1
# 95.005253 -- aq2
# 94.472257 -- aq3
# 94.406745 -- aq4
# 95.198142 -- hevc-aq
# 95.142638 -- hevc-aq + selective-sao 2

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

So, VMAF-wise it looks like hevc-aq is a clear winner. What I found very interesting is that I had to reduce CRF quite a lot to reach the same bitrate aq-mode 1 would spend at CRF 18. The VMAF scores are from 2-pass encodes to match AQ1.

Clip 1: CRF 15.1, avg QP 22.87
Clip 2: CRF 16, avg QP 23.39
Clip 3: CRF 15.1, avg QP 21.25
Clip 4: CRF 13.5, avg QP 20.13
Clip 5: CRF 14.4, avg QP 20.60

What these figures tell me is that hevc-aq reduces bitrate in static scenes substantially. I don't know what to make of it -- will it become a problem when watching things on the TV if I don't want to compensate CRF so much that the scenes with more motion then have overallocated bits.

What I'm going to do next is try finding the CRF value which gives me roughly the same VMAF score as AQ1 does, then watch the result on the TV. Maybe I also need to test extracting bigger chunks, like 1000 frames or so over the duration of the whole episode or movie to average things out a bit.

[sneaker_ger]

this is my problem: an already encoded HEVC video i try to re-encode using x265 always renders a green screen on the re-encoded version. i just re-encode to shrink the file, but i test it out in placebo preset with the same results! any ideas? thanks in advance for any suggestion.
This is probably not a problem of the x265 encoder but with decoding the source file. Open a new thread with more details (software you are using, log, sample file) or ask in the appropriate thread (if it has a dedicated thread on doom9).

[Sagittaire]

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.

Well, by experience, I think that all metric are more or less dependant. I prefer OPSNR for first test because you have simple and real temporal metric. And if you have 1 dB boost with OPSNR, all the other metric will be certainely better too. IMO have the best possible OPSNR is always good first to have for test new fonctionnality and after you test psy option with that.

With your ToS challenge, I seem have better result for all metric (APSNR, OPSNR, SSIM, MSSIM, PSNR-HVS, PSNR-HVS-M, VMAF). Test in progress ... ;-)

[Sagittaire]

Ok, I did some more tests. Not visuals yet, I'll probably get to that later today.
What these figures tell me is that hevc-aq reduces bitrate in static scenes substantially. I don't know what to make of it -- will it become a problem when watching things on the TV if I don't want to compensate CRF so much that the scenes with more motion then have overallocated bits.

What I'm going to do next is try finding the CRF value which gives me roughly the same VMAF score as AQ1 does, then watch the result on the TV. Maybe I also need to test extracting bigger chunks, like 1000 frames or so over the duration of the whole episode or movie to average things out a bit.

1) Well I have similar result.

For higher bitrate in static scene, you have rate control solution.

- Lower bframe number (3 bframe is generaly good in all case)
- Lower bframe quantizer ratio (1.2 or 1.1 for --pbratio)
- Higher rate control compression (0.5 for --qcomp)

--bframes 3 --b-adapt 2 --pbratio 1.10 --qcomp 0.50

2) I test actualy with that personnaly: --tune ssim --hevc-aq --qp-adaptation-range 1.0

good result in all metric.

You can have more strenght for --hevc-aq with --qp-adaptation-range. 1.0 seem optimized seeting for OPSNR but I don't test qp-adaptation-range with VMAF. If you want try.

[Boulder]

Lowering the amount of b-frames to 3 doesn't do much, also setting both ip- and pb-ratio won't raise the bitrate enough to compensate. I'll need to do the more extensive test to extract several chunks of each case and see how the average turns out.

[benwaggoner]

What these figures tell me is that hevc-aq reduces bitrate in static scenes substantially. I don't know what to make of it -- will it become a problem when watching things on the TV if I don't want to compensate CRF so much that the scenes with more motion then have overallocated bits.
Interesting results! Thanks for running those tests.

And now I must Dadsplain things about VMAF.

With VMAF, something like 3 units is a Just Noticible Difference, where 50% of viewers would score a visible difference. The biggest variance in your examples is more like 2.5, so less than half of viewers would even say there was a quality difference. And particularly in the >90, VMAF's subjective correlation gets even weaker. Without double-blind subjective ratings, I'd not be confident about actual percivable quality differences between the modes. I've certainly seen cases where an encoder of the same content with a VMAF two less than another actually looked better.

Testing at at a higher CRF (and thus lower VMAF) where VMAF is more sensitive is more likely to be useful.

Also VMAF itself was trained of clips up to around 10 seconds, IIRC. Trying to rank overall quality for a 10 second by the mean of individual frame metrics is something. But the longer the clip, the less indicitive the mean is, as there is more time for the content itself to vary. 30 second clips aren't too bad. But you can still find cases where, with two clips of the same VMAF, one looks really bad in some shots and really good in others, while another is consistantly mediocre. Viewers defintely prefer consistant mediocrity than wild quality swings. VMAF-per-GOP is a decent compromise, and then looking at the distribution of scores for individual GOPs.

[Boulder]

Interesting results! Thanks for running those tests.

And now I must Dadsplain things about VMAF.

With VMAF, something like 3 units is a Just Noticible Difference, where 50% of viewers would score a visible difference. The biggest variance in your examples is more like 2.5, so less than half of viewers would even say there was a quality difference. And particularly in the >90, VMAF's subjective correlation gets even weaker. Without double-blind subjective ratings, I'd not be confident about actual percivable quality differences between the modes. I've certainly seen cases where an encoder of the same content with a VMAF two less than another actually looked better.

Testing at at a higher CRF (and thus lower VMAF) where VMAF is more sensitive is more likely to be useful.

Also VMAF itself was trained of clips up to around 10 seconds, IIRC. Trying to rank overall quality for a 10 second by the mean of individual frame metrics is something. But the longer the clip, the less indicitive the mean is, as there is more time for the content itself to vary. 30 second clips aren't too bad. But you can still find cases where, with two clips of the same VMAF, one looks really bad in some shots and really good in others, while another is consistantly mediocre. Viewers defintely prefer consistant mediocrity than wild quality swings. VMAF-per-GOP is a decent compromise, and then looking at the distribution of scores for individual GOPs.

Thank you for a thorough explanation. I don't think I've seen anything really explaining the idea in layman's terms.
VMAF was just an idea that came to my mind as one metric which is based on actual watching instead of blind comparison so it was interesting to see what happened.

My normal viewing distance from the 65" is about 3-3.5 metres, quite a lot, so probably I could not tell much of a difference if there were some serious issues. Dancing noise is easier to see instead of slight ringing or blurring in some parts. When I set an acceptable level for the media player stuff, I try to watch it from 2 metres or so to make sure I can live with the results. And then apply a slight headroom to CRF on top. It's something I probably need to do here with hevc-aq (starting from 18 and going down 0.5 at a time) and see what happens.

[benwaggoner]

Thank you for a thorough explanation. I don't think I've seen anything really explaining the idea in layman's terms.
VMAF was just an idea that came to my mind as one metric which is based on actual watching instead of blind comparison so it was interesting to see what happened.
VMAF is absolutely the least-bad metric we've ever had, and they keep updating the model with new tests and refinements, so today's VMAF scores are more accurate than earlier ones (which also means that when we compare VMAF scores, we need to compare using the same model and some other parameters). But machine learning models are only as good as the tests they were trained on. VMAF originally wasn't good at 4K, but then they revised the model with new 4K tests and it became better. VMAF has never been training on HDR content, so its application to HDR isn't clear. And it hasn't been trained on artifacts from upcoming codecs like VVC and EVC; I'm not sure if the current one has even seen AV1 or HEVC.

My normal viewing distance from the 65" is about 3-3.5 metres, quite a lot, so probably I could not tell much of a difference if there were some serious issues. Dancing noise is easier to see instead of slight ringing or blurring in some parts. When I set an acceptable level for the media player stuff, I try to watch it from 2 metres or so to make sure I can live with the results. And then apply a slight headroom to CRF on top. It's something I probably need to do here with hevc-aq (starting from 18 and going down 0.5 at a time) and see what happens.
To resolve 1080p content on a 65" TV with 20/20 vision, those distances are about as far as they can go, but not too far. For 4K content, you'd want to be within 2 meters; no more than 20% farther away than the diagonal screen size.

For full 8K clarity, you need to sit so close to the screen that you can't see the screen's sides.

[KeVe1983]

Hi all,

need a little bit of help.

I'm using Stax and try to encode a Bluray Movie to x265 8 Bit.
The Movie is called Warrior (2011) and has a lot of grain.

I typically encode CRF 20/Slow no tune

My settings:
--preset slow --aq-mode 1 --aq-strength 0.9 --min-keyint 24 -- --deblock -1:-1 --no-sao

But with these settings the output will be big with more than 10 Gigs.

I also tried to read about command line options for x265 but sorry, i dont get it.

So can you guys help and tell me what parameters i need to switch, to get smaller filesizes for movies with grain and obtain quality?

Or should i give it a go with a 2pass encode?

[Boulder]

Hi all,

need a little bit of help.

I'm using Stax and try to encode a Bluray Movie to x265 8 Bit.
The Movie is called Warrior (2011) and has a lot of grain.

I typically encode CRF 20/Slow no tune

My settings:
--preset slow --aq-mode 1 --aq-strength 0.9 --min-keyint 24 -- --deblock -1:-1 --no-sao

But with these settings the output will be big with more than 10 Gigs.

I also tried to read about command line options for x265 but sorry, i dont get it.

So can you guys help and tell me what parameters i need to switch, to get smaller filesizes for movies with grain and obtain quality?

Or should i give it a go with a 2pass encode?

If it's very grainy, you probably need to denoise and/or downscale to a lower resolution if the final size is a concern. You could try a 2-pass encode but results could be ugly. Noise and grain just requires all those bits.
Is there a reason not to encode to 10bit?

[Sagittaire]

Hi all,

I'm using Stax and try to encode a Bluray Movie to x265 8 Bit.
The Movie is called Warrior (2011) and has a lot of grain.



crf and bitrate are not really correlated: at crf 10 with really low frequency and low motion source, you can have lower bitrate than crf 20 with really high frequency and high motion source.

Use two pass or higher crf will produce the same result at same bitrate.

[KeVe1983]

If it's very grainy, you probably need to denoise and/or downscale to a lower resolution if the final size is a concern. You could try a 2-pass encode but results could be ugly. Noise and grain just requires all those bits.
Is there a reason not to encode to 10bit?

Not sure about 10 Bit... Maybe playback issues?
Or will the most soft and hardware player be able to play 10 Bit content right now?

Is a 10 Bit encode the better option in general?
Will there be any difference in output filesize?

Maybe i'll give it a try

[almanteka]

This is probably not a problem of the x265 encoder but with decoding the source file. Open a new thread with more details (software you are using, log, sample file) or ask in the appropriate thread (if it has a dedicated thread on doom9).

thanks for your reply! i change from avisynth to vapoursynth in staxrip and that fix the green screen! don't know why, i'll ask in the staxrip thread! thanks for your reply and help!

[Boulder]

I did more tests with hevc-aq, and the floating noise issue is something which will prevent me from using it. Mind you, also mode 2 suffers from it which is why I still use mode 1 even if 2 is the default.

You can see the problem in the scene right after the start, above the file cabinet. In mode 1, the background noise is more random-like. In mode 2 and hevc-aq -- particularly in hevc-aq -- the noise starts floating around like a dirty screen or something.
That floating thing is also one reason why I tend to denoise very slightly. If you denoise too heavily, the encoder will start creating those because the complexity is not enough to attract bits.

The encode was done by converting to 16 bit depth, resizing with Lanczos to 1280x720 and feeding the result into x265. Encoded at 10bits, dither enabled. I matched CRF in the hevc-aq encode to approximately match aq1's bitrate.

You can give it a go if you like, here are some links:
Original : https://drive.google.com/open?id=1R67JjV6kH5sMPfvPahuyvXP8sZZcISgF
AQ1 : https://drive.google.com/open?id=1EDz4bAiJos7xOD3qIlyIALZ84C5c91Ep
AQ2 : https://drive.google.com/open?id=1wyqdEH20N8FvKpSvWSHPLJPt5T5mSaVu
HEVC-AQ : https://drive.google.com/open?id=1Txv7_rv8Ml7vEwcQKJMk_Qi15_fazzrW

[Stereodude]

I will readily admit in your clips that AQ1 looks subjectively better than AQ2 or HEVC-AQ, but you're feeding VC-1 compression artifacts into the encoder, not a clean source.

I would MCTD that thing right off the bat.

[Boulder]

It's a tough source (bronze tier in the old Blu-ray PQ ranking list), but I would say pretty much average so many sources look similar. Denoising so that all the artifacts are gone is not my choice in these cases, simply because to denoise enough, you also remove quite a lot of the detail and it's easy to get a plastic look throughout the movie.

I'll do another test with Hot Fuzz, which is quite high quality but has some grain. In my quick basic test, there was one scene where grain acted like it was floating on one character's cheek when aq2 or hevc-aq was used.

[microchip8]

I always use AQ1 because it's the most balanced mode. I've tried all others and they suck up bitrates but actually do not improve (that much) the encode so I settled on AQ1 with high values of psy-rd and psy-rdoq, which helps a lot to preserve noise and details but also increases bitrate somewhat (high psy-rd/psy-rdoq is also used in the grain preset and I agree with that). Regardless, my aim is good quality at an acceptable speed (between 3 and 7 fps on my Ryzen 7) for FHD input

What I'm happy about is that I do not need to do any postprocessing (denoise, etc) the original and still get reasonable file sizes at very decent quality. Compared to x264 where I always had to denoise noisy films just so it doesn't blow up the bitrate and file sizes

[benwaggoner]

...but you're feeding VC-1 compression artifacts into the encoder, not a clean source.

I would MCTD that thing right off the bat.
Or use WMV PowerToy to set the optimal WMV postprocessing mode for the source. 5-6 different levels of deblocking and deringing IIRC.

[benwaggoner]

I believe I've found a bug with multipass encoding with --frame-dup. In a two-pass encode, the second pass fails with a "different number of frames in source" error. Which is presumably due to duplicate frames not being coded and/or read properly in the .stats file.

[vpupkind]

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.
They are not orthogonal. They are different ways of accounting for edges and texture sensitivity.
--hevc-aq looks at variances of quartiles
--aq 4 looks at edge pixel variance

[Boulder]

Regarding gq-size, is it generally better to lower it from 32 to 16 when dealing with 720p encodes? If the default was based on 4K, the proportional area covered by qg-size is quite a lot bigger with 720p.

[excellentswordfight]

Regarding gq-size, is it generally better to lower it from 32 to 16 when dealing with 720p encodes? If the default was based on 4K, the proportional area covered by qg-size is quite a lot bigger with 720p.
Default value follows --ctu, so when you lower it qg-size will follow. Or would you like to lower it independant from the CU size? Why?

[microchip8]

I found using a lower qg-size than the CTU one provides worse results. Some visual artifacts are introduced such a mild blocking and smearing. IIRC, qg-size also applies to AQ. YMMY

[Boulder]

Default value follows --ctu, so when you lower it qg-size will follow. Or would you like to lower it independant from the CU size? Why?

There's a long standing misdocumented thing there. The default is always 32 unless CTU is less than that even if the docs say that it's the same as CTU.

And yes, I was thinking if there is any use to lower the size due to the frame size being so much smaller but I'll keep it as it is.

[filler56789]

x265.exe 3.3+24-37916f420742

http://www.mediafire.com/file/olxjiosjggqh0er/x265_3.3%252B24-37916f420742.rar/file

[benwaggoner]

x265.exe 3.3+24-37916f420742

http://www.mediafire.com/file/olxjiosjggqh0er/x265_3.3%252B24-37916f420742.rar/file
Nice! Looks like it fixes the multilib issue seen earlier and adds improved quality for 2-pass CBR encoding.

[Patman]

I've updated x265 too, link is in my sig.

[almanteka]

I've updated x265 too, link is in my sig.

can't find x265.exe 3.3+24-37916f420742 in your signature links! thanks in advance for any help!

[Patman]

can't find x265.exe 3.3+24-37916f420742 in your signature links! thanks in advance for any help!I use the git source (not hg source) and there the build number is a bit different. Download x265-3.3+22-gde09ab80e build, it's the same.

[filler56789]

I use the git source (not hg source) and there the build number is a bit different.

Could you please tell us what is your "trick"?
https://bitbucket.org/multicoreware/x265_git/commits/ does not list de09ab80e :confused:

[Patman]

Could you please tell us what is your "trick"?

https://bitbucket.org/multicoreware/x265_git/commits/ does not list de09ab80e :confused:The mirror on github based on hg source (https://github.com/videolan/x265)

The Synchronisation between https://bitbucket.org/multicoreware/x265 and https://bitbucket.org/multicoreware/x265_git doesn't work properly

[filler56789]

The mirror on github based on hg source (https://github.com/videolan/x265)

Thanks! :thanks:

The Synchronisation between https://bitbucket.org/multicoreware/x265 and https://bitbucket.org/multicoreware/x265_git doesn't work properly

And probably the x265 devs themselves are not very fond of git...

[LoRd_MuldeR]

And probably the x265 devs themselves are not very fond of git...

If the ywant to continue to use Bitbucket, they'll have to migrate to Git tough:
https://hub.packtpub.com/bitbucket-to-no-longer-support-mercurial-users-must-migrate-to-git-by-may-2020/

[almanteka]

I use the git source (not hg source) and there the build number is a bit different. Download x265-3.3+22-gde09ab80e build, it's the same.

thanks!

[stax76]

Sorry to repost, MediaInfo.NET supports a special presentation for x265 parameters, it can be enabled in the settings.

Meanwhile, it was ported to run on .NET Framework 4.8 (so people don't need to install .NET Core) and it has a PowerShell based folder view.

https://github.com/stax76/MediaInfo.NET

https://forum.doom9.org/showthread.php?t=176886

https://i.postimg.cc/0Q3RNTMD/image.png

[Blue_MiSfit]

Hey that's really neat! Thanks for adding this ^ :)

[filler56789]

x265.exe 3.3+26-193db49

http://msystem.waw.pl/x265/

Fix bug in frame-dup + multi pass

Add save-load regression test CLI for Frame Duplication

[Patman]

Updated to version x265-3.3+25-ga6489d2fb (git source). See my sig

[Sagittaire]

x265.exe 3.3+26-193db49

http://msystem.waw.pl/x265/

Fix bug in frame-dup + multi pass

Add save-load regression test CLI for Frame Duplication

Well seem don't change anything. I make test for benwaggoner encoding challenge and I must make 3 pass to have good rate control. 2 pass encoding have too agressive quantizer curve compression at the start of encoding.

[tuanden0]

Updated to version x265-3.3+25-ga6489d2fb (git source). See my sig

Thank for your build :D

[filler56789]

x265.exe 3.3+29-1e3dbf0

--- Cleanup
--- save-load-tests: Fix CLI
--- EQT Updates.

1. Improves documentation in help and x265readthedocs for rskip cli options.
2. Renamed rskip variable in x265_param structure & rectified regression clis.
3. Removed rskip mode 3 which is same as mode 2 with min-cu-size 16.

http://msystem.waw.pl/x265/

[Patman]

Updated (git source):

x265-3.3+4-g6a7df3229-* (marked as 3.4 branch, but the version shows 3.3+4 / maybe stable) [* built with msvc1925 and gcc11.0.0]
x265-3.3+27-g4780a8d99-* (master branch) [* built with msvc1925 and gcc11.0.0]

Downloadlink, see my sig

[RainyDog]

Updated (git source):

x265-3.3+4-g6a7df3229-* (marked as 3.4 branch, but the version shows 3.3+4 / maybe stable) [* built with msvc1925 and gcc11.0.0]
x265-3.3+27-g4780a8d99-* (master branch) [* built with msvc1925 and gcc11.0.0]

Downloadlink, see my sig

Thanks for your builds as always :)

Is there a reason why they no longer support raw .avs (no piping) input?

[Patman]

Thanks for your builds as always :)



Is there a reason why they no longer support raw .avs (no piping) input?You're welcome. My builds have never supported direct avs input. Maybe I will add avs input support in future releases.

[stax76]

Are there builds that support both avs and vpy? libavformat supports both, that's how mpv opens avs and vpy, but does not support portable mode, blocks DLL loading from path env var.

[RainyDog]

You're welcome. My builds have never supported direct avs input. Maybe I will add avs input support in future releases.

Hmm, I was sure there was a point last year when I had the piping tool option set to none in StaxRip across the board. Unless it was just with my x264 set-up...

In any case, be good if you can make your x265 builds work with raw input too. Thanks :)

[Patman]

Hmm, I was sure there was a point last year when I had the piping tool option set to none in StaxRip across the board. Unless it was just with my x264 set-up...



In any case, be good if you can make your x265 builds work with raw input too. Thanks :)Yeah, x264 support that. I do my best and give you a feedback [emoji6]

[RainyDog]

Yeah, x264 support that. I do my best and give you a feedback [emoji6]

Thanks :)

I've now remembered how I was previously using raw input with x265... It was when Stax was using Wolfberry's builds. So seems it is possible to implement at least, unless something's changed with x265 itself since then.

I'll leave it in your capable hands anyway :p

[MeteorRain]

Direct AVS input was there for a while. x265 official denied my attempt to enhance the I/O part, so I have been keeping all patches out of the tree.

No one wrote direct VPY input so far.