x265 HEVC Encoder

[Procrastinating]

You make a point that they are only applying for a US trademark, and don't have trademarks in other countries. Even I would admit that no professional company would consider using .cc as a tld, and I would assume most people see .cc sites as scams anyway.

However, from what I understand, it is reasonable for a company to aggressively defend a trademark before it becomes registered, to prevent claims of genericness(even though x265 is pretty generic, and easy to confuse with x264, but that's for another fiasco).
In that sense, Hyperthreadsoft is probably just catching legal fever.

Bah. given the realms of non-genericness, I don't think anyone would have trouble with something like "x h265" given that the term "x *codec*" has become marginally synonymous with encoders(x262, xvp8).

[mandarinka]

[warning/tldr: Rant.]

Trademark or not, look at it this way - they (MCW) are doing almost all the work on the encoder currently (how can they "hate community" if one hardly exists?). The picked x265 as a name.

Even if they had no trademark at all, even if somebody else had it... there still is certain merit to it if they asked people (assuming it is asking politely ofc) to not use the name. You know, law isn't the only thing to go by - there are less tangible rules and reasons to respect/do something.

When someone doesn't want you to do something or asks you to do something, I don't think it is reasonable to a priori dismiss it just because "nothing forces me legally to do so!". Polite people listen to each other.

[sirt]

Hello, I check this thread for the first time and I have read it partially, so forgive my ignorance. I simply would like to know if an HEVC encoder is available in comand line mode and, in that case, if any software is able to play it.

[Selur]

x265, DivX265 and Kvazaar all are HEVC command line encoders which libav (-> most of the software players) can playback.

[sirt]

Well thanks Selur, I read a couple of things about x265 and got an available binary (link (https://code.google.com/p/x265/downloads/detail?name=x265-bin-201209-preview8.ZIP&can=2&q=)) but it only supports .yuv streams and not anything else nor avisynth. Or maybe I don't know how to use it ?

Something that is still unclear to me : it appears lead x264 developpers are not implied in the x265 project. Do you know why ?

[LigH]

You seem to be asking questions which have been answered several times in the previous pages of this thread...

Yes, x265 still does only support YUV or Y4M, so you have to feed AviSynth scripts via helper tools like avs2yuv if you don't want to write out intermediate files.

And yes, the x265 project was started not by the x264 developers, but mainly by the MulticoreWare Inc. team; some x264 developers may support them, but will still primarily keep developing x264.

[microchip8]

Hi,

is there an IRC room where we can follow the development? thanks

[turab]

Is there a changelog? The commit messages aren't exactly readable for those mainly interested in the features.

[filler56789]

Hi,

is there an IRC room where we can follow the development? thanks

Join us at #x265 on freenode

source: http://forum.doom9.org/showthread.php?t=168301

[LigH]

Just an updated file: 60 seconds action from "Tears of Steel" (http://www.mediafire.com/watch/a5h81wbrxaw0l4o/tos_60s_hevc.crf24.mp4) (1080p LB, 10.7 MB), encoded with x265 r0.6+282 (MSVC, 32b, 8bpp – as available in MeGUI), CRF 24 + a few GOP tweaks
__

And in addition, the same with CRF 12 (http://www.mediafire.com/watch/tuqw86aqn752ntn/tos_60s_hevc.crf12.mp4) (74.0 MB); quite utilized CPU during playback.

[sborho]

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.

The MSVC and Xcode cmake targets are the only ones that need to build the assembly files once for static and again for shared. It boiled down to a cmake bug, it could not support yasm assembly in normal project libs in IDE targets, and it's still not fixed upstream. So there are special code for the assembly files in the root cmake script to deal with this. For all the other compilers the assembly is only compiled once in the typical way.

The only workaround I've found for this is to make the shared library optional.

[mariush]

Just an updated file: 60 seconds action from "Tears of Steel" (1080p LB, 10.7 MB), encoded with x265 r0.6+282 (MSVC, 32b, 8bpp – as available in MeGUI), CRF 24 + a few GOP tweaks
And in addition, the same with CRF 12 (74.0 MB); quite utilized CPU during playback.


There's a full version of tears of steel in HEVC format here: http://labs.divx.com/node/127909

It's encoded with HM Reference encoder though, but it may be useful to compare with other encodings.

[LigH]

Well, yes, just a few HEVC samples (https://www.mediafire.com/folder/6lfp2jlygogwa/HEVC) of free material for some testing.

[fumoffu]

Can someone maybe post here a recent build (x64 preferably)? and maybe do that lets say every week? ;)
Or is that violating some rules?

[LigH]

It would be great if the buildbot could be resurrected, just under another personal name and domain. So I hope that "the user formerly known as x265.cc" is not too "miffed" anymore. :) :)

I uploaded a build v0.7+95 (GCC 4.8.2, Win32, 8bpp) on my MediaFire account (see above) and try to discover how to "simply" make a build for the AMD64 architecture (and possibly even 16bpp); guides are welcome, I have hardly any experience with C and GNU tools (setting up an MSYS environment was easy enough thanks to a brief guide in the VideoHelp forum).

[fumoffu]

Thx LigH, it works (although I noticed the size is almost 2 times the "usual")
There are recent builds on x265.ru but they don't work for me - first it wants 2 dll files, I downloaded them and put them in folder but now it just crashed (i tested the x64 version)

[LigH]

If they are from a Microsoft Visual C++ Runtime (MSVC*.DLL):

Do not load DLLs from any suspicious website. Download the Visual C++ Runtime installer in the required version from Microsoft and install it. Furthermore, a crash may mean that you mixed 32 and 64 bit of DLLs and programs; another reason not to simply download DLLs, the installer would put them where they belong, in the matching Windows system folder (Windows 64-bit has two of them, and they have to be distinct).

[Brazil2]

I uploaded a build v0.7+95 (GCC 4.8.2, Win32, 8bpp)
Thanks a lot for that!
And please, keep making GCC builds :)

[fumoffu]

I think I have all the runtimes, just reinstalled 2010 and 2012, x64 and x86. Still wants msvcr120.dll and msvcp120.dll :(
I downloading the missing files from www.dll-files.com so not just some random Russian site and I'm usually careful with stuff like that.
Previous build from x265.cc and yours works ok.
Since I have VS2012 installed I just downloaded the source and will see if I can figure out how to compile it. (I never wrote anything major so I have no experience with all the build tools).

[LigH]

MSVC v12.0 is VS 2013 (http://www.microsoft.com/de-de/download/details.aspx?id=40784).

I can't promise to keep building regularly. But someone pointed me to a russian machine doll (http://machine-doll.ru/vc12/)...

[nevcairiel]

I think I have all the runtimes, just reinstalled 2010 and 2012, x64 and x86. Still wants msvcr120.dll and msvcp120.dll :(

msvcr120.dll is VS2013. The version number does not correspond to the year, which can get quite confusing. 2012 is VS11, and 2013 is VS12. Only for 2010 it worked. ;)

[fumoffu]

MSVC v12.0 is VS 2013 (http://www.microsoft.com/de-de/download/details.aspx?id=40784).
msvcr120.dll is VS2013. The version number does not correspond to the year, which can get quite confusing. 2012 is VS11, and 2013 is VS12. Only for 2010 it worked. ;)

Yea, I just figured it out while attempting to get cmake to work and I realized Visual Studio 12 is NOT Visual Studio 2012... Why make things simple for people? ;)
Anyway by some miracle I actually figured it all out and manged to compile both x86 and x64 version with VS2012
If anyone need latest build:
http://www.multiupload.nl/L06K09QEG7
(those are not XP compatible)

edit:
I can't promise to keep building regularly. But someone pointed me to a russian machine doll (http://machine-doll.ru/vc12/)...
Oh never mind then, all my efforts for nothing ;)

[mindwin]

x265 builds.
http://x265.ru/en/

I do not think that Tom would protest against Russia. :)

[x265.cc]

x265 builds.
http://x265.ru/en/

I do not think that Tom would protest against Russia. :)

