x265 HEVC Encoder

[Sm3n]

You're right. Even if it's a little bit faster, it will be hard to tell how much it is.
I try to encode a 720p with -p veryslow... So slow!
Can we know which parameters correspond the preset veryslow? (and the other)

[sneaker_ger]

http://forum.doom9.org/showpost.php?p=1655923&postcount=213

[Sm3n]

http://forum.doom9.org/showpost.php?p=1655923&postcount=213

:goodpost: Thank you.

[xooyoozoo]

x264 and other AVC encoders don't fully utilize generalized-B-frames. I've never really thought about why, but I came across a paper (http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=6272183) from last year that suggests completely replacing P-frames with B-frames in H.264 is hit-&-miss in terms of efficiency improvements (http://i.imgur.com/ge03I7d.png).

That explains x264/AVC, as there's no point in spending engineering effort on something that only moves sideways. However, for HEVC, there's a clear and compelling compression benefit (http://i.imgur.com/7WptcmI.png)* to replacing P-frames in the bitstream.

I bring this up because I'm wondering if this is something x265 will support in the future? As far as these things go, blanket efficiency boosts by playing around with slice types sound like a rather low hanging fruit.

*HM-LP is similar to the first table's 'P,1+3', HM-LB similar to 'B1+3 l1=l0'

[x265_Project]

x264 and other AVC encoders don't fully utilize generalized-B-frames. I've never really thought about why, but I came across a paper (http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=6272183) from last year that suggests completely replacing P-frames with B-frames in H.264 is hit-&-miss in terms of efficiency improvements (http://i.imgur.com/ge03I7d.png).

That explains x264/AVC, as there's no point in spending engineering effort on something that only moves sideways. However, for HEVC, there's a clear and compelling compression benefit (http://i.imgur.com/7WptcmI.png)* to replacing P-frames in the bitstream.

I bring this up because I'm wondering if this is something x265 will support in the future? As far as these things go, blanket efficiency boosts by playing around with slice types sound like a rather low hanging fruit.

*HM-LP is similar to the first table's 'P,1+3', HM-LB similar to 'B1+3 l1=l0'

B frames are generally more efficient than P frames, but there is a tradeoff with respect to random access of the video (playback from any given position in the video stream). The longer your GOP structure and the more B frames you use, the more frames that you must decode before you can decode the frame you want to start playing (on average). P frames are dependent on a single previous I frame or P frame, and they generally reduce the number of frames that any random frame would be dependent on in order to be decoded, improving random access.

Tom

[filler56789]

I bring this up because I'm wondering if this is something x265 will support in the future?

Earlier versions of x265 would use only I- and B- frames IF
"b-frames = TRUE".
The Strongene Lentoid Decoder didn't like that very-much, though.

[xooyoozoo]

The longer your GOP structure and the more B frames you use, the more frames that you must decode before you can decode the frame you want to start playing (on average). P frames are dependent on a single previous I frame or P frame, and they generally reduce the number of frames that any random frame would be dependent on in order to be decoded, improving random access.

As evident in the Low Delay configs in the HM, B-frames (as defined in the spec rather than as defined in common usage) have been generalized so that they don't need to refer to any more frames than a P-frame would (because L1=L0). Consequently, random access or lack thereof would remain exactly the same, and the only difference now would be the inclusion of these new non-future-referencing B-frames that are effectively P-frames-with-extra-coding-tools.

The paper I linked to above suggested the JM (and maybe AVC in general) didn't benefit much from this change due to overhead in coding a B slice. However, I'm trying to point out that data suggests things could be different with HEVC, and that it's no longer necessary or beneficial for an encoder to strictly define a frame-that-only-references-past-frames as a P-frame.

[x265_Project]

As evident in the Low Delay configs in the HM, B-frames (as defined in the spec rather than as defined in common usage) have been generalized so that they don't need to refer to any more frames than a P-frame would (because L1=L0). Consequently, random access or lack thereof would remain exactly the same, and the only difference now would be the inclusion of these new non-future-referencing B-frames that are effectively P-frames-with-extra-coding-tools.

The paper I linked to above suggested the JM (and maybe AVC in general) didn't benefit much from this change due to overhead in coding a B slice. However, I'm trying to point out that data suggests things could be different with HEVC, and that it's no longer necessary or beneficial for an encoder to strictly define a frame-that-only-references-past-frames as a P-frame.
I'm sorry I misunderstood your question.

This is a good question. If it's beneficial, we'll definitely be interested in doing it. Until now we haven't had a chance to explore optimizations like this. I'll check with the development team.

Thanks
Tom

[fumoffu]

After the latest commits (0.6+204-09d...) CUtree is now enabled by default.
However I don't think its working quite right yet because crf values are way off (now crf 23 looks like crf 30 looked before), I didn't test bitrate mode yet. With aq enabled there might be some artifacts again, at least with --rd 4, hard to tell because my test encode turned out in pretty bad quality.
Anyways if anyone needs to disable it for now you can use: --no-cutree

[x265_Project]

We are in the process of enabling CUTree by default. But it's complicated at the moment, due to inter-dependencies between modes. We will clean this up in the coming days. If you're doing any critical work, use a build from the stable branch.

The current default setting in the repo is... --tune psnr (CUTree ON, AQ-strength zero, weightP ON).

--no-cutree turns both CUTree and AQ off

--tune ssim turns both CUTree and AQ on

Tom

[Sm3n]

Dunno if it's very relevant...

http://i.imgur.com/mA9MEJa.png

Comparisons: http://www.screenshotcomparison.com/comparison/53387/

There is some artefacts on dark scene. May be --tune ssim gives better results.

[mandarinka]

Is there any reason why --no-cutree disables AQ?
In x264 the two aren't tied together and IMHO that is how it should ideally be.

[benwaggoner]

There is some artefacts on dark scene. May be --tune ssim gives better results.
I think --aq-mode 1 gives --tune ssim and further psychovisual optimizations.

[Sm3n]

You think aq-mode enabled is a better choice?

[benwaggoner]

You think aq-mode enabled is a better choice?
I've not done very extensive testing on that, but it seems it is overall an improvement, certainly versus tuning for psnr. But the feature is still in development so I imagine there's content that would look worse with --aq-mode 1 versus --tune ssim.

Like all things x265, things may be different in a day or a week :).

[fumoffu]

I wonder if/when there is going be implemented something like trellis in x264.
x265 has tendencies to blur a bit too much so adding some sharpness would be nice.

[x265_Project]

Is there any reason why --no-cutree disables AQ?
In x264 the two aren't tied together and IMHO that is how it should ideally be.
A quick update...
Our internal testing is showing that turning CUTree and AQ on independently does not deliver a good improvement in visual quality at a given bitrate. We get the best results when CUTree and AQ are enabled in tandem. Development and testing of these features is ongoing.

Tom

[Sm3n]

CUTree is not enabled when --tune ssim is activated in --qp mode, only in --crf and --bitrate mode. Is that normal?

[mandarinka]

CUTree is not enabled when --tune ssim is activated in --qp mode, only in --crf and --bitrate mode. Is that normal?

Yeah, that would be expected - qp mode means constant quantizer, which is not reconcilable with CUTree which by definition changes quantizers.

[Sagittaire]

@ x265_project

read that:
http://forum.doom9.org/showthread.php?t=137117&highlight=ssd

x264 have major HVS improvement at this time.

[Daemon404]

Ran a few encodes last night.... seems x265 is still destroying luma. Chart here (http://chromashift.org/img/x265/20dec2013.png). Params I used here (http://chromashift.org/img/x265/params_20dec2013.txt). Encodes here (http://chromashift.org/img/x265/encoded_20dec2013.tar.xz). Lot of blur, lots of pop-ins.

Not very impressive yet... unless you can spot somewhere I've gone wrong in my settings.

[James Freeman]

It appears H.265 has some fundamental flaws.
It softens the picture and destroys picture detail.

Can anyone tell me Why?
It seems too big of a flaw to actually use x265 for anything important.

[LigH]

The fundamental flaw may be judging a technology with the target to compress UltraHD video to sane bitrates — using magnifiers, instead of sitting back in your sofa.

[nevcairiel]

It appears H.265 has some fundamental flaws.
It softens the picture and destroys picture detail.

Can anyone tell me Why?
It seems too big of a flaw to actually use x265 for anything important.

You should not confuse H.265, the codec specification, with x265, an alpha-quality implementation with lots of work still to be done.

[James Freeman]

The fundamental flaw may be judging a technology with the target to compress UltraHD video to sane bitrates — using magnifiers, instead of sitting back in your sofa.

Its like closing your eyes and pretending the problem isn't there.

x265 samples are fundamentally flawed when comparing to x264 samples.

You should not confuse H.265, the codec specification, with x265, an alpha-quality implementation with lots of work still to be done.

Right, sorry.

I hope this "Detail Destroying" alpha stage will be gone soon.

Any one tried to compress detailed video with x265 and x264 to the same bitrate and compare the two PQ-wise (no SSIM or PSNR stuff, but real visual inspection)?

[LoRd_MuldeR]

It appears H.265 has some fundamental flaws.
It softens the picture and destroys picture detail.

Can anyone tell me Why?
It seems too big of a flaw to actually use x265 for anything important.

See also:
http://x264dev.multimedia.cx/archives/164

Yes, he's talking about H.264 encoders there, but the situation for H.265 encoders should be very similar: The standard gives you a bunch of "tools" to work with, but you need to figure out how to use/combine them in the best way.

BTW: Does x265 implement anything like x264's Psy-RDO/Trellis yet? If not, then it's not much of a surprise that it cannot keep up in detail retention with x264 right now. x264 wasn't that good in detail retention before Psy-RDO/Trellis either ;)

Also, isn't SOA (Sample adaptive offset) supposed to help with such things in H.265? Does x265 make use of SOA already?

[mandarinka]

x265 does have SAO (inherited from HM probably?), but it doesn't have PsyRDO. The RDO features as such are also inherited from HM I think. About trellis I have no idea, but I think that quantization might be RDOed - in the slow modes that is, of course.

[Daemon404]

Any one tried to compress detailed video with x265 and x264 to the same bitrate and compare the two PQ-wise (no SSIM or PSNR stuff, but real visual inspection)?

I've done a bunch, ranging from CIF to 4k, and my conclusion is the same as yours. This conclusion holds when I've tested against x264 with --no-psy as well.

I've also so noticed x265 exhibits very very bad keyframe pulsing. I know x265 doesnt have scene change detection yet, but that alone would not cause this.

[Sagittaire]

x265 have exactly the same problem than x264 in his history: grain retention is bad. Anyway x264 solve that with FGO anf after with psy mode. x265 is in alpha mode: priority is at this time to obtain best possible metric. It's always like that for new codec.

[Audionut]

People were saying the same thing about x264 vs xvid back in the day. Expectations should be lowered until x265 has a chance to mature.

[xooyoozoo]

Is there confirmation that CUTree is working as it should?

In the first 5 seconds of Pedestrian Area 1080p test clip, tested as a single GOP interval, I'm getting worse objective results at the frame and clip level when comparing --cutree against --no-cutree.

[Daemon404]

Is there confirmation that CUTree is working as it should?

In the first 5 seconds of Pedestrian Area 1080p test clip, tested as a single GOP interval, I'm getting worse objective results at the frame and clip level when comparing --cutree against --no-cutree.

I noticed the same thing when redoing my tests without it.

Still looks worse han x264, visually though.

[Dark Eiri]

So, since it's working and producing valid streams, as inherited by HM base, the priority now is porting every single good thing x264 has that is also applicable to H.265 and might help the quality, right? Psy-RDO, mb-tree and all that stuff?

[James Freeman]

I am no programmer,
but I think the right way to do this is to retain the visual quality while reducing the bitrate.

NOT, reducing the bitrate and only then Fixing the resulting degradation.
That's just illogical, and defeating the whole purpose of what's called "efficiency" in a codec.

[phate89]

I am no programmer,
but I think the right way to do this is to retain the visual quality while reducing the bitrate.

NOT, reducing the bitrate and only then Fixing the resulting degradation.
That's just illogical, and defeating the whole purpose of what's called "efficiency" in a codec.
The missing detail in high complexity parts it's not because they are trying to lower the bitrate giving up some detail but because right now x265 encoder is not advanced enough to keep that detail at those bitrates with difficult stuff.
At start x265 it was hm code, able only to produce h265 standard compliant streams without great compression results to have a (working) starting point to test and improve.
Now they're "slowly" (it's a lot of stuff to do so it takes time) adding features that make the encoder smarter, helping to keep more detail at the same bitrate. They added only some of the advanced "features" that x264 have so x265 can easily win with the "easy" stuff but with the "hard" stuff (high content bitrate) it's obvious that x265 can't beat x264, it's too "stupid"...

[Dark Eiri]

The missing detail in high complexity parts it's not because they are trying to lower the bitrate giving up some detail but because right now x265 encoder is not advanced enough to keep that detail at those bitrates with difficult stuff.
At start x265 it was hm code, able only to produce h265 standard compliant streams without great compression results to have a (working) starting point to test and improve.
Now they're "slowly" (it's a lot of stuff to do so it takes time) adding features that make the encoder smarter, helping to keep more detail at the same bitrate. They added only some of the advanced "features" that x264 have so x265 can easily win with the "easy" stuff but with the "hard" stuff (high content bitrate) it's obvious that x265 can't beat x264, it's too "stupid"...

Is it hard to port all the x264 "smart-stuff" to x265? :(

I get really excited about this since I took knowledge of x264 when it was already very nice, but I saw it getting better and better with the efforts and ideas of all the developers around here and it was magnificent to see it unfold into the beautiful monster it is today. It has become too powerful for even H265 to take it down without a hell of a struggle, it seems! haha-

With x265 I'm seeing it from the beggining, so it's like watching a demi-god being born. Unfortunarely, I'm no developer so I believe I'm not of much use to the project per-se, I'm afraid. But I'm here rooting for it just like I did for x264 and I owe you guys my very sincere thanks and infinite admiration! :D

[benwaggoner]

Is it hard to port all the x264 "smart-stuff" to x265? :(
Some yes, some no. Lots of simple heuristics that presume certain relationships between QP and quality certainly will require adaption. And HEVC has lots of options than H.264 didn't, so taking advantage of those optimally will require lots of code that just doesn't exist for x264.

For example I'd expect Trellis to be pretty linear, but psy-rd less so.

But just knowing an algorithm is possible and what it should look like makes it much easier to retune it to a different bitstream format that having to start with a new algorithm from scratch! So even if stuff can't be done like it was in x264, I expect it'll be quicker to get an equivalent feature done for x265 than it was for x264 in the first place.

But it'll certainly be a multi-year process before x265 is able to take as full an advantage of the HEVC spec as x264 is for H.264. And there's still significant room for optimization in x264.

With x265 I'm seeing it from the beggining, so it's like watching a demi-god being born. Unfortunarely, I'm no developer so I believe I'm not of much use to the project per-se, I'm afraid. But I'm here rooting for it just like I did for x264 and I owe you guys my very sincere thanks and infinite admiration! :D
Reporting bugs and cases where quality falls apart is always useful.

I've not touched code in 18 years, but I've still contributed a lot to improve many different codecs and encoding tools.

Also, there are definitely places where x265 exceeds x264. Just for amusement, I encoded Tears of Steel at 3840x1600 at the default x265 settings. The default CRF looked pretty lousy, until I realized the whole file encoded at 178 Kbps! For UHD! No way could x264 had looked as good at such a stupid low bitrate.

[Dark Eiri]

Reporting bugs and cases where quality falls apart is always useful.

I've not touched code in 18 years, but I've still contributed a lot to improve many different codecs and encoding tools.

Also, there are definitely places where x265 exceeds x264. Just for amusement, I encoded Tears of Steel at 3840x1600 at the default x265 settings. The default CRF looked pretty lousy, until I realized the whole file encoded at 178 Kbps! For UHD! No way could x264 had looked as good at such a stupid low bitrate.

Of course! That's a great idea! Since most of the developers are here, I guess it will be quite easy to file reports, right?
As soon as I get home I'll download the most recent build available and start trying out some scenarios! I'll be happy to try and be useful! :D

By the way... can I use any video sample (like my own blurays, 4K video from friends or recorded .ts TV) or would the devs prefer widely available, free samples for reports?

[foxyshadis]

Continued discussion about disappointment or the potential of the codec is probably off topic, since it's mostly speculation.

Can some of you guys test with various combinations of --rdpenalty 1 & 2, --no-strong-intra-smoothing, --ctu 16. I'm not sure it's a magic bullet, but maybe --tu-intra-depth and --tu-inter-depth of 4 as well (only applies for large CTUs, won't work with --ctu 16). --rdpenalty 2 disables 32x32dct in some cases, but there's no absolute off switch like like x264's --no8x8dct, and no other way to fiddle with maximums and minimums without editing the source. Smaller blocks should net more detail at the cost of quality reduction in smoother areas. This is just for developer feedback; even if something works it shouldn't be considered the magic bullet to get detail/grain retention in x265.

I'm at work and don't have access to my blurays to test with.

[x265_Project]

Of course! That's a great idea! Since most of the developers are here, I guess it will be quite easy to file reports, right?
As soon as I get home I'll download the most recent build available and start trying out some scenarios! I'll be happy to try and be useful! :D

By the way... can I use any video sample (like my own blurays, 4K video from friends or recorded .ts TV) or would the devs prefer widely available, free samples for reports?

Sounds good Dark Eiri! Additional testing and feedback would be very helpful and very much appreciated.

We're testing with all of the standard test clips that the Joint Collaborative Team on Video Coding (JCT-VC) is using, but we've tested these to death. We're also using many of the publicly available clips uncompressed (from Xiph.org, etc.). And we're getting test clips from our commercial customers.

Using clips that are available to anyone is advantageous in that others can understand and if needed, reproduce your results. However, we want to hear how x265 performs under the widest range of real-world conditions, so feel free to test with any and all content (home video, mobile phone video, webcam video, anime, video game captures, GoPro footage, etc.).

Tom

[xooyoozoo]

The recent CUTree fix seems to be doing its job. I haven't looked at objective metrics, but visual improvements over having the feature off are palpable.

I did some x265 encodes at default CRF and compared against x264 without psy. I'm not claiming this is x264 at its finest, but I also don't think psy-rd would be a magic salve. Even 0.4:0 was too much in this situation, and that's the lowest offered in an x264 tuning. Beyond that, I think I can claim x265 is a comfortable superset of x264's coding quality, at least at medium and lower bitrates.

Side-by-side comparisons and bitstreams link (https://drive.google.com/folderview?id=0BzAA-H5x8NKTMnVIMW5BUU9sakE&usp=sharing). All encodes used veryslow presets, aq-mode 2, 0.5s min-keyint, 5s max-keyint, and --ref set to whatever AVC L4.2 allows. The clips are either straight from a Bluray or resampled/resized versions of real test sequences.

Lastly, there might be a bug with x265+CUTree and the very first frame. In most of the clips, you can clearly see that the initial I-frame has much lower quality than the frames in the next couple of seconds.

[benwaggoner]

Continued discussion about disappointment or the potential of the codec is probably off topic, since it's mostly speculation.

Can some of you guys test with various combinations of --rdpenalty 1 & 2, --no-strong-intra-smoothing, --ctu 16. I'm not sure it's a magic bullet, but maybe --tu-intra-depth and --tu-inter-depth of 4 as well (only applies for large CTUs, won't work with --ctu 16). --rdpenalty 2 disables 32x32dct in some cases, but there's no absolute off switch like like x264's --no8x8dct, and no other way to fiddle with maximums and minimums without editing the source.
Based on description, it sounds like --rdpenalty 1 should be the default, given the description of:
--rdpenalty penalty for 32x32 intra TU in non-I slices. 0:disabled 1:RD-penalty 2:maximum. Default 0

Is there any downside to at least using 1 instead of 0? And what's the difference between 1 and 2 in practice?

Also, for what scenario are you tuning with those settings? 1080p? I'm pretty confident that 32x32 blocks are useful in UHD encoding.

Which I'm getting 90:1 encoding times with on a dual socket 16-core E5-2680 v2 system, FWIW :). First time I've actually gotten slower than my PowerMac 8100/80 was encoding 320x240p15 Cinepak (80:1).

[greenfountain]

@Atak_Snajpera, can you test your water clips with the latest fix for cutree, aq n x265 pls? we should be seeing much better results in terms of reduction in blurring out the details this time around.

[Atak_Snajpera]

@Atak_Snajpera, can you test your water clips with the latest fix for cutree, aq n x265 pls? we should be seeing much better results in terms of reduction in blurring out the details this time around.

There is original source file
http://forum.doom9.org/showthread.php?p=1657444#post1657444

Do it yourself.

[vood007]

Did not test that water clip but for my own por err personal stuff i see a huge step in speed and quality with the latest build. x265 team for devs of the year award!!1 ;)

[benwaggoner]

Did not test that water clip but for my own por err personal stuff i see a huge step in speed and quality with the latest build. x265 team for devs of the year award!!1 ;)
Quality, yes. Speed seems to be half of last week's dev tip builds for me. Although I've been mainly doing --preset veryslow at UHD resolutions.

I live my life as an edge case :). Thank goodness for the new Ivy Bridge cc3.8xlarge (https://aws.amazon.com/ec2/instance-types/#instance-details)instances. I'm still getting about 1 min encoded per 3 hours of encode time, though.

I see there were some commits (https://bitbucket.org/multicoreware/x265/commits/all)last night for weight analysis and fixing the first I-frame quality issues. I've been really impressed by how responsive MultiCoreWare has been to issues brought up in this thread.

[bxyhxyh]

I did test when 0.5's early time. Preset fast was slower than 10 bit x264's preset veryslow.

And when I did test on yesterday, preset slow's speed was nearly same as 10 bit x264's preset veryslow.

Quality is increased too but it still blurry.

x265 preset slow, crf 28 - 26.2 mb
x264 preset veryslow slow first pass - 26.2 mb

http://check2pic.ru/compare/34248/

[benwaggoner]

What pix_fmt are folks using in Y4M for x265.exe? yuv420p10le?

[sneaker_ger]

Unless this was added in the last weeks you cannot use 10 Bit input with Y4M header. Use raw input for 10 Bit.

[plonk420]

are there any suggestions on how to retain grain the way --deblock -3:-3 does with x264? Panic Room (DVD) is giving me issues...

oddly, super strong grain like the music video Rapture by Iio retained grain quite well with default settings...