x265 HEVC Encoder

[benwaggoner]

MPC-BE
LAV Filters
Strongene Lentoid HEVC Decoder
Osmo Player from GPAC
Nice to see the support and multiple independent implementations. But I was asking about consumer-facing players or architectures.

Something that doesn't require a user to have Admin access to install an unusual package.

[vood007]

First ARM SoCs with HEVC are announced for mid 2014 AFAIK. I am quite sure x265 will be ready when we really need it, means when 4k stuff start to be spread. Its hard to say when this will happen, 4k PC displays are still 10x as expensive as HD ones and theres not that *must have" feeling we all had when HD came around the corner. I´d say give it *some" years and meanwhile be happy x265 team let us watch how this fine project evolves...

[Selur]

Have you added anything to the source / your binary?

If not, it will still not work.
Haven't modified the source, but encoding works fine here,...

[Sagittaire]

That's true and unfortunately useless for now. I doubt that in 2014 x265 will beat x264 in those "extreme samples" by 50%.

x265 work already for real life source like movie. Your sample are useless ... :devil:

In your sample you have water with chaotic mouvement: all codec fail to encode that because it's really uncompressible.

[foxyshadis]

But this footage was taken from camcorder for god sake. Are you saying that x265 is designed only for static anime?

Less redundancy in the source means less possibility for further compression, no matter what algorithm you use. Jumpy, noisy sources are always less redundant; camcorder footage is actually some of the least compressible video out there. Similarly MPEG2->AVC won't get you much extra compression for the same footage. On typical movies with steadycam it'll be near 50% less, unless a blinding amount of extra grain is added.

If you calmed the shaking and processed out some of the noise, you'd see a substantial improvement.

[MythCreator]

0.6+150 & newer version works for me, cheers~~

[Atak_Snajpera]

If you calmed the shaking and processed out some of the noise, you'd see a substantial improvement.
So basically I should always carry tri-pod with me because so called next-gen codec is not able to keep details? Also I'm not allowed to record my kids playing by the sea because unpredictable water will destroy details on their faces and whole sand will look blurry? Don't you think this should work in opposite way? Encoder should do all it's magic to keep all fine details even at high motion scenes with low bitrate. Somehow x264 has no problem with that even at those crazy low bitrates (--crf 34.25 ~2Mbps) and still whole encoding time is 4 times faster! If encoder can survive those high motion , high detail scenes it will also survive "talking head" footage and movies with crazy high depth-of-field.

In your sample you have water with chaotic mouvement: all codec fail to encode that because it's really uncompressible.
uncompressible my ass!
http://i.cubeupload.com/unMKl5.pnghttp://i.cubeupload.com/YaXv9E.png
http://i.cubeupload.com/TRV3q9.pnghttp://i.cubeupload.com/xTEbe4.png

[sneaker_ger]

So basically I should always carry tri-pod with me because so called next-gen codec is not able to keep details? Also I'm not allowed to record my kids playing by the sea because unpredictable water will destroy details on their faces and whole sand will look blurry?

No, you can keep using x264 as long as you like and wait for x265 (or other H.265 encoders) to mature. No one ever promised that every H.265 encoder will be better than x264 for all content from the beginning - some might never surpass x264. H.265 offers more potential than H.264, that's pretty much it. Dark Shikari wrote that it took years development for x264 to consistently beat xvid (http://forum.doom9.org/showthread.php?p=1634558#post1634558). He even wrote a post saying that in some cases mpeg2 encoders did a better job than some H.264 encoders (http://x264dev.multimedia.cx/archives/164). I must say I was surprised when x265 beat x264 in a short test I did (more Hollywood blockbuster type of content).

It's good to make constant comparisons and reviews of the x265 development, but at the current point any kind of complaints when x264 does a better job than x265 are out of place. We weren't promised that to be the case by the devs, those are goals for the future. Maybe we should create a separate thread for constant comparisons of x264 vs. next-gen encoders and let this one focus more on new features, bug reports etc.

P.S.: The sky looks better in the x265 encode. Apart from that I agree that x264 simply destroys x265 for these samples.

[MythCreator]

So basically I should always carry tri-pod with me because so called next-gen codec is not able to keep details? Also I'm not allowed to record my kids playing by the sea because unpredictable water will destroy details on their faces and whole sand will look blurry?


The things you say , also happened in early time of x264. In that period, there is a lot of people say that x264 is totally bulls**t. But now？ You know it.

