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. |
8th July 2017, 13:30 | #5441 | Link | |
Registered User
Join Date: May 2015
Posts: 185
|
Quote:
|
|
8th July 2017, 21:39 | #5442 | Link | |
Guest
Posts: n/a
|
Quote:
We have a commercial product called UHDkit that can run multiple x264 or x265 instances, in order to get more performance under different circumstances. As you know, x265 is free for anyone who can comply with the terms of the GPL v2 license. This includes large web video services, who don't distribute x265 (they distribute video). UHDkit is our value-added solution designed as an incentive for commercial customers to come to us to get a commercial license, which means they go from being free-riders on the x265 open source project to being sponsors of the project, which means we can hire more developers to improve x265 for everyone. The features in UHDkit are features that only commercial users would need, like the ability to produce multiple bit/quality rate tiers from a single video file twice as efficiently as doing unique encodes, or the ability to do live 4K 60P 10 bit encoding on a many-core (dual socket) server. Of course, anyone can run multiple instances of x265 on a single machine by themselves, but it wouldn't be easy to match the performance optimization features, or the other value-added features in UHDkit. |
|
8th July 2017, 22:08 | #5443 | Link |
RipBot264 author
Join Date: May 2006
Location: Poland
Posts: 7,803
|
High core count on AMD/Intel cpus is not a problem if you are RipBot264 user. All you need to do is activate distributed encoding mode with some servers.
This way you can easily saturate even dual AMD EPYC 7601 cpus (64C/128T) with just 1080p footage.
__________________
Windows 7 Image Updater - SkyLake\KabyLake\CoffeLake\Ryzen Threadripper |
9th July 2017, 14:13 | #5445 | Link |
Registered User
Join Date: Jun 2017
Posts: 89
|
May I ask a question to the x265 devs here?
Why is --sao enabled by default? We recently discussed this in another thread... As the other thread is about high quality encodes, I thought --sao might be beneficial at low bitrates... So I encoded my sample at 400 kbit/s, default settings, no tune. Once default, once with --no-sao. Even at this extremely low bitrate I see no real benefit of --sao. At high bitrates however, nobody seems to like --sao, because it adds a lot of blur. The savings with a CRF also seem minor, considering this is such a big quality impact... So, what is the reason for --sao by default? Am I just missing something or would you consider --no-sao as default? |
9th July 2017, 15:42 | #5446 | Link | |
Registered User
Join Date: Nov 2012
Posts: 218
|
Quote:
|
|
9th July 2017, 15:56 | #5447 | Link |
German doom9/Gleitz SuMo
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,746
|
There are surely cases where SAO makes sense to reduce complexity. Mostly in UHD resolutions where looking at tiny details from a larger distance is less important than looking at small video dimensions close-up, where a pixel still makes an important detail, in relation.
|
10th July 2017, 11:58 | #5448 | Link |
Registered User
Join Date: Jun 2017
Posts: 89
|
Could someone help me out here?:
https://forum.doom9.org/showthread.p...83#post1811483 I would mainly like to know what exactly --hdr-opt actually does. It does come with a bitrate saving, so far so good, but is there a (negative) impact on quality? If so, what kind of impact? I don't see an immediate degradation in that demo video, but it might not be well suited to make out the difference... |
11th July 2017, 00:06 | #5449 | Link |
German doom9/Gleitz SuMo
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,746
|
Most of all, it tells the encoder to expect high dynamic range, and to adapt internal value ranges to characteristics of specific displays.
It is pretty useless for conversion of "usual video" without a high bit depth already in the original video source. If you don't know what "color primaries" mean, don't attempt to use it. |
11th July 2017, 04:39 | #5450 | Link | |
Guest
Posts: n/a
|
Quote:
|
|
11th July 2017, 07:37 | #5451 | Link | |||
Registered User
Join Date: Jun 2017
Posts: 89
|
Thanks for your answers!
Quote:
Quote:
I did encode a 10bit HDR video: Quote:
Does that mean there will be no visible degradation when I use --hdr-opt? |
|||
12th July 2017, 15:41 | #5452 | Link |
German doom9/Gleitz SuMo
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,746
|
x265 2.4+99-3160e1a0cc5f (merge stable+default)
"Allocate frame threads based on available pool threads" ... + a Mac fix and preps for v2.5 milestone. |
12th July 2017, 15:53 | #5453 | Link | |
Registered User
Join Date: May 2015
Posts: 185
|
Quote:
|
|
13th July 2017, 18:03 | #5455 | Link |
Registered User
Join Date: Sep 2015
Posts: 48
|
x265 version 2.5, which includes improvements to grain handling, and improved CSV logging feature which is now built into the library.
Version 2.5 can be downloaded from here (md5: 192e54fa3068b594aa44ab2b703f071d).Full documentation is available at http://x265.readthedocs.io/en/stable/ Release Notes for Version 2.5 ======================= Encoder enhancements -------------------------------- 1. Improved grain handling with --tune grain option by throttling VBV operations to limit QP jumps. 2. Frame threads are now decided based on number of threads specified in the --pools, as opposed to the number of hardware threads available. The mapping was also adjusted to improve quality of the encodes with minimal impact to performance. 3. CSV logging feature (enabled by --csv) is now part of the library; it was previously part of the x265 application. Applications that integrate libx265 can now extract frame level statistics for their encodes by exercising this option in the library. 4. Globals that track min and max CU sizes, number of slices, and other parameters have now been moved into instance-specific variables. Consequently, applications that invoke multiple instances of x265 library are no longer restricted to use the same settings for these parameter options across the multiple instances. x265 can now generate a seprate library that exports the HDR10+ parsing API. Other libraries that wish to use this API may do so by linking against this library. Enable ENABLE_HDR10_PLUS in CMake options and build to generate this library. 5. SEA motion search receives a 10% performance boost from AVX2 optimization of its kernels. 6. The CSV log is now more elaborate with additional fields such as PU statistics, average-min-max luma and chroma values, etc. Refer to documentation of --csv for details of all fields. 7. x86inc.asm cleaned-up for improved instruction handling. API changes ----------------- 1. New API x265_encoder_ctu_info() introduced to specify suggested partition sizes for various CTUs in a frame. To be used in conjunction with --ctu-info to react to the specified partitions appropriately. 2. Rate-control statistics passed through the x265_picture object for an incoming frame are now used by the encoder. 3. Options to scale, reuse, and refine analysis for incoming analysis shared through the x265_analysis_data field in x265_picture for runs that use --analysis-reuse-mode load; use options --scale, --refine-mv, --refine-inter, and --refine-intra to explore. 4. VBV now has a deterministic mode. Use --const-vbv to exercise. Bug fixes ------------- 1. Several fixes for HDR10+ parsing code including incompatibility with user-specific SEI, removal of warnings, linking issues in linux, etc. 2. SEI messages for HDR10 repeated every keyint when HDR options (--hdr-opt, --master-display) specified. Happy compressing! |
13th July 2017, 21:39 | #5456 | Link |
German doom9/Gleitz SuMo
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,746
|
Realistic guess, then!
x265 2.5+2-18fa144d453e (merge with stable; new v2.5 milestone) SEI payload message writing fixed |
15th July 2017, 17:58 | #5458 | Link |
Registered User
Join Date: Feb 2007
Location: Sweden
Posts: 481
|
x265 v2.5+3-3f6841d271e3 (GCC 7.1.0, 32 & 64-bit 8/10/12bit Multilib Windows Binaries)
x265 [info]: HEVC encoder version 2.5+3-3f6841d271e3 x265 [info]: build info [Windows][GCC 7.1.0][32/64 bit] 8bit+10bit+12bit x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2 Code:
https://bitbucket.org/multicoreware/x265/commits/branch/default |
Thread Tools | Search this Thread |
Display Modes | |
|
|