He will protest against anything that cotains "x265".

But it's fully legal, since they do not own the trademark.


It would be great if the buildbot could be resurrected, just under another personal name and domain. So I hope that "the user formerly known as x265.cc" is not too "miffed" anymore. :) :)

I currently don't see any reason for an buildbot. Since the x265 marketing manager seems to be not intrested that "not developing users" use there encoder.

I've prefered my builbot due to different reasons (TLS1.2, zip compression, newest compiling tools, md5/sha1 hashing, etc..), but there are some others..


http://builds.x265.eu/ (old GCC, no compression, bad tls implemention, no file hashs)
http://x265.ru/en/ (VC12 only, shared, very bad tls implemention, no file hashs, no automation?)

Oh, and yeah, they don't state that they are not x265 team related.

Great success Mr. Vaughan. :D


P.S. Yes, im "miffed". But not this much. Otherwise i would do some SEO instead of closing the buildbot.

[LigH]

Please don't get any more personal... you both have your points of view, and the current situation leaves only victims.

[filler56789]

...........

http://builds.x265.eu/

.............

which says,

x265 Builds for Windows Cross Compiled with mWingw :) by Yukikaze/snowfag :D

[Daemon404]

http://chromashift.org/x265_builds/

Here.

Currently it is doing ICL64 and MSVC2012 builds (8bpp and 16bpp) nightly.

