x265 HEVC Encoder

[vivan]

What i simply meant was that the aim for x265 is to reduce bandwidth more, hence why low bitrate efficiency is gold.Downscaling.

if it can look like 2mbps at 500bitrate... while looking like 360p at 4K resoultion ;)

[zerowalker]

I actually prefer lowering bitrate and high resolution then downscaling it to fit the bitrate better, though i guess it goes to a certain degree though.

[LigH]

The main reason for the broadcasting related companies to develop even more efficient codecs is reducing the bitrate of Ultra-HD video content to a range DVB-S2 can handle without monopolizing a bouquet.

Private people may have different reasons to take advantage of this efficiency... Even though some encoding techniques in H.265 may be especially suitable for high resolution video, doesn't mean they are completely useless for usual resolutions.

Nevertheless, it isn't magic, it is a lossy reduction of redundancy. But redundancy can only be reduced with little loss if there is enough similarity. At its limits, the loss can be more or less obvious and annoying. Modern video codecs are fighting between two fronts: Finding "abbreviatable" similarities better (which is mainly the time consuming part of the encoding), and leaving less annoying loss than the previous technologies (which often means a more or less clever™ filtering).

[Dark Eiri]

I'd like the industry to view H264 as a chance to keep the bitrate and "double" the quality, but it seems most people view is at a "same quality, half bitrate" situation.

[Atak_Snajpera]

Forget about double quality. Broadcasters will always do everything to cut costs. In polish dvb-t 1080i channels already use very low bitrate ( 5Mbps ). sd channels use 2.5 Mbps. If they could use hevc they would for sure reduce bitrate two times.

[EncodedMango]

How exactly does it reduce costs, can someone elaborate please?

[kolak]

Half bitrate=2 channels in the same bandwidth. Simple. 2x more annoying adverts, so more money.

[zerowalker]

Does decoding work for you guys with x265 with the current builds?
It's messed up for me, black/white and stuff like that, not sure if the decoder is bad or the encoder.

[LigH]

More details please to check it: x265 version+patch number, used decoder?

x265 [info]: HEVC encoder version 0.9+126-4f7658b3c78a
x265 [info]: build info [Windows][GCC 4.8.2][64 bit] 8bpp

Result plays well in MPC-HC 1.7.4 (internal LAV 0.61.2.0).

[zerowalker]

Not sure about build number, but i got it from automated builds of x265, x64 bit, and it was released 25th April, i tried some older as well, and they didn't work, i used the latest LAV Filter as decoder with Zoom Player, also tried MPC-HC and it's internal, unsure which version though.

[Romario]

One question to MAIN x265 developer, mister "x265 project". When we can expect x265 1.0 revision and what we can expect ?

Right now, I have some tests, but I am little disapointed with x265 quality and lack of features. I hope that x265 1.0 will be much better, in terms of speed and quality.

[EncodedMango]

One question to MAIN x265 developer, mister "x265 project". When we can expect x265 1.0 revision and what we can expect ?

Right now, I have some tests, but I am little disapointed with x265 quality and lack of features. I hope that x265 1.0 will be much better, in terms of speed and quality.
It was mentioned a few pages back that 1.0 release will be a regular release like they have been so far, it won't be something 'special' like usually 1.0 means.

[LigH]

@ zerowalker:

Facts. Facts. Facts.

We may be able to check if you accidently got bugged versions if we know the version numbers. Check them with "x265 -V". It is possible that there are x265 versions with such a kind of bugs that the bitstream contains wrong data, but I rather doubt that this was happening lately. But you did not even provide screenshots of this effect yet. Well possible that someone recognizes it as "oh well, your display of deep-color video is wrong, that may have happened with 10bit-per-component x264 as well"?!

Help us to help you.

[zerowalker]

Okay got the latest version from this site: http://x265.ru/soft/x265/GCCBuild/x265_0.9+128_x64_8bpp.zip
Or rather here is the link to the current latest that i used now.

And then i encoded with default settings (encoded a Yuy file and manually told it the resolution 1920x1080, other than it was as is).

Here is the encoder version:

