x265 HEVC Encoder

[-Habanero-]

I encoded the clip in 10-bit last night via Megui but I can't get this to work in CMD. Why is it automatically "correcting" the resolution? The resolution is fine the way it is and I don't want it corrected.

M:\>avs4x26x.exe --x26x-binary x265.exe ng2.avs --crf 39.6 --preset veryslow --ref 16 --keyint 600 -
-no-psy-rd --no-psy-rdoq --input-depth 10 -o ng210.hevc
avs [info]: AviSynth 2.60, build:Sep 18 2013 [17:36:36]
avs [info]: Video colorspace: YV24
avs [info]: Video resolution: 256x224
avs [info]: Video framerate: 1008307711/16777215
avs [info]: Video framecount: 2334
avs4x26x [info]: High bit depth detected, resolution corrected
avs4x26x [info]: "x265.exe" - --crf 39.6 --preset veryslow --ref 16 --keyint 600 --no-psy-rd --no-ps
y-rdoq -o ng210.hevc --input-depth 10 --frames 2334 --fps 1008307711/16777215 --input-res 128x224 --
input-csp i444
yuv  [info]: 128x224 fps 1008307711/16777215 i444p10 unknown frame count
x265 [info]: HEVC encoder version 1.5+420-24fdb661bb57
x265 [info]: build info [Windows][GCC 4.8.2][32 bit] 16bpp
x265 [warning]: Assembly not supported in this binary
x265 [info]: using cpu capabilities: none!
x265 [warning]: level 2 detected, but NumPocTotalCurr (total references) is non-compliant
x265 [info]: NONE profile, Level-NONE (Main tier)
x265 [info]: frame threads / pool features       : 2 / none
x265 [info]: Internal bit depth                  : 10
x265 [info]: Coding QT: max CU size, min CU size : 64 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 3 inter / 3 intra
x265 [info]: ME / range / subpel / merge         : star / 57 / 4 / 4
x265 [info]: Keyframe min / max / scenecut       : 60 / 600 / 40
x265 [info]: Lookahead / bframes / badapt        : 40 / 8 / 2
x265 [info]: b-pyramid / weightp / weightb / refs: 1 / 1 / 1 / 16
x265 [info]: Rate Control / AQ-Strength / CUTree : CRF-39.6 / 1.0 / 1
x265 [info]: tools: rect amp rd=6 rdoq=2 signhide tmvp b-intra
x265 [info]: tools: strong-intra-smoothing deblock sao
[6.3%] 146/2334 frames, 0.83 fps, 78.31 kb/s, eta 0:43:40

[LigH.de]

DeepColor video has to be created in a very special mode and with special filters to preserve the higher color resolution (the more significant 8 bit next to the less significant 8 bit), because AviSynth only supports 8 bit per component. AviSynth would then return a clip with a double width. If you would look at the clip, you would see some very colorful and noisy result, instead of the expected video content only. Most AviSynth filters don't support DeepColor clips, they don't know about the "msb next to lsb" structure of such clips.

[-Habanero-]

Avisynth opens the video just fine, it's only running x265 from CMD that ****s it up. I already encoded this clip with x265 via Megui which worked and didn't screw with the resolution but I don't wanna use Megui at this point. So somehow I don't see this as an avisynth problem.

By the way, can someone clear up this seriously confusing multiple terminology rooting around higher colorspaces?
As I understand it, YV12 is equated to 8-bit colorspace which has full luma resolution but just half the color resolution. How are the 12 and 8 numbers related? Why does banding even occur? Is the full luma resolution not good enough?

RGB is called 10-bit which I don't get because isn't RGB 8-bit per component? How are 10 bits relevant here? YV24 I might understand how its quality is equated to RGB because the 24 refers to 24 total bits which RGB has?

On top of this, I hear two builds of x265, one 8bpp and one 16bpp. What's BPP even mean, bits per pixel? Why does it say 16bpp if it should be 10?

Such a frigging mess. Just as bad as those tactless, flaming idiots at MPEG who couldn't make up their minds what to call their damn standards. They call their first two standards MPEG-1 and MPEG-2, fair enough. Then for some reason they skip MPEG-3, yet call TWO different standards MPEG-4, they call their first three audio standards MP1 MP2 and MP3 but for some idiotic reason made MP4 a video file extension and M4A the audio so nobody even knew AAC was the successor to MP3 and as a result that shitty OGG became popular instead. They're ever-so-consistent today by calling H265 "MPEG-H", the first time they used a letter instead of a number.
It's like they did this shit on purpose just to make everything as confusing as possible. I had a hell of a time figuring all this out back when I was just starting out with all this.

