Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Video Encoding > High Efficiency Video Coding (HEVC)

Reply
 
Thread Tools Search this Thread Display Modes
Old 24th September 2013, 03:11   #1  |  Link
x265_Project
Guest
 
Posts: n/a
x265 HEVC Encoder

We've made a number of substantial improvements to x265 in the past few weeks. x265 documentation can be found here... http://x265.readthedocs.org/en/default/

Tom
MulticoreWare

Last edited by x265_Project; 1st November 2015 at 06:46. Reason: Removing old link to Evaluator's Guide... documentation is now online
  Reply With Quote
Old 24th September 2013, 08:04   #2  |  Link
spookybathtub
Registered User
 
Join Date: Sep 2013
Posts: 7
What is the maximum resolution supported by x265?
spookybathtub is offline   Reply With Quote
Old 24th September 2013, 09:12   #3  |  Link
professor_desty_nova
Registered User
 
professor_desty_nova's Avatar
 
Join Date: Nov 2006
Posts: 55
It seems there a typo on the latest evaluators guide...
The new option "rd" appears as "-rd" on changes and suggested settings, and as "--rd" on "Standalone Executable Options" later on the same guide.

PS: only --rd works on x265.exe.

Last edited by professor_desty_nova; 24th September 2013 at 09:21.
professor_desty_nova is offline   Reply With Quote
Old 24th September 2013, 12:41   #4  |  Link
filler56789
SuperVirus
 
filler56789's Avatar
 
Join Date: Jun 2012
Location: Antarctic Japan
Posts: 1,351
Has anybody ever tested the following statement?

Quote:
If not building in Windows XP but want the binary to be XP-compatible, enable WINXP_SUPPORT Cmake option.
Because so far, I still haven't seen any MSVS build of x265 compiled on a non-XP machine that can actually run under Windows XP.
Either you get the error message

Code:
The procedure entry point InterlockedCompareExchange64 could not be located in the dynamic link library KERNEL32.dll.
or you get the error message

Code:
"Path-To\x265.exe" is not a valid Win32 application.

Last edited by filler56789; 24th September 2013 at 13:02.
filler56789 is offline   Reply With Quote
Old 24th September 2013, 21:20   #5  |  Link
x265_Project
Guest
 
Posts: n/a
Quote:
Originally Posted by professor_desty_nova View Post
It seems there a typo on the latest evaluators guide...
The new option "rd" appears as "-rd" on changes and suggested settings, and as "--rd" on "Standalone Executable Options" later on the same guide.

PS: only --rd works on x265.exe.
Thanks. Microsoft Word was auto-correcting double hyphens (--) to a single dash (–), driving me crazy until I found the setting that prevents this. We've posted a corrected version of the guide. x265_Evaluators_Guide_09-24-13.pdf

We welcome participation in the project in every way, including help with better documentation (explanations of settings, etc.) and with any feedback on usage, etc. This has been challenging up to this point as x265 has been a moving target, undergoing fairly substantial fundamental changes over the past 6 months. We should be evolving to the point where we are doing more performance optimization of the existing algorithms, rather than replacing / implementing them, and to where we are able to focus on additional features and platforms.

We continue to experiment to find the most optimal settings for different situations, and we expect to have x264 style presets at some point (slow, faster, fastest, etc.). But we also welcome feedback in this area.

Thanks
Tom

Last edited by x265_Project; 24th September 2013 at 22:57.
  Reply With Quote
Old 24th September 2013, 13:33   #6  |  Link
Kurtnoise
Swallowed in the Sea
 
Kurtnoise's Avatar
 
Join Date: Oct 2002
Location: Aix-en-Provence, France
Posts: 5,191
Try this build...
Kurtnoise is offline   Reply With Quote
Old 24th September 2013, 14:03   #7  |  Link
filler56789
SuperVirus
 
filler56789's Avatar
 
Join Date: Jun 2012
Location: Antarctic Japan
Posts: 1,351
Quote:
Originally Posted by Kurtnoise View Post
Try this build...
It works ( finally, \o/ )
filler56789 is offline   Reply With Quote
Old 24th September 2013, 17:54   #8  |  Link
ndkamal
Registered User
 
Join Date: May 2005
Location: Paris
Posts: 48
Will it have avisynth input ?

Like x264 encoder.
__________________
Intel Core i5 4200
RAM 8 Go
Nvidia GeForce 840M
Windows 10
ndkamal is offline   Reply With Quote
Old 24th September 2013, 20:24   #9  |  Link
filler56789
SuperVirus
 
filler56789's Avatar
 
Join Date: Jun 2012
Location: Antarctic Japan
Posts: 1,351
Quote:
Originally Posted by ndkamal View Post
Will it have avisynth input ?

Like x264 encoder.
Only indirectly, I'm afraid,
"stdin for video input in CLI app" is on their TODO list
( but that's a start, at least )

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

Last edited by filler56789; 25th September 2013 at 07:46.
filler56789 is offline   Reply With Quote
Old 25th September 2013, 07:22   #10  |  Link
x265_Project
Guest
 
Posts: n/a
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/...ki/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.
  Reply With Quote
Old 25th September 2013, 07:58   #11  |  Link
smok3
brontosaurusrex
 
smok3's Avatar
 
Join Date: Oct 2001
Posts: 2,392
Why not use a name that stands out a bit, like y265 ?
(Just a suggestion)
__________________
certain other member
smok3 is offline   Reply With Quote
Old 26th September 2013, 04:46   #12  |  Link
lainiwaku
Registered User
 
Join Date: Jul 2013
Posts: 3
is it hard to use command line version ? i always used MeGui for x264
lainiwaku is offline   Reply With Quote
Old 26th September 2013, 06:51   #13  |  Link
x265_Project
Guest
 
Posts: n/a
Quote:
Originally Posted by lainiwaku View Post
is it hard to use command line version ? i always used MeGui for x264
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
  Reply With Quote
Old 14th October 2013, 08:47   #14  |  Link
nakTT
Registered User
 
Join Date: Dec 2008
Posts: 415
Quote:
Originally Posted by lainiwaku View Post
is it hard to use command line version ? i always used MeGui for x264
Same here. I hope some GUI like MeGUI etc could integrate this encoder. I would love to do testing with this new encoder.
nakTT is offline   Reply With Quote
Old 26th September 2013, 05:10   #15  |  Link
iwod
Registered User
 
Join Date: Apr 2002
Posts: 756
Something less related. Is DS working on x265 yet?
iwod is offline   Reply With Quote
Old 26th September 2013, 06:54   #16  |  Link
x265_Project
Guest
 
Posts: n/a
Quote:
Originally Posted by iwod View Post
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
  Reply With Quote
Old 27th September 2013, 13:37   #17  |  Link
Daemon404
Registered User
 
Join Date: Mar 2005
Posts: 128
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.

Pretty graph here.

Last edited by Daemon404; 27th September 2013 at 13:38. Reason: Grammar
Daemon404 is offline   Reply With Quote
Old 27th September 2013, 21:09   #18  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,746
Doesn't tell me much more than "they are not completely different". But I feel that is a good conclusion.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 1st October 2013, 07:52   #19  |  Link
zerowalker
Registered User
 
Join Date: Jul 2011
Posts: 1,121
Could someone put some Screen Comparisons of x265 and x264?
zerowalker is offline   Reply With Quote
Old 1st October 2013, 08:59   #20  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,746
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.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 06:40.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.