[mandarinka]

Yeah, I would also say that the detail removal on the wall and on the silver spruces for example is hardly justifiable. Those patches of solid color actually look like something that a bug or corruption would produce to me, rather than a normal compression artifact.

Of course x264 isn't perfectly looking either, so x265 probably falls apart partially due to lowish bitrate?

[James Freeman]

Yeah, I would also say that the detail removal on the wall and on the silver spruces for example is hardly justifiable.
Those patches of solid color actually look like something that a bug or corruption would produce to me, rather than a normal compression artifact.

I think so too, there is no way it looks THIS bad.

[Atak_Snajpera]

The same "bug" is here as well
http://forum.doom9.org/showthread.php?p=1657187#post1657187

[JEEB]

I like it how everyone ignores Sagittaire's attitude towards Atak_Snajpera (esp. where he tells him that his 'sample are useless'), while his tests are just a response to the very positive claims here (http://forum.doom9.org/showthread.php?p=1657132#post1657132).

I think everyone in this thread understands that x265 is a heavily WIP project, and at relatively early stages (although the HM base does give an advantage to the vendor in getting something 'to work'). It's still rather important to get a general look at how it is going every now and then. And downplaying any relatively-sane testing is just silly. Improper testing is a separate thing, and that of course should be noted and, if possible, corrected.

I have done some testing for SSIM (calculated with the dump_ssim tool from the daala repository) with an animated 2158 frame 720p24 sample just before the 0.6 tagging myself (looking at the results while at it), and the current evaluation I have for x265 (with the CRF mode) is:

It can beat x264 in overall SSIM already (keyints matched, preset placebo for both, tune ssim for x264 and aq-mode 1 for x265, as that is the only thing that tune ssim currently does on that side).

x265: Total: 13.501 (Y': 12.4967 Cb: 16.1191 Cr: 17.3511 ), x264: Total: 13.4168 (Y': 12.5562 Cb: 15.3001 Cr: 16.6475 )
x265: Total: 15.4499 (Y': 14.7066 Cb: 16.9546 Cr: 18.0772 ), x264: Total: 15.3943 (Y': 14.7724 Cb: 16.4152 Cr: 17.6585 )
x265: Total: 17.5805 (Y': 17.1232 Cb: 18.223 Cr: 19.1715 ), x264: Total: 17.4453 (Y': 17.1263 Cb: 17.6575 Cr: 18.7367 )

It blurs. A lot.
Poking some people with the encoded samples for a quick visual inspection, some (usually less technical folk) see little difference, while the rest prefer how x264 encodes.
If calculated with the Avisynth SSIM plugin, x264 wins with the average on everything but the highest bit rate target. As I was not sure how standard its calculations are, I opted for the dump_ssim tool instead. Not to mention that the Xiph tool also outputs 10*log10(1/(1-ssim)) instead of just pure SSIM values.

I will post all the numbers and the streams (I tested multiple bit rate targets) after I finish making some nice graphs. If I give up on that, I will just post the results and you can have fun with the numbers yourselves ;) . I will also test 10bit encoding later, as that is another point of interest for myself.

Also, do note that the default keyint-min value is rather different from x264 in x265 (same as the default keyint, 250), and that the IRAP type used is different as well, not IDR but CRA (still called CDR in x265 and most probably in HM). CRA lets one not kill off references and adds the possibility of using leading pictures that then reference to pictures before the CRA picture, although I have no idea if x265 uses this feature. HM did use it if I recall correctly.

[x265_Project]

Jeeb,
It's really helpful when people approach these discussions from an analytical perspective, performing tests and sharing their results and insights. Thanks for sharing!

Tom

[fumoffu]

I like it how everyone ignores Sagittaire's attitude towards Atak_Snajpera (esp. where he tells him that his 'sample are useless'), while his tests are just a response to the very positive claims here (http://forum.doom9.org/showthread.php?p=1657132#post1657132).



Well maybe Sagittaire's attitude had something to do with this:
Files created by x265 remind me WMV3/9 ;) Ultra slow encoding and everything smeared.

;P