[LigH.de]

YV12 is a FourCC which describes planar YUV 4:2:0 video. If Y, U and V had all the full resolution, you would have 3×8 bit = 24 bit per pixel; but because in 4:2:0 chroma subsampling, (simplified) a square of 2×2 pixels shares the same U and V chroma difference values, you will only have 4+1+1 = 6 Bytes = 48 bits for each 4 pixels, this makes an average of 48:4 = 12 bits per pixel.

Banding may occur mostly due to quantization of the transformed parameters in a frequency domain, but partially also due to some rounding errors during a conversion from YUV back to RGB, for displaying on a monitor using RGB additive color mixture. Giving the YUV samples a higher precision than 8 bit per component doesn't make much sense when the internal precision of the frequency parameters is still limited to 8 bit before quantization which reduces the precision even more.

x265 comes in flavours with either 8 bit precision of internal parameters, or with "up to 16 bit" precision ("High Bit Depth", currently implemented for 10 bit precision to create Main10 or High10 profile HEVC bitstreams); "bpp" is rather meant as "bits per parameter", not "bits per pixel (component)", as it is related to parameters after a transformation to a frequency domain (you may have learned about the Fourier transform in school, the transforms used in video compression are similar but limited in range, therefore limited in the number of parameters, whereas Fourier transforms are for infinite periodical functions with infinite sums of parameters).

The optimum to avoid banding would be that both AviSynth filters video with more than 8 bit precision per YUV component (DeepColor mode; currently very limited support), and x265 transforms it to frequency parameters with more than 8 bit precision (High Bit Depth build).

"RGB is called 10-bit" is a completely wrong statement.

Your rant does not support clearing this confusion; but I agree that it takes time to get used to a lot of nits. By the way, MP4 is the container, it may contain video, but only "usually". MP3 was only a "convenience" abbreviation of "MPEG-1 Audio Layer 3" (MPEG-1 was already a standard for a video, several audio, and even two container formats, PS and TS).

[sneaker]

I encoded the clip in 10-bit last night via Megui but I can't get this to work in CMD. Why is it automatically "correcting" the resolution? The resolution is fine the way it is and I don't want it corrected.

Don't use "--input-depth 10" when you are only inputting 8 bit.

[-Habanero-]

Thanks sneaker, that fixed it. Though it does say the input is 10-bit with or without that command so this is really confusing. Is there ever a time when I need to use that command?

YV12 is a FourCC which describes planar YUV 4:2:0 video. If Y, U and V had all the full resolution, you would have 3×8 bit = 24 bit per pixel; but because in 4:2:0 chroma subsampling, (simplified) a square of 2×2 pixels shares the same U and V chroma difference values, you will only have 4+1+1 = 6 Bytes = 48 bits for each 4 pixels, this makes an average of 48:4 = 12 bits per pixel.

Makes sense. Small question, does converting from RGB24 to YV24 impact the quality at all? It doesn't seem to.

Banding may occur mostly due to quantization of the transformed parameters in a frequency domain, but partially also due to some rounding errors during a conversion from YUV back to RGB, for displaying on a monitor using RGB additive color mixture. Giving the YUV samples a higher precision than 8 bit per component doesn't make much sense when the internal precision of the frequency parameters is still limited to 8 bit before quantization which reduces the precision even more.

This I don't understand, aren't the rounding errors only in the color domain? Why should that produce banding?

x265 comes in flavours with either 8 bit precision of internal parameters, or with "up to 16 bit" precision ("High Bit Depth", currently implemented for 10 bit precision to create Main10 or High10 profile HEVC bitstreams); "bpp" is rather meant as "bits per parameter", not "bits per pixel (component)", as it is related to parameters after a transformation to a frequency domain (you may have learned about the Fourier transform in school, the transforms used in video compression are similar but limited in range, therefore limited in the number of parameters, whereas Fourier transforms are for infinite periodical functions with infinite sums of parameters).

