x265 HEVC Encoder

[foxyshadis]

CRF and 2-pass ABR will differ significantly without lookahead, but disabling lookahead disables so many useful features that there's a good reason only the zero-latency profile does. Technically 2-pass always gets the benefit of a near-infinite lookahead, and therefore some choices will differ, but realistically the benefit of larger lookahead falls off pretty quickly.

Originally Posted by benwaggoner

Ah, it's a two parter. https://bitbucket.org/multicoreware/...161be79dec6062.

Hopefully we'll get an updated description about how CRF works when this is finished.

Based this code:

    CHECK(param->rc.rfConstant < -6 * (param->internalBitDepth - 8) || param->rc.rfConstant > 51,
          "Valid quality based range: -qpBDOffsetY to 51");

it looks like they're aiming to make crf as close as possible between the two. Last week I could bank on a +5-6 crf for 10bit pretty reliably, but I bet that's changing.

[Sagittaire]

yeap, and the sky is blue. We're talking about 1-pass VBR.

false ... 1

crf and 2 pass produce exactly the same visual quality for x264 (not bit to bit ... but almost). And xxxxx never talk about ABR 1 pass for the encoding but just 900 kbps encoding. Sorry.

That's obviously wrong. Since encoder doesn't know what lies ahead it can't produce constant quality. That means that some parts of the video will waste bitrate, while others will starve.

false ... 2

really false. You can get "constant quality" with simple constant quantizer mode. Moreover there are predictibility in crf mode with lookahead (for I,P,B,b decision for exemple). 1 pass quality mode (like crf or quant mode) mean simply impossible final bitrate prediction and anything else. Sorry.

What? Do you know what VBV does? It limits peak bitrate, and doesn't let encoder use bitrate it wants. It prevents encoder from encoding with constant quality.

false ... 3

Not really. And I know very, very, very well how VBV work. VBV is little more complexe. It's the only exemple where multipass can be really usefull but you must have really complex Rate Control. Multipass can help to have really optimal Buffer management and obtain more constant quality. Sorry.


I'am french and it's world cup. and 1 ... and 2 ... and 3 ... 0 for me.

[xooyoozoo]

Originally Posted by foxyshadis

Technically 2-pass always gets the benefit of a near-infinite lookahead, and therefore some choices will differ, but realistically the benefit of larger lookahead falls off pretty quickly.

Speaking of 2-pass and "infinite" lookahead, I wonder if the x265 dev team has considered moving beyond frame parallelism.

I'm talking about something slightly more elegant than the GOP-parallelism x265 used to do, as after the 1st encoding pass, the encoder should have enough information to cleanly split up the stream at nice cutpoints. Something like this old program... but actively developed.

Scene-parallelism seems like a nice answer HEVC's inherently poorer granularity compared to AVC. It also helps encoding scale pass NUMA barriers and helps prepare for the future of increasingly less-hamstrung Atom designs as well as rising core counts for workstations. A consequence here would be much greater RAM usage, but as long as the feature is opt-in or heuristically activated, it's not as much of a sin as idle resources.

Anyway, this is just something I've been pondering in the face of x265 not using all cores when the source needs few b-frames or has low vertical resolution (stupid 2.35 aspect ratio). On a 2P server, I've played around with scripting something that decodes the entire stream in ffmpeg with '-vf select='gt(scene\,0.4)', greps the log output for scenecut frame nums, launches encodes with the frame ranges, and uses taskset to change the pids's socket affinity. However, it's still inelegant to have to decode the source more times than necessary.

[nandaku2]

Originally Posted by benwaggoner

Ah, it's a two parter. https://bitbucket.org/multicoreware/...161be79dec6062.

Hopefully we'll get an updated description about how CRF works when this is finished.

Hi,
The CRF patch removed an-almost-bug that was adding bit-depth offsets to the QP twice. As mentioned in the commit message, Ratecontrol does not worry about bitdepth-offsets, that's added in TComTrQuant.

[xxxxx]

Originally Posted by Sagittaire

crf and 2 pass produce exactly the same visual quality for x264 (not bit to bit ... but almost). And xxxxx never talk about ABR 1 pass for the encoding but just 900 kbps encoding. Sorry.

I know the difference between ABR 1pass and cfr, i used cfr of course, sorry, i generated a little bit of flame.
I did some test with cfr25 and the result bitrate was between 600-2400 Kbps so my point was i'm waiting for the 2pass encoding.

[LigH]

Just to confirm the already obvious: By "1-pass bitrate based encodes" I meant ABR, not CRF.

IMHO, there are only few reasons to choose ABR mode (e.g. limited bandwidth). In general, the more freedom the encoder has to vary the bitrate according to the complexity of the scene, the better the quality can be preserved equally. Therefore, quality tests should not use ABR mode, because the quality will vary a lot from scene to scene, and trolling affine people will select the worst scenes to complain.

[Motenai Yoda]

Originally Posted by Sagittaire

