x265 HEVC Encoder

[littlepox]

Originally Posted by Motenai Yoda

merange 24 - 2.91fps, 51765.78kbps, psnr 35.228, ssim 12.801
merange 57 - 3.02fps??, 51685.29kbps, psnr 35.227, ssim 12.801

Crazy. My test earlier showed a 30% time reduce for me_range 57->25. I'd re-test to see what's the pattern.

Originally Posted by Motenai Yoda

Yep on non-edge areas there is a bit of loss, source's screenshot are yet denoised?

The source is from Blu-Ray and without any pre-processing. I know I should post screenshots about after-denoise-pre-encoding vs encoded, but I don't have the time so I used the one prepared earlier on. Anyway, since we know x265 is going to blur the non-edge areas, it does not make too much difference.

Originally Posted by Motenai Yoda

I also notice an artefact near chest on #5 (edit preceded by mandarinka)

see my reply above

Originally Posted by Motenai Yoda

Sometimes I have to remove (did u see Urusei Yatsura?), sometimes I have to add..

I hope they port aq3 and aq4, or something like triaq...

Yep. Pre-processing should be considered on individual basis, and generally I would say, the more grain you wish to keep, the less recommended you use x265.

I'm also looking forward to some improvements. I hope I'd use x265 to encode some movies, concerts @ near-transparent level, but it really disappointed me to show its incompetence after hundreds of tests.

[Lyris]

Originally Posted by x265_Project

The NAB show starts Monday. We have a private suite where we'll have some great demos of our latest capabilities including real-time 4K encoding, high quality offline encoding, and decoding on a variety of platforms including tablets. We look forward to discussing our product roadmap with all of our customers and partners, and learning more about their plans and requirements.

If you're going to the NAB show, and you'd like to meet up, email me (tom.vaughan at multicorewareinc dot com). The x265 team's meeting schedule is nearly packed from 8 am to 6 pm every day, but we have a couple of slots open on Tuesday and Wednesday. I'll also be at Ben's Compressionist's party Tuesday night, but it looks like I'll get there a bit late.

Aaack! If I'd known about either of those events I'd have loved to have stopped by. Next year?

[LigH]

x265 1.6+239-5c3443546ccc

News: Support for SMPTE ST 2086 (HDR / Wide Gamut display metadata) and piping reconstructed video to a Y4M viewer.

[RBX]

What exactly is the use of lookahead? I've been trying to encode some anime. I've been using a value of 32, and increasing it to 60 increased the output size, and setting it back to 20 produced size lower than that by 32.

[benwaggoner]

Originally Posted by RBX

What exactly is the use of lookahead? I've been trying to encode some anime. I've been using a value of 32, and increasing it to 60 increased the output size, and setting it back to 20 produced size lower than that by 32.

I would expect that lookahead would be particularly helpful with anime, as you'll get cu-tree, the equivalent of x264's mbtree. MBtree was a HUGE win for anime when it came out, as it was able to figure out what parts of a frame were reused in future frames, and make sure that bits went to making them high quality back in the IDR they first apperared.

Even if the size varies some, you should visually verify you're getting the same visual quality.

If long lookahead is actually harmful, you should file an issue with a repro over at the x265 bitbucket.


-Ben Waggoner (via TapaTalk)

[Motenai Yoda]

Originally Posted by littlepox

Crazy. My test earlier showed a 30% time reduce for me_range 57->25. I'd re-test to see what's the pattern.

Indeed I was testing with me hex and subme 2, not me star and subme 5.

Originally Posted by littlepox

The source is from Blu-Ray and without any pre-processing. I know I should post screenshots about after-denoise-pre-encoding vs encoded, but I don't have the time so I used the one prepared earlier on. Anyway, since we know x265 is going to blur the non-edge areas, it does not make too much difference.

Yep but may seem like a sneaky behavior lead to reference screenshots from non denoised source vs denoised encode ones, especially when you're complaining about x265's grain retention.

[foxyshadis]

Originally Posted by RBX

What exactly is the use of lookahead? I've been trying to encode some anime. I've been using a value of 32, and increasing it to 60 increased the output size, and setting it back to 20 produced size lower than that by 32.

CRF comparisons are only meaningful when you don't change anything else. If you do, you have to adjust CRF to get the same file size and look at the visual quality, unless you're capable of judging visual quality vs file size. Sorry, there are no shortcuts to actually watching.