But seriously I think in most cases if we post here something that look like criticism we are not hating on x265 but rather hoping that one of the devs will see it and will go look for bugs or ways to improve the encoder (yes I know it's not that easy..).

Also, about AtakSnajpera tests (hejka ;) )
I was wondering: With complex source with semi random stuff like moving water and trees it's possible that high number of reference frames (16 on very slow) is very helpful for x264 (because there is a bigger chance that encoder will find something similar enough to use as reference) and x265 even at placebo uses only 5 ref.
So for my curiosity, if you are not too busy can you maybe also test x264 restricted to --ref 5 ?

[xooyoozoo]

On the first 100 frames of the Sunflower test sequence, encoded as a single GOP block, and using x265 @a87f12e:

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

( The HM12 QP points were at [20 23 26 29]. CRF used for x264 & x265 were respectively [18 21 24 27] and [19 22 25 28]. )

Keeping the encoding parameters above and looking at *SSIM instead, perhaps there's a commentary on what each encoder promotes at a basic level, before human-friendly features are added on top of everything:

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

Against the HM, YPSNR bdrate says that x264/265 respectively needs 111% & 26% more bitrate for the same quality. MS-SSIM worsens the numbers a bit for x264 and proportionately more for x265.

If I had a point, it'd be that development is obviously still ongoing, and neither the HEVC bitstream nor the x264 feature set has been fully optimized here.

[benwaggoner]

Also, in comparing CRF, I don't think that any attempt has been made to have the CRF scale be the same between x264 and x265. They are both relative to QP for the given format, and HEVC and H.264 QP values weren't designed to have similar perceptual quality.

Comparing at equal CRF is probably not useful at this point. Hopefully we can eventually figure out some RF equivalence mapping.

[foxyshadis]

So basically I should always carry tri-pod with me because so called next-gen codec is not able to keep details? Also I'm not allowed to record my kids playing by the sea because unpredictable water will destroy details on their faces and whole sand will look blurry?

I wasn't implying that you can't do it, I meant using Avisynth to pre-process the video to get some improvement and not look quite so horrible, though that would also improve x264.

Until AQ and CU-tree land, there's no possibility of x265 beating x264 on encoder torture tests like yours. In the meantime, x264 is obviously so much higher perceptual quality that it's only worth using that video as a routine testing source to track the progress as it evolves.

[James Freeman]

what's HM12.1?

[LigH]

The HEVC Test Model (http://hevc.info/HM-doc/) (specification) and reference encoding/decoding software. There is a source git repository (http://hevc.kw.bbc.co.uk/git/w/jctvc-hm.git) at the BBC, as well as an SVN repository (https://hevc.hhi.fraunhofer.de/svn/svn_HEVCSoftware/trunk) at Fraunhofer HHI.

[mandarinka]

The reference encoder (note that it is very very slow and more or less unusable practially).
Edit: ah sorry, it has already been explained. I should have refreshed the thread before reply.

[James Freeman]

Thanks, but few questions arise:

Why should the big guys (major studios that release blurays) care for other encoders besides the reference one if they have no time concerns?
Why not just use the best even if its slower?

According to the graphs xooyoozoo posted, HM 12.1 actually IS twice as better as x264.

Is x265 is more like a third party based on guidelines, compared to the official code of the Test Model?
Will hardware encoders will use the official Test Model code?

[sneaker_ger]

1. Blu-Ray does not support H.265 at all, so I don't know why you are asking here.
2. x264 and other H.264 encoders beat the reference one not only speed but also quality wise.

[kypec]

Why not just use the best even if its slower?
I'm no content producer but believe me - HM reference encoder is so slow that there would be sequel of Hobbit released in cinemas sooner than the first movie was actually encoded into HEVC by that piece of software.:D

[Atak_Snajpera]

because encoding 2h-3h movie 3840x2160 would take weeks /months? ;)

[foxyshadis]

I'm no content producer but believe me - HM reference encoder is so slow that there would be sequel of Hobbit released in cinemas sooner than the first movie was actually encoded into HEVC by that piece of software.:D

One benchmark:

While up to 100 hours were needed to encode a single 10-second test case (BQTerrace) with version 0.7 of the reference software, the time was reduced to a more manageable 20 hours a few versions later.

This was with several 6-core Nehalem Xeons @ 3 GHz. BQTerrace is 600 frames, 1080p. 12.1 is much more optimized, almost twice as fast. Cool!

60 frames per hour on a 24-core cluster. Now reduce that for however many cores you have, while adjusting for Sandy Bridge bring roughly 50% faster, and Ivy Bridge & Haswell roughly 100% faster. Oh, and 4K video will cost more than 4x the time.

