x265 HEVC Encoder

[filler56789]

Hmmm, according to this post, the patch suggested above "cannot be automated" or something.

[Kurtnoise]

yes, I saw that in the mailing list...I think that can be retrieved by reading the reg value.

btw,

Not really matters if you build the makefiles without the batch files. Simply add the "-T "v110_xp"" switch to cmake.
Anyway nice work for batch users.

this guy doesn't understand what my patch does...the switch goes to the cmake command line.

[Kurtnoise]

Originally Posted by LigH

And yes: There is not even support for streaming video sources (pipe / AviSynth) yet. GUIs could not efficiently serve frames to such an encoder.

Piping is under way now...



Edit: test build uploaded.

[filler56789]

Originally Posted by Kurtnoise

Piping is under way now...



Edit: test build uploaded.

Thanks for the experimental build, but you didn't say whether it works or doesn't work on your machine(s)

I took the time to compile the latest commit with GCC 4.8.1, including the stdin patch, and sadly the best the EXE does is encode 0 frames when fed through avs2yuv.

[Monarc]

One question about x265.

on x265.org i can read:

x265 is a commercially funded open source implementation

on x265.com:

As the x265 reaches production, flat fee and per-unit commercial licenses will be available for companies that cannot accept x265 under a GPL license.

So x265 is a normal commercial product?
And x265 will be re-licensed under a new licence, when ready?
And sold like a normal product?

[nevcairiel]

x265 is dual-licensed, like x264. Its available for free under GPL, but also available under a commercial license if your requirements are not compatible with the GPL. The text only states that the commercial license is not available until the product reaches a certain level of maturity.

[x265.cc]

Originally Posted by Kurtnoise

this guy doesn't understand what my patch does...the switch goes to the cmake command line.

Can you please tell me what i haven't understood? It would be helpful for me. Thanks

btw. i've now implemented this (the commandline way) for my buildbot.

[Kurtnoise]

Originally Posted by filler56789

Thanks for the experimental build, but you didn't say whether it works or doesn't work on your machine(s)

I took the time to compile the latest commit with GCC 4.8.1, including the stdin patch, and sadly the best the EXE does is encode 0 frames when fed through avs2yuv.

Fact is, it does not work, at least on windows plateforms...Checking the code, it seems that the issue comes from guessFrameCount() function within the pipeline (i.e the seeking returns always 0). So, encoding cannot start and fails.

[Kurtnoise]

Originally Posted by x265.cc

Can you please tell me what i haven't understood? It would be helpful for me. Thanks

btw. i've now implemented this (the commandline way) for my buildbot.

the batch file calls the patched cmake command line...what can I say moreover ?

[x265.cc]

Originally Posted by Kurtnoise

the batch file calls the patched cmake command line...what can I say moreover ?

The use of

cmake -G "Visual Studio 11" -T "v110_xp" ..\..\source

only will not work.

Also the batch file cannot be automated due to the fact that it needs "cmake-gui".

Anyway, the automation of cmake (means commandline only) is really not a big deal.

Originally Posted by Monarc

One question about x265.

on x265.org i can read:

x265 is a commercially funded open source implementation

on x265.com:

As the x265 reaches production, flat fee and per-unit commercial licenses will be available for companies that cannot accept x265 under a GPL license.

So x265 is a normal commercial product?
And x265 will be re-licensed under a new licence, when ready?
And sold like a normal product?

Commercial licenses are available now for companies that wish to distribute x265 in their products without being subject to the conditions of the GPL license. Contact me - license at x265.com.

Tom
MulticoreWare

[MoSal]

Originally Posted by Kurtnoise

Fact is, it does not work, at least on windows plateforms...Checking the code, it seems that the issue comes from guessFrameCount() function within the pipeline (i.e the seeking returns always 0). So, encoding cannot start and fails.

You can't seek in pipes. That has nothing to do with the platform.

Input should be buffered instead.
Obviously, piping is useless if you need to buffer the whole input.

[qyot27]

