x265 HEVC Encoder

[James Freeman]

Originally Posted by LigH

Compile? Encode, probably.

Yes, Encode.

Originally Posted by LigH

BTW, you ask for a maximum of 108 Mbps, this looks like a double 802.11g WLAN rate?

It's the Bitrate of the original video.
Nothing to do with 802.11g.

The goal here is to test how much CPU it takes to decode a High Bitrate 1080p HEVC video, that is all.
108Mbps is higher than a typical Blu Ray with 30Mbps.
If you have anything higher than 108Mbps it will be of help.

I feel Hollywood will be more concentrated on higher bitrate with 1080p resolution, than UHD with lower bitrate.

For example:
The new 100GB discs with 1080p, but with HEVC, Higher Bitrate, Wider Gamut (Rec.2020), 4:2:2/4:4:4 Chroma, and HFR (maybe).
The quality will be comparable to Digital Cinema (2K) finally.

Lets call it Blu Ray 2 shall we.

Originally Posted by Brazil2

Check this one :
http://forum.doom9.org/showthread.ph...83#post1651083

Yeah, I already tested this one.

I got 21fps with: 3770K (4.5Ghz), GTX660 (nothing to do with it).

I specifically ask for the 1080p one for the reason I pointed above.

[LigH]

Well, I try to understand your point, but again ... it doesn't make much sense to try to reach the bitrate of an already lossy compressed "original" with another lossy compression algorithm. The encoder will mainly try to re-encode the quantization artefacts of the former copy, so you may spend a lot of time, but the result won't tell you much more than the time wasted.

I prefer to use (almost) lossless sources for testing, like Sintel (a Blender render movie which is available in different image dimensions – e.g. 1080p or 4K – and even high color resolution, 16 bpc = 48 bpp) as original, so I can even get a meaningful quality measure; just their downloads can take several days, due to the size of several Gigabytes.

For shorter tests, there is also the Sintel trailer in 1080p@24fps (Y4M, 3.7 GB / PNG.tgz, 900 MB).

[sneaker_ger]

He just wants to measure the decoding performance, artifacts and source quality don't matter for that.

[mandarinka]

Yes, but the resulting file might still not be representative. There could for example be more skips blocks and as a result, the decoding load would be lower than with a video coded from a lossless source.

[pieter3d]

Note that Main10 profile allows chroma and luma to have separate bits per pixel values, between 8..10 inclusive. So you can have either or both luma/chroma using bitdepths of 9.

[nevcairiel]

Originally Posted by pieter3d

Note that Main10 profile allows chroma and luma to have separate bits per pixel values, between 8..10 inclusive. So you can have either or both luma/chroma using bitdepths of 9.

While this feature also existed in H.264, it was not really used by anything and not supported by most of the decoders. I would wager that this will remain the same situation with HEVC.

[pieter3d]

I disagree. While probably it won't be used often, it is part of Main 10 profile, so anyone wishing to build a compliant decoder must support it. I can promise you that all Main10 HW decoders will support it, as part of conformance. Encoders however, probably not unless there is a good special application.

[nevcairiel]

The same thing applies to H.264, yet many decoders didn't handle it, even if they otherwise handled 10-bit decoding - it was just never implemented, because it was never used.

[James Freeman]

Can anyone point me to a link with a 1080p HEVC 30Mbps+ NON-animated (reality) video sample?
I want to compare it with a typical blu ray quality (1080p H.264 30Mbps+).

I want to compare CPU-Load & Picture Quality.

Thanks.

[iSunrise]

Originally Posted by James Freeman

...I feel Hollywood will be more concentrated on higher bitrate with 1080p resolution, than UHD with lower bitrate...

That´s not how marketing works.

[James Freeman]

Originally Posted by iSunrise

That´s not how marketing works.

I can understand that.
4K is alot shinier than HD

What do you think the future of Blu Ray will look like?

[Guest]

Originally Posted by James Freeman

What do you think the future of Blu Ray will look like?

Not on-topic for this thread. Please open a new one.

[mandarinka]

Originally Posted by nevcairiel