If you aren't willing to watch and compare, there's not much choice but to accept the results. My gut feeling is that the larger size is balanced out by better quality, but I don't know that for sure.

[benwaggoner]

I'm pleased to see that fine grain adaptive quant is checked back in: http://x265.readthedocs.org/en/defau...ption--qg-size

Originally Posted by benwaggoner

I'm pleased to see that fine grain adaptive quant is checked back in: http://x265.readthedocs.org/en/defau...ption--qg-size

Me too... but I think it still needs fine tuning. In my initial tests I see lots of things that I like (with respect to visual quality), and some things that I'm less sure of. More testing and tuning is needed before fine-grained AQ can be incorporated into our default settings with confidence. Feedback on combinations of AQ mode, AQ strength and QG Size that seem to work best would be welcomed from the x265 community.

[divxmaster]

Originally Posted by benwaggoner

I'm pleased to see that fine grain adaptive quant is checked back in: http://x265.readthedocs.org/en/defau...ption--qg-size

I cant get qg-size 16 to make any difference at all. Byte output is identical with or without qg-size 16. This is using preset slow, so default qg-size should be 64 if not specified.

Using 1.6+239. It accepts the parameter fine and show it as a valid parameter in --help. Am I missing something, is it somehow not enabled +239 build?

params: --crf 20 --preset slow --sar 222:145 --rdoq-level 1 --min-keyint 23 --keyint 240 --pmode --deblock -3:-3 --psy-rd 0.5 --qg-size 16

Cheers,
Divxmaster

Originally Posted by divxmaster

I cant get qg-size 16 to make any difference at all. Byte output is identical with or without qg-size 16. This is using preset slow, so default qg-size should be 64 if not specified.

Using 1.6+239. It accepts the parameter fine and show it as a valid parameter in --help. Am I missing something, is it somehow not enabled +239 build?

params: --crf 20 --preset slow --sar 222:145 --rdoq-level 1 --min-keyint 23 --keyint 240 --pmode --deblock -3:-3 --psy-rd 0.5 --qg-size 16

Cheers,
Divxmaster

The command line option was added on April 6th, but the function was disabled on April 7th (leaving the API and command line option in place) until April 17th, when it was re-enabled.

Changeset:
10225 (3ebf02051ca0) AQ: Re-enable fine grained adaptive quantization

So you need to get a newer build. You'll see the QG size reported on the console when it's enabled (same line as AQ mode and strength).

Try QG-Size 32 also... you may like the results better than QG-Size 16, at least for now.

[divxmaster]

Originally Posted by x265_Project

The command line option was added on April 6th, but the function was disabled on April 7th (leaving the API and command line option in place) until April 17th, when it was re-enabled.

Changeset:
10225 (3ebf02051ca0) AQ: Re-enable fine grained adaptive quantization

So you need to get a newer build. You'll see the QG size reported on the console when it's enabled (same line as AQ mode and strength).

Try QG-Size 32 also... you may like the results better than QG-Size 16, at least for now.

Ah ok, got it. Yes I knew about it being pulled, but wasn't aware it was still in the CLI! Thanks. Hopefully LigH can compile soon. 1.6+239 build was posted 20 Apr, but I guess that source was < 17 Apr? Will try that qgsize 32. Cheers.

[MeteorRain]

Originally Posted by divxmaster

Ah ok, got it. Yes I knew about it being pulled, but wasn't aware it was still in the CLI! Thanks. Hopefully LigH can compile soon. 1.6+239 build was posted 20 Apr, but I guess that source was < 17 Apr? Will try that qgsize 32. Cheers.

If you don't mind, you can give my build a shoot.

[divxmaster]

Originally Posted by MeteorRain

If you don't mind, you can give my build a shoot.

@MeteorRain, thanks will give it a try

While waiting for the fine grained AQ patch, Ive been doing some testing in the other direction, which
is creating x265 for mobile devices, seeing how low a bitrate can be used, but still with good quality.
Note this is for mobile devices, screen sizes I have are 4-10.1 inch.

Using params (thanks @burfadel):
--crf 28 --preset slow --b-intra --ref 5 --bframes 5 --max-merge 5 --nr-intra 400 --nr-inter 400 --sar %sar% --no-open-gop --min-keyint 23 --keyint 288 --pmode --deblock -1:-1

The resultant bit rates can only be described as incredible (all 10 bit x265):

