x265 HEVC Encoder [Archive]

x265_Project

25th September 2013, 07:22

More details on the state of x265 from our lead developer (Steve Borho)...

I've made a tag on the stable branch for 0.4.1. This email describes the state of the encoder at that tag.

x265 can be compiled and run on Linux, Mac OS X, and Windows. Its cmake based build system supports MSVC 9-11, Xcode, gcc+gmake, MinGW/MSYS, and Intel C++ (both icl and icpc)

x265 currently generates HM11 compliant bitstreams.

= New features since 0.3 =

1. Frame parallelism

* The GOP level parallelism and mini-gop cadence of the 0.3 release were removed and replaced with fine-grained frame level parallelism.
* The memory requirements were drastically reduced, x265 no longer caches subpel planes per reference frame
* Latency is drastically reduced, WPP + 5 frame threads is enough to saturate a dual socket 8 core Xeon.

2. New simple average bitrate (ABR) rate control

* converges on target bitrate via frame level QP adjustments
* algorithm was adapted from x264 for HEVC
* safe for use in combination with frame parallelsim (new since 0.4)

3. New Lookahead

* three complexity levels of slice decision with scene cut and flash detection
* algorithm was adapted from x264 for HEVC
* still missing bidir cost estimates, multiple refs, weightp, and MBtree

= Disabled Features since 0.3 =

* weightp and weighted bidir prediction are both disabled; they were broken when we stopped pre-generating reference (subpel) pixels
* GOP parallelism is dead, hopefully to never return to the core library. It could be added above x265 if necessary.
* many CLI options were added, removed, or renamed since 0.3. Consult the online help for the current set of options.

= Known Bugs =

* all intra encodes (--keyint 1) require --b-adapt 0 to avoid a lookahead bug
* --no-sao-lcu-bounds cannot be used in conjunction with frame parallelism. The encoder will use incomplete reference pixels with predictable bad effects.
* we have a report that our DPB signalling is potentially incorrect for decoders which respect max DPB size. This is under investigation.

ABR and lookahead are very new and we will not be surprised to find bugs in those features. Please report any bugs you find to this mailing list.

= Performance Characteristics =

See https://bitbucket.org/multicoreware/x265/wiki/Performance

= Upcoming features =

We are trying to make the encoder deterministic with -Fn for all values of n greater than 1. In other words, there will always be a slight benefit to having only one frame thread (unlimited motion search to reference frames) but -F2 and -F10 should output the exact same bitstream with CQP rate control. This is considered a debugging feature to validate our frame parallelism.

We are also planning to swap out the HM's bidir search with logic adapted from x264 (for performance reasons) and to add estimation logic for this new bidir search to the lookahead (to improve lookahead accuracy).

We plan to repair the weighted prediction features and re-enable its command line options.

Lastly, the lookahead will use wave-front scheduling of the lowres CUs using the existing thread pool. This should lesson the bottlenecking effects of --b-adapt 2.

smok3

25th September 2013, 07:58

Why not use a name that stands out a bit, like y265 ?
(Just a suggestion)

lainiwaku

26th September 2013, 04:46

is it hard to use command line version ? i always used MeGui for x264 :helpful:

iwod

26th September 2013, 05:10

Something less related. Is DS working on x265 yet?

x265_Project

26th September 2013, 06:51

is it hard to use command line version ? i always used MeGui for x264 :helpful:
I suppose it depends on your level of experience with command-line interfaces. If you've used a CLI before, you should find x265 fairly easy to use. CLIs have some advantages, including the ability to write batch files (scripts).

Keep in mind that x265 is really a core video encoding library, designed to be integrated into other software applications. Video editing and transcoding applications add more powerful capabilities like opening different types of media files, demultiplexing the content, decoding the source video into uncompressed frames, scaling video, frame rate conversion, transcoding audio, and packaging up the result in a file like .mp4 or .mkv.

Tom

x265_Project

26th September 2013, 06:54

Something less related. Is DS working on x265 yet?
I'll let DS speak for himself... but I would point you to the x265 development mailing list to see all of the activity from all of the different contributors. The project is ramping up nicely, and we're psyched to see so many talented people writing and reviewing code, submitting bugs and responding to open questions.

Tom

Daemon404

27th September 2013, 13:37

For anyone interested, I did a quick SSIM-based comparison of the 1-pass ABR modes in x264 and x265 (take it with a grain of salt). Source is Elephant's Dream, from here (http://media.xiph.org/video/derf/).

Pretty graph here (http://chromashift.org/img/x265/comparison_abr_27sep2013.png).

LigH

27th September 2013, 21:09

Doesn't tell me much more than "they are not completely different". But I feel that is a good conclusion. :)

zerowalker

1st October 2013, 07:52

Could someone put some Screen Comparisons of x265 and x264?

LigH

1st October 2013, 08:59

That won't make much sense without specific testing parameters. Even though x265 is nowhere near "feature complete", it is already able to encode in visually transparent quality with a certain bitrate or quality level. And it will, of course, have compression artefacts with a lack of.

In such an early testing stage, there are not even comparable default values. You will certainly not be able to make up "similar-quality options" for both encoders. The default quantization level in x265 (=32) is very coarse, limits the pixel-bitrate to values where compression artefacts are not only obvious but even annoying.

For a sensible comparison, one would have to find a quantization for x265 which gives a good result with still recognizable artefacts, and run x264 in 2-pass mode with the resulting bitrate as target; x265 does not even have a 2-pass mode, and 1-pass ABR is not optimal.

zerowalker

1st October 2013, 09:08

Ah, well if there isn´t a comparable setting, then it is indeed meaningless.

Kurtnoise

1st October 2013, 09:56

That won't make much sense without specific testing parameters.
Looking at the graph, you will see the parameters used : x264 -placebo + no-psy vs x265 defaults

professor_desty_nova

1st October 2013, 10:21

Maybe in a few weeks/months, when x265 has Weight P and Weight B working and more stuff borrowed from x264 (look at their TODO list (https://bitbucket.org/multicoreware/x265/wiki/TODO)), it will be more "fair" to compare...

mandarinka

1st October 2013, 19:03

I don't think those are specifically the problem. It's probably the rate control that is most important.

LigH

2nd October 2013, 08:28

@ Kurtnoise:

I thought zerowalker asked for any comparison screenshots, not specifically from the test above. That's why I continued thinking about its general sense in the current stage of development...

Apart from other working features, there is also some need for useful default values. From my experience so far, a default quantizer of 32 in x265 is not really a sensible value.

BadFrame

2nd October 2013, 08:50

Really love how development has picked up on the x265 project, I'm getting some good 'x264 vibes' :D

Is there a tool to decode the x265 generated raw hevc stream to another format at the moment?

LigH

2nd October 2013, 09:17

The Osmo4 player in the GPAC Nightly Builds (Win32) can play it (muxed as MP4 with e.g. MP4Box in this package, or a current L-SMASH).

The HM reference decoder (ver. 12.0 currently?) can decode it to Y4M. JEEB's build (http://x264.fushizen.eu/builds/hevc-hm/hm_12.0_r3541_release.7z) (TAppDecoder.exe).

BadFrame

2nd October 2013, 09:27

Thanks LigH!

Kurtnoise

2nd October 2013, 22:22

Wanna play with avisynth & libx265 on windows platforms ?

I've made a fresh compile of avconv (http://www.mediafire.com/?z3dzrgag1y70ywi) from libav (http://git.khirnov.net/cgit.cgi/libav/log/?h=hevc_upstream) + patches (http://lists.libav.org/pipermail/libav-devel/2013-October/051599.html) from Daemon404...:cool:

Not all options from x265 cli are available yet but it's a good start.

Kurtnoise

3rd October 2013, 07:37

Maybe...when hevc support in matroska (i.e in Mosu's mkvtoolnix, not Rovi) will be officially supported.

nakTT

14th October 2013, 08:47

is it hard to use command line version ? i always used MeGui for x264 :helpful:
Same here. I hope some GUI like MeGUI etc could integrate this encoder. I would love to do testing with this new encoder.

Selur

14th October 2013, 13:24

gui support in MeGui and other tools will probably not come unless input via std::in is supported.
Most GUIs won't support tools which require huge temporary files as input.

LigH

14th October 2013, 13:53

Apart from that, x265 is not yet available for users, only for testers with sound background knowledge in video coding algorithms, and working with CLI encoders (at least by editing a batch file) is the least issue in the current stage of development.

There is no complete feature implementation yet.
There is no stabe set of command line options yet.
How often do you expect a GUI to follow sudden and unexpected changes in the set of encoder options?

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

nekrosoft13

14th October 2013, 17:32

anyone could share a sample file encoded in x265?

JEEB

14th October 2013, 17:48

anyone could share a sample file encoded in x265?
Daemon404's test encodes are available in the directory (http://chromashift.org/img/x265/).

filler56789

14th October 2013, 18:15

anyone could share a sample file encoded in x265?

This thread @ Videohelp has various sample videos:

http://forum.videohelp.com/threads/357754-%5BHEVC%5D-x265-EXE-mingw-builds

LigH

15th October 2013, 08:30

Here are also a few of mine (http://www.mediafire.com/?6lfp2jlygogwa).

Also there are some new builds, compiled with MSys/MinGW GCC for x86 or with MSVC11 for x86 and AMD64 (latter may have a minimum requirement of Windows 7 and the MSVC 2012 Redistributable (http://www.microsoft.com/en-us/download/details.aspx?id=30679); a CPU with AVX support and 8 GB RAM are reommended): https://x265.cc/

Kurtnoise

15th October 2013, 10:48

Also there are some new builds, compiled with MSys/MinGW GCC for x86 or with MSVC11 for x86 and AMD64 (latter may have a minimum requirement of Windows 7 and the MSVC 2012 Redistributable (http://www.microsoft.com/en-us/download/details.aspx?id=30679); a CPU with AVX support and 8 GB RAM are reommended): https://x265.cc/
who has created this buildbot ? It's from official devs ?

For MSVC builds, it's quite easy to support XP platforms and remove the c++ runtime.

I'll create a patch if needed.

LigH

15th October 2013, 10:56

The user registered with the nick "x265.cc" in the VideoHelp forum (http://forum.videohelp.com/threads/357754-%5BHEVC%5D-x265-EXE-mingw-builds?p=2273873&viewfull=1#post2273873); I don't know if he is related to the development team.

x265_Project

16th October 2013, 00:10

Kurtnoise

16th October 2013, 05:48

Here is the patch:

# HG changeset patch
# User Kurtnoise <kurtnoise@free.fr>
# Date 1381898006 -7200
# Wed Oct 16 06:33:26 2013 +0200
# Node ID 723e554191e14e6289342043225e485e656c27d7
# Parent a998daed845922b3b880b48c0cafa32c422c941e
Add Windows XP support in MSVC11 builds. This requires CMake 2.8.11 or later.

diff -r a998daed8459 -r 723e554191e1 build/vc11-x86/make-solutions.bat
--- a/build/vc11-x86/make-solutions.bat Tue Oct 15 20:57:47 2013 -0500
+++ b/build/vc11-x86/make-solutions.bat Wed Oct 16 06:33:26 2013 +0200
@@ -3,4 +3,4 @@
:: run this batch file to create a Visual Studion solution file for this project.
:: See the cmake documentation for other generator targets
::
-cmake -G "Visual Studio 11" ..\..\source && cmake-gui ..\..\source
+cmake -G "Visual Studio 11" -T "v110_xp" ..\..\source && cmake-gui ..\..\source
diff -r a998daed8459 -r 723e554191e1 build/vc11-x86_64/make-solutions.bat
--- a/build/vc11-x86_64/make-solutions.bat Tue Oct 15 20:57:47 2013 -0500
+++ b/build/vc11-x86_64/make-solutions.bat Wed Oct 16 06:33:26 2013 +0200
@@ -3,4 +3,4 @@
:: run this batch file to create a Visual Studion solution file for this project.
:: See the cmake documentation for other generator targets
::
-cmake -G "Visual Studio 11 Win64" ..\..\source && cmake-gui ..\..\source
+cmake -G "Visual Studio 11 Win64" -T "v110_xp" ..\..\source && cmake-gui ..\..\source
diff -r a998daed8459 -r 723e554191e1 source/CMakeLists.txt
--- a/source/CMakeLists.txt Tue Oct 15 20:57:47 2013 -0500
+++ b/source/CMakeLists.txt Wed Oct 16 06:33:26 2013 +0200
@@ -7,7 +7,7 @@
endif()

project (x265)
-cmake_minimum_required (VERSION 2.8.8) # OBJECT libraries require 2.8.8
+cmake_minimum_required (VERSION 2.8.11) # OBJECT libraries require 2.8.11

# X265_BUILD must be incremented each time the public API is changed
set(X265_BUILD 1)

XP platforms require v110_xp as toolset instead of v110. Otherwise, applications don't run correctly on this platform.

This patch requires CMake 2.8.11 because the flag dedicated to the toolset has been fixed in this version.

filler56789

17th October 2013, 00:45

Hmmm, according to this post (http://forum.videohelp.com/threads/357754-%5BHEVC%5D-x265-EXE-mingw-builds?p=2274423&viewfull=1#post2274423), the patch suggested above "cannot be automated" or something.
:confused:

Kurtnoise

17th October 2013, 08:04

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

25th October 2013, 08:15

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 (https://mailman.videolan.org/pipermail/x265-devel/2013-October/001766.html) now... :)

Edit: test build (http://www.mediafire.com/?r6v6rewf66ecl9d) uploaded.

filler56789

25th October 2013, 12:01

Piping is under way (https://mailman.videolan.org/pipermail/x265-devel/2013-October/001766.html) now... :)

Edit: test build (http://www.mediafire.com/?r6v6rewf66ecl9d) 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 :mad: when fed through avs2yuv.

Monarc

25th October 2013, 12:36

nevcairiel

25th October 2013, 12:46

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

25th October 2013, 13:16

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

25th October 2013, 16:08

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 :mad: 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

25th October 2013, 16:11

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

25th October 2013, 16:32

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.

x265_Project

25th October 2013, 16:37

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

25th October 2013, 18:06

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

26th October 2013, 03:02

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

26th October 2013, 05:38

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

27th October 2013, 20:48

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

28th October 2013, 09:18

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

Kurtnoise

28th October 2013, 09:20

It was already there in my package from here (http://forum.doom9.org/showthread.php?t=169607)...;)

x265_Project

29th October 2013, 20:32

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

30th October 2013, 10:50

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

30th October 2013, 10:51

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

nevcairiel

30th October 2013, 10:59

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. ;)

Main10 profile is listed in the "Upcoming improvements" section... :)

Kurtnoise

30th October 2013, 11:07

Ups, yeah, I missed that...thanks.

BadFrame

31st October 2013, 13:49

x265 reaches 0.5 milestone

New stable version tag 0.5:

That's some very impressive progress, seems x265 is on a the same excellent path as x264 before it, great work!

professor_desty_nova

2nd November 2013, 15:42

It seems that with the new --preset switch, the default values are not the ones shown in --h (help) anymore.

Before the presets, they are the same:
G:\x265_0.5+72-e842b2a4aeeb>x265 --frames 1 G:\x264\TestClipsYUV\ducks_take_off_420_720p50.y4m -o test.hevc
y4m [info]: 1280x720 50Hz, frames 0 - 0 of 500
x265 [info]: using cpu capabilities: MMX2 SSE SSE2Fast LZCNT
x265 [info]: performance primitives: intrinsic assembly
x265 [info]: Main profile, Level-4 (Main tier)
x265 [info]: WPP streams / pool / frames : 12 / 4 / 1
x265 [info]: CU size : 64
x265 [info]: Max RQT depth inter / intra : 3 / 3
x265 [info]: ME / range / subpel / merge : star / 60 / 5 / 5
x265 [info]: Keyframe min / max : 250 / 250
x265 [info]: Rate Control : CQP-32
x265 [info]: Lookahead / bframes / badapt : 10 / 3 / 1
x265 [info]: tools: rect amp rd=2 ref=1 lft sao-lcu sign-hide tskip(fast+rdo)
x265 [info]: frame I:1 kb/s: 36872.80 PSNR Mean: Y:36.404 U:36.833 V:39.259

x265 [info]: global: kb/s: 36872.80 PSNR Mean: Y:36.404 U:36.833 V:39.259

encoded 1 frames in 4.71s (0.21 fps), 36872.80 kb/s, Global PSNR: 36.814

After presets commit, not anymore:

G:\x265_0.5+90-f81af999ef6c>x265 --frames 1 G:\x264\TestClipsYUV\ducks_take_off_420_720p50.y4m -o test.hevc
y4m [info]: 1280x720 50Hz, frames 0 - 0 of 500
x265 [info]: using cpu capabilities: MMX2 SSE SSE2Fast LZCNT
x265 [info]: performance primitives: intrinsic assembly
x265 [info]: Main profile, Level-4 (Main tier)
x265 [info]: WPP streams / pool / frames : 12 / 4 / 1
x265 [info]: CU size : 64
x265 [info]: Max RQT depth inter / intra : 1 / 1
x265 [info]: ME / range / subpel / merge : star / 60 / 5 / 3
x265 [info]: Keyframe min / max : 250 / 250
x265 [info]: Rate Control : CQP-32
x265 [info]: Lookahead / bframes / badapt : 10 / 3 / 1
x265 [info]: tools: rect amp rd=0 ref=1 lft sao-lcu sign-hide
x265 [info]: frame I:1 kb/s: 38479.60 PSNR Mean: Y:36.366 U:36.744 V:39.278

x265 [info]: global: kb/s: 38479.60 PSNR Mean: Y:36.366 U:36.744 V:39.278

encoded 1 frames in 2.53s (0.40 fps), 38479.60 kb/s, Global PSNR: 36.778

PS: It seems to me that "--preset medium" is used by default, and overrides the (older?) default values that appear in --h (help).

Selur

2nd November 2013, 18:10

anyone manged to compile x265 on Mac OS X?
Tried it myself, but I'm really not good with using a mac. :)

I checked out the source using SourceTree, opened a terminal, called the x265/build/linux/make-Makefiles.bash (there I set x86_64 as architecture, called configure and generate), then I called make and got:
1%] Building CXX object encoder/CMakeFiles/encoder.dir/__/Lib/TLibEncoder/NALwrite.cpp
/Users/selur/x265/source/Lib/TLibEncoder/NALwrite.cpp:1: error: -mstackrealign not supported in the 64bit mode
make[2]: *** [encoder/CMakeFiles/encoder.dir/__/Lib/TLibEncoder/NALwrite.cpp] Error 1
make[1]: *** [encoder/CMakeFiles/encoder.dir/all] Error 2
make: *** [all] Error 2
so I removed -mstackrealign from x265\source\CMakeLists.txt and ran make-Makefiles.bash again (configure and generate), now calling make I ended up with:
[ 1%] Building CXX object common/CMakeFiles/common.dir/__/Lib/TLibCommon/TComBitStream.cpp.o
[ 2%] Building CXX object common/CMakeFiles/common.dir/__/Lib/TLibCommon/TComDataCU.cpp.o
[ 4%] Building CXX object common/CMakeFiles/common.dir/__/Lib/TLibCommon/TComLoopFilter.cpp.o
[ 5%] Building CXX object common/CMakeFiles/common.dir/__/Lib/TLibCommon/TComMotionInfo.cpp.o
[ 7%] Building CXX object common/CMakeFiles/common.dir/__/Lib/TLibCommon/TComPattern.cpp.o
[ 8%] Building CXX object common/CMakeFiles/common.dir/__/Lib/TLibCommon/TComPic.cpp.o
[ 10%] Building CXX object common/CMakeFiles/common.dir/__/Lib/TLibCommon/TComPicSym.cpp.o
[ 11%] Building CXX object common/CMakeFiles/common.dir/__/Lib/TLibCommon/TComPicYuv.cpp.o
[ 12%] Building CXX object common/CMakeFiles/common.dir/__/Lib/TLibCommon/TComPicYuvMD5.cpp.o
[ 14%] Building CXX object common/CMakeFiles/common.dir/__/Lib/TLibCommon/TComPrediction.cpp.o
[ 15%] Building CXX object common/CMakeFiles/common.dir/__/Lib/TLibCommon/TComRom.cpp.o
[ 17%] Building CXX object common/CMakeFiles/common.dir/__/Lib/TLibCommon/TComSampleAdaptiveOffset.cpp.o
[ 18%] Building CXX object common/CMakeFiles/common.dir/__/Lib/TLibCommon/TComSlice.cpp.o
[ 20%] Building CXX object common/CMakeFiles/common.dir/__/Lib/TLibCommon/TComTrQuant.cpp.o
[ 21%] Building CXX object common/CMakeFiles/common.dir/__/Lib/TLibCommon/TComWeightPrediction.cpp.o
[ 22%] Building CXX object common/CMakeFiles/common.dir/__/Lib/TLibCommon/TComYuv.cpp.o
[ 24%] Building CXX object common/CMakeFiles/common.dir/x86/asm-primitives.cpp.o
[ 25%] Building ASM_YASM object common/CMakeFiles/common.dir/x86/pixel-a.asm.o
[ 27%] Building ASM_YASM object common/CMakeFiles/common.dir/x86/const-a.asm.o
[ 28%] Building ASM_YASM object common/CMakeFiles/common.dir/x86/cpu-a.asm.o
[ 30%] Building ASM_YASM object common/CMakeFiles/common.dir/x86/sad-a.asm.o
[ 31%] Building ASM_YASM object common/CMakeFiles/common.dir/x86/mc-a.asm.o
[ 32%] Building ASM_YASM object common/CMakeFiles/common.dir/x86/mc-a2.asm.o
[ 34%] Building ASM_YASM object common/CMakeFiles/common.dir/x86/ipfilter8.asm.o
[ 35%] Building ASM_YASM object common/CMakeFiles/common.dir/x86/pixel-util.asm.o
[ 37%] Building CXX object common/CMakeFiles/common.dir/vec/vec-primitives.cpp.o
/Users/selur/x265/source/common/vec/vec-primitives.cpp:121: warning: unused parameter ‘p’
/Users/selur/x265/source/common/vec/vec-primitives.cpp:121: warning: unused parameter ‘cpuMask’
[ 38%] Building CXX object common/CMakeFiles/common.dir/primitives.cpp.o
[ 40%] Building CXX object common/CMakeFiles/common.dir/pixel.cpp.o
[ 41%] Building CXX object common/CMakeFiles/common.dir/dct.cpp.o
[ 42%] Building CXX object common/CMakeFiles/common.dir/ipfilter.cpp.o
[ 44%] Building CXX object common/CMakeFiles/common.dir/intrapred.cpp.o
[ 45%] Building CXX object common/CMakeFiles/common.dir/cpu.cpp.o
cc1plus: error: unrecognized command line option "-Wno-narrowing"
make[2]: *** [common/CMakeFiles/common.dir/cpu.cpp.o] Error 1
make[1]: *** [common/CMakeFiles/common.dir/all] Error 2
make: *** [all] Error 2

Cu Selur

MoSal

2nd November 2013, 19:41

cc1plus: error: unrecognized command line option "-Wno-narrowing"

Are you building with clang?
Maybe "-Wnarrowing" is GCC-specific.

x265_Project

2nd November 2013, 22:18

It seems that with the new --preset switch, the default values are not the ones shown in --h (help) anymore.
...
PS: It seems to me that "--preset medium" is used by default, and overrides the (older?) default values that appear in --h (help).

Yes, we have started to implement x264 style presets. As part of this work the values for the "medium" performance preset have become the new default values. I apologize that our documentation efforts haven't kept pace with our development efforts. We'll get a new Evaluator's Guide posted ASAP.

The presets are as follows (default values are used wherever a setting is not specified).

ultrafast=-s 32 --b-adapt 0 -b 4 --tu-inter-depth=1 --tu-intra-depth=1 --rd 0 --subme=0 --max-merge=1 --me=0 --no-amp --no-rect --no-tskip --early-skip --fast-cbf --no-lft --no-sao --no-signhide --no-weightp
superfast=-s 32 --b-adapt 0 -b 4 --tu-inter-depth=1 --tu-intra-depth=1 --rd 0 --subme=1 --max-merge=1 --me=1 --no-amp --no-rect --no-tskip --early-skip --fast-cbf --no-signhide --no-weightp
veryfast=--b-adapt 0 -b 4 --tu-inter-depth=1 --tu-intra-depth=1 --rd 0 --subme=1 --me=1 --max-merge=2 --no-amp --no-rect --no-tskip --early-skip --fast-cbf
faster=--b-adapt 0 -b 4 --tu-inter-depth=1 --tu-intra-depth=1 --rd 0 --subme=1 --me=1 --max-merge=2 --no-amp --no-rect --no-tskip --early-skip
fast=--tu-inter-depth=1 --tu-intra-depth=1 --rd 0 --subme=1 --me=1 --max-merge=2 --no-amp --no-rect --no-tskip
medium=--tu-inter-depth=1 --tu-intra-depth=1 --rd 2 --max-merge=3 --no-amp --no-rect --no-tskip
slow=--b-adapt 2 -b 4 --tu-inter-depth=1 --tu-intra-depth=1 --rd 2 --max-merge=3 --no-tskip
slower=--b-adapt 2 --rc-lookahead 20 -b 5 --tu-inter-depth=2 --tu-intra-depth=2 --rd 2 --max-merge=4 --no-tskip --ref 3
veryslow=--b-adapt 2 --rc-lookahead 30 -b 9 --max-merge=5 --ref 5
placebo=--b-adapt 2 -b 16 --max-merge=5 --ref 16 --merange 124 --rc-lookahead 60

These are a fairly quick first take at the right settings to use for these presets. We're not satisfied that these are optimal at this point. For example, placebo mode should produce HM reference quality compression efficiency under any circumstance, and in our early tests it doesn't yet. As you select slower presets we want to see a clear improvement in compression efficiency (quality@ any bit rate), and as you select faster presets we want to see the minimum possible tradeoff in compression efficiency for the maximum improvement in encoding speed.

Keep in mind that for faster performance you will need to set the number of frames to be encoded in parallel (-F), and that you should also use --no-progress.

As this is an open source project, we welcome your testing of these presets and your suggestions for improvement. I'll monitor this thread for your feedback. We have our own tests underway also.

Tom
MulticoreWare

qyot27

2nd November 2013, 23:36

sneaker_ger

3rd November 2013, 00:03

What does "16bpp" mean? I thought even 12 Bit encoding is still nothing but a draft?

qyot27

3rd November 2013, 00:23

What does "16bpp" mean? I thought even 12 Bit encoding is still nothing but a draft?
16 bits per pixel (or maybe plane).

The internal precision of the encoder doesn't necessarily have anything to do with the output depth. No one answered my previous question on the relevance of the 16bpp build (http://forum.doom9.org/showthread.php?p=1650040#post1650040) so anything I'd say is pure conjecture.

Selur

3rd November 2013, 05:39

@qyot27: did a clean checkout and 'cmake .' ends with:
Building CXX object encoder/CMakeFiles/encoder.dir/__/Lib/TLibEncoder/NALwrite.cpp
/Users/selur/x265/source/Lib/TLibEncoder/NALwrite.cpp:1: error: -mstackrealign not supported in the 64bit mode
make[2]: *** [encoder/CMakeFiles/encoder.dir/__/Lib/TLibEncoder/NALwrite.cpp] Error 1
make[1]: *** [encoder/CMakeFiles/encoder.dir/all] Error 2
make: *** [all] Error 2
(got a clean Snow Leopard install with Xcode 4 installed)

Are you building with clang?
Maybe "-Wnarrowing" is GCC-specific.
I guess, only installed Xcode 4 and it's command line tools,..

poisondeathray

3rd November 2013, 05:41

16 bits per pixel (or maybe plane).

I don't know what terminology conventions HEVC uses, but traditionally BPP is different than BPC

BPC is bits per channel . e.g. 8bits R, 8bits B, 8bits G for "8bit RGB" , or 8bit Y, 8bit U, 8bit V for "8bit YUV". It's usually expressed as per channel as in each channel . 8bit values would allow for 2^8 or (0 to 255) = 256 values per channel . It's also referred to as "bit depth"

BPP is bits per pixel . It's usually expressed as the sum of the bits in all the channels . However, because of chroma subsampling , the amount of bits is reduced

YV12 4:2:0 is "12bpp" because U , V ,are reduced in dimension 1/2 for width and height . e.g. 1920x1080 is only 960x540 in each U, V plane or 1/4 of the bits. So 8 + 2 + 2 = 12

YUY2 4:2:2 is "16bpp" because U, V planes are 1/2 of the bits, or 8+4+4 = 16

qyot27

3rd November 2013, 14:22

qyot27

3rd November 2013, 16:00

@qyot27: did a clean checkout and 'cmake .' ends with:

(got a clean Snow Leopard install with Xcode 4 installed)

I guess, only installed Xcode 4 and it's command line tools,..
It would appear that the -mstackalign issue is a common problem for 64-bit Snow Leopard. At the very least, Homebrew requires Lion for the x265 formula:
https://github.com/mxcl/homebrew/commit/fe806e9adb03f7f3fe87b8b6153e864f19bfa1d8

And they make mention of the -mstackalign issue in the formula.

It *might* be possible to get around it for Snow Leopard if you build your compilation toolchain from scratch and make sure it's updated enough, but that's only a guess (and beyond what the average user is willing to do).

x265_Project

3rd November 2013, 20:56

I don't know what terminology conventions HEVC uses, but traditionally BPP is different than BPC

BPC is bits per channel . e.g. 8bits R, 8bits B, 8bits G for "8bit RGB" , or 8bit Y, 8bit U, 8bit V for "8bit YUV". It's usually expressed as per channel as in each channel . 8bit values would allow for 2^8 or (0 to 255) = 256 values per channel . It's also referred to as "bit depth"

BPP is bits per pixel . It's usually expressed as the sum of the bits in all the channels . However, because of chroma subsampling , the amount of bits is reduced

YV12 4:2:0 is "12bpp" because U , V ,are reduced in dimension 1/2 for width and height . e.g. 1920x1080 is only 960x540 in each U, V plane or 1/4 of the bits. So 8 + 2 + 2 = 12

YUY2 4:2:2 is "16bpp" because U, V planes are 1/2 of the bits, or 8+4+4 = 16
In video coding, bits per pixel is generally understood to mean the # of bits per sample (per pixel per color), not the sum of all bits in all channels for each pixel. For example, note how Imagination uses a row labeled "bit/pixel" in their chart when defining their HEVC decoding capability - http://withimagination.imgtec.com/index.php/powervr-video/the-emergence-of-hevc-and-10-bit-colour-formats. It is not as technically accurate as bits/color or bits/sample, but it is fairly prevalent, even among video professionals. It's understood by the context that we're not talking about 8, 10 or 12 bits for the whole RGB or YUV pixel.

Obviously, you can't use 8 bit internal precision when working with decoded video that was encoded with 10 or 12 bits per sample. So, the encoder must switch over to using 16 bit values internally (even though the least 6 or 4 significant bits will be zero). For obvious reasons, this will impact performance.

x265 can be built to use 8 bit internal precision, or (with the HIGH_BIT_DEPTH build option) 16 bit internal precision. The HIGH_BIT_DEPTH version of x265 has not been an area of focus in the initial months of the project, but are fully committed to supporting high bit depths, and we are starting to devote more time and attention to this now.

Tom
MulticoreWare

mandarinka

3rd November 2013, 21:32

I don't know any details, but it seems that some sort of CRF rate-control has landed in x265 code tree: https://bitbucket.org/multicoreware/x265/commits/c51c35880df53def63953e95d81ad90b56ea67b9

poisondeathray

3rd November 2013, 23:19

In video coding, bits per pixel is generally understood to mean the # of bits per sample (per pixel per color), not the sum of all bits in all channels for each pixel. For example, note how Imagination uses a row labeled "bit/pixel" in their chart when defining their HEVC decoding capability - http://withimagination.imgtec.com/index.php/powervr-video/the-emergence-of-hevc-and-10-bit-colour-formats. It is not as technically accurate as bits/color or bits/sample, but it is fairly prevalent, even among video professionals. It's understood by the context that we're not talking about 8, 10 or 12 bits for the whole RGB or YUV pixel.

Obviously, you can't use 8 bit internal precision when working with decoded video that was encoded with 10 or 12 bits per sample. So, the encoder must switch over to using 16 bit values internally (even though the least 6 or 4 significant bits will be zero). For obvious reasons, this will impact performance.

x265 can be built to use 8 bit internal precision, or (with the HIGH_BIT_DEPTH build option) 16 bit internal precision. The HIGH_BIT_DEPTH version of x265 has not been an area of focus in the initial months of the project, but are fully committed to supporting high bit depths, and we are starting to devote more time and attention to this now.

Tom
MulticoreWare

Thanks, It's good that you clarify that

There is some confusion, it almost feels like a "switcharoo" , sort of like how "PAR" or pixel aspect ratio was used in MPEG2 terminology but "SAR" or sample aspect ratio is used in MPEG4-AVC terminology

I'm not sure of the historical orgins, but I think the the term "bpp" was derived from old computer graphics displays . For example, Microsoft uses the old terminology for video rendering.

http://msdn.microsoft.com/en-us/library/windows/desktop/dd206750%28v=vs.85%29.aspx#YUV420formats12bitsperpixel

James Freeman

4th November 2013, 08:10

Can someone please compile this video with HEVC while retaining maximum bitrate.

"Ducks take off" 1080p 108Mbps MKV.
https://docs.google.com/file/d/0B-Xd3P6pWQI9NllMa2tGRUIwb0E/edit?usp=sharing&pli=1

LigH

4th November 2013, 09:22

Compile? Encode, probably.

Recoding from a quite lossy source may not make much sense. A best possible source is always preferable. The file name (including "CRF25") suggests a rather low quality.

And furthermore, the rate control of x265 is probably not yet implemented up to the ability of ensuring a specific maximum bitrate, this would certainly require a VBV or similar implementation.

BTW, you ask for a maximum of 108 Mbps, this looks like a double 802.11g WLAN rate?

Brazil2

4th November 2013, 10:53

Can someone please compile this video with HEVC while retaining maximum bitrate.
"Ducks take off" 1080p 108Mbps MKV.
https://docs.google.com/file/d/0B-Xd3P6pWQI9NllMa2tGRUIwb0E/edit?usp=sharing&pli=1
Check this one :
http://forum.doom9.org/showthread.php?p=1651083#post1651083

James Freeman

4th November 2013, 11:00

Compile? Encode, probably.
Yes, Encode.

BTW, you ask for a maximum of 108 Mbps, this looks like a double 802.11g WLAN rate?

It's the Bitrate of the original video.
Nothing to do with 802.11g.

The goal here is to test how much CPU it takes to decode a High Bitrate 1080p HEVC video, that is all.
108Mbps is higher than a typical Blu Ray with 30Mbps.
If you have anything higher than 108Mbps it will be of help.

I feel Hollywood will be more concentrated on higher bitrate with 1080p resolution, than UHD with lower bitrate.

For example:
The new 100GB discs with 1080p, but with HEVC, Higher Bitrate, Wider Gamut (Rec.2020), 4:2:2/4:4:4 Chroma, and HFR (maybe).
The quality will be comparable to Digital Cinema (2K) finally.

Lets call it Blu Ray 2 shall we. :eek: :cool:

Check this one :
http://forum.doom9.org/showthread.php?p=1651083#post1651083

Yeah, I already tested this one.

I got 21fps with: 3770K (4.5Ghz), GTX660 (nothing to do with it).

I specifically ask for the 1080p one for the reason I pointed above.

LigH

4th November 2013, 11:26

Well, I try to understand your point, but again ... it doesn't make much sense to try to reach the bitrate of an already lossy compressed "original" with another lossy compression algorithm. The encoder will mainly try to re-encode the quantization artefacts of the former copy, so you may spend a lot of time, but the result won't tell you much more than the time wasted.

I prefer to use (almost) lossless sources for testing, like Sintel (http://media.xiph.org/sintel/) (a Blender render movie which is available in different image dimensions – e.g. 1080p or 4K – and even high color resolution, 16 bpc = 48 bpp) as original, so I can even get a meaningful quality measure; just their downloads can take several days, due to the size of several Gigabytes.

For shorter tests, there is also the Sintel trailer in 1080p@24fps (Y4M (http://media.xiph.org/video/derf/y4m/sintel_trailer_2k_1080p24.y4m), 3.7 GB / PNG.tgz (http://media.xiph.org/sintel/sintel_trailer-1080-png.tar.gz), 900 MB).

sneaker_ger

4th November 2013, 12:25

He just wants to measure the decoding performance, artifacts and source quality don't matter for that.

mandarinka

4th November 2013, 18:52

Yes, but the resulting file might still not be representative. There could for example be more skips blocks and as a result, the decoding load would be lower than with a video coded from a lossless source.

pieter3d

5th November 2013, 01:38

Note that Main10 profile allows chroma and luma to have separate bits per pixel values, between 8..10 inclusive. So you can have either or both luma/chroma using bitdepths of 9.

nevcairiel

5th November 2013, 06:55

Note that Main10 profile allows chroma and luma to have separate bits per pixel values, between 8..10 inclusive. So you can have either or both luma/chroma using bitdepths of 9.

While this feature also existed in H.264, it was not really used by anything and not supported by most of the decoders. I would wager that this will remain the same situation with HEVC.

pieter3d

5th November 2013, 07:54

I disagree. While probably it won't be used often, it is part of Main 10 profile, so anyone wishing to build a compliant decoder must support it. I can promise you that all Main10 HW decoders will support it, as part of conformance. Encoders however, probably not unless there is a good special application.

nevcairiel

5th November 2013, 09:29

The same thing applies to H.264, yet many decoders didn't handle it, even if they otherwise handled 10-bit decoding - it was just never implemented, because it was never used.

James Freeman

5th November 2013, 15:23

Can anyone point me to a link with a 1080p HEVC 30Mbps+ NON-animated (reality) video sample?
I want to compare it with a typical blu ray quality (1080p H.264 30Mbps+).

I want to compare CPU-Load & Picture Quality.

Thanks.

iSunrise

5th November 2013, 17:04

...I feel Hollywood will be more concentrated on higher bitrate with 1080p resolution, than UHD with lower bitrate...
That´s not how marketing works.

James Freeman

5th November 2013, 19:05

That´s not how marketing works.

I can understand that.
4K is alot shinier than HD

What do you think the future of Blu Ray will look like?

Guest

5th November 2013, 19:28

What do you think the future of Blu Ray will look like? Not on-topic for this thread. Please open a new one.

mandarinka

5th November 2013, 21:01

The same thing applies to H.264, yet many decoders didn't handle it, even if they otherwise handled 10-bit decoding - it was just never implemented, because it was never used.

Well, there were no decoders for High 10 to begin with. There is only CoreAVC and libavcodec and both are software. Also, they probably don't care much about being completely conformant to the whole spec.

LigH

6th November 2013, 09:05

Can anyone point me to a link with a 1080p HEVC 30Mbps+ NON-animated (reality) video sample?

The closest lossless source to "reality" I have is "Tears of Steel". I'm just testing an encode of an action cut of one minute, the result may be available today or tomorrow, depending on the speed and resulting bitrate. And due to the efficiency of HEVC, it is not easy to pass the target of 30 Mbps (without padding)...

James Freeman

6th November 2013, 10:09

@LigH

Thank you for the upcoming test video.
A minute of footage will be enough to compare HEVC vs H.264.

And due to the efficiency of HEVC, it is not easy to pass the target of 30 Mbps (without padding)...

I have no idea what padding is.
Do you mean HEVC is too efficient so the results are always less than 30Mbps?
If that's the case, its Great!

I thought of a good comparison method.
Visual (SSIM) & File Size:

File Size comparison (same visual quality):
1. x264 encoded to 30Mbps with a resulting X SSIM value.
2. Set HEVC with the same X SSIM value but let it compress to what Bitrate as it wants.

This test is good to compare how much will we able to put into a single defined space, like an optical disc.
For example: How many hours of film will we be able to put into the same size with the same quality.

Visual Comparison (same file size):
1. x264 encoded to 30Mbps with a resulting X SSIM value.
2. HEVC encoded to 30Mbps with a different resulting Y SSIM.

This test is good to visually compare how much better the picture quality will be in the same file size.

zerowalker

6th November 2013, 10:35

I am a bit confused as i haven´t been following H265.

Which encoder is the one i should look at, is it this x265?

And if so, which of them, i see the one linked at first post, and i know the one at Google Source thing?
Or are they the same?

Also, how is it looking, is it still a child to be fed, or is it starting to look like something so to speak?

Thanks

filler56789

6th November 2013, 11:44

I have no idea what padding is.

When you set the encoder to achieve a target bitrate "X", and the resulting stream has an actual bitrate "less than X", then the encoder may fill the video stream with NULL bytes.

And due to the efficiency of HEVC, it is not easy to pass the target of 30 Mbps (without padding)...

Correct :) Still, you could try the following settings:

--- disable B-frames

--- use short GOPs (i.e., more I-frames)

--- use low quantizers (18 or even less)

HTH :)

LigH

6th November 2013, 11:53

Well, yes, it is possible to get quite high bitrates locally. Limiting the encoding efficiency will reduce the required decoding efforts as well, though, therefore I'm trying to create a rather complex video with longer GOPs, severe referencing, and still high bitrates; so the only way to achieve that is a low quantization. CRF 12 appears to be promising... more later.

To keep the bitrate in a closer range, x265 would require a VBV like regulation, though.

And yes, stuffing would mean to fill up the video with non-bitstream junk just to keep the brutto bitrate rather constant; the only known use (to me) for this waste would be DVB bouquets, and maybe optical disk material to avoid buffer overflows.

Kurtnoise

6th November 2013, 14:43

Does anybody confirm that the latest x265 builds (with the latest commits from today) are broken using the pipeline ?

I tested my own builds and the ones from x265.cc, all fail...at least with yuv.

LigH

6th November 2013, 16:36

Version 0.5+153 (VC12 x86-64) works in general with Y4M file input, but produces artefacts with a complex command line:

-F 3 -q 23 -b 3 --b-adapt 2 --bframe-bias 30 -w --ref 3 -i 240 --psnr --ssim --rdpenalty 1 --aq-mode 1

Same for piping Y4M via avs2yuv: Works in general, but produces artefacts.

Same for piping raw YUV i420 via avs2yuv: Works in general, but produces artefacts.
__

Hmm. Different command line option set, no artefacts...

--preset slower --crf 24 -F 6 -w --bframe-bias 30 -i 240 --rdpenalty 1 --aq-mode 1

Skankee

7th November 2013, 00:23

Yes, Encode.
108Mbps is higher than a typical Blu Ray with 30Mbps.
If you have anything higher than 108Mbps it will be of help.

You could try the movie "sita sings the blues" (1080p, 31,1 GB y4m file)

With x264.2345.x86.exe and "--preset placebo --tune animation --crf 18 --keyint infinite --open-gop --threads 2"

there was a 128 Mbps peak between 1min 50s - 2min 05s. Maybe this is what you need to do you HEVC-decoding test.

The closest lossless source to "reality" I have is "Tears of Steel"...And due to the efficiency of HEVC, it is not easy to pass the target of 30 Mbps (without padding)...

Just for fun i encoded Tears of Steel with extreme settings with x264 at crf 18 and got an average bitrate of 6890 kbps, so 30 Mbps seems to be a little bit too much for me when you (James Freeman) expect "big" differences between h264 and HEVC.

C:\x264.2358.10bit.x86.exe --video-filter resize:width=1920,height=804,method=bicubic --profile high10 --preset placebo --crf 18 --tune film --threads 1 --keyint infinite --open-gop --colormatrix bt709 --output ...

zerowalker

7th November 2013, 01:13

x265_Project

7th November 2013, 02:04

Where can i get builds?
I am unable to build them myself, don´t understand, i used Cygwin64, and it says something about Cmake 32bit, seems to be different from normal git stuff.

So hoping someone is building and have it to share, or perhaps know a easy way to build it?

It's not too difficult to get your system configured to clone the source code repository, or later just pull updated source code with mercurial, make a solution with cmake, then build the solution with your favorite compiler. Instructions are here... https://bitbucket.org/multicoreware/x265/wiki/Home.

To clone the repo, run the following command after installing mercurial (edit the destination directory if you want something other than c:\x265)...
hg clone https://bitbucket.org/multicoreware/x265 c:\x265
After you've cloned the repo, you can just write a script that allows you to pull updates, make and build.

For example, on my Windows 64 system I have a batch file that automates the process...
c:
cd c:\x265
hg pull -u https://bitbucket.org/multicoreware/x265
@echo on
ECHO Generate the solution, then continue
cmake-gui C:\x265\source --build C:/x265/build/vc11-x86_64
pause

ECHO Building the solution
C:\x265\build\vc11-x86_64\x265.sln /t:rebuild /p:configuration=release
pause
Of course, you may need to edit this to point it to your local copy of the x265 source code, or to use a different compiler.

The script above utilizes the cmake and Visual Studio GUIs (which will allow you to set CMAKE options, or build a debug build, for example). Here is a similar script that avoids the CMAKE and Visual Studio GUIs (using the built-in Windows compiler... you may need to edit this to find your compiler)
c:
cd c:\x265
hg pull -u https://bitbucket.org/multicoreware/x265
pause
@echo on
ECHO Generate the solution
cmake -G "Visual Studio 11 Win64" C:\x265\source --build C:/x265/build/vc11-x86_64

ECHO Building the solution
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\msbuild.exe C:\x265\build\vc11-x86_64\x265.sln /m /t:build /p:configuration=release
xcopy C:\x265\build\vc11-x86_64\release\x265.exe c:\Testx265\x265.exe /Y

Note that the above scripts will default to the development tip. If you want to build the latest stable version, run the following command (after you pull the latest code with hg pull)...
hg up stable
... then make the solution and build.

I hope this helps.

Tom
MulticoreWare

filler56789

7th November 2013, 02:26

Where can i get builds?

https://x265.cc/

...perhaps know a easy way to build it?

http://forum.videohelp.com/threads/357754-%5BHEVC%5D-x265-EXE-mingw-builds?p=2259093&viewfull=1#post2259093

zerowalker

7th November 2013, 04:41

Thanks!

Kurtnoise

7th November 2013, 08:51

Does anybody confirm that the latest x265 builds (with the latest commits from today) are broken using the pipeline ?

I tested my own builds and the ones from x265.cc, all fail...at least with yuv.
ok, it has been fixed...

LigH

7th November 2013, 09:38

Just for fun i encoded Tears of Steel with extreme settings with x264 at crf 18 and got an average bitrate of 6890 kbps, so 30 Mbps seems to be a little bit too much for me when you (James Freeman) expect "big" differences between h264 and HEVC.

Preset "placebo" is mainly a waste of time. Any faster preset would take less efforts to remove redundancies and return more bitrate.

If you want higher bitrate, don't encode slower. Instead, encode more exactly, decrease the CRF value.

I just encoded a 1 minute snippet from "Tears of Steel" using x265 with CRF 12, but still a slower preset to ensure a high complexity to stress decoders. It has an average of ~31.3 Mbps video bitrate. Peaks are around 100 Mbps (if I can use the bits-per-frame log as reliable presentation base).

tos_60s_hevc.mp4 (http://www.mediafire.com/download/zb8tbcr5v2tu31z/tos_60s_hevc.mp4) on MediaFire (224 MB)

http://www.ligh.de/pics/tos_60s_hevc.png

LigH

7th November 2013, 14:10

To keep the bitrate in a closer range, x265 would require a VBV like regulation, though.

And just that was mentioned in the developer mailinglist, regarding a source patch.

Soon™. :)

James Freeman

7th November 2013, 17:55

@LigH

Thank you for this sample.
I takes about 2-3 times the CPU load across all cores (no GPU decoding) compared to a 30Mbps Blu ray.

x265_Project

7th November 2013, 22:41

I've just published an updated version of the x265 Evaluator's Guide (https://bitbucket.org/multicoreware/x265/downloads/x265%20Evaluators%20Guide%2011-07-13.pdf).

Let me know if anything is unclear, or if you have any suggestions for improvement.

Thanks!

Tom
MulticoreWare

vood007

8th November 2013, 03:03

Is there anything special to take care of when using --aq-mode 1 ? As LigH said it breaks video when used with a preset faster than "slower".

Using VDub with "--input-res %(width)x%(height) --fps %(fps) --preset faster --crf 24 --aq-mode 1 --no-progress - -o "%(tempvideofile)"
and latest MPCHC/LAV for playback.

Anyway thanks to all x265 devs out there, you do a fantastic job!

LigH

8th November 2013, 08:32

As LigH said it breaks video when used with a preset faster than "slower".

I did not say it this way; but if your observation is correct, then it may be related to slower presets initializing some specific options which faster presets might miss. This is certainly worth an investigation.
__

P.S.:

The preset "slower" is the fastest with full RDO analysis in mode decision (--rd 2), all faster presets use a limited RDO analysis. This is probably not yet supported well by AQ, according to Steve Borho (in the developer mailinglist).

professor_desty_nova

9th November 2013, 10:19

Is there a problem with --rd? Because now the "slower" and "veryslow" presets have it at rd=0. Or is it that with these presets it's too slow?

Selur

9th November 2013, 12:03

looking at the code (https://bitbucket.org/multicoreware/x265/src/45c5ba1dc340fe59a91b5397adb769e5ba8e2fde/source/common/common.cpp?at=default) it seems like they changed the defaults and removed all 'rdLevel' entries > 0 from the presets
-> small correction, the whole presets are a mess atm. since they have not been adjusted alongside the defaults,...
in example, new defaults state:
maxNumReferences = 3
veryfast, superfast, ultrafast -> maxNumReferences not defined -> maxNumReferences = default = 3
faster, fast preset -> maxNumReferences = 2
slow preset -> maxNumReferences = 3
.....

Blue_MiSfit

10th November 2013, 05:09

The latest 8 bit Windows x64 build from x265.cc seems to be doing something strange. I'm getting nasty corruption when playing in mpc-hc and the latest mp4box is refusing to mux it saying the following:

Unknown input file type
Unknown input file type
Error importing x265_20000.h265:fps=50: Corrupted Data in file/stream

easyfab

10th November 2013, 09:34

Blue_MiSfit

10th November 2013, 11:56

Got it -that worked.

Still some horrible strangeness in MPC. I wonder if this is just a corner case? I'm trying to encode parkjoy in 1080p50 at 8 Mbps and 20 Mbps, and even at 20 Mbps the whole scene is extremely bright, blocky, and smeared in the first GOP. The brightness issue is fixed in the second GOP but it's still blocky and smeared.

x264 is almost perfect at this bitrate.

http://imgur.com/a/KEYSj#0

The images got reversed. Image 0 is the second GOP and image 1 is the first GOP.

filler56789

10th November 2013, 12:04

@ Blue_MiSfit: how about posting the exact command-line you used?
Keep in mind that currently some of the options do produce weird results when used together.

Also, when using avs2yuv without the option "-raw", x265 must use the --y4m switch.

Blue_MiSfit

11th November 2013, 08:04

Mostly defaults, just tuning for SSIM and measuring it, plus a 20 Mbps ABR target

x265 --bitrate 20000 --tune ssim --ssim --csv x265_20000.csv --output x265_20000.h265 parkjoy.y4m

filler56789

11th November 2013, 11:14

Mostly defaults, just tuning for SSIM and measuring it, plus a 20 Mbps ABR target

x265 --bitrate 20000 --tune ssim --ssim --csv x265_20000.csv --output x265_20000.h265 parkjoy.y4m

Which translates as something like:
x265 [info]: CU size : 64
x265 [info]: Max RQT depth inter / intra : 1 / 1
x265 [info]: ME / range / subpel / merge : star / 60 / 5 / 3
x265 [info]: Keyframe min / max : 250 / 250
x265 [info]: Rate Control : ABR-***** kbps
x265 [info]: Lookahead / bframes / badapt : 40 / 3 / 1
x265 [info]: tools: rect amp rd=0 ref=3 lft sao-lcu sign-hide aq

Therefore, thanks for confirming what I had said :)

currently some of the options do produce weird results when used together

For relevant and more up-to-date info, you'd better start following the thread http://forum.videohelp.com/threads/357754-%5BHEVC%5D-x265-EXE-mingw-builds

Yes, it has a lot of "noise" :rolleyes: , but that's not the point ;)

benwaggoner

11th November 2013, 23:04

Blue_MiSfit

12th November 2013, 02:52

:D go figure - the second I sit down to start messing around and the presets are wonky :D

Hiritsuki

12th November 2013, 03:43

well, I try to compile the default version in source code and test it....

http://i.minus.com/jvpiFisuI2r4G.png (http://minus.com/lvpiFisuI2r4G)

seems have some blur?

BD Source
http://i.minus.com/jbczilqQ9TWeKt.png (http://minus.com/lbczilqQ9TWeKt)

x265 -q 17
http://i.minus.com/jbdzO6RLxwUCWr.png (http://minus.com/lbdzO6RLxwUCWr)

Hiritsuki

12th November 2013, 04:20

Round 2

try to Disable SAO

http://i.minus.com/jbrLLhJeEFj8n0.png (http://minus.com/lbrLLhJeEFj8n0)

Blue_MiSfit

12th November 2013, 06:51

Good lord. Is that a quad socket system with all 8 core CPUs? Running 2012 R2? Being used for home stuff? What fun ;)

To be on-topic, I would expect some softness. x265 is still quite young.

x265_Project

12th November 2013, 07:01

I've been playing around with quality and scenario tuning of x265 (using 0.5+259-9d74638c3640). I have a few questions I haven't seen answered yet.
Ben,
Answers from our lead developer inline below...

* Does x265 CRF generally match the perceptual quality of x264 CRF? Or are they on a different visual scale due to QP being handled differently or anything? I note the default is 28, which is higher than x264's.
CRF is a feature contributed by an open-source developer, back-porting this from x264, so we are roughly the same. However in general, I believe CRF really wants a decent adaptive quant feature and ours is still incomplete. It would really benefit from mb-tree but that is not even started yet.
* When using CRF, should --tune be left alone to let Rate Factor work, or will it still try to default to --tune PSNR, in which case using --tune SSIM will probably offer better VQ?
the --tune PSNR and --tune SSIM switches currently do nothing. We are still working through this as part of the AQ work.
* Was --weightp turned on by default? The Evaluator's guide suggests no, but the --preset parameters suggest yes

It is not, yet. We're waiting for weightp lookahead analysis before turning it on by default. We're currently *also* turning it off for ultrafast preset just to make sure when the default is switched on, the ultrafast preset still disables it. I expect this to be switched on by default this week.

* Does --aq-mode default to off due to quality concerns or what?
Basically, AQ, CRF, --tune SSIM and --weightp are all unfinished features in the middle of construction

* is --merange in pixels of final frame, or a half-size frame, or what?

It is in pixels of the final frame.

Tom

Hiritsuki

12th November 2013, 08:45

SAO will blur some color

Enable SAO 687MB
http://i.minus.com/jm9FR88Be2AcY.png (http://minus.com/lm9FR88Be2AcY)

Disable SAO 695MB
http://i.minus.com/j1Sq5zisRIjS7.png (http://minus.com/l1Sq5zisRIjS7)

Kurtnoise

12th November 2013, 09:21

Which decoder did you use ?

Hiritsuki

12th November 2013, 10:57

Lav :d

Hiritsuki

12th November 2013, 11:21

BTW

x264 10bit --preset Placebo --ref 8 --bframe 8 --pass 2pass --bitrate 5000 (0.99GB)

http://i.minus.com/jbNkIeHypsYTV.png (http://minus.com/lbNkIeHypsYTV)

Hiritsuki

12th November 2013, 17:13

hi, is there have any way to mux .h265 to other fomat with audio and change fps to 23.976?

microchip8

12th November 2013, 17:23

hi, is there have any way to mux .h265 to other fomat with audio and change fps to 23.976?

use mkvmerge

filler56789

12th November 2013, 17:44

use mkvmerge

Is there any HEVC-capable build of MKVtoolnix besides the non-compliant versions from the DivX Labs? :)

Otherwise, there are the alpha builds of MP4Box and mp42ts ;)

easyfab

12th November 2013, 17:52

DivX mkvmerge or mp4box, but this is experimental as the final specification is not out yet.
So your file could be incompatible in the future

James Freeman

12th November 2013, 20:25

@Hiritsuki

The x264 video is 5kbps and 990MB.
What is the kbps for the HEVC 695MB?

Disable SAO looks a lot better.

mandarinka

12th November 2013, 21:39

I've been playing around with quality and scenario tuning of x265 (using 0.5+259-9d74638c3640). I have a few questions I haven't seen answered yet.

Does x265 CRF generally match the perceptual quality of x264 CRF? Or are they on a different visual scale due to QP being handled differently or anything? I note the default is 28, which is higher than x264's.
When using CRF, should --tune be left alone to let Rate Factor work, or will it still try to default to --tune PSNR, in which case using --tune SSIM will probably offer better VQ?
Was --weightp turned on by default? The Evaluator's guide suggests no, but the --preset parameters suggest yes
Does --aq-mode default to off due to quality concerns or what?
is --merange in pixels of final frame, or a half-size frame, or what?

x265 doesn't have psyrdo, which means that the visual quality isn't quite as good as with x264 - it will still smooth out texture or grain, although less so now that you can use adaptive quantization (it really helps in this). It seemed to me though that the crf "number" isn't that different from x264 when I tried it with placeboish options (everybody needs to try how it works out for them, though).

Hiritsuki

13th November 2013, 00:09

@James Freeman

Yes, disable SAO is looks better than enable.
I set x265 -q 17
28min22s and 695MB so...it's AVG 3345kbps
It's encode over 2.5hours.

final I use mp4box (beta ver?) to mux video,audio and change fps frome friend.

sneaker_ger

13th November 2013, 00:13

final I use mp4box (beta ver?)
Yes, get a nightly from here (http://gpac.wp.mines-telecom.fr/downloads/gpac-nightly-builds/#Windows 32 bits).

Not sure if it is ok to just change the frame rate in mp4box or if you should use the correct frame rate in x265 using the --fps parameter already.

fumoffu

13th November 2013, 00:23

http://i.minus.com/ibwKpR4gi1WDk8.png http://i.minus.com/i9ZZMdX4hwGt.png

the lines in HEVC look much nicer, pretty much ideally while there is a lot of jaggies and ringing in x264

although this might be due to default psy.

x264 10bit --preset Placebo --ref 8 --bframe 8 --pass 2pass --bitrate 5000 (0.99GB)
--tune animation sets --psy-rd 0.4:0 I prefer even lower like --psy-rd 0.3:0
btw. tune animation also sets --aq-strength 0.6 which I find puzzling because it seems high values like --aq-strength 1.3 or 1.4 prevent artifacts on smooth areas and gradients
it's also recommended to disable trellis for animation --trellis 0

Hiritsuki

13th November 2013, 00:44

use the correct frame rate in x265 using the --fps parameter already.

x265 using --fps is means input source's fps is:scared:

Hiritsuki

13th November 2013, 03:25

in my test .. 8bpp have little better quality than 16bpp
i thought because that 16bpp is use for 10,12,16bit input.

@fumoffu

x264 have to set tune but x265 have not and file size is smaller.
but encode time is more than x264 4 times...

zerowalker

13th November 2013, 09:38

does x265 support 16bit output?
Or is it only input up to 16bit or something?

LigH

13th November 2013, 09:52

It is not related to the resolution of the visible image components (RGB or YUV), only to the internal representation of coefficients after a transformation into a frequency domain (prior to H.264, a Discrete Cosine Transform with 8×8 sample partitions – blocks and macroblocks – was commonly used; since H.264, additional integer transforms with different partition sizes are more common).

The support of "deep-color video" is not yet implemented. If it will be, is guesswork...

Selur

13th November 2013, 11:56

does x265 support 16bit output?
Or is it only input up to 16bit or something?
from what I see atm. both input and output should be 8bit (only internal calculation precision can be changed to 16bit and it's unclear if that is working properly)

qyot27

13th November 2013, 14:24

Actually, you can output 10-bit if you give it YUV and use --input-depth 10. mediainfo detects it as 10-bit, and it can be played back by the HEVC decoder in libavcodec (ffmpeg detects it as yuv420p10le too). But it seems that many parts of the encoding chain haven't been made high bit depth aware, since to avoid macroblocking you have to use a lower crf value than for 8-bit (or we're just seeing the return of crf value skew between bit depths like right after 10-bit was added to x264).

It'd be nice if the y4m support would include the extended format that FFmpeg uses (VapourSynth also uses it, and x264 can recognize it). That'd allow for piping in high bit depth video in y4m. Currently, it complains about missing headers if you try it.

zerowalker

14th November 2013, 11:29

I see well 16bit internal processing should be advantageous, especially in dark areas.
Still i would like it to have output support to 10bit, above would be nice as well though it has dimishing return.

Has anyone tried Lossless btw, and compare it to x264 in size?
If x265 has lossless support yet that is.

Have tried some tests myself, but it doesn´t seem to go my way, and crash or just turn out to look really crappy for some reason.
Not sure if it´s suppose to look like 500bitrate when it´s at 2k, even if it is in Beta.

Kurtnoise

14th November 2013, 11:31

x265 doesn't have a lossless mode yet...:rolleyes:

zerowalker

14th November 2013, 11:50

Ah, hope it comes, x264 is amazing.
Though i do prefer Lagarith and UT Video Codec cause of the Key Frames i think, x264 messes up Seek ability when editing.

though about x265, is Decoding lagish for you?
It seems to lag for me even though it doesn´t use 100% of the CPU (or 50% in my case as i think it only has 2 threads supported).

And also did some tests, and x265 very similar in quality to x264 as it is now, a bit worse. But in it´s development stage i think that´s to be expected as x264 has been developed for as long as one can remember.

pieter3d

15th November 2013, 21:26

Hiritsuki

19th November 2013, 23:37

why new version 0.5+414-1449a1a2041f I get error crash?

LigH

20th November 2013, 08:30

May happen. The autobuild binaries are created with the release of each patch, which may introduce bugs.

fumoffu

20th November 2013, 18:51

Can someone explain what --cbqpoffs and --crqpoffs options do? and what is the difference between them?
thanks

Selur

20th November 2013, 20:58

from what I understand:
Cb and Cr are blue-and red-difference of chroma components, see: http://en.wikipedia.org/wiki/CbCr
qp = quantization parameter
--cbqpoffs sets an offset for the quantization of the blue-difference of the chroma
--crqpoffs sets an offset for the quantization of the red-difference of the chroma
so basically you can change the compression of red and blue color components through it (positive values -> higher quantizer -> higher rounding losses; negative values -> lower quantizer -> less rounding losses)

mandarinka

21st November 2013, 04:37

Same as x264's chroma quantizer offset, but you can tweak it separately for both of the chroma channels (funny idea, you probably don't generally want to do that, but maybe some day somebody will ahve use for the flexibility).

nakTT

21st November 2013, 07:55

Good day to you guys.

I can see is that the MeGUI running x265 encoder does not seem to follow ABR (say, 300kbps) that I have set. It will somehow mysteriously go way below that value, even way below 100kbps. I do not know if this is issue with how MeGUI handle the x265 or it is an issue with x265 itself. Please advise.:thanks:

Selur

21st November 2013, 11:22

@nakTT: megui issue

Kurtnoise

21st November 2013, 11:30

@nakTT: megui issue
why did you say that without real information ? :rolleyes:

@NakTT : you should retry with a more recent x265 build...

nakTT

21st November 2013, 13:39

@nakTT: megui issue
Thanks for the reply. Will follow up with MeGUI guru in their thread.

nakTT

21st November 2013, 13:45

why did you say that without real information ? :rolleyes:

@NakTT : you should retry with a more recent x265 build...
Thanks for the advise. Currently I am using the latest version that I can get through normal update on MeGUI (Development Update Server). Any idea which build on the x265.cc that I can use to replace the version I get from MeGUI (r2424) Development Update Server?
:thanks:

Selur

21st November 2013, 17:54

@Kurtnoise: you are right did some further testing and seems like it is related to the input and the settings used :)

benwaggoner

22nd November 2013, 17:21

Thanks for the advise. Currently I am using the latest version that I can get through normal update on MeGUI (Development Update Server). Any idea which build on the x265.cc that I can use to replace the version I get from MeGUI (r2424) Development Update Server?
:thanks:
There have been lots of parameter changes. You probably don't want to run x265 if you want to be using recent updates. It looks like even the dev server is using an Nov 12th build, which is eons ago for x265 :).

Selur

22nd November 2013, 17:48

In Hybrid I'm using '0.5+413-2f5f538d2cbc', which seems to be rather stable,..

nakTT

22nd November 2013, 17:50

There have been lots of parameter changes. You probably don't want to run x265 if you want to be using recent updates. It looks like even the dev server is using an Nov 12th build, which is eons ago for x265 :).
Thanks for the advice.

Just to share my experience today with the latest x265 rev 0.5+524 (VC12) taken from x265.cc. It seems that for the same CQ setting (say, 27), the file size (bitrate) is a bit smaller (around 13% smaller) compared to the one that come with the rev 0.5+259 that come from MeGUI Development Update Server. And the quality isn't getting worse despite the drop in bitrate. Perhaps it was my eyes perhaps not.

mandarinka

22nd November 2013, 20:18

nakTT

23rd November 2013, 02:57

B-pyramid has been enabled in the encoder AFAIK. That is probably the reason, although at 13 % bitrate reduction, I suspect the quality has dropped a bit too (more bframes which have higher QPs than pframes).
You maybe right and perhaps it just not really apparent to my untrained eyes.;)

BTW, the input video that I used was HD (resolution: 1280 X 528) and the Encoding Mode: CQ (Constant Quality) at 27 running on x265 rev 0.5+524 (VC12).

Now I am encoding (as we speak) on even latter version of x265: rev 0.5+546 (VC12). Will update here if there is any thing worth mentioning.

fumoffu

23rd November 2013, 15:01

There seems to be a problem with --frame-skip. When I tried to use it, it just skipped all frames.

ffmpeg.exe -i test.mp4 -an -f yuv4mpegpipe - | x265 --y4m --input-res 1280x720 --fps 29.97 --frame-skip 26000 --frames 777 --no-progress --crf 20 - -o test.hevc
In the console window I saw it was still skipping frames even after 30000 frame...
Also skipping frames is suspiciously cpu intensive. And the limiting factor wasn't ffmpeg but x265 which was saturating 25% of my 4 core CPU - 1core. I guess no one implemented multi-threading for skipping frames ;) probably because it shouldn't really be taking almost any cpu power?

Selur

23rd November 2013, 15:13

frame skip with pipe input would still require x265 to read all the skipped frames,... -> better limit your ranges through ffmpeg
('--frame-skip' should be a normal input only option,..)

nakTT

23rd November 2013, 16:21

Hi guys.

Do you guys know any short (very high quality, detail as well as complex) video clip that I can download and use as a sample to test x265? Thank you in advance.
:thanks:

LigH

23rd November 2013, 16:30

Check the Xiph.org Test Media (http://media.xiph.org/) collection. Many are available losslessly as Y4M (but huge downloads!).

Also I provide some files on MediaFire, e.g. the Sintel trailer encoded with x264 in CRF 6 (http://www.mediafire.com/watch/d2wmzz76d47q838/sintel_trailer_1080_crf06.mkv).

nakTT

23rd November 2013, 17:01

Also I provide some files on MediaFire, e.g. the Sintel trailer encoded with x264 in CRF 6 (http://www.mediafire.com/watch/d2wmzz76d47q838/sintel_trailer_1080_crf06.mkv).
This is more like it. Smaller size like this one would be better for my broadband quota.
:thanks:

fumoffu

23rd November 2013, 18:18

frame skip with pipe input would still require x265 to read all the skipped frames,... -> better limit your ranges through ffmpeg
('--frame-skip' should be a normal input only option,..)

thanks I will do that, but still that doesn't explain why it doesn't work :/
well at least it's nothing important

mandarinka

23rd November 2013, 19:01

Maybe you also could use avisynth instead of ffmpeg, and pipe using avs2yuv.

avs2yuv has -seek and -frames options, and it should only forward those selected frames through the pipe. (Note that I never needed to try that.)

benwaggoner

24th November 2013, 19:41

x265_Project

25th November 2013, 02:47

x265_Project

25th November 2013, 03:23

I just made a couple of last minute corrections... if you downloaded it already, please download again to get the corrected version.

nakTT

25th November 2013, 03:44

Thanks. Will do that.

caiyuwei

25th November 2013, 03:50

Megui didn't let us config Andvanced Settings of x265 in x265 configuration dialog yet...

LigH

25th November 2013, 11:27

@ caiyuwei:

MeGUI r2422 (http://kurtnoise.free.fr/megui/MeGUI-r2422_x265.7z) within x265 basic support, to play with...Only presets and ABR/CRF/QP modes are available for the moment.

I don't expect this limit to be overcome already, from test build r2422 to official build r2424.

If you are an experienced tester, you may prefer other x265 GUIs or even direct editing of CLI options (e.g. in Batch files).

If you are no tester, don't use x265 at all, yet.

nakTT

25th November 2013, 12:08

Experimenting with a build from Friday, I accidentally encoded Tears of Steel at 3840x1600p24 at 5 Mbps. It looks actually pretty good! I used crazy high quality encoding settings that ran at 0.19 fps on my 12-core, but still. 5 Mbps UHD!

Keep up the good work, guys.
That was some hell of a job for your 12-Core. What is the built that you used? Was it 0.5+547 or 546? Any comment if compared with the version that come with MeGUI? For me, I can see that current build produce smaller file size for the same Constant Quality setting.

Personally, I wouldn't dare to go within 10-feet of the resolution you was using. The highest I have gone so far with my ancient so-called ultrabook (i7-3667U) is just HD resolution.

fumoffu

25th November 2013, 14:18

I've posted an updated version of the x265 Evaluator's Guide...

x265 Evaluators Guide Nov 24 2013.pdf (https://bitbucket.org/multicoreware/x265/downloads/x265%20Evaluators%20Guide%20Nov%2024%202013.pdf)

Feedback is welcomed.

Tom

Thank you very much!
Question: the --merange default value 60 seems a bit high compared to x264 default 16... I understand it might be necessary for 4K video but if I encode in 720p lowering it to 24 or 32 wouldn't be more optimal? Were there any tests done to determine the default value?
Also why 60 and 124 for placebo and not "round" 64 and 128? ;-)

x265_Project

25th November 2013, 17:41

Thank you very much!
Question: the --merange default value 60 seems a bit high compared to x264 default 16... I understand it might be necessary for 4K video but if I encode in 720p lowering it to 24 or 32 wouldn't be more optimal? Were there any tests done to determine the default value?
Also why 60 and 124 for placebo and not "round" 64 and 128? ;-)

We've performed many tests to determine the most optimal performance presets (and default values), but there is always room for improvement. We tend to err on the side of quality for each setting, but as you need to run faster, we try to find the right combination of settings that improve encoding speed with the minimal tradeoff in compression efficiency (quality / bitrate). You will see that the fastest performance presets use a smaller motion estimation search range.

We leave 4 pixels at the end of the motion estimation search range to allow room for subpel refinement without causing the encoder to need to retrieve more Coding Units.

Tom

Selur

25th November 2013, 19:45

sadly, compiling on Mac OS X 10.6.8 is still broken

benwaggoner

25th November 2013, 20:56

That was some hell of a job for your 12-Core. What is the built that you used? Was it 0.5+547 or 546? Any comment if compared with the version that come with MeGUI? For me, I can see that current build produce smaller file size for the same Constant Quality setting.
It was using a daily build from Friday. I'm traveling right now and can't verify the actual build number.

fumoffu

26th November 2013, 00:03

We've performed many tests to determine the most optimal performance presets (and default values), but there is always room for improvement. We tend to err on the side of quality for each setting, but as you need to run faster, we try to find the right combination of settings that improve encoding speed with the minimal tradeoff in compression efficiency (quality / bitrate). You will see that the fastest performance presets use a smaller motion estimation search range.

So I have done some simple tests on 720p, 4 minute long hand-held camera footage - a lot of motion all the time ;)

x265 settings: defaults with --crf 21 --b-adapt 2
merange 60: 4.61fps psnr: 46.402 size: 63719KB
merange 40: 4.86fps psnr: 46.403 size: 63801KB - 5% faster, 0.13% size increase
merange 24: 5.08fps psnr: 46.404 size: 64194KB - 10% faster, 0.74% size increase

With PSNR almost identical, imho it's worth it to decrease the range for 720p sources. I think I will go with merange 32 or 36 in the future.
Would it be against some convention for the encoder to change default merange depending on input resolution? Surely what is optimal for 4K video isn't optimal for SD...
For example, encoder detects (or rather is told) that the input res is:
>=1080p it sets merange to 60
<1080p and >=720p sets merange to 32 or something like that
<720p sets merange to 24
or we could come up with some clever formula that sets merange depending on pixel count in the frame.
Bad idea?

nakTT

26th November 2013, 03:22

It was using a daily build from Friday. I'm traveling right now and can't verify the actual build number.
Its okay, enjoy your travelling.

I take it that the version you used has B-Pyramid feature. By the way, I can see that mediainfo unable to give us the version number of the x265 encoder (as well as the detail settings that it can give in the case of x264). Is there any other easy way to get it form the x265 encoded video? Right now I only use the hard way to determine it.

x265_Project

26th November 2013, 08:41

So I have done some simple tests on 720p, 4 minute long hand-held camera footage - a lot of motion all the time ;)

x265 settings: defaults with --crf 21 --b-adapt 2
merange 60: 4.61fps psnr: 46.402 size: 63719KB
merange 40: 4.86fps psnr: 46.403 size: 63801KB - 5% faster, 0.13% size increase
merange 24: 5.08fps psnr: 46.404 size: 64194KB - 10% faster, 0.74% size increase

With PSNR almost identical, imho it's worth it to decrease the range for 720p sources. I think I will go with merange 32 or 36 in the future.
Would it be against some convention for the encoder to change default merange depending on input resolution? Surely what is optimal for 4K video isn't optimal for SD...
For example, encoder detects (or rather is told) that the input res is:
>=1080p it sets merange to 60
<1080p and >=720p sets merange to 32 or something like that
<720p sets merange to 24
or we could come up with some clever formula that sets merange depending on pixel count in the frame.
Bad idea?
Your point is well taken. The optimal setting for merange is certainly related to the resolution of the input video, and we are now getting to the point where we can work on better algorithms for setting these variables, just as you have suggested.

Thanks for your feedback! I appreciate you sharing your test data also.

Tom

fumoffu

26th November 2013, 15:07

Is aq mode/strength supposed to work already?
It crashes the encoder for me after about 300 frames and what is encoded has artifacts.
I tried on latest (0.5+571-491fd3ee6fd1) 64bit build from x265.cc both vc12 and mingw.

Also few toughs about my earlier points about merange:
- Not sure how the results would change without b-pyramid (which doesn't work with some GOP structures) because if we skip a frame (meaning it can't be used as reference) it might be harder to find some motion vectors that during this frame moved outside search range.
- If we would optimize merange depending on resolution, it could also be optimized for fps. With 60fps video that is much more fluid we could theoretically decrease the motion search by half without much impact on compression.
- My tests video was amateur hand-held camera footage. I'm not sure how it would compare to feature films where the image for the most part doesn't move as much. I bet the difference is size would be even smaller but maybe the gains in speed would be much less noticeable also.

Sagittaire

26th November 2013, 20:35

Someone make regular build for this really good open source project?

x265.cc

26th November 2013, 20:39

Using the current megui for x265 is a bad idea*.

It comes with old 16bpp (only) builds from various (32bit) compilers.

*performance and quality wise

e.g.
x265 [info]: HEVC encoder version 0.5+259-9d74638c3640
x265 [info]: build info [Windows][GCC 4.8.2][32 bit] 16bpp
x265 [info]: using cpu capabilities: MMX2 SSE SSE2Fast SSSE3 SSE4.1 Cache64

x265 [info]: HEVC encoder version 0.5+554-fdaa754dfbd4
x265 [info]: build info [Windows][MSVC 1700][32 bit] 16bpp
x265 [info]: using cpu capabilities: MMX2 SSE SSE2Fast SSSE3 SSE4.1 Cache64

Any idea which build on the x265.cc that I can use to replace the version I get from MeGUI (r2424) Development Update Server?

Any version should fit. You should use 64 bit, 8bpp build (gcc/vc12)

Someone make regular build for this really good open source project?

What do you mean with "regular build"?

Sagittaire

26th November 2013, 21:04

Someone make regular build for this really good open source project?

"regular" in my french language mean "make regulary build" for user like on x264.nl web page ... ;-)

x265.cc

26th November 2013, 21:08

"regular" in my french language mean "make regulary build" for user like on x264.nl web page ... ;-)

erm..

something like the x265.cc (https://x265.cc) web page? :D

Sagittaire

26th November 2013, 22:43

erm..

something like the x265.cc (https://x265.cc) web page? :D

exactly ... lol

thx

nakTT

27th November 2013, 04:07

Any version should fit. You should use 64 bit, 8bpp build (gcc/vc12)
Currently I am using 32bit version of x265 (VC12) from x265.cc.
Should I decide to use the 64bit version as you recommend, do I need to change any settings (or whatever) in the MeGUI? I love to use 64bit if it is not too much trouble. Thanks.
:thanks:

nakTT

27th November 2013, 06:10

erm..

something like the x265.cc (https://x265.cc) web page? :D
VC12 0.5+571, 0.5+581 and 0.5+584 all crash on me. The latest version that is not crash is 0.5+554. Please advice.:thanks:

sborho

27th November 2013, 06:58

sadly, compiling on Mac OS X 10.6.8 is still broken

If you send an email to the x265-devel@videolan.org mailing list with the full compile error, there's a good chance it will get fixed.

LigH

27th November 2013, 08:14

@ Sagittaire:

x265 is regularly built.

But still not for users, only for testers. ;)

Selur

27th November 2013, 09:36

@sborho: I hope so would be a shame to only be able to use x265 on Mavericks and up.

xooyoozoo

27th November 2013, 09:45

Min Keyinterval is currently set to match max keyint with no cli options for otherwise. However, scene detection / key frame placement seems to work perfectly fine if I modify the source. Is there a reason to avoid letting scene detection do its thing?

Selur

27th November 2013, 13:09

@xooyoozoo: Did you check what minimal key int interval gets chosen for "--min-key-int" set to 0 (auto) ? (or did you 'simply' use a fixed value for min-key-int?)

fumoffu

27th November 2013, 13:19

Is aq mode/strength supposed to work already?
It crashes the encoder for me after about 300 frames and what is encoded has artifacts.

Correction it does seem to work only with (crazy slow) --rd 2
Is this how it's supposed to be?

LigH

27th November 2013, 13:36

No, development of "incomplete" RD modes and AQ in conjunction is progressing... I did not have crashes in earlier tests, but encoding artefacts; AQ use{s|d} to rely on complete RD analysis data.

xooyoozoo

28th November 2013, 21:37

nakTT

29th November 2013, 06:41

x265_Project

29th November 2013, 08:12

We are getting close to a stable 0.6 version. If you are running builds from the development tip you will notice that we just updated the performance preset settings, providing better results and a better distribution of values (along the speed vs. efficiency curve). We'll publish a new Evaluator's Guide with the new values shortly.

Tom

nakTT

29th November 2013, 10:13

Procrastinating

29th November 2013, 10:30

Tested a simple 16s clip cut from a documentary BluRay and x264 2377 and x265 @2ba6c26. Used placebo presets and matched x264's 2pass bitrate to x265's default CRF (28) with aq-mode 1. Bitstreams and side-by-side comparison (https://drive.google.com/folderview?id=0BzAA-H5x8NKTelUtRHNrT3kzUms&usp=sharing).

I know that things are still incomplete, but at the very least, AQ seems to be doing its thing and there's no longer that fuzzy 'reference' look I remember from the HM.
Granted the x264 video could probably have been better tuned, but that does look like quite a measurable improvement! I have some free time on my hands, so I might try comparing some anime credits or something.

Another question, is 16bpp functional? Ie, can I input and/or output 10-bit video?

x265.cc

29th November 2013, 16:53

What is the version of x265 used?

"x265 @2ba6c26" ~ x265_0.5+610-2ba6c26c9feb

How do I know which is a development tip and which is not? Thanks.:thanks:

Look at the "stable" tag at https://bitbucket.org/multicoreware/x265/commits/all. As you can see the "stable" versions are normal "development" version which are meant to be stable.

Another question, is 16bpp functional? Ie, can I input and/or output 10-bit video?

AFAIK it can currently only output 16-bit hevc files (you probably should try it yourself), the current 16bpp version should work but is really incomplete and slow (in comparison to the 8bpp version).

We are getting close to a stable 0.6 version.

Can you tell me if there is any special usage case for the stable version?

James Freeman

29th November 2013, 17:01

Bitstreams and side-by-side comparison (https://drive.google.com/folderview?id=0BzAA-H5x8NKTelUtRHNrT3kzUms&usp=sharing).

Holly Cow, what a difference. :eek:
I don't know what the PSNR or SSIM are, but it sure looks almost twice as good.

And its only the beginning.

JEEB

29th November 2013, 17:23

AFAIK it can currently only output 16-bit hevc files (you probably should try it yourself), the current 16bpp version should work but is really incomplete and slow (in comparison to the 8bpp version).
The "16bpp" part only notes that the variables that keep the intermediate (and final) values are 16bit. The HEVC specification only specifies algorithms up to 14 bits, and the current HEVC profiles only support 8-10 bits. The encoding itself is 10 bits.

You are correct about it being very much slower than the 8bit version, of course ;)

MasterNobody

29th November 2013, 17:27

Tested a simple 16s clip cut from a documentary BluRay and x264 2377 and x265 @2ba6c26. Used placebo presets and matched x264's 2pass bitrate to x265's default CRF (28) with aq-mode 1. Bitstreams and side-by-side comparison (https://drive.google.com/folderview?id=0BzAA-H5x8NKTelUtRHNrT3kzUms&usp=sharing).

I know that things are still incomplete, but at the very least, AQ seems to be doing its thing and there's no longer that fuzzy 'reference' look I remember from the HM.
I would recommend next time when you will do x264 compression at such low bitrates that it is already blocking to disable PsyRD (--psy-rd 0). Because imho PsyRD is only visually useful when you have enough bitrate for it and at low bitrates it can harm quality. I doubt it will change this comparison significantly but should make x264 less blocky.

x265.cc

29th November 2013, 20:27

The "16bpp" part only notes that the variables that keep the intermediate (and final) values are 16bit.

hehe, thanks for clarifying this :goodpost:

Probably i should had to check the "input-depth" parameter first :D

x265_Project

29th November 2013, 20:54

We've updated x265's performance presets, providing better performance and compression efficiency (quality at any given bitrate) for most presets. We've also worked to provide a good range of values along the speed vs. efficiency curve.

I've posted a new x265 Evaluator's Guide (https://bitbucket.org/multicoreware/x265/downloads/x265%20Evaluators%20Guide%20Nov%2029%202013.pdf).

As always, constructive feedback is welcomed.

Tom

filler56789

29th November 2013, 21:16

Any GOOD reason why now the PDF is "secured" (i.e., Content Copying, Page Extraction and Commenting now are "not allowed")? :sly:

fumoffu

29th November 2013, 21:22

I have been looking in the preset changes in the code before you posted updated guide and noticed possible mistake.
by default bpyramid is being set to 2 while the only documented values are 0 and 1
param->bpyramid = 2
and all other presets are setting it back to 1 except slower, veryslow, placebo
if bpyramid 2 exists and does something to improve quality it's strange that default has it set to 2 but slow to 1

btw. default keyframeMin = 0 seems a bit low ;) is there some other mechanism that prevents too frequent I frames in fast changing images? is there a switch to change this like --min-keyint ?

Also if anyone knowledgeable is bored ;) and could explain what some of those options do I would be very happy:
--max-merge - what are we merging? I'm guessing partitions but I would love to know more how and when this works.
--early-skip - what are we skipping?
--fast-cbf - what does cbf stands for again?

x265.cc

29th November 2013, 21:50

what does cbf stands for again?

coded block flag

--early-skip - what are we skipping?

is Early skip detection for HEVC

http://phenix.it-sudparis.eu/jct/doc_end_user/documents/7_Geneva/wg11/JCTVC-G543-v3.zip could be useful for you

fumoffu

29th November 2013, 22:36

Thanks, l was wondering what is the difference between that and --tskip
Hopefully someday everything will be as nicely documented/explained as in X264 Settings - MeWiki :)

x265_Project

29th November 2013, 23:34

I have been looking in the preset changes in the code before you posted updated guide and noticed possible mistake.
by default bpyramid is being set to 2 while the only documented values are 0 and 1
param->bpyramid = 2
and all other presets are setting it back to 1 except slower, veryslow, placebo
if bpyramid 2 exists and does something to improve quality it's strange that default has it set to 2 but slow to 1

Good eye. It's my mistake (I wrote the patch to revise the defaults and preset values). I fixed this in the documentation but it needs to be fixed in the code. I've sent another patch to our development team to review and commit. Of course, since bpyramid is a logical value, any non-zero value is true, and so this bug is benign.

Tom

Procrastinating

30th November 2013, 06:06

The "16bpp" part only notes that the variables that keep the intermediate (and final) values are 16bit. The HEVC specification only specifies algorithms up to 14 bits, and the current HEVC profiles only support 8-10 bits. The encoding itself is 10 bits.

You are correct about it being very much slower than the 8bit version, of course ;)

So 16bpp output is storing 10-bit data in 16-bit variables? I'm guessing there isn't any redundancy/that x264 also does something similar?
Leading on from that, obviously it's much slower, but is it more space-efficient than 8bpp? Or rather, is there any reason to test/compare 16bpp/10-bit to 8bpp at this stage?

I plan on comparing some anime credits, so I want to make sure I am making fair comparisons to default/fan-tuned encodes(8-bit vs 8-bit, or 10-bit vs 10-bit, or all vs all). Just looking through different ones at the moment to find problem-cases(difficult to compress but not because of noise)

LoRd_MuldeR

30th November 2013, 13:52

So 16bpp output is storing 10-bit data in 16-bit variables? I'm guessing there isn't any redundancy/that x264 also does something similar?

The smallest addressable unit of memory (aka "Byte") is 8-Bit on pretty much any modern computer. So if you store a value in memory, you need to use at least one byte (8-Bit). Even booleans usually take one byte! But if the data is bigger than one byte, you will need to use two bytes (16-Bit) to store the value - even if the value is only 10, 12 or 14 bits in size. The "unused" bits will usually be padded with zero's. For values bigger than 16-Bit you'd use 24-Bit or even 32-Bit. And so on...

Surely, one could "pack", for example, 4 values à 10-Bit into 5 consecutive bytes, in order to eliminate that overhead. But then these values won't be addressable directly anymore. You would need to use some bit-operation magic to store/read your values, which usually is too complex and too slow. So, most of the time, you simply accept the overhead of storing a 10-Bit (12-Bit, 14-Bit) value in a 16-Bit variable.

x265_Project

30th November 2013, 22:18

The smallest addressable unit of memory (aka "Byte") is 8-Bit on pretty much any modern computer. So if you store a value in memory, you need to use at least one byte (8-Bit). Even booleans usually take one byte! But if the data is bigger than one byte, you will need to use two bytes (16-Bit) to store the value - even if the value is only 10, 12 or 14 bits in size. The "unused" bits will usually be padded with zero's. For values bigger than 16-Bit you'd use 24-Bit or even 32-Bit. And so on...

Surely, one could "pack", for example, 4 values à 10-Bit into 5 consecutive bytes, in order to eliminate that overhead. But then these values won't be addressable directly anymore. You would need to use some bit-operation magic to store/read your values, which usually is too complex and too slow. So, most of the time, you simply accept the overhead of storing a 10-Bit (12-Bit, 14-Bit) value in a 16-Bit variable.
This is a very good explanation. To this I would add that using the word "storing" (as procrastinating did in the original question) might be a bit misleading. Yes, we are storing these 10, 12 or 14 bit samples in 16 bit values, but only during the few milliseconds that we are processing those video samples in a CPU or GPU.

All modern video encoding standards use some form of lossless data compression (entropy encoding) which converts symbols into the final bitstream. HEVC uses context adaptive binary arithmetic coding (CABAC) to losslessly compress syntax elements to encoded bits. AVC uses CABAC or CAVLC. So, when the video is stored on a hard drive or other storage medium, we don't end up with all of those extra zeros padding the ends of our samples. But when we are encoding or decoding video, we need to process uncompressed video samples with standard CPUs or GPUs, and for this we need to move and perform operations on the uncompressed data in standard-sized units (data words). Computer processors can process data in 8 bit words, 16 bit words, 32 bit words, and for some 64 bits or larger. We can also process multiple words of data with a single instruction (this is called Single Instruction, Multiple Data, or SIMD), allowing us to pack eight 8-bit data words into a single 64 bit register, performing operations on all 8 of these data words with one instruction. When we are processing 10 bit video, we have to use 16 bit words to move and operate on these 10 bit values, and so we can only process half as many data words per clock cycle. This is why we see a big performance penalty the moment we start trying to process video that has more than 8 bits/sample. Once we switch over to using 16 bit words for every video sample, we will only move and operate on half as much data per clock cycle.

So, again... when stored in a video file, thanks to entropy encoding (CABAC, CAVLC, etc.), 10 bit/sample video is not twice the size of 8 bit/sample video. But when we are encoding, decoding or performing any intermediate processing (scaling, color space conversion, frame rate conversion, etc.) on 10 bit/sample video, we will see a big drop in performance on standard off-the-shelf CPU and GPU hardware (versus 8 bit/sample video). Of course, if you are designing an Application Specific Integrated Circuit (a hardware encoder/decoder/video processor), you can design it to operate on data of any width necessary, and so you aren't faced with the same limitation.

I hope this helps.

Tom

Procrastinating

1st December 2013, 13:38

Reading into that, I wonder if recent advancements in FPGA technology and openCL could allow for the development of cost effective ad hoc h265 encoders/decoders with the DSP capability of a software application.

x265_Project

2nd December 2013, 18:22

easyfab

2nd December 2013, 19:18

@x265_Project

If possible, can we have a more accurate SSIM number, 4 or 5 decimal places or perhaps add db like in x264 ?

x265_Project

2nd December 2013, 23:41

@x265_Project

If possible, can we have a more accurate SSIM number, 4 or 5 decimal places or perhaps add db like in x264 ?

My initial reaction is that this would be an easy change if it only involves the reporting of the number and not the calculation. I developed a similar patch (fixing the SSIM reporting in the log file) over the weekend.

diff -r 833d78aaf71e source/encoder/encoder.cpp
--- a/source/encoder/encoder.cpp Fri Nov 29 16:40:42 2013 +0530
+++ b/source/encoder/encoder.cpp Fri Nov 29 15:49:01 2013 -0800
@@ -570,7 +570,7 @@
else
fprintf(m_csvfpt, " -, -, -, -,");
if (param.bEnableSsim)
- fprintf(m_csvfpt, " %.2f,", stats.globalSsim);
+ fprintf(m_csvfpt, " %.3f,", stats.globalSsim);
else
fprintf(m_csvfpt, " -,");

Tom

easyfab

3rd December 2013, 08:58

Thanks Tom, that's what I want.

For info are there several possible calculations ? It's a standard formula, right ?

mandarinka

3rd December 2013, 09:12

For comparing different encoders, you should probably use a standalone tool.
For example x264 IIRC did some shortcuts (not deblocking non-reference Bframes or something like that) during the calculations, and it is possible x265 does it similarly. Using a standalone tool in any case gets rid of such variances.

fumoffu

3rd December 2013, 22:12

I was wondering, are there any plans for adjustable deblock strength and threshold like in x264?

x265_Project

3rd December 2013, 22:51

Release Notes...

x265 0.6 is a regularly scheduled release

There were large improvements in compression efficiency since 0.5, mostly a result of the completion of weightp and b-pyramid. There is also a large amount of new assembly code; replacing most of the compiler intrinsic functions and adding coverage for some new primitives.

= New Features =
* CLI reads input video from stdin
* Main10 profile is enabled, requires a HIGH_BIT_DEPTH build
* weightp is now complete enough to be enabled by default
* performance presets have been defined, matching x264 preset names
* b-pyramid (hierarchical B frames) now supported
* Constant Rate Factor rate control is considered stable
* Adaptive Quantization introduced (experimental)

Adaptive Quantization is still considered experimental. We are not always seeing the expected improvements to SSIM when it is enabled, and thus it is still not enabled by default.

= API Changes =
* x265_nal data members renamed
* x265_picture now has colorSpace member
* --weightp enabled by default
* default parameters now match our medium preset
* new x265_param_default_preset() method for assigning preset and tune
* new x265_param_alloc() and x265_param_free() methods for version safety
* new x265_picture_alloc() and x265_picture_free() methods for version safety

The public data structures have changed enough that apps compiled against previous versions of x265 must be recompiled to use x265 0.6. We are taking steps to add version safety to the public interface. If you use the new alloc/free methods for the param and picture structures, and use x265_param_parse() to set param values by name, you will likely not have to recompile your application to dynamically link against later releases of x265.

= New Command Options =
* --y4m overrides detection of Y4M input stream, ex: x265 --y4m - out.hevc < vid.y4m
* --version long option alias for -V
* -p/--preset sets performance preset
* -t/--tune sets parameter tuning
* --[no-]b-pyramid enabled by default
* --input-csp color space parameter, only i420 is supported in this release
* --crf constant rate factor rate control
* --aq-mode and --aq-strength

See x265 --help for more details

= Upcoming improvements =
* motion compensated weightp analysis (using lookahead data)
* CU-tree (MBtree adapted from x264)
* VBV rate control
* assembly for HIGH_BIT_DEPTH builds

foxyshadis

3rd December 2013, 23:43

x265_Project

4th December 2013, 01:09

Now this is good news. The rate of change has been incredible over the past few months, especially in getting assembly written, and I've seen the patches coming for CUtree already. Great work! I'll probably take this and see how it performs on a real video soon.

Thanks Foxyshadis. The development team has definitely ramped up to a good pace, and we're very pleased with the results of their hard work. Still lots more work to do, but I think we're on track.

Tom

fumoffu

4th December 2013, 03:28

btw. 0.6 Release Notes, since it hasn't been mentioned:
--rd can now have values from 1 to 6 (previous value 2 is now 5,6)

from my tests Adaptive Quantization works correctly with rd>=4

benwaggoner

4th December 2013, 12:55

Release Notes...

x265 0.6 is a regularly scheduled release

* Adaptive Quantization introduced (experimental)

Adaptive Quantization is still considered experimental. We are not always seeing the expected improvements to SSIM when it is enabled, and thus it is still not enabled by default.
If your AQ is based on the one from x264, it is considerably more advanced and subjectively correlated than SSIM. If it is on, you will probably see a bigger gap between SSIM and PSNR. But the only really relevant way to check is subjective comparison.

From my experimenting in the last couple of weeks, it did seem to provide a significant visual improvement, although I wasn't doing comprehensive testing.

LigH

4th December 2013, 13:05

SSIM is not able to measure a subjective improvement. So don't be sad about not getting a perfect similarity based on a technical metric; the metric will be the less reliable value, compared to an ABX test with hundreds of probands.

sneaker_ger

4th December 2013, 15:10

I'm having some difficulty using x265. I tried a 10 Bit encode using a build from x265.cc (64bit, 16bpp, 1d2d60f4eb81, mingw). Here's the command-line I used:
x265 - --input-res 1920x800 --fps 24000/1001 --input-depth 10 --crf 18 --aq-mode 1 -o test2.h265 --preset slow
Sample (http://www.file-upload.net/download-8363232/test2.h265.html), log (http://pastebin.com/EadP16si)

1. I can't mux it using either l-smash or mp4box. Both suspect corruption.
2. It came out at only ~11 Mbytes for 2684 frames with horrible quality. I know I can decrease --crf further but is this really the quality expected for crf 18?
3. The log says "yuv [info]: 1920x800 24000Hz[...]". Should I have used "23.976" instead of "24000/1001"?

Kurtnoise

4th December 2013, 15:25

1. I can't mux it using either l-smash or mp4box. Both suspect corruption.
With mp4box : you have to use either the hevc/hvc/265 file extension or add :FMT=HEVC to your command line

So, either
mp4box -add input.hevc output.mp4

or
mp4box -add input.h265:FMT=HEVC output.mp4

sneaker_ger

4th December 2013, 15:32

Thx, that does indeed fix 1.

fumoffu

4th December 2013, 19:23

2. It came out at only ~11 Mbytes for 2684 frames with horrible quality. I know I can decrease --crf further but is this really the quality expected for crf 18?
3. The log says "yuv [info]: 1920x800 24000Hz[...]". Should I have used "23.976" instead of "24000/1001"?

I'm pretty sure those 2 are related, if x265 thinks the video is meant to be played at 24000fps ;-) it compresses the motion much, much, much more than usually so everything looks like crap if you play this at only 23.976...

sneaker_ger

4th December 2013, 19:32

I will test but it sounds reasonable. Totally blind to not notice 24000 != 24.000. Now when using "--fps 23.976" the log says "23Hz". Wondering if it just clips the log or if the output might be wrong (if there a timings in the raw stream at all).

Kurosu

4th December 2013, 19:38

--max-merge - what are we merging? I'm guessing partitions but I would love to know more how and when this works.
Partitions marked as merge will copy a neighbour partition motion as is (including one scaled from collocated block in another frame). The different potential motions are index in a specific order. Basically, this is a mean to declare an area that has the same motion.

--early-skip - what are we skipping?
Probably a fast termination of the best partitioning/search if the best encoded mode for the CU is skip (akin to merged 2Nx2N partition without residual)

--fast-cbf - what does cbf stands for again?
Coded block flag - whether there was residual in a transform block. I guess this is a fast decision, ie no need to test smaller transform sizes if there are already a lot of not-coded transform blocks.

Sagittaire

4th December 2013, 20:22

Well I test actualy this 0.6 build and optimistation (speed and quality) are simply terrific in few month. H264 is simply surpassed and by far. I test codec since 2003 and I use always the same trailer for that. x265 produce same output quality for psnr than H264 mainconcept codec at half bitrate. x265 is actualy not able to produce the same quality output for psnr than x264 10 bit in placebo mode at half bitrate. Anyway it's only the 0.6 version for x265 ... :eek:

In all my test with this trailer x264 10 bit in placebo mode is never able to produce the same quality output than MPEG4 ASP (XviD or DivX) at half bitrate. H265 is certainely the most advanced evolution (in codec generation comparison) that I have never see for new codec (and I test some codec since more 10 years) ... :eek:

James Freeman

4th December 2013, 20:56

x265 is actualy not able to produce the same quality output for psnr than x264 10 bit in placeb mode.

Can you please re-say that?
Do you mean x264 is still better than x265, at higher qualities?

easyfab

4th December 2013, 20:57

x265 is actualy not able to produce the same quality output for psnr than x264 10 bit in placeb mode.

At the same bitrate or half bitrate ?

Sagittaire

4th December 2013, 21:01

At the same bitrate or half bitrate ?
half bitrate ... I make correction ...

fumoffu

4th December 2013, 21:01

@Kurosu - thanks for explanations!

I will test but it sounds reasonable. Totally blind to not notice 24000 != 24.000. Now when using "--fps 23.976" the log says "23Hz". Wondering if it just clips the log or if the output might be wrong (if there a timings in the raw stream at all).

AFAIK there are no timings in raw stream, and the fps count is only used to tweak compression. With this in mind those decimal places aren't even important as there isn't that much of a difference. Few days ago I accidentally used 29.97fps to encode 23.976 clip and after muxing to mkv (with correct fps value) I couldn't even tell that it was encoded with faster fps.

easyfab

4th December 2013, 21:15

Sagittaire

4th December 2013, 21:19

Can you please re-say that?
Do you mean x264 is still better than x265, at higher qualities?

No. x265 produce in my test quality between H264 Mainconcept (slowest mode) and x264 10 bits (placebo mode) at half bitrate. I have simply never see this difference bettwen previous and next generation codec ... :D

James Freeman

4th December 2013, 21:31

No. x265 produce in my test quality between H264 Mainconcept (slowest mode) and x264 10 bits (placebo mode) at half bitrate. I have simply never see this difference bettwen previous and next generation codec ... :D

That's great. :cool:

Can't wait till this implemented commercially world wide, especially for the new Blu-Ray standard.

sneaker_ger

4th December 2013, 21:36

AFAIK there are no timings in raw stream, and the fps count is only used to tweak compression. With this in mind those decimal places aren't even important as there isn't that much of a difference. Few days ago I accidentally used 29.97fps to encode 23.976 clip and after muxing to mkv (with correct fps value) I couldn't even tell that it was encoded with faster fps.
H.264 had timings and frame rate mode in the stream which could break some players or specs if not set exactly correct, that's why I'm asking.

I did test with --fps 23.976 now and bitrate was raised by ~60% at the same crf though it looked worse than the crf 18 I was used to from x264. For fun I made an x264 10 Bit encode with 2pass and preset veryslow at the same bitrate and the x265 one looked more pleasing. Artifacts were a lot less pronounced/visible, though it may have come out blurrier overall so the result might be different for decent bitrates or pre-filtering. Looking forward to the further development.

Beelzebubu

4th December 2013, 22:01

I also notice that even if a frame looks worse encoded by x265 than x264 (when comparing frame by frame ), when playing the video is much more pleasant for x265 encoded videos.
There must be some temporal filter or some noise processing in HEVC and not for AVC ?

This is likely because of the bigger block sizes. What sometimes happens with older codecs (e.g. h264) is that neighbouring blocks with virtually identical motion will get slightly different motion vectors (1 qpel value different, for example), because the RD doesn't take block edge artifacts into account. In new codecs (e.g. hevc), it will choose a bigger block size, which therefore gets a uniform motion vector, and thus the artifacts at block edges disappear.

Procrastinating

5th December 2013, 06:29

Because of the more accurate motion prediction of h265, I wonder if pseudo-slowmo won't look as awful now.

xooyoozoo

5th December 2013, 08:07

Adaptive Quantization is still considered experimental. We are not always seeing the expected improvements to SSIM when it is enabled, and thus it is still not enabled by default.

I've been testing AQ on still images because it's quick and *SSIM is still a spatial metric, and I also assumed it was reasonable that changes in Intra results would represent changes in the rest of a clip. Here, 5-20% bdrate improvements versus HM12 on MS-SSIM seems normal.

Just did an actual short clip, and x265+AQ scored worse than HM12, in contrast to what both a set of single-frame encodes and visual inspection of mid-clip snaps (http://i.imgur.com/eKd71Bp.png) demonstrate. ¯\_(ツ)_/¯

x265_Project

5th December 2013, 08:17

I've been testing AQ on still images because it's quick and *SSIM is still a spatial metric, and I also assumed it was reasonable that changes in Intra results would represent changes in the rest of a clip. Here, 5-20% bdrate improvements versus HM12 on MS-SSIM seems normal.

Just did an actual short clip, and x265+AQ scored worse than HM12, in contrast to what both a set of single-frame encodes and visual inspection of mid-clip snaps (http://i.imgur.com/eKd71Bp.png) demonstrate. ¯\_(ツ)_/¯

Interesting! Thanks for sharing.

LigH

5th December 2013, 08:27

Now when using "--fps 23.976" the log says "23Hz".

It still does? I don't even remember when I reported this missing precision... during v0.3?

sneaker_ger

5th December 2013, 10:25

I revisited the --crf encodes today and compared 10 Bit to 8 Bit encoding and the 10 Bit crf feature really looks to be far off/have a different scale.

Kurosu

5th December 2013, 10:34

visual inspection of mid-clip snaps (http://i.imgur.com/eKd71Bp.png) demonstrate. ¯\_(ツ)_/¯

Visual inspection of that snap shows me a vast superiority of x265+AQ over HM12 to my eyes: the HM12 is a blurry mess (tree, grass, sky). And the parts where it is a lot more blurry have less motion, so one may notice that more easily.

Procrastinating

5th December 2013, 12:02

Just did an actual short clip, and x265+AQ scored worse than HM12
As kurosu said, did you look at those pictures? HM12 looks awful in comparison on just about every noticeable front.

sneaker_ger

5th December 2013, 16:44

It still does? I don't even remember when I reported this missing precision... during v0.3?

Fractional rates seem to be on the to-do list at least.

https://bitbucket.org/multicoreware/x265/wiki/TODO

foxyshadis

6th December 2013, 01:02

I revisited the --crf encodes today and compared 10 Bit to 8 Bit encoding and the 10 Bit crf feature really looks to be far off/have a different scale.

In AVC & HEVC, every extra bit of depth bumps the quant scale up by 6, so 10-bit is +12. 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. If you normally use 10, you have to use -2. (Yup, negative crf is allowed.)

I have no idea why they chose that method.

Procrastinating

6th December 2013, 09:14

I may be missing something here, but can x265 input yuv420p10le color space? Otherwise in what format should the 10-bit YUV/Y4M be? Or am I really missing something here and x265 cannot yet input 10-bit video?

x265 crashes with the error "header missing" on a yuv420p10le .y4m when using --input-depth 10 (displays no error and just crashes on --input-depth 8)
and displays the processing of the first frame before crashing when providing the parameters and using a raw .yuv
The YUV's and Y4M's were processed with FFMPEG using the rawvideo yuv420p10le and yuv4mpegpipe formats respectively.
For the record, x264 processes these raw inputs fine.

Similarly, what is the best way for outputting x265 compatible 10-bit y4m through ffmpeg?

easyfab

6th December 2013, 09:30

for raw 10-bit .yuv it's ok for me with --input-depth 10 --input-csp i420 --input-res ***x*** --fps ***
But from ffmpeg with : -pix_fmt yuv420p10le -f yuv4mpegpipe it doesn't work

Selur

6th December 2013, 09:31

yuv420p10le through ffmpeg works fine here,...
ffmpeg -v -10 -i "H:\TestClips&Co\test.avi" -an -sn -threads 8 -vsync 0 -r 25 -pix_fmt yuv420p10le -f rawvideo - | x265-16bit --input - --input-depth 10 --input-res 640x352 --fps 25 --frames 429 --b-adapt 2 --rd 0 --no-signhide --output "H:\TESTCL~1\test_09_26_58_7410_01.265"
when using y4m with ffmpeg you simply need to exchange '-f rawvideo' with '-f y4m' iirc.

easyfab

6th December 2013, 09:35

Selur,

You're right with -f rawvideo it's ok so it's only -f yuv4mpegpipe that doesn't work for me.

sneaker_ger

6th December 2013, 09:38

Yes, raw 10 bit worked fine here, too. What doesn't seem to work is 10 Bit data with an y4m header (which x264 does support).

Selur

6th December 2013, 09:48

Does anybody know why:
mencoder -lavdopts threads=8 -of rawvideo -o - -ovc raw -demuxer lavf -noskip -vf scale,format=i420,scale,format=420p10le -forcedsubsonly -nosub -nosound -mc 0 "H:\TESTCL~1\test.avi"
fails, due to the decoding part:
mencoder -lavdopts threads=8 -of rawvideo -o - -ovc raw -demuxer lavf -noskip -vf scale,format=i420,scale,format=420p10le -forcedsubsonly -nosub -nosound -mc 0 "H:\TESTCL~1\test.avi"
which fails with:
MEncoder SVN-r36521-4.8.2 (C) 2000-2013 MPlayer Team
success: format: 0 data: 0x0 - 0x1c2c9e
libavformat version 55.21.102 (internal)
libavformat file format detected.
[lavf] stream 0: video (mpeg4), -vid 0
[lavf] stream 1: audio (mp3), -aid 0
VIDEO: [MP4V] 640x352 24bpp 25.000 fps 0.0 kbps ( 0.0 kbyte/s)
[V] filefmt:35 fourcc:0x5634504D size:640x352 fps:25.000 ftime:=0.0400
Writing to stdout
Opening video filter: [expand osd=1]
Expand: -1 x -1, -1 ; -1, osd: 1, aspect: 0.000000, round: 1
Opening video filter: [format fmt=420p10le]
Opening video filter: [scale]
Opening video filter: [format fmt=i420]
Opening video filter: [scale]
==========================================================================
Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family
libavcodec version 55.44.100 (internal)
Selected video codec: [ffodivx] vfm: ffmpeg (FFmpeg MPEG-4)
==========================================================================
The selected video_out device is incompatible with this codec.
Try appending the scale filter to your filter list,
e.g. -vf spp,scale instead of -vf spp.

Exiting...
-> Did I miss something, doesn't '-of rawvideo -ovc raw' support 420p10le as output?

Cu Selur

qyot27

6th December 2013, 16:28

I mentioned the fact that x265 doesn't support FFmpeg's extended y4m format back on page 4 (http://forum.doom9.org/showthread.php?p=1653130#post1653130). The situation is that those extensions are purely on FFmpeg's side (libav doesn't support them), not from MJPEGTools, and the argument that it's an unofficial extension to Y4M (no matter that x264 and VapourSynth both use it) is probably why it's been overlooked. Or it might not have such ulterior motives and merely be an honest mistake of omission. Without an actual explanation, all there is is conjecture.

-> Did I miss something, doesn't '-of rawvideo -ovc raw' support 420p10le as output?
My guess: mencoder simply doesn't support it because it has to be specifically modified to do so, which is unlikely because of how badly unmaintained it is. A year ago, I'd done some fiddling in mpv to add support for the 12-bit and 14-bit outputs, and it required going in and adding a bunch of IDs to the pixel format lists specifically so it could see them (this is no longer how it works in mpv, so all those pixfmts are handled automatically now, but what I just described is highly likely to be how mencoder handles it - the 'old way' is probably from the legacy mplayer codebase that mencoder is derived from, but possibly even older than mplayer-svn's current method of handling it might be).

fumoffu

7th December 2013, 01:43

I have a problem with x265 - it blurs delicate skin textures way too much.
(If there is a strong texture it preserves it and other strong details are well preserved too but those more delicate textures are just becoming flat).
I tried almost every possible setting and I didn't find anything that makes much difference. Setting aq strength to 2 increases bitrate very much for very small visual improvement. The weird thing is that increasing crf/bitrate doesn't help much either.
(I also tried: no-sao, no lft, subme 7, b-adapt 0-2, rd 4-5 and cbqpoffs/crqpoff)
The reason I'm mentioning it is I tested divx encoder today with the same bitrate and it did much better. In the past I also played with Strongene encoder and from what I remember it didn't had this problem until really low bitrates.
Of course I'm not writing this to argue that DivxHEVC is better - devs are doing great job with x265 and I'm a fan ;) Just wanted to point out that there might be a problem with something.

Example: original/divx and x265 at around 2500kbps
http://i.imgur.com/74WD2B2.png http://i.imgur.com/1J1h0Wo.png http://i.imgur.com/oBL7kZX.png

Or maybe I'm doing something wrong? Maybe it's color space conversion issue or something?
I have been just encoding with command like this:

ffmpeg.exe -i test.mp4 -an -f yuv4mpegpipe - | x265 --y4m --input-res 1280x720
--fps 29.97 --merange 32 --no-progress --crf 20 - -o test.hevc

and optionally adding other stuff like --rd 4 --aq-mode 1 --aq-strength 1.8 or other switches..

edit:
I've done some more test and:
-x265 @4000kbps still looked worse than DivxHevc (@2500kbps) and worse than x264 @4000kbps (preset slow with some tweaks)
-x265 @4000kbps +aq-strength 1.8 - better, similar to DivxHevc (@2500kbps)

Procrastinating

7th December 2013, 09:26

None of the various 10-bit sources I have seem to work with x265, even after converting to YUV, and even on default parameters. Could someone upload a short 10-bit .yuv/source which worked for them?
x265 crashes immediately after beginning the processing for the first frame, not even a log is produced with --log 3 and --csv enabled.

Tried both 32 and 64 bit 16bpp 0.6+83-a482cf5de173 MinGW builds. I'm using Win8 64-bit i5 3570, but I find it hard to believe that my system is causing it to crash.

sneaker_ger

7th December 2013, 09:59

It can't have anything to do with the source since we are talking about raw data. Even if you use a wrong one it should produce (syntactically correct) garbage at worst. Did you try the VC builds?

https://x265.cc/

filler56789

7th December 2013, 12:16

Over here, crashes happen only if I try to use other --input-csps than i420.

x265_Project

7th December 2013, 22:51

The developer team is working on a bug that is causing builds from the default branch (development tip) to crash. The stable branch is not affected.

x265.cc

8th December 2013, 00:01

The stable branch is not affected.

..and the stable version is just a development version flagged as stable.

So if somebody want to get this version, build it yourself or simply check out which development version (https://bitbucket.org/multicoreware/x265/commits/all) has been flagged as stable, and download it at the buildbot site.

zerowalker

8th December 2013, 02:18

No. x265 produce in my test quality between H264 Mainconcept (slowest mode) and x264 10 bits (placebo mode) at half bitrate. I have simply never see this difference bettwen previous and next generation codec ... :D

I don´t quite get what you mean.

Are you saying that x265 produces something in the middle of the 2 (h264 slowest, x264 10bit placebo) but at half the bitrate compare to those 2?

Meaning x264 10bit 5k bitrate will look a little bit better than 2.5k bitrate x265, but increasing the bitrate a bit will make it better?

Procrastinating

8th December 2013, 08:46

So if somebody want to get this version, build it yourself or simply check out which development version (https://bitbucket.org/multicoreware/x265/commits/all) has been flagged as stable, and download it at the buildbot site.

It seems that none of the (two) 0.6 "stable" builds are available on the buildbot site, and neither are several previous commits, which is a shame. I guess I'll wait it out to see if the crash they are describing is also the crash I am encountering. I have tried all variations of the latest build and the 64bit 16bpp mingw builds of several earlier builds, and they all either crash immediately after entering the parameters, or on processing the first frame (ie [0.1%] 1/1684 frames...)

x265.cc

8th December 2013, 14:45

It seems that none of the (two) 0.6 "stable" builds are available on the buildbot site

use the "x265_0.6+3-55c0bf9d9966.zip" version, it should mostly be this what the call "stable".

I have tried all variations of the latest build and the 64bit 16bpp mingw builds of several earlier builds, and they all either crash immediately after entering the parameters, or on processing the first frame (ie [0.1%] 1/1684 frames...)

The 8bpp builds don't crash for me. (low res source, ffmpeg pipe, medium preset)

qyot27

8th December 2013, 18:50

The only crashes (more precisely, segfaults that I haven't had time to run through gdb) I've experienced where/are when using certain presets. At one point a couple weeks ago it was there on the default preset and the ones higher than it (but not ultrafast), a couple days ago when I tried it only happened when I tried using placebo; veryslow was unaffected. So what trips it is probably some option that got moved around in the preset reshuffling.

I have no idea if this is related to the ones described above, though. This was on OSX 10.7¹, as I've not attempted it on Linux or Windows². The video was 848x480, 23.976fps, 4:2:0, as a standalone y4m file.

¹and thereby, whatever version of Clang that Xcode is using, I can't remember at the moment

²which use GCC 4.8 for both - .1 and .2, respectively

Procrastinating

9th December 2013, 10:49

That particular x265 build seems to have been stable enough! Videos are encoding fine now :|

It seems that with 1080p anime, on untuned placebo settings, 10-bit x265 is ~ 2-4 times more efficient than 10-bit x264. You start to see diminishing returns in terms of artifacts:size above 10bit CRF 24, though the artifacts look "nicer".

Unfortunately it also takes ~3-5 times longer to encode. My one-minute dialogue+action sample took ~30 minutes to encode with placebo 10bit on x264, vs 2 hours with x265, though higher CRF values cut that time by 15 minutes or so.

Not all tuning parameters are equal however, and x265 still has plenty of room for optimization.

I'll probably make a couple different comparisons at low and high presets as well as tuning over the course of this week, and maybe create some actual statistics.

Nevertheless, the results so far have been pretty phenomenal. I would imagine that once fansub groups get the hang of tuning this, any anime distribution service which holds back on h265, let alone 10bit could be hurting themselves pretty badly. On the flipside, if streaming services do implement h265, I think internet video could become an undeniably better source of video compared to TV (This could also make fancode groups redundant).

I think the biggest shift that this could make however is in live streaming. If faster presets enable significant gains in realtime quality, we could see a marked improvement in streaming quality across the board on sites like twitch over the next year or so.

zerowalker

9th December 2013, 12:18

What settings do you use, just placebo on both?
When i try HEVC , x264 wins by quite a bit even though HEVC take alot more time.

I wasn´t confused as i know that x264 has been optimized for years, but if you say it´s 2-4 time more efficient, i am starting to wonder.
Though i haven´t tried 10bit, 8bit should be pretty much the same if i compare the two.

Atak_Snajpera

9th December 2013, 17:18

On real very detailed footage x264 easily beats x265.

x264 8 bit rev 2345
x265 8 bit rev 0.6+89-55d99b6651f2 (UTC 11:21:27 AM) from https://x265.cc/

Sample: park_joy_1080p50.y4m (http://media.xiph.org/video/derf/)
x264 --preset veryslow --crf 32.4
https://mega.co.nz/#!9Z9C0JLZ!Y7GcCgWMehUgezvJhXb_qX6FIKRYrp2AEhxsm6s-6xQ
AVERAGE BITRATE: 6757 kbps

x265 --preset medium --crf 28 (default value) --fps 50
https://mega.co.nz/#!wE0SyRhA!RcDCBnXnEwvZCxbDymM9FxIzwCZ36Qs14vt3Rqrviyg
AVERAGE BITRATE: 6821 kbps

Use latest mpc-hc to play raw .265 files

Encoding time on Q6600@3Ghz
x264 : 2m:45s
x265 : 10m:03s

Screenshots
x264 -> http://s17.postimg.org/4r8nvo0wv/park_joy_1080p50_mkv_160.png
x265 -> http://s17.postimg.org/cy0nn8qzj/park_joy_1080p50_265_160.png

Sample: crowd_run_1080p50.y4m (http://media.xiph.org/video/derf/)
x264 --preset veryslow --crf 31.32
https://mega.co.nz/#!9EsDBbKS!DlWsrS3Net8Vt9MjZzSaJhvhJ3UhtKFLQ4HpUDriavA
AVERAGE BITRATE: 7049 kbps

x265 --preset medium --crf 28 (default value) --fps 50
https://mega.co.nz/#!RUc0QSpC!JY5mH3bALvcifyuo_uSC-hzIudNFGpPiPVi42PRN1Ro
AVERAGE BITRATE: 7047 kbps

Use latest mpc-hc to play raw .265 files

Encoding time on Q6600@3Ghz
x264 : 2m:50s
x265 : 10m:28s

Screenshots
x264 -> http://s17.postimg.org/nqcieh40v/crowd_run_1080p50_mkv_160.png
x265 -> http://s17.postimg.org/mzjs8p1nj/crowd_run_1080p50_265_160.png

benwaggoner

9th December 2013, 18:41

It seems that with 1080p anime, on untuned placebo settings, 10-bit x265 is ~ 2-4 times more efficient than 10-bit x264. You start to see diminishing returns in terms of artifacts:size above 10bit CRF 24, though the artifacts look "nicer".
Are you comparing without any --tune parameter in x264 as well? Even if so, that's still a dramatic delta!

Unfortunately it also takes ~3-5 times longer to encode. My one-minute dialogue+action sample took ~30 minutes to encode with placebo 10bit on x264, vs 2 hours with x265, though higher CRF values cut that time by 15 minutes or so.
There's lots of optimization still be done for 10-bit I believe. Compared to the speed of the reference encoders a year ago, only 3-5 slower is pretty tremendous. I've heard some codec engineers estimate that at equivalent levels of exhaustiveness*, H.265 would be about 3-5 times slower than H.264. It sounds like we'll likely wind up with a smaller gap than that.

* I guess you could think of this as a setting that's a certain percentage below the maximum possible placebo encode.

On the flipside, if streaming services do implement h265, I think internet video could become an undeniably better source of video compared to TV (This could also make fancode groups redundant).
I'll take my 1080p AIV encodes over against anything Comcast delivers for Anime by a HUGE margin already :)!

I think the biggest shift that this could make however is in live streaming. If faster presets enable significant gains in realtime quality, we could see a marked improvement in streaming quality across the board on sites like twitch over the next year or so.
I don't know that we can expect broad support for HEVC decode in most web clients in 2014. I can't think of any clients/players/platforms/browsers other than VLC that has even announced HEVC support yet.

Silicon is certainly coming for CE devices, though. And software decode of WPP HEVC on a multicore system will be more performant than single-slice H.264 decode.

fumoffu

9th December 2013, 18:41

On real very detailed footage x264 easily beats x265.

Yes, this is rather worrying. Can some bug in the code cause this? Or is it rather lack of certain x264 features not yet implemented in x265?
In my earlier post I was complaining that x265 seems to be destroying delicate details and blurs everything a bit. I'm surprised that in your test even "rough" and detailed part of the image like trees look ugly and smeared :/

Atak_Snajpera

9th December 2013, 18:50

Files created by x265 remind me WMV3/9 ;) Ultra slow encoding and everything smeared.

x265_Project

9th December 2013, 19:21

The Dev team just pushed a bug fix to the development tip. This fixes the crash that some of you were seeing.

Tom

x265.cc

9th December 2013, 21:09

The Dev team just pushed a bug fix to the development tip.

And it also got the "stable" tag.

Sagittaire

9th December 2013, 23:02

Files created by x265 remind me WMV3/9 ;) Ultra slow encoding and everything smeared.

No it's simply that you compare x264 and x265 for extreme sample example. New H265 functionality are certainely simply useless for these really complexe sample. Moreover x264 is really highly optimized for these really complexe content. Certainely that psy, AQ, mbtree or trellis will really help for x265.

foxyshadis

9th December 2013, 23:27

x264 had the same blurring problem before AQ, as well; that was the entire impetus to create it. It's just one of those things we have to wait for a final implementation of.

MythCreator

10th December 2013, 04:26

There is a strange situation

AVS:
LWLibavVideoSource("00002.m2ts")

avs2yuv "test.avs" -o "test.yuv"

x265 --input-res 1280x720 --input-csp i420 --fps 23.976 --no-lft --crf 18 --input "test.yuv" -o "test.265"

It's crashed on 1st frame over and over again (I tried 32bit & 64bit, 8bpp & 16bpp), 0.6+3 & 0.6+111 and even a version of 0.5 but still get crash

In the other hand, When I use MeGUI to input an 1080p source, it also get an error, but works well when I simply resize it to lower resolution.

My system is Windows 8.1 Pro 64bit

Selur

10th December 2013, 16:17

@MythCreator: If you feed raw yuv input via pipe to x265 you also need to specify the number of frames to encode. (in example "--frames 429")

MythCreator

10th December 2013, 17:30

@Selur

C:\ffmpeg_64\ffmpeg.exe -i "E:\Downloads\STREAM\00002.m2ts" -pix_fmt yuv420p -an -f rawvideo - | E:\avs2yuv\x265_64_8bpp.exe --frames 35654 --input-csp i420 --input-res 1920x1080 --fps 23.976 --no-lft --crf 18 - -o "E:\Downloads\STREAM\test.265"

Still crash on 0.6+112 -_-

Selur

10th December 2013, 18:21

Uploaded versions I build using media-autobuild_suite (https://github.com/jb-alvarado/media-autobuild_suite) to my google share (https://drive.google.com/folderview?id=0B_WxUS1XGCPASUZibG5XZkRfeTg&usp=sharing), try if it works if you use these.

x265.cc

10th December 2013, 19:09

try if it works if you use these.

Have you added anything to the source / your binary?

If not, it will still not work.

C:\ffmpeg_64\ffmpeg.exe -i "E:\Downloads\STREAM\00002.m2ts" -pix_fmt yuv420p -an -f rawvideo - | E:\avs2yuv\x265_64_8bpp.exe --frames 35654 --input-csp i420 --input-res 1920x1080 --fps 23.976 --no-lft --crf 18 - -o "E:\Downloads\STREAM\test.265"

Try:

ffmpeg.exe -i {INPUT} -f yuv4mpegpipe -pix_fmt yuv420p - | x265.exe --y4m -o {OUTPUT} -

I recommend the latest "FFmpeg x64 static" build from zeranoe.com (http://ffmpeg.zeranoe.com/builds/) and the latest "x265 x64" build from x265.cc (https://x265.cc/builds/MSYS-x86_64/8bpp/x265_latest.zip)

MythCreator

11th December 2013, 12:42

@x265.cc

I tried it, and still crash... I think I'm gonna be crash (((

Atak_Snajpera

11th December 2013, 14:59

No it's simply that you compare x264 and x265 for extreme sample example. New H265 functionality are certainely simply useless for these really complexe sample. Moreover x264 is really highly optimized for these really complexe content. Certainely that psy, AQ, mbtree or trellis will really help for x265.

Is this also an extreme sample?
Original file -> http://www.diktafon.atw.hu/112.MTS

x265 (rev 110) --crf 28 --preset medium --aq-mode 1 --aq-strength 1 --fps 25
https://mega.co.nz/#!pBsEzAxQ!RMsqjjAyyyJQ_TH74kFNgEw2Tj953IWYVu__Xo9LDMg
AVERAGE BITRATE: 1948 kbps

x264 --crf 34.25 --preset veryslow
https://mega.co.nz/#!RN9xlaZB!aiRSSGtZIxFERVgmrtbc9RnJWn8Y1879BfCkTeBFc7s
AVERAGE BITRATE: 1972 kbps

Screenshots
x265
http://i.cubeupload.com/bb6tcp.png
http://i.cubeupload.com/8behZ6.png

x264
http://i.cubeupload.com/dfh31Y.png
http://i.cubeupload.com/I4XZl2.png

Sad thing is that x265 --preset medium is about 4x slower on my Q6600@3Ghz than x264 --preset veryslow :(

Sagittaire

11th December 2013, 15:06

Is this also an extreme sample?
Original file -> http://www.diktafon.atw.hu/112.MTS

Yes, all your sample are particular and extreme example (high detail level, high motion level). Try with real life example like complete movie or trailer (if you have no time) ... and see the result: you have in general case half bitrate for H265 for the same quality than H264.

Atak_Snajpera

11th December 2013, 15:24

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

vood007

11th December 2013, 15:39

x265 is in early stage of development, whats so hard to understand about this?

Atak_Snajpera

11th December 2013, 15:45

x265 is in early stage of development, whats so hard to understand about this?

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

x265_Project

11th December 2013, 17:37

We had a bug which only appeared on certain machines (causing x265 to crash immediately). x265 builds from the development tip were crashing on my system, but not crashing on our developers' systems. Debug builds weren't crashing. Fortunately, I was able to build a "release with debug info" build, and we were able to figure out where and why this was happening (in CU logging code). The development tip (default) build from this morning isn't crashing. So, if you were experiencing crashes in development builds, please try again with a new build (0.6 + 150).

I would encourage all technically savvy x265 adopters to help us find and isolate bugs in the same way. If x265 crashes on your system, create a Debug or Release with Debug Info build, run it under the same conditions that crashed before and when x265 crashes, copy and submit the call stack to the devel mailing list with your system configuration, x265 command line and input test sequence you are using.

Tom

benwaggoner

11th December 2013, 17:46

That's true and unfortunately useless for now. I doubt that in 2014 x265 will beat x264 in those "extreme samples" by 50%.
It's not supposed to be useful yet :). There aren't ANY mainstream players that can play HEVC so far.

Useful in the second half of 2014 would be tremendous, honestly.

Has anyone heard about any browsers, Flash, etcetera (anything other than VLC) that has announced HEVC playback support?

filler56789

11th December 2013, 18:01

Has anyone heard about any browsers, Flash, etcetera (anything other than VLC) that has announced HEVC playback support?

MPC-BE
LAV Filters
Strongene Lentoid HEVC Decoder
Osmo Player from GPAC

fumoffu

11th December 2013, 18:15

you forgot
MPC-HC
...and DivX player

benwaggoner

11th December 2013, 19:16

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

11th December 2013, 20:45

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

11th December 2013, 20:49

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

11th December 2013, 23:18

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

11th December 2013, 23:20

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

12th December 2013, 03:35

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

Atak_Snajpera

12th December 2013, 14:26

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

12th December 2013, 15:04

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

12th December 2013, 15:18

mandarinka

12th December 2013, 15:28

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

12th December 2013, 16:04

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

12th December 2013, 16:06

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

JEEB

12th December 2013, 17:25

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

12th December 2013, 18:59

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

12th December 2013, 20:26

xooyoozoo

12th December 2013, 20:53

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

12th December 2013, 23:22

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

13th December 2013, 02:01

James Freeman

13th December 2013, 12:54

what's HM12.1?

LigH

13th December 2013, 13:20

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

13th December 2013, 13:25

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

13th December 2013, 22:32

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

13th December 2013, 22:35

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

13th December 2013, 22:37

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

13th December 2013, 22:40

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

foxyshadis

14th December 2013, 00:53

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

14th December 2013, 02:39

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

14th December 2013, 07:32

Thanks everybody.

Procrastinating

14th December 2013, 11:11

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

14th December 2013, 17:06

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

14th December 2013, 17:55

sneaker_ger

14th December 2013, 17:59

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

14th December 2013, 18:03

Motenai Yoda

15th December 2013, 00:47

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

15th December 2013, 03:14

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

15th December 2013, 03:53

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

15th December 2013, 04:52

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

15th December 2013, 05:07

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

15th December 2013, 14:44

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

15th December 2013, 14:51

Selur

16th December 2013, 09:44

@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

16th December 2013, 10:28

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

LigH

16th December 2013, 11:05

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

16th December 2013, 16:52

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

16th December 2013, 18:18

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

16th December 2013, 21:52

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

16th December 2013, 22:23

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

17th December 2013, 00:06

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

17th December 2013, 12:21

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

17th December 2013, 12:35

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

Sm3n

17th December 2013, 17:53

You're right. Even if it's a little bit faster, it will be hard to tell how much it is.
I try to encode a 720p with -p veryslow... So slow!
Can we know which parameters correspond the preset veryslow? (and the other)

sneaker_ger

17th December 2013, 18:04

http://forum.doom9.org/showpost.php?p=1655923&postcount=213

Sm3n

17th December 2013, 19:44

http://forum.doom9.org/showpost.php?p=1655923&postcount=213

:goodpost: Thank you.

xooyoozoo

18th December 2013, 00:09

x265_Project

18th December 2013, 00:37

x264 and other AVC encoders don't fully utilize generalized-B-frames. I've never really thought about why, but I came across a paper (http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=6272183) from last year that suggests completely replacing P-frames with B-frames in H.264 is hit-&-miss in terms of efficiency improvements (http://i.imgur.com/ge03I7d.png).

That explains x264/AVC, as there's no point in spending engineering effort on something that only moves sideways. However, for HEVC, there's a clear and compelling compression benefit (http://i.imgur.com/7WptcmI.png)* to replacing P-frames in the bitstream.

I bring this up because I'm wondering if this is something x265 will support in the future? As far as these things go, blanket efficiency boosts by playing around with slice types sound like a rather low hanging fruit.

*HM-LP is similar to the first table's 'P,1+3', HM-LB similar to 'B1+3 l1=l0'

B frames are generally more efficient than P frames, but there is a tradeoff with respect to random access of the video (playback from any given position in the video stream). The longer your GOP structure and the more B frames you use, the more frames that you must decode before you can decode the frame you want to start playing (on average). P frames are dependent on a single previous I frame or P frame, and they generally reduce the number of frames that any random frame would be dependent on in order to be decoded, improving random access.

Tom

filler56789

18th December 2013, 00:39

I bring this up because I'm wondering if this is something x265 will support in the future?

Earlier versions of x265 would use only I- and B- frames IF
"b-frames = TRUE".
The Strongene Lentoid Decoder didn't like that very-much, though.

xooyoozoo

18th December 2013, 04:20

The longer your GOP structure and the more B frames you use, the more frames that you must decode before you can decode the frame you want to start playing (on average). P frames are dependent on a single previous I frame or P frame, and they generally reduce the number of frames that any random frame would be dependent on in order to be decoded, improving random access.

As evident in the Low Delay configs in the HM, B-frames (as defined in the spec rather than as defined in common usage) have been generalized so that they don't need to refer to any more frames than a P-frame would (because L1=L0). Consequently, random access or lack thereof would remain exactly the same, and the only difference now would be the inclusion of these new non-future-referencing B-frames that are effectively P-frames-with-extra-coding-tools.

The paper I linked to above suggested the JM (and maybe AVC in general) didn't benefit much from this change due to overhead in coding a B slice. However, I'm trying to point out that data suggests things could be different with HEVC, and that it's no longer necessary or beneficial for an encoder to strictly define a frame-that-only-references-past-frames as a P-frame.

x265_Project

18th December 2013, 06:11

As evident in the Low Delay configs in the HM, B-frames (as defined in the spec rather than as defined in common usage) have been generalized so that they don't need to refer to any more frames than a P-frame would (because L1=L0). Consequently, random access or lack thereof would remain exactly the same, and the only difference now would be the inclusion of these new non-future-referencing B-frames that are effectively P-frames-with-extra-coding-tools.

The paper I linked to above suggested the JM (and maybe AVC in general) didn't benefit much from this change due to overhead in coding a B slice. However, I'm trying to point out that data suggests things could be different with HEVC, and that it's no longer necessary or beneficial for an encoder to strictly define a frame-that-only-references-past-frames as a P-frame.
I'm sorry I misunderstood your question.

This is a good question. If it's beneficial, we'll definitely be interested in doing it. Until now we haven't had a chance to explore optimizations like this. I'll check with the development team.

Thanks
Tom

fumoffu

18th December 2013, 15:40

After the latest commits (0.6+204-09d...) CUtree is now enabled by default.
However I don't think its working quite right yet because crf values are way off (now crf 23 looks like crf 30 looked before), I didn't test bitrate mode yet. With aq enabled there might be some artifacts again, at least with --rd 4, hard to tell because my test encode turned out in pretty bad quality.
Anyways if anyone needs to disable it for now you can use: --no-cutree

x265_Project

18th December 2013, 16:38

We are in the process of enabling CUTree by default. But it's complicated at the moment, due to inter-dependencies between modes. We will clean this up in the coming days. If you're doing any critical work, use a build from the stable branch.

The current default setting in the repo is... --tune psnr (CUTree ON, AQ-strength zero, weightP ON).

--no-cutree turns both CUTree and AQ off

--tune ssim turns both CUTree and AQ on

Tom

Sm3n

19th December 2013, 00:27

Dunno if it's very relevant...

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

Comparisons: http://www.screenshotcomparison.com/comparison/53387/

There is some artefacts on dark scene. May be --tune ssim gives better results.

mandarinka

19th December 2013, 03:53

Is there any reason why --no-cutree disables AQ?
In x264 the two aren't tied together and IMHO that is how it should ideally be.

benwaggoner

19th December 2013, 18:06

There is some artefacts on dark scene. May be --tune ssim gives better results.
I think --aq-mode 1 gives --tune ssim and further psychovisual optimizations.

Sm3n

19th December 2013, 22:03

You think aq-mode enabled is a better choice?

benwaggoner

19th December 2013, 23:22

You think aq-mode enabled is a better choice?
I've not done very extensive testing on that, but it seems it is overall an improvement, certainly versus tuning for psnr. But the feature is still in development so I imagine there's content that would look worse with --aq-mode 1 versus --tune ssim.

Like all things x265, things may be different in a day or a week :).

fumoffu

20th December 2013, 00:36

I wonder if/when there is going be implemented something like trellis in x264.
x265 has tendencies to blur a bit too much so adding some sharpness would be nice.

x265_Project

20th December 2013, 02:28

Is there any reason why --no-cutree disables AQ?
In x264 the two aren't tied together and IMHO that is how it should ideally be.
A quick update...
Our internal testing is showing that turning CUTree and AQ on independently does not deliver a good improvement in visual quality at a given bitrate. We get the best results when CUTree and AQ are enabled in tandem. Development and testing of these features is ongoing.

Tom

Sm3n

20th December 2013, 17:31

CUTree is not enabled when --tune ssim is activated in --qp mode, only in --crf and --bitrate mode. Is that normal?

mandarinka

20th December 2013, 18:59

CUTree is not enabled when --tune ssim is activated in --qp mode, only in --crf and --bitrate mode. Is that normal?

Yeah, that would be expected - qp mode means constant quantizer, which is not reconcilable with CUTree which by definition changes quantizers.

Sagittaire

21st December 2013, 12:04

@ x265_project

read that:
http://forum.doom9.org/showthread.php?t=137117&highlight=ssd

x264 have major HVS improvement at this time.

Daemon404

21st December 2013, 20:40

Ran a few encodes last night.... seems x265 is still destroying luma. Chart here (http://chromashift.org/img/x265/20dec2013.png). Params I used here (http://chromashift.org/img/x265/params_20dec2013.txt). Encodes here (http://chromashift.org/img/x265/encoded_20dec2013.tar.xz). Lot of blur, lots of pop-ins.

Not very impressive yet... unless you can spot somewhere I've gone wrong in my settings.

James Freeman

22nd December 2013, 15:08

It appears H.265 has some fundamental flaws.
It softens the picture and destroys picture detail.

Can anyone tell me Why?
It seems too big of a flaw to actually use x265 for anything important.

LigH

22nd December 2013, 15:20

The fundamental flaw may be judging a technology with the target to compress UltraHD video to sane bitrates — using magnifiers, instead of sitting back in your sofa.

nevcairiel

22nd December 2013, 15:35

It appears H.265 has some fundamental flaws.
It softens the picture and destroys picture detail.

Can anyone tell me Why?
It seems too big of a flaw to actually use x265 for anything important.

You should not confuse H.265, the codec specification, with x265, an alpha-quality implementation with lots of work still to be done.

James Freeman

22nd December 2013, 15:49

The fundamental flaw may be judging a technology with the target to compress UltraHD video to sane bitrates — using magnifiers, instead of sitting back in your sofa.

Its like closing your eyes and pretending the problem isn't there.

x265 samples are fundamentally flawed when comparing to x264 samples.

You should not confuse H.265, the codec specification, with x265, an alpha-quality implementation with lots of work still to be done.

Right, sorry.

I hope this "Detail Destroying" alpha stage will be gone soon.

Any one tried to compress detailed video with x265 and x264 to the same bitrate and compare the two PQ-wise (no SSIM or PSNR stuff, but real visual inspection)?

LoRd_MuldeR

22nd December 2013, 15:49

It appears H.265 has some fundamental flaws.
It softens the picture and destroys picture detail.

Can anyone tell me Why?
It seems too big of a flaw to actually use x265 for anything important.

See also:
http://x264dev.multimedia.cx/archives/164

Yes, he's talking about H.264 encoders there, but the situation for H.265 encoders should be very similar: The standard gives you a bunch of "tools" to work with, but you need to figure out how to use/combine them in the best way.

BTW: Does x265 implement anything like x264's Psy-RDO/Trellis yet? If not, then it's not much of a surprise that it cannot keep up in detail retention with x264 right now. x264 wasn't that good in detail retention before Psy-RDO/Trellis either ;)

Also, isn't SOA (Sample adaptive offset) supposed to help with such things in H.265? Does x265 make use of SOA already?

mandarinka

22nd December 2013, 17:31

x265 does have SAO (inherited from HM probably?), but it doesn't have PsyRDO. The RDO features as such are also inherited from HM I think. About trellis I have no idea, but I think that quantization might be RDOed - in the slow modes that is, of course.

Daemon404

22nd December 2013, 18:04

Any one tried to compress detailed video with x265 and x264 to the same bitrate and compare the two PQ-wise (no SSIM or PSNR stuff, but real visual inspection)?

I've done a bunch, ranging from CIF to 4k, and my conclusion is the same as yours. This conclusion holds when I've tested against x264 with --no-psy as well.

I've also so noticed x265 exhibits very very bad keyframe pulsing. I know x265 doesnt have scene change detection yet, but that alone would not cause this.

Sagittaire

22nd December 2013, 20:25

x265 have exactly the same problem than x264 in his history: grain retention is bad. Anyway x264 solve that with FGO anf after with psy mode. x265 is in alpha mode: priority is at this time to obtain best possible metric. It's always like that for new codec.

Audionut

23rd December 2013, 05:03

People were saying the same thing about x264 vs xvid back in the day. Expectations should be lowered until x265 has a chance to mature.

xooyoozoo

24th December 2013, 05:06

Is there confirmation that CUTree is working as it should?

In the first 5 seconds of Pedestrian Area 1080p test clip, tested as a single GOP interval, I'm getting worse objective results at the frame and clip level when comparing --cutree against --no-cutree.

Daemon404

24th December 2013, 21:38

Dark Eiri

25th December 2013, 18:54

So, since it's working and producing valid streams, as inherited by HM base, the priority now is porting every single good thing x264 has that is also applicable to H.265 and might help the quality, right? Psy-RDO, mb-tree and all that stuff?

James Freeman

25th December 2013, 20:36

phate89

26th December 2013, 01:19

I am no programmer,
but I think the right way to do this is to retain the visual quality while reducing the bitrate.

NOT, reducing the bitrate and only then Fixing the resulting degradation.
That's just illogical, and defeating the whole purpose of what's called "efficiency" in a codec.
The missing detail in high complexity parts it's not because they are trying to lower the bitrate giving up some detail but because right now x265 encoder is not advanced enough to keep that detail at those bitrates with difficult stuff.
At start x265 it was hm code, able only to produce h265 standard compliant streams without great compression results to have a (working) starting point to test and improve.
Now they're "slowly" (it's a lot of stuff to do so it takes time) adding features that make the encoder smarter, helping to keep more detail at the same bitrate. They added only some of the advanced "features" that x264 have so x265 can easily win with the "easy" stuff but with the "hard" stuff (high content bitrate) it's obvious that x265 can't beat x264, it's too "stupid"...

Dark Eiri

26th December 2013, 06:13

The missing detail in high complexity parts it's not because they are trying to lower the bitrate giving up some detail but because right now x265 encoder is not advanced enough to keep that detail at those bitrates with difficult stuff.
At start x265 it was hm code, able only to produce h265 standard compliant streams without great compression results to have a (working) starting point to test and improve.
Now they're "slowly" (it's a lot of stuff to do so it takes time) adding features that make the encoder smarter, helping to keep more detail at the same bitrate. They added only some of the advanced "features" that x264 have so x265 can easily win with the "easy" stuff but with the "hard" stuff (high content bitrate) it's obvious that x265 can't beat x264, it's too "stupid"...

Is it hard to port all the x264 "smart-stuff" to x265? :(

I get really excited about this since I took knowledge of x264 when it was already very nice, but I saw it getting better and better with the efforts and ideas of all the developers around here and it was magnificent to see it unfold into the beautiful monster it is today. It has become too powerful for even H265 to take it down without a hell of a struggle, it seems! haha-

With x265 I'm seeing it from the beggining, so it's like watching a demi-god being born. Unfortunarely, I'm no developer so I believe I'm not of much use to the project per-se, I'm afraid. But I'm here rooting for it just like I did for x264 and I owe you guys my very sincere thanks and infinite admiration! :D

benwaggoner

27th December 2013, 00:03

Is it hard to port all the x264 "smart-stuff" to x265? :(
Some yes, some no. Lots of simple heuristics that presume certain relationships between QP and quality certainly will require adaption. And HEVC has lots of options than H.264 didn't, so taking advantage of those optimally will require lots of code that just doesn't exist for x264.

For example I'd expect Trellis to be pretty linear, but psy-rd less so.

But just knowing an algorithm is possible and what it should look like makes it much easier to retune it to a different bitstream format that having to start with a new algorithm from scratch! So even if stuff can't be done like it was in x264, I expect it'll be quicker to get an equivalent feature done for x265 than it was for x264 in the first place.

But it'll certainly be a multi-year process before x265 is able to take as full an advantage of the HEVC spec as x264 is for H.264. And there's still significant room for optimization in x264.

With x265 I'm seeing it from the beggining, so it's like watching a demi-god being born. Unfortunarely, I'm no developer so I believe I'm not of much use to the project per-se, I'm afraid. But I'm here rooting for it just like I did for x264 and I owe you guys my very sincere thanks and infinite admiration! :D
Reporting bugs and cases where quality falls apart is always useful.

I've not touched code in 18 years, but I've still contributed a lot to improve many different codecs and encoding tools.

Also, there are definitely places where x265 exceeds x264. Just for amusement, I encoded Tears of Steel at 3840x1600 at the default x265 settings. The default CRF looked pretty lousy, until I realized the whole file encoded at 178 Kbps! For UHD! No way could x264 had looked as good at such a stupid low bitrate.

Dark Eiri

27th December 2013, 00:45

Reporting bugs and cases where quality falls apart is always useful.

I've not touched code in 18 years, but I've still contributed a lot to improve many different codecs and encoding tools.

Also, there are definitely places where x265 exceeds x264. Just for amusement, I encoded Tears of Steel at 3840x1600 at the default x265 settings. The default CRF looked pretty lousy, until I realized the whole file encoded at 178 Kbps! For UHD! No way could x264 had looked as good at such a stupid low bitrate.

Of course! That's a great idea! Since most of the developers are here, I guess it will be quite easy to file reports, right?
As soon as I get home I'll download the most recent build available and start trying out some scenarios! I'll be happy to try and be useful! :D

By the way... can I use any video sample (like my own blurays, 4K video from friends or recorded .ts TV) or would the devs prefer widely available, free samples for reports?

foxyshadis

27th December 2013, 01:01

Continued discussion about disappointment or the potential of the codec is probably off topic, since it's mostly speculation.

Can some of you guys test with various combinations of --rdpenalty 1 & 2, --no-strong-intra-smoothing, --ctu 16. I'm not sure it's a magic bullet, but maybe --tu-intra-depth and --tu-inter-depth of 4 as well (only applies for large CTUs, won't work with --ctu 16). --rdpenalty 2 disables 32x32dct in some cases, but there's no absolute off switch like like x264's --no8x8dct, and no other way to fiddle with maximums and minimums without editing the source. Smaller blocks should net more detail at the cost of quality reduction in smoother areas. This is just for developer feedback; even if something works it shouldn't be considered the magic bullet to get detail/grain retention in x265.

I'm at work and don't have access to my blurays to test with.

x265_Project

27th December 2013, 02:27

Of course! That's a great idea! Since most of the developers are here, I guess it will be quite easy to file reports, right?
As soon as I get home I'll download the most recent build available and start trying out some scenarios! I'll be happy to try and be useful! :D

By the way... can I use any video sample (like my own blurays, 4K video from friends or recorded .ts TV) or would the devs prefer widely available, free samples for reports?

Sounds good Dark Eiri! Additional testing and feedback would be very helpful and very much appreciated.

We're testing with all of the standard test clips that the Joint Collaborative Team on Video Coding (JCT-VC) is using, but we've tested these to death. We're also using many of the publicly available clips uncompressed (from Xiph.org, etc.). And we're getting test clips from our commercial customers.

Using clips that are available to anyone is advantageous in that others can understand and if needed, reproduce your results. However, we want to hear how x265 performs under the widest range of real-world conditions, so feel free to test with any and all content (home video, mobile phone video, webcam video, anime, video game captures, GoPro footage, etc.).

Tom

xooyoozoo

28th December 2013, 22:57

The recent CUTree fix seems to be doing its job. I haven't looked at objective metrics, but visual improvements over having the feature off are palpable.

I did some x265 encodes at default CRF and compared against x264 without psy. I'm not claiming this is x264 at its finest, but I also don't think psy-rd would be a magic salve. Even 0.4:0 was too much in this situation, and that's the lowest offered in an x264 tuning. Beyond that, I think I can claim x265 is a comfortable superset of x264's coding quality, at least at medium and lower bitrates.

Side-by-side comparisons and bitstreams link (https://drive.google.com/folderview?id=0BzAA-H5x8NKTMnVIMW5BUU9sakE&usp=sharing). All encodes used veryslow presets, aq-mode 2, 0.5s min-keyint, 5s max-keyint, and --ref set to whatever AVC L4.2 allows. The clips are either straight from a Bluray or resampled/resized versions of real test sequences.

Lastly, there might be a bug with x265+CUTree and the very first frame. In most of the clips, you can clearly see that the initial I-frame has much lower quality than the frames in the next couple of seconds.

benwaggoner

29th December 2013, 23:43

Continued discussion about disappointment or the potential of the codec is probably off topic, since it's mostly speculation.

Can some of you guys test with various combinations of --rdpenalty 1 & 2, --no-strong-intra-smoothing, --ctu 16. I'm not sure it's a magic bullet, but maybe --tu-intra-depth and --tu-inter-depth of 4 as well (only applies for large CTUs, won't work with --ctu 16). --rdpenalty 2 disables 32x32dct in some cases, but there's no absolute off switch like like x264's --no8x8dct, and no other way to fiddle with maximums and minimums without editing the source.
Based on description, it sounds like --rdpenalty 1 should be the default, given the description of:
--rdpenalty penalty for 32x32 intra TU in non-I slices. 0:disabled 1:RD-penalty 2:maximum. Default 0

Is there any downside to at least using 1 instead of 0? And what's the difference between 1 and 2 in practice?

Also, for what scenario are you tuning with those settings? 1080p? I'm pretty confident that 32x32 blocks are useful in UHD encoding.

Which I'm getting 90:1 encoding times with on a dual socket 16-core E5-2680 v2 system, FWIW :). First time I've actually gotten slower than my PowerMac 8100/80 was encoding 320x240p15 Cinepak (80:1).

greenfountain

30th December 2013, 09:58

Atak_Snajpera

30th December 2013, 12:29

@Atak_Snajpera, can you test your water clips with the latest fix for cutree, aq n x265 pls? we should be seeing much better results in terms of reduction in blurring out the details this time around.

There is original source file
http://forum.doom9.org/showthread.php?p=1657444#post1657444

Do it yourself.

vood007

31st December 2013, 12:07

Did not test that water clip but for my own por err personal stuff i see a huge step in speed and quality with the latest build. x265 team for devs of the year award!!1 ;)

benwaggoner

31st December 2013, 17:44

Did not test that water clip but for my own por err personal stuff i see a huge step in speed and quality with the latest build. x265 team for devs of the year award!!1 ;)
Quality, yes. Speed seems to be half of last week's dev tip builds for me. Although I've been mainly doing --preset veryslow at UHD resolutions.

I live my life as an edge case :). Thank goodness for the new Ivy Bridge cc3.8xlarge (https://aws.amazon.com/ec2/instance-types/#instance-details)instances. I'm still getting about 1 min encoded per 3 hours of encode time, though.

I see there were some commits (https://bitbucket.org/multicoreware/x265/commits/all)last night for weight analysis and fixing the first I-frame quality issues. I've been really impressed by how responsive MultiCoreWare has been to issues brought up in this thread.

bxyhxyh

1st January 2014, 17:22

I did test when 0.5's early time. Preset fast was slower than 10 bit x264's preset veryslow.

And when I did test on yesterday, preset slow's speed was nearly same as 10 bit x264's preset veryslow.

Quality is increased too but it still blurry.

x265 preset slow, crf 28 - 26.2 mb
x264 preset veryslow slow first pass - 26.2 mb

http://check2pic.ru/compare/34248/

benwaggoner

2nd January 2014, 20:17

What pix_fmt are folks using in Y4M for x265.exe? yuv420p10le?

sneaker_ger

2nd January 2014, 20:22

Unless this was added in the last weeks you cannot use 10 Bit input with Y4M header. Use raw input for 10 Bit.

plonk420

6th January 2014, 09:59

are there any suggestions on how to retain grain the way --deblock -3:-3 does with x264? Panic Room (DVD) is giving me issues...

oddly, super strong grain like the music video Rapture by Iio retained grain quite well with default settings...

xooyoozoo

7th January 2014, 19:48

x265_Project

8th January 2014, 19:48

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

14th January 2014, 05:00

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

14th January 2014, 22:05

fumoffu

18th January 2014, 04:18

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

18th January 2014, 17:09

Tom Vaughan at CES

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

mandarinka

18th January 2014, 17:12

x265_Project

18th January 2014, 19:26

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

18th January 2014, 19:41

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

18th January 2014, 20:43

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

18th January 2014, 20:47

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

xooyoozoo

18th January 2014, 22:28

x265_Project

18th January 2014, 23:23

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

18th January 2014, 23:24

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

19th January 2014, 01:18

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

20th January 2014, 21:12

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

22nd January 2014, 07:37

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

22nd January 2014, 07:59

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

22nd January 2014, 08:06

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

22nd January 2014, 10:31

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

22nd January 2014, 19:54

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

22nd January 2014, 21:02

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

22nd January 2014, 22:06

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

23rd January 2014, 23:19

foxyshadis

24th January 2014, 01:50

x265_Project

27th January 2014, 20:44

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

30th January 2014, 11:38

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

2nd February 2014, 15:00

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

2nd February 2014, 15:33

x265_Project

2nd February 2014, 19:52

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

2nd February 2014, 22:56

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

3rd February 2014, 07:01

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

3rd February 2014, 07:55

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

3rd February 2014, 08:02

LigH

3rd February 2014, 09:25

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

3rd February 2014, 09:30

@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

3rd February 2014, 09:34

Brazil2

3rd February 2014, 11:32

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

3rd February 2014, 12:30

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

3rd February 2014, 21:30

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

pieter3d

4th February 2014, 05:28

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

4th February 2014, 06:53

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

4th February 2014, 07:31

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

4th February 2014, 07:34

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

4th February 2014, 07:39

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

4th February 2014, 07:52

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

4th February 2014, 14:26

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

4th February 2014, 17:52

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

5th February 2014, 00:16

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

5th February 2014, 14:26

@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...

Procrastinating

5th February 2014, 14:39

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

5th February 2014, 16:38

[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

5th February 2014, 20:19

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

5th February 2014, 20:27

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

sirt

6th February 2014, 11:04

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

6th February 2014, 11:19

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

6th February 2014, 19:16

Hi,

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

turab

6th February 2014, 19:39

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

filler56789

6th February 2014, 19:56

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

7th February 2014, 14:04

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

7th February 2014, 18:18

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

8th February 2014, 17:48

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

8th February 2014, 20:02

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

fumoffu

10th February 2014, 09:57

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

10th February 2014, 10:29

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

10th February 2014, 11:32

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

10th February 2014, 11:57

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

10th February 2014, 12:25

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

10th February 2014, 12:27

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

10th February 2014, 12:44

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

10th February 2014, 12:45

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

10th February 2014, 13:05

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

10th February 2014, 14:59

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

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

x265.cc

10th February 2014, 17:23

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

10th February 2014, 18:00

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

filler56789

10th February 2014, 20:06

...........

http://builds.x265.eu/

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

which says,

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

Daemon404

10th February 2014, 23:11

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

11th February 2014, 08:06

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

11th February 2014, 10:53

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

11th February 2014, 10:57

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

11th February 2014, 12:58

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

11th February 2014, 13:09

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

Daemon404

11th February 2014, 13:26

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

11th February 2014, 13:35

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

11th February 2014, 13:52

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

Thanks for the buildbot...:)

LigH

12th February 2014, 08:57

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

12th February 2014, 18:21

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

12th February 2014, 18:24

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

13th February 2014, 09:36

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

14th February 2014, 02:44

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

14th February 2014, 15:30

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

14th February 2014, 16:02

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

14th February 2014, 17:56

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

14th February 2014, 18:20

<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

15th February 2014, 00:05

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

15th February 2014, 01:36

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

15th February 2014, 08:29

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

18th February 2014, 16:40

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

19th February 2014, 04:36

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

19th February 2014, 08:20

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!

Kurtnoise

19th February 2014, 08:51

Your conclusion is biased...you compare only one HEVC/AVC encoder. Moreover, why not compare also the speed time between each other ?

LigH

19th February 2014, 09:00

Do that. I also have a fulltime job besides my hobby. ;)

I never claimed to know how to do a comparison which satisfies every member of this forum. I just added a few values as incentive for others.

Selur

19th February 2014, 16:17

@Kurtnoise: since this is the x265 thread isn't it kind of obvious that people will post stuff about x265 and not about other hevc encoders,...

smok3

19th February 2014, 17:34

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

...

The quality differences are interesting...

Pretty amazing stuff from HEVC here (Although the original must be really weirdly sharpened).

My try at low-bitrate "Big bucks bunny" (crf26, everything default, 420) https://dl.dropboxusercontent.com/u/79532365/tmp/bbb26hifi.mp4
ffmpeg -r 24 -i big_buck_bunny_%05d.png -pix_fmt yuv420p -r 24 -f yuv4mpegpipe - 2> /dev/null | x265 --crf 26 -o bbb.hevc - --y4m

bxyhxyh

21st February 2014, 16:37

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!
Did you use slow first pass? This would give more correct crf values for x264

Audionut

21st February 2014, 19:33

not sure about Bitbucket,

Bitbucket parses the RST automatically like so: https://bitbucket.org/hudson/magic-lantern/src/fd5a7b3cb94d001c9bac60223576239d0744d125/modules/dual_iso/?at=unified

LigH

23rd February 2014, 15:56

@ bxyhxyh:

I was not at all interested in "exact" CRF values for x264. Just in a vague notion that quality/bitrate relations of x264 and x265 have different magnitudes already, and x265 is not yet "finished" by far.

qyot27

24th February 2014, 00:42

Something about the CPU detection in the buildsystem is broken with the development tip (Ubuntu 13.10, x86). CMake reported that it couldn't recognize i686 as an x86 CPU and then disabled the assembly. Which is weird, considering it was detected properly with MinGW-w64 when I cross-compiled a couple days ago.

Obviously, changing the 'i386' to 'i686' in CMakeLists.txt enabled it to detect the CPU correctly and build the assembly. But it seems like something is getting in the way of properly detecting the CPU during configure.

darkbasic

24th February 2014, 02:12

Hi, I did an x264 vs x265 comparison at low bitrates. Here it is if someone is interested:

http://www.linuxsystems.it/2014/02/washed-video-x264-vs-x265-placebo-comparison/

I will add vp9 to the comparison but it will take 2.6 days to encode because it uses a wooden abacus to encode instead of my i7-3770K. Really, I tought it was broken before realising if was really that slow.

I just bought "The Hobbit: An Unexpected Journey" which is considered one of the best quality sources available, so next time I will rip directly from Blu Ray and I will choose an higher target bitrate.

Procrastinating

24th February 2014, 14:04

Essentially, currently x265 handles 8-bit low detail with high accuracy, and 8-bit high detail with low detail. Great for some anime, particularly at 10bit(where other features becomes less significant), not great for much else at this stage.

This has been the case since the dawn of x265, and key x264 features have not been implemented yet. It's not going to look nice on high-detail/grain footage until reasonable feature parity has been met.

I'll probably make some new 10bit comparisons once the devs feel that x265 has met relative feature parity with x264. Studios are starting to make not-terrible BD encodes of anime nowadays too, which makes 10bit all the more exciting!

With all that said, how is Main Still Frame coming along? Is that planned as a post-parity feature?

sneaker_ger

24th February 2014, 14:16

and key x264 features have not been implemented yet.
And those would be which?

darkbasic

24th February 2014, 17:44

Essentially, currently x265 handles 8-bit low detail with high accuracy, and 8-bit high detail with low detail.

I couldn't agree more, x265 HATES grain which is such a pity.

foxyshadis

27th February 2014, 02:20

x265_Project

27th February 2014, 06:25

Main Still is literally just setting the profile to 3 instead of 1 (Main) or 2 (Main 10), the only restriction from Main is that it can't have more than one frame. The default VUI doesn't even change to full range (PC levels) like JPEG, it has to be manually specified if you want that. Anyone could submit a patch to include it today, multicoreware probably won't write it unless there's some demand.

It's 8-bit and 4:2:0 only, though, which sucks. I'm waiting for a Still 10 4:4:4; in the meantime, since there's no difference, I'll just encode one frame to regular 10 or 10 4:4:4 and pretend it's still profile.

As for grain, it's mostly not feature parity anymore; cu-tree and AQ and weightp are all working. (Weightb is in the wings along with .) At this point it's aggressive tuning of AQ and mode decision for different profiles, because their current focus is 16-bit assembly functions to speed up Main 10, VBV, platform compatibility, and bugfixes. Tuning is great, but very time consuming when just implementing everything is pressing.
We're definitely interested in supporting Main Still Picture. If the studies I've read are accurate, HEVC still picture has great potential as a more efficient image compression format.

The x265 development team is focused on achieving the best possible subjective visual quality. This includes further development/optimization of features that have already been implemented, tuning, porting / adapting of the remaining visual quality optimizations from x264, and ongoing algorithm development.

Tom

x265_Project

4th March 2014, 20:39

x265 0.8 is a regularly scheduled feature release

= New in 0.8 =

* 4:4:4 internal color space is now supported. Input pictures must also be 4:4:4, 8 or 10bit. We advise to disable weightp with 4:4:4. Note that since the HEVC Range Extensions are not finalized, this feature should be considered highly experimental. Our output streams may not be compliant with the final spec.

* Improved VBV. x265 will now do mid-frame QP adjustments in order to better meet the bit target. Further improvements will be in the next release (partial slice re-encode when bit budget is very tight).

* FPS is finally handled in a sane fashion. It may be configured as a rational number (numerator/denominator) or as a float. The frame rate is now signaled in the VPS header for use by the decoder.

* VUI signaling is now exposed in the x265_param structure and in the x265 CLI. The exact params and CLI options should be considered experimental at this point, and are liable to change.

* Near full ASM coverage of the 8bit build, and much more 10bit assembly than the previous release. All of the interpolation and intra primitives that were written with SIMD intrinsics have been replaced with assembly routines.

* Input pixel bit depth is now decoupled from the internal bit depth. An 8bpp build and a 16bpp build of x265 will both be able to encode 8bit or 10bit or 16bit raw video streams. The encoder will shift and mask pixels as necessary to get them to the internal depth.

* Motion compensated weight analysis. This will be further improved in the next release.

= CLI changes since 0.7 =

# Added #

--scenecut <integer>
-i/--min-keyint <integer>

--vui
--sar <int:int|int>
--overscan <string>
--videoformat <string>
--range <string>
--colorprim <string>
--transfer <string>
--colormatrix <string>
--chromaloc <integer>
--[no-]fieldseq
--[no-]framefieldinfo
--crop-rect <string>
--timinginfo
--nal-hrd
--bitstreamrestriction
--subpichrd

See CLI help for descriptions

# Replaced options, to sync with x264 #

--refresh <integer> is now --[no]open-gop --frame-skip <integer> is now --seek <integer> -i/--keyint <integer> is now -I/--keyint <integer> (short opt case change)

= Upcoming work =

The next release will focus on improving all of the recently added features, particularly VBV and adaptive quant, and focusing heavily on improving perceptive visual quality.

darkbasic

5th March 2014, 03:20

http://www.linuxsystems.it/2014/03/new-screenshots-comparator-loads-new-x264-x265-vp8-vp9-tests/

Congratulations to the x265 team: at low bitrates x265 completely CRUSH x264 if you use a very high quality source like the Blu-ray of “The Hobbit: An Unexpected Journey”.
Hopefully in the future it will improve at high bitrates too. hi10p is just too bugged to be useful right now.

LigH

5th March 2014, 08:34

And don't forget to release a current Evaluator's Guide as well, please.

x265_Project

5th March 2014, 09:20

And don't forget to release a current Evaluator's Guide as well, please.

x265 Evaluators Guide March 4 2014.pdf (https://bitbucket.org/multicoreware/x265/downloads/x265%20Evaluators%20Guide%20March%204%202014.pdf)

Kurtnoise

5th March 2014, 09:53

What does the "NOT IMPLEMENTED" flag mean exactly in the VUI options ?

Kurtnoise

7th March 2014, 14:02

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

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

dude, may we have also the mingw64 builds please ?

Daemon404

7th March 2014, 14:56

dude, may we have also the mingw64 builds please ?

Why? There's no discernible benefit.

Kurtnoise

7th March 2014, 15:45

In order to make some comparisons between each compilers...

Selur

7th March 2014, 17:00

@Kurtnoise: uploaded MinGW(32&64bit) builds of 0.8+40 here (http://forum.videohelp.com/threads/357754-%5BHEVC%5D-x265-EXE-mingw-builds?p=2306614&viewfull=1#post2306614)

Daemon404

7th March 2014, 20:54

In order to make some comparisons between each compilers...

I'm definitely not interested in adding an extra nightly build just for this.

upyzl

9th March 2014, 03:41

for whom wants to compare diff compilings: Google drive (https://docs.google.com/file/d/0B6cMPUGFjTn8UDhpbmg5M3hTYXc/edit?pli=1)

latest stable, vc12(u1)/icl14.0.2/gcc4.8.2, default and with AVX flag on
only 64bit 8bpp

LigH

9th March 2014, 19:08

v0.8+40 Win32 (XP enabled) and Win64 (cross-compile) also on my HEVC folter on MediaFire (https://www.mediafire.com/folder/6lfp2jlygogwa/HEVC).

Marchand

11th March 2014, 01:39

Built: 2014/Mar/10 - Version: 0.8+61-50d7910ddd61 - Hevc Video Encoder (32 and 64Bit)

x265-64bit-0.8+61-50d7910ddd61.zip (http://forum.videohelp.com/attachments/24010-1394491956/x265-64bit-0.8+61-50d7910ddd61.zip) (759.6 KB)
x265-32bit-0.8+61-50d7910ddd61.zip (http://forum.videohelp.com/attachments/24011-1394491956/x265-32bit-0.8+61-50d7910ddd61.zip) (759.6 KB)

Atak_Snajpera

12th March 2014, 17:15

# Replaced options, to sync with x264 #

--refresh <integer> is now --[no]open-gop --frame-skip <integer> is now --seek <integer> -i/--keyint <integer> is now -I/--keyint <integer> (short opt case change)

Good idea. Why not to replace even --y4m in x265 with --stdin y4m from x264?

mandarinka

13th March 2014, 03:24

= Upcoming work =

The next release will focus on improving all of the recently added features, particularly VBV and adaptive quant, and focusing heavily on improving perceptive visual quality.

Oh, I am looking forward to that last part, yay :)

professor_desty_nova

14th March 2014, 19:41

There's an error in the table "QUALITY PRESETS" of the latest Evaluators Guide. In "--aq-mode", the default is 1 not 2.
And on page 10, it has --b-adapt 1 as default, when 2 is the default.

PS: Isn't "(now it only enables B GOP structure)" on x265 help outdated ("--bframes <integer> Maximum number of consecutive b-frames (now it only enables B GOP structure) Default 4")? It is the same as version 0.3 when you didn't have b-adapt...

x265_Project

16th March 2014, 22:00

x265_Project

16th March 2014, 22:26

Someone asked me the following question privately. For everyone to benefit from the answer, we prefer questions to be asked publicly (through our x265-devel mailing list, or on this forum). I've anonymized some details in the question...
What is the input format for 10-bit 4:2:0 into x265?

We used x264 for <our last project> and would like to use x265 for the 4k <version of our next project>. We would like to start developing our 10-bit <content>. We create most of <our content> natively in 4:2:0 to avoid down conversion loss.

Do you support P010 or P016 input? http://msdn.microsoft.com/en-us/library/windows/desktop/bb970578(v=vs.85).aspx

For x264, we used the QP min and max parameters and set the peak bitrate and buffer size. If we underflow, then we adjust the QP up. e.g. Most of our <content> was encoded with QPMax set to 0 and peak bitrate set to 40 Mbps. I believe Blu-ray 4k will be 60 Mbps peak. Some <content> had to be a higher QP (8 or 10) to not violate the VBV constraints.

Yes. x265 supports 10 bit YUV input. I believe it supports 12 and 16 bit input also, but this will be truncated to 10 bits/sample.
Using FFMPEG to create your YUV file, we support the following -pix_fmts...
yuv420p10le
yuv444p10le

For example, you can convert a ProRes 4444 10 bit MOV file to YUV 420 10 bit with the following syntax;
ffmpeg -i example_1920x1080_2997fps.mov -pix_fmt yuv420p10le example420p10.YUV

Stacey Spears

17th March 2014, 05:11

Thank you Tom.

Is yuv420p10le the same as the FOURCC P010? http://msdn.microsoft.com/en-us/library/windows/desktop/bb970578(v=vs.85).aspx

Daemon404

17th March 2014, 14:52

Thank you Tom.

Is yuv420p10le the same as the FOURCC P010? http://msdn.microsoft.com/en-us/library/windows/desktop/bb970578(v=vs.85).aspx

No.

YUV420P10LE is planar.

Stacey Spears

17th March 2014, 16:12

No.

YUV420P10LE is planar.

P010 is planar.

nevcairiel

17th March 2014, 16:25

P010 is half-planar, Y is separate, and CbCr are interleaved, just like NV12 for 8-bit.
YUV420P10LE is completely planar, 3 separate planes for Y, Cb, Cr each.

Stacey Spears

17th March 2014, 19:23

Thank you nevcairiel, that helps. Are YUV420P10LE and YUV444P10LE actually documented anyplace?

James Freeman

20th March 2014, 13:25

LigH

20th March 2014, 13:40

The ability to preserve details is being fixed and enhanced, there have been several patches changing some internal behaviour regarding motion vectors and quantization. So I believe it will be comparable in version 1.0; and I assume that professional studios won't get a commercial license much earlier anyway.

sneaker_ger

20th March 2014, 13:45

and I assume that professional studios won't get a commercial license much earlier anyway.
Not that they need one, GPL is free for commercial use.

LigH

20th March 2014, 13:54

Means, it will be each studio's own matter to contact the MPEG-LA for the created content in case of relevant amount and circumstances? Well, these details may be beyond this topic.

James Freeman

20th March 2014, 14:17

Thanks.

Time-wise, when x265 v1.0 will be ready to be licensed?
From what I've ready all over the net, the next Blu-Ray standard will be announced in 2014-2015.

x265_Project

20th March 2014, 17:05

I've missed the progression of this thread, but I have a question.

Is x265 up to par with x264? I remember not so long ago x265 would destroy the fine detail...
My real question is, is it good enough for professional studios to use it as the next blu-ray standard?

Thanks.
As x264 is the gold standard for production video encoders, and as we are porting and adapting x264 features into x265, we run extensive tests comparing the visual quality of x265 against x264 at the same bit rate. From an objective standpoint, x265 produces rate distortion curves that are substantially better (either with PSNR or SSIM) at any constrained bit rate. But the only thing that really matters is subjective visual quality. From a subjective standpoint, in our tests x265 produces better visual quality in the vast majority of test sequences. HEVC is especially stronger with respect to temporal noise. We're still working hard to fine-tune the encoding algorithms under all of the most challenging conditions (high motion with high detail at low bit rates), and we're still working to implement some x264 features like psy-rd.

So, the quick answer is - try it. Run x264 and x265 on the same clips at the same bit rate, play the video back and see what you think.

We've come a long way, but we're not done. You can expect a number of improvements that are focused on visual quality in the coming weeks.

Tom

x265_Project

20th March 2014, 17:13

Thanks.

Time-wise, when x265 v1.0 will be ready to be licensed?
From what I've ready all over the net, the next Blu-Ray standard will be announced in 2014-2015.
x265 is ready to license today. We have been reaching licensing agreements with leading video hardware, software and service providers for many months.

We will reach the 0.9 tag in the next couple of weeks. I don't expect to hit the 1.0 milestone until late April, but this is just a number. Most of the key HEVC encoding features are already implemented in x265 (v0.8). As we continue our work it will just keep getting better with respect to features, performance and encoding efficiency (visual quality at a given bit rate).

Tom

James Freeman

20th March 2014, 17:42

These are excellent news (for me).
Thank you very much Tom.

benwaggoner

20th March 2014, 18:25

So, the quick answer is - try it. Run x264 and x265 on the same clips at the same bit rate, play the video back and see what you think.
My overall experience has been that x265 is substantially superior to x264 at similar, challenging bitrates at UHD frame sizes.

Atak_Snajpera

20th March 2014, 20:32

For my test file x264 still wins

sample -> http://www.diktafon.atw.hu/112.MTS (http://www.diktafon.atw.hu/112.MTS)

CPU: Xeon E5-2690 @ 2.9Ghz ( 8C - 16T )

x264 --preset veryslow --crf 33.6 , encoding speed 8.3 fps , average bitrate : 2279 Kbps , file size : 16.3 MB
https://mega.co.nz/#!BE0nmTrZ!Nf6dG2BC4aBb3CBWdp9nPPIZj4bj7b2WEPbrWgz93YY

x265 --preset medium --crf 30 , encoding speed 7.7 fps , average bitrate : 2269 Kbps , file size : 16.3 MB
https://mega.co.nz/#!NN9mwbiY!2Zp4lN2bJ-zLbHWh9jGRKChDAjPk5ROwkID6on6Gs0g

frame 625 -> http://i.cubeupload.com/99I2GS.png
frame 1065 -> http://i.cubeupload.com/21QL6S.png

x265
frame 625 -> http://i.cubeupload.com/Jrl3mg.png
frame 1065 -> http://i.cubeupload.com/oHudEz.png

benwaggoner

20th March 2014, 21:02

For sample -> http://www.diktafon.atw.hu/112.MTS (http://www.diktafon.atw.hu/112.MTS)
That site gets blocked by my work network. Can you tell me its specs?

x264 --preset veryslow --crf 33.6 , encoding speed 8.3 fps , average bitrate : 2279 Kbps , file size : 16.3 MB
https://mega.co.nz/#!BE0nmTrZ!Nf6dG2BC4aBb3CBWdp9nPPIZj4bj7b2WEPbrWgz93YY

x265 --preset medium --crf 30 , encoding speed 7.7 fps , average bitrate : 2269 Kbps , file size : 16.3 MB
https://mega.co.nz/#!NN9mwbiY!2Zp4lN2bJ-zLbHWh9jGRKChDAjPk5ROwkID6on6Gs0g
I don't know if we want to be comparing x264 and x265 at the same bitrate AND the same encoding time at this point. We know that x264 has a lot more speed optimization than x265.

I'm not sure how well refined CRF is in x265, and it generally makes comparisons more complex. I'd suggest CBR so we are generally comparing similar bitrates throughout the file.

x265_Project

20th March 2014, 21:02

For my test file x264 still wins

Atak_Snajpera - Thanks for posting this. I like your test file (112.MTS). We downloaded this when you first posted it in December, and we've been using it for tests since that time. Waves on water are always a challenge for video encoders, as they contain high frequencies both spatially and temporally. At constrained bit rates, the question is - how do you handle it? Do you fail gracefully, or does the lack of bits cause visually obvious and objectionable artifacts? x264 and x265 handle the lack of sufficient bits in different ways. With x264 you see more temporal noise (inaccuracy in the actual edge or position of objects, or apparent motion where there should be none).

I know you understand this, but for those less experienced; you can't see temporal noise in a still picture, ... you need to watch the video. With x265 we see much lower temporal noise, but we see some areas that appear to be low-pass filtered. We've been working on this, and we have made a lot of progress in the past few months, but we're not quite there yet.

I've posted a couple of my encodes from 112.MTS here...
http://x265.org/video/112veryslow1500.264
http://x265.org/video/112_vslow_1500_25fps.hevc

Tom

x265_Project

20th March 2014, 21:06

I don't know if we want to be comparing x264 and x265 at the same bitrate AND the same encoding time at this point. We know that x264 has a lot more speed optimization than x265.

Agreed. The basic idea here is that HEVC gives us the coding tools to achieve higher compression efficiency, but you don't get that higher efficiency for free. It comes at the cost of higher computational complexity (higher compute resource requirements for a given level of performance, or slower performance on a given system).

kolak

20th March 2014, 22:33

x265_Project

20th March 2014, 22:50

I am running some tests on UHD 60p content as our client requested final delivery as DPX and H265 transport stream. This is high-end footage shot on Sony F65. I was surprised that they are asking for h265, but they want the best possible quality at 50mbit.
I am using ffmpeg as it can mux h265 into ts and h265 definitely gives better than x264 overall quality. I think blurring problem is not that obvious anymore. I just have decoding speed issues :p

Is latest ffmpeg on pair with x265 libraries?

I have also tried 4096x2160, but this seams to producing unplayable streams (at least by ffplay and LAV decoder). Picture breaks up.

Another question, does 50mbit for UHD 60p footage fall in medium or low bitrate area?
We have a high-speed decoder called UHDcode. Our decoder is not open sourced. I can provide this for your evaluation under NDA.

As I understand it, FFMPEG links with x265 statically. So you'll get whatever version of x265 was available when FFMPEG was built. You can pipeline FFMPEG into your own build of x265 to get the latest and greatest x265.

If you provide me with a sample 4096x2160 video file we can debug the issue you're seeing. We had no problems with traffic_4096x2048_30p.yuv.

50 Mbit is a fairly generous (high) bit rate, even for UHD 60p. Certainly some people use higher bit rates, but 50 Mbit is not what most people would call a low or medium bit rate.

kolak

20th March 2014, 23:01

x265_Project

20th March 2014, 23:16

Any special settings to preserve grain? Higher aq-strength ?

Higher AQ strength might help a bit, but our current AQ implementation varies QP at the usually 64x64) CTU level. We're working to implement finer granularity to AQ, to the PB level.

I have to use ffmpeg as I need to mux to ts stream and if I feed ffmpeg with raw x265 file it seams to not liking it.
It uses one of the latest x265 version, but not exactly the latest. I understand.

I don't think its related to actual source file, it maybe just 4096x2160@60p problem. I will try on some bars file with these parameters.

smegolas

21st March 2014, 16:28

Audionut

22nd March 2014, 04:32

And I recall the same things being said about x264 vs xvid/mpeg2, when it was in it's initial development cycle.

smegolas

22nd March 2014, 13:33

And I recall the same things being said about x264 vs xvid/mpeg2, when it was in it's initial development cycle.

That's why I said 'yet'. The question he asked was about the current status. Not about the future.

Daemon404

22nd March 2014, 17:57

As I understand it, FFMPEG links with x265 statically. So you'll get whatever version of x265 was available when FFMPEG was built. You can pipeline FFMPEG into your own build of x265 to get the latest and greatest x265.

Author here. It only does so when you tell it to.

You can link dynamically, and as long as the x265 ABI is stable/matches the build time ABI, it will work.

There is still a blurring effect.

At very low bitrates - the type of bitrates that most people would consider too low for watchable quality - x265 easily outperforms x264. The artifacts have a smoother, rounder quality.

However if you want to do a high quality encode it's still not capable of outperforming x264 yet. It's just too blurry.

So it is great in bitrate starved conditions, but no good if you are trying to achieve high quality, fine detail with grain retention etc.

This anecdote matches every test I've done thus far, since I only care about the mid-to-high end.

LigH

23rd March 2014, 12:15

anonymlol

23rd March 2014, 15:10

Is there anyone with a big fat modern intel multi-core CPU who can provide some coarse "benchmark" results for 720p and 1080p material at different (ultrafast .. fast) speed presets?

I have only some AMD Phenom-II available: no AVX, no SSE4+, x265 honors at most "SSE2Fast" (SSE3 seems to be not very relevant for HEVC encoding algorithms, or its implementation is too slow on K10).

Samples from LDV tests on a Phenom II X6 1045T using v0.8+195 (GCC 4.8.2, Win64):

720p

ultrafast: 17.84 fps
veryfast: 15.49 fps
faster: 12.35 fps
fast: 4.61 fps

1080p

ultrafast: 5.08 fps
veryfast: 4.00 fps
faster: 3.19 fps
fast: 1.60 fps

I have an i7 2700K @4.4GHz.

HEVC encoder version 0.8+185-27e0620327e5
build info [Windows][MSVC 1800][64 bit] 16bpp
using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX

Settings are --recon-depth 10 and the presets below.

720p

ultrafast: 38.39 fps
superfast: 33.24 fps
veryfast: 23.34 fps
faster: 19.04 fps
fast: 13.48 fps
medium: 8.84 fps
slow: 5.20 fps
slower: 2.72 fps
veryslow: 1.70 fps

1080p

ultrafast: 18.29 fps
superfast: 15.85 fps
veryfast: 10.65 fps
faster: 9.36 fps
fast: 6.24 fps
medium: 4.09 fps
slow: 2.39 fps
slower: 1.36 fps
veryslow: 0.86 fps

LigH

23rd March 2014, 15:33

Nice, thank you; however, I expect 10 bit encoding to be much slower than 8 bit encoding.

I was curious if realtime 1080p encoding with x265 (despite not yet being completely optimized) is already close to "possible", and regarding your results, I would agree that it won't take forever to get there.
__

P.S.:

There is a preset "superfast"? Appears to be undocumented in the help output and the explanations in the Evaluator's Guide on page 3, but appears in the table of quality presets on page 9.

mandarinka

23rd March 2014, 16:53

For the results to be comparable, I think the same source is needed, and also the same crf. The speed probably scales with bitrate, at least with the slow settings?

LigH

24th March 2014, 09:14

I was not yet interested in comparable results, only in a magnitude. And regarding some results reported in the VideoHelp forum, realtime encoding of 1080p is already possible with fastest presets and fast desktop PC CPUs. The result will just not be as efficient as HEVC is meant to be...

So thank you for this little experiment. But of course, it has little relevance for practical use.

Audionut

24th March 2014, 09:25

benwaggoner

24th March 2014, 19:19

I was curious if realtime 1080p encoding with x265 (despite not yet being completely optimized) is already close to "possible", and regarding your results, I would agree that it won't take forever to get there.
Certainly for some scenarios and quality levels with a dual Ivy Bridge or something. Of course, realtime encoding also requires a fair amount of buffering if encode time per frame varies a bunch. Reliable live encoding is a tricky thing, and until the x265 devs say they've tested and tuned for the scenario, I wouldn't do more than experiment with it for the time being.

There are already live HD HEVC commercial encoders, so it is certainly possible.

kolak

24th March 2014, 22:45

Yes, this is what I thought, but we want to have high transparency to the master, so even if it looks quite good at 50mbit, it's lacking most of the original grain when compared to DPX master. Overall, I think it looks good and definitely better than x264.

Any special settings to preserve grain? Higher aq-strength ?
I have to use ffmpeg as I need to mux to ts stream and if I feed ffmpeg with raw x265 file it seams to not liking it.
It uses one of the latest x265 version, but not exactly the latest.

I don't think its related to actual source file, it maybe just 4096x2160@60p problem. I will try on some bars file with these parameters.

I've tried latest ffmpeg and all decoding problems seams to be gone. Looks like it uses more recent x265 libraries and has fixed some problems from previous version.
I do have a bit of blurring issues, even when using 50Mbit for UHD. It almost looks like some bug in whole engine (some areas get over quantized). Any way of stopping it?

x265_Project

25th March 2014, 02:30

I've tried latest ffmpeg and all decoding problems seams to be gone. Looks like it uses more recent x265 libraries and has fixed some problems from previous version.
I do have a bit of blurring issues, even when using 50Mbit for UHD. It almost looks like some bug in whole engine (some areas get over quantized). Any way of stopping it?
Our engineering team is reviewing all of the many coding algorithms that affect visual quality right now, as part of a final overall optimization and tune-up in the current development phase. We're aware of this concern, and we're focused on it.

Tom

kolak

25th March 2014, 11:00

LigH

25th March 2014, 11:14

You can try to reduce in-loop deblocking (like in film or grain tunings) to keep more of high frequency parts.

But an important part of the efficiency of current video encoders is based on reducing the accuracy of frequencies which are notorious for representing noise and less important for recognizing whole objects. A little more high frequency accuracy means a lot more required bitrate.

mandarinka

25th March 2014, 12:16

x264 has very similar problem. Even with high bitrates it would sometimes destroy all details on areas with high contrast. It's not as visible and common like with x265, but the same problem is also there.
I hope it can be fixed.

Note that such "killed" frames with x264 could very likely be the result of capped bitrate/VBV, which oyu as a professional user probably have enabled.

If a majorly complex scene needs bits and the encoder doesn't have them available, the result is washed out detail, decimated grain, or artifacts.

That being said, x265 does have issues with dropping texture detail in some areas even at high bitrates (I tried 18 megabits with 1440x1080p24 for example). This behaviour might improve once it gets PsyRDO.

kolak

25th March 2014, 12:56

x265_Project

26th March 2014, 03:55

You are correct- this was under max bitrate/vbv restrictions.
Saying that I would prefer if encoder would reduce bits over whole frame, than create some small flat spots (but this is part of the whole PsyRDO I assume).
Whole AQ needs just a more work which as it has been said is already in progress.

I also have I frame pumping issue, any setting to stop it? I can't see anything which would give P, B frames more bits.

Kolak, et al,
We're all over this... the whole x265 team. We've been looking at everything that affects visual quality, and we're working on a number of improvements. Fine-grained AQ is just one of many things that will help.

I also want to let everyone know that our documentation (the document formerly known as the "Evaluator's Guide" is online in the form of RestructuredText here ... http://x265.readthedocs.org. A new rule for x265 developers - changes to the code that affect the command-line syntax, debug or log file output (or anything we've documented) must include changes to the documentation at the same time. Anyone can suggest improvements to the documentation simply by submitting a patch to the x265-devel mailing list. Patches will be reviewed just as code patches are. If the x265 developer community deems the change to be an improvement, it will be committed.

Thanks
Tom

filler56789

27th March 2014, 05:36

For the notes...

now libx265 breaks FFmpeg's compatibility with Windows XP :mad: :mad: :mad: :mad: :mad:

http://ffmpeg.zeranoe.com/forum/viewtopic.php?f=7&t=1889

May I ask why for Command Line Tool something higher than Win XP is required?

Also,

On Tue, Mar 25, 2014 at 4:44 PM, Jason Garrett-Glaser <jason@x264.com> wrote:

> On Tue, Mar 25, 2014 at 10:32 AM, Steve Borho <steve@borho.org> wrote:

>> On Tue, Mar 25, 2014 at 11:25 AM, Roger Pack <rogerdpack2@gmail.com>
wrote:

>>> Hello. I noticed in a recent discussion that seemingly windows xp
>>> support had been "dropped" to clean up code:
>>>
>>>
http://forum.videohelp.com/threads/357754-%5BHEVC%5D-x265-EXE-mingw-builds?goto=newpost

>>
>> I would describe the situation more as we needed to use a
>> synchronization primitive (condition variable) in order to prevent
>> deadlocks and that primitive is not supported on XP. This wasn't a
>> code cleanup, it was fixing a serious race hazard.

>
> x264 supports condition variables on XP just fine.

I see that now in win32thread.c around line 117, thanks for the pointer.

So it is definitely possible to mimic a condition var on XP. Any
volunteers to adapt this to our threading.h?

--
Steve Borho

nevcairiel

27th March 2014, 10:12

If you care about XP (most developers don't), you should volunteer to provide the XP compatibility wrapper, like Steve asked someone to do.

filler56789

27th March 2014, 10:22

^ Wrong answer, Hendrik.

LigH

27th March 2014, 10:37

The usual story about teamwork (someone, anyone, noone and everyone)?

Do or do not. But don't blame.

foxyshadis

27th March 2014, 23:55

^ Wrong answer, Hendrik.

It was a hasty decision to fix a bug, it's a known issue, there are workarounds, and a fix is already somewhere in the works. How much more exposure is necessary?

(The fact that few developers still care about XP is true, though, especially if they aren't paying customers.)

fumoffu

28th March 2014, 14:41

I was testing latest build from http://chromashift.org/x265_builds/
btw. can someone explain what is the difference between builds tagged icl14 and msvc2012 is it just different compiler? I'm asking because for me the first one is literary 2 times faster than the second which I find surprising... (I'm testing on i5-3570)

LigH

28th March 2014, 15:16

Yes, it is just a different compiler (Microsoft Visual C++ vs. Intel C Compiler). The ICL may optimize C/C++ code (much?) better for intel CPUs, if it works correctly. But the more manually tuned Assembler code gets implemented, the less the used C compiler will matter.

mandarinka

28th March 2014, 16:00

I had the same result on AMD chips (K10), only the difference was more like three times faster encoding with ICL.

IIRC though, with a different version of MSVC, the results were actually the same for both. We talked about it in the IRC channel, but IIRC no clear cause/solution was arrived at.

anonymlol

28th March 2014, 18:05

That's weird, my MSVC builds are way faster than the ICC (and MSVC) builds from that site.

If anyone wants to compare: x265 highbitdepth 64bit 0.8+243 msvc (https://db.tt/tq3ZTDGf)

Mine: 13.69s (1.31 fps)
MSVC from there: 27.18s (0.70 fps)
ICC from there: 22.30s (0.81 fps)

nevcairiel

28th March 2014, 18:08

Sounds like some of the builds are flat out broken - maybe issues with multithreading?

vood007

28th March 2014, 18:56

Could it be they are debug builds? i remember i could not use a build because it tried to load msvcp110d.dll (d=debug version)?

cyberbeing

29th March 2014, 00:32

That's weird, my MSVC builds are way faster than the ICC (and MSVC) builds from that site.
I can reproduce this. The builds on chromashift.org are extremely slow for some reason. Quick test with default settings on a 720p y4m with i5-3570K.

VC12 highbitdepth (my build): 9.18 fps
VC12 highbitdepth (anonymlol's build): 9.18 fps

VC12 highbitdepth (chromashift): 4.33 fps
ICL14 highbitdepth (chromashift): 7.34 fps

filler56789

29th March 2014, 09:52

It was a hasty decision to fix a bug, it's a known issue, there are workarounds, and a fix is already somewhere in the works.

How much more exposure is necessary?

I think the pertinent questions are these,

¿why does the X265 Wiki (http://forum.videohelp.com/threads/357754-%5BHEVC%5D-x265-EXE-mingw-builds?p=2274443i#post2274443) (<= click) still deny or ignore the existence of MinGW?

¿what's the point of their prior commitment to Visual C++ and CMake?

qyot27

29th March 2014, 12:32

I think the pertinent questions are these,

¿why does the X265 Wiki (http://forum.videohelp.com/threads/357754-%5BHEVC%5D-x265-EXE-mingw-builds?p=2274443i#post2274443) (<= click) still deny or ignore the existence of MinGW?

¿what's the point of their prior commitment to Visual C++ and CMake?
That's a forum thread, not a Wiki.

This is the Wiki, and it does, in fact, refer to MinGW:
https://bitbucket.org/multicoreware/x265/wiki/CrossCompile

Talking about MinGW under the cross-compile section is the correct place to do it, since it's far more notable as a cross-environment running under Linux or Cygwin than it is running under MSys (although the page there does mention MSys as an aside).

Visual Studio is the native compiler for Windows, that's why they focus on it. CMake has nothing to do with it, and isn't a factor in this at all.

filler56789

29th March 2014, 14:05

That's a forum thread, not a Wiki.

Yes, and that forum post presents a pertinent criticism to the X265 Wiki.

CMake has nothing to do with it, and isn't a factor in this at all.

Perhaps.

Visual Studio is the native compiler for Windows, that's why they focus on it.

That sounds a lot like a rationalization :)

http://en.wikipedia.org/wiki/Rationalization_(making_excuses)

nevcairiel

29th March 2014, 14:19

They focus on Visual Studio because thats the primary development platform of a lot of their developers. :p

Daemon404

29th March 2014, 14:42

I can reproduce this. The builds on chromashift.org are extremely slow for some reason. Quick test with default settings on a 720p y4m with i5-3570K.

VC12 highbitdepth (my build): 9.18 fps
VC12 highbitdepth (anonymlol's build): 9.18 fps

VC12 highbitdepth (chromashift): 4.33 fps
ICL14 highbitdepth (chromashift): 7.34 fps

Think I figured out why -- it was my fault. When I was telling it to use /MT instead of /MD, cmake was completely nuking all the CFLAGS/CXXFLAGS (read: /O2 and pals).

The current build at the usual place is fixed now, as are all future builds.

LigH

29th March 2014, 15:55

Also there is an interesting side note in the Wikipedia that the ICL only creates optimized code if it is running on a "GenuineIntel" CPU, but badly unoptimized code when running on any other CPUID. Which made me stop thinking further about it before even trying, knowing that I have only AMD CPUs available.

mandarinka

29th March 2014, 18:52

You can get around that by overwriting ICL's CPU detection. x264 has something to do that, not sure about x265.

cyberbeing

29th March 2014, 20:31

Think I figured out why -- it was my fault. When I was telling it to use /MT instead of /MD, cmake was completely nuking all the CFLAGS/CXXFLAGS (read: /O2 and pals).

The current build at the usual place is fixed now, as are all future builds.

I can confirm the speed of your MSVC builds is now normal on my i5-3570K. No change with the ICL14 builds compared to my previous results, so I guess MSVC just optimizes x265 64bit better for Ivy Bridge at this time.

LigH

29th March 2014, 22:34

From the developer mailing list:

[PATCH] restore WINXP_SUPPORT build option, workaround for CONDITION_VARIABLE on XP

Are you happy now, as soon as it is commited?

foxyshadis

31st March 2014, 22:03

I think the pertinent questions are these,

¿why does the X265 Wiki (http://forum.videohelp.com/threads/357754-%5BHEVC%5D-x265-EXE-mingw-builds?p=2274443i#post2274443) (<= click) still deny or ignore the existence of MinGW?

¿what's the point of their prior commitment to Visual C++ and CMake?

HM was built on Visual Studio, and x265 started as an extension of HM. You don't like it, go harass the guys who ran the JCT-VC and created H.265; I'd rather be glad that MCW took the time to make it cross-compatible. Now take this garbage out of here, this thread isn't the place for harassing developers because you don't understand things.

benwaggoner

3rd April 2014, 17:34

Anyone know what the proper max values of --vbv-maxrate are by level? The --bitrate values are well documented.

sneaker_ger

3rd April 2014, 18:02

How can "--bitrate" be documented?

Vbv values can be found in the spec, table A.1 (page 203/217) and A.2 (page 205/219).
http://www.itu.int/rec/T-REC-H.265-201304-I

benwaggoner

3rd April 2014, 18:20

How can "--bitrate" be documented?

Vbv values can be found in the spec, table A.1 (page 203/217) and A.2 (page 205/219).
http://www.itu.int/rec/T-REC-H.265-201304-I
Sorry, I meant for --vbv-bufsize. --bitrate and --vbv-maxrate have identical restrictions.

LigH

3rd April 2014, 20:07

For AVC in Blu-ray, there is this table in Encoding Video for Blu-Ray using H264/AVC (http://forum.doom9.org/showthread.php?t=154533); I guess there has to be a similar specification for any specific hardware player that will use HEVC.

D3C0D3R

3rd April 2014, 21:06

Are you happy now, as soon as it is commited?

A lot :)

Meanwhile some strange perfomance regression was found in MinGW-compiles.

LigH

3rd April 2014, 21:18

Strange, indeed. Now that the reprogrammed Condition Variables (based on x264 code) are default because they are reportedly faster than the native kernel functions ... can you provide a few more details?

EncodedMango

5th April 2014, 03:59

So x265 has reached 0.9? The builds on chromashift seem to indicate so.

x265_Project

5th April 2014, 04:09

x265 0.9 is a regularly scheduled bug fix release. Many bugs have been fixed since the 0.8 tag, primarily in rate control and 10bit encodes. A race hazard on POSIX systems was fixed, and several non-determinism problems were resolved.

= API Changes =
* the stride of x265_picture is now in units of bytes, not pixels
* VUI configurables were moved into a param.vui sub-struct
* unimplemented VUI options removed
* bRepeatHeaders option added (inserts VPS+SPS+PPS each keyframe)
* fast-decode tune option added
* x265_encoder_headers() returns NAL byte count on success

= Command Line Interface Changes =
* --dither option to improve quality of pixel downshifts
* --cpuid replaced with x264 compatible --asm option
* --crf-max <float> added
* improved --help documentation, plus new online documentation
* **experimental** --interlaceMode <prog|tff|bff>
* **experimental** --weightb

= New Features =
* experimental support for interlaced content (field coding)
* experimental weightb support

We now have online documentation for this release http://x265.readthedocs.org/en/0.9/
plus http://x265.readthedocs.org/en/default/ and http://x265.readthedocs.org/en/stable for the two development branches.

See the online manual for full documentation of CLI (and API) options

Our focus for the near future remains on visual quality and rate control improvements.

uneedme

6th April 2014, 04:41

The new Vapoursynth is written in python language, so it might run on the GAE platform and using google CPU time and actualizing the cloud computing.

Is there any build of x265 with python, could hosting the public calculations online (like many people contributing their GAE accounts to join and construct one or several mega-mutilthreads to run apps with in-out ports).

I have known that a proxy-fuction software: "goagent" is working on that mode properly.

I am just a tech lame.

Or semi-mixed working mode <partial local , partial up-online>

Am I dreaming?

LigH

6th April 2014, 09:29

uneedme

6th April 2014, 15:23

Dreaming? ... Probably, yes: x265 is mostly assembler based because many routines are so extremely computing intense that optimizing them at the level of CPU dependent instructions, and parallelizing them with a rather tight synchronization, is necessary to encode at a satisfying speed.

It may be possible to write another HEVC encoder in Python (similar to writing an AVC encoder for CUDA or QuickSync). But that will certainly not be "x265". Furthermore, porting algorithms to specific execution environments may have its own complexity limits, and because interpreted or JIT-compiled languages (like Python) are never as fast as well optimized Assembler code, it will probably take much longer than x265 with the same number of threads and at the same encoding complexity.

In addition, the more threads, the less optimal the encoding may become, depending on the algorithm (either it is looking for abbreviatable redundancies only in each thread's frame part independently, or sharing with other threads – if that is possible at all – will make the threads wait for each other a lot more). And finally, if you let a "Cloud" execute several threads of one algorithm in possibly very distant places, sharing information between them will cost a lot of time, while I could imagine that x265 would even try to make use of CPU-internal caches, if possible.

o Thanks for your analysis,

assembler based...... that could be a problem...

extremely computing intense... that is why using cloud computing

CPU dependent instructions....
GAE allocates some free cpu resources for each account (10 units per account) and some storage spaces. If we got 1000 accounts deployed that would be 10000 units free usages. And We could design the uploaded-program with self-acknowledged mod. The given instructions is spreading to units within the google servers and self-immigration when eating up the current cpu unit resources and moving on... Unless exhusting all unit cpu time, it could still processing to the end.

All units almost could be called or acknowledged simultaneously, so the not optimized coding and long on-call time consuming could be neglected. (try to imaging some 10000 units work parallel)

the more threads, the less optimal the encoding may become.........
what of our consideration is to save the long long process time, not saving the utility bill or developing processing efficiency. The rather massive computing with a set of cpu units leads the program pending and dragged down to less 10 fps output, actually, there are so many "google" server resources running idly (or public cloud providers or GAE-like platforms) .

The true problems is how we recruit so many gae accounts as possible, and how to revise the x265 programm to suit the Distributed computing.

LigH

6th April 2014, 16:20

extremely computing intense... that is why using cloud computing

Well, massive parallelization only helps in certain cases: When the results of each calculation are mainly independent. But in HEVC, all results may depend on many other partial results across several frames during one GOP, all calculations probably need to share data among each other. This makes a distributed solution not very helpful, because they can't easily and – even more important – quickly exchange much data.

All units almost could be called or acknowledged simultaneously, so the not optimized coding and long on-call time consuming could be neglected. (try to imaging some 10000 units work parallel)

Not per-se helpful for HEVC, because:

the more threads, the less optimal the encoding may become

due to either a too much limited scope of motion estimation, or much overhead to share partial results among threads.

Except the calculation of a long movie gets partitioned into a distributed calculation of many parts of the movie. But that requires an optimal calculation of partitioning points first. In theory, already AVC was able to use data of very similar scenes before and after a brief inserted cut (not sure if it was measurably successful in practice).

uneedme

6th April 2014, 16:53

Well, massive parallelization only helps in certain cases: When the results of each calculation are mainly independent. But in HEVC, all results may depend on many other partial results across several frames during one GOP, all calculations probably need to share data among each other. This makes a distributed solution not very helpful, because they can't easily and – even more important – quickly exchange much data.

Not per-se helpful for HEVC, because:

due to either a too much limited scope of motion estimation, or much overhead to share partial results among threads.

Except the calculation of a long movie gets partitioned into a distributed calculation of many parts of the movie. But that requires an optimal calculation of partitioning points first. In theory, already AVC was able to use data of very similar scenes before and after a brief inserted cut (not sure if it was measurably successful in practice).

to set segmented fragments and then to collect and string up the segmented results...... o...

I wish my idea could be inspiring. And the good is it turned out to be a not all pointlessness. lol

Thanks anyway.

LigH

6th April 2014, 17:31

:o Well, sometimes I may sound pessimistic; I'll leave the inspiration to the real active developers (e.g. from Multicoreware). I'm merely a tester. :)

jackoneill

6th April 2014, 18:12

The new Vapoursynth is written in python language, so it might run on the GAE platform and using google CPU time and actualizing the cloud computing.

"The new Vapoursynth" is not written in Python. The core is written in C++, the included filters are written in C, C++, and some x86 assembly.

uneedme

7th April 2014, 07:49

"The new Vapoursynth" is not written in Python. The core is written in C++, the included filters are written in C, C++, and some x86 assembly.

o

to be precise, python adapted or python binded......

D3C0D3R

8th April 2014, 12:39

Strange, indeed. can you provide a few more details?

Nevermind. I turn off WIN_XP support on Win8 machine. But if turn it on (by default) - its ok.
Now that the reprogrammed Condition Variables (based on x264 code) are default because they are reportedly faster than the native kernel functions
Just curoius. Since project is cpp, why they didnt use C++11 standart synchronization primitives wrapped in macro and then change it when C-backport primetime?

Daemon404

8th April 2014, 19:04

Just curoius. Since project is cpp, why they didnt use C++11 standart synchronization primitives wrapped in macro and then change it when C-backport primetime?

Because the compilers they target do not all support C++11.

D3C0D3R

8th April 2014, 21:43

Which compilers they target havent support condition variables?

LigH

9th April 2014, 08:48

The support of Condition Variables is not directly related to the support of the C++11 language standard.

As far as I learned yesterday (I don't have much own experience with C and C++), modern C++ language variants (2011, 2014, 2017) tend to support "meta programming", leaving the decision about the specific implementation of features to the specific platform the compiler targets for. This may be convenient for some programmers trying to write portable code, but demands a lot from the specific compiler; you know, someone has to program the compiler first to make it able to adapt its strategy according to the C++11(ff.) standard. And it is doubtful that the result will have optimal performance in every case.

It is certainly possible to have a compiler without support for C++11 "primitives" still support Condition Variables, by explicitly programming them.

The decision to prefer kernel functions of Windows Vista+ in Windows builds broke compatibility to Windows XP (yes, a deprecated platform, but there are many people who keep it alive, maybe due to specific hardware and driver availability reasons, maybe due to some level of poverty ... don't judge them). The x264 project already used a source provided workaround before, this was adapted for the x265 project to avoid this specific kernel dependency. I could imagine that C++11 compliant compilers wouldn't care about XP compatibility anymore, either...

D3C0D3R

9th April 2014, 12:18

Both latest compilers GCC 4.8 and VC12 - support conditional variables.

I could imagine that C++11 compliant compilers wouldn't care about XP compatibility anymore, either...
Microsoft for sure will do so. Only yesterday they officially stop support XP. gcc in this case more tolerant to old platforms.

D3C0D3R

9th April 2014, 12:26

Recently i faced with another trouble on 32-bit system. I run x265 on different presets
result is same familiar window pop ups: Instruction "0x004e63f0" want address "0xffffffff" for "read".

--log=4. but nothing valuable. it fails before can encode any frame
x265 [info]: build info [Windows][GCC 4.8.2][32 bit] 8bpp
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64

Ok. Then i use --no-asm. Works perfectly.
Then using trial and error method i determined that this fail was caused --asm SSSE3.
I dont know how turn on debug info on to provide additional info.

Edit: more precise --asm 0x014003F - works. --asm 0x014007F - fails. So its SSSE3 for sure.

LigH

9th April 2014, 18:30

Now if we also knew the processor model and the exact x265 build (version+patch-githash), developers would know which patch probably introduced this issue, and if it is already known or still to be fixed...

A pity you cut the log at the wrong line.

D3C0D3R

9th April 2014, 18:46

Now if we also knew the processor model
I dont think its impotant because --asm parametr determines branch, that will be executed. Pentium E5200
the exact x265 build (version+patch-githash)
changeset: 6682:bdca492dc1d7
A pity you cut the log at the wrong line.
Uncutted.
x265_6682_asm --crf 20 --y4m --preset=medium --asm=0x014007F --ssim --log=4 --psnr --csv 1_20.csv --output 1_20.265 -
y4m [info]: 512x384 fps 25/1 i420 unknown frame count
x265 [info]: HEVC encoder version +-
x265 [info]: build info [Windows][GCC 4.8.2][32 bit] 8bpp
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
x265 [info]: WPP streams / pool / frames : 6 / 2 / 1
x265 [info]: Main profile, Level-2.1 (Main tier)
x265 [info]: CU size : 64
x265 [info]: Max RQT depth inter / intra : 1 / 1
x265 [info]: ME / range / subpel / merge : hex / 57 / 2 / 2
x265 [info]: Keyframe min / max / scenecut : 25 / 250 / 40
x265 [info]: Lookahead / bframes / badapt : 20 / 4 / 2
x265 [info]: b-pyramid / weightp / weightb / refs: 1 / 1 / 0 / 3
x265 [info]: Rate Control / AQ-Strength / CUTree : CRF-20.0 / 1.0 / 1
x265 [info]: tools: rect amp rd=3 lft sao-lcu sign-hide

EDIT:Or better should send this directly into developers mailing lists?

LigH

9th April 2014, 18:52

x265 [info]: HEVC encoder version +-

Hmm, all the builds I've made so far with GCC printed their version number here. I could imagine that your x265.rc was not updated correctly.
__

P.S.:

Yes, the developer mailing list will be a good place to bring it quickly to attention. Forums are less frequently read.

The CPU type may be interesting because this issue seems to happen only on a few CPU families which do support SSSE3 (e.g. AMD Athlon/Phenom X# do not yet, or are excluded due to a slow implementation), but not yet SSE4 (Core i# and AMD FX+ will already).

D3C0D3R

9th April 2014, 18:59

Hmm, all the builds I've made so far with GCC printed their version number here. I could imagine that your x265.rc was not updated correctly.
You right.
./make-Makefiles.sh generates this:

FILEVERSION ,,0,
PRODUCTVERSION ,,0,

and i forced manually write numbers there, because otherwise it fails
x265/build/msys/x265.rc:4: syntax error
I have this troubles after 6105:0fcc87d05d10, IIRC.

LigH

9th April 2014, 19:41

Probably also an issue to investigate...

When was your last fresh clone? I'll try one right now.
__

Version info added in all required places:

#include <winresrc.h>

VS_VERSION_INFO VERSIONINFO
FILEVERSION 0,9,0,25
PRODUCTVERSION 0,9,0,25
# ...
BLOCK "StringFileInfo"
BEGIN
BLOCK "04090000"
BEGIN
VALUE "FileDescription", "HEVC video encoder"
VALUE "FileVersion", "0.9+25-bd987db26d5d"
VALUE "InternalName", "x265"
VALUE "LegalCopyright", "Multicoreware: GPLv2 or commercial"
VALUE "OriginalFilename", "libx265.dll"
VALUE "ProductName", "x265"
VALUE "ProductVersion", "0.9+25-bd987db26d5d"
END
END
BLOCK "VarFileInfo"
BEGIN
VALUE "Translation", 0x409, 1200
END
END

foxyshadis

10th April 2014, 01:56

The ASM crashes used to happen from time to time when an SSE4 instructions was included in the SSE2 branch. Hopefully Min Chen can take a look at it and see if something like that's the case here.

LigH

10th April 2014, 07:52

EDIT:Or better should send this directly into developers mailing lists?

You may have missed my later edit in my reply; so I sent a brief report on your behalf today.

raine

11th April 2014, 08:53

I just have a few quick questions regarding x265, I hope it's OK to ask them here.

Given the recent developments (hevc and opus), I'm planning to batch convert a huge film archive (6TB), mostly not-even-HD content encoded as H.264, using medium or slow preset via ffmpeg, with the hopes of shrinking the archive. I don't know how important psy-rd, trellis, intra-refresh etc. are.

Is it mature enough? (for an ordinary eye, for a home archive. I'm not Netflix or Hollywood so my requirements aren't that high :) )
Are there important improvements waiting in the queue? Should I start already or is it worth waiting?
What parameters do you suggest for encoding? I'm planning to go with -preset slow only, without using -x265-params, but if it turns out to be too slow, I can switch to medium with -x265-params me=star. (as far as I know, there are no -tune film or psy-rd based tunings yet).

I made a small experiment with a 1280x720 H264 video from my archive, using medium preset with crf=22. The resulting file was less than half of the original file with no visible (to me, a keen eye or PSNR/etc may differ) reduction in quality. So it seems it's definitely worth trouble. Even with a recent Haswell i7 processor, the video encoding (I used -c:a copy) was a bit slow (~14 FPS), though this is expected. I hope it will get faster in time though.

I will experiment with slow and slower and make a detailed post next time.

LigH

11th April 2014, 08:58

raine

11th April 2014, 09:24

Try to estimate the energy costs caused by the required encoding time and decide if it is worth to pay your energy supplier for weeks or months of converting.

The faster you choose the preset, the less efficient a further compression will be. And it will certainly be lossy as well. As far as I remember, there is still some structure flattening. But that is the cost of efficient redundancy removal: Sometimes it is too optimistic in deciding what may be unimportant.

Thanks for the quick response! The energy cost is OK, I have a low-TDP Haswell, I didn't even heard any fan noise during encoding. I also expect the loss, it's lossy -> lossy after all; as long as I don't realize it, it's OK. Maybe this translates to some lower CRF; I used 22.

LigH

11th April 2014, 09:39

@ D3C0D3R:

Can you provide a call stack of the crash to the developer mailing list? That would help finding the close range of the reason; the developers don't have the same hardware to check it.

But don't ask me how to do that... Let's hope that Windows will display a verbose crash dialog where you can extract details from. Crash address + your specific EXE may be a minimal anchor.

Well, maybe it can also be provoked with a better CPU by masking SSE4 out.

D3C0D3R

11th April 2014, 19:40

You may have missed my later edit in my reply; so I sent a brief report on your behalf today.

Thank you! I've have look at x265-devel yesterday, but they tried to fix something unrelated, because --n0-asm works.

I will try to retrive stacktrace, or some debug info.
Its obvious that bug-report instruction here http://www.videolan.org/developers/x265.html ./configure --enable-debug simply copy-pasted from x264 and should be updated.

I suppose CMAKE_BUILD_TYPE, CMAKE_CXX_FLAGS must be set to Debug.

D3C0D3R

11th April 2014, 21:57

Ok. I compile x265 with CMAKE_BUILD_TYPE = Debug.
And run this:
gdb --args x265_debug --crf 20 --input ffmpeg_g.exe --input-depth 8 --input-res 320x240 --fps 20 --preset=medium --asm=0x014007F --ssim --log=4 --output 1_1.265

Then type "run" in gdb console:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 2916.0xf28]
0x00533950 in x265_patial_butterfly_inverse_internal_pass2_ssse3 ()
(gdb) bt
#0 0x00533950 in x265_patial_butterfly_inverse_internal_pass2_ssse3 ()
#1 0x00533b6e in x265_idct8_ssse3 ()
#2 0x0441f339 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb) disass $pc-32,$pc+32
Dump of assembler code from 0x533930 to 0x533970:
0x00533930 <x265_patial_butterfly_inverse_internal_pass1_ssse3+368>: jb 0x533916 <x265_patial_butterfly_inverse_internal_pass1_ssse3+342>
0x00533932 <x265_patial_butterfly_inverse_internal_pass1_ssse3+370>: pop %es
0x00533933 <x265_patial_butterfly_inverse_internal_pass1_ssse3+371>: psubd %xmm5,%xmm1
0x00533937 <x265_patial_butterfly_inverse_internal_pass1_ssse3+375>: psrad $0x7,%xmm1
0x0053393c <x265_patial_butterfly_inverse_internal_pass1_ssse3+380>: packssdw %xmm1,%xmm4
0x00533940 <x265_patial_butterfly_inverse_internal_pass1_ssse3+384>: movq %xmm4,0x30(%edi)
0x00533945 <x265_patial_butterfly_inverse_internal_pass1_ssse3+389>: movhps %xmm4,0x40(%edi)
0x00533949 <x265_patial_butterfly_inverse_internal_pass1_ssse3+393>: ret
0x0053394a <x265_patial_butterfly_inverse_internal_pass1_ssse3+394>: nopw 0x0(%eax,%eax,1)
=> 0x00533950 <x265_patial_butterfly_inverse_internal_pass2_ssse3+0>: movdqa (%edi),%xmm0
0x00533954 <x265_patial_butterfly_inverse_internal_pass2_ssse3+4>: movdqa %xmm0,%xmm4
0x00533958 <x265_patial_butterfly_inverse_internal_pass2_ssse3+8>: pshufb 0x6a7950,%xmm4
0x00533961 <x265_patial_butterfly_inverse_internal_pass2_ssse3+17>: pmaddwd 0x6a7960,%xmm4
0x00533969 <x265_patial_butterfly_inverse_internal_pass2_ssse3+25>: phsubd %xmm4,%xmm5
0x0053396e <x265_patial_butterfly_inverse_internal_pass2_ssse3+30>: pshufd $0x4e,%xmm4,%xmm4
End of assembler dump.

eax 0xc55b90 12934032
ecx 0x163d900 23320832
edx 0x10 16
ebx 0x30 48
esp 0x10bf8c8 0x10bf8c8
ebp 0x623990 0x623990 <_ZSt16__convert_from_vRKPiPciPKcz+6437264>
esi 0x623970 6437232
edi 0x10bf8cc 17561804
eip 0x4e63f0 0x4e63f0 <x265_patial_butterfly_inverse_internal_pass2_ssse3>
eflags 0x10216 [ PF AF IF RF ]
cs 0x1b 27
ss 0x23 35
ds 0x23 35
es 0x23 35
fs 0x3b 59
gs 0x0 0

xmm0 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0}, v16_int8 = {0x31, 0xf5, 0xff, 0xff,
0x4c, 0x8, 0x0, 0x0, 0xb1, 0x3, 0x0, 0x0, 0xd7, 0x6, 0x0, 0x0}, v8_int16 = {0xf531, 0xffff, 0x84c, 0x0,
0x3b1, 0x0, 0x6d7, 0x0}, v4_int32 = {0xfffff531, 0x84c, 0x3b1, 0x6d7}, v2_int64 = {0x84cfffff531,
0x6d7000003b1}, uint128 = 0x000006d7000003b10000084cfffff531}
xmm1 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x8000000000000000}, v16_int8 = {0xd1, 0x4,
0x0, 0x0, 0xea, 0x0, 0x0, 0x0, 0x22, 0x4, 0x0, 0x0, 0xe5, 0xf6, 0xff, 0xff}, v8_int16 = {0x4d1, 0x0, 0xea,
0x0, 0x422, 0x0, 0xf6e5, 0xffff}, v4_int32 = {0x4d1, 0xea, 0x422, 0xfffff6e5}, v2_int64 = {0xea000004d1,
0xfffff6e500000422}, uint128 = 0xfffff6e500000422000000ea000004d1}
xmm2 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x8000000000000000, 0x8000000000000000},
v16_int8 = {0x80, 0x4, 0x80, 0x4, 0x80, 0xfb, 0x40, 0xf9, 0xc0, 0xfd, 0x0, 0x0, 0x0, 0x0, 0x80, 0xfb},
v8_int16 = {0x480, 0x480, 0xfb80, 0xf940, 0xfdc0, 0x0, 0x0, 0xfb80}, v4_int32 = {0x4800480, 0xf940fb80,
0xfdc0, 0xfb800000}, v2_int64 = {0xf940fb8004800480, 0xfb8000000000fdc0},
uint128 = 0xfb8000000000fdc0f940fb8004800480}
xmm3 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x8000000000000000, 0x0}, v16_int8 = {0xa7, 0xf8,
0xff, 0xff, 0xaf, 0xff, 0xff, 0xff, 0x74, 0xfe, 0xff, 0xff, 0x0, 0x0, 0x0, 0x0}, v8_int16 = {0xf8a7, 0xffff,
0xffaf, 0xffff, 0xfe74, 0xffff, 0x0, 0x0}, v4_int32 = {0xfffff8a7, 0xffffffaf, 0xfffffe74, 0x0}, v2_int64 = {
0xffffffaffffff8a7, 0xfffffe74}, uint128 = 0x00000000fffffe74ffffffaffffff8a7}
xmm4 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x8000000000000000, 0x8000000000000000},
v16_int8 = {0xdb, 0x6, 0x41, 0x4, 0x39, 0xfc, 0x1, 0xf9, 0xd1, 0x4, 0xea, 0x0, 0x22, 0x4, 0xe5, 0xf6},
v8_int16 = {0x6db, 0x441, 0xfc39, 0xf901, 0x4d1, 0xea, 0x422, 0xf6e5}, v4_int32 = {0x44106db, 0xf901fc39,
0xea04d1, 0xf6e50422}, v2_int64 = {0xf901fc39044106db, 0xf6e5042200ea04d1},
uint128 = 0xf6e5042200ea04d1f901fc39044106db}
xmm5 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0}, v16_int8 = {0x80, 0x82, 0x0, 0x0, 0xc0,
0xd5, 0x0, 0x0, 0xc0, 0x5, 0xfe, 0xff, 0x0, 0x87, 0x0, 0x0}, v8_int16 = {0x8280, 0x0, 0xd5c0, 0x0, 0x5c0,
0xfffe, 0x8700, 0x0}, v4_int32 = {0x8280, 0xd5c0, 0xfffe05c0, 0x8700}, v2_int64 = {0xd5c000008280,
0x8700fffe05c0}, uint128 = 0x00008700fffe05c00000d5c000008280}
xmm6 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0}, v16_int8 = {0x0, 0x8, 0x0, 0x0, 0x0,
0x8, 0x0, 0x0, 0x0, 0x8, 0x0, 0x0, 0x0, 0x8, 0x0, 0x0}, v8_int16 = {0x800, 0x0, 0x800, 0x0, 0x800, 0x0,
0x800, 0x0}, v4_int32 = {0x800, 0x800, 0x800, 0x800}, v2_int64 = {0x80000000800, 0x80000000800},
uint128 = 0x00000800000008000000080000000800}
xmm7 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x8000000000000000, 0x8000000000000000},
v16_int8 = {0x5e, 0xfe, 0x62, 0xf5, 0x27, 0xfc, 0x7e, 0xff, 0xf7, 0xf5, 0xf3, 0x9, 0x0, 0xf6, 0x9d, 0xfe},
v8_int16 = {0xfe5e, 0xf562, 0xfc27, 0xff7e, 0xf5f7, 0x9f3, 0xf600, 0xfe9d}, v4_int32 = {0xf562fe5e,
0xff7efc27, 0x9f3f5f7, 0xfe9df600}, v2_int64 = {0xff7efc27f562fe5e, 0xfe9df60009f3f5f7},
uint128 = 0xfe9df60009f3f5f7ff7efc27f562fe5e}

LigH

11th April 2014, 22:17

I hope this function name already helps narrowing the search. If not, the developers may need your ffmpeg_g.exe together with this result.

D3C0D3R

12th April 2014, 13:57

the developers may need your ffmpeg_g.exe together with this result.

Post updated. Failure is _completly_ independent from yuv-input.

I look for some public-avaible builds. one which i found ran under 32-bit xp, from x265.ru (8-bit 0.9+29). And it fails exact way, at exact movdqa, only functions names unavailble in debugger, because exe without debug-info.

Sorry, now for me convenient to reply here instead mailing lists.

LigH

12th April 2014, 14:01

They are already on a track. IIUC, here is an instruction that may lead to a crash on SSSE3 only CPUs when the stack is not aligned. Gosh, how much do you need to know about it to discover that?!

smegolas

12th April 2014, 18:36

x265_Project

13th April 2014, 23:43

We were at the NAB show in Las Vegas last week, giving demonstrations to many of the companies attending, showing x265 encodes of popular video sequences side by side with x264 encodes (the gold standard for quality today). Attendees were blown away by the quality of x265. We demonstrated 2 streams played back in sync, showing the middle 50% of two 4K clips on a 4K monitor. Here is a photo of our demo... http://x265.org/NAB2014_CrowdRun4K.jpg

Sample frame grabs from Crowd_Run4K50 @ 4 Mbps are here... http://x265.org/CrowdRun4K_4Mbps.7z
You can repeat these tests yourself, using the SVT clips from http://media.xiph.org/video/derf/ - Crowd Run, Old Town Cross, Ducks Take Off, In To Tree.... take your pick.

H.265 provides for much higher video coding accuracy. The thing you will notice is that x265 encodes don't have all of the temporal artifacts of H.264. x265 is typically winning comparisons against x264 even at half the bit rate. There were cases where x265 was preferred even at 1/4 the bit rate
(Crowd Run 4K - x265 veryslow 4 Mbps vs x264 veryslow @ 16 Mbps), due to the lack of temporal artifacts and macroblocking in x265.

Blue_MiSfit

14th April 2014, 05:16

x265_Project

14th April 2014, 06:14

I wish I had stopped by your booth :)

This is an impressive demonstration, but I think x265 is still too slow for any real use - especially for 4k. I haven't looked at alternatives yet (the glacial broadcast industry is still a long ways away from HEVC), but is there hope for significant speedup or are we already to the point where further ASM optimizations could give only 10-20% more?

To amend the above, I have looked at Elemental Live. Their HEVC encoder is supposedly real-time for 4kp30 using a single server, and 4kp60 using two servers strapped together. This is of course using scads of very powerful and expensive GPUs, but would the same thing theoretically be possible with today's technology using CPU-only encoders like x265? Let's pretend we have a beastly quad-socket fire breathing 48 core monster at our disposal.. :devil:

Thanks,
Derek
We had a private suite. We'll look at getting a booth next year.

It's true that you don't get these significant improvements in video compression efficiency for free. HEVC requires substantially higher compute resources for a given performance level. x265 can scale performance nicely on multiple socket machines, and we will continue to optimize for our studio / broadcast customers that use these systems.

A number of current and pending x265 licensees are building real-time encoders. One was demonstrating real-time 4K encoding based on x265, using multiple processors (dividing the incoming stream into segments). It looked great!

Procrastinating

15th April 2014, 07:57

Is the 1.0 release intended to be the one which is "fit for public consumption", or will it be progression as usual?

Kurtnoise

15th April 2014, 12:22

https://bitbucket.org/multicoreware/x265/wiki/RoadMap
https://bitbucket.org/multicoreware/x265/wiki/TODO

raine

15th April 2014, 15:20

No, this would be not a good idea.

x265 is not mature enough yet. It is still in beta. Everybody complains about blurring with live action content. Witness how much x264 improved since the first year. Will be same with x265.

There are no hardware decoders so we don't know what 'correct' settings are to ensure widespread compatiblity. (eg HEVC equivalent of H.264 HP@L4.1)

6TB isn't really a huge collection. Pretty soon it will fit on one disk. If you have run out of space just buy more storage, it would be cheaper than your electricity bill for encoding that many movies.
Thanks so much! I think I will wait until the stable 1.0 release then (assuming all items in Quality/Efficiency TODOs are cleared).
However, I haven't seen any blurring so far (using x265 0.9, ffmpeg 2.2.1) with crf through 22 to 26. Is this an issue with the older versions?

As I mentioned above, I have a low-TDP Haswell CPU. The power supply itself is 80W (comparable to an old-fashioned bulb), so there is really no issue regarding the electricity usage. When I say Haswell, people seem to think of a big ATX machine with 800W power supply :)

And BTW, on average, I found that x265 version is 40-60% of the original file. For HD content, the encoding rate is around 10fps whereas for low-definition videos (360p or even less) it is around 40fps. I couldn't see any visual loss using crf 22-24, and it is very difficult for me to tell them apart with crf=26.

In my case, buying more storage is not a problem, but having external harddisks floating around is; I'm trying to minimize the number of harddisks, while still having space to add more movies. And yes, I'm planning to buy a 6TB harddisk :)

mandarinka

15th April 2014, 15:36

x265_Project

16th April 2014, 00:54

BTW, about that "1.0". It isn't going to be a particularly significant, complete, "stable" or how you want to call it milestone. It looks like it will be more of a normal, scheduled release like the ones before it.
See on the mailing list (https://mailman.videolan.org/pipermail/x265-devel/2014-April/004128.html).
Well, I'm not going to argue with Steve, but I should point out that x265 has matured a great deal since we started the project, and it's already shipping with a number of commercial solutions.

The 1.0 milestone is well timed. We did map out these milestones early on with a plan to reach 1.0 with a fairly feature-complete and fully usable implementation, and we're on track for that.

phate89

16th April 2014, 03:01

Thanks so much! I think I will wait until the stable 1.0 release then (assuming all items in Quality/Efficiency TODOs are cleared).
However, I haven't seen any blurring so far (using x265 0.9, ffmpeg 2.2.1) with crf through 22 to 26. Is this an issue with the older versions?

As I mentioned above, I have a low-TDP Haswell CPU. The power supply itself is 80W (comparable to an old-fashioned bulb), so there is really no issue regarding the electricity usage. When I say Haswell, people seem to think of a big ATX machine with 800W power supply :)

And BTW, on average, I found that x265 version is 40-60% of the original file. For HD content, the encoding rate is around 10fps whereas for low-definition videos (360p or even less) it is around 40fps. I couldn't see any visual loss using crf 22-24, and it is very difficult for me to tell them apart with crf=26.

In my case, buying more storage is not a problem, but having external harddisks floating around is; I'm trying to minimize the number of harddisks, while still having space to add more movies. And yes, I'm planning to buy a 6TB harddisk :)
The problem of the energy needed for that amount of transcoding is still there because your cpu might need less energy but it will take more time. It's actually possible that a hungry cpu will get better results in power consumption because it could have a better cpu computing power/electric power ratio:
http://www.cpubenchmark.net/power_performance.html
and if you have to encode enough files it will probably costs more the energy than a new disk.
Btw even if the cost isn't a problem to get the advantage of a disk less and you still want to do it even knowing that a good part of the quality will go away and you will not be able to do it again because the loss would be too much (2 low bitrate compressions even with the better encoder in the world give terrible results) it's still suggested to wait at least until x265 has all the features of x264.
Because if for you the quality is ok now the next year you will get the same quality with 5/10/20/25% less bitrate (there's still room for a lot of improvements especially with psy-rdo) and consuming 5/10/20/25% less power (because it will be faster and more optimized)...

raine

16th April 2014, 04:31

I don't think recompressing video collections was ever a good idea.
You will kill a great deal of the content, and what is really the gain? /are you planning to do this each five years when a new scheme or improved encoders are available?/

BTW, about that "1.0". It isn't going to be a particularly significant, complete, "stable" or how you want to call it milestone. It looks like it will be more of a normal, scheduled release like the ones before it.

See on the mailing list (https://mailman.videolan.org/pipermail/x265-devel/2014-April/004128.html).

Wow, thanks for the friendly reply.

The gain is the reduction in the file size 40-60% (in certain non-trivial cases I got to 25%, such as a 2.5 hrs of 640x480 divx converted via x265 @crf=26; this appears to be the case with old wmv and divx 360p-480p videos), and actually, everything I have can be easily found somewhere on the net. Yes, I'm familiar with the downsides of lossy -> lossy transcoding. My point is, I'm apparently not killing a great deal of content. If the extra loss is not visible to my eyes, I'm OK with that.

As a matter of fact, this is the first time I'm going to do this. Among other things, I have ancient low-definition MPEG videos (created long before x264 even existed) that are totally wasting space.

And no, I probably won't transcode them again with x269.

The problem of the energy needed for that amount of transcoding is still there because your cpu might need less energy but it will take more time. It's actually possible that a hungry cpu will get better results in power consumption because it could have a better cpu computing power/electric power ratio:
http://www.cpubenchmark.net/power_performance.html
and if you have to encode enough files it will probably costs more the energy than a new disk.
Btw even if the cost isn't a problem to get the advantage of a disk less and you still want to do it even knowing that a good part of the quality will go away and you will not be able to do it again because the loss would be too much (2 low bitrate compressions even with the better encoder in the world give terrible results) it's still suggested to wait at least until x265 has all the features of x264.
Because if for you the quality is ok now the next year you will get the same quality with 5/10/20/25% less bitrate (there's still room for a lot of improvements especially with psy-rdo) and consuming 5/10/20/25% less power (because it will be faster and more optimized)...
Luckily, operational speed per watt is not a linear function, and more importantly, encoding FPS numbers I have look actually good (I know, they will look much better with a 4770K, but I'm OK being 10% slower at half TDP).

And thanks a lot, this is the kind of stuff I wanted to know about. x264 feature-parity might be too much, but I will wait at least until we have psy-rdo.

fumoffu

16th April 2014, 15:54

benwaggoner

16th April 2014, 17:46

If the source is good quality and sharp the blurring usually is very tolerable and not that noticeable. The problem is much more visible if you have source encoded for example with not the best h264 encoder (pretty much all encoders except x264 including hardware solutions) - now the things that were not very detailed are becoming completely flat.
Also I'm surprised that you get good results at such low resolutions - I would thing that x265 would be better than x264 mainly in HD resolution since from what I understand the main improvements are bigger CU and better motion search. Have you tried re-encoding those movies with x264 using good-high settings? Maybe the results would be comparable?
HEVC has a bigger differential advantage over H.264 at high frame sizes (particularly >1080p), but there's lots of good stuff in there that will help significantly at every frame size.

I wouldn't be surprised if a x265 as well-tuned as x264 is today might only need 40% the bitrate at 4K resolutions and 50% at lower resolutions to hit the same subjective quality.

LigH

16th April 2014, 19:32

sKRUVEN

16th April 2014, 20:43

Oh, Ben, you just cut the cake I put into the oven today!

I was not yet able to encode 4K video because it takes so much time (and a Phenom-II X4 is the best I can spend here, and x265 does not even try to use SSE3 instructions on it)... but some 1080p test samples already tell an interesting tale:

I encoded some 10 s clips from Derf's Xiph media archive (crowd_run; ducks_take_off; in_to_tree) with x265 --crf 30 --preset veryslow and also with x264 in 2-pass mode to get

the same bitrate
the double bitrate
the triple bitrate
and even the quadruple bitrate in one case

and would like to invite (https://www.mediafire.com/folder/6lfp2jlygogwa/HEVC) you all to compare and rate.

When I am able to use a better CPU, I may even try the 2160p versions...
I'm currently doing the same thing but in 2160p (all five sequences from SVT_MultiFormat_2160p50 but slowed down to 25p). I've got a 4770k so i can use avx2 so the speed is not that bad. But I ran into some problems that maybe someone here can sort out. I'm trying to do some visual comparisons between x264 and x265 and for some reason x265 (crf22 ~48Mbps slow preset) is looking worse then x264 (vbr2pass 50Mbps slow preset)

I use avs4x265 (with the 0.9+53 8bpp build from x265.ru) then remux it with mp4box
avs4x265.exe --crf 22 --preset slow -o output.hevc input.avs
mp4box.exe -add output.hevc#trackID=1:fps=25.0 -new output.mp4

I use MPC-BE, Lav filer, madvr for playback (all up to date) and use the screen grab command (alt-i) to export frames for comparison. Anyone know why the x265 version is less detailed? The playback is not smooth either, anyone know a better decoder for 4k x265 material or is not possible yet for 4k?

benwaggoner

16th April 2014, 21:21

But I run into some problems that maybe someone here can sort out. I'm trying to do some visual comparisons between x264 and x265 and for some reason x265 (crf22 ~48Mbps slow preset) is looking worse then x264 (vbr2pass 50Mbps slow preset)?
You're not doing any perceptual tuning in your setting, so it'll default to tuning for PSNR, while x264 will default to tuning for Rate Factor.

At a minimum, you should use --tune ssim. --aq-mode 2 and --rdpenalty 1 may help as well. I'm not sure how frame size and content-dependent they are.

sKRUVEN

16th April 2014, 22:09

You're not doing any perceptual tuning in your setting, so it'll default to tuning for PSNR, while x264 will default to tuning for Rate Factor.

At a minimum, you should use --tune ssim. --aq-mode 2 and --rdpenalty 1 may help as well. I'm not sure how frame size and content-dependent they are.
Oh, that might be it, the source contains alot of film grain and the x265 version looks denoised so there is less grain and detail compared to the x264 one. Will try those tweeks and see if it helps to retain the detail.

Edit. That did nothing, the one with --tune ssim and --aq-mode 2 look exactly the same as the old one. Don't even know if it worked or that it default ssim since the new file has the exact same file size.

Atak_Snajpera

16th April 2014, 22:34

--tune film?

LigH

16th April 2014, 22:47

There are several tunings for x264; but only few tunings for x265, and it is not really certain if they already make any difference at all.

sKRUVEN

16th April 2014, 23:09

x265_Project

17th April 2014, 02:04

Oh, that might be it, the source contains alot of film grain and the x265 version looks denoised so there is less grain and detail compared to the x264 one. Will try those tweeks and see if it helps to retain the detail.

Edit. That did nothing, the one with --tune ssim and --aq-mode 2 look exactly the same as the old one. Don't even know if it worked or that it default ssim since the new file has the exact same file size.

--tune ssim is on by default

foxyshadis

17th April 2014, 02:20

When it comes to recompressing with an immature codec, start with the stuff you care the least about yet takes up the most extra space. Ridnacs and other space-visualizing tools are a great help. x265 may not quite be mature yet, but it's definitely juvenile level (without even writing angsty Twilight fan-fiction subtitles), seeing lots of steady quality gains, and the time you buy archiving less-important stuff lets you wait a little bit longer for the best. Of course it's tempting to concentrate on your favorite movies ever first, but you'll just want to re-do them every time the codec improves.

Obviously the easiest way to save space and time is to decide that hey, I'm never going to watch that movie again in my life, and chuck it. :D

x265_Project

17th April 2014, 04:47

Here are some frames. http://speedy.sh/A6Bjh/CrowdRun-2160p50-CgrLevels-MASTER-SVTdec05.rar

x265 do look cleaner, however it looks less true to the original then the x264 one. So what do you guys think? Is it that x265 is tuned to be less noisy or am I doing something wrong?

LigH how did your tests look? Did x265 retain more grain than x264?

sKRUVEN - interesting results. As we've discussed here, x264 and x265 handle things in very different ways.

As a general rule, when you're trying to evaluate video compression, comparing still frames has very limited value. Still frames show the differences in spatial detail, but you won't be able to see or understand the level of temporal accuracy or noise when you view still frames. You really need to watch the video, side by side, in sync, on the same monitor, or on identical hardware with displays calibrated to match.

For example, to evaluate two 1080P encodes side by side on a 1080P monitor, you could show the left half of one encode side by side with the right half of the other encode. Or you could crop both streams to show only the middle 50% (horizontally), then offset one by 480 pixels to the left, and the other by 480 pixels to the right. If you have a 4K monitor, you can simply composite two 1080P encodes side by side.

The best way for you to do this would be to decode both streams you are comparing to a YUV file, then composite the two decoded YUV files into a single side-by-side YUV file. You could do this in a video editor, cropping and shifting them so that they are side by side, and then exporting as a YUV file. You may also be able to do this with FFMPEG... see http://ianfeather.co.uk/compare-two-webpagetest-videos-using-ffmpeg/ Then, play the composited YUV with YUVplayer or FFPlay. I know this sounds like a big pain, but the result is very revealing.

raine

17th April 2014, 10:11

If the source is good quality and sharp the blurring usually is very tolerable and not that noticeable. The problem is much more visible if you have source encoded for example with not the best h264 encoder (pretty much all encoders except x264 including hardware solutions) - now the things that were not very detailed are becoming completely flat.
Also I'm surprised that you get good results at such low resolutions - I would think that x265 would be better than x264 mainly in HD resolution since from what I understand the main improvements are bigger CU and better motion search. Have you tried re-encoding those movies with x264 using good-high settings? Maybe the results would be comparable?

I just tried: with x265 crf=24, the video size was 195MB, using x264 crf=24 -tune film I got 405MB. Both look same as the source (to my eyes). On the bright side, x264 was 8x faster.
BTW, the original video stream is a 1.1GB DX5 stream.

LigH

17th April 2014, 10:21

CRF 24 for x264 will probably not mean exactly the same as CRF 24 for x265. But regarding the "level of annoyance" of quality loss, from my experience, it is pretty similar.

raine

17th April 2014, 10:48

CRF 24 for x264 will probably not mean exactly the same as CRF 24 for x265. But regarding the "level of annoyance" of quality loss, from my experience, it is pretty similar.

Well, they all look same to me (dx5, x264, x265). I will try to find the highest crf for each at which I can notice distortion.
Edit: I started noticing loss at crf=25 for both. (I should note that I later on tried playing side-by-side with the original video, and slight distortions in some particular frames become apparent event at crf=24 for both. I can't tell them apart @crf=20, but the video size is more than 2x)

LigH

17th April 2014, 10:54

If neither looked bad, you can't tell which looked worse. ;)

fumoffu

17th April 2014, 14:23

I just tried: with x265 crf=24, the video size was 195MB, using x264 crf=24 -tune film I got 405MB. Both look same as the source (to my eyes). On the bright side, x264 was 8x faster.
BTW, the original video stream is a 1.1GB DX5 stream.

Emm ...are you sure you don't need glasses? :p
Sorry for being smartass but crf24 is rather poor quality especially on lower resolution sources. Could you maybe post some screens here?
Also I was talking about using high = slower settings for x264, something like:
--preset slow --open-gop --bframes 5 --deblock -1:-1 --subme 10 --trellis 2 --psy-rd 0.3:0.15
I know it won't save 200MB but it should help a bit.

raine

17th April 2014, 15:58

Emm ...are you sure you don't need glasses? :p
Sorry for being smartass but crf24 is rather poor quality especially on lower resolution sources. Could you maybe post some screens here?
Also I was talking about using high = slower settings for x264, something like:
--preset slow --open-gop --bframes 5 --deblock -1:-1 --subme 10 --trellis 2 --psy-rd 0.3:0.15
I know it won't save 200MB but it should help a bit.
Well, I can't. That particular video is NSFW :D (although maybe I can upload some OK parts, like first few minutes). (Maybe this is the reason for this amount of reduction in filesize since I get around 40-60% for ordinary movies).
However, I can tell them apart when I play the video side-by-side with the original. What I mean is, I can't tell if there is extra loss introduced by x265. At crf=20, I can't tell them apart even side-by-side. Maybe I do need glasses though, but the important parameter for transcoding my archive is whether I notice it or not :)

Quick question, how do I pass these parameters via ffmpeg? Edit: found it: x264opts and replace : with ,

Edit: I sent a PM containing the info on accessing to the first few minutes.

smegolas

17th April 2014, 16:40

As a general rule, when you're trying to evaluate video compression, comparing still frames has very limited value. Still frames show the differences in spatial detail, but you won't be able to see or understand the level of temporal accuracy or noise when you view still frames. You really need to watch the video, side by side, in sync, on the same monitor, or on identical hardware with displays calibrated to match.

If a still image shows me that the grain is not retained, it's fair to say the grain has not been retained. It's not going to magically come back in motion.

benwaggoner

17th April 2014, 18:09

--tune ssim is on by default
Cool. I didn't notice that change. One more simplification to my command lines :)!

benwaggoner

17th April 2014, 18:22

However, I can tell them apart when I play the video side-by-side with the original. What I mean is, I can't tell if there is extra loss introduced by x265. At crf=20, I can't tell them apart even side-by-side. Maybe I do need glasses though, but the important parameter for transcoding my archive is whether I notice it or not :)
So they look the same at CRF 20 and they have equivalent quality but show different minor artifacts when compared at CRF 24.

That makes perfect sense to me. There are multiple routes to "good enough" quality. "Imperceptibly different from the source" and "no visible degradation in encoded stream" are different targets. Something can look a little different from the source but still look great if the viewer isn't comparing it to anything.

And I expect HEVC to have some real advantages here in that its artifacts are going to be less visible. There was an academic paper a while back showing that the viewer preference for HEVC over H.264 was greater than PSNR (and maybe SSIM) would have predicted. The comparison was between the reference encoders, so not directly applicable to x265 v. x264 today. But it certainly gives hope that mature HEVC can have some big relative bitrate savings when targeting "good enough" quality over constrained bandwidths. Also if the degradation is "smoother" we can probably get away with higher frame sizes since the worst frames are less likely to get catastrophically bad.

HEVC is a great next step from H.264, which was the first codec that did a good job of degrading into softness and loss of detail before obvious block patterns started emerging like MPEG-2, MPEG-4 part 2, and to a lesser degree VC-1. Small and variable block sizes plus in-loop deblocking was a very powerful combination.

A key VC-1 developer told me once that the biggest error he wished he could correct was having a mode with a stronger in-loop deblocking filter. VC-1's design was focused more on "minimum bitrate for transparent encoding" and could have done a lot more with "maximum perceptual quality at very low bitrates." Although VC-1 was also designed assuming that the out-of-loop VC-1 postprocessing stage would be used, and would be enhanced over time.

Anyway, HEVC's tuning around deblocking and block sizes seem to really take it to the next stage of lower bitrates just losing detail rather than having a block pattern emerge. Even H.264 High Profile still has trouble with smooth gradients at low bitrates.

fumoffu

17th April 2014, 19:21

I saw the NSFW sample video and it's quality isn't the best - a lot of visible compression artifacts already, so it's hard to compare codecs on such video because you are not sure which artifacts were already there and which were introduced during re-encoding. That said x265 can be better at re-encode such videos because it will blur out some of those initial artifiacts while x264 will waste bitrate trying to preserve them ;)

sKRUVEN

17th April 2014, 19:39

sKRUVEN - interesting results. As we've discussed here, x264 and x265 handle things in very different ways.

As a general rule, when you're trying to evaluate video compression, comparing still frames has very limited value. Still frames show the differences in spatial detail, but you won't be able to see or understand the level of temporal accuracy or noise when you view still frames. You really need to watch the video, side by side, in sync, on the same monitor, or on identical hardware with displays calibrated to match.

For example, to evaluate two 1080P encodes side by side on a 1080P monitor, you could show the left half of one encode side by side with the right half of the other encode. Or you could crop both streams to show only the middle 50% (horizontally), then offset one by 480 pixels to the left, and the other by 480 pixels to the right. If you have a 4K monitor, you can simply composite two 1080P encodes side by side.

The best way for you to do this would be to decode both streams you are comparing to a YUV file, then composite the two decoded YUV files into a single side-by-side YUV file. You could do this in a video editor, cropping and shifting them so that they are side by side, and then exporting as a YUV file. You may also be able to do this with FFMPEG... see http://ianfeather.co.uk/compare-two-webpagetest-videos-using-ffmpeg/ Then, play the composited YUV with YUVplayer or FFPlay. I know this sounds like a big pain, but the result is very revealing.
I've done some testing now with side by side comparison. And x265 eliminates a lot of grain, to the point were its visible not only in stills but also in side by side comparison (4k cropped to 1080p since i don't have a 4k display). It seems that x265 is optimized for low bitrate, as far as i can tell from this test is that even a bluray-like x264 encodes preserve more film grain then x265. I'm sure this isn't a problem for most sources, but there seems to be a problem with high quality lossless grainy sources. I don't wanna be rude or anything but is it tuned this way on purpose to allow for better efficiency? 50% better efficiency as stated in the press for other encoders isn't that impressive if its denoising the video :P And don't get me wrong, the x265 looks great, it's a lot cleaner and most would probably argue that it looks "better" but it still does a lot of denoising, which is great for low bitrate encodes but maybe not so much for high bitrate ones.

And two other questions: Will a abr encode be exactly the same as a crf encode if they got the same bitrate? And when will there be an option for vbr2pass?

x265_Project

17th April 2014, 20:36

If a still image shows me that the grain is not retained, it's fair to say the grain has not been retained. It's not going to magically come back in motion.
True. I didn't say that comparing still frames has no value... just limited value. It makes sense to compare still frames when you are looking for film grain in an area that otherwise has low detail. But for other spatial details you won't be able to easily see if their position is accurate (or whether there is motion judder). You won't be able to see if all of the apparent details should be in the picture or not. For example, temporal noise in H.264 encodes can sometimes produce artifacts that appear as real detail in a still frame, but when you watch the video you'll see that these details are rapidly coming and going, creating nice texture in a still frame, but this high frequency changing texture is perceived as noise when you watch the video.

x265_Project

17th April 2014, 21:15

If a still image shows me that the grain is not retained, it's fair to say the grain has not been retained. It's not going to magically come back in motion.

I've done some testing now with side by side comparison. And x265 eliminates a lot of grain, to the point were its visible not only in stills but also in side by side comparison (4k cropped to 1080p since i don't have a 4k display). It seems that x265 is optimized for low bitrate, as far as i can tell from this test is that even a bluray-like x264 encodes preserve more film grain then x265. I'm sure this isn't a problem for most sources, but there seems to be a problem with high quality lossless grainy sources. I don't wanna be rude or anything...
No worries... we have these same discussions all day every day, and we don't mind discussing the issues in public. It's how open source projects move forward.
... but is it tuned this way on purpose to allow for better efficiency? 50% better efficiency as stated in the press for other encoders isn't that impressive if its denoising the video :P And don't get me wrong, the x265 looks great, it's a lot cleaner and most would probably argue that it looks "better" but it still does a lot of denoising, which is great for low bitrate encodes but maybe not so much for high bitrate ones.
No, it's not tuned this way on purpose. You're just seeing one of the differences between HEVC and AVC (H.265 and H.264). We continue to investigate ways to tune our algorithms to optimize these tradeoffs (for example, the tradeoff between more spatial detail and less temporal noise).
And two other questions: Will a abr encode be exactly the same as a crf encode if they got the same bitrate?
No. These are two different rate control modes, and the allocation of bits is going to be different.
And when will there be an option for vbr2pass?
When we have a licensee who funds the development of this feature. We expect this to happen at some point, but the work hasn't been funded yet, and so work hasn't started.

Dark Shikari

17th April 2014, 21:24

sKRUVEN

17th April 2014, 21:49

No worries....
Thanks for your answers. Gonna murder my cpu some more now, avx2 is fing brutal. And btw, did a crf16 test and yeah it was pretty much transparent, keep up the good work.

I don't think it's reasonable to expect x265 to ever have similar quality to x264 at half the bitrate when most of the bitrate is spent on incompressible grain.
Didn't expect that either :P But it looked subjectively worse at the same bitrate in this case since it took away to much detail for my taste.

benwaggoner

17th April 2014, 21:59

Retaining grain requires bitrate (though things like psy-RD help). The compression gap between encoders drops dramatically when grain comes into the picture, because it's just random noise and isn't very compressible. x264 might be 4 times better than MPEG-2 on some sources, but you're not going to achieve nearly that kind of gain while retaining grain on a grainy source. It's the same with x265 and x264.

I don't think it's reasonable to expect x265 to ever have similar quality to x264 at half the bitrate when most of the bitrate is spent on incompressible grain.
If you're trying to replicate the exact same grain pattern per frame in the source, sure. But psychovisual tuning around getting the same general grain texture feel can take advantage of improved codec features. x264 was a big leap forward in that area.

I also imagine that the per-band tuning that HEVC allows could do something nice when tuned to the grain frequencies of a particular source.

fumoffu

17th April 2014, 22:00

I don't think it's reasonable to expect x265 to ever have similar quality to x264 at half the bitrate when most of the bitrate is spent on incompressible grain.

Agreed but it would be nice to have some switches to adjust things like that, so you could tune things depending on the source and what you need/want to preserve.

Procrastinating

20th April 2014, 16:48

smegolas

21st April 2014, 15:39

True. I didn't say that comparing still frames has no value... just limited value.

Okay, but actually you said very limited value. Which I don't agree with.

cyberbeing

21st April 2014, 16:17

On the subject of test samples, is there any "safe harbor" for test clips of copyrighted material on this site? Screenshots are generally considered okay, so would it be reasonable to share say, 30 second sample footage without sound, or part of the OP of an anime? Where do you draw the line between a sequence of screenshots and an "unsafe" clip, is probably what I am trying to ask.

Generating a greater variety of test samples from "safe" clips of anime say, could be beneficial for tuning and cross-testing a variety of footage.

As long as each sample posted exhibits a specific focus or problem, the sample is not larger than required for testing, and you can prove without a doubt that the source of each sample does not violate Rule #6, use good judgment and you shouldn't run into problems.

benwaggoner

21st April 2014, 20:19

On the subject of test samples, is there any "safe harbor" for test clips of copyrighted material on this site?

All the Blender titles are Creative Commons licensed, and are great for this kind of use.

Movie-like (available in 4K): http://tearsofsteel.org/
CGI widescreen (available in 4K): http://sintel.org/
CGI 16:9 (now available in 60p 4K 3D!): http://www.bigbuckbunny.org/
CGI 16:9 (now with a stereo 3D version): http://elephantsdream.org/

The top 3 are available as 16-bit per channel image sequences, and so can make great sources for testing 10-bit HEVC.

LigH

21st April 2014, 20:24

Neither is a "classical cartoon", though.

nevcairiel

21st April 2014, 20:28

As long as the source of the content is legal, short samples fall under Fair-Use, and noone here on the forum will complain, or ever has when a user shared a sample with me. However, Fair-Use doesn't apply if the source of the content violates Rule #6.

benwaggoner

21st April 2014, 20:57

Neither is a "classical cartoon", though.
Indeed. Some Creative Commons licensed cel animation or anime would be incredibly valuable.

Why too many "advanced" new codec algorithms fall flat on their faces with that kind of content, as the frequency distribution required is so different.

Procrastinating

22nd April 2014, 04:16

The big problem is that you really can't go half-way with traditional animation. With CG it's feasible to have a small, dedicated group of volunteers to gradually churn out a project over time, but with traditional animation it's more or less required to form a production committee and pay at least some freelance key animators and the inbetweeners, else the project will never get finished.

One possible route would be to simply ask a studio to release uncompressed footage to the public domain, similar to how studio trigger, at least initially, shared Little Witch Academia.

What lies under "fair use", though? It would be problematic for everyone if we simply uploaded arbitrary sections of footage to only end up debating whether the footage was in fact "fair use". Some house-guidelines like "only 30 seconds of the opening credits" or "a single scene from an episode without sound" would be helpful. The problem with using a catch-all term like "problem cases" is that once the case is no longer a problem case, is it still test footage? Is it still allowed to be shared from that point onward? If a whole five-minute scene is a problem case, can the five-minute scene be shared?

LigH

22nd April 2014, 07:40

Here is a kind of "Creative Commons Cartoon": Sita sings the Blues (http://www.sitasingstheblues.com/) (downloads at archive.org (https://archive.org/details/Sita_Sings_the_Blues) and from other locations (http://sitasingstheblues.com/wiki/index.php?title=SitaSites)).

Wikipedia mentions earlier Copyright problems (http://en.wikipedia.org/wiki/Sita_Sings_the_Blues#Copyright_problems) before the license was redefined to "CC-0" (public domain).

Unfortunately, an uncompressed version requires a download of 200 GB... A shorter clip would be appreciated.

smegolas

22nd April 2014, 11:28

All the Blender titles are Creative Commons licensed, and are great for this kind of use.

Movie-like (available in 4K): http://tearsofsteel.org/

Tears of Steel has no grain so while it is representative of modern digitally shot content, in addition you will want some clips to approximate content shot on film.

Some of my favourite Blurays are titles like 3:10 to Yuma or Gladiator and x265 hasn't been outperforming x264 at the kind of bitrates necessary for grain retention.

Sure, if I do something stupid like 1Mbps (for 1080p) then of course it outperforms it but at sensible bitrates or ratefactors x264 starts to retain grain and fine detail very well while x265 still blurs quite a lot.

Atak_Snajpera

22nd April 2014, 15:40

x265 has still serious problems with cpu utilization

source park_joy_1080p50.y4m

x264 --preset veryslow
http://youtu.be/1dRRo31heTk

x265 (latest from builds.x265.eu) --preset veryslow
http://youtu.be/DU9PD8yl9k0

kolak

22nd April 2014, 17:16

I have 12 threads at 100% during x265 encodes.

Atak_Snajpera

22nd April 2014, 18:17

Try with at least 8C / 16T and then we will talk

easyfab

22nd April 2014, 20:27

And with -F 10 or -F 16 what is the cpu usage and speed

Atak_Snajpera

23rd April 2014, 15:55

I've just tested with preset medium and cpu usage is surprisingly better 85%-90% but still worse than constant 100% with x264. Playing with --threads value does not help either.

kolak

23rd April 2014, 16:18

Something is not well threaded in higher preset.

Atak_Snajpera

23rd April 2014, 16:56

Even default medium is not perfect. Still 10%-15% is wasted (not used) by encoder.

Procrastinating

24th April 2014, 06:20

Here is a kind of "Creative Commons Cartoon": Sita sings the Blues (http://www.sitasingstheblues.com/)

Unfortunately even flash animation has its differences from traditional animation, as factors such as auto-tweening, simple backgrounds and sharper edges lead to very different factors in terms of tuning encoders.

Modern anime and cartoons also have important differences such as animating on threes versus twos, different styles of post-processing effects(anime tends to be more in line with cinematic post-processing), different methods of shading and colouring, different methods of in-between weighting and so on.

After searching the internet a little, it seems that there are a few https://en.wikipedia.org/wiki/List_of_animated_films_in_the_public_domain_in_the_United_States Older animated films, as well as some obscure korean films such as "Space Transformers", "Space thunder kids", "Raiders of galaxy" and "defenders of space". Unfortunately most of these sources are likely to be of low quality and/or 240p.

Nowadays it could be feasible to crowdfund a public domain animation project, but that is something which has yet to happen.

One final option would be to straight up buy the rights to some cheap, but contemporary quality and definition, short animated film.

sneaker_ger

24th April 2014, 14:27

How does crf scale with internal bit depth at the moment? Some time back crf had to be reduced a lot for 10 bit compared to 8 bit (someone suggested -6 for each extra bit). In a short test with 0.9.91 10 bit crf had to be increased by 8 compared to achieve similar bitrate (maybe related to this commit (https://bitbucket.org/multicoreware/x265/commits/2fb85daef8af16015f876745e8379d2a9f5fbcd6)?). Is this on purpose? Was my test too short? Why the "- 8" in the commit?

foxyshadis

24th April 2014, 22:16

HEVC uses the same +6 per bit boost that AVC does, so there should be a 12 quant difference. But it's not perfect since the implementations are slightly different between 8 and 10/16-bit, and crf doesn't perfectly match up to constant quant anyway. If 8 works across a wide range of video types (not just one particular video) then I guess you have your answer.

I wonder if encoding 8-bit video in the 10-bit build differs from encoding it in the 8-bit build?

zerowalker

25th April 2014, 21:21

Is there any Comparasions Screenshots available on how it currently compares to x264 in certain bitrates?

LigH

25th April 2014, 21:33

Again, and again, and again: Screenshots have only a limited use. Better compare videos, because the temporal development of artefacts of different encoders is different too.

Some screenshots and also videos are published in the VideoHelp forum. I did not try several different CRF values yet, but compared a few CRF 30 encodes of x265 with x264 encodes of the same, double, and triple bitrate (and even quadruple in one case), more details here (http://forum.videohelp.com/threads/360069-x265-HEVC-Encoder?p=2315362&viewfull=1#post2315362). This may be a rather extreme low-bitrate test. Sane bitrates will have much less obvious differences.

zerowalker

25th April 2014, 21:49

Yeah i know, i try to keep a pace;P

True indeed, i just want to see screenshots for a simplistic view on how it's going, not any deep technical understanding on how it is.

I like seeing how stuff look one day, and how it has been improved later on, hence why screenshots are simple enough, but of course they never do justice as it's a Video codec and not Image codec.

Actually saw that picture with the people running, that caught my attention as being alot better than i expected, which i somehow doubt, as currently x264 should be ahead of x265 except on some occasion cause of how new x265 is(or perhaps was?).

EDIT:

Tried encoding a video myself, but decoding it seems to cause issues, doesn't Lav Filter support it, or has the Bitstream changed (Latest Version)?

vivan

25th April 2014, 22:08

Actually saw that picture with the people running, that caught my attention as being alot better than i expected, which i somehow doubt, as currently x264 should be ahead of x265 except on some occasion cause of how new x265 is(or perhaps was?).If you meant that post (http://forum.doom9.org/showthread.php?p=1677487#post1677487) - then yes, x265 is better at absurdly low bitrates (4 mbps for 4K@50 fps). While x264 simply fails x265 impresses us with amazing quailty (http://i.imgur.com/nyYDFUt.png).

zerowalker

25th April 2014, 22:16

Yes that one, it looked truly amazing, something you usually see when one of the encoders settings are completely wrong, and if that isn't the case, i am impressed,
even though x265 is aimed at beating x264, it's spectacular that it can achieve that, doesn't matter if it's low bitrate, that is simply better as the higher bitrate the less the codec matters.

fumoffu

25th April 2014, 23:15

...doesn't matter if it's low bitrate, that is simply better as the higher bitrate the less the codec matters.

I don't really agree with this and would like to point out that if your bitrate is limited why not just encode in lower resolution instead?
Both encoding and decoding will be faster so it can be done on slower hardware. But thanks to the laws or marketing it's now common to have HD video encoded with too low bitrate, while even 480p clips encoded with good codec can look good on big screen or at least better than HD video with visible encoding artifacts.
Why artificially inflate video resolutions?

Asmodian

25th April 2014, 23:30

even though x265 is aimed at beating x264, it's spectacular that it can achieve that, doesn't matter if it's low bitrate, that is simply better as the higher bitrate the less the codec matters.

You cannot judge relative codec quality at high rates based only on relative qualities at low rates. It is possible to have the low rate look better with this x265 and the higher rate look better with x264.

zerowalker

25th April 2014, 23:44

What i simply meant was that the aim for x265 is to reduce bandwidth more, hence why low bitrate efficiency is gold.
By no means am i saying that it's worthless to be efficient at transparent rates, for personal stuff i aim for transparency or similar, but in a global view bitrate is limited and if it can look like 2mbps at 500bitrate, than that is much more worth in that area than transparency bitrates.

Also i don't compare x265 to x264 at higher bitrates, i know that it's only in some scenarios and lower bitrates it currently beats it, but for what it's worth, i think it's great:)

vivan

26th April 2014, 00:17

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

26th April 2014, 00:43

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

26th April 2014, 13:14

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

29th April 2014, 19:54

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

29th April 2014, 21:08

EncodedMango

29th April 2014, 22:29

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

kolak

29th April 2014, 22:32

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

zerowalker

30th April 2014, 06:11

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

30th April 2014, 12:57

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

1st May 2014, 00:59

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

1st May 2014, 01:07

EncodedMango

1st May 2014, 06:44

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

1st May 2014, 08:20

@ 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

1st May 2014, 10:16

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

1st May 2014, 11:19

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

1st May 2014, 21:28

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

1st May 2014, 22:31

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

1st May 2014, 23:09

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

zerowalker

1st May 2014, 23:33

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

2nd May 2014, 09:32

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

zerowalker

2nd May 2014, 09:41

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

2nd May 2014, 20:56

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

3rd May 2014, 00:27

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

4th May 2014, 01:25

1.0 is out ???

Please give us COMPLETE changelog, dear x265_project.

LoRd_MuldeR

4th May 2014, 01:39

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

4th May 2014, 02:03

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

4th May 2014, 02:06

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

4th May 2014, 03:49

Does Evaluate Guide (need) update, please?

x265_Project

4th May 2014, 04:18

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

upyzl

4th May 2014, 04:31

oh, that's it...

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

zerowalker

4th May 2014, 11:13

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

4th May 2014, 15:06

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

4th May 2014, 15:21

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

4th May 2014, 16:49

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

4th May 2014, 19:30

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

4th May 2014, 20:12

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

5th May 2014, 03:01

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

5th May 2014, 11:11

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

5th May 2014, 12:45

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

5th May 2014, 22:36

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

6th May 2014, 08:07

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

LigH

6th May 2014, 08:21

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

6th May 2014, 13:11

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

6th May 2014, 16:31

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

6th May 2014, 17:22

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

7th May 2014, 07:33

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

7th May 2014, 13:09

@ 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

7th May 2014, 14:19

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

7th May 2014, 14:28

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

7th May 2014, 14:32

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).

Atak_Snajpera

7th May 2014, 15:12

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.
It is not a problem for me because whole command line is generated automatically by my gui ;) The question remains why x265 can't encode single frame like x264?

kolak

7th May 2014, 15:24

Atak_Snajpera

7th May 2014, 16:47

Bug report

--seek switch does not work. I've discovered that while testing x265 in my Distributed Encoding Mode

Log from first chunk

Encoding started...
""\\XEON-PC\Ripbot264temp\tools\avs2yuv\avs2yuv.exe" "\\XEON-PC\RipBot264temp\job1\Chunks\1.avs" -o - | "\\XEON-PC\Ripbot264temp\tools\x265\x265_x64.exe" --crf 20 --fps 24000/1001 --min-keyint 24 --keyint 240 --frames 1343 --sar 1:1 --y4m --seek 0 --output "\\XEON-PC\RipBot264temp\job1\Chunks\1.265" -"
y4m [info]: 624x464 fps 24000/1001 i420p8 sar 1:1 unknown frame count
x265 [info]: HEVC encoder version 1.0+22-7773ee321539
x265 [info]: build info [Windows][GCC 4.6.3][64 bit] 8bpp
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
x265 [info]: WPP streams / pool / frames : 8 / 16 / 5
x265 [info]: Main profile, Level-3 (Main tier)
x265 [info]: CU size : 64
x265 [info]: Max RQT depth inter / intra : 1 / 1
x265 [info]: ME / range / subpel / merge : hex / 57 / 2 / 2
x265 [info]: Keyframe min / max / scenecut : 24 / 240 / 40
x265 [info]: Lookahead / bframes / badapt : 20 / 4 / 2
x265 [info]: b-pyramid / weightp / weightb / refs: 1 / 1 / 0 / 3
x265 [info]: Rate Control / AQ-Strength / CUTree : CRF-20.0 / 1.0 / 1
x265 [info]: tools: rect amp rd=3 lft sao-lcu signhide
\\XEON-PC\RipBot264temp\job1\Chunks\1.avs: 624x464, 24000/1001 fps, 1343 frames

encoded 1343 frames in 132.88s (10.11 fps), 845 kbps

x265 [info]: frame I: 12 Avg QP:18.33 kb/s: 2804.80
x265 [info]: frame P: 418 Avg QP:21.51 kb/s: 1271.64
x265 [info]: frame B: 913 Avg QP:23.67 kb/s: 624.67
x265 [info]: global : 1343 Avg QP:22.95 kb/s: 845.51
x265 [info]: Weighted P-Frames: Y:0.7% UV:0.7%
x265 [info]: consecutive B-frames: 12.6% 7.7% 46.3% 21.9% 11.6%

Second chunk
Encoding started...
""\\XEON-PC\Ripbot264temp\tools\avs2yuv\avs2yuv.exe" "\\XEON-PC\RipBot264temp\job1\Chunks\2.avs" -o - | "\\XEON-PC\Ripbot264temp\tools\x265\x265_x64.exe" --crf 20 --fps 24000/1001 --min-keyint 24 --keyint 240 --frames 1517 --sar 1:1 --y4m --seek 36 --output "\\XEON-PC\RipBot264temp\job1\Chunks\2.265" -"
y4m [info]: 624x464 fps 24000/1001 i420p8 sar 1:1 unknown frame count
x265 [info]: HEVC encoder version 1.0+22-7773ee321539
x265 [info]: build info [Windows][GCC 4.6.3][64 bit] 8bpp
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
x265 [info]: WPP streams / pool / frames : 8 / 16 / 5
x265 [info]: Main profile, Level-3 (Main tier)
x265 [info]: CU size : 64
x265 [info]: Max RQT depth inter / intra : 1 / 1
x265 [info]: ME / range / subpel / merge : hex / 57 / 2 / 2
x265 [info]: Keyframe min / max / scenecut : 24 / 240 / 40
x265 [info]: Lookahead / bframes / badapt : 20 / 4 / 2
x265 [info]: b-pyramid / weightp / weightb / refs: 1 / 1 / 0 / 3
x265 [info]: Rate Control / AQ-Strength / CUTree : CRF-20.0 / 1.0 / 1
x265 [info]: tools: rect amp rd=3 lft sao-lcu signhide

encoded 1517 frames in 153.57s (9.88 fps), 1546 kbps

x265 [info]: frame I: 15 Avg QP:19.53 kb/s: 4746.50
x265 [info]: frame P: 424 Avg QP:22.39 kb/s: 2303.27
x265 [info]: frame B: 1078 Avg QP:24.35 kb/s: 1203.73
x265 [info]: global : 1517 Avg QP:23.75 kb/s: 1546.08
x265 [info]: Weighted P-Frames: Y:2.4% UV:2.1%
x265 [info]: consecutive B-frames: 7.7% 8.0% 26.7% 46.2% 11.4%
\\XEON-PC\RipBot264temp\job1\Chunks\2.avs: 624x464, 24000/1001 fps, 1553 frames
error: wrote only 432729 of 434304 bytes

Third Chunk
Encoding started...
""\\XEON-PC\Ripbot264temp\tools\avs2yuv\avs2yuv.exe" "\\XEON-PC\RipBot264temp\job1\Chunks\3.avs" -o - | "\\XEON-PC\Ripbot264temp\tools\x265\x265_x64.exe" --crf 20 --fps 24000/1001 --min-keyint 24 --keyint 240 --frames 1379 --sar 1:1 --y4m --seek 82 --output "\\XEON-PC\RipBot264temp\job1\Chunks\3.265" -"
y4m [info]: 624x464 fps 24000/1001 i420p8 sar 1:1 unknown frame count
x265 [info]: HEVC encoder version 1.0+22-7773ee321539
x265 [info]: build info [Windows][GCC 4.6.3][64 bit] 8bpp
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
x265 [info]: WPP streams / pool / frames : 8 / 16 / 5
x265 [info]: Main profile, Level-3 (Main tier)
x265 [info]: CU size : 64
x265 [info]: Max RQT depth inter / intra : 1 / 1
x265 [info]: ME / range / subpel / merge : hex / 57 / 2 / 2
x265 [info]: Keyframe min / max / scenecut : 24 / 240 / 40
x265 [info]: Lookahead / bframes / badapt : 20 / 4 / 2
x265 [info]: b-pyramid / weightp / weightb / refs: 1 / 1 / 0 / 3
x265 [info]: Rate Control / AQ-Strength / CUTree : CRF-20.0 / 1.0 / 1
x265 [info]: tools: rect amp rd=3 lft sao-lcu signhide

encoded 1379 frames in 144.78s (9.52 fps), 1240 kbps

x265 [info]: frame I: 20 Avg QP:19.26 kb/s: 4148.72
x265 [info]: frame P: 392 Avg QP:22.28 kb/s: 1951.58
x265 [info]: frame B: 967 Avg QP:24.43 kb/s: 892.26
x265 [info]: global : 1379 Avg QP:23.74 kb/s: 1240.61
x265 [info]: Weighted P-Frames: Y:0.8% UV:0.8%
x265 [info]: consecutive B-frames: 9.7% 7.8% 35.9% 31.3% 15.3%
\\XEON-PC\RipBot264temp\job1\Chunks\3.avs: 624x464, 24000/1001 fps, 1461 frames
error: wrote only 433254 of 434304 bytes

And last one

Encoding started...
""\\XEON-PC\Ripbot264temp\tools\avs2yuv\avs2yuv.exe" "\\XEON-PC\RipBot264temp\job1\Chunks\4.avs" -o - | "\\XEON-PC\Ripbot264temp\tools\x265\x265_x64.exe" --crf 20 --fps 24000/1001 --min-keyint 24 --keyint 240 --frames 1566 --sar 1:1 --y4m --seek 24 --output "\\XEON-PC\RipBot264temp\job1\Chunks\4.265" -"
y4m [info]: 624x464 fps 24000/1001 i420p8 sar 1:1 unknown frame count
x265 [info]: HEVC encoder version 1.0+22-7773ee321539
x265 [info]: build info [Windows][GCC 4.6.3][64 bit] 8bpp
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
x265 [info]: WPP streams / pool / frames : 8 / 16 / 5
x265 [info]: Main profile, Level-3 (Main tier)
x265 [info]: CU size : 64
x265 [info]: Max RQT depth inter / intra : 1 / 1
x265 [info]: ME / range / subpel / merge : hex / 57 / 2 / 2
x265 [info]: Keyframe min / max / scenecut : 24 / 240 / 40
x265 [info]: Lookahead / bframes / badapt : 20 / 4 / 2
x265 [info]: b-pyramid / weightp / weightb / refs: 1 / 1 / 0 / 3
x265 [info]: Rate Control / AQ-Strength / CUTree : CRF-20.0 / 1.0 / 1
x265 [info]: tools: rect amp rd=3 lft sao-lcu signhide

encoded 1566 frames in 157.09s (9.97 fps), 1685 kbps

x265 [info]: frame I: 15 Avg QP:18.92 kb/s: 3843.35
x265 [info]: frame P: 465 Avg QP:23.10 kb/s: 2284.15
x265 [info]: frame B: 1086 Avg QP:24.68 kb/s: 1400.03
x265 [info]: global : 1566 Avg QP:24.15 kb/s: 1685.96
x265 [info]: Weighted P-Frames: Y:19.8% UV:18.7%
x265 [info]: consecutive B-frames: 8.5% 14.0% 26.7% 44.4% 6.5%
\\XEON-PC\RipBot264temp\job1\Chunks\4.avs: 624x464, 24000/1001 fps, 1590 frames
error: wrote only 433252 of 434304 bytes

Error message at the end clearly shows that seek switch didn't discard those frames. Result repeated sequence at joined chunks.

I need working --seek switch in order to discard any corrupted frames caused by still buggy FFmpegSource()

LigH

7th May 2014, 17:42

@ Atak_Snajpera:

I have only a 32-bit OS available right now. But my just built x265 v1.0+21 was able to encode only one frame; just my script was based on ColorBarsHD.

avs2yuv.exe FullHD_1f.avs -o - | x265 --bitrate 128 --fps 1 --frames 1 --sar 1:1 --preset veryslow --y4m -o FullHD_1f.hevc -
FullHD_1f.avs: 1920x1080, 1 fps, 1 frames
y4m [info]: 1920x1080 fps 1000/1000 i420p8 sar 1:1 unknown frame count
x265 [info]: HEVC encoder version 1.0+21-8963bc3aa2e1
x265 [info]: build info [Windows][GCC 4.8.2][32 bit] 8bpp
x265 [info]: using cpu capabilities: MMX2 SSE2Slow SlowCTZ
x265 [info]: WPP streams / pool / frames : 17 / 2 / 1
x265 [info]: Main profile, Level-5 (Main tier)
x265 [info]: CU size : 64
x265 [info]: Max RQT depth inter / intra : 3 / 3
x265 [info]: ME / range / subpel / merge : star / 57 / 4 / 4
x265 [info]: Keyframe min / max / scenecut : 1 / 250 / 40
x265 [info]: Lookahead / bframes / badapt : 40 / 8 / 2
x265 [info]: b-pyramid / weightp / weightb / refs: 1 / 1 / 0 / 5
x265 [info]: Rate Control / AQ-Strength / CUTree : ABR-128 kbps / 1.0 / 1
x265 [info]: tools: rect amp rd=6 lft sao-lcu signhide
x265 [info]: frame I: 1 Avg QP:10.85 kb/s: 321.58
x265 [info]: global : 1 Avg QP:10.85 kb/s: 321.58
x265 [info]: consecutive B-frames: 100.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0%

encoded 1 frames in 9.89s (0.10 fps), 321.58 kb/s

FullHD_1f.avs:
ColorBarsHD(1920,1080)
AssumeFPS(1,1)
ConvertToYV12()
Trim(0,-1)
Info()

So maybe there is an issue in relation with ImageSource here? I'll try again with a PNG image as source.
__

P.S.: This works just as well for me. But it takes quite a long time to prepare the encoding.

avs2yuv.exe FullHD_1f.avs -o - | x265 --bitrate 128 --fps 1 --frames 1 --sar 1:1 --preset veryslow --y4m -o FullHD_1f.hevc -
FullHD_1f.avs: 1920x1080, 1 fps, 1 frames
y4m [info]: 1920x1080 fps 1000/1000 i420p8 sar 1:1 unknown frame count
x265 [info]: HEVC encoder version 1.0+21-8963bc3aa2e1
x265 [info]: build info [Windows][GCC 4.8.2][32 bit] 8bpp
x265 [info]: using cpu capabilities: MMX2 SSE2Slow SlowCTZ
x265 [info]: WPP streams / pool / frames : 17 / 2 / 1
x265 [info]: Main profile, Level-5 (Main tier)
x265 [info]: CU size : 64
x265 [info]: Max RQT depth inter / intra : 3 / 3
x265 [info]: ME / range / subpel / merge : star / 57 / 4 / 4
x265 [info]: Keyframe min / max / scenecut : 1 / 250 / 40
x265 [info]: Lookahead / bframes / badapt : 40 / 8 / 2
x265 [info]: b-pyramid / weightp / weightb / refs: 1 / 1 / 0 / 5
x265 [info]: Rate Control / AQ-Strength / CUTree : ABR-128 kbps / 1.0 / 1
x265 [info]: tools: rect amp rd=6 lft sao-lcu signhide
x265 [info]: frame I: 1 Avg QP:17.61 kb/s: 3320.82
x265 [info]: global : 1 Avg QP:17.61 kb/s: 3320.82
x265 [info]: consecutive B-frames: 100.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0%

encoded 1 frames in 19.97s (0.05 fps), 3320.82 kb/s

Encoded frame is playable in MPC-HC.

Atak_Snajpera

7th May 2014, 18:15

It is really weird

With this script (2 frames)

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

x265 encodes 1 frame ;)

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

x264 for example correctly encoded 2 frames

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

nevcairiel

7th May 2014, 18:20

With this script (2 frames)

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

x265 encodes 1 frame ;)

Your commandline seems to include --frames 1, of course it encodes one frame. Everything else would be wrong. :)

Atak_Snajpera

7th May 2014, 18:29

Your commandline seems to include --frames 1, of course it encodes one frame. Everything else would be wrong. :)

You are right ofcourse in this example. My mistake.

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

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

Script contains one frame. I tell x265 to also encode 1 frame but I get ZERO ;) Even If I remove --frame switch I still get 0.

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

is correctly encoded by x265

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

zerowalker

8th May 2014, 18:59

Here is a comparison from DeadSpace 2, just did a quick one as i wanted to try out 10bit in x264/x265 with dark gradients and higher details etc.
And the results are less than i actually expected, i thought the gain would be a bit more for x265, but it still loses till i get down to less than 1mbps.

As before, nothing to purely judge, just a quick one for you to see how it handles at dark with the advantages 10bit gains (x265 was done in 16bit but the output is 10bit).

http://i58.tinypic.com/5bqt60.png
http://i61.tinypic.com/xcknyd.png

BTW, is it possible to make the images less in size on the forum, and make it clickable to resize it to it's original?
As it wastes so much space, probably bothersome to most people.

Atak_Snajpera

8th May 2014, 19:10

And how many fps did you get on x264 and x265 during encoding?

zerowalker

8th May 2014, 19:20

17.97 fps on x264 10 bit.
2.28 fps on x265 16bit - 10bit output.

both default settings, except CRF.

Atak_Snajpera

8th May 2014, 20:37

lol x264 is ~8 times faster and quality is still more or less the same? x265 realy likes to waste cpu cycles and electricity ;)

zerowalker

8th May 2014, 20:51

Can't disagree, must be quite some optimization that has to be done, would like to get hold of the first public release of x264 to compare it with, just to see the evolution.

What bothers me most with x265 however, is the filtering it's doing, killing details is one thing, but the "haloing/ringing" effect is something that's frustrating at low bitrates.
Even if it looks alot better than x264 at those bitrates, the ringing gives of a, plastic unreal feeling.

But probably one of the least prioritized things on the list as it only occurs in those cases, at least as far as i have noticed.

easyfab

8th May 2014, 21:02

Zerowalker,

Here a freenode-x265.log extract for you:

2014-05-07 18:54:51 < Daemon404> im sitll having issues with detail retention at mid-to-high bitrate
2014-05-07 18:54:53 < Daemon404> or well
2014-05-07 18:54:56 < Daemon404> "detail"
2014-05-07 18:54:59 < Daemon404> since it is psy after all
2014-05-07 18:55:44 < muggs> yeah, this is tops on my list right now; since we've finally fixed the all the known bugs in analysis (that cost wrap problem was a bitch)
2014-05-07 18:56:10 < Daemon404> cool

Sagittaire

9th May 2014, 09:02

lol x264 is ~8 times faster and quality is still more or less the same? x265 realy likes to waste cpu cycles and electricity ;)

Well it's completely false. x265 produce really better quality than x264 at same bitrate in most case. You can certainely find some example to condradict that but for "real life case" x265 produce better result than x264 and by far and it's really simple to prove that ... lol

LigH

9th May 2014, 09:07

Exceptions are some known issues with psychovisual features, which are being fixed. Patience and trust. Developers are only humans, too.

zerowalker

9th May 2014, 09:57

easyfab,

did you mean that he has high priority of it?
Cause if so, i think that isn't the thing i meant, which is "ringing".

But then again, detail retention may actually go hand i hand, solving that will perhaps reduce the other.
Good news anyhow:)

Sagittaire,

Actually can't agree with you there.
In my tests, x264 wins pretty much all the time against x265, Except at very low bitrates.
When you reach the "medium", like 4k for 1080p, x265 will force filtering on much of the thing causing a blurry mess, while x264 will look blocky, but will retain a lot more detail.

So well, x265 win in a "silky" look, but i can't say that's realistically comparable to the original, but it does look good at some occasions where x264 "blocky mess" misplaces to much data and just appears as artifacts rather than an actual shape.

Romario

9th May 2014, 15:03

Can you, x265_project, add support for *.MPEG input and *. AVI input in x265 encoder, please ?

I find that Y4M format is very strange...and I don't like it, to be quite honest. Thank you.

X265 should be developed in much faster developing rate, for me x265 is not ideal, at the moment. Lack of details is evident, unfortunanely.

Can you predict when will be x265 on par(in quality terms) with x264 ? End this year, next year ?

Atak_Snajpera

9th May 2014, 15:07

Most likely next year. Y4M is fine. With avs2yuv you can import any format.

LigH

9th May 2014, 15:13

And avs4x265 will simplify the piping of AviSynth scripts even more.

Finishing the encoder core will certainly be preferred over adding interface features (like including libav libraries to read media files on its own).

Fixing the lack of detail preservation has been discussed during the last months. It is known, and it is being developed.

LoRd_MuldeR

9th May 2014, 15:47

Can you, x265_project, add support for *.MPEG input and *. AVI input in x265 encoder, please ?

I find that Y4M format is very strange...and I don't like it, to be quite honest. Thank you.

Y4M is nothing but "raw" YUV data with a minimalist header. So it's the format in which your input video data will end up anyway, regardless of how you feed it into the encoder.

As others have suggested, you can use avs2yuv or vspipe to feed current x265 directly from Avisynth or VapourSynth, respectively - which means you can load pretty much any video format in existence.

And if you don't want to do this manually, just use a GUI (https://forum.doom9.org/showthread.php?t=144140) which can accomplish this task more conveniently ;)

Also keep in mind that x265 is an encoder library, which takes "raw" YUV data as input and returns compressed H.265 data, not a fully-fledged video processing application. The same way x264 is an encoder library that takes "raw" YUV data and returns compressed H.264 data. Decoding the input video format to "raw" YUV before feeding it into the encoder library is the job of the calling application. Consequently, in case of x264, support for handling various types of input video formats is not implemented in the x264 "core" library, but in the x264 CLI front-end. Other front-ends exist, such as FFmpeg, Avidemux, etc. And, indeed, FFmpeg already does support x265 too! Look here (http://ffmpeg.zeranoe.com/builds/) for FFmpeg builds that have x265 support enabled.

zerowalker

9th May 2014, 17:28

X265 should be developed in much faster developing rate, for me x265 is not ideal, at the moment. Lack of details is evident, unfortunanely.

Not sure if you mean it Should develop faster, as in for some reason, or if you want it to.

However, if i am not entirely mistaken, x265 can use many features from x264, they just need to redevelop them or something.

And if that's the case, the evolution should go faster compared to x264 which didn't have anything to go with so everything was created from scratch, or at least most of it.

foxyshadis

10th May 2014, 00:57

Well, a very experimental psy-rd test patch (https://mailman.videolan.org/pipermail/x265-devel/2014-May/004371.html) was just posted to the mailing list, so I figured I'd make a build. It's incomplete, but hey, it's something. I still haven't had a chance to test it, so beware of dragons.

x265 1.0+38+psy-rd: 16bit (https://www.dropbox.com/sh/6mjj0iuzuatfllt/AACkf-Rjv3ZiJuX11uOJggAKa/x265-1.0-r38-psyrd.exe) - 8bit (https://www.dropbox.com/sh/6mjj0iuzuatfllt/AACkf-Rjv3ZiJuX11uOJggAKa/x265-1.0-r38-psyrd-8bit.exe) - Symbols (https://www.dropbox.com/sh/6mjj0iuzuatfllt/AABoi_Fgq7CevwnRHCy-sb_Ka), all x64 only. Requires VC2013 Runtime (https://www.microsoft.com/en-us/download/details.aspx?id=40784).

x264's default is --psy-rd 1.0 --aq-strength 1.2, while --tune stillimage is --psy-rd 2.0 --aq-strength 1.2 and --tune animation is --psy-rd 0.4 --aq-strength 0.6, for what it's worth. Might be good starting points.

xooyoozoo

10th May 2014, 03:17

Maybe it's just me, but I had to replace "psy-rd" with "psyrd" in the patch. Otherwise, the command line would complain whenever I try to change psyrd values from default 1.0.

I didn't save any shots from tests, but the effect so far is on the subtle end. Bad(?) news is that, at CRF28 and default psy, I couldn't tell much of a difference while a clip is playing. Good news is that in still shots, I can see extra "noise" in the right spots, like on a dog's fur or around a sprinkler.

Personally, I wouldn't mind a conservative ramp up with x265's psy features, as long as it adapts to high QPs more gracefully that x264's psy.

easyfab

10th May 2014, 06:24

Maybe it's just me, but I had to replace "psy-rd" with "psyrd" in the patch. Otherwise, the command line would complain whenever I try to change psyrd values from default 1.0.

same here : x265 [error]: invalid argument: psy-rd = 1.5

Thanks for the trick

Kurtnoise

10th May 2014, 09:00

Maybe it's just me, but I had to replace "psy-rd" with "psyrd" in the patch.
There is a typo in this patch :

+ OPT("psyrd") p->psyRd = atof(value);

Should be :
+ OPT("psy-rd") p->psyRd = atof(value);

zerowalker

10th May 2014, 10:22

Tried the 8bit build, not sure if the patch works or not as you can't change the settings, so i guess it means it's just a normal 8 bit build?

However, i did a test with my DeadSpace clip, and compared 16-bit to 8-bit, and the 8-bit looked quite a lot better, which doesn't make sense to me, either something has happened since the 16-bit build, or something is wrong.
The 16-bit should clearly win at the same bitrate in this clip.

EDIT:

Here are links:

x265 8bit with psyrd patch (typo) (https://docs.google.com/uc?export=download&id=0B_UKJFH8rbiNcTZ0dWFjVl9jNE0)
x265 16bit (https://docs.google.com/uc?export=download&id=0B_UKJFH8rbiNLWtINkVEbjdTWWM)

easyfab

10th May 2014, 12:02

Tried the 8bit build, not sure if the patch works or not as you can't change the settings, so i guess it means it's just a normal 8 bit build?

With the patch, psy-rd is enable by default for me .

x265 [info]: tools: rect amp rd=4 psyrd=1.0 lft sao-lcu signhide

Make sure to have rd >= 4.

The change with this experimental psy-rd is really sublte for the moment but it does not matter, I only test it out of curiosity :)

Atak_Snajpera

10th May 2014, 12:08

In terms of threading x265 also needs fixing. This is a real problem with low res videos. In my example I used XviD 624x352 video clip. First part of the movie shows cpu usage with x264 --preset veryslow. Second part x265 --preset medium. In both cases I used latest x64 builds. In this test x264 has ~2.5 better cpu usage than x265. And please do not tell me that x265 is only for stupid 4k footage. UHD will never be as popular as lower res videos.

https://www.youtube.com/watch?v=rrghV1yqaTU&feature=youtu.be

zerowalker

10th May 2014, 12:43

With the patch, psy-rd is enable by default for me .

x265 [info]: tools: rect amp rd=4 psyrd=1.0 lft sao-lcu signhide

Make sure to have rd >= 4.

The change with this experimental psy-rd is really subtle for the moment but it does not matter, I only test it out of curiosity :)

So, by previous versions, psy-rd doesn't exist?
If i am not completely out, isn't this a quite useful feature that took awhile for x264 to implement?
Something about predicting details and making more subtle changes to the eyes, so it looks better than it really is?

can't change the rd(psyrd?) as the typo exists, so would need another version for that.

LoRd_MuldeR

10th May 2014, 17:18

In terms of threading x265 also needs fixing.

You may wish to read this:
http://x265.readthedocs.org/en/default/threading.html

I suppose the x265 developers will be interested in your ideas of how this can be further improved ;)

Also keep the following in mind:
https://forum.doom9.org/showpost.php?p=1655710&postcount=15

Atak_Snajpera

10th May 2014, 17:43

You may wish to read this:
http://x265.readthedocs.org/en/default/threading.html

I suppose the x265 developers will be interested in your ideas of how this can be further improved ;)

Also keep the following in mind:
https://forum.doom9.org/showpost.php?p=1655710&postcount=15

Interesting read. Thanks mulder. So now I see that encoding multiple chunks at once is really a necessity for those with multiple logical cores. In order to achieve max speed with x265 (CU 64) now I have to encode 2-3 chunks at the same time.

UPDATE:
Ok. With CU 16 I have constant 100% , with CU 32 ~75%

UPDATE2
According to my test
CU 64 with 3 chunks gives the fastest encoding speed ~41 fps (average for all chunks)
CU 32 with 2 chunks is noticeable slower ~35 fps
CU 16 with 1 chunk is the slowest ~30 fps (despite constant 100% usage)

nevcairiel

10th May 2014, 19:10

Smaller CTUs also increase the number of CTUs to process, so seeing slower speed at higher CPU usage is not entirely unexpected. On top of that, they also reduce compression efficiency.
But the docs and the animation explain it quite well. As smaller as the image gets, WPP gets less and less effective.

foxyshadis

10th May 2014, 21:59

There is a typo in this patch :

+ OPT("psyrd") p->psyRd = atof(value);

Should be :
+ OPT("psy-rd") p->psyRd = atof(value);
Thanks for pointing the problem out, I've rebuilt them and included the new patch in the folder as well. It actually did work fine with --psyrd x before, but better to have it right.

zerowalker: Yes, use --psy-rd 0.0 to compare to previous versions that don't have it at all, since 1.0 is now default. (Although you might want to sanity check, using a real previous version to see if the output is really the same.)

What psy-rd does is try to keep the noisiness of blocks as close as possible to the original, and weights matches based on that, instead of purely on coding cost. Dark Shikari wrote a bit about it (http://x264dev.multimedia.cx/archives/37) a while back.

fumoffu

11th May 2014, 00:50

Good to see psyrd finally in the works.
I did some tests and for now the difference and image quality is very very slight. Understandable considering that with psy-rd set to 1.0 the bitrate increased only about 1% while on the same sample while encoding with x264 bitrate increased almost 20% when changing psy-rd from 0.0 to 1.0
(witch is why I think the default 1.0 in x264 is a bit too high but that is another story)

btw. using --early-skip shouldn't interfere with psy-rd, right?

LoRd_MuldeR

11th May 2014, 01:01

I did some tests and for now the difference and image quality is very very slight. Understandable considering that with psy-rd set to 1.0 the bitrate increased only about 1% while on the same sample while encoding with x264 bitrate increased almost 20% when changing psy-rd from 0.0 to 1.0

If you compare the effect of Psy-RD with encodes of different file size (i.e. different bitrate), then your test is completely useless. You need to compare files of identical size (i.e. same bitrate). For example, if the encode with Psy-RD has better quality (compared to the encode without Psy-RD) but also comes out bigger, then you have learned exactly nothing! Of course spending more bits results in better quality. That's not surprising and doesn't required Psy-RD at all. You could just have increased the target bitrate. So, it's all about achieving better quality at the same bitrate (file size). Alternatively, you could also create encodes of the identical perceived quality and then compare the file sizes - but that is much more difficult to do!

Another important point to consider: Who says that a Psy-RD strength of 1.0 currently is a good choice? Or a good choice for your particular source? With such Psy optimizations, choosing a strength that is too low will not give the desired effect. But choosing a strength that is too high will produce annoying side effects. It's all about finding the "sweet spot". And this can vary quite a lot between different types of sources. So if you think that the effect is too subtle, try a higher strength!

foxyshadis

11th May 2014, 03:05

It doesn't seem to be very strong yet. The differences aren't as pronounced as x264; given that they're pretty different and HEVC allows much larger blocks I'm not all that surprised. I don't even know if it's complete, as in touching all decisions.

But there seems to be a bit of difference, and hey, that's what's important. I'll post some shots if I'm sure I'm not just imagining it.

Just test everything with 0.0 and 2.0, to see the most difference and whether it helps anything. I don't think that the 0.0-2.0 scale or 1.0 default will change, but I'm sure it'll be scaled as it's modified over time.

As Mulder says, you have to pick a size and stick to it when comparing anything, even if you normally only do things by crf; anything else introduces more unnecessary variable that you can't intuitively correct for.

fumoffu

11th May 2014, 10:51

Yes I definitely agree that generally you should compare things with the same size.
But for now I was just testing if the implementation works at all and how switching it on changes the image and file size.

mandarinka

14th May 2014, 12:41

Seems there is a new version on the ML: https://mailman.videolan.org/pipermail/x265-devel/2014-May/004389.html

LigH

14th May 2014, 13:26

Psy-RD adaption from x264, 2nd edition, Request For Comments ... rather looks like it may take a little more until it will be committed. Patience, Padawans.

fumoffu

14th May 2014, 18:12

Seems there is a new version on the ML: https://mailman.videolan.org/pipermail/x265-devel/2014-May/004389.html

can someone post updated build? pretty please ^-^

LoRd_MuldeR

14th May 2014, 22:16

can someone post updated build?

Here we go:
x265-PsyRD.win-x64-8bit.2014-05-14.rar (http://www.mediafire.com/download/zp7i1aw6tt7be61/x265-PsyRD.win-x64-8bit.2014-05-14.rar)

zerowalker

14th May 2014, 22:20

Is the build inside already patched?

LoRd_MuldeR

14th May 2014, 22:22

Is the build inside already patched?

Yes. Would be difficult to patch the binary afterwards :p

foxyshadis

14th May 2014, 22:38

Sure, no problem: 16bit (https://www.dropbox.com/sh/ezw6te74q6j6roa/AADI_iwQ76pryb5_OcuFbEi6a/x265-1.0%2B53-psyrd.exe) - 8bit (https://www.dropbox.com/sh/ezw6te74q6j6roa/AADYxCcnxYq_bfSez4TzXFjFa/x265-1.0%2B53-8bit-psyrd.exe) - Patch and unmodified builds (https://www.dropbox.com/sh/ezw6te74q6j6roa/AAB39l7YxLoXRIDRFbukN7Tca)

Edit: Haha, Mulder at the same time!

zerowalker

14th May 2014, 22:41

Well i tried the supplied build which was patched, and it looks identical with and without Psy-RD (0,1).

Not sure if i am doing something wrong.

LoRd_MuldeR

14th May 2014, 22:54

Well i tried the supplied build which was patched, and it looks identical with and without Psy-RD (0,1).

Not sure if i am doing something wrong.

As others have reported before, the effect of this patch seems to be rather subtle at the moment. But you can try to adjust the strength.

Furthermore, you need to be aware that Psy-RD only has an effect with RDO enabled.

Last but not least, if you actually want to see a difference, you'll need to pick a bitrate that is low enough: If the version without Psy-RD already looks "transparent" already, then there isn't much to gain!

(But of course the bitrate must not be too low either. If both versions just look like a mess, you won't be able to learn anything)

zerowalker

14th May 2014, 23:08

Is RDO enabled by default?

Cause i am talking Identical, precise the same in size and looks, so it doesn't even use it, so something must be wrong;S

LoRd_MuldeR

14th May 2014, 23:24

Is RDO enabled by default?

http://x265.readthedocs.org/en/default/cli.html#cmdoption--rd

So the default value is "--rd 3", which means that RDO is enabled by default.

But the higher you set it, the more exhaustive the RD analysis - and thus the more chances for Psy-RDO to kick in (in theory).

So you might want to add "--rd 6" to your command-line, just to be sure...

Cause i am talking Identical, precise the same in size and looks, so it doesn't even use it, so something must be wrong;S

I just applied the patch, as it was posted on the mailing list, to latest x265. And that's it.

The only test I made with that build is that it would encode "foreman" with default settings without crashing right away ;)

So I have no idea whether something is wrong or not :p

zerowalker

14th May 2014, 23:32

It seems to work with --rd 6, then the file size changes at least, psy-rd is quite larger than the other, even with both using --rd 6.
Not really sure how i should test the files though, should i try to get the same size, or simply compare how Psy-RD acts?

LoRd_MuldeR

14th May 2014, 23:37

Not really sure how i should test the files though, should i try to get the same size, or simply compare how Psy-RD acts?

See here:
https://forum.doom9.org/showpost.php?p=1680298&postcount=786

zerowalker

14th May 2014, 23:39

Okay, thought as much, will however wait with that, as --rd 6 is extremely slow, will take ages for my to try to find the CRF setting to reach similar bitrates.

fumoffu

14th May 2014, 23:40

hmm I'm getting some small artifacts with LoRd_MuldeR build but foxyshadis version seems to working fine.

xooyoozoo

14th May 2014, 23:58

On Ubuntu 14.04 + gcc-4.9, I'm also getting artifacts.

foxyshadis

15th May 2014, 01:34

Okay, thought as much, will however wait with that, as --rd 6 is extremely slow, will take ages for my to try to find the CRF setting to reach similar bitrates.

Instead of trial and error, a quicker way to test is to two-pass it. Test once with your favorite crf, then use the final bitrate of that to plug into the two-pass bitrate of every future test. Then at least you're not wasting extra encodes.

vivan

15th May 2014, 04:03

but... it still doesn't support 2-pass mode :)

kypec

15th May 2014, 08:11

but... it still doesn't support 2-pass mode :)
Really? What a shame, average bitrate controlled mode is a must nowadays I'd guess....

x265_Project

15th May 2014, 17:28

but... it still doesn't support 2-pass mode :)
It's not a trivial effort to support two pass encoding; at least, not if you want to do it the right way. As always, patches are welcomed. :)

We have higher priorities for our near-term development backlog... improving existing rate control modes (ABR, VBV), improving the visual quality produced by the all of the encoding algorithms we've developed, developing new algorithms for visual quality (psycho-visual optimizations), and improved performance.

xooyoozoo

15th May 2014, 19:47

Getting hash mismatches with the recent x265 commits and `-p slower --psy-rd 1`.

The hash mismatches stop if I change line 109 of TComRdCost.h from

`width = height = 1 << (size * 2);`

to

`width = height = 1 << (size + 2);`

Daemon404

15th May 2014, 19:56

We have higher priorities for our near-term development backlog... improving existing rate control modes (ABR, VBV), [...]

Is it even worth it to put so much time into ABR?

x265_Project

15th May 2014, 20:01

Is it even worth it to put so much time into ABR?
Well, I know you're an offline guy, but there is a whole world of low latency real-time encoding applications that need ABR and its derivatives... VBV, HRD, CBR.

foxyshadis

15th May 2014, 20:47

Is it even worth it to put so much time into ABR?

Real-time encoding is the only place the money is anymore, at least until a new disc or download standard includes HEVC support. Youtube, Netflix and the like stick to x264 or their own codecs for their offline encoding needs. (So far.)

x265_Project

15th May 2014, 21:13

Real-time encoding is the only place the money is anymore, at least until a new disc or download standard includes HEVC support. Youtube, Netflix and the like stick to x264 or their own codecs for their offline encoding needs. (So far.)

I wouldn't go that far. We focused on offline encoding for the longest time, as the priority was always on the encoding algorithms and we didn't want to complicate matters. But as you know, our business model is to fund the development of x265 privately. There are several classes of companies backing the project, including commercial licensees (companies that distribute the codec in their product) and strategic partners (semiconductor or platform companies).

Fortunately, a number of companies that could otherwise choose to freeload (use x265 for free under the terms of the GPL) have wisely chosen to back the project. Companies whose business is centered on video (streaming video services, movie studios, etc.) recognize that...

HEVC is a very powerful technology, and the benefits will soon outweigh the costs of implementation
To remain competitive they need to lead when it comes to implementing HEVC
It is in their long-term interest for x265 to be their HEVC encoder of choice
It makes sense to fund the project to drive the development priorities in their direction, to meet their specific deployment requirements

We're generally getting good feedback from our customers and potential customers. Interest from the real-time space has certainly ramped up in recent months as companies compare the available options and see what x265 is capable of. As more real-time companies fund our development efforts, you'll see us develop more real-time features.

Note... I don't mean to use the term "freeload" in a derogatory manner. Using x265 for free is a legitimate option for many companies. The free-rider problem (http://en.wikipedia.org/wiki/Free_rider_problem) is an inherent part of our dual open source / commercial license business model. Our challenge is to convince companies that could otherwise pay nothing that it is in their best interest to back the project. Fortunately, we're succeeding in those efforts.

foxyshadis

15th May 2014, 23:14

Bug report from r6864:

- double *qp_offset = IS_X265_TYPE_B(frames[b]->sliceType) ? frames[b]->qpAqOffset : frames[b]->qpOffset;
+ double *qp_offset = (frames[b]->sliceType = X265_TYPE_B) ? frames[b]->qpAqOffset : frames[b]->qpOffset;

I'm assuming this should be ==? Or is that intentional? (The docs for this function also mention MB-tree instead of CU-tree.)

****

In other news, psy-rdo is committed, it's now disabled by default but otherwise no algorithm changes from the previous build. I checked, --subme 4 is also the minimum to enable it at all (preset veryslow).

Thanks for the clarification, x265_Project.

LoRd_MuldeR

15th May 2014, 23:54

In other news, psy-rdo is committed, it's now disabled by default but otherwise no algorithm changes from the previous build. I checked, --subme 4 is also the minimum to enable it at all (preset veryslow).

I'm still getting heavy artifacts (http://www.mediafire.com/download/o8bdyoru0hy9mr3/Test.rar) with "--preset veryslow --psy-rd 1.0", while just using "--preset veryslow" seems to be okay.

(Straight-forward MSVC 2013.2 build of 1.0+62, no patches or anything)

zerowalker

16th May 2014, 05:21

Instead of trial and error, a quicker way to test is to two-pass it. Test once with your favorite crf, then use the final bitrate of that to plug into the two-pass bitrate of every future test. Then at least you're not wasting extra encodes.

That's true.

Is it possible to Automate 2 pass?
Or will i have to do 2 commands?

LoRd_MuldeR

16th May 2014, 11:32

Is it possible to Automate 2 pass?
Or will i have to do 2 commands?

x265 does not currently support 2-Pass encoding.

http://forum.doom9.org/showpost.php?p=1680789&postcount=808

Daemon404

16th May 2014, 15:16

x265 does not currently support 2-Pass encoding.

If you have copious amounts of CPU-time and/or time, you could use Newton–Raphson (http://en.wikipedia.org/wiki/Newton%27s_method) or Brent's Method (http://en.wikipedia.org/wiki/Brent%27s_method) with x265's CRF mode, which should be more or less equivalent to its upcoming 2pass, if it follows x264's 2pass ratecontrol (aside from stuff like reference reordering, of course).

SciPy makes it pretty easy, e.g. for x264:

from scipy.optimize import brentq
import subprocess
import re

def f(x):
x264 = subprocess.Popen(['./x264', '--preset', 'placebo', '--crf', '%f' % x, '-o',
'/dev/null', '../v3.yuv', '--input-csp', 'i420', '--fps', '50',
'--input-res', '3840x2160', '2>&1'],
stdout=subprocess.PIPE, stderr=subprocess.STDOUT)
for line in iter(x264.stdout.readline,''):
line = line.rstrip()
if re.match('encoded', line):
return float(re.sub('encoded \d+ frames, \d+\.\d+ fps, (\d+\.\d+) kb/s', '\g<1>', line)) - 5892.3

print(brentq(f=f, a=25, b=30, xtol=0.05))

Particularly useful since the vast amount of encoding libraries which exist have terrible ratecontrol.

Well, I know you're an offline guy, but there is a whole world of low latency real-time encoding applications that need ABR and its derivatives... VBV, HRD, CBR.

Not entirely, no. Some interesting things are CRF mode with VBV and a max CRF value, which I think x265 already supports, as of recently (kudos).

The idea of CBR being needed seems rather silly, though ABR+VBV is certainly useful for a livestream environment (while simultaneously sending off chunks to 2pass in the background, for use with e.g. MPEG-DASH or HLS or whatever). YouTube has something like this IIRC.

What exactly is the usecase of CBR?

Note... I don't mean to use the term "freeload" in a derogatory manner. Using x265 for free is a legitimate option for many companies. The free-rider problem (http://en.wikipedia.org/wiki/Free_rider_problem) is an inherent part of our dual open source / commercial license business model. Our challenge is to convince companies that could otherwise pay nothing that it is in their best interest to back the project. Fortunately, we're succeeding in those efforts.

Some companies prefer to contribute in the form of patches/bug fixes/features/at-scale-fuzzing/etc, which I do think is a valuable thing for an open source project which may otherwise not have access to such developer time and/or that scale of testing (FFmpeg/Libav get a lot of this, and a bunch of x264's features were contributed this way as well). This would apply less to x265, I suppose, as it started life as a commercial venture.

x265_Project

16th May 2014, 16:33

Some companies prefer to contribute in the form of patches/bug fixes/features/at-scale-fuzzing/etc, which I do think is a valuable thing for an open source project which may otherwise not have access to such developer time and/or that scale of testing (FFmpeg/Libav get a lot of this, and a bunch of x264's features were contributed this way as well). This would apply less to x265, I suppose, as it started life as a commercial venture.
True. This is a key competitive advantage of our business model, vs. all of our fully proprietary competitors.

LoRd_MuldeR

19th May 2014, 11:46

x265 1.0+74 still produces strong artifices when Psy-RD is enabled.

Binary (vanilla MSVC 2013.2 build):
http://www.mediafire.com/download/uops57uebg5pcbq/x265.win-x64-8bit.2014-05-19.rar

Command:
x265.exe --preset veryslow --psy-rd 1.0 -o psytest.hevc foreman_cif.y4m

Result:
http://www.mediafire.com/download/n379fbcl74rr7dr/psytest.2014-05-19.rar

benwaggoner

19th May 2014, 19:44

x265 1.0+74 still produces strong artifices when Psy-RD is enabled.
I see several psy-rd fixed were checked in on Friday. Do you know if they were included in your build?

This one in particular sounds significant https://bitbucket.org/multicoreware/x265/commits/f3f3eecd28f120716c531ba2e18c88d26dc54374

LoRd_MuldeR

19th May 2014, 20:24

I see several psy-rd fixed were checked in on Friday. Do you know if they were included in your build?

This one in particular sounds significant https://bitbucket.org/multicoreware/x265/commits/f3f3eecd28f120716c531ba2e18c88d26dc54374

Yeah, I saw those fixes. That's why I made a new build (v1.0+74) today, but the problem remains. As explained in my previous post.

(Note: I only tried MSVC 2013.2, x64, 8-Bit)

benwaggoner

19th May 2014, 20:27

Yeah, I saw those fixes. That's why I made a new build (v1.0+74) today, but the problem remains. As explained in my previous post.
Oh well. Early days yet for this feature.

foxyshadis

19th May 2014, 23:35

Yeah, it looks like psy-rd is badly broken. On a frame-by-frame, I constantly get big fat sharp squares a little offset from where they should be, which fade away as the next couple frames compensate, bringing the overall quality way down. More in the 8-bit than 16-bit, and they're never the same from encode to encode. --noasm does not seem to fix it. (using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX)

Without psy-rd, foreman looks amazing at 400k; with it, it's a flickery mess even at a much larger size.

x265_Project

20th May 2014, 01:02

Oh well. Early days yet for this feature.
Yes, it will take some time to optimize psy-rd for HEVC.

Yeah, it looks like psy-rd is badly broken. On a frame-by-frame, I constantly get big fat sharp squares a little offset from where they should be, which fade away as the next couple frames compensate, bringing the overall quality way down. More in the 8-bit than 16-bit, and they're never the same from encode to encode. --noasm does not seem to fix it. (using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX)

Without psy-rd, foreman looks amazing at 400k; with it, it's a flickery mess even at a much larger size.
We appreciate the feedback from everyone. I wouldn't say it's broken... it's just not finished. Like most encoding features, we first implement the basic logic, and then we tune the algorithm, adapting it to HEVC. We thought it might be useful to expose the initial (untuned) implementation as an optional feature to get some feedback. We'll keep working to tune this up.

LoRd_MuldeR

20th May 2014, 01:36

I wouldn't say it's broken...

I would ;)

It's clear that any "psy" optimization has its pros and cons. And that finding a good trade-off is challenging. But those flashing "out of place" blocks we currently see with Psy-RD enabled certainly look much more like there's a serious bug somewhere in the code than just side-effects of the algorithm.

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

x265_Project

20th May 2014, 02:14

I would ;)

It's clear that any "psy" optimization has its pros and cons. And that finding a good trade-off is challenging. But those flashing "out of place" blocks we currently see with Psy-RD enabled certainly look much more like there's a serious bug somewhere in the code than just side-effects of the algorithm.
Yeah... I should have included bug fixes in my description of "tuning" above. Certainly, there may be bugs in the current early implementation... in fact, it's likely. But we know we have a lot of tuning left also.

LigH

20th May 2014, 07:13

I did not see any issues with my MSYS build of v1.0+74 on a Phenom-II (SSE2). Does it depend on the compiler, on the resolution ... on CPU instructions?

xooyoozoo

20th May 2014, 07:29

I did not see any issues with my MSYS build of v1.0+74 on a Phenom-II (SSE2). Does it depend on the compiler, on the resolution ... on CPU instructions?

Just to be clear, this is with psy-rd turned on? It's off by default.

LigH

20th May 2014, 07:36

Gosh, I wonder why I made my computer science graduation... ;) — Yes, all presets with additional '--psy-rd 1.0'.

-o tos_60s_360_%preset%.hevc --preset %preset% --psnr --ssim --log 3 --csv tos_60s_360_%preset%.csv --psy-rd 1.0

OK, in the Sintel trailer, there are shaky and flaky areas when there is little, slow motion. The parkrun should provoke some too...
__

P.S.: Uploaded (https://www.mediafire.com/folder/6lfp2jlygogwa/HEVC) 720p50 parkrun veryslow, with and without "--psy-rd 1.0"; with is much bigger, and movement is choppy (especially look at the umbrella).

Romario

20th May 2014, 14:42

@ x265_Project

What is with x265 optimizations ? I mean an SSE3 and others instructions set, newest. Is newest x265 1.0, at least in part, optimized for Intel Haswell ? When can we expect better optimisation ?

Thank you for answer.

LigH

20th May 2014, 14:58

Already for several versions, x265 supports optimized algorithms for e.g. SSE2, SSSE3, SSE4.1, AVX, FMA...; speed optimizations are constantly arriving, not only in assembler, but also for more general algorithms. Wouldn't you be rather surprised if it was not the case?

foxyshadis

20th May 2014, 22:39

Sadly, the sa8d fix didn't solve the psy-rd problem on low-motion scenes, and doesn't even seem to have made a dent in it: https://www.dropbox.com/s/4u2a9tz6vnpzyib/foreman-psyrd-fix.hevc

x265_10 --crf 30 --preset veryslow --psy-rd 1.0 --input foreman_cif.y4m foreman-psyrd-fix.hevc

x265_Project

21st May 2014, 07:50

x265_Project

22nd May 2014, 06:09

The psy-rd bug is still bugging us. The team is making progress, but we're not there yet. Please hold off testing psy-rd for now.

Thanks,
Tom

Chengbin

22nd May 2014, 14:26

x265_Project

22nd May 2014, 16:15

Out of curiosity, how many full time developers are there that are working on x265? Steve Borho seems to be doing most of the commits, but it seems hard to believe (and incredible) if there's only 1 full time developer for x265.

There are many developers, but only a few people have commit rights. You can see author of each patch on Bitbucket, or on the development mailing list.

LigH

23rd May 2014, 10:57

Some test results of the "noise reduction" (encoded with x265 v1.0+103) are being uploaded (http://www.mediafire.com/?6lfp2jlygogwa): tos_60s_fast_nr[0|100|1000].mp4

My first impression is that it can give a smaller file with a cleaner image and less motion-shaky artefacts.

Atak_Snajpera

23rd May 2014, 16:01

I think it is time to take a look at settings used in presets. I've tested those presets with first 10 min of Drive movie (http://www.imdb.com/title/tt0780504/?ref_=nv_sr_1).
Frame size after cropping: 1920x800
My CPU: Intel Xeon E5-2690 ( 8C / 16T )
Common command line: --crf 20 --min-keyint 24 --keyint 240
NOTE: In order to achieve max cpu usage and encoding speed in x265 I was encoding two 1 min chunks at the same time. (10 chunks total)

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

As you can see difference in encoding speed is marginal between superfast and fast. Also there is huge drop from fast to medium (almost 2x)

and for comparison ...

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

x265_Project

23rd May 2014, 16:15

I think it is time to take a look at settings used in presets.
I've been thinking the same thing, and we're looking at this. We run a full sweep of tests on a wide range of video sequences every week, on multiple machine types. In general we still see a good trade-off of speed vs. quality, but we want to make sure that the presets represent the highest possible points, spread out along the speed vs quality (efficiency) curve.

Tom

Atak_Snajpera

23rd May 2014, 16:20

I think you should change for example ME in superfast preset to DIA like in x264. merange should be also reduced in superfast and veryfast. Settings from medium preset should be moved to slow preset. New Medium preset should use old fast preset settings and so on.

qyot27

23rd May 2014, 20:15

Since we're talking about the presets, IMO the zerolatency and fastdecode tunings should be rolled into ultrafast - especially since both of those tunings contain settings that speed things up (or disable default things that I honestly think ultrafast should be disabling anyway, like B-frames), but since you can only enable one tuning at a time, it requires the user to put the rest of the settings in manually. Similarly, other settings could be turned down to the bare minimum needed for them to make sense, or turned off completely, as the logic behind ultrafast is pretty much to just go as fast as possible, accuracy:filesize ratio be damned.

For comparison, x264's zerolatency and fastdecode tunings are included in its ultrafast preset, for the most part.

The patch I've been using locally to do this, for example:
diff --git a/source/common/param.cpp b/source/common/param.cpp
index c6fb9d5..989c8d4 100644
--- a/source/common/param.cpp
+++ b/source/common/param.cpp
@@ -246,10 +246,13 @@ int x265_param_default_preset(x265_param *param, const char *preset, const char

if (!strcmp(preset, "ultrafast"))
{
- param->lookaheadDepth = 10;
- param->scenecutThreshold = 0; // disable lookahead
- param->maxCUSize = 32;
- param->searchRange = 25;
+ param->lookaheadDepth = 1;
+ param->scenecutThreshold = 0;
+ param->maxCUSize = 16;
+ param->searchRange = 16;
+ param->maxNumMergeCand = 1;
+ param->rdLevel = 0;
+ param->bframes = 0;
param->bFrameAdaptive = 0;
param->subpelRefine = 0;
param->searchMethod = X265_DIA_SEARCH;
@@ -258,8 +261,10 @@ int x265_param_default_preset(x265_param *param, const char *preset, const char
param->bEnableEarlySkip = 1;
param->bEnableCbfFastMode = 1;
param->bEnableSAO = 0;
+ param->bEnableLoopFilter = 0;
param->bEnableSignHiding = 0;
param->bEnableWeightedPred = 0;
+ param->bEnableWeightedBiPred = 0;
param->maxNumReferences = 1;
param->rc.aqStrength = 0.0;
param->rc.aqMode = X265_AQ_NONE;
--
1.9.1

xooyoozoo

23rd May 2014, 22:56

qyot27

23rd May 2014, 23:11

The main presets should still be pareto optimal (http://en.wikipedia.org/wiki/File:PareoEfficientFrontier1024x1024.png) and reasonably spaced, so although your assumptions may be correct, testing is needed to make sure the changes are worth it. For example, it would be silly if changing lookaheadDepth lowers quality by 10% but only increases speed by 0.1%.
A 0.1% speed increase in general wouldn't really qualify as a reason to turn something off/down, though.

It may be worth considering architecture constraints too - if you're encoding on a Sandy Bridge or Haswell, then it might be a 0.1% speed increase vs. 10% quality drop, but on an Orleans or Yorkfield it could boost speed far more than 0.1% because those can't take advantage of the higher SIMD sets. Also that the -fast presets would generally tend to be used more with older CPUs like those.

x265_Project

24th May 2014, 02:16

A 0.1% speed increase in general wouldn't really qualify as a reason to turn something off/down, though.

It may be worth considering architecture constraints too - if you're encoding on a Sandy Bridge or Haswell, then it might be a 0.1% speed increase vs. 10% quality drop, but on an Orleans or Yorkfield it could boost speed far more than 0.1% because those can't take advantage of the higher SIMD sets. Also that the -fast presets would generally tend to be used more with older CPUs like those.

Yes, there are lots of complicating factors when it comes to picking 10 performance presets, including the hardware and the type of content. We welcome input / test results / analysis on this topic.

In general, I'd like to see our medium (default) preset get faster without any appreciable impact on encoding efficiency (quality@ a given bit rate). I think that this is possible, but we haven't had a chance to run the kind of tests that we want to run.

I'd also like to see our Ultrafast get faster, if possible, but I don't view Ultrafast as a "max speed at any cost" setting. My view is that these presets are for users who don't want to mess with the individual options, and I want to protect these users from doing something that strays too far from the normal speed vs efficiency tradeoff.

Of course we'd like to see our highest quality presets (veryslow, placebo) become even more efficient, but with these settings we've got every algorithm dialed up to "full on". So, I don't think that it's possible today to improve these presets much with the current build, but I'd love it if someone could prove me wrong! We've got a number of algorithmic improvements designed to produce higher visual quality still in development, and I think that this is how we will move these presets in the right direction.

Ideally, we would like to see the 10 performance presets somewhat evenly spaced along the speed vs. efficiency curve, but generally that isn't possible. When you turn certain things on or off you can see a big impact on encoding speed, and so you get a bigger difference in speed between these presets. At the high-quality end, as everyone knows, there are diminishing returns on efficiency as you spend more time looking for the optimal way to encode.

Tom

benwaggoner

28th May 2014, 16:43

I've seen a TON of psy-rd related commits come in over the last week, related to the new m_totalPsyCost parameter.

This latest seems like perhaps the culmination of that:https://bitbucket.org/multicoreware/x265/commits/306d3e6b5185da57b7d9200329626cc7bfac92be

Is psy-rd in a good point for evaluation right now, or are there more important fixes coming in the next few days?

Doing my UHD encodes, and with psy-rd requiring rd-mode 5/6, psy-rd commits are coming faster than my encodes complete :).

x265_Project

28th May 2014, 23:38

x265_Project

29th May 2014, 04:27

Heads up... we will be adjusting our performance presets.

The default setting (the medium preset) will be adjusted to include the --no-rect and --no-amp options, becoming faster (on average, about 70%, but as much as 90%), with a very slight (~ 1 - 4%) impact on encoding efficiency. Expect a few additional adjustments going forward.

Tom

zerowalker

29th May 2014, 07:34

EncodedMango

29th May 2014, 07:48

Isn't that colossal, it's nearly double the speed for next to no disadvantage, sounds to good to be true.
Sounds like how it is for presets in x264, the slowest ones only add up to very low compression efficiency %age

x265_Project

29th May 2014, 08:31

Wait, does disabling does increase speed by 70-90% but decrease encoding efficiency only by 1-4%?

Isn't that colossal, it's nearly double the speed for next to no disadvantage, sounds to good to be true.
It's true, but only the medium, fast and faster presets are affected by the change. Veryfast, superfast and ultrafast haven't used --rect or --amp. The slow, slower, veryslow and placebo modes will continue to use --rect and --amp.

We've made a lot of changes since we last configured the performance presets, and it's definitely time for a few adjustments. The --rect function enables rectangular coding units (CUs), but it takes a lot more time to test all of these possibilities, and at the default (medium) setting, the benefit was very small.

zerowalker

29th May 2014, 09:26

Well it's good news, medium is the one who should be in the middle ground, and that is really something that Slow and above(below?) should use.
This makes it at least 50% faster, so tests can be done at greater speed;P!

kensan

2nd June 2014, 05:22

LoRd_MuldeR

2nd June 2014, 14:46

HIGH_BIT_DEPTH is a compile-time option, you cannot change this at runtime!

And since 10-Bit HEVC requires the "Main 10" profile, this is what you will get, if your x265 binary was compiled with HIGH_BIT_DEPTH enabled.

http://en.wikipedia.org/wiki/High_Efficiency_Video_Coding#Profiles

x265_Project

2nd June 2014, 17:13

Does anyone knows how to change main and main10 profile after compiling? What is the option to switch. If HIGH_BIT_DEPTH is ON, main10 profile is generated, and if OFF, main profile is generated, I think.

And YUV 8bit input can be encoded to main10 10bit stream like HM? Could you tell the option?

Regards,
As Lord Mulder said... if HIGH_BIT_DEPTH is set on when you build x265, you will build the 16 bits per pixel (bpp) version of x265, and all encodes from this build will be Main10 profile. If it is off, you will get the 8 bpp build of x265, and all encodes from this build are Main profile. There is no runtime selection.

No option is required to encode an 8bit video as Main10. Just tell the 16 bpp build of x265 the input bit depth: x265 foo.yuv --input-res 1920x1080 --fps 24 --input-depth 8 out.hevc.

LigH

2nd June 2014, 21:57

Version 1.1 is coming "soon™", so there was a stable merge again. There have been many preset changes to make them a lot faster with only little quality penalty.

Therefore another MinGW build: x265 1.0+151-108996798e78 (https://www.mediafire.com/?b5wev7k73gb1ndt)

x265_Project

3rd June 2014, 02:01

The latest build includes improvements to psy-rd, and it looks like things are working better now.

I'm seeing some artifacts when the psy-rd strength is higher, but I'm seeing a nice improvement in picture quality with the limited testing I've done at lower strengths (0.2 to 0.5).

x265_Project

3rd June 2014, 02:06

Version 1.1 is coming "soon™", so there was a stable merge again. There have been many preset changes to make them a lot faster with only little quality penalty.

We have sped up the ultrafast preset by about 10 to 30% (bigger benefit at higher bit rates). There is a very small impact on encoding efficiency, but you can always increase efficiency by using a slower (higher quality) preset. We've also sped up the superfast, veryfast and faster presets in a similar way.

x265_Project

3rd June 2014, 03:35

There is also a new lossless mode. Of course, lossless encoding will generate high bit rates, but the decoded content should be identical to the uncompressed source.
--lossless forces full lossless coding of every frame and every CU. --lossless will make the output bit-exact to the input regardless of preset. As lossless mode still uses motion estimation, slower presets will generally give you better lossless compression.

--cu-lossless forces the encoder to perform RD cost analysis between lossy and lossless modes and choose the least cost mode for each CU. The mode decision algorithm will create one more candidate where the transform and quantization was skipped for the CU. It will compare the RD cost for this lossless CU to all the other encode candidates. If the RD cost is better, it will use it. This just adds one more encode candidate to the mode decision. --cu-lossless will not guarantee a lossless bitstream. It is generally only useful for very high quality (slow, higher bit rate) encodes where you want every bit of efficiency possible.

Procrastinating

3rd June 2014, 07:29

x265_Project

3rd June 2014, 08:19

Has x265 lossless size been compared to x264 lossless? Another thread showed that x264 --slow was pretty competitive with codecs designed with lossless storage in mind, though obviously a lot slower.

Similarly, would lossless compression be expected to improve even marginally over time, or is that more fixed to the specification?
The lossless feature has just been implemented, and so it hasn't been tested extensively.

Lossless HEVC compression can be expected to improve over time, for a couple of reasons. First, the Joint Collaborative Team on Video Coding (the experts who developed the HEVC standard) are continuing their work on extensions to the standard, including enhancements specifically designed to improve lossless encoding efficiency. Second, lossless encoding takes advantage of inter-prediction (a.k.a. motion estimation, or temporal encoding), finding redundancies in previous or subsequent frames. Multiple encoding candidates can be compared for each block to see which one encodes most efficiently. So, as with the normal, lossy compression that x265 provides, it's possible to spend more time to find more redundancy, producing more efficiency. We haven't done any optimization for the lossless mode, but there is almost certainly room for future improvement.

Farfie

3rd June 2014, 16:35

In light of recent discussion regarding further preset optimization, I decided to start removing --rect and --amp from my encode command line to see what kind of difference it would make. Initially the speed increase was very obvious, from 2.3~ to 5.3~ FPS when using Slow, --tune SSIM (I know it's default but whatever :)). What I noticed next was strange... the size of the resulting file was also smaller than its counterpart with both switches enabled.So --rect and --amp put ~100% more stress on my CPU in order to make a larger file!

Could it be related to the specific content I'm encoding? Because I'm also not seeing a visual benefit either, though I didn't expect it to, because while the file IS bigger, it's not by much... 2,050,837KB to 2,119,957KB with switches.

Strange or no? Do these switches go beyond what reading the thread has made me to believe they are for, which in my mind was a simple efficiency for speed tradeoff?

edit:
Pardon, should add this was using 2014-06-02: 64 Bit-(d93801eda07e76cb32c85834760306e1) from http://builds.x265.eu/

LoRd_MuldeR

3rd June 2014, 17:10

The latest build includes improvements to psy-rd, and it looks like things are working better now.

Yeah, I definitely see some improvement! But also looks like it's not fixed completely yet:
http://www.mediafire.com/download/fs08d8dls07w8xf/x265-psyrd-test.rar

There's still some very apparent "wobbling" effect. You can see it clearly at the beginning of the clip, on the right side of the face (near his left ear).

Also, but not necessarily related to Psy-RD, the brick wall looks smoothed out initially. But then, shortly after the camera pan is complete, the details are popping up.

x265_Project

3rd June 2014, 19:32

Yeah, I definitely see some improvement! But also looks like it's not fixed completely yet:
http://www.mediafire.com/download/fs08d8dls07w8xf/x265-psyrd-test.rar

There's still some very apparent "wobbling" effect. You can see it clearly at the beginning of the clip, on the right side of the face (near his left ear).

Also, but not necessarily related to Psy-RD, the brick wall looks smoothed out initially. But then, shortly after the camera pan is complete, the details are popping up.
What was your command line?

LoRd_MuldeR

3rd June 2014, 19:41

What was your command line?

Everything on default, except for what is required to enable Psy-RD ("--preset veryslow" + "--psy-rd 1"). Version 1.0+156, clean MSVC build.

x265_Project

3rd June 2014, 20:08

Everything on default, except for what is required to enable Psy-RD ("--preset veryslow" + "--psy-rd 1"). Version 1.0+156, clean MSVC build.

I looked at your clip, and I see what you are referring to. I'm not surprised. I'm seeing these types of artifacts also if psy-rd strength is set too high.

As I mentioned, I wouldn't suggest a psy-rd strength of 1.0 at this point. Forget what you know about x264... x265 is a different animal, and psy-rd is still in the tuning phase. We may need to recalibrate in the future to make 1.0 the default strength. For now, I would try encodes with psy-rd strength of around 0.2 to 0.5. Experiment and see what works best.

LoRd_MuldeR

3rd June 2014, 22:31

Okay, I think a psy-rd strength of 0.2 looks okay. At strength 0.5 the problem appears again, but much less than at strength 1.0. Though I'm not sure whether I prefer 0.0 or 0.2 in this clip.

x265 Psy-RD 0.0 vs. 0.2 vs. 0.5:
http://www.mediafire.com/download/6w3kgq9u101lqed/x265-psyrd-compare.rar

x265_Project

4th June 2014, 00:08

Release 1.1 has been tagged. This is an incremental update with several important rate control improvements and a few new features.

= New Features =

1. Psycho-visual rate distortion optimizations. These RD optimizations are only effective on presets which use RDO (rd levels 5 and 6).
Psy-rd is still considered experimental in this release and is not enabled by default. We recommend evaluating with a low psy weight factor, for instance: --rd 5 --psy-rd 0.4

2. Lossless coding. This release of x265 can create a bit-accurate output bitstream by using --lossless. This feature disables rate control and distortion metrics, and instead just reports the compression ratio at the end of the encode. Lossless coding is considered experimental in this release, we believe there is room for improvement in both compression efficiency and performance.

3. Support for Y4M streams with more than 8 bit depth (for example, ffmpeg -i vid.avi -pix_fmt yuv420p10le -strict -1 -f yuv4mpegpipe - | ./x265 - --y4m o.hevc)

= API Changes =

* new x265_picture.forceQp for qpfile functionality
* new param.levelIdc to force a decoder requirement level
* new param.psyRd for (experimental) psycho-visual rate distortion optimizations
* new param.bIntraInBFrames to disable intra predictions in B slices regardless of preset
* new param.noiseReduction, very similar to x264 noise reduction
* new param.bLossless to enable lossless coding (experimental)
* new param.bCULossless to include trans-quant bypass modes in CU RD analysis
* new param.rc.rfConstantMin to limit rate factors in rate control
* param.rc.aqMode now defaults to 2 (to match CLI behavior)

new x265_encoder_parameters() function which retrieves a copy of the active parameters from the encoder. x265_encoder_open() was modified to ensure it never modified the param structure passed to the function; it makes a private copy of the param prior to making any modifications to it.

The default setting (the medium preset) was be adjusted to include the --no-rect and --no-amp options, becoming faster (on average, about 70%, but as much as 90%), with a very slight (~ 1 - 4%) impact on encoding efficiency.

We have sped up the ultrafast preset by about 10 to 30% (bigger benefit at higher bit rates). There is a very small impact on encoding efficiency, but you can always increase efficiency by using a slower (higher quality) preset. We've also sped up the superfast, veryfast and faster presets in a similar way.

= CLI Changes =

New options:
--level
--repeat-headers (older feature, newly exposed to CLI) --nr --lossless --psy-rd --crf-min --no-b-intra --cu-lossless --qpfile

--tune fast-decode now also disabled intra in B frames

As always, the most detailed documentation for the command line arguments can be found in our online documentation:
http://x265.readthedocs.org/en/1.1/

= Rate Control =

Single pass ABR received a lot of attention in this release, in particular the tendency for ABR to undershoot and overshoot wildly in the first two seconds of the video. We added two new features to ABR to limit this tendency. First, we now amortize a portion of the cost of I frames across many frames. Second, we limit frame parallelism until we have about a half-second of P frames encoded. Together these two changes have greatly improved the ability of single pass ABR to arrive at the good QP for the first GOP without any large swings.

Further improvements were made to ABR to allow it to reach very high bit rates.

We also did some re-balancing of CRF between Main and Main10 so they achieve closer quality, and several fixes were made to VBV.

Recovery Point SEI are now generated at each keyframe

In the near future we will be focusing on two-pass encoding and making mode decision more efficient.

LoRd_MuldeR

4th June 2014, 02:43

Here's a fresh set of x265 v1.1 binaries:
x265-win-msvc2013.2014-06-04.rar (http://www.mediafire.com/download/qllbo1bqw6easbp/x265-win-msvc2013.2014-06-04.rar)

(MSVC 2013.2, 32-Bit and 64-Bit binaries, 8-bpp and 16-bpp)

LigH

4th June 2014, 08:20

x265 1.1+3-1fe42453d2e3 (https://www.mediafire.com/download/h45yzrgxjn86s46/x265_1.1+3-1fe42453d2e3.7z) is up. Time to clean up my HEVC folder (https://www.mediafire.com/folder/6lfp2jlygogwa//HEVC) a bit and remove 0.8 versions.

Atak_Snajpera

4th June 2014, 17:20

x264 --crf 22 --preset medium (average bitrate 966 kbps)
http://i.imgur.com/4ZRwIi5.png

x264 --crf 22 --preset veryslow (average bitrate 886 kbps)
http://i.imgur.com/gTqmkjJ.png

x265 --crf 20 --preset medium (average bitrate 992 kbps)
http://i.imgur.com/TT9h3Ok.png
(http://i.imgur.com/TT9h3Ok.png)

UPDATE

x265 --crf 20 --preset medium --rd 6 --psy-rd 0.2 (average bitrate 915 kbps)
http://i.imgur.com/iu1fWmh.png

x264 --crf 20 --preset veryslow --no-psy (average bitrate 903 kbps)
http://i.imgur.com/6DTT23H.png

In this example x265 with psy looks more or less like x264 with psy disabled. In other hand x264 with enabled psy looks much better than without it. Unfortunately We still do not see that big leap in quality with x265's psy yet.

UPDATE 2

x265 --crf 20 --preset medium --rd 6 --psy-rd 0.5 (average bitrate 957 kbps)
http://i.imgur.com/TXTdeHp.png

x265 --crf 20 --preset medium --rd 6 --psy-rd 1.0 (average bitrate 1060 kbps)
http://i.imgur.com/42gksNo.png

x265_Project

5th June 2014, 20:08

In this example x265 with psy looks more or less like x264 with psy disabled. In other hand x264 with enabled psy looks much better than without it. Unfortunately We still do not see that big leap in quality with x265's psy yet.

Try a little bit higher --psy-rd strength... 0.4 to start with.

nekrosoft13

5th June 2014, 20:45

i'm quite new to x265, can files be smaller (at smaller kbps) compared to x264 and still have the same image image quality?

if yes, about how much smaller?

sneaker_ger

5th June 2014, 21:22

The comparisons between x264 and x265 are inconclusive at this point in time. Sometimes x265 is better, sometimes worse than x264.

benwaggoner

5th June 2014, 21:32

The comparisons between x264 and x265 are inconclusive at this point in time. Sometimes x265 is better, sometimes worse than x264.
For low-bitrate UHD content, x265 beats x264 by a huge margin, at least with --preset veryslow.

It does require a lot of patience, though :).

Atak_Snajpera

5th June 2014, 22:10

A lot of patience or multiple 14c / 24t xeons on board ;) x265 can easily degrade your fancy overclocked i7 to the "pentium 4" level ;)

benwaggoner

5th June 2014, 22:14

A lot of patience or multiple 14c / 24t xeons on board ;)
Both :). I'm getting ~200:1 times on a sixteen core Ivy Bridge! Tuned for absolute quality to an unreasonable degree; I'm sure I could be a lot faster with only a few extra percent bitrate.

Romario

6th June 2014, 01:56

Nice changes, x265_project. :)

But I wait 2-pass encoding. Is it possible for version 1.2 ?

x265_Project

6th June 2014, 04:31

Nice changes, x265_project. :)

But I wait 2-pass encoding. Is it possible for version 1.2 ?
Thanks.

We're just starting to work on 2-pass encoding. It will take more than one milestone.

Atak_Snajpera

6th June 2014, 13:26

Try a little bit higher --psy-rd strength... 0.4 to start with.

I've have updated my post with 0.5 and 1.0. Still x264's psy looks better.

benwaggoner

6th June 2014, 20:26

I've have updated my post with 0.5 and 1.0. Still x264's psy looks better.
The differences are pretty small though, particularly as the frame is paused. And both encodes look pretty good.

It might be interesting to compare at 500 Kbps where HEVC compression efficiency will have more to do.

Also, I thought psy-rd didn't kick in without --rd of 5+

See http://x265.readthedocs.org/en/default/cli.html?highlight=psy-rd#cmdoption--psy-rd

--psy-rd <float>
Influence rate distortion optimizations to try to preserve the energy of the source image in the encoded image, at the expense of compression efficiency. 1.0 is a typical value. Default disabled. It only has effect on presets which use full RDO-based decisions (slower, veryslow and placebo)

Range of values: 0 .. 2.0

Although the --help says Slow, not Slower is the minimum required.

--psy-rd <0..2.0> Strength of psycho-visual optimization. Requires slow preset or below. Default 0.000000

Given Slow is --rd 4 and Slower+ is --rd 6, I think the online documentation is correct. So I'd test with at least --preset slower.

Atak_Snajpera

6th June 2014, 21:30

but i forced --rd 6 ! Take a look at my post again.

I think that ~1mbps for 1280x534 is already very low. Besides x264 veryslow is at least 2x faster than x265 with medium preset plus rd 6 and still looks great.

For sane bitrates x264 is still a better choice for most users.

benwaggoner

6th June 2014, 21:37

but i forced --rd 6 ! Take a look at my post again.
Ah, sorry.

I think that ~1mbps for 1280x534 is already very low.
Low for x264. But low for HEVC? I don't think we know that yet?

Besides x264 veryslow is at least 2x faster than x265 with medium preset plus rd 6 and still looks great.
Sure. And we can't expect that x265 would ever be as fast as x264, as it just has so many more choices it can make. The expectation is that with HEVC we'll be able to trade of longer encoding time for significantly lower bitrates versus H.264.

I think it's too early to start worrying about quality @ speed with x265, since it's had many years less optimization than x264. Its potential quality is more interesting today.

For sane bitrates x264 is still a better choice for most users.
But sane bitrates are defined by what looks good in x264, so that's kind of a circular definition. Sane bitrates were a lot higher five years ago, and they'll be a lot lower in five more. I'd like to see how x264 and x265 compare at a sane bitrate for HEVC. There's definitely a crossover point below which the greater intrinsic efficiency of HEVC makes up for the relative rawness of x265's perceptual quality tuning versus x264. And that crossover point is getting higher.

Atak_Snajpera

6th June 2014, 21:49

at 1mbps both x265 and x264 already have problems to keep fine details. I will post tomorrow original frame to show you how many fine details on his face is removed. if i reduce bitrate 2 times x265 will have to remove even more details. I don't think you will enjoy watching wax figures instead of actors ;)

Romario

7th June 2014, 00:08

Thanks.

We're just starting to work on 2-pass encoding. It will take more than one milestone.

Ok, thanks on answer.

Can you, please, tell me about future optimisations. I wait for more FPS then we have now. When we can except GREAT optimisations in speed ?

foxyshadis

7th June 2014, 00:59

Ok, thanks on answer.

Can you, please, tell me about future optimisations. I wait for more FPS then we have now. When we can except GREAT optimisations in speed ?

The Wiki TODO page (https://bitbucket.org/multicoreware/x265/wiki/TODO) is reasonably up to date with what's coming up, in no particular order. You can look at the history and see how much has been accomplished. The only answer to "when" is "when it's done" or "maybe not ever", so I don't think that's a useful question; the conversion of everything to assembly may have been the last big free performance boost for a while. We'll have to see.

Atak_Snajpera

7th June 2014, 11:58

fumoffu

8th June 2014, 16:24

Cool comparison and the results are rather sad ;/
but your uncompressed frame is not the same frame...

Atak_Snajpera

8th June 2014, 18:31

but your uncompressed frame is not the same frame...

nope!

frame 6519
http://i.imgur.com/RP0rHp9.png

frame 6520 (from previous post)
http://i.imgur.com/aGKEjdC.png

frame 6521
http://i.imgur.com/b4UC66H.png

fumoffu

8th June 2014, 21:49

hmm weird...
in both encoded versions the left eyebrow/eyelashes seem higher and light reflexes in eyes are different from uncompressed but the same in x264 and x265. I guess motion estimation/compression algorythms are similar in both?
Just in case: what do you use for grabbing those frames? I'm asking because for example MPC-HC which I usually use for this is very unreliable with frame numbers and it often goes to the wrong one. And from the ones you posted it looks like they are out of order, it seems they should go: 6520,6521,6519... (or the other way around 6519,6521,6520)

LigH

9th June 2014, 11:42

A more reliable way to catch the same frame is probably using AviSynth with L-SMASH Works and ImageWriter.

benwaggoner

9th June 2014, 19:16

nope!

frame 6519
http://i.imgur.com/RP0rHp9.png

frame 6520 (from previous post)
http://i.imgur.com/aGKEjdC.png

frame 6521
http://i.imgur.com/b4UC66H.png
Can you share the actual video files for these? It's hard to judge how visible these differences would be in motion as opposed to a still image.

Sagittaire

9th June 2014, 21:56

Uncompressed frame
http://i.imgur.com/MU2RNcd.png

x265 --crf 20 --preset medium --rd 6 --psy-rd 1.0 (average bitrate 1060 kbps)
http://i.imgur.com/42gksNo.png

x264 --crf 22 --preset veryslow (average bitrate 886 kbps)
http://i.imgur.com/gTqmkjJ.png

and as always that doesn't mean anything because you can have pframe for x264 and bframe for x265. For the same sample you can certainely say that x265 win with pframe if x264 use pyramidal bframe. Conclusion for frame N will be not the same for frame N+1. If you want make comparison like that, you must use x264 and x265 in constant quantizer mode and certainely not in cfr mode.

Atak_Snajpera

9th June 2014, 22:30

i will upload full 10 min samples tomorrow so you can judge yourself. x265 psy is always more blury than x264's psy. I would have to increase psy strength to atleast 1.5 to achieve similar level of detail. Unfortunatelly this would generate even higher average bitrate.

LoRd_MuldeR

10th June 2014, 01:41

I would have to increase psy strength to atleast 1.5 to achieve similar level of detail. Unfortunatelly this would generate even higher average bitrate.

You should always compare clips of the same size (same average bitrate), otherwise the comparison is meaningless.

So if Psy-RD strength 1.5 increases the bitrate in CRF mode, you need to increase your CRF value in order to compensate. Or use ABR mode right away.

Anyway, from my tests Psy-RD strength 1.5 will be far too high. I was getting very obvious artifacts with a strength of "only" 1.0 :scared:

(x265 project recommends something in the 0.2 to 0.4 range)

mandarinka

10th June 2014, 05:36

Yes, but strength 0.5 is really too little to attain grain/texture retention like x264 can, he's correct in that.

Atak_Snajpera

10th June 2014, 12:57

Sagittaire

10th June 2014, 22:44

x265 --crf 20 --preset medium --rd 6 --psy-rd 1.0 (average bitrate 1060 kbps) - ENCODING TIME : 22m55s
https://mega.co.nz/#!kM80wCTI!rIhFZ40t-9i_yISWiUN_rJ-4pEG6sdgi_7dlLY0f-a4

x264 --crf 21 --preset veryslow (average bitrate 1031 kbps) - ENCODING TIME : 9m22s
https://mega.co.nz/#!0ZcxzajB!QjH8qs4CX0GEZLtJkrUq6qEWkjA40ScXX1s3WR01K5E

frame 6310
x264 -> http://i.cubeupload.com/165cDq.png
x265 -> http://i.cubeupload.com/MAGGW7.png

frame 7380
x264 -> http://i.cubeupload.com/LaMR7r.png
x265 -> http://i.cubeupload.com/Dn0t5C.png

frame 12630
x264 -> http://i.cubeupload.com/IGLRca.png
x265 -> http://i.cubeupload.com/YQIGuD.png

Well I don't understand very well your demonstration. crf 21 for x264 is not really a hard challenge for quality. Certainely that xvid will provide excellente quality too here. x264 is perhaps more sharp and x265 seem more flat for it's for really expert eyes.

Try with 500 kbps and make comparison with same sample and the conclusion will be radicaly different ... :D. For me H265 is designed for make 4K on DVD9 size, 1080p encoding on DVD5 size or 720p encoding on CDR size with really high quality.

benwaggoner

10th June 2014, 22:52

Well I don't understand very well your demonstration. crf 21 for x264 is not really a hard challenge for quality. Certainely that xvid will provide excellente quality too here. x264 is perhaps more sharp and x265 seem more flat for it's for really expert eyes.

Try with 500 kbps and make comparison with same sample and the conclusion will be radicaly different ... :D. For me H265 is designed for make 4K on DVD9 size, 1080p encoding on DVD5 size or 720p encoding on CDR size with really high quality.
I concur the tests will be more interesting at lower bitrates.

Also, why even do CRF? For apples-to-apples 1-pass CBR makes more sense to me. 500 Kbps? With --vbv-maxrate 500 and --vbv-bufsize 1000?

Lastly, I think the same --preset veryslow should be used in both encodes. We know x265 isn't fully optimized, and if we're not trying to do a quality @ speed test, we should let each codec strut its stuff to see what the potential quality deltas are. Quality @ speed is important, but let's just test one variable at a time.

Atak_Snajpera

10th June 2014, 23:11

I prefer practical tests that's why i used very popular constant quality mode. Preset very slow should be renamed to insanely slow. It is so slow that it is practicaly useless. What will be your next excuse to disapointing quality? Maybe I should use reference encoder next time???

What's the point of reducing bitrate even further if even at current 1mbps we see lack of the details on actors faces. Unlike you sagitare I hate watching actors with applied photoshop's surface blur.

zerowalker

12th June 2014, 04:39

The thing is that x265 currently, can only beat x265 when the bitrates are so low that the fundamental structure of it breaks.
x264 will turn into a block madness, x265 will look like HD vs SD when you compare the two.

When you reach the breaking point where x264 hasn enough bitrate to make the picture, it turns the tide.

This however, as far as i know, is because x264 is optimized for ages and beyond, x265 is more advanced and offers more complexity, but the encoder isn't using everything to it's advantage, like x264 is now.

So i look at it simply as an x264 all over again, but which a greater span of evolution available to it, (Think of it as x264 goes to lvl 99, but x265 can go to 100 and beyond;P).

(How these statements are correct in some sense anyway)

LigH

12th June 2014, 07:23

Are you still speculating why x265 with broken psychovisual enhancements looks worse? I don't remember that they were announced as "fixed".

Some more material to watch (http://www.mediafire.com/?6lfp2jlygogwa): "Johnny" 720p with preset slower and psy-rd 0.0 .. 1.0 in steps of 0.2. I have two more similar clips, any suggestions which combinations of options I should try?

Atak_Snajpera

12th June 2014, 12:53

Certainely that xvid will provide excellente quality too here.
Latest Xvid + slowest settings enabled + 2-pass
https://mega.co.nz/#!IZFmBDqI!4oIPL_XKkvac0-X6L-FRUsOz_z97RR025T7e1W_ZWAA

frame 6310
Xvid -> http://i.imgur.com/B7SXQOa.png

frame 7380
Xvid -> http://i.imgur.com/lIfJWMG.png

frame 12630
Xvid -> http://i.imgur.com/9vCdHCs.png

Indeed "excellente quality"

http://i.imgur.com/sVD4nNH.png
http://i.imgur.com/RdqE8fr.png
http://i.imgur.com/qxQPSRG.png

x264 will turn into a block madness, x265 will look like HD vs SD when you compare the two.
Both will look ugly. x264 will give you blocks while x265 will "apply" ultra strong denoising filter. In both cases important details will be sent to hell ;)

Similar history with audio compression. 48Khz HE-AAC@32kbps with parametric stereo will definitely sound better than mp3 with the same bitrate and so what. The question is : Will you be encoding your FLAC collection for your ipod/smatphone using such ridiculously low bitrate??? I do not think so! Most likely you will be using something between 64kbps-128kbps.

LigH

12th June 2014, 13:21

Both will look ugly. x264 will give you blocks while x265 will "apply" ultra strong denoising filter. In both cases important details will be sent to hell ;)

Already in April I uploaded files to compare: "in_to_tree" 1080p50, encoded with x265 --crf 30 (http://www.mediafire.com/watch/g80s1nszbjqp8po/in_to_tree_1080p50.x265-crf30.mp4) and with x264 in 2-pass using the same (http://www.mediafire.com/watch/65zm6z6ct6u3jgk/in_to_tree_1080p50.x264_br~x265-crf30.mp4) / 2 times (http://www.mediafire.com/watch/l2a9efbuzbvudbj/in_to_tree_1080p50.x264_br~x265-crf30_x2.mp4) / 3 times (http://www.mediafire.com/watch/pshba3nuef6baut/in_to_tree_1080p50.x264_br~x265-crf30_x3.mp4) the bitrate of the x265 encode (each with preset "veryslow"). And I believe I should try again soon.

Atak_Snajpera

12th June 2014, 13:36

@LigH
Try to encode full 2h movie 1920x1080 (16:9) with x265's preset very slow ;) I do not think that end user will leave his PC on for whole week to encode just one movie ;) Do you see where I'm going? Veryslow preset is insanely sloooow to be practically useful. Not to mention about electricity bills ;) Magic tricks won't speed up encoding to sane levels.

nevcairiel

12th June 2014, 14:01

They could change the presets to be faster at the cost of quality, or you could just use a faster preset all by yourself..
You shouldnt be surprised if the "veryslow" preset is ... very slow!

There was never any argument that x265 would be as fast as x264, everyone knows that its going to be slower.

Atak_Snajpera

12th June 2014, 14:21

Test sample : in_to_tree_1080p50.y4m

x265 --crf 30 --preset veryslow --psy-rd 1.0 (average bitrate 3279 kbps) - ENCODING TIME : 6m58s
https://mega.co.nz/#!tV8QEQIC!KXIHtFHO5ABKKl9rPuefZA_DzUuobA8dH5uQ8bq2G88

x264 --crf 29 --preset veryslow (average bitrate 3351 kbps) - ENCODING TIME : 0m49s
https://mega.co.nz/#!lY0jkTwC!y12ljhXV6-roO9aLkJVjVd-GPbLidcyq-zNsjYoAFCY

Frame 50
uncompressed -> http://i.cubeupload.com/FMmLDC.png
x265 -> http://i.cubeupload.com/0cxHBh.png
x264 -> http://i.cubeupload.com/DPAfrZ.png

This is perfect example where details are gone. No matter what encoder you will use.

LigH

12th June 2014, 14:32

There was probably a similar trade-off discussion between H.264 and VC-1, I just don't remember in detail anymore, but I believe that WMV used more elaborate post-processing filters to cover compression artefacts.

Next time I will probably compare a faster x265 preset against the veryslow x264 preset; but I am not sure when and which exactly, it may depend on the development of psy-rd preset limits in x265, and a prerequisite will be that psy-rd will work correctly. Which is not yet the case, as far as I remember. When it is fixed, it may even work with smaller rd levels; surrendering psychovisual features because they are too slow would limit practical use of x265 a lot. Let's be curious and look forward...

LigH

12th June 2014, 15:21

Even more material to watch (http://www.mediafire.com/?6lfp2jlygogwa): "KristenAndSara" 720p with preset veryslow and psy-rd 0.0 .. 1.0 in steps of 0.2.

The artefacts above the left shoulder (Frame ~350) appear to be mainly a temporal development.

http://frupic.frubar.net/shots/31892.jpg

Audionut

12th June 2014, 20:04

@LigH
Magic tricks won't speed up encoding to sane levels.

Some people call it development (http://forum.doom9.org/showthread.php?t=141352)!

What reasonable expectation do you put on x265 becoming "mainstream"? 2 years? There's another 20% or so speed with hardware alone.

I really wish you would stop expecting x265 to be a polished product, here and now. Allow the devs some time to optimise it.

fumoffu

12th June 2014, 20:40

Good news everyone!
I accidentally discovered how do x265 encodes much faster! Basically you take x264 and set aq-strength to some low value like 0.3, you can also turn down psy-rd to similar value. Now you get files that are much smaller (if using CRF) and have very nice edges but unfortunately loose some detail... I was also using preset slow, brames 5 and 0 trellis but that is not too important.
I'm half jocking here but I really was surprised how similar the results are! I suspect those settings could help x264 compete with x265 at those very low bitrates everybody is excited about, come on - give it a try :)

Atak_Snajpera

12th June 2014, 20:44

@Audionut
Honeymoon is over! Time to check what we have now. I'm not going to sit and wait for your permission if i want to do some tests. Get used to it.

x265_Project

12th June 2014, 21:51

I really wish you would stop expecting x265 to be a polished product, here and now. Allow the devs some time to optimise it.
I don't care how, I want it NOW!!! (https://www.youtube.com/watch?v=TRTkCHE1sS4&feature=youtu.be&t=1m54s)

LigH

12th June 2014, 21:59

Especially a "sniper" :sly: should know that patience is a virtue... :p

x265_Project

12th June 2014, 22:10

But seriously folks. We appreciate the passion and the interest. I can assure you that we're working very hard every day to continue to improve x265 in three ways;

Encoding efficiency (subjective visual quality / bit rate)
Performance
Features (rate control, etc.)

Encoding efficiency is our highest priority. It doesn't matter if it goes fast if it doesn't produce the best possible visual quality at any desired bit rate. Our development team is still working to optimize psy-rd, and they are exploring a number of possible improvements to the core algorithms that x265 uses. We'll make these improvements available as soon as they are tested and validated.

Performance is a high priority, and we have a very solid roadmap focused on performance improvements. I don't want to share the details at this point, as we're in discussions with many companies regarding the funding and the priority for these improvements. There are many possible ways to improve performance. Generally, we're working to improve performance without sacrificing efficiency or capabilities.

Features like rate control are always important, especially to our commercial customers. We know where the opportunities for improvement lie, and we have developers who are working on these improvements.

Sagittaire

12th June 2014, 23:45

Latest Xvid + slowest settings enabled + 2-pass
https://mega.co.nz/#!IZFmBDqI!4oIPL_XKkvac0-X6L-FRUsOz_z97RR025T7e1W_ZWAA

frame 6310
Xvid -> http://i.imgur.com/B7SXQOa.png

frame 7380
Xvid -> http://i.imgur.com/lIfJWMG.png

frame 12630
Xvid -> http://i.imgur.com/9vCdHCs.png

Indeed "excellente quality"

http://i.imgur.com/sVD4nNH.png
http://i.imgur.com/RdqE8fr.png
http://i.imgur.com/qxQPSRG.png

Your conclusions are simply ridiculous. I see your sample with xvid codec. And quality is simply, for my eyes, something like DVD quality. For me it's high quality ... at this bitrate. Why use x265 or even x264 here if xvid make really good job?

Your prolem is that you want absolutely prove with really strange test that x264 is superior at x265.

I make many test too. And the reality is that x265 is really superior, and by far, at x264 in difficult situation, in most case. At low quantizer, only expert eyes like your or mine, will see real advantage for x264. For high quantizer, x265 will produce more pleasure result than x264 for really large majority of people.

Make the same encoding at 500 Kbps or even 250 Kbps and see the result. It's not necessary to upload your sample because I know the result.

Please, Atak_Snajpera, now, stop your trooling ...

foxyshadis

13th June 2014, 01:59

Atak_Snajpera, I think you should start a new thread for ongoing comparisons to other codecs (and it'd be helpful to include other codecs than x264 too), or I'll have to split it. This thread should be more about announcements, help using it, and discussions about the ongoing development. The constant comparisons and arguing are really derailing this thread.

My own two cents are that I remember when x264 took days to encode a full length movie, and that was fast when I'd just stepped up from a Pentium M to a Core Duo; now x265 takes the same on my Haswell i7. That's the nature of progress, and why H.264 took so many years to catch on. VP9 is likewise slow as hell right now too, they will slowly become more mainstream as hardware catches up.

nhakobian

13th June 2014, 05:24

I don't care how, I want it NOW!!! (https://www.youtube.com/watch?v=TRTkCHE1sS4&feature=youtu.be&t=1m54s)

I think this one might also be slightly relevant :D:
https://www.youtube.com/watch?feature=player_detailpage&v=Yrst8gmd9Cw#t=24

Back on topic:

I think its impressive how much work you guys have done in such little time. Building on the framework of x264 must have saved some time, but its good seeing someone actively working on new open source encoders. Best of luck!

Guest

13th June 2014, 11:50

@Sagittaire

Please don't trigger flamewars by calling someone a troll. Atak_Snajpera is a highly valued forum member who has made significant contributions.

Let's all keep it technical, please. Thank you.

foxyshadis

14th June 2014, 00:29

Seriously, guys, get over it. (OK, personal attack posts are removed now.)

As far as I'm concerned, any comparison posts are basically useless unless you have all of: Source file (and/or script), encoder version and 8/10 bit, encoder command line, and output sequences. Unless you're showing artifacts, stop posting full frames, they're arbitrary at best and totally misleading at worst, and you need a minimum of a few in a row from a few separate scenes to really tell a story with any confidence. Let the output speak for itself, and let's keep the emotion and ego out of it.

Moving on: I figured out the error in the KristenAndSara sequence; it's so noisy but quantized so flat that the psy-rd is thrown off and tries to pull that noise energy from wherever it can, in this case the hair. psy-rd 1.0 is way too much; it's actually trying to match MORE noise energy than exists in the original area, and totally mispredicting. It's much less ugly with 0.2 or 0.4, although it's apparent that psy-rd is also just a bad idea with very low bitrates. (Makes sense.) The effect completely disappears with --nr 100 even at --psy-rd 1.0.

x265_Project

14th June 2014, 00:48

As far as I'm concerned, any comparison posts are basically useless unless you have all of: Source file (and/or script), encoder version and 8/10 bit, encoder command line, and output sequences. Unless you're showing artifacts, stop posting full frames, they're arbitrary at best and totally misleading at worst, and you need a minimum of a few in a row from a few separate scenes to really tell a story with any confidence. Let the output speak for itself, and let's keep the emotion and ego out of it.

Agree completely with all of the above. Casual thoughts and observations are one thing, but if you're going to argue your point vehemently, show your work.

Moving on: I figured out the error in the KristenAndSara sequence; it's so noisy but quantized so flat that the psy-rd is thrown off and tries to pull that noise energy from wherever it can, in this case the hair. psy-rd 1.0 is way too much; it's actually trying to match MORE noise energy than exists in the original area, and totally mispredicting. It's much less ugly with 0.2 or 0.4, although it's apparent that psy-rd is also just a bad idea with very low bitrates. (Makes sense.) The effect completely disappears with --nr 100 even at --psy-rd 1.0.
Psy-RD is not done yet. It works at low strength (.3 or .4), but you will definitely see artifacts if you use higher strength, and we're not ok with that at all. If you're paying close attention to the devel mailing list you'll see that there are patches in the works. They won't be committed until we're sure they represent two steps forward and no steps back. Psy-RD is not the only visual quality improvement we're working on.

LigH

14th June 2014, 08:08

Plus, you are obviously not only working on (psycho-) visual enhancements, but also on speedups by making the code more efficient. Not many patches will have a noticable effect on their own, but their sum will probably be convenient.

:thanks: Go on, you are still not running out of good ideas.

Atak_Snajpera

14th June 2014, 12:01

LigH

14th June 2014, 13:08

Links to uncompressed sources are useful too for other people to recreate your results, and to compare against the original. Many uncompressed sources are available via the Xiph Media archive, but not all. The talking people in front of the dark blue background are hosted on a finnish server; x265 mentioned the exact filename of one of three in the VideoHelp forum so I was able to find it, but I am not certain if revealing the URL is allowed in public.

The file is called Johnny_1280x720_60.yuv It's 829,440,000 bytes. I can't provide a link... but you may be able to find a copy somewhere.

destanig

14th June 2014, 14:39

Dear Atak_Snajpera,

The feature that controls encoder's attention to fine detail is called Adaptive Quantization. Psy-rd is not about that and no amount of it will make x265 or x264 retain more details.

I encoded ~15 seconds of Drive with medium and placebo presets in the ABR mode. For the medium encode I used --preset medium --rd 6 --psy-rd 0.45 --aq-mode 1 --aq-strength 1.8. The bitrate is 1034 Kbps.
The clip is here:
https://mega.co.nz/#!4M8jWbSR!lSnm0u33yKTD7neJUXN73Txjt5kvNy3huriDEBGw1qM

For the placebo encode I used --preset placebo --psy-rd 0.4 --aq-mode 1 --aq-strength 1.8. The bitrate is 1045 Kbps. The clip is here:
https://mega.co.nz/#!QENxhCYa!LAndZQoBuXfe6pYxeQFOjFF26IF0l11Bjq0OipDnVmU

Both encodes look much better than your x265 and x264 encodes. They retain more details and lack the blocky noise of x264. What your tests show is that the default parameter tuning of x265 is worse than that of x264.

mandarinka

14th June 2014, 15:03

You can't say that in such a blanket matter. Both these features work together to preserve detail, textures and grain, as you can see in x264.

Using just AQ as a tool, you won't get grain retention, or textured flat areas. You need PsyRDO too, to compensate for the encoder's tendency to smooth and discard complexity.

destanig

14th June 2014, 15:26

The doc doesn't say much about PsyRDO. I could very well be wrong but my understanding is that it doesn't code any actual detail from the source at all. It looks at what details have been quantized out and adds noise in place of those to compensate for their absence.

On the other hand, AQ is exactly about removing bits from complex areas and using them in less complex areas like in flat textures.

LoRd_MuldeR

14th June 2014, 15:42

The doc doesn't say much about PsyRDO. I could very well be wrong but my understanding is that it doesn't code any actual detail from the source at all. It looks at what details have been quantized out and adds noise in place of those.

Video encoding is all about making choices! The standard RDO (rate distortion optimization) algorithm tries to minimize the "distortion" (in terms of pixel differences) as well as the "rate" (in terms of bit cost). So, for example, if a particular choice would result in very small bit cost, but also cause very high distortion, then the encoder won't make that choice. Similarly, if a particular choice would result in very small distortion, but cause extraordinary bit cost, the encoder won't make that choice either. In other words, RDO is all about finding the "best" compromise between the distortion and the bit cost. Unfortunately, a "small distortion" alone doesn't necessarily mean that the image looks "sharp" and "detailed" to the human eye!

Now what Psy-RDO does differently is that it considers one additional property: the "complexity" (in terms of variance). Consequently, with Psy-RDO enabled, the encoder will now prefer choices that keep the complexity (variance) of the coded picture as close as possible to the complexity of the original, even if that means a somewhat higher distortion and/or a somewhat higher bit cost. And the Psy-RDO strength controls how much weight the "complexity" measure gets in the encoder's choice making. It should also be obvious that setting the Psy-RDO strength too high will allow for very strong distortions and thus result in nasty artifacts. Keeping the "complexity" as close as possible to the original alone doesn't help either.

See also:
http://x264dev.multimedia.cx/archives/37

LigH

14th June 2014, 15:51

From a certain point of view, "noise" is also "detail"; it just depends if it is recognized as annoying, especially when chaotic and irregular. Or "overly regular" in the wrong situation.

Atak_Snajpera

14th June 2014, 17:01

Sulik

14th June 2014, 17:01

In other words, RDO is all about finding the "best" compromise between the distortion and the bit cost.

IMO, the real problem is that we don't have a good measure of "Distortion", so RDO in its current form would be more appropriately called "RPO", or "Rate-PSNR-Optimization"...

Daemon404

14th June 2014, 17:22

LoRd_MuldeR

14th June 2014, 19:17

IMO, the real problem is that we don't have a good measure of "Distortion", so RDO in its current form would be more appropriately called "RPO", or "Rate-PSNR-Optimization"...

And that's exactly why Psy-RDO has been created, I suppose.

One can also think of Psy-RDO as an enhanced distortion measure that takes into account "complexity" retention - in addition to the classical pixel-wise error (PSNR).

Sulik

14th June 2014, 22:27

And that's exactly why Psy-RDO has been created, I suppose.

It's definitely a step in the right direction, but I guess I'm not as confident in the existing various variance-based psy models. Seems like it's an area that has a lot of room for improvement but seems like little changed since the MPEG-2/TM5 days, in comparison to improvements in coding efficiency -> it seems like there should be both spatial and temporal considerations when measuring distortion (unless we consider residual rate itself a measure of temporal complexity ?).

Sagittaire

15th June 2014, 13:29

And that's exactly why Psy-RDO has been created, I suppose.

One can also think of Psy-RDO as an enhanced distortion measure that takes into account "complexity" retention - in addition to the classical pixel-wise error (PSNR).

yes Psy-RDO can be HVS compromise between different metric like PSNR, SSD or other.

destanig

15th June 2014, 15:32

Looks like my understanding of Psy-rd was oversimplified and may be it still is.

So if a certain detail is quantized out, PsyRDO tries to recover the lost energy by distorting the image.
The quantizer focuses on important details and the PsyRDO masks the loss of unimportant ones by introducing distortion that attempts to keep the original "complexity". This may work very well with things like grain at constrained bitrates: the quantizer doesn't code much of it and the PsyRDO just adds similar amounts of easy-to-code noise that looks like grain.

However, if the problem is with important details being quantized out, it's the quantizer that should be tweaked, not the Psy-rd. Increasing the Psy-rd setting is just going to add more noise in place of those details.

The problem with Atak_Snajpera's Drive encodes is lack of detail in flat areas, which is precisely the problem AQ was made to solve. Increasing AQ strength makes a huge difference here. And this is the point that I'm making with my encodes.

LoRd_MuldeR

15th June 2014, 15:47

So if a certain detail is quantized out, PsyRDO tries to recover the lost energy by distorting the image.

I wouldn't say it actively distorts the image.

Instead, with Psy-RDO enabled, the encoder will be biased towards making choices that preserve the energy/complexity, even if (but not necessarily) those choices result in a somewhat stronger distortion.

And here "distortion" refers to the classical distortion measure, like PSNR!

You can also think of it like this: If the original block had a lot of detail/noise, then Psy-RDO prefers a coded block that also has a lot of detail/noise, even if the detail/noise pattern isn't quite the same.

This is justified by the idea that the human eye has no idea how the original looked like. So detail retention can be more important than resembling the original as accurately as possible.

Of course this has its limits. If you set the Psy-RDO strength too high, the coded picture will diverge too much from the original and you are going to get other nasty problems than just "blurring" ;)

mandarinka

15th June 2014, 16:20

I wouldn't say it actively distorts the image.

Instead, with Psy-RDO enabled, the encoder will be biased towards making choices that preserve the energy/complexity, even if (but not necessarily) those choices result in a somewhat stronger distortion.

I think that is a bit unfortunate way to say about it, because it suggests that the "lower distortion" without psyrdo was inherently a better thing.

However problem is that the rate-distortion metric used is very limited in its "decision-making" ability. Even if plain RDO is supposedly shooting for "least distortion", its results are unbearably smoothed, because the metric doesn't care about noise-like features of the picture and instead supports smoothing them out.

When you look at many such encodes, it is painfully obvious that the smoothing/washing out is very strong and that it outweighs any gains of "decreased distortion" from absence of PsyRDO. In other words, PsyRDO increases distortion as meassured by SSIM and PSNR, but at the same time greatly decreases subjective (or how to call it) distortion caused by all the smoothing effects.

Hence I think it is not very useful to describe psyrdo as something that "increases distortion" or "makes up detail". I would say that ideally, it actually aims to do the same thing as plain RDO, only it has different criteria (not just psnr score)...

Sagittaire

15th June 2014, 17:47

The problem with Atak_Snajpera's Drive encodes is lack of detail in flat areas, which is precisely the problem AQ was made to solve. Increasing AQ strength makes a huge difference here. And this is the point that I'm making with my encodes.

AQ and psyrdo are not the same thing. If codec have problem with detail retention, you can't really solve that with AQ. AQ is here for better bits repartition (HVS sens) in picture with HVS masking like Luma, complexity or contrast. AQ can solve local problem in picture with better quality in dark/flat area for exemple. Anyway AQ can't solve problem to general grain retention in complete picture.

x265_Project

15th June 2014, 19:24

In a literal sense he is correct. Psy-RD does *not* preserve detail. It is psychovisual, and in a simple sense, it recreates the complexity (http://forum.doom9.org/showthread.php?t=138293) of the source frame. That is not the same thing as preserving detail.
Daemon404 - I'm pretty sure that you understand how x265 works, but I think your explanation may be confusing to some. I'll try to clear up the confusion in this thread.

Psy-RD is a simply a metric used for mode decision (the algorithm in x265 that decides how to encode a particular block). Psy-RD is off by default, but when it is turned on it is used to calculate the PsyRDcost in place of the normal rdcost for each candidate. PsyRDcost adds one metric to the mode decision - the psycost (the difference in energy between the source block and the reconstructed block). Psy-RD will bias mode decision towards candidates with energy (level of detail) in the reconstructed (decoded) block that more closely matches the energy of the source block.

Daemon404- When you said that Psy-RD "recreates the complexity of the source frame", some may have interpreted this as x265 modifying pixels (distorting the image). Except for a handful of obvious exceptions (noise reduction, dithering of high bit depth to lower bit depth, quantization, loop filtering) x265 doesn't modify the source pixels. Psy-RD is just a different method of choosing the best way to encode each block.
We're still working to adapt Psy-RD for HEVC, and to improve the Psy-RD algorithm. Our development team decided to make an early implementation available to get some feedback, but more changes are coming.

Daemon404

15th June 2014, 19:35

Daemon404- When you said that Psy-RD "recreates the complexity of the source frame", some may have interpreted this as x265 modifying pixels (distorting the image).

It was pretty clear from the post I linked that it doesn't modify the source pixels, IMO. Also considering the 'RD' in Psy-RD stands for rate distortion, it should also be somewhat clear, at least to anyone with a background in digital video.

foxyshadis

16th June 2014, 01:40

I always give links to encoded files with command line. Screenshots are good for showing lack of details particularly mostly in dark scenes. With improved psy we can atleast quickly notice some progress. No idea why some of you switch to auto defence mode whenever I show weakness of current version of x265. At least end user knows that it is too early to switch from x264 to x265. I wouldn't waste my time for those tests if I didn't see posts claiming that x265 already offers better quality than x264. BTW. When I say better quality I mean more details at certain bitrate. I still have that marketing bull saying "Same quality (level of details) ,half bitrate" in my head ;)

People get annoyed with you because you are demanding x265 put up or shut up over something they've never claimed. They don't even claim to be better than x264 at all, they just let the encoder stand for itself and announce its improvements, you're the only one who expects something more. It's the JCT-VC committee and the press that claimed "same quality at half bitrate", when everyone knows that was the design goals, not even a comparison of the JM with the HM, although that did get close. x264 is not JM, obviously.

You need to tone down the emotion or leave this subject alone. It's obvious that it's developed into a grudge for you, when the other posters here just want to experiment and encourage its development.

xxxxx

16th June 2014, 11:38

LigH

16th June 2014, 11:56

A claim without proof and details, impossible to evaluate its meaning. And 1-pass bitrate based encodes provide worst quality distribution anyway.

Kurtnoise

16th June 2014, 12:07

It will be perfect with 2 pass encoding, i really hope it's coming soon:)
patches for that are coming (https://mailman.videolan.org/pipermail/x265-devel/2014-June/004554.html)...

Atak_Snajpera

16th June 2014, 13:12

kentaru

16th June 2014, 17:51

People who are having difficulty with detail retention in their x265 encodes may want to try lowering the the max CU size. In my tests --ctu=16 works best for SD content and --ctu=32 works well for 1080p. The effect of lowering this value is far more pronounced than psy-rd.

x265_Project

17th June 2014, 03:33

Another psy-rd patch was committed, but more changes are pending. Don't get too excited about the first patch... better to wait for the additional patches that are coming. Hopefully another patch tomorrow, and further patches in the coming days.

Sagittaire

17th June 2014, 12:25

I don't understan how can people say x264 is better. I just made a test with a Big Bang Theory episode at 900kbps, x264 is terrible (people like vax, almost no details, unwatchable), while x265 gives almost the same quality like the source.
It will be perfect with 2 pass encoding, i really hope it's coming soon:)

well it's simple: simply because the test use particular source and/or particular bitrate (really low compexity, really dark, low quantizer encoding ... etc etc). With these source or/and profil encoding, psy optimisation in x264 work very well. Anyway in general case, and particulary at low bitrate, x265 produce really better result than x264, and by far. x265 is abble to encode complete movie at 720p in CDR size at acceptable quality level, not x264.

Sagittaire

17th June 2014, 12:28

A claim without proof and details, impossible to evaluate its meaning. And 1-pass bitrate based encodes provide worst quality distribution anyway.

crf mode produce exactly the same output quality than multipass mode ... without bitrate predictibility anyway.

vivan

17th June 2014, 13:05

well it's simple: simply because the test use particular source and/or particular bitrate (really low compexity, really dark, low quantizer encoding ... etc etc). With these source or/and profil encoding, psy optimisation in x264 work very well.Low complexity? Yeah, crowdrun and parkjoy have really low complexity.
And what is "profil encoding"?

crf mode produce exactly the same output quality than multipass mode ... without bitrate predictibility anyway.Since when 1-pass is multipass?

benwaggoner

17th June 2014, 16:49

Since when 1-pass is multipass?
A CRF encode is essentially the same as a 2-pass VBR encode targeting the same average bitrate. The first pass of a 2-pass encode can be thought of (although it does more than) determining the CRF value that will provide the specified average bitrate.

benwaggoner

17th June 2014, 17:02

I saw this commit from last night:
https://bitbucket.org/multicoreware/x265/commits/3a19a9fdb103979e65a9daf15c46c0735e8d743e

ratecontrol: [CHANGES OUTPUT for 10-bit CRF] Remove QP_BD_OFFSET from Ratecontrol

This offset is added inside Quant (setQPforQuant)

Is this just refactoring, or will it have any impact on what a particular CRF value does in 10-bit mode?

One x264 feature I miss in x265 is that 8-bit and 10-bit CRF values are generally equivalent. x265 needs a substantially higher CRF in 10-bit than in 8-bit mode.

vivan

17th June 2014, 17:04

A CRF encode isPlease check the post I was quoting.

Sagittaire

17th June 2014, 18:36

Low complexity? Yeah, crowdrun and parkjoy have really low complexity.
And what is "profil encoding"?

Since when 1-pass is multipass?

.... etc etc etc

Crowdrun and parkjoy are really really really particular source. And x264 is particulary well tuned for make good encoding with these source (DS work hard on parkjoy with x264). If you want compare x264 and x265 don't use it. When I compare x264 and x265, I make complete movie or long trailer encoding with really various type scene and not only really short scene like Crowdrun and parkjoy.

Sagittaire

17th June 2014, 18:47

Please check the post I was quoting.

well ... please check the post I was quoting too ... lol

A claim without proof and details, impossible to evaluate its meaning. And 1-pass bitrate based encodes provide worst quality distribution anyway

crf 1 pass mode encoding produce exactly the same output quality than multipass mode without final bitrate prediction. Multipass mode is usefull only for bitrate prediction and not for produce better quality. You can have better quality distribution only in one case: multipass VBR with VBV constraint but it's only for really advanced Rate Control.

benwaggoner

17th June 2014, 18:50

I saw this commit from last night:
https://bitbucket.org/multicoreware/x265/commits/3a19a9fdb103979e65a9daf15c46c0735e8d743e
Ah, it's a two parter. https://bitbucket.org/multicoreware/x265/commits/c8973aec5e708d431ffd3f59fa161be79dec6062.

Hopefully we'll get an updated description about how CRF works when this is finished.

vivan

17th June 2014, 19:19

crf 1 pass mode encoding produce exactly the same output quality than multipass mode without final bitrate prediction.yeap, and the sky is blue. We're talking about 1-pass VBR.

Multipass mode is usefull only for bitrate prediction and not for produce better quality.That's obviously wrong. Since encoder doesn't know what lies ahead it can't produce constant quality. That means that some parts of the video will waste bitrate, while others will starve.

You can have better quality distribution only in one case: multipass VBR with VBV constraint but it's only for really advanced Rate Control.What? Do you know what VBV does? It limits peak bitrate, and doesn't let encoder use bitrate it wants. It prevents encoder from encoding with constant quality.

cyberbeing

17th June 2014, 20:29

vivan, you seem to be thinking of 1-pass ABR (Average Bitrate) which indeed will produce worse quality than 2-pass.

This is not true for CRF (Constant Rate Factor) which produces identical quality to 2-pass, in the time of a 1-pass encode. At least in x264, CRF mode and 2-pass will theoretically produce identical encodes if the bitrate is matched exactly. Unless you require strict VBV or an exact file size, there is no reason to waste time on 2-pass with x264. If the same holds true for x265's future 2-pass mode, will depend on how they choose to implement it.

vivan

17th June 2014, 20:50

vivan, you seem to be thinking of 1-pass ABR (Average Bitrate) which indeed will produce worse quality than 2-pass.Of course, because that's what original quote is about!
A claim without proof and details, impossible to evaluate its meaning. And 1-pass bitrate based encodes provide worst quality distribution anyway.

cyberbeing

17th June 2014, 23:11

A claim without proof and details, impossible to evaluate its meaning. And 1-pass bitrate based encodes provide worst quality distribution anyway.
Of course, because that's what original quote is about!

The context of LigH's post (1-pass ABR = worse quality) was about how xxxxx's post lacked details about how his encodes at 900kbps were created. If 1-pass bitrate (ABR) was used at very low bitrates, x264 quality in particular would be crippled. This is why Sagittaire responded in agreement with LigH, that indeed CRF is a superior quality alternative to ABR when performing a 1-pass encode. In the context of doing quality comparisons, ABR mode should not be used. Since x265 does not support 2-pass yet, that means using CRF, and then matching the bitrate with x264 2-pass.
crf mode produce exactly the same output quality than multipass mode ... without bitrate predictibility anyway.

Your response to Sagittaire then made it sound like you didn't realize CRF (1-pass VBR) has the same quality as multipass encodes.
Since when 1-pass is multipass?

I assume English is not your first language, since the context of Sagittaire's post was 'CRF (1-pass VBR) quality', while "Since when 1-pass is multipass?" would be then be commonly interpreted as "Since when is single-pass CRF quality equivalent to multi-pass quality?" which now obviously seems to not be what you intended. Anyway, it sounds like this was all a misunderstanding. Hopefully this clears up why everyone was responding to your posts how they were.

foxyshadis

17th June 2014, 23:26

CRF and 2-pass ABR will differ significantly without lookahead, but disabling lookahead disables so many useful features that there's a good reason only the zero-latency profile does. Technically 2-pass always gets the benefit of a near-infinite lookahead, and therefore some choices will differ, but realistically the benefit of larger lookahead falls off pretty quickly.

Ah, it's a two parter. https://bitbucket.org/multicoreware/x265/commits/c8973aec5e708d431ffd3f59fa161be79dec6062.

Hopefully we'll get an updated description about how CRF works when this is finished.

Based this code:

CHECK(param->rc.rfConstant < -6 * (param->internalBitDepth - 8) || param->rc.rfConstant > 51,
"Valid quality based range: -qpBDOffsetY to 51");

it looks like they're aiming to make crf as close as possible between the two. Last week I could bank on a +5-6 crf for 10bit pretty reliably, but I bet that's changing.

Sagittaire

17th June 2014, 23:52

yeap, and the sky is blue. We're talking about 1-pass VBR.

false ... 1

crf and 2 pass produce exactly the same visual quality for x264 (not bit to bit ... but almost). And xxxxx never talk about ABR 1 pass for the encoding but just 900 kbps encoding. Sorry.

That's obviously wrong. Since encoder doesn't know what lies ahead it can't produce constant quality. That means that some parts of the video will waste bitrate, while others will starve.

false ... 2

really false. You can get "constant quality" with simple constant quantizer mode. Moreover there are predictibility in crf mode with lookahead (for I,P,B,b decision for exemple). 1 pass quality mode (like crf or quant mode) mean simply impossible final bitrate prediction and anything else. Sorry.

What? Do you know what VBV does? It limits peak bitrate, and doesn't let encoder use bitrate it wants. It prevents encoder from encoding with constant quality.

false ... 3

Not really. And I know very, very, very well how VBV work. VBV is little more complexe. It's the only exemple where multipass can be really usefull but you must have really complex Rate Control. Multipass can help to have really optimal Buffer management and obtain more constant quality. Sorry.

I'am french and it's world cup. and 1 ... and 2 ... and 3 ... 0 for me.

xooyoozoo

18th June 2014, 05:28

Technically 2-pass always gets the benefit of a near-infinite lookahead, and therefore some choices will differ, but realistically the benefit of larger lookahead falls off pretty quickly.

Speaking of 2-pass and "infinite" lookahead, I wonder if the x265 dev team has considered moving beyond frame parallelism.

I'm talking about something slightly more elegant than the GOP-parallelism x265 used to do, as after the 1st encoding pass, the encoder should have enough information to cleanly split up the stream at nice cutpoints. Something like this old program (http://www.funknmary.de/bergdichter/projekte/index.php?page=ELDER)... but actively developed. ;)

Scene-parallelism seems like a nice answer HEVC's inherently poorer granularity compared to AVC. It also helps encoding scale pass NUMA barriers and helps prepare for the future of increasingly less-hamstrung (http://www.realworldtech.com/knights-landing-details/2/) Atom designs as well as rising core counts (http://i.imgur.com/kMKfFRN.png) for workstations. A consequence here would be much greater RAM usage, but as long as the feature is opt-in or heuristically activated, it's not as much of a sin as idle resources.

Anyway, this is just something I've been pondering in the face of x265 not using all cores when the source needs few b-frames or has low vertical resolution (stupid 2.35 aspect ratio). On a 2P server, I've played around with scripting something that decodes the entire stream in ffmpeg with '-vf select='gt(scene\,0.4)', greps the log output for scenecut frame nums, launches encodes with the frame ranges, and uses taskset to change the pids's socket affinity. However, it's still inelegant to have to decode the source more times than necessary.

nandaku2

18th June 2014, 07:26

Ah, it's a two parter. https://bitbucket.org/multicoreware/x265/commits/c8973aec5e708d431ffd3f59fa161be79dec6062.

Hopefully we'll get an updated description about how CRF works when this is finished.

Hi,
The CRF patch removed an-almost-bug that was adding bit-depth offsets to the QP twice. As mentioned in the commit message, Ratecontrol does not worry about bitdepth-offsets, that's added in TComTrQuant.

xxxxx

18th June 2014, 07:46

crf and 2 pass produce exactly the same visual quality for x264 (not bit to bit ... but almost). And xxxxx never talk about ABR 1 pass for the encoding but just 900 kbps encoding. Sorry.

I know the difference between ABR 1pass and cfr, i used cfr of course, sorry, i generated a little bit of flame.
I did some test with cfr25 and the result bitrate was between 600-2400 Kbps so my point was i'm waiting for the 2pass encoding.

LigH

18th June 2014, 07:49

Just to confirm the already obvious: By "1-pass bitrate based encodes" I meant ABR, not CRF.

IMHO, there are only few reasons to choose ABR mode (e.g. limited bandwidth). In general, the more freedom the encoder has to vary the bitrate according to the complexity of the scene, the better the quality can be preserved equally. Therefore, quality tests should not use ABR mode, because the quality will vary a lot from scene to scene, and trolling affine people will select the worst scenes to complain.

Motenai Yoda

18th June 2014, 13:44

Not really. And I know very, very, very well how VBV work. VBV is little more complexe. It's the only exemple where multipass can be really usefull but you must have really complex Rate Control. Multipass can help to have really optimal Buffer management and obtain more constant quality. Sorry.

? how decreasing bitrate/quality into high bitrate scenes, and increasing it into low bitrate scene to compensate, will make a costant quality encode (2-pass vbr) more constant quality?

LigH

18th June 2014, 13:52

The difference between encoding with and without VBV rate control is unrestricted VBR (CRF) vs. restricted VBR (CRF with limits based on the estimated decoder buffer utilization).

Dark Eiri

18th June 2014, 14:46

Simulating real world streaming usage would be like we have now, right? 1080p @ 3.5 Mbps / 720p @ 2.5 Mbps? Does x265 look better than x264 in -medium vs -medium at the moment with these rates?

x265_Project

18th June 2014, 15:47

Hi,
The CRF patch removed an-almost-bug that was adding bit-depth offsets to the QP twice. As mentioned in the commit message, Ratecontrol does not worry about bitdepth-offsets, that's added in TComTrQuant.
FYI - nandaku2 is the engineering manager for x265.

benwaggoner

18th June 2014, 18:39

Simulating real world streaming usage would be like we have now, right? 1080p @ 3.5 Mbps / 720p @ 2.5 Mbps? Does x265 look better than x264 in -medium vs -medium at the moment with these rates?
With appropriate tuning, it does in my tests.

Motenai Yoda

18th June 2014, 19:58

The difference between encoding with and without VBV rate control is unrestricted VBR (CRF) vs. restricted VBR (CRF with limits based on the estimated decoder buffer utilization).
Yep but when it's limiting at some high bitrate scenes it lowers quality for these scenes, also to compensate aiming at target bitrate it will increase bitrate/quality on the other ones.
Assuming 2pass w/o vbv is costant quality (that isn't 'cause qcomp rarely will be set to 1), with vbv will be no more constant, but less.

benwaggoner

18th June 2014, 21:47

Some thoughts on today's "how to test and compare" discussions:

Obviously different scenarios have different needs for encoding type. But certainly an ABR + VBV encode is a very common case for many applications, and is supported by essentially all encoders. It works well for apples-to-apples comparison, and does a nice job of highlighting how different sorts of scenes encode within the same file. Note that if rc-lookahead is longer than the maximum number of frames that could be in a VBV, 1-pass and 2-pass should offer essentially identical results.

This is probably the easiest way to get clear comparisons between x264 and x265 today. Of course, other parameters don't map linearly, like --psy-rd, psychovisual tuning modes like --tune film, --rdpenalty, and --preset.

So a real comparison of where the codecs stand today would have to figure out what the optimal perceptual quality settings are for each are. Given how fast x265 is moving, we could have a defined x264 encode as a reference, and then watch how x265 matches that as builds progress.

upyzl

19th June 2014, 03:41

x265_Project

19th June 2014, 03:59

sorry to insert another topic about x265 question, but I want to confirm...
No problem.

Does now x265 8bpp using high-bit internal-precision(e.g. 12bit internal-precision) for encoding?

No. The 8 bit per sample build of x265 uses 8 bits of internal precision.

nandaku2

19th June 2014, 11:18

No problem.

No. The 8 bit per sample build of x265 uses 8 bits of internal precision.

x265_Project and upyzl,

x265 works like x264 in this regard. You could build x265 with HIGH_BIT_DEPTH on, and use this for encoding 8-bit input video. This build (x265-16bpp) will use higher bit depth precision in the encoder internals.

LigH

19th June 2014, 11:42

I still wonder why HIGH_BIT_DEPTH builds of x265 are smaller than the 8 bit per component builds, so they seem to lack of other features?

Kurtnoise

19th June 2014, 12:25

you mean, smaller in size or something else ?

Sagittaire

19th June 2014, 12:39

I still wonder why HIGH_BIT_DEPTH builds of x265 are smaller than the 8 bit per component builds, so they seem to lack of other features?

Pehaps the code itself is less complex (just SSE low level implementation for exemple)

LigH

19th June 2014, 12:39

Yes. I compile the same sources with MinGW GCC 4.8.2 with different options, and after stripping, e.g. the following executable sizes in byte are reported:

x265.exe for Win32:
2270208 B (-DWINXP_SUPPORT=1)
2107392 B (-DWINXP_SUPPORT=1 -DHIGH_BIT_DEPTH=1)

x265.exe for Win64:
2816512 B (-DCMAKE_TOOLCHAIN_FILE=toolchain-x86_64-w64-mingw32.cmake)
2748928 B (-DCMAKE_TOOLCHAIN_FILE=toolchain-x86_64-w64-mingw32.cmake -DHIGH_BIT_DEPTH=1)

There is probably some more elaborate code in some routines for low bit depths only.

upyzl

19th June 2014, 12:57

I see, thank for replys :)

LoRd_MuldeR

19th June 2014, 15:08

I still wonder why HIGH_BIT_DEPTH builds of x265 are smaller than the 8 bit per component builds, so they seem to lack of other features?

Noticed that too. Maybe the optimized assembler code, that exists for many of the "critical" functions, is currently for 8-Bit only and thus won't be included in HIGH_BIT_DEPTH builds.

a5180007

19th June 2014, 20:45

Hi folks,

First of all thanks to MCW for the works they are doing, and to you all for this great post. It's pretty amazing to see how fast x265 development is evolving.

I thought the following personal tests could be of interest for the community.

x265 is 32 bits 8bpp 1.1+88

Source : One minute excerpt from Lionsgate's Bluray 'BrainDead' (1992) (https://drive.google.com/file/d/0B4QaEqxOEYWvTmJjVXpVSmlyeFk/edit?usp=sharing). It has grain, leaves, hair, skin, and even at 18 Mbps it has been starved.

x264 medium no-psy CRF23 (https://drive.google.com/file/d/0B4QaEqxOEYWvS05KX0xROUQtbmc/edit?usp=sharing) vs x265 medium CRF 21.26 (https://drive.google.com/file/d/0B4QaEqxOEYWvODgtS3U4T0xXSTA/edit?usp=sharing)
Here x265 has achieved the milestone of being better than x264 with default presets (psy-rd excluded, until it has been finalised).
Above CRF23 there are lower resolutions where x264 would look better on a FHD screen, so there is little point in compressing x264 above CRF23.
What I don't understand is both have same keyint min/max and scenecut, but x264 has 20 I-frames whereas x265 has 13?
How can I make sure both encodes have the same number of I-frames?

x265 1080p medium CRF 28 (https://drive.google.com/file/d/0B4QaEqxOEYWvTXJzbDhHT0Y3Qjg/edit?usp=sharing) vs x265 896p medium CRF 25.96 (https://drive.google.com/file/d/0B4QaEqxOEYWvdWFPMm1GTjNuUVU/edit?usp=sharing)
The CRF 28 shows a great amount of artifacts, ringing and blocking. The reduced 896p resolution looks slightly better than the 1080p on a full HD screen. So it makes me wonder whether the default RF 28 is not too high?
EDIT : downscale with Repair(BicubicResize(clip,h,v),GaussResize(clip,h,v,p=100),mode=1)

anonymlol

19th June 2014, 21:38

x265_Project

19th June 2014, 22:19

Screenshot comparison (http://screenshotcomparison.com/comparison/79823)
Files (https://mega.co.nz/#!2AoEWQQb!2B0lyxA7ITuNVzx8COgHSqA8R72zNZaKjDGWBmA9oN0)
Full source: elephants_dream 720p from xiph (https://media.xiph.org/video/derf/)

Settings
x264-10bit --level 5.1 --preset veryslow --crf 15.0 --output "720 x264.mkv" "720.avs"

avs4x265.exe 720.avs --crf 20.12 --recon-depth 10 --preset veryslow -o "720 x265.hevc"

edit: x265 1.1+136-59a6891dff51 used for the comparison.
edit2: Just realized I forgot to set preset veryslow for x265, will update in a few min. - fixed
Uhhh... these are two different frames. The frame you used for the x265 screen shot has lots of simulated motion blur, making this a very unfavorable comparison.

As we've discussed here many times, screen shots (still images) have very limited use for codec comparisons. Video is moving pictures, and what looks good in a still frame doesn't always look good as a sequence of moving pictures, and vice versa.

x265_Project

19th June 2014, 22:30

anonymlol

19th June 2014, 22:34

Pretty sure the frames are the same. There are two comparisons (#1 and #2), first one is from the start of the clip, the second one from the end. You can toggle between x264 and x265 with mouseover.

Sagittaire

19th June 2014, 22:55

Pretty sure the frames are the same. There are two comparisons (#1 and #2), first one is from the start of the clip, the second one from the end. You can toggle between x264 and x265 with mouseover.

No not the same frame. Anyway make comparison at crf 15 with x264 is pretty useless. It's something like BluRay level quality. At this bitrate (with this really compressible source) even MPEG2 will certainely produce excellent result.

nevcairiel

19th June 2014, 23:02

There is actually two frames in there. You can switch betweem them by clicking #1 and #2, while you alternate between the x264 and x265 encodes via hovering over the image (or not hovering, as it may be)
Should probably not combine two samples into one comparison, it confuses people. =)

anonymlol

19th June 2014, 23:09

nevcairiel, thank you. :thanks:

I thought it's pretty obvious how the site works.
#1 and #2 are different frames because they are different comparisons (still and motion). #1 and #2 have both 2 images each, you toggle between them by moving your mouse over/off the image.

x264 on mouse out, x265 on mouse over the image. Simple, right?
http://puu.sh/9BcCT/c6deac8673.png

Anyway make comparison at crf 15 with x264 is pretty useless. It's something like BluRay level quality.
It's not useless. I'm going for quality and trying to reach the same quality with x265 while keeping the filesize the same. Unfortunately, x265 still doesn't look as good at the same filesize for high bitrate encodes (but I'm sure it will in the future).

foxyshadis

19th June 2014, 23:56

sorry to insert another topic about x265 question, but I want to confirm...

Does now x265 8bpp using high-bit internal-precision(e.g. 12bit internal-precision) for encoding?
x264 10bpp takes advantage over than x264 8bpp mostly because its 10bit internal-precision though 8bit original input/10bit output
I noticed HEVC has IBDI(Internal bit depth increase) in 2012, but haven't seem in nowadays...

IBDI didn't make it into the spec, it was dropped in 2011 iirc. Since then, InternalBitDepth has only meant:

"If the input video is a different bit depth to InternalBitDepth, it is automatically converted... Note: The effect of this option is as if the input video is externally converted to the InternalBitDepth and then coded with this value as InputBitDepth. The codec has no notion of two different bit depths."

It was dropped because its functionality was basically pointless, an encoder and decoder could easily operate in high bit depth but input/output low without needing a spec for it. There were a few blogs that proudly trumpeted its merits when the HEVC/H.265 spec was finalized, because the Wikipedia page hadn't yet been updated and that was their only reference, heh.

LigH

20th June 2014, 07:05

So the best this comparison tells is: There is so little difference that the toggling was often not noticed while hovering with the mouse, therefore the misunderstanding of the feature. ;)

Unfortunately, as usual, single screenshots explain hardly how annoying loss is perceived while watching the movie. And it was rather little loss, mosytly in not too relevant parts.

a5180007

20th June 2014, 08:47

Try psy-rd and I think you'll see even better results.
Hi Tom, I sure will do when you say psy-rd is ready for testing. But the source is so grainy I'm not convinced psy-rd will bring any benefit at such compression. At least in x264 it does not : it removes a lot of details to put back grain noise. And before testing psy-rd, I wanted to make sure standard SAD rdo was as good as x264 in grain and detail retention.

Are the algorithms for placing I-frames so different in x264 and x265? Why would x265 put one third less I-frames with both scenecuts at 40%? This biases comparison.

EDIT : and it makes single frame comparison with x264 even more pointless.
EDIT 2 : Got it. x264 and x265 --bframes 3 --b-adapt 1 return the same amount of I-frames. Placement and numbers of P and B frames are still totally different though.

upyzl

20th June 2014, 10:02

IBDI didn't make it into the spec, it was dropped in 2011 iirc. Since then, InternalBitDepth has only meant:

It was dropped because its functionality was basically pointless, an encoder and decoder could easily operate in high bit depth but input/output low without needing a spec for it. There were a few blogs that proudly trumpeted its merits when the HEVC/H.265 spec was finalized, because the Wikipedia page hadn't yet been updated and that was their only reference, heh.
so that's it... :thanks:

seems there's no any en/decoder operate in high bit depth but input/output 8bit now...or in fact I missed?(or maybe CPU overhead is too high currently?)
or that means future en/decoder(e.g. x265 in the future) could use high-bit-depth internal-only for 8bit video?

a5180007

20th June 2014, 11:57

Another comparison (still with 1.1+88 e69a427) : x265 medium 1080p CRF 26 (https://drive.google.com/file/d/0B4QaEqxOEYWvTVAtMVQzQ3BJcVU/edit?usp=sharing) vs x265 medium 896p CRF 23.92 (https://drive.google.com/file/d/0B4QaEqxOEYWvRTlXb3AxUlZHTGc/edit?usp=sharing) (same size)

There is still a substantial amount of ringing in the 1080p. The upscaled 896p, although slightly softer, does look better than the 1080p, which suggests that even CRF 26 is too high as the default CRF -at least for this source.

Some frame compares source/1080p/896p to gain time (these are animated PNG, so leave time for the three frames to download -or download the file and open with e.g. Firefox) :

Frame 82 (https://drive.google.com/file/d/0B4QaEqxOEYWvRmNURDZaLWNKVEk/edit?usp=sharing)
Frame 485 (https://drive.google.com/file/d/0B4QaEqxOEYWvM1NRVlF2OHVJcU0/edit?usp=sharing)

EDIT : 896p upscaled with Lanczos2

qyot27

20th June 2014, 16:45

Noticed that too. Maybe the optimized assembler code, that exists for many of the "critical" functions, is currently for 8-Bit only and thus won't be included in HIGH_BIT_DEPTH builds.
If you use the Ninja generator, it shows pretty clearly that the HIGH_BIT_DEPTH builds lack one or two whole files from the build process that the 8-bit builds have (8-bit: 89, 16-bit: 87).

benwaggoner

20th June 2014, 17:49

so that's it... :thanks:

seems there's no any en/decoder operate in high bit depth but input/output 8bit now...or in fact I missed?(or maybe CPU overhead is too high currently?)
or that means future en/decoder(e.g. x265 in the future) could use high-bit-depth internal-only for 8bit video?
You can run HEVC Main 10 with 8-bit input and output. It doesn't really come out meaningfully different, though.

I think the same thing was possible with H.264 High 10, and it would produce meaningfully improved quality compared to just High.

foxyshadis

21st June 2014, 00:13

so that's it... :thanks:

seems there's no any en/decoder operate in high bit depth but input/output 8bit now...or in fact I missed?(or maybe CPU overhead is too high currently?)
or that means future en/decoder(e.g. x265 in the future) could use high-bit-depth internal-only for 8bit video?

The reference encoder (HM) can, x265 can, Mainconcept can, Ateme can... the encoding side definitely has you covered. On the decoding side, the reference decoder can, ffmpeg can, LAV can... basically anything that supports high-bit-depth will support bit depth conversion, as well.

What exactly are you doing that isn't working?

upyzl

21st June 2014, 03:12

@benwaggoner & @foxyshadis

well, to be specific

1) now at same medium bitrate(medium bitrate means, e.g. x264 crf22), x264-10bit act much better than x264-8bit in prevent banding(especially in dark flat area because of gamma compression) if Source has no banding -- of course benefit from high interal bit depth, also have positive to prevent other artifacts -- and now x264-10bit optimize is good enough even at [same encoding time & bitrate], it could still act better quality than x264-8bit

2) x265 8bpp now also use 8bit internal, I should use x265 16bpp for high bit internal -- x265 works like x264 in this regard

3) until now, H.264/AVC 10bit-depth has low compatibility. e.g. we could not use Hardware acceleration for 10bit video; mobile device/PS3 like hardware device(diff from PC could use x86-CPU for generic software decode and almost ignore decode performance and power consumption) playing 10bit video is much difficulty and unfriendly; seems video editing fields is the same(e.g. Adobe Premiere is not support for H.264 10bit video). I'm very worry about HEVC/H.265 age will be the same...

4) and...for [8bit input] and high-bit internal, if use 8bit output rather than 10bit output, should be smaller size at same quality?(I'm Not expert on this)

----
so, I'm interest in 8bit in/output and high-bit internal, especially in encoding
seek for lowest bitrate for same high quality is eternal topic for video compression, and I am, but I also care about a degree of compatibility (and encoding time)...