Server is in Europe, and I have no intention of ceasing builds.

Enjoy!

[LigH]

And I was able to modify (http://forum.videohelp.com/threads/357754-%5BHEVC%5D-x265-EXE-mingw-builds?p=2301183&viewfull=1#post2301183) portions of the MinGW building guide (http://forum.videohelp.com/threads/357754-%5BHEVC%5D-x265-EXE-mingw-builds?p=2259093&viewfull=1#post2259093) for an easy variant to make a 64-bit 8bpp EXE, if you want to try it on your own.

[Kurtnoise]

http://chromashift.org/x265_builds/
Currently it is doing ICL64 and MSVC2012 builds (8bpp and 16bpp) nightly.

Running a test with your builds, I've got an "x265 is not a valid win32 application". How did you compile them ?



Tested on a Windows 7 Entreprise x64.

[LigH]

x265-0.7.103-icl14.0-64.7z

is an x86-64 (AMD64) build:

x265 [info]: build info [Windows][ICC 1400][64 bit] 8bpp

It appears to run in Windows 7 SP1 Ultimate 64-bit.

[Daemon404]

Running a test with your builds, I've got an "x265 is not a valid win32 application". How did you compile them ?

I've built and ran them on 64-bit Windows 8.1.

I definitely don't care about 32-bit OSes... if you're running a 32-bit OS and want to encode HEVC, you're doing it wrong... get in this decade!

[Kurtnoise]

I don't care either...tests were done on a Windows 7 Entreprise x64, like I said earlier.

[Daemon404]

I don't care either...tests were done on a Windows 7 Entreprise x64, like I said earlier.

I certainly can't reproduce it locally, nor can LigH on the same OS, apparently, so there's not a lot I can do.

Can anyone else?

[LigH]

It may depend on the environment the EXE is called in. Do you run it directly in a cmd.exe shell or from another program?

[Kurtnoise]

Well, I found my issue : the downloaded packages were corrupt and my 7-zip version was too old. :D


Thanks for the buildbot...:)

[LigH]

Your discovery might help in the VideoHelp forum too, there is someone complaining that no other x265 build works with STDIN, although every build since v0.4.1 should. He also reported this error "not a valid Win32 application". Maybe he had an outdated unpacker too... :D