That's why no one is using HM. It'd take years to do a whole movie at good settings.

[x265_Project]

Why should the big guys (major studios that release blurays) care for other encoders besides the reference one if they have no time concerns?
Why not just use the best even if its slower?

As others have mentioned, the HM reference encoder is not just a little bit slower, it's impractically slow for anything except tests on very short video sequences (and even these tests on 10 second clips can take many hours). It's entirely single-threaded. It won't take advantage of multiple CPU cores at all.

A competitive production quality video encoder needs a number of features that the HM lacks, including advanced rate control modes. So even if you could just make the HM run fast, it wouldn't meet the requirements for most commercial, professional or consumer products.

The HM isn't always "the best". x265 is often able to exceed HM reference efficiency (using objective measurements like PSNR/bit rate). This depends on the content you are testing, but on some test sequences (Johnny, KristinAndSara) we are seeing better-than-HM quality with our higher quality presets, and even with the medium preset at certain bit rates. We continue to work on both quality and performance, and you can expect further improvement in both areas. Note that some improvements to visual quality are not reflected in objective measurements like PSNR or SSIM, but are observable in subjective testing.
Is x265 is more like a third party based on guidelines, compared to the official code of the Test Model?
All HEVC encoders should be designed to produce an output bitstream compliant with the HEVC specifications. Because only the output bitstream and the method to decode are specified, encoder developers are free to do anything they want to achieve the desired result. We used the HM reference encoder as a starting framework for development, but we had to make major architectural changes to enable a high level of parallelism. Over time, we've replaced most of the HM code.
Will hardware encoders will use the official Test Model code? No. Hardware encoders are designed differently, using hardware design tools to create a hardware layout, expressed in a representation like RTL. RTL is then reduced to a gate-level description using a synthesis tool. This is then converted to a hardware layout using "place and route" tools.

Tom
MulticoreWare

[James Freeman]

Thanks everybody.

[Procrastinating]

These are just some screenshots from my initial set of tests, but because a lot of discussion has begun on the effectiveness of 8-bit HEVC, I figured I would at least show my observations.

For the sake of comparing similar file sizes, the following were all stills from an anime sequence using both dialogue and action.

The output was 10-bit, and I used untuned, placebo settings.
The x264 video was encoded at CRF 24 while x265 at CRF 12 (because of the weird CRF difference at 10-bit).
The x265 video averaged 1337kbps while the the x264 video averaged 1279kbps, so with close to 60kbps more x265 could be expected to appear a little better in this set.
From memory the x264 video took ~30 minutes compared to x265 at ~2 hours maxing an i5 3570.

Video screenshots were taken from MPC-HC using LAV filters.

