x265 HEVC Encoder

[upyzl]

I see, thank for replys

[LoRd_MuldeR]

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?

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). It has grain, leaves, hair, skin, and even at 18 Mbps it has been starved.

x264 medium no-psy CRF23 vs x265 medium CRF 21.26
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 vs x265 896p medium CRF 25.96
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
Files
Full source: elephants_dream 720p from xiph

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

Originally Posted by anonymlol

Screenshot comparison
Files
Full source: elephants_dream 720p from xiph

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.

Originally Posted by 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). It has grain, leaves, hair, skin, and even at 18 Mbps it has been starved.

x264 medium no-psy CRF23 vs x265 medium CRF 21.26
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 vs x265 896p medium CRF 25.96
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]

Originally Posted by 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.

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.

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?

Originally Posted by Sagittaire

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]

Originally Posted by 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...

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

Originally Posted by HM Documentation

"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]

Originally Posted by x265_Project

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]

Originally Posted by foxyshadis

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

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 vs x265 medium 896p CRF 23.92 (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
Frame 485

EDIT : 896p upscaled with Lanczos2

[qyot27]

Originally Posted by LoRd_MuldeR

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]

Originally Posted by upyzl

so that's it...

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]

Originally Posted by upyzl

so that's it...

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]

Originally Posted by 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.

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.