I was told earlier that I was confusing 10-bit depth with 10-bit calculation precision which is completely new to me. So the 10-bit feature of x264 and x265 have nothing whatsoever to do with colorspace? If that's the case, can I encode YV24 content with "8-bit precision" and keep the high colorspace?

"RGB is called 10-bit" is a completely wrong statement.

That's certainly the impression I got all these years from the 8-bit version of the codec being unable to encode anything higher quality than YV12 while 10-bit could.

By the way, I have encoded my RGB32-sourced sample with 8-bit and 10-bit x265. You guys wanted proof that 10-bit requires more bitrate to compensate for the extra colorspace, here it is:
http://www.screenshotcomparison.com/comparison/119417

They both have the same encoding settings and the 10-bit output is somewhat higher bitrate than the 8-bit (64 vs 56 kb/s)
As you can see, the 10-bit output is a lot worse quality with a lot more smearing. This is perfectly consistent with the last test I did with x264 years ago. I can provide both MKVs if you guys still don't believe me, they're almost the same size as those screenshots anyway.

Now just a few days ago I was bitching about 4 fps encoding speed for a 256x224 video, 10-bit precision lowered that to 0.66 fps.
This is getting ridiculous... >_<

[x265]

Until now, HEVC has been a technology for experts and hard-core video enthusiasts only. We have a fast, reliable HEVC decoder, called UHDcode, but we needed to find a way to make this available for everyone to try. x265 was available in source code form, but we didn't have an application available directly from the x265 team.

To make it easier for anyone to try x265 and experience the benefits of HEVC, today we're launching the x265 HEVC Upgrade. We've created a new Windows 64 bit application that lets you convert MP4 files to HEVC. There is a new Basic Mode which anyone non-technical person should be able to use. In Advanced Mode we expose the full feature set of x265.

The x265 Encoder application is bundled with our UHDcode HEVC decoder, packaged as a Windows DirectShow filter; a plug-in for Windows Media Player. This upgrades Windows Media Player (64 bit) to play back HEVC video files (raw bitstreams or MP4 files with HEVC).

The MSRP of the x265 HEVC is $29.95, but for a limited time you can download for free at x265.com. We hope you find these applications valuable.

[poisondeathray]

Thanks sneaker, that fixed it. Though it does say the input is 10-bit with or without that command so this is really confusing. Is there ever a time when I need to use that command?

As the name suggests , you use it specify the input depth .

The most common case where it's used is when you are piping in raw video

Small question, does converting from RGB24 to YV24 impact the quality at all? It doesn't seem to.

Yes it does. This is a lossy conversion. RGB and YUV are non overlapping color models. You always incur loss - whether or not it's "visible" is a different matter

Banding may occur mostly due to quantization of the transformed parameters in a frequency domain, but partially also due to some rounding errors during a conversion from YUV back to RGB, for displaying on a monitor using RGB additive color mixture. Giving the YUV samples a higher precision than 8 bit per component doesn't make much sense when the internal precision of the frequency parameters is still limited to 8 bit before quantization which reduces the precision even more.

This I don't understand, aren't the rounding errors only in the color domain? Why should that produce banding?

Rounding errors are everywhere, from the color space converion, the intermediate calculations

There are different types of what people call "Banding", and different causes. High quantizer (low bitrates) is a main one, but in an 8bit source, there are only 0 to 255 or 256 values of expression for each channel in RGB. In normal range YUV it's even less , only values 16-235 are used in Y' , 16-240 in Cb Cr . Fewer values for expression cause banding. Finally, non overlapping color models. Not all values of YUV can be expressed in RGB (There are "negative" values))

I was told earlier that I was confusing 10-bit depth with 10-bit calculation precision which is completely new to me. So the 10-bit feature of x264 and x265 have nothing whatsoever to do with colorspace? If that's the case, can I encode YV24 content with "8-bit precision" and keep the high colorspace?

Your source bit depth is 8, but encoding using 10bit is still beneficial because of the calculation precision. "Colorspace" is often synonmous with "color model" . e.g. "YUV" or "RGB". They are models to describe color.

"Colorspace" and "bit depth" are independent - eg. You can have 8bit RGB, you can have 10bit RGB, you can have 8bit YUV, you can have 10bit YUV . RGB encoding is less efficient

