x265 HEVC Encoder

[benwaggoner]

Since when 1-pass is multipass?
A CRF encode is essentially the same as a 2-pass VBR encode targeting the same average bitrate. The first pass of a 2-pass encode can be thought of (although it does more than) determining the CRF value that will provide the specified average bitrate.

[benwaggoner]

I saw this commit from last night:
https://bitbucket.org/multicoreware/x265/commits/3a19a9fdb103979e65a9daf15c46c0735e8d743e

ratecontrol: [CHANGES OUTPUT for 10-bit CRF] Remove QP_BD_OFFSET from Ratecontrol

This offset is added inside Quant (setQPforQuant)

Is this just refactoring, or will it have any impact on what a particular CRF value does in 10-bit mode?

One x264 feature I miss in x265 is that 8-bit and 10-bit CRF values are generally equivalent. x265 needs a substantially higher CRF in 10-bit than in 8-bit mode.

[vivan]

A CRF encode isPlease check the post I was quoting.

[Sagittaire]

Low complexity? Yeah, crowdrun and parkjoy have really low complexity.
And what is "profil encoding"?

Since when 1-pass is multipass?

.... etc etc etc

Crowdrun and parkjoy are really really really particular source. And x264 is particulary well tuned for make good encoding with these source (DS work hard on parkjoy with x264). If you want compare x264 and x265 don't use it. When I compare x264 and x265, I make complete movie or long trailer encoding with really various type scene and not only really short scene like Crowdrun and parkjoy.

[Sagittaire]

Please check the post I was quoting.

well ... please check the post I was quoting too ... lol

A claim without proof and details, impossible to evaluate its meaning. And 1-pass bitrate based encodes provide worst quality distribution anyway

crf 1 pass mode encoding produce exactly the same output quality than multipass mode without final bitrate prediction. Multipass mode is usefull only for bitrate prediction and not for produce better quality. You can have better quality distribution only in one case: multipass VBR with VBV constraint but it's only for really advanced Rate Control.

[benwaggoner]

I saw this commit from last night:
https://bitbucket.org/multicoreware/x265/commits/3a19a9fdb103979e65a9daf15c46c0735e8d743e
Ah, it's a two parter. https://bitbucket.org/multicoreware/x265/commits/c8973aec5e708d431ffd3f59fa161be79dec6062.

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

[vivan]

crf 1 pass mode encoding produce exactly the same output quality than multipass mode without final bitrate prediction.yeap, and the sky is blue. We're talking about 1-pass VBR.

Multipass mode is usefull only for bitrate prediction and not for produce better quality.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.

You can have better quality distribution only in one case: multipass VBR with VBV constraint but it's only for really advanced Rate Control.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.

[cyberbeing]

vivan, you seem to be thinking of 1-pass ABR (Average Bitrate) which indeed will produce worse quality than 2-pass.

This is not true for CRF (Constant Rate Factor) which produces identical quality to 2-pass, in the time of a 1-pass encode. At least in x264, CRF mode and 2-pass will theoretically produce identical encodes if the bitrate is matched exactly. Unless you require strict VBV or an exact file size, there is no reason to waste time on 2-pass with x264. If the same holds true for x265's future 2-pass mode, will depend on how they choose to implement it.

[vivan]

vivan, you seem to be thinking of 1-pass ABR (Average Bitrate) which indeed will produce worse quality than 2-pass.Of course, because that's what original quote is about!
A claim without proof and details, impossible to evaluate its meaning. And 1-pass bitrate based encodes provide worst quality distribution anyway.

[cyberbeing]

A claim without proof and details, impossible to evaluate its meaning. And 1-pass bitrate based encodes provide worst quality distribution anyway.
Of course, because that's what original quote is about!

The context of LigH's post (1-pass ABR = worse quality) was about how xxxxx's post lacked details about how his encodes at 900kbps were created. If 1-pass bitrate (ABR) was used at very low bitrates, x264 quality in particular would be crippled. This is why Sagittaire responded in agreement with LigH, that indeed CRF is a superior quality alternative to ABR when performing a 1-pass encode. In the context of doing quality comparisons, ABR mode should not be used. Since x265 does not support 2-pass yet, that means using CRF, and then matching the bitrate with x264 2-pass.
crf mode produce exactly the same output quality than multipass mode ... without bitrate predictibility anyway.