sg1 s03e06 720x480 ntsc Bitrate 116kbps! *tivtc and qtgmc via 64bit vapoursynth
sg1 s03e07 720x480 ntsc Bitrate 241kbps
sg1 s03e08 720x480 ntsc Bitrate 173kbps
Irobot DVD 712x440 pal Bitrate 233kbps
k9 Pi DVD 712x552 pal Bitrate 162kbps

Quality is great on small screen sizes, and more importantly file size is miniscule, which is needed
for current microsd card sizes. These bitrates would mean all 10 seasons of sg1 would fit in
12-15gb!.

Cheers,
Divxmaster

[divxmaster]

Originally Posted by x265_Project

The command line option was added on April 6th, but the function was disabled on April 7th (leaving the API and command line option in place) until April 17th, when it was re-enabled.

Changeset:
10225 (3ebf02051ca0) AQ: Re-enable fine grained adaptive quantization

So you need to get a newer build. You'll see the QG size reported on the console when it's enabled (same line as AQ mode and strength).

Try QG-Size 32 also... you may like the results better than QG-Size 16, at least for now.

I done some preliminary testing using --qg-size 32, and the results are not quite what I was expecting. The file size is 3% smaller than using qg-size 64. I thought 32 was to retain more detail so the bitrate should be higher?

Another weird thing, when comparing +239 (qg disabled) vs +275 (qg 64), the new +275 file is bigger. I would have thought the file size shouldn't have changed, as the fine grained patch only started working on <64 ctu? (ok, its only .3% bigger).

These test are on 576p, 1080p may be way different.

Cheers,
Divxmaster

[LoRd_MuldeR]

Originally Posted by divxmaster

I done some preliminary testing using --qg-size 32, and the results are not quite what I was expecting. The file size is 3% smaller than using qg-size 64. I thought 32 was to retain more detail so the bitrate should be higher?

As always: If you want to compare different settings, then you have to ensure that the files come out at the same size. If you visually compare files of different size, your comparison will be biased! For example, if one of the files comes out larger, but also looks better, what do you learn? Did the particular setting that you were testing with this file actually improve something? Or does the file just look better because it ended up using more bits? Well, you just don't know!

Note that you can always improve quality, simply by increasing the bitrate - or vice versa. No need to change any settings (except the target bitrate) for that! The whole point about testing different settings is to figure out whether a particular setting improves quality at the same bitrate (same file size). Or, equivalently, whether it can retain the same quality at a lower bitrate (smaller file size). But the latter is more difficult to test, which is why we compare files of identical size.

[foxyshadis]

Originally Posted by divxmaster

I done some preliminary testing using --qg-size 32, and the results are not quite what I was expecting. The file size is 3% smaller than using qg-size 64. I thought 32 was to retain more detail so the bitrate should be higher?

Another weird thing, when comparing +239 (qg disabled) vs +275 (qg 64), the new +275 file is bigger. I would have thought the file size shouldn't have changed, as the fine grained patch only started working on <64 ctu? (ok, its only .3% bigger).

These test are on 576p, 1080p may be way different.

Cheers,
Divxmaster

That's not the only thing that's changed. There's a new lowres MVP predictor method, a new cost function for fast profiles, plus I think all the new QG code does slightly change AQ output even when it's still at 64.

Originally Posted by foxyshadis

That's not the only thing that's changed. There's a new lowres MVP predictor method, a new cost function for fast profiles, plus I think all the new QG code does slightly change AQ output even when it's still at 64.

Yes, we are still working on fine-grained AQ, and we are working to see if we can improve all AQ modes. QG-size is still experimental.

[divxmaster]

Originally Posted by foxyshadis

That's not the only thing that's changed. There's a new lowres MVP predictor method, a new cost function for fast profiles, plus I think all the new QG code does slightly change AQ output even when it's still at 64.

@foxyshadis & @x265_project,
ah, ok, thanks, that explains what is going on. Well let the testing begin. fine grained aq shows promise already for my low bitrate encodes detailed a few posts up. Visual comparison of specific 'hard to encode' areas, that I noted when fine tuning the params, look visually the same using qgsize32, but @ 3% smaller size.

Edit: looking at the samples on a bigger screen, the qgsize32 is actually better. Some obvious banding in one area under qg64 is gone under qg32. nice.

Cheers,
Divxmaster

[stax76]

avs reading support would be great for AviSynth+ 64-Bit users and tool makers.