By the way, I have encoded my RGB32-sourced sample with 8-bit and 10-bit x265. You guys wanted proof that 10-bit requires more bitrate to compensate for the extra colorspace, here it is:
http://www.screenshotcomparison.com/comparison/119417

They both have the same encoding settings and the 10-bit output is somewhat higher bitrate than the 8-bit (64 vs 56 kb/s)
As you can see, the 10-bit output is a lot worse quality with a lot more smearing. This is perfectly consistent with the last test I did with x264 years ago. I can provide both MKVs if you guys still don't believe me, they're almost the same size as those screenshots anyway.

Now just a few days ago I was bitching about 4 fps encoding speed for a 256x224 video, 10-bit precision lowered that to 0.66 fps.
This is getting ridiculous... >_<

Dos game ? B frame vs. P frame ? You should upload the original source and videos, encoding settings etc

There might a few fringe cases where 10bit produces worse results, but for the vast majority of scenarios it is the other way.

[-Habanero-]

Link to the source video and compressed files.

Commandline for latest 10-bit encode:

M:\>avs4x26x.exe --x26x-binary x265.exe ng2.avs --crf 39.6 --preset veryslow --ref 16 --bframes 16 -
-keyint 600 --no-psy-rd --no-psy-rdoq --rc-lookahead 200 -o ng210.hevc
avs [info]: AviSynth 2.60, build:Sep 18 2013 [17:36:36]
avs [info]: Video colorspace: YV24
avs [info]: Video resolution: 256x224
avs [info]: Video framerate: 1008307711/16777215
avs [info]: Video framecount: 2334
avs4x26x [info]: "x265.exe" - --crf 39.6 --preset veryslow --ref 16 --bframes 16 --keyint 600 --no-p
sy-rd --no-psy-rdoq --rc-lookahead 200 -o ng210.hevc --frames 2334 --fps 1008307711/16777215 --input
-res 256x224 --input-csp i444
yuv  [info]: 256x224 fps 1008307711/16777215 i444p8 unknown frame count
x265 [info]: HEVC encoder version 1.5+420-24fdb661bb57
x265 [info]: build info [Windows][GCC 4.8.2][32 bit] 16bpp
x265 [warning]: Assembly not supported in this binary
x265 [info]: using cpu capabilities: none!
x265 [warning]: level 2.1 detected, but NumPocTotalCurr (total references) is non-compliant
x265 [info]: NONE profile, Level-NONE (Main tier)
x265 [info]: Thread pool created using 8 threads
x265 [info]: frame threads / pool features       : 3 / wpp(4 rows)
x265 [info]: Internal bit depth                  : 10
x265 [info]: Coding QT: max CU size, min CU size : 64 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 3 inter / 3 intra
x265 [info]: ME / range / subpel / merge         : star / 57 / 4 / 4
x265 [info]: Keyframe min / max / scenecut       : 60 / 600 / 40
x265 [info]: Lookahead / bframes / badapt        : 200 / 16 / 2
x265 [info]: b-pyramid / weightp / weightb / refs: 1 / 1 / 1 / 16
x265 [info]: Rate Control / AQ-Strength / CUTree : CRF-39.6 / 1.0 / 1
x265 [info]: tools: rect amp rd=6 rdoq=2 signhide tmvp b-intra
x265 [info]: tools: strong-intra-smoothing deblock sao
x265 [info]: frame I:      4, Avg QP:41.35  kb/s: 1146.70
x265 [info]: frame P:    311, Avg QP:45.25  kb/s: 179.44
x265 [info]: frame B:   2019, Avg QP:51.95  kb/s: 36.74
x265 [info]: global :   2334, Avg QP:51.04  kb/s: 57.66
x265 [info]: Weighted P-Frames: Y:0.6% UV:0.3%
x265 [info]: Weighted B-Frames: Y:0.4% UV:0.3%
x265 [info]: consecutive B-frames: 1.0% 3.2% 1.3% 7.6% 9.2% 34.0% 5.4% 4.1% 6.0% 18.4% 1.3% 0.3% 1.6
% 3.8% 0.0% 0.0% 2.9%

encoded 2334 frames in 3549.46s (0.66 fps), 57.66 kb/s

I did not take just one frame out of context, the entire video is visibly worse quality than the 8-bit one.