x265 [info]: HEVC encoder version 0.9+128-a25fb61a73263b61
x265 [info]: build info [Windows][GCC 4.8.2][64 bit] 8bpp
x265 [info]: Compiling by snayper [x265.ru]
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2

And here is a screenshot, as you can see it's B/W but there is color, but it goes from left to right the more it plays, you can also see that the image also moves to the left, it like 2 images are side by side and going to the right.
Hopefully you get what i mean, look at the left side, you will see that the image cuts of and starts over.

http://i59.tinypic.com/301hqp1.png

[LigH]

OK, so it looks like the chrominance is drifting away in content with very little saturation. That's certainly a bug to be investigated. I'll notify the developers via the mailing list about it.

Please try to upload small material to check whether the bug is in the bitstream or in the decoder or your graphic driver (on-display issue). MediaFire offers a few GB of space for free.

But well, it's in the screenshot too, so I believe the third option can be excluded.
__

P.S.:

And then i encoded with default settings (encoded a Yuy file and manually told it the resolution 1920x1080, other than it was as is).

What does that mean?

If you recorded the YUV file with e.g. 1920x1200 pixels, you must tell x265 that the YUV file has this resolution. You can't use a wrong resolution to tell x265 to crop or resize the image to e.g. 1920x1080 pixels.

A wrong resolution in --input-res will make x265 read out the YUV file incorrectly. Chrominance shifts would be the smalles issue, most of the content would also "scroll through" like a cinematic film sliding out of the projector.

[benwaggoner]

Forget about double quality. Broadcasters will always do everything to cut costs. In polish dvb-t 1080i channels already use very low bitrate ( 5Mbps ). sd channels use 2.5 Mbps. If they could use hevc they would for sure reduce bitrate two times.
Broadcast perhaps, but download and over-the-top services aren't stuck with the painful fixed channel limitations, and can and do use improved encoding technologies to improve quality as well.

[zerowalker]

What does that mean?

If you recorded the YUV file with e.g. 1920x1200 pixels, you must tell x265 that the YUV file has this resolution. You can't use a wrong resolution to tell x265 to crop or resize the image to e.g. 1920x1080 pixels.

A wrong resolution in --input-res will make x265 read out the YUV file incorrectly. Chrominance shifts would be the smalles issue, most of the content would also "scroll through" like a cinematic film sliding out of the projector.

I am telling it the correct input resolution, and fps as well, just said it to know if that matters, but it seems it doesn't.

http://www.sendspace.com/file/rpyf5f

Here is an encoded file, not the precise screenshot file, i used -crf 16 to make it easier to look at, other than that it's the same.

[Atak_Snajpera]

you should use .y4m format and get rid of that --input-res switch

[zerowalker]

How can i get that format, is it possible to get it via ffmpeg on current Yuv files?

Also, Important, i tried another Yuv file which was 640x480, and that decodes correctly, color and all that (of course i changed the res to 640x480 as well).

So it may be the video itself, however VP9 doesn't complain on it, so a bit confused, will try to changed format to see if that matters.


EDIT:


Okay changing the file name to ".y4m" seems to solve the problem, just ignored the --fps --input-res and all went well.
Not sure why i could just rename it though, shouldn't there be some difference between the formats?

But however, the issue wasn't in x265 i guess, but just some misunderstanding when handling the file.

[Atak_Snajpera]

because your .yuv file was in fact .y4m with correct resolution and fps information. True .yuv file does not contain above information.

[zerowalker]

Ah, that explains it.
New to those formats, if i remember correctly i simply turned it into a Raw Video (ffmpeg) and thought it was Yuv as people mentioned it when doing tests with vp9,x265 etc.

[benwaggoner]

because your .yuv file was in fact .y4m with correct resolution and fps information. True .yuv file does not contain above information.
Relatedly, did anyone figure out a way to use Y4M with 10-bit video successfully with x265? I've got it working with YUV, but as demonstrated, keeping all those parameters straight is a pain.

[qyot27]

