x265 HEVC Encoder

[xooyoozoo]

In some clips, there's still a massive, erroneous upswing in quality between the first I-frame and subsequent frames. In2tree offers the clearest example (https://drive.google.com/file/d/0BzAA-H5x8NKTWXFXUFZZYWVZcFE/edit?usp=sharing) of this. Settings were written in the track name tag.

[x265_Project]

In some clips, there's still a massive, erroneous upswing in quality between the first I-frame and subsequent frames. In2tree offers the clearest example (https://drive.google.com/file/d/0BzAA-H5x8NKTWXFXUFZZYWVZcFE/edit?usp=sharing) of this. Settings were written in the track name tag.

We're aware of this bug, and I expect it to be resolved soon. We see the same thing with Tears of Steel, which starts out with credits for 215 frames (driving QP to zero with ABR rate control). QP isn't boosted fast enough, and you get a big bit rate spike until things settle out.

Tom

[xooyoozoo]

Frame order of an encode with ref=8:

POC 28 (P) [L0 24 22 20 18 16 14 12 10 ]
POC 26 (B) [L0 24 22 20 18 16 14 12 10 ] [L1 28 ]
POC 25 (b) [L0 24 22 20 18 16 14 10 ] [L1 26 ]
POC 27 (b) [L0 26 24 22 20 18 16 14 10 ] [L1 28 ]
POC 32 (P) [L0 28 26 24 22 20 18 16 14 ]

Shouldn't pic 25 also use 28 in L1? 28 is still being kept around in the DPB and is already used as a ref in a dependency.

x265 doesn't ever let L1 size be greater than 1, in contrast to both the HM and x264. Is this a design choice for frame parallelism or simply something that's not yet evaluated?

[x265_Project]

Frame order of an encode with ref=8:

POC 28 (P) [L0 24 22 20 18 16 14 12 10 ]
POC 26 (B) [L0 24 22 20 18 16 14 12 10 ] [L1 28 ]
POC 25 (b) [L0 24 22 20 18 16 14 10 ] [L1 26 ]
POC 27 (b) [L0 26 24 22 20 18 16 14 10 ] [L1 28 ]
POC 32 (P) [L0 28 26 24 22 20 18 16 14 ]

Shouldn't pic 25 also use 28 in L1? 28 is still being kept around in the DPB and is already used as a ref in a dependency.

x265 doesn't ever let L1 size be greater than 1, in contrast to both the HM and x264. Is this a design choice for frame parallelism or simply something that's not yet evaluated?
Our development team is taking a look at this.

Tom

[fumoffu]

Can development team also look at -aq-strength please?
because:
- documentation (a bit outdated at this point) says possible values are between 0.0 and 3.0 but 2.0 and greater values seem to not work correctly. Maybe it's just typo in the Evaluators Guide?
- it doesn't seem to be doing much
I already wrote about it but it seems impossible to decently preserve skin textures with x265. It flattens other delicate stuff too but it's most visible on skin probably because human eye tends to pay attention to it. So basically it sucks at encoding porn... and while this might seem a bit funny porn is probably 50% of all video data in existence ;)
Skin always blurs too much and looks pretty much identical, no matter crf 21 or 16, aq-strength 1.0 or 1.8
x264 sometimes could struggle with this as well (especially without trellis) but not to that extend and more importantly raising aq-strenght a bit was immediately visible improvement.

[easyfab]

Tom Vaughan at CES

https://www.youtube.com/watch?v=yYy5nD25PPc#t=30

[mandarinka]

x265 lacks psyRDO (as well as said trellis quantization), which probably also has a huge role in preserving textures.

That said I agree that detail and texture presevation are very needed if x265 is to ever come out of x264's shadow. Not just for the type of material you mention but in general - for high quality 4K encodes (future bluray replacement) or higher quality web video etc. Of for anime fansubs :)

[x265_Project]

x265 lacks psyRDO (as well as said trellis quantization), which probably also has a huge role in preserving textures.