ng2 x265 10-bit.mkv has somewhat different commandline than the 8-bit, I used maximum lookahead thinking this will fix the variable quality I've been seeing but it didn't. I also used 16 bframes instead of 8 because I saw it didn't use 16 by default like it should have.
Everything else is the same. Same 600 keyint, same 16 refs.
If this bothers you, refer to the ng2 x265 10-bit megui.mkv where the exact same commandline was used as the 8-bit output.

I'll read the rest of your post in a bit.

[poisondeathray]

I did not take just one frame out of context, the entire video is visibly worse quality than the 8-bit one.

ng2 x265 10-bit.mkv has somewhat different commandline than the 8-bit, I used maximum lookahead thinking this will fix the variable quality I've been seeing but it didn't. I also used 16 bframes instead of 8 because I saw it didn't use 16 by default like it should have.
Everything else is the same. Same 600 keyint, same 16 refs.
If this bothers you, refer to the ng2 x265 10-bit megui.mkv where the exact same commandline was used as the 8-bit output.

Thanks for uploading the tests.

That's not entirely true, some sections are better some are worse. eg. Look at the section with the mountains an blue background.

Eitherway, the tests were not "proper" since you messed up the bitrate and encoding some 4:4:4 (10bit), others 4:2:0 (8bit) , some with 8 bframes, others with 16. You usually can't use the same CRF, since 10bit and 8bit have different scales for the quantizers. People usually do fractional CRF encodes, or 2pass bitrate based encodes when testing

While preserving YUV 4:4:4 would be ideal, it also requires more bitrate to successfully do so. In the lower bitrate range relative to content complexity, it's going to be more of a detriment .

Proper tests should control all the variables, so only the 1 thing being tested is actually being tested (ie. 10bit vs. 8bit if that was what you were testing here) .

[-Habanero-]

Yes it does. This is a lossy conversion. RGB and YUV are non overlapping color models. You always incur loss - whether or not it's "visible" is a different matter

Wow, you're right. I tested it right not with a hex editor and I see pixel values differences of 1. No wonder I couldn't see any difference even close up.

Rounding errors are everywhere, from the color space converion, the intermediate calculations

There are different types of what people call "Banding", and different causes. High quantizer (low bitrates) is a main one,

That's what I thought but everyone keeps recommending to use 10-bit to fix this and since encoding a higher colorspace adds entropy I can only see this causing more banding and more artifacts as my test just proved.

but in an 8bit source, there are only 0 to 255 or 256 values of expression for each channel in RGB. In normal range YUV it's even less , only values 16-235 are used in Y' , 16-240 in Cb Cr . Fewer values for expression cause banding. Finally, non overlapping color models. Not all values of YUV can be expressed in RGB (There are "negative" values))

That's not a big difference, 220 values vs 256. Would this really cause banding? Shouldn't this just erase all pixels darker than 16 or brighter than 235?

Your source bit depth is 8, but encoding using 10bit is still beneficial because of the calculation precision. "Colorspace" is often synonmous with "color model" . e.g. "YUV" or "RGB". They are models to describe color.

"Colorspace" and "bit depth" are independent - eg. You can have 8bit RGB, you can have 10bit RGB, you can have 8bit YUV, you can have 10bit YUV . RGB encoding is less efficient

You didn't answer my question. If bit depth and calculation precision are two different things, why can't I encode YV24 content with 8-bit precision? Why does it automatically convert it to YV12?

Dos game ?

NES game, mofo. Ninja Gaiden. Check it out.

Thanks for uploading the tests.

That's not entirely true, some sections are better some are worse. eg. Look at the section with the mountains an blue background.

I think that's more a qcomp problem and its failure to properly allocate bits. The first 10 seconds are easy to compress because of the huge, featureless background. There's an absence of constant quality here.
Be honest, the 10-bit video has more frames that are worse quality than better.

Eitherway, the tests were not "proper" since you messed up the bitrate and encoding some 4:4:4 (10bit), others 4:2:0 (8bit) , some with 8 bframes, others with 16.

That's not true, I used a higher lookahead and more bframes with the ng2 x265 10bit.mkv video because I thought it would fix the variable quality problem but it didn't. The video that uses the exact same settings as the 8-bit is ng2 x265 10bit megui.mkv.

You usually can't use the same CRF, since 10bit and 8bit have different scales for the quantizers. People usually do fractional CRF encodes, or 2pass bitrate based encodes when testing