Your response to Sagittaire then made it sound like you didn't realize CRF (1-pass VBR) has the same quality as multipass encodes.
Since when 1-pass is multipass?

I assume English is not your first language, since the context of Sagittaire's post was 'CRF (1-pass VBR) quality', while "Since when 1-pass is multipass?" would be then be commonly interpreted as "Since when is single-pass CRF quality equivalent to multi-pass quality?" which now obviously seems to not be what you intended. Anyway, it sounds like this was all a misunderstanding. Hopefully this clears up why everyone was responding to your posts how they were.

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

Ah, it's a two parter. https://bitbucket.org/multicoreware/x265/commits/c8973aec5e708d431ffd3f59fa161be79dec6062.

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]

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 (http://www.funknmary.de/bergdichter/projekte/index.php?page=ELDER)... 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 (http://www.realworldtech.com/knights-landing-details/2/) Atom designs as well as rising core counts (http://i.imgur.com/kMKfFRN.png) 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]

Ah, it's a two parter. https://bitbucket.org/multicoreware/x265/commits/c8973aec5e708d431ffd3f59fa161be79dec6062.

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]

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]

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?

[x265_Project]

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]

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]

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

[x265_Project]

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]

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]

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.

[upyzl]

I see, thank for replys :)

[LoRd_MuldeR]

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?

Noticed that too. Maybe the optimized assembler code, that exists for many of the "critical" functions, is currently for 8-Bit only and thus won't be included in HIGH_BIT_DEPTH builds.

[a5180007]

Hi folks,

First of all thanks to MCW for the works they are doing, and to you all for this great post. It's pretty amazing to see how fast x265 development is evolving.

I thought the following personal tests could be of interest for the community.

x265 is 32 bits 8bpp 1.1+88

Source : One minute excerpt from Lionsgate's Bluray 'BrainDead' (1992) (https://drive.google.com/file/d/0B4QaEqxOEYWvTmJjVXpVSmlyeFk/edit?usp=sharing). It has grain, leaves, hair, skin, and even at 18 Mbps it has been starved.