The same thing applies to H.264, yet many decoders didn't handle it, even if they otherwise handled 10-bit decoding - it was just never implemented, because it was never used.

Well, there were no decoders for High 10 to begin with. There is only CoreAVC and libavcodec and both are software. Also, they probably don't care much about being completely conformant to the whole spec.

[LigH]

Originally Posted by James Freeman

Can anyone point me to a link with a 1080p HEVC 30Mbps+ NON-animated (reality) video sample?

The closest lossless source to "reality" I have is "Tears of Steel". I'm just testing an encode of an action cut of one minute, the result may be available today or tomorrow, depending on the speed and resulting bitrate. And due to the efficiency of HEVC, it is not easy to pass the target of 30 Mbps (without padding)...

[James Freeman]

@LigH

Thank you for the upcoming test video.
A minute of footage will be enough to compare HEVC vs H.264.

And due to the efficiency of HEVC, it is not easy to pass the target of 30 Mbps (without padding)...

I have no idea what padding is.
Do you mean HEVC is too efficient so the results are always less than 30Mbps?
If that's the case, its Great!


I thought of a good comparison method.
Visual (SSIM) & File Size:

File Size comparison (same visual quality):
1. x264 encoded to 30Mbps with a resulting X SSIM value.
2. Set HEVC with the same X SSIM value but let it compress to what Bitrate as it wants.

This test is good to compare how much will we able to put into a single defined space, like an optical disc.
For example: How many hours of film will we be able to put into the same size with the same quality.

Visual Comparison (same file size):
1. x264 encoded to 30Mbps with a resulting X SSIM value.
2. HEVC encoded to 30Mbps with a different resulting Y SSIM.

This test is good to visually compare how much better the picture quality will be in the same file size.

[zerowalker]

I am a bit confused as i haven´t been following H265.

Which encoder is the one i should look at, is it this x265?

And if so, which of them, i see the one linked at first post, and i know the one at Google Source thing?
Or are they the same?

Also, how is it looking, is it still a child to be fed, or is it starting to look like something so to speak?

Thanks

[filler56789]

Originally Posted by James Freeman

I have no idea what padding is.

When you set the encoder to achieve a target bitrate "X", and the resulting stream has an actual bitrate "less than X", then the encoder may fill the video stream with NULL bytes.

Originally Posted by LigH

And due to the efficiency of HEVC, it is not easy to pass the target of 30 Mbps (without padding)...

Correct Still, you could try the following settings:

--- disable B-frames

--- use short GOPs (i.e., more I-frames)

--- use low quantizers (18 or even less)

HTH

[LigH]

Well, yes, it is possible to get quite high bitrates locally. Limiting the encoding efficiency will reduce the required decoding efforts as well, though, therefore I'm trying to create a rather complex video with longer GOPs, severe referencing, and still high bitrates; so the only way to achieve that is a low quantization. CRF 12 appears to be promising... more later.

To keep the bitrate in a closer range, x265 would require a VBV like regulation, though.

And yes, stuffing would mean to fill up the video with non-bitstream junk just to keep the brutto bitrate rather constant; the only known use (to me) for this waste would be DVB bouquets, and maybe optical disk material to avoid buffer overflows.

[Kurtnoise]

Does anybody confirm that the latest x265 builds (with the latest commits from today) are broken using the pipeline ?

I tested my own builds and the ones from x265.cc, all fail...at least with yuv.

[LigH]

Version 0.5+153 (VC12 x86-64) works in general with Y4M file input, but produces artefacts with a complex command line:

-F 3 -q 23 -b 3 --b-adapt 2 --bframe-bias 30 -w --ref 3 -i 240 --psnr --ssim --rdpenalty 1 --aq-mode 1

Same for piping Y4M via avs2yuv: Works in general, but produces artefacts.

Same for piping raw YUV i420 via avs2yuv: Works in general, but produces artefacts.
__

Hmm. Different command line option set, no artefacts...

--preset slower --crf 24 -F 6 -w --bframe-bias 30 -i 240 --rdpenalty 1 --aq-mode 1