I know but keep in mind that it takes a whole hour for me to encode this tiny, highly-compressible 256x224 video. I can't wait a whole hour just to see if the next CRF value will output that perfect filesize I wanted. Either way, the bitrates were largely similar.
The fact that the 10-bit one has 14% higher bitrate yet worse quality further proves my point if anything.

While preserving YUV 4:4:4 would be ideal, it also requires more bitrate to successfully do so. In the lower bitrate range relative to content complexity, it's going to be more of a detriment .

BINGO! This is what I've been trying to say all along but y'all didn't believe me.

[poisondeathray]

That's what I thought but everyone keeps recommending to use 10-bit to fix this and since encoding a higher colorspace adds entropy I can only see this causing more banding and more artifacts as my test just proved.

Hold on, your test didn't "prove" anything yet. It's one observation that goes against 1000's of others. One data point. It might eventually be correct for this type of test scenario when you do proper tests - but you cannot extend that observation and apply it to other types of content, other bitrate ranges. Or did you think this game is representative of typical blu-rays or movies ?

but in an 8bit source, there are only 0 to 255 or 256 values of expression for each channel in RGB. In normal range YUV it's even less , only values 16-235 are used in Y' , 16-240 in Cb Cr . Fewer values for expression cause banding. Finally, non overlapping color models. Not all values of YUV can be expressed in RGB (There are "negative" values))

That's not a big difference, 220 values vs 256. Would this really cause banding? Shouldn't this just erase all pixels darker than 16 or brighter than 235?

No, it typically gets compressed. You "squish" the range, thus banding. Instead of 1-2-3-4 . You might get 1-3-4, thus coarse quantization of steps, or banding. But that's only part of the reason

If you clip the data, then it wouldn't look right.

You didn't answer my question. If bit depth and calculation precision are two different things, why can't I encode YV24 content with 8-bit
precision? Why does it automatically convert it to YV12?

I don't know if it's enabled yet in the typical distributed x265 binaries - did you try --input-csp i444 ?

That's not entirely true, some sections are better some are worse. eg. Look at the section with the mountains an blue background.

I think that's more a qcomp problem and its failure to properly allocate bits. The first 10 seconds are easy to compress because of the huge, featureless background. There's an absence of constant quality here.
Be honest, the 10-bit video has more frames that are worse quality than better.

Yes, even at higher bitrate, the 10bit version of your test looked worse overall. But it used 444 . Think of it this way, you used a larger frame size for the chroma planes

While preserving YUV 4:4:4 would be ideal, it also requires more bitrate to successfully do so. In the lower bitrate range relative to content complexity, it's going to be more of a detriment .

BINGO! This is what I've been trying to say all along but y'all didn't believe me.

No, you were saying 10bit vs 8bit. 444 vs 420 is a different concept. Again, don't mix bit depth, with chroma subsampling.

YUV444 has a larger size for the chroma planes, so of course you would need more bitrate. You 're only encoding 128x112 dimensions for U and V with YUV420. YUV444 uses full resolution, 256x232 for all 3 planes Y,U,V.

[poisondeathray]

Yes , --input-csp i444 works with 8bit x265 , and the output is YUV444

Post your console/ log for the 8bit runs , or if you used megui or some GUI , try to find the log

[hogger129]

Does anyone notice any significant posterization, banding, artifacts, etc; using x265 on the fastest speed setting (Ultrafast) with a decent CRF setting like 18-20?

Just curious. I have a pretty new CPU (i7-4790) and can do an Ultrafast x265 encode in a decent amount of time (2-4 hours) and I would probably get significantly smaller files than using x264 Slow.

I would be watching these on a computer, so processing power wouldn't really be a huge problem as I understand that is what is holding H.265 back from being supported on things like iPads and set top boxes.

I did some test encodes with Vidcoder. I trust my eyes and to me, x265 on the fastest speed setting with CRF18, looked better than x264 with the same settings but on the Medium or Slow speed setting.

[LigH.de]

CRF 18 for x265 is almost a generous quality level, if it wasn't for the ultrafast preset with minimal complexity.

[hogger129]

CRF 18 for x265 is almost a generous quality level, if it wasn't for the ultrafast preset with minimal complexity.

Would I gain anything but smaller file size by going to a slower x265 speed setting?

[-Habanero-]