Mid-Shot:
x265 HEVC (https://i5.minus.com/ix0fg4MKDlaKK.png)
x264 AVC (https://i1.minus.com/ibb2Ueo2JQyCSL.png)

Dialogue-1:
x265 HEVC (https://i2.minus.com/itYj8sdnJcGuU.png)
x264 AVC (https://i3.minus.com/iKxahKPXVXwSQ.png)
With x265, particularly around the collar and eyes, the tones appear sharper and less grainy.

Dialogue-2:
x265 HEVC (https://i5.minus.com/iRDVmXg94oTlF.png)
x264 AVC (https://i5.minus.com/ib0r5mCYBdFhjr.png)

Action-Shot:
x265 HEVC (https://i1.minus.com/ibejKF7tYFnf0V.png)
x264 AVC (https://i2.minus.com/iMMFYWHgydS8n.png)
Particularly in high-motion(with a smooth camera at least), x265 has considerably less artefacts. Lines look much smoother and there is much less noise around the edges.

As it has already been discussed, tuning would change all of the potential results here considerably, and CRF isn't a particularly good comparison, possibly moreso at 10-bit.
But if there is anything to take away from this, I think it's clear to say that x265 was designed for 10-bit anime first and foremost.

[fumoffu]

But you are also testing x264 with advanced features that should be disabled for anime, you should add
--trellis 0 --psy-rd 0.3:0
(and if you are going to say you did this because x265 has no tune settings so far, it's not the same because x264 defaults are pretty much already tuned for feature film content, so in this case it's almost like using wrong tune settings)
That being said sources like this are definitely where x265 shines,
and not professional (meaning mainly: no depth of field, no static image, no optimal lighting), cam recored footage is its biggest week-point.

[Atak_Snajpera]

These are just some screenshots from my initial set of tests, but because a lot of discussion has begun on the effectiveness of 8-bit HEVC, I figured I would at least show my observations.

For the sake of comparing similar file sizes, the following were all stills from an anime sequence using both dialogue and action.

The output was 10-bit, and I used untuned, placebo settings.
The x264 video was encoded at CRF 24 while x265 at CRF 12 (because of the weird CRF difference at 10-bit).
The x265 video averaged 1337kbps while the the x264 video averaged 1279kbps, so with close to 60kbps more x265 could be expected to appear a little better in this set.
From memory the x264 video took ~30 minutes compared to x265 at ~2 hours maxing an i5 3570.

Video screenshots were taken from MPC-HC using LAV filters.

Mid-Shot:
x265 HEVC (https://i5.minus.com/ix0fg4MKDlaKK.png)
x264 AVC (https://i1.minus.com/ibb2Ueo2JQyCSL.png)

Dialogue-1:
x265 HEVC (https://i2.minus.com/itYj8sdnJcGuU.png)
x264 AVC (https://i3.minus.com/iKxahKPXVXwSQ.png)
With x265, particularly around the collar and eyes, the tones appear sharper and less grainy.

Dialogue-2:
x265 HEVC (https://i5.minus.com/iRDVmXg94oTlF.png)
x264 AVC (https://i5.minus.com/ib0r5mCYBdFhjr.png)

Action-Shot:
x265 HEVC (https://i1.minus.com/ibejKF7tYFnf0V.png)
x264 AVC (https://i2.minus.com/iMMFYWHgydS8n.png)
Particularly in high-motion(with a smooth camera at least), x265 has considerably less artefacts. Lines look much smoother and there is much less noise around the edges.

As it has already been discussed, tuning would change all of the potential results here considerably, and CRF isn't a particularly good comparison, possibly moreso at 10-bit.
But if there is anything to take away from this, I think it's clear to say that x265 was designed for 10-bit anime first and foremost.

x264 still wins . x265 blurs everything too much
http://i.cubeupload.com/0wvoj5.pnghttp://i.cubeupload.com/bvjLdh.png

[sneaker_ger]

While x265 blurs more I find it more pleasing than the very pronounced artifacts that x264 shows in this sample. It's similar to the sky in the sample you posted. I think sometimes blurring is better than the artifact fest that x264 produces here - probably looks even worse when watching the moving video. As long as the video isn't very detailed to begin with it seems to work better.

[Atak_Snajpera]

While x265 blurs more I find it more pleasing than the very pronounced artifacts that x264 shows in this sample. It's similar to the sky in the sample you posted. I think sometimes blurring is better than the artifact fest that x264 produces here - probably looks even worse when watching the moving video. As long as the video isn't very detailed to begin with it seems to work better.

If I was encoding anime I would use --tune anime preset ;) After all it was designed to reduce those artifacts.

[Motenai Yoda]

If you'd normally use crf 24, you'd have to use crf 12 in 10-bit or you'll get files about four times as large.
Isn't the opposite?

[Nozdrum]

Isn't the opposite?

it should be, in x264 10-bit encoding gives less artifacts and smaller file size than 8-bit at same crf, I think the same would apply to x265 10-bit vs 8-bit, by the way, is there a 10-bit x265 build already? I just noticed last week that x265 was released because MeGUI listed it in the updates list (I was surprised, that was fast!) but I think it's 8-bit, I didn't have time to encode anything this week and I don't know where to search for a 10-bit version


Mid-Shot:
x265 HEVC (https://i5.minus.com/ix0fg4MKDlaKK.png)
x264 AVC (https://i1.minus.com/ibb2Ueo2JQyCSL.png)


that x265 snapshot looks like a x264 filtered snapshot to me, the details in the floor are washed as if a deblocking or a bad trilinear/anisotropic filter was used, still the size and overall quality is acceptable for a 8-bit encoded imo, I wonder what x265 10-bit looks like, probably great

[Sapo84]

I think sometimes blurring is better than the artifact fest that x264 produces here - probably looks even worse when watching the moving video. As long as the video isn't very detailed to begin with it seems to work better.

It's not like you watch action scene frame by frame, you usually won't notice artifact on moving objects (well, in this case you might, but crf 24 is too high a setting for a decent rip quality wise).

Anyway, judging by the screenshots there is still too much blurriness and loss of details.
The texture on the first screenshot has already be pointed out, in the Dialogue-1 there is a loss of detail on the shadow of the shirt collar (right one), in the Dialogue-2 the collarbone line (on the left) has a loss of detail.
While it's a compromise (the background is a lot less blocky) I hate blurred lines and loss of details (I never use --tune anime for this very reason), that's a step back I would not love to make.

I'm sure we will see improvements in the future (x264 before fgo/psy-rd wasn't better than this), but for now there are still some drawbacks compared to x264.

[Procrastinating]

still the size and overall quality is acceptable for a 8-bit encoded imo, I wonder what x265 10-bit looks like, probably great
Except if you read the post they were both 10-bit outputs :>

@Atak_Snajpera, I'm not one for pickiness, but I definitely prefer the lesser bleeding of lines, general blockiness and noisiness to the x264 output, but again a change in presets would change the results here on both ends.

Similarly I don't think a --tune animaiton comparison is fair either because that's just adding further incomparable parameters. The ideal comparison would be to find the "most optimal" parameters for a sequence on both x264 and x265, and compare that, though as you have suggested, even that would be subjective.

You might prefer a grainer output, but I still feel that 10-bit x265 looks considerably better on defaults for anime sources.
I don't see how one could see that it is "more blurry" as the lines are sharper, due to less mosquito noise and blocking of the lines if anything, and no more blurred comparatively. I didn't even notice the black-on-black blending on my old TN monitor(whoops) so I concede that some threshold is blending low-contrast areas together on x265, but that is a particularly black-on-black case(though it needs to be considered at least).

[Nozdrum]

Except if you read the post they were both 10-bit outputs :>

I just read that in H.265 is 10-bit standard, this is not bad because 8-bit is honestly getting old, I mean, even the crappiest notebook can play smoothly 10-bit streams now, so no wonder they're using it as standard, still x265 can be improved even more, I like detailed backgrounds especially in anime, sometimes they're just like paintings and losing all those details in not very nice. Even if the artifacts creation is very lower than x264, at least from these screenshots, I think that preserving as much detail as possible, at the same bitrate, should be the priority, but I can't tell for sure unless I watch a dozen of videos, I'm very interested in what x265 can do with anime sources, I hope that we'll get a good animation tune, just like x264.

[sneaker_ger]

It's not like you watch action scene frame by frame, you usually won't notice artifact on moving objects (well, in this case you might, but crf 24 is too high a setting for a decent rip quality wise).
Yes, but the weaknesses pointed out in x265's result were on the characters which I assume are moving while x264 did bad on the (probably static) background, i.e. this supports my opinion.

it should be, in x264 10-bit encoding gives less artifacts and smaller file size than 8-bit at same crf, I think the same would apply to x265 10-bit vs 8-bit
x265 uses different crf scales for different bit depths, unlike x264 which tried to match them. Someone above theorized it would be -6 for 1 bit extra precision, i.e. you'd have to subtract 12 when going from 8 bit to 10 bit.

by the way, is there a 10-bit x265 build already?
Use the 16bpp builds from e.g. x265.cc, feed raw 10 bit data and use the "--input-depth 10" switch. Unlike x264cli x265 cannot convert 8 bit to 10 bit by itself but tools like ffmpeg or VapourSynth can assist in this.

I just read that in H.265 is 10-bit standard
We'll have to wait and see. Currently H.265 supports different bit depths just like H.264 but digital TV and Blu-Ray only support 8 bit. For the Ultra HDTV standards 10 bit and even 12 bit are being debated.

[OWA]

Speed ​​Comparison encode

Machine
Intel Core i5-3570k (6M Cache, 4x4.62GHz) ; 16332 MB DDR3; Windows Server 2012 R2

x265 - ver 05+30 - 30-Oct-2013

VC11-x86: encoded 300 frames in 26.84s (11.18 fps), 28.59 kb/s, Global PSNR: 39.079
VC11-x64: encoded 300 frames in 21.07s (14.24 fps), 28.59 kb/s, Global PSNR: 39.079

Image (http://i2.minus.com/ioOMLcr4fpcSp.png)

x265 - ver 06+173 - 13-Dec-2013

VC13-x86: encoded 300 frames in 3.73s (80.32 fps), 27.98 kb/s, Global PSNR: 39.043
VC13-x64: encoded 300 frames in 2.94s (102.04 fps), 27.98 kb/s, Global PSNR: 39.043

Image (http://i6.minus.com/iNhqVVR4UewJv.png)

[Selur]

@OWA: without posting the exact command line this does not really surprise, the defaults and presets changed a lot so unless you make sure you use the same settings this doesn't say much, especially if you are not even sharing the settings you used. *gig*

For the Ultra HDTV standards 10 bit and even 12 bit are being debated.
12bit in a consumer standard would be nice, since this would trigger a wider support for higher bit depth in general. :)

[Kurtnoise]

Look at the pictures...you'll see the command used.

[LigH]

Late - but still @ James Freeman:

The purpose of a "reference encoder" is to create technically correct bitstreams. It is not supposed to be very fast or very efficient. Just correct to the current specifications. Decoders are expected to decode any output of the reference encoder correctly (which matches the Profile@Level combinations supported by this decoder, at least).

[Selur]

Look at the pictures...you'll see the command used.
you are right, he simply used the defaults, which changed quite a bit,..

[x265_Project]

Speed ​​Comparison encode

Machine
Intel Core i5-3570k (6M Cache, 4x4.62GHz) ; 16332 MB DDR3; Windows Server 2012 R2

x265 - ver 05+30 - 30-Oct-2013

VC11-x86: encoded 300 frames in 26.84s (11.18 fps), 28.59 kb/s, Global PSNR: 39.079
VC11-x64: encoded 300 frames in 21.07s (14.24 fps), 28.59 kb/s, Global PSNR: 39.079

Image (http://i2.minus.com/ioOMLcr4fpcSp.png)

x265 - ver 06+173 - 13-Dec-2013

VC13-x86: encoded 300 frames in 3.73s (80.32 fps), 27.98 kb/s, Global PSNR: 39.043
VC13-x64: encoded 300 frames in 2.94s (102.04 fps), 27.98 kb/s, Global PSNR: 39.043

Image (http://i6.minus.com/iNhqVVR4UewJv.png)
There were many improvements between these builds, but the most significant difference in this example is the # of frames processed in parallel. In the earlier example this option was set to 1 by default, but today this value is calculated based on the # of CPU cores in your machine.

The default settings for many options were revised, and in general, x265 runs faster today at the default settings. It's nice to see this example of how performance was improved without sacrificing compression efficiency.

Thanks for sharing!

Tom

[Sm3n]

Some tests with same parameters...

My avs script looks like this:

LoadPlugin("C:\MeGUI x86\tools\dgindexnv\DGDecodeNV.dll")
DGSource("E:\xxx\BluRays\xxx\00006.dgi",fieldop=0)
crop(0, 138, 0, -138)
Spline36Resize(1280,536) # Spline36 (Neutral)
Trim(128835, 131508)


Using avs:

Commande & Encode (http://i.imgur.com/ZuHoWJD.png)

Screen (http://i.imgur.com/KvzXAT4.jpg)


Using avs2yuv:

Commande & Encode (http://i.imgur.com/LM37Vf6.png)

Screen (http://i.imgur.com/1L4oJvo.jpg)


It seems I'm doing something wrong using avs2yuv. :confused:
I never convert avs to yuv before today.

May be next time I'll use ffmpeg instead.

[sneaker_ger]

I think avs2yuv uses the y4m header before the raw data by default, i.e. you have to use the --y4m switch for x265 (or maybe rename the file to *.y4m).

[foxyshadis]

Isn't the opposite?

Sorry, yes, meant quarter the size, not quadruple.

x265 uses different crf scales for different bit depths, unlike x264 which tried to match them. Someone above theorized it would be -6 for 1 bit extra precision, i.e. you'd have to subtract 12 when going from 8 bit to 10 bit.

Well, I double-checked and I was wrong, it's currently set to the standard -(6*extra bits) to 51 scale internally, same as x264 does now. Might just be a rate-control bug. There is a small bug that the crf scale is hardcoded in the help to "(0-51)" even though the code doesn't match.

[Sm3n]

I think avs2yuv uses the y4m header before the raw data by default, i.e. you have to use the --y4m switch for x265 (or maybe rename the file to *.y4m).

Thx! I forgot the --y4m option. Works smoothie now but I think I prefer use avs4x265. (much faster?)

[LigH]

I doubt you will notice much difference, as slow as the HEVC encoding is, compared to the frameserving.