That said I agree that detail and texture presevation are very needed if x265 is to ever come out of x264's shadow. Not just for the type of material you mention but in general - for high quality 4K encodes (future bluray replacement) or higher quality web video etc. Of for anime fansubs :)

These capabilities are on the development roadmap. We're getting more and more high quality material to test with from Hollywood studios, and we're starting to be able to focus in this area.

Tom

[x265_Project]

Tom Vaughan at CES

https://www.youtube.com/watch?v=yYy5nD25PPc#t=30
I'm glad this finally showed up. I ran into Patrick Norton at CES, and when I explained what we were working on he was very interested. He asked "can we have this conversation on camera?", and I agreed. So I quickly briefed him on the project, and then we just shot this in one take.

I like the part where I say "35 to 50% more efficiently", and they show my slide that says "25 to 35% lower bit rates at equivalent quality". :o

Tom

[easyfab]

I like the part where I say "35 to 50% more efficiently", and they show my slide that says "25 to 35% lower bit rates at equivalent quality". :o

Tom

And I was very surprised at 1:34 :D

[x265_Project]

And I was very surprised at 1:34 :D
They didn't show the title on this slide, which reads "x265 Project Advisors".

[xooyoozoo]

One of the new commits today (weightp?) is causing mismatched hash.

Example 50 frame clip (https://drive.google.com/file/d/0BzAA-H5x8NKTUlQ4LXp3UUYzNkE/edit?usp=sharing). Defaults CRF28 = okay. Plus ref 4 = lol.

[x265_Project]

One of the new commits today (weightp?) is causing mismatched hash.

Example 50 frame clip (https://drive.google.com/file/d/0BzAA-H5x8NKTUlQ4LXp3UUYzNkE/edit?usp=sharing). Defaults CRF28 = okay. Plus ref 4 = lol.

It was an attempt to fix an issue, but we're not there yet. We're zeroing in on the issue now, but in the meantime, I suggest you use an earlier build.

[fumoffu]

x265 lacks psyRDO (as well as said trellis quantization), which probably also has a huge role in preserving textures.

That said I agree that detail and texture presevation are very needed if x265 is to ever come out of x264's shadow. Not just for the type of material you mention but in general - for high quality 4K encodes (future bluray replacement) or higher quality web video etc. Of for anime fansubs :)

I was just wondering if this is just lack of features or maybe some small bug is causing this. Because DivX implementation seems to blur less and also if you need psyRDO and trellis to preserve textures does this mean that most other encoders and more importantly all hardware implementation of HEVC encoder will blur too much and there is nothing you can do about this?

[mandarinka]

more importantly all hardware implementation of HEVC encoder will blur too much and there is nothing you can do about this?

Yeah, that is what I sort of expect :/. Well, the same goes for H.264 too, though, AFAIK (and VP8/9 etc).

[fumoffu]

After last few commits I noticed CPU usage fluctuates a lot more, before it was pretty consistently 95% or higher, now it's more like 85-95%.
I use default setting with --early-skip (edit: just checked: without --early-skip it's the same).

edit: ok turns out this is very source dependent but I don't think it was before

btw. --early-skip seems really nice, it offers significant encoding speed boost for very small cost, imho it could be enabled with fast and medium presets too and maybe even in slow (or is that heresy? :devil:)

[greenfountain]

Can development team also look at -aq-strength please?
because:
- documentation (a bit outdated at this point) says possible values are between 0.0 and 3.0 but 2.0 and greater values seem to not work correctly. Maybe it's just typo in the Evaluators Guide?
- it doesn't seem to be doing much

We tested some clips ( in_to_tree_420_720p50.y4m, parkrun_720p.y4m and a few more in ABR/CRF modes ) with both x264, x265 with various aq-strength from 1 to 3. Observed that maximum quality improvement is seen around 1.7-2 in both x264 and x265 so far..But its mainly up to the user to set the strength since they know their input material better,so we're leaving the aq-strength range the same as x264.

[Dark Shikari]

parkjoy/parkrun tend to benefit from significantly higher AQ than default -- but setting AQ that high tends to hurt a lot of other videos, hence the lower defaults. A smarter algorithm might be able to adapt better to videos with very uniform areas of high complexity like parkjoy, versus edges and other areas that can't take quite as high a quantizer.

[x265_Project]

We tested some clips ( in_to_tree_420_720p50.y4m, parkrun_720p.y4m and a few more in ABR/CRF modes ) with both x264, x265 with various aq-strength from 1 to 3. Observed that maximum quality improvement is seen around 1.7-2 in both x264 and x265 so far..But its mainly up to the user to set the strength since they know their input material better,so we're leaving the aq-strength range the same as x264.

To clarify - greenfountain is one of the x265 developers.

Tom

[xooyoozoo]

On the short seq (https://drive.google.com/file/d/0BzAA-H5x8NKTUlQ4LXp3UUYzNkE/edit?usp=sharing) I previously linked, backing out of the recent cuTree bugfix (https://bitbucket.org/multicoreware/x265/commits/3cf5a75a80026f1222d45ad30e276884117e9649) gives a 3-5% SSIM bdrate improvement on CRF 20,23,26,29. This seems to be reproducible in both medium and veryslow and a couple other 720p clips. I'm not sure if there's something with the bug fix or just something the fix uncovered.

[xooyoozoo]

Oh and x264's compilation speedup (http://git.videolan.org/?p=x264.git;a=commit;h=956c8d8c2a3c2fb1f2f17807532321e492c75efc) seems to work with x265. I think it's preferable to separately modifying yasm like the wiki suggests.

[JEEB]

The patch for yasm is the real fix, since the search for macros in yasm is very, very non-optimal. By making the hash table bigger, you only make the assembler use some kilobytes of memory more, yet you gain a massive speed-up.

The x86inc.asm change is of course an optimization in its own right, and applying it shouldn't generally be a problem.

[qyot27]

I had been wondering why the heck it always took so long to build x265, since it seems to get caught on the ASM (~two hours for x265, IIRC, compared to <20 min. for x264). Good to know that there's an actual reason.

I'll have to run some new tests now with both of them to see what kind of speedup I get.

EDIT: Using yasm (git HEAD) with the patch,
x264 (git HEAD) = ~12 min.
x265 (development tip) = ~35 min.

So it still takes longer to build x265, but only about 3x now instead of 5-6x.

[MoSal]

I had been wondering why the heck it always took so long to build x265, since it seems to get caught on the ASM (~two hours for x265, IIRC, compared to <20 min. for x264). Good to know that there's an actual reason.

I'll have to run some new tests now with both of them to see what kind of speedup I get.

EDIT: Using yasm (git HEAD) with the patch,
x264 (git HEAD) = ~12 min.
x265 (development tip) = ~35 min.

So it still takes longer to build x265, but only about 3x now instead of 5-6x.

The high-level language in x265 is C++ :scared:

[foxyshadis]

If a way could be found to prevent yasm from re-assembling unchanged files every single build, and instead assemble as many files at once as you have cores, build times would be cut 70-80% without any changes. Right now every asm file is built twice, once for static and once for shared, every time.

Maybe it'd be better to have them in a separate project for starters? I don't know, I'll play around with it tonight.

[x265_Project]

For those experiencing long compile times on Windows, you might try the built-in Windows MSBuild compiler instead of running Visual Studio. My compile times on a quad-core (Core i7 4700HQ) notebook are generally just a minute or two, especially now that we have the improved version of YASM.

My Pull/Make/Build script for 8 bit development builds looks like this...

c:
cd c:\x265
hg pull -u https://bitbucket.org/multicoreware/x265
hg up tip
hg sum
pause
REM This pause allows me to abandon the build if there are no new commits.
cmake -G "Visual Studio 11 Win64" -DHIGH_BIT_DEPTH:BOOL=OFF C:\x265\source --build C:/x265/build/vc11-x86_64
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\msbuild.exe C:\x265\build\vc11-x86_64\x265.sln /m /t:build /p:configuration=release
REM Copy the new build to my test directory.
xcopy C:\x265\build\vc11-x86_64\release\x265.exe c:\Testx265\x265.exe /Y


I hope this helps.

Tom

[x265.cc]

For those experiencing long compile times on Windows, you might try the built-in Windows MSBuild compiler instead of running Visual Studio.

Do you really experience lower build times if using the command line instead of the VS gui? :confused:


-----

Also i have another question:

Whats the reason for publishing new code changes in the stable tree first, and merging them later in the development tree?

Afaik the development tree should be always ahead and stable development tree changes should be merged into the stable branch. :confused:

-------------------

Yov've won, Mr. Vaughan. I've stopped my x265 buildbot project, which was planned to support the project by open it for video encoding newbies.

Keep your weird marketing up, it would be much easier if you had wrote me a email at the beginning, as i've told you.

-------------------

@x265.ru: if you're still intrested, resend me your email ;)

[fumoffu]

Thank you for your work x265.cc
I really don't understand x265 developers reasoning...
I was really optimistic for the project but for some time now I didn't see any improvement in video quality, on many sources x264 is still much better, sure sometimes x265 gives impressive, small file size but if you apply temporal/spatial noise removal or some other clever filter before x264 compression you'll get nice small bitrate too and this is how x265 looks often right now.
And now this, ehh...
Somebody doesn't want their encoded tested by too many users?
I remember developers encourage testing before...

[mandarinka]

Funny that you suggest VP9 as alternative project. That is pretty much a controlled project and I don't think you can currently get Windows builds anywhere... (or am I mistaken?)

If anything isn't desired to be tested by the unwashed masses, it is VP9 :D

[x265_Project]

We support and encourage adoption of the x265 software worldwide. GPL software is available to all to do what they would like (under the terms of the GPL). Anyone can create and distribute builds. That's not the issue here.

If you are setting up a business or a website, don't use another organization's trademark. It's better to build your own brand.

Tom

[Selur]

If anything isn't desired to be tested by the unwashed masses, it is VP9
without better rate control (2pass encoding hitting near a specified bit rate seems to be just luck) and multi-threading support VP9 simply isn't that appealing.

[mindwin]

Its like OpenOffice, open source but registered trademark.
But who now is using OpenOffice?

We all use LibreOffice!!! )))

I think this is a very good lesson for all holders of trademarks.

[aBra]

I've tried to compile x265 for myself and failed. Maybe I'm too stupid, but I can't get the tools to create a x64 executable. So for me, projects like x265.cc are perfect and it's a shame, the developers won't support it. :/

[x265_Project]

Mindwin,
We are very strong advocates of open source, and we are active contributors to a number of open source projects including LibreOffice.

We welcome and support the entire open source community, but there is really no legitimate need for anyone to use our project name for their site.

Tom

[LigH]

So the complaint is rather about naming the site (and the user account) "x265.*", less about providing autobuilds of vanilla checkouts? Using a more personal domain (similar to offering Xvid binaries on koepi.info) would be acceptable?

I would be relieved if the issue were so specific. So all could be summed up as "bad idea to start working before talking".

[James Freeman]

@x265_Project

I didn't follow the whole exclusivity story...are you the only one now like VideoLan x264?
How do you relate to Rovi?
Are there any other versions/developers?
If so, what is the point of having multiple versions?

[x265_Project]

So the complaint is rather about naming the site (and the user account) "x265.*", less about providing autobuilds of vanilla checkouts? Using a more personal domain (similar to offering Xvid binaries on koepi.info) would be acceptable?

Exactly. Yes.

[Brazil2]

If you are setting up a business or a website, don't use another organization's trademark. It's better to build your own brand.
I understand.
That's the reason why you have choosen "x265" as a name because it's original and doesn't look nor sound like "x264".

[Atak_Snajpera]

I understand.
That's the reason why you have choosen "x265" as a name because it's original and doesn't look nor sound like "x264".

The same story with doom9.org vs doom10.org ;)