Concerning 16bpp, I'm wondering whether this is for the future implementation of higher bit depth output, to avoid the issues that have been noted regarding x264 and 12/14-bit support? Is it [mostly] irrelevant for current 8bpp-only encoding cases, or is there a generalized visual or coding efficiency benefit (I assume there might be) from having internal processing in 16bpp even though from what I can tell, the input and output of 16bpp builds is still restricted to only 8bpp? I'm assuming that there is some kind of performance hit from using 16bpp builds, just because of the higher complexity math and any discrepancies that might exist in the asm between the two versions.

I guess what I'm getting at here is, is the -DHIGH_BIT_DEPTH option actually worth using at this point in time? I've not seen this particular part explained.

[Kurtnoise]

Originally Posted by MoSal

You can't seek in pipes. That has nothing to do with the platform.

Input should be buffered instead.
Obviously, piping is useless if you need to buffer the whole input.

Well...I meant, guessFrameCount() uses the seekg/tellg to find the current position/size of the stream. That's all.

[DarrellS]

Finally, there are a couple of x265 builds that accept stdin "-".

http://forum.videohelp.com/attachments/208...ccac3a7d3622.7z


https://x265.cc/

Here is the working command argument for Virtualdub 1.10.3 external encoder...

--input-res %(width)x%(height) --fps %(fps) --q 24 --keyint 40 --max-merge 3 --hash 1 --no-rect --wpp --tu-intra-depth 1 --tu-inter-depth 1 --no-tskip --frame-threads 4 - -o "%(tempvideofile)"

[LigH]

A source patch for reading YUV4MPEG from stdin was published in the mailinglist. So expect a build with Y4M piping support soon™...

[Kurtnoise]

It was already there in my package from here...

New stable version tag 0.5

= New Features =
* x265 can now be built by Mac OS X clang compiler
* install/uninstall build targets (install-only for Windows)
* Our cmake scripts now build static and shared libraries
* --ref N is now supported for enabling multiple L0 references
* SSIM global statistic reporting (--ssim)
* CSV logging is now a core feature, introduced per-frame logging

= API Changes =
* "_t" suffix removed from public data types for POSIX compatibility
* public API is now versioned
* --cpuid meaning has changed from level to capability bitmap, same as x264
* param.bipredSearchRange has been removed (--bpredrange N)
* param.maxNumReferences has been added (--ref N)
* param.csvfn has been added (--csv FILENAME.csv)
* PSNR and/or SSIM reporting are optional (--[no-]psnr --[no-]ssim)
* x265_version_str exported string symbol with version (tag) info
* x265_build_info_str exported string symbol with compile info
* x265_encoder_get_stats() method for querying encoder statistics
* x265_encoder_log() method for writing to CSV log file
* x265_param_parse() method for configuring x265_param_t via strings
* x265 now requires cmake 2.8.8 or later in order to build
* Weightp options re-enabled, but feature is still unfinished
* param.rc.aqmode, param.rc.aqstrength for unfinished AQ support

= Improvements =
* x265 is deterministic at -F1 and separately deterministic for Fn>1
(ie: -F2 and -F12 will give the same outputs if all other args are same)
* We have adopted a bidir search more closely resembling x264's bidir
* Lookahead analysis now includes bidir candidates for B slice types
* Lookahead uses thread pool and wave-front block scheduling
* The "multiple of min CU size (4)" resolution requirement has been removed
* More x264 assembly is being used for motion search and bidir MC
* PSNR and SSIM are measured row-by-row after deblocking and SAO
* Use of Standard Template Library classes has been removed
* SIMD Vector Classes are no longer used for 8bpp primitives

= Upcoming improvements =
* support in CLI for reading YUV or Y4M on stdin (already in default)
* performance presets
* Main10 profile
* Weightp in lookahead, weight analysis adapted from x264
* lookahead worker thread
* Adaptive QP

[Kurtnoise]

Nice work...

btw, what is the status of high bits depth ? It looks like it's clamped to 8bits in the current code...but I'm just wondering.

[LigH]

The buildbot author reported that the compiling fails for the 16bpp branch. He may publish the logs there too...