Ahh, I now I understand what the source of my confusion was. I did --input-csp i444 as PDR instructed and YV24 video was successfully encoded by both 8-bit x264 and x265.

For the past few years, non-10-bit encoders automatically converted everything to YV12 before it could proceed and 10-bit encoders were always associated with encoding YV24 material so naturally I correlated 10-bit to the colorspace because nobody talked about encoding YV24 with 8-bit. God damn you, TASvideos!

But if the bit depth has nothing to do with the colorspace, can someone explain in simple terms what it is? I hear "calculation precision" but calculating what with more precision?

No, it typically gets compressed. You "squish" the range, thus banding. Instead of 1-2-3-4 . You might get 1-3-4, thus coarse quantization of steps, or banding. But that's only part of the reason.

I just tested this, yes it does seem to spread the loss and cause a little bit of banding but not what you typically see in a compressed video. Most of it I guess is quantization like you said.
Thanks for patiently clearing these things up.
And no I don't think my sample represents Blu-ray movies but it's the only sample I have that I could do tests with quickly. The best part about old platformers is they benefit from every encoder setting greatly, even TESA increases the quality by 4-5%.

[hogger129]

CRF 18 for x265 is almost a generous quality level, if it wasn't for the ultrafast preset with minimal complexity.

I don't understand.

Is there really even a reason to use x265 other than for small file sizes? There really is no hardware out there short of a PC that can decode it.

[poisondeathray]

But if the bit depth has nothing to do with the colorspace, can someone explain in simple terms what it is? I hear "calculation precision" but calculating what with more precision?

Bit depth is the range of values per channel.
http://en.wikipedia.org/wiki/Color_depth

For 8bit, this would mean 2^8 = 256 possible values (from zero to 255) . 10bit would be 2^10 or 1024 . So there are more intermediate values that can be used. For the Y channel , black to white would be 0-1023 instead of 0-255. There are more intermediate "shades". Even 8bit sources can benefit from 10bit calculations, because the intermediate calculations, especially the motion estimation (ME) stage has higher precision. Higher accuracy means smaller residuals (residuals are the differences between what is predicted from the ME - and that is what is actually stored in the b frame, thus lower filesizes)

I ran some quick tests that were "proper", and in that specific test and scenario (very low bitrates, truncated color pallette, dos type games), 10bit might not be beneficial on that specific clip, but it requires more testing and analysis of similar videos. And your test clip isn't as "highly compressible" as you described. The motion characteristics make it less desireable for compression

I just tested this, yes it does seem to spread the loss and cause a little bit of banding but not what you typically see in a compressed video. Most of it I guess is quantization like you said.
Thanks for patiently clearing these things up.
And no I don't think my sample represents Blu-ray movies but it's the only sample I have that I could do tests with quickly. The best part about old platformers is they benefit from every encoder setting greatly, even TESA increases the quality by 4-5%.

Yes, the "banding" that people describe is multifactorial. But the banding from RGB<=>YUV issue becomes especially important when converting 8bit RGB (like video game captures) to standard range 8bit YUV. You get banding, even with lossless compression - that type of "banding" isn't from high quantizers . Because you've ruled out lossy compression (high quantizers) - that is purely from colormodel conversions (ie. the other reasons mentioned) . This is very easy to demonstrate. Just take a RGB gradient from photoshop, gimp etc.. convert it to lossless YUV444 ; there will be banding when you view it (note it gets converted back to RGB for display on your monitor) . And you can take it one step farther to eliminate the range conversion , and do a "full range conversion" ; ie. Map 0-255 in RGB 0,0,0-255,255,255 to YUV in 0-255 . You still get banding, albeit a bit less - Why? Because they are non overlapping color models. Not every value has a 1:1 representation in the color cube. Graphically you can see it here , when you plug it into the equation you get negative values which have "no answer". And even within the "mappable" values (those values which have an answer) there are rounding errors







Anyways, I think we should stick to x265 specific topic discussion in this thread - you can read or make other threads about the other topics

[LigH.de]

Would I gain anything but smaller file size by going to a slower x265 speed setting?

A little more efforts in searching a good matching reference may result not only in a smaller result, but even in a better looking one. The "rate factor" is not exactly the same as subjective quality. No calculated metric matches the human sense perfectly, and on top, there are different people with different meanings of "good quality". Only "no recognizable difference" (visually transparent quality) can certainly satisfy most people. But if there is visible loss, different people may rate it differently annoying.