[xooyoozoo]

Trademark restrictions on third-party binaries aren't anything new. (http://www.mozilla.org/en-US/foundation/trademarks/community-edition-policy/)

[pieter3d]

Funny that you suggest VP9 as alternative project. That is pretty much a controlled project and I don't think you can currently get Windows builds anywhere... (or am I mistaken?)

If anything isn't desired to be tested by the unwashed masses, it is VP9 :D

The VP8/VP9 encoder can be built on windows, but it is kind of a pain. If anyone is interested I can write a separate post on how to do it in the other forum on alternative codecs.

[x265_Project]

I understand.
That's the reason why you have choosen "x265" as a name because it's original and doesn't look nor sound like "x264".
To clarify this point, we didn't just decide to call our encoder x265 without the support of the x264 development team. We discussed the idea at length with the x264 team, and then reached an agreement which enables us to modify and adapt x264 source code for use x265. This is why the x265 syntax is so similar to x264 syntax.

[mariush]

So I guess a lot of people would hate me if I'd start publishing binaries on x265.net :) No worries, not going to do that.

btw... x265_Project if you guys are interested in the domain I'm willing to transfer it to your group, as long as I can get back my registration costs (about 25$ in total).

I bought it some time ago (maybe a couple of years) to (eventually) donate it to an open source group like x264 but you guys can afford spending a few dollars for it.