[x265.cc]

Since i don't longer need it, if any buildbot admin is intrested in the "x265.cc" domain (+ssl cert) write me a PM, i will set an A record (or transfer it to you) for free. ;)

[Daemon404]

Since i don't longer need it, if any buildbot admin is intrested in the "x265.cc" domain (+ssl cert) write me a PM, i will set an A record (or transfer it to you) for free. ;)

I purposely did not use a domain name with 'x265' in it, so Tom could not harass me.

[x265_Project]

I've posted an updated Evaluator's Guide

x265 Evaluators Guide Feb 12 2014.pdf (https://bitbucket.org/multicoreware/x265/downloads/x265%20Evaluators%20Guide%20Feb%2012%202014.pdf)

[x265_Project]

I've been thinking about how we can open source the development of our documentation. I'd like for anyone who is interested and capable to be able to make improvements directly, and we can review, edit and post them.

Our Evaluator's Guide was written for early adopters: expert users, and developers who are testing HEVC encoders. We need better guides for pulling and compiling x265, for our developers API, and for users. I can post PDFs, but who edits PDFs? I could share a Word doc, but most people would rather download a PDF than a .DOCX. What do you think? Should we do a Wiki, like MeWiki? Any suggestions for a good web framework for online documentation?

Thanks,
Tom

[Daemon404]

Our Evaluator's Guide was written for early adopters: expert users, and developers who are testing HEVC encoders. We need better guides for pulling and compiling x265, for our developers API, and for users. I can post PDFs, but who edits PDFs? I could share a Word doc, but most people would rather download a PDF than a .DOCX. What do you think? Should we do a Wiki, like MeWiki? Any suggestions for a good web framework for online documentation?

For the API, I found the comments in x265.h pretty adequate, aside from some edge cases.

Does the guide provide anything that x265 --help doesn't?

[filler56789]

I can post PDFs, but who edits PDFs? I could share a Word doc, but most people would rather download a PDF than a .DOCX. What do you think?

Choose a simple HTML file, problem solved :sly:

[Daemon404]

Choose a simple HTML file, problem solved :sly:

Most people would probably prefer some sort of markup like rst or markdown, I'd imagine, rather than manual HTML.

[x265_Project]

<thinking out loud>
I need to solve the problem of allowing, receiving, reviewing and posting edits to documentation. Look at the way the source code is distributed, tracked, revised and reviewed. Anyone can create edits and publish them, but only reviewed and approved edits are committed to the main code branch. There are a number of tools and skills you need to work with this system (Mercurial or Git, an editor or IDE, CMAKE+YASM+Compiler, email), but it's a system that flows nicely once everyone is up and running, and the source code management system tracks all the edits. Would it make sense to put the docs in the \doc folder of the source code? In this case we might think about a separate x265-DOCS mailing list (or a separate email subject tag, like [DOCS] for changes to documentation, so that we don't clutter up the development mailing list. The next question is the file format. HTML is nice in that it is universally easy to edit, has hyperlinks and that it can be posted online. I'm looking at Bitbucket's documentation, and they seem to have a way to push changes to an external web server - https://confluence.atlassian.com/display/BITBUCKET/POST+hook+management (which would allow us to host the latest/greatest documentation on x265.org). What do you think?

[qyot27]

Most people would probably prefer some sort of markup like rst or markdown, I'd imagine, rather than manual HTML.
Seconded.



The syntax for something like RST is far simpler than HTML, it's very clean-looking and readable, and can be used to generate the right documentation in multiple formats (via rst2man, rst2pdf, Sphinx for HTML docs...not sure about Bitbucket, but Github can parse and display RST - or Markdown - directly from the source tree). And it's something that lends itself more easily to version control in general. Look at the docs included with mpv or VapourSynth for more elaborate examples.

[x265_Project]

Seconded.
The syntax for something like RST is far simpler than HTML, it's very clean-looking and readable, and can be used to generate the right documentation in multiple formats (via rst2man, rst2pdf, Sphinx for HTML docs...not sure about Bitbucket, but Github can parse and display RST - or Markdown - directly from the source tree). And it's something that lends itself more easily to version control in general. Look at the docs included with mpv or VapourSynth for more elaborate examples.

Thanks. I'll take a look at your suggestions.

Tom

[x265_Project]

We want to let you know that support for 4:4:4 input frames (full sized chroma planes with no sub-sampling) is now checked in to the default branch.

At this time, you are required to use --no-weightp and --cpuid 1 when using the 4:4:4 color space (to avoid output mistakes, and decoder hash mismatches) because there are problems with a few assembly routines and with weightp when used with 4:4:4 content. We hope to have both of those issues resolved very soon.

To test this feature you either need 4:4:4 Y4M content, or use 4:4:4 YUV content and add --input-csp 3 to your command line.

If you try this new feature and encounter problems, please let us know. Thanks.

PS: Support for 4:2:2 color space is under development.

[LigH]

Just uploaded some updates encoded with x265 v0.7+ and x264 core:142:

a) tos_60s_hevc.crf24.mp4 (http://www.mediafire.com/watch/t2e1rw50ekywuww/tos_60s_hevc.crf24.mp4) – encoded with x265 --crf 24 returning a HEVC stream with ~1520 kbps; to match the size: tos_60s_avc.1520.mp4 (http://www.mediafire.com/watch/zahu2vi7k0z4kiz/tos_60s_avc.1520.mp4) – encoded with x264 --bitrate 1520 (2-pass)
b) tos_60s_hevc.crf18.mp4 (http://www.mediafire.com/watch/dydk08xub1w4kr3/tos_60s_hevc.crf18.mp4) – encoded with x265 --crf 18 returning a HEVC stream with ~3560 kbps; to match the size: tos_60s_avc.3560.mp4 (http://www.mediafire.com/watch/87c9102smwvk58m/tos_60s_avc.3560.mp4) – encoded with x264 --bitrate 3560 (2-pass)

The quality differences are interesting...

[Procrastinating]

While comparing CRF with bitrate isn't entirely fair, This resonates well with the testing I have done.

x265 seems to be much better at accurately and consistently defining edges, particularly in high-motion sequences. However at this stage it still loses some of the texture which is present in the x264 footage.

In other words, x265 is still being designed with anime in mind. This is a good thing.

Would you mind sharing more details, like your encoding setup, and encoding times? It seems best at this stage that we compare all aspects of the encoding pipeline to make verbose comparisons.

[LigH]

While comparing CRF with bitrate isn't entirely fair...

This is not 1-pass CBR, but 2-pass VBR, and that works in a not too different way:

The 1st pass gathers statistics required to calculate the CRF which is required to reach the desired bitrate for the 2nd pass. So after all, the 2nd pass is a CRF encoding as well.

Several people with much experience and insight explained why it is necessary to try to get to similar filesizes in result to make meaningful comparisons, so I tried to achieve just that.

Furthermore, we are comparing x265 (HEVC) vs. x264 (AVC), so differences in the bitrate distribution are pretty expectable; encoding efficiency will be different for different scenes.

The algorithms in x265 are by far not yet final. Especially psychovisual enhancements are not yet elaborate. Still, the only conclusion I would agree to for now is, that the high efficiency of HEVC (*g*) was made obvious; and there is still headroom for improving implementations...
__

P.S.: According to the 1st pass statistics of x264, for this clip and the chosen parameters, trying to reach the same output size (not a similar visual quality):
x265 --crf 24 ~ x264 --crf 31.68
x265 --crf 18 ~ x264 --crf 25.17
x265 --crf 12 ~ x264 --crf 18.36
Not to be generalized!