x264 medium no-psy CRF23 (https://drive.google.com/file/d/0B4QaEqxOEYWvS05KX0xROUQtbmc/edit?usp=sharing) vs x265 medium CRF 21.26 (https://drive.google.com/file/d/0B4QaEqxOEYWvODgtS3U4T0xXSTA/edit?usp=sharing)
Here x265 has achieved the milestone of being better than x264 with default presets (psy-rd excluded, until it has been finalised).
Above CRF23 there are lower resolutions where x264 would look better on a FHD screen, so there is little point in compressing x264 above CRF23.
What I don't understand is both have same keyint min/max and scenecut, but x264 has 20 I-frames whereas x265 has 13?
How can I make sure both encodes have the same number of I-frames?

x265 1080p medium CRF 28 (https://drive.google.com/file/d/0B4QaEqxOEYWvTXJzbDhHT0Y3Qjg/edit?usp=sharing) vs x265 896p medium CRF 25.96 (https://drive.google.com/file/d/0B4QaEqxOEYWvdWFPMm1GTjNuUVU/edit?usp=sharing)
The CRF 28 shows a great amount of artifacts, ringing and blocking. The reduced 896p resolution looks slightly better than the 1080p on a full HD screen. So it makes me wonder whether the default RF 28 is not too high?
EDIT : downscale with Repair(BicubicResize(clip,h,v),GaussResize(clip,h,v,p=100),mode=1)

[anonymlol]

Screenshot comparison (http://screenshotcomparison.com/comparison/79823)
Files (https://mega.co.nz/#!2AoEWQQb!2B0lyxA7ITuNVzx8COgHSqA8R72zNZaKjDGWBmA9oN0)
Full source: elephants_dream 720p from xiph (https://media.xiph.org/video/derf/)

Settings
x264-10bit --level 5.1 --preset veryslow --crf 15.0 --output "720 x264.mkv" "720.avs"

avs4x265.exe 720.avs --crf 20.12 --recon-depth 10 --preset veryslow -o "720 x265.hevc"


RawSource("elephants_dream_720p24.y4m")
trim(12433,12443)

edit: x265 1.1+136-59a6891dff51 used for the comparison.
edit2: Just realized I forgot to set preset veryslow for x265, will update in a few min. - fixed

[x265_Project]

Screenshot comparison (http://screenshotcomparison.com/comparison/79823)
Files (https://mega.co.nz/#!2AoEWQQb!2B0lyxA7ITuNVzx8COgHSqA8R72zNZaKjDGWBmA9oN0)
Full source: elephants_dream 720p from xiph (https://media.xiph.org/video/derf/)

Settings
x264-10bit --level 5.1 --preset veryslow --crf 15.0 --output "720 x264.mkv" "720.avs"

avs4x265.exe 720.avs --crf 20.12 --recon-depth 10 --preset veryslow -o "720 x265.hevc"




edit: x265 1.1+136-59a6891dff51 used for the comparison.
edit2: Just realized I forgot to set preset veryslow for x265, will update in a few min. - fixed
Uhhh... these are two different frames. The frame you used for the x265 screen shot has lots of simulated motion blur, making this a very unfavorable comparison.

As we've discussed here many times, screen shots (still images) have very limited use for codec comparisons. Video is moving pictures, and what looks good in a still frame doesn't always look good as a sequence of moving pictures, and vice versa.

[x265_Project]

Hi folks,

First of all thanks to MCW for the works they are doing, and to you all for this great post. It's pretty amazing to see how fast x265 development is evolving.

I thought the following personal tests could be of interest for the community.

x265 is 32 bits 8bpp 1.1+88

Source : One minute excerpt from Lionsgate's Bluray 'BrainDead' (1992) (https://drive.google.com/file/d/0B4QaEqxOEYWvTmJjVXpVSmlyeFk/edit?usp=sharing). It has grain, leaves, hair, skin, and even at 18 Mbps it has been starved.

x264 medium no-psy CRF23 (https://drive.google.com/file/d/0B4QaEqxOEYWvS05KX0xROUQtbmc/edit?usp=sharing) vs x265 medium CRF 21.26 (https://drive.google.com/file/d/0B4QaEqxOEYWvODgtS3U4T0xXSTA/edit?usp=sharing)
Here x265 has achieved the milestone of being better than x264 with default presets (psy-rd excluded, until it has been finalised).
Above CRF23 there are lower resolutions where x264 would look better on a FHD screen, so there is little point in compressing x264 above CRF23.
What I don't understand is both have same keyint min/max and scenecut, but x264 has 20 I-frames whereas x265 has 13?
How can I make sure both encodes have the same number of I-frames?

x265 1080p medium CRF 28 (https://drive.google.com/file/d/0B4QaEqxOEYWvTXJzbDhHT0Y3Qjg/edit?usp=sharing) vs x265 896p medium CRF 25.96 (https://drive.google.com/file/d/0B4QaEqxOEYWvdWFPMm1GTjNuUVU/edit?usp=sharing)
The CRF 28 shows a great amount of artifacts, ringing and blocking. The reduced 896p resolution looks slightly better than the 1080p on a full HD screen. So it makes me wonder whether the default RF 28 is not too high?
EDIT : downscale with Repair(BicubicResize(clip,h,v),GaussResize(clip,h,v,p=100),mode=1)

Thanks. I don't have time to look at the downscaled version right now, but when I play back the first clips in my special side-by-side player I can see that x265 is doing better at grain retention. Psy-RD is not perfected, but it's working, and generally providing a significant visual quality benefit at low psy-rd strengths (0.3 or 0.4). Try psy-rd and I think you'll see even better results.

[anonymlol]

Pretty sure the frames are the same. There are two comparisons (#1 and #2), first one is from the start of the clip, the second one from the end. You can toggle between x264 and x265 with mouseover.

[Sagittaire]

Pretty sure the frames are the same. There are two comparisons (#1 and #2), first one is from the start of the clip, the second one from the end. You can toggle between x264 and x265 with mouseover.

No not the same frame. Anyway make comparison at crf 15 with x264 is pretty useless. It's something like BluRay level quality. At this bitrate (with this really compressible source) even MPEG2 will certainely produce excellent result.

[nevcairiel]

There is actually two frames in there. You can switch betweem them by clicking #1 and #2, while you alternate between the x264 and x265 encodes via hovering over the image (or not hovering, as it may be)
Should probably not combine two samples into one comparison, it confuses people. =)

[anonymlol]

nevcairiel, thank you. :thanks:

I thought it's pretty obvious how the site works.
#1 and #2 are different frames because they are different comparisons (still and motion). #1 and #2 have both 2 images each, you toggle between them by moving your mouse over/off the image.

x264 on mouse out, x265 on mouse over the image. Simple, right?
http://puu.sh/9BcCT/c6deac8673.png

Anyway make comparison at crf 15 with x264 is pretty useless. It's something like BluRay level quality.
It's not useless. I'm going for quality and trying to reach the same quality with x265 while keeping the filesize the same. Unfortunately, x265 still doesn't look as good at the same filesize for high bitrate encodes (but I'm sure it will in the future).

[foxyshadis]

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

IBDI didn't make it into the spec, it was dropped in 2011 iirc. Since then, InternalBitDepth has only meant:

"If the input video is a different bit depth to InternalBitDepth, it is automatically converted... Note: The effect of this option is as if the input video is externally converted to the InternalBitDepth and then coded with this value as InputBitDepth. The codec has no notion of two different bit depths."

It was dropped because its functionality was basically pointless, an encoder and decoder could easily operate in high bit depth but input/output low without needing a spec for it. There were a few blogs that proudly trumpeted its merits when the HEVC/H.265 spec was finalized, because the Wikipedia page hadn't yet been updated and that was their only reference, heh.

[LigH]

So the best this comparison tells is: There is so little difference that the toggling was often not noticed while hovering with the mouse, therefore the misunderstanding of the feature. ;)

Unfortunately, as usual, single screenshots explain hardly how annoying loss is perceived while watching the movie. And it was rather little loss, mosytly in not too relevant parts.

[a5180007]

Try psy-rd and I think you'll see even better results.
Hi Tom, I sure will do when you say psy-rd is ready for testing. But the source is so grainy I'm not convinced psy-rd will bring any benefit at such compression. At least in x264 it does not : it removes a lot of details to put back grain noise. And before testing psy-rd, I wanted to make sure standard SAD rdo was as good as x264 in grain and detail retention.

Are the algorithms for placing I-frames so different in x264 and x265? Why would x265 put one third less I-frames with both scenecuts at 40%? This biases comparison.

EDIT : and it makes single frame comparison with x264 even more pointless.
EDIT 2 : Got it. x264 and x265 --bframes 3 --b-adapt 1 return the same amount of I-frames. Placement and numbers of P and B frames are still totally different though.

[upyzl]

IBDI didn't make it into the spec, it was dropped in 2011 iirc. Since then, InternalBitDepth has only meant:



It was dropped because its functionality was basically pointless, an encoder and decoder could easily operate in high bit depth but input/output low without needing a spec for it. There were a few blogs that proudly trumpeted its merits when the HEVC/H.265 spec was finalized, because the Wikipedia page hadn't yet been updated and that was their only reference, heh.
so that's it... :thanks:

seems there's no any en/decoder operate in high bit depth but input/output 8bit now...or in fact I missed?(or maybe CPU overhead is too high currently?)
or that means future en/decoder(e.g. x265 in the future) could use high-bit-depth internal-only for 8bit video?

[a5180007]

Another comparison (still with 1.1+88 e69a427) : x265 medium 1080p CRF 26 (https://drive.google.com/file/d/0B4QaEqxOEYWvTVAtMVQzQ3BJcVU/edit?usp=sharing) vs x265 medium 896p CRF 23.92 (https://drive.google.com/file/d/0B4QaEqxOEYWvRTlXb3AxUlZHTGc/edit?usp=sharing) (same size)

There is still a substantial amount of ringing in the 1080p. The upscaled 896p, although slightly softer, does look better than the 1080p, which suggests that even CRF 26 is too high as the default CRF -at least for this source.

Some frame compares source/1080p/896p to gain time (these are animated PNG, so leave time for the three frames to download -or download the file and open with e.g. Firefox) :

Frame 82 (https://drive.google.com/file/d/0B4QaEqxOEYWvRmNURDZaLWNKVEk/edit?usp=sharing)
Frame 485 (https://drive.google.com/file/d/0B4QaEqxOEYWvM1NRVlF2OHVJcU0/edit?usp=sharing)

EDIT : 896p upscaled with Lanczos2

[qyot27]

Noticed that too. Maybe the optimized assembler code, that exists for many of the "critical" functions, is currently for 8-Bit only and thus won't be included in HIGH_BIT_DEPTH builds.
If you use the Ninja generator, it shows pretty clearly that the HIGH_BIT_DEPTH builds lack one or two whole files from the build process that the 8-bit builds have (8-bit: 89, 16-bit: 87).

[benwaggoner]

so that's it... :thanks:

seems there's no any en/decoder operate in high bit depth but input/output 8bit now...or in fact I missed?(or maybe CPU overhead is too high currently?)
or that means future en/decoder(e.g. x265 in the future) could use high-bit-depth internal-only for 8bit video?
You can run HEVC Main 10 with 8-bit input and output. It doesn't really come out meaningfully different, though.

I think the same thing was possible with H.264 High 10, and it would produce meaningfully improved quality compared to just High.

[foxyshadis]

so that's it... :thanks:

seems there's no any en/decoder operate in high bit depth but input/output 8bit now...or in fact I missed?(or maybe CPU overhead is too high currently?)
or that means future en/decoder(e.g. x265 in the future) could use high-bit-depth internal-only for 8bit video?

The reference encoder (HM) can, x265 can, Mainconcept can, Ateme can... the encoding side definitely has you covered. On the decoding side, the reference decoder can, ffmpeg can, LAV can... basically anything that supports high-bit-depth will support bit depth conversion, as well.

What exactly are you doing that isn't working?

[upyzl]

@benwaggoner & @foxyshadis

well, to be specific

1) now at same medium bitrate(medium bitrate means, e.g. x264 crf22), x264-10bit act much better than x264-8bit in prevent banding(especially in dark flat area because of gamma compression) if Source has no banding -- of course benefit from high interal bit depth, also have positive to prevent other artifacts -- and now x264-10bit optimize is good enough even at [same encoding time & bitrate], it could still act better quality than x264-8bit

2) x265 8bpp now also use 8bit internal, I should use x265 16bpp for high bit internal -- x265 works like x264 in this regard

3) until now, H.264/AVC 10bit-depth has low compatibility. e.g. we could not use Hardware acceleration for 10bit video; mobile device/PS3 like hardware device(diff from PC could use x86-CPU for generic software decode and almost ignore decode performance and power consumption) playing 10bit video is much difficulty and unfriendly; seems video editing fields is the same(e.g. Adobe Premiere is not support for H.264 10bit video). I'm very worry about HEVC/H.265 age will be the same...

4) and...for [8bit input] and high-bit internal, if use 8bit output rather than 10bit output, should be smaller size at same quality?(I'm Not expert on this)

----
so, I'm interest in 8bit in/output and high-bit internal, especially in encoding
seek for lowest bitrate for same high quality is eternal topic for video compression, and I am, but I also care about a degree of compatibility (and encoding time)...

[nandaku2]

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.

This is likely because we have lesser asm functions at HIGH_BIT_DEPTH. Some of the larger intra asm functions were developed for 8bpp, but were deemed infeasible for 16bpp.