[x265_Project]

So I guess a lot of people would hate me if I'd start publishing binaries on x265.net :) No worries, not going to do that.

btw... x265_Project if you guys are interested in the domain I'm willing to transfer it to your group, as long as I can get back my registration costs (about 25$ in total).

I bought it some time ago (maybe a couple of years_ to donate it to an open source group like x264 but you guys can afford spending a few dollars for it.
Thanks Mariush. I'll contact you directly.

Tom

[Procrastinating]

We didn't just decide to call our encoder x265 without the support of the x264 development team. We discussed the idea at length with the x264 team.

Is the problem confusing "trademarked" x265 with "not official" x265? For example, would x26S or xH265 be reasonable names, particularly given the small range of non-genericness the x265 trademark has.

Similarly, is it reasonable to immediately state that the software in question is in fact, a build of x265?

[x265_Project]

Is the problem confusing "trademarked" x265 with "not official" x265? For example, would x26S or xH265 be reasonable names, particularly given the small range of non-genericness the x265 trademark has.

Similarly, is it reasonable to immediately state that the software in question is in fact, a build of x265?

With trademarks the question is whether a name/mark is "confusingly similar (http://en.wikipedia.org/wiki/Confusing_similarity)" to the trademark in question.

[kieranrk]

Mindwin,
We are very strong advocates of open source, and we are active contributors to a number of open source projects including LibreOffice.

We welcome and support the entire open source community, but there is really no legitimate need for anyone to use our project name for their site.

Tom

Except as you know you're not the trademark holder in all parts of the world...
That said I can see why you want to reduce confusion; a disclaimer would have been ok.

[x265.cc]

Except as you know you're not the trademark holder in all parts of the world..

They do NOT own the trademark in any country.

(Country = owner)

Registered Trademarks*:

GB = VideoLAN non-profit organization
FR = VideoLAN non-profit organization
EU = VideoLAN non-profit organization

Requested:

US = MulticoreWare, Inc. Corporation CALIFORNIA


Just to clarify, since he often states i violate there trademark.

JFYI there are 19 x265.tld domains registered.


*Buildbot was EE based, i've also asked the trademark owner (VideoLAN) for permission. (btw.. x264.nl..)

[Audionut]

This is the problem with companies, despite how much they praise open source, it always boils down to the bottom dollar.

It was quite clear to anyone with half a brain that x265.cc was not affiliated with with MultiCoreWare Inc. It's just another case of a, for profit company, flexing it's legal prowess.

[Kurtnoise]

@Tom : why not putting binaries on your website in this case ? Otherwise, you can ask directly to VLC organization (Jean-Baptiste Kempf, the responsible, iirc) to create something like we have for the x264 encoder...