Relatedly, did anyone figure out a way to use Y4M with 10-bit video successfully with x265? I've got it working with YUV, but as demonstrated, keeping all those parameters straight is a pain.
No, not unless they've finally synched with FFmpeg's extended Y4M format. I've finally decided to open an issue about this on Bitbucket, so let's see what the response ends up being. (https://bitbucket.org/multicoreware/x265/issue/53/support-for-ffmpegs-extended-y4m-format)

So basically, only using FFmpeg itself with -vcodec libx265 will work for 10-bit Y4M (although for that matter, you wouldn't need it in Y4M if you were just giving to it FFmpeg anyway).

[Romario]

1.0 is out ???

Please give us COMPLETE changelog, dear x265_project.

[LoRd_MuldeR]

1.0 is out ???

Please give us COMPLETE changelog, dear x265_project.

Just look at the public repository:
https://bitbucket.org/multicoreware/x265/commits/tag/1.0

[x265_Project]

No, not unless they've finally synched with FFmpeg's extended Y4M format. I've finally decided to open an issue about this on Bitbucket, so let's see what the response ends up being. (https://bitbucket.org/multicoreware/x265/issue/53/support-for-ffmpegs-extended-y4m-format)

So basically, only using FFmpeg itself with -vcodec libx265 will work for 10-bit Y4M (although for that matter, you wouldn't need it in Y4M if you were just giving to it FFmpeg anyway).
While there are higher priorities right now, we'll take a look at this, and if it's not difficult we'll add support.

[x265_Project]

1.0 is out ???

Please give us COMPLETE changelog, dear x265_project.
x265 1.0 is a regularly scheduled feature release

The only significance to the "1.0" tag is that this is our tenth tagged release.

There were many bugs fixed since the 0.9 tag, particularly in rate control and Main10 mode decision. There have been a couple of minor performance improvements.

= Feature changes =

* Experimental support for 4:2:2
* improved profile and level detection
* imported checkasm-a.asm from x264 and fixed the asm bugs it exposed
* lookahead will use a worker thread when beneficial
* Many more motion candidate vectors are passed to motion estimation
* Lambda table improvements for better bitrate response at low QP

= API changes =

* added param.bEnableAccessUnitDelimiters
* removed param.vui.bEnableVuiParametersPresentFlag (now implied)
* removed param.vui.bEnableAspectRatioIdc (now implied)
* removed param.vui.bEnableVuiTimingInfoPresentFlag (always enabled)

= CLI changes =

--aud was added
--vui was removed
--timinginfo was removed (it is always enabled)

Our online documentation is steadily improving. We hope to add more and more content over the coming weeks. http://x265.readthedocs.org/

Development is still focused on finding and fixing coding bugs, improving visual quality, improving rate control, and improving performance.

[upyzl]

Does Evaluate Guide (need) update, please?

[x265_Project]

Does Evaluate Guide (need) update, please?
The Evaluator's Guide has been replaced with online documentation... http://x265.readthedocs.org/

[upyzl]

oh, that's it...

hope for detailed such "preset params" as Evaluate Guide's :P

[zerowalker]

As i have asked for screenshots and stuff, i have now done some myself, just to show how the situation is.

Nothing special really, used x264 and x265, both at different CRF settings so they reached about the same bitrate, x265 had sliughtly less even, but both were about 550 bitrate.

The video itself is 1600x1200, but it had black borders top/bottom which i removed in the screenshots (not on the actual encoding), but shoudn't matter any as the bitrate was probably not used on the black anyway as it was pure digital, the source is from a Game (Zelda Ocarina of Time).

http://i60.tinypic.com/29dxwdc.png
http://i58.tinypic.com/hwzczm.png

Note: Pictures at Webp are set 100% - Lossless not checked (But looks pretty transparent except even with the YV12 color conversion).
Here is a link to all pictures in webp: http://www.sendspace.com/filegroup/b0C%2FnJbPqz2WcHIulA14%2Fe6sng5pAXfAXCIdhIJNMPwcwdgOn56PinT7uOC2Mp1bvgpYK2NabkuYI%2BKy5SMWdE5gPzwhEfXKjFuLNJcuHSEmuuhskYS6%2BQ
Note: Png is 100% lossless.
Update: Link to all Pictures in png format: http://www.sendspace.com/filegroup/25CtZe2TrYpFHyf9xPOZ94FNvuODfWDQwPfFTZGmC1XT7%2BbNnkQ7jBbDz21LZS%2Fu7CMBXmNG%2Bb4%2BiAHn%2FCcBFkx%2Fx11UIXMFZjclgyxCzYIynvQMiLdjdA

Edit: Seems to be problem showing the images as the upload site doesn't support Image to forumes as it requires download access all the time, if anyone knows a good site which support any file format, or at least Webp please tell.
Edit2: Will upload it with png for the forum as well as a batch, as i know webp isn't that used.

[Atak_Snajpera]

Can you redo test with preset anime (x264) ? BTW N64 games due to ultra low amount of vram are always very blury. Try with recent games maybe ;) Crysis 3 ?

[zerowalker]

Why Anime, it's 3D in all it's glory?

Can't really agree there, except if you mean the textures, cause yes they are blurry.
However the 3D itself it as is, clear and crispy.

Why i used it was simple because it was simple, using games with high details made things harder to see, except extremely low bitrates.
Here where everything was simple it was easier to see when x264 was unable to grasp the "models" and started altering the environment, while x265 managed to maintain it more or less.

[Atak_Snajpera]

Because anime preset is tuned for flat low detail areas. N64 games look like anime. Lack of details and full of hard edges.

[x265_Project]

oh, that's it...

hope for detailed such "preset params" as Evaluate Guide's :P

Yes, we need to add this to the online docs. I'll ask my team to add a chart like the one we had in the Evaluator's Guide to the ReStructuredText documentation.

It's a little harder to read and interpret (as everything is expressed in terms of x265 variables and not the command-line options), but the performance presets are set by the code in this C++ file... https://bitbucket.org/multicoreware/x265/src/dcf74ea39e3157ff1e66331db56f03edd5f9b810/source/common/param.cpp.

Tom

[Sagittaire]

Because anime preset is tuned for flat low detail areas. N64 games look like anime. Lack of details and full of hard edges.

Well here it's useless. H264 can't really not fight with H265 with specific anime content. Even bad H265 implementation will always better than x264 with this particular source simply because H265 have really good functionality to compress that. For real stuff with high level noise ... it's another problem ... ;-)

[zerowalker]

So, x265 is currently ahead of x264 when it comes to flat, low detail etc?
While it lacks the ability to currently compete with high detail sources (at least on more fair bitrates)?

If so, is that the lack of tuning done, or is it the specifications that limit this somehow?

[BadFrame]

So, x265 is currently ahead of x264 when it comes to flat, low detail etc?

Likely the next generation formats (HEVC, VP9) are much better at lower bitrates, as it was when I used your test video (3d game as well but more detailed) to compare VP9 to x264, where VP9 beat x264 quite readily, in particular on the lower bitrates: http://forum.doom9.org/showthread.php?p=1636137#post1636137

While it lacks the ability to currently compete with high detail sources (at least on more fair bitrates)?

I guess that for most of us here, we are more interested in the quality achieved at 'higher' bitrates, and here x265 seems to have some catching up to do, however one has to take into account that x264 has had many years of experimentation and fine-tuning to reach the great quality it now achieves, by comparison x265 and VP9 are 'puppies'.

Also it's important to underline that the 'same quality for 50% bitrate' type statements are in reality only for best case scenarios, where the source video allows making the best use of HEVC's compression features.

[zerowalker]

Oh, that game clip, remember that, was quite a while i go, i still have it and use it, i thinks it's good as it's a lot of details as you say, and also it has bright and dark areas.
If anyone would like the raw clip, i will gladly share it.

I am very suprised that it beats x264 at 2k bitrate though, was pretty sure when i did some testing some days ago that x264 is better at 1k+, guess i must remember it wrong.


Yeah that's the thing, x264 has been around for, like 10 years, or something similar i guess?
And if i am not mistaken, the common h264 encoders that exists (non x264), aren't something spectacular either, the changes from when it came to this day should be pretty extreme, and hopefully x265 will go through that as well.
Would also like VP9 to join the league a bit more, currently it seems that VP9 is a bit worse in quality in my tests, but the difference in performance is out of this world, VP9 is so slow that you can barely test it, x265 however is not That slow.

Looking forward to when x265 can beat x264 at "good enough" bitrates, like 5-10k for HD 1080p, cause that would clearly open some doors when it comes to bandwidth, and of course local storage of certain media.

[x265_Project]

Relatedly, did anyone figure out a way to use Y4M with 10-bit video successfully with x265? I've got it working with YUV, but as demonstrated, keeping all those parameters straight is a pain.
Ben,
Steve took a look at this, determined that it was relatively simple to add support, and just committed a patch to support 10 bit Y4M. Let us know if you encounter any issues.

Tom

[zerowalker]

Does x265 support 10bit?
Or is this only for input, so that x265 itself will handle the dithering?

[LigH]

There are high-bit-depth builds (supporting up to 16 bit per component as input).

I'll upload (http://www.mediafire.com/?6lfp2jlygogwa) version 1.0+9-075705aa41a9 (GCC 4.8.2) in a moment...

Important information from the patch header:

y4m: support variable bit depth via CXXXpDD Y4MPEG header; ie: C420p10

ffmpeg's support for this is non-standard, so you must use -strict -1, aka:

ffmpeg -i vid.avi -pix_fmt yuv420p10le -strict -1 -f yuv4mpegpipe - | ./x265 - --y4m o.hevc

[Kurtnoise]

Or is this only for input, so that x265 itself will handle the dithering?
you have the --dither switch for that (http://x265.readthedocs.org/en/default/cli.html#cmdoption--dither)...

[x265_Project]

Does x265 support 10bit?
Or is this only for input, so that x265 itself will handle the dithering?
x265 has supported 10 bit / sample input for many months, with the appropriate (high bit depth = 16 bit/sample) build. This patch added support for 10 bit content in Y4M files.

[Atak_Snajpera]

I'm unable to encode this script with x265.

ImageSource("C:\Users\Dave\Desktop\Image compression test\1793814.png",1,1,1).ConvertToYV12(matrix="rec709")

Command line

"C:\Users\Dave\Documents\Delphi_Projects\RipBot264\_Compiled\tools\avs2yuv\avs2yuv.exe" "C:\Temp\RipBot264temp\job1\job1.avs" -o - | "C:\Users\Dave\Documents\Delphi_Projects\RipBot264\_Compiled\tools\x265\x265_x64.exe" --bitrate 128 --fps 1 --frames 1 --sar 1:1 --preset veryslow --y4m --output "C:\Temp\RipBot264temp\video.265" -


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

Above script works fine with x264. My goal was to compare intra coding efficiency vs x264 10 bit --veryslow --stillimage at low bitrate.

[zerowalker]

I am sorry i just don't get what you mean.
Are you saying that it Only supports input, and will Always dither it down to 8 bit (One mentioned a --dither switch which makes me skeptical to that though)?

Or are you saying you can input up to 16 bit, and output it at 10bit, or perhaps up to 16 bit as well (Lossless "Bit tranformation")?

Cause if so, i need to redo some tests as 10bit clearly has some extreme advantages when it comes to dark gradient areas compared to 8bit.

[LigH]

@ zerowalker:

If you use the 8-bit build, it will at most use 8 bits per component; and if you add the --dither option, let it dither down to 8 bit (otherwise it will simply round).

If you use the 16-bit build, it may use up to 10 or 12 bit (not sure how much is currently already implemented).
__

@ Atak_Snajpera:

Maybe you would prefer avs4x265 instead. It reads most clip attributes from the script and generates the full x265 command line internally. Shorter command line to type for you.

[kolak]

you have the --dither switch for that (http://x265.readthedocs.org/en/default/cli.html#cmdoption--dither)...

Any more precise info about method and quality of the dither option?

[LoRd_MuldeR]

Any more precise info about method and quality of the dither option?

https://bitbucket.org/multicoreware/x265/commits/106fc00d4eabc81720e665a105cd59576105a8f7#chg-source/filters/filters.cpp

[LigH]

source/filters/filters.cpp:27
/* The dithering algorithm is based on Sierra-2-4A error diffusion. */

a.k.a. "Filter Lite" (http://www.algorytm.org/przetwarzanie-obrazow/algorytm-sierra-2-4a-filter-lite.html) — very simple and fast-computing; discussed before (http://forum.doom9.org/showthread.php?t=166368).