There really is no hardware out there short of a PC that can decode it.

There are; UHD TV sets can.

And yes, "efficiency = quality preservation : file size" is the reason to develop new codecs. But it makes little sense to compare extremes. If you make a codec use only the least possible efforts, don't blame it for no optimal efficiency; if you make it use the most possible efforts, don't blame it for taking a lot of time. And don't expect it to do miracles; a little more bitrate may preserve a lot more quality than a lot more efforts to search for redundancies to reduce.

[Selur]

There really is no hardware out there short of a PC that can decode it

+ Newer smartphones can decode H.265 Main and Main10 (at least when using 4:2:0) just fine.

[-Habanero-]

Thanks PDR for explaining everything. Yes there were rounding errors on my video when going from RGB32 > YV24 but only differences of one pixel value.
10-bit is awesome, even with crf50 there is NO BANDING. This is great but the even lower of what was already slow encoding speed is discouraging. I'll have to abstain until I get a new computer. In the meantime, I'll have to eat my own words of what I said a few years ago when I bragged about always using the latest stuff no matter how slow it was. I've forgotten what it was like to use x264 with a Pentium 4 and wait several days for things to finish.

[-Habanero-]

Finally found an anime source to do a test with and I'm very impressed. It's 32 seconds, 480p, denoised. 2803KB for x264 and 1803KB for x265 at the same SSIM. Lower bitrates don't really look too much worse despite much lower SSIM, there's no blocking or ringing and the edges are preserved, but microdetails are still lost hence why I trust SSIM's accuracy.

This is very impressive. 60% bitrate reduction this soon for cartoons.

[-Habanero-]

Ok x265's CRF is unpredictable. I'm encoding the credits of a movie and the bitrates are much higher than its x264 counterpart. x264 at CRF20 outputs 264 kb/s, x265 CRF20 440 kb/s, x264 CRF30 60 kb/s and x265 CRF30 86 kb/s.

x265's CRF is so unintuitive. Is it not supposed to produce the same filesize as x264 (but better quality)? With x264 keeping it at 18 provides consistent quality with any type of video. With x265 I have to experiment between 18-26.

[Selur]

Is it not supposed to produce the same filesize as x264 (but better quality)?

No it isn't and never was. And why and how should it be?
crf is not a quality measurement unit. You might want to read up on what a rate factor is.
(as a side note, iirc x264 had some special tunings to detect the credits of a movie, so x265 still has potential to get better,..)

[-Habanero-]

CRF is nicknamed "constant quality" for a reason. CRF26 shouldn't be great quality for some videos and crappy quality for others. This credits scene isn't the only example.

[Selur]

CRF is nicknamed "constant quality" for a reason.

And you clearly didn't get the reason.

CRF26 shouldn't be great quality for some videos and crappy quality for others.

You really might want to get a deeper understanding what a rate factor is.
a. CRF does not define a constant quality metric.
b. crf can only be used to specify quality (for a specific encoder) if you keep everything else fixed
-> assuming that:
a. crf will produce the same objective quality for different inputs, is simply wrong
b. crf will produce the same objective quality when using different encoders, is simply wrong

crf tries to keep a relative constant quality level over all the frame of a specific source (considering the effect of all other options).
crf is like another quality metric which isn't perfect.

[LigH.de]

CRF is not a constant absolute quality (regardless of the content), but a more or less constant amount of quality loss (dependent on the original content). In any case, quality will get worse. And if the material was already bad, then a good amount of bitrate has to get spent on reproducing already existing compression artefacts.

[-Habanero-]

My material is not bad quality, the first is denoised animation while the second is a replay of a NES game thus 100% noiseless.
The first needs CRF20 for great quality, the second is flawless at CRF26. If I do the NES game at CRF20 then it will be flawless and oversized.
x264 had better consistency than this, I could use CRF18 for everything without putting much thought.

The credits I gotta say were flawless at CRF30, that's not normal, hahaha. CRF30 should output bad quality.

[Selur]

Since you don't seem to get that crf isn't an absolute quality metric you probably didn't notice that there are tons of other options for x265.
+ hoping for consistency while x265 is still changing quite a bit in the background (simply check the changelogs to see how often the presets&co have changed) seems like a pipe dream