Not really. And I know very, very, very well how VBV work. VBV is little more complexe. It's the only exemple where multipass can be really usefull but you must have really complex Rate Control. Multipass can help to have really optimal Buffer management and obtain more constant quality. Sorry.

? how decreasing bitrate/quality into high bitrate scenes, and increasing it into low bitrate scene to compensate, will make a costant quality encode (2-pass vbr) more constant quality?

[LigH]

The difference between encoding with and without VBV rate control is unrestricted VBR (CRF) vs. restricted VBR (CRF with limits based on the estimated decoder buffer utilization).

[Dark Eiri]

Simulating real world streaming usage would be like we have now, right? 1080p @ 3.5 Mbps / 720p @ 2.5 Mbps? Does x265 look better than x264 in -medium vs -medium at the moment with these rates?

Originally Posted by nandaku2

Hi,
The CRF patch removed an-almost-bug that was adding bit-depth offsets to the QP twice. As mentioned in the commit message, Ratecontrol does not worry about bitdepth-offsets, that's added in TComTrQuant.

FYI - nandaku2 is the engineering manager for x265.

[benwaggoner]

Originally Posted by Dark Eiri

Simulating real world streaming usage would be like we have now, right? 1080p @ 3.5 Mbps / 720p @ 2.5 Mbps? Does x265 look better than x264 in -medium vs -medium at the moment with these rates?

With appropriate tuning, it does in my tests.

[Motenai Yoda]

Originally Posted by LigH

The difference between encoding with and without VBV rate control is unrestricted VBR (CRF) vs. restricted VBR (CRF with limits based on the estimated decoder buffer utilization).

Yep but when it's limiting at some high bitrate scenes it lowers quality for these scenes, also to compensate aiming at target bitrate it will increase bitrate/quality on the other ones.
Assuming 2pass w/o vbv is costant quality (that isn't 'cause qcomp rarely will be set to 1), with vbv will be no more constant, but less.

[benwaggoner]

Some thoughts on today's "how to test and compare" discussions:

Obviously different scenarios have different needs for encoding type. But certainly an ABR + VBV encode is a very common case for many applications, and is supported by essentially all encoders. It works well for apples-to-apples comparison, and does a nice job of highlighting how different sorts of scenes encode within the same file. Note that if rc-lookahead is longer than the maximum number of frames that could be in a VBV, 1-pass and 2-pass should offer essentially identical results.

This is probably the easiest way to get clear comparisons between x264 and x265 today. Of course, other parameters don't map linearly, like --psy-rd, psychovisual tuning modes like --tune film, --rdpenalty, and --preset.

So a real comparison of where the codecs stand today would have to figure out what the optimal perceptual quality settings are for each are. Given how fast x265 is moving, we could have a defined x264 encode as a reference, and then watch how x265 matches that as builds progress.

[upyzl]

sorry to insert another topic about x265 question, but I want to confirm...

Does now x265 8bpp using high-bit internal-precision(e.g. 12bit internal-precision) for encoding?
x264 10bpp takes advantage over than x264 8bpp mostly because its 10bit internal-precision though 8bit original input/10bit output
I noticed HEVC has IBDI(Internal bit depth increase) in 2012, but haven't seem in nowadays...

Originally Posted by upyzl

sorry to insert another topic about x265 question, but I want to confirm...

No problem.

Does now x265 8bpp using high-bit internal-precision(e.g. 12bit internal-precision) for encoding?

No. The 8 bit per sample build of x265 uses 8 bits of internal precision.

[nandaku2]

Originally Posted by x265_Project

No problem.

No. The 8 bit per sample build of x265 uses 8 bits of internal precision.

x265_Project and upyzl,

x265 works like x264 in this regard. You could build x265 with HIGH_BIT_DEPTH on, and use this for encoding 8-bit input video. This build (x265-16bpp) will use higher bit depth precision in the encoder internals.

[LigH]

I still wonder why HIGH_BIT_DEPTH builds of x265 are smaller than the 8 bit per component builds, so they seem to lack of other features?

[Kurtnoise]

you mean, smaller in size or something else ?

[Sagittaire]

Originally Posted by LigH

I still wonder why HIGH_BIT_DEPTH builds of x265 are smaller than the 8 bit per component builds, so they seem to lack of other features?

Pehaps the code itself is less complex (just SSE low level implementation for exemple)

[LigH]

Yes. I compile the same sources with MinGW GCC 4.8.2 with different options, and after stripping, e.g. the following executable sizes in byte are reported:

x265.exe for Win32:
2270208 B (-DWINXP_SUPPORT=1)
2107392 B (-DWINXP_SUPPORT=1 -DHIGH_BIT_DEPTH=1)

x265.exe for Win64:
2816512 B (-DCMAKE_TOOLCHAIN_FILE=toolchain-x86_64-w64-mingw32.cmake)
2748928 B (-DCMAKE_TOOLCHAIN_FILE=toolchain-x86_64-w64-mingw32.cmake -DHIGH_BIT_DEPTH=1)

There is probably some more elaborate code in some routines for low bit depths only.