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. |
10th February 2018, 10:39 | #5902 | Link |
Registered User
Join Date: Nov 2015
Posts: 4
|
Hello everyone, I know that this question was posted a lot of time so apologize: is it true that it's better to encode a 8bit video to 10bit even if the source it's 8 bit? What's the difference? Does the x265 encoder works better? Thank you
|
10th February 2018, 10:46 | #5903 | Link | |
Registered User
Join Date: Oct 2001
Location: Germany
Posts: 7,277
|
Quote:
|
|
10th February 2018, 11:10 | #5904 | Link | |
Pig on the wing
Join Date: Mar 2002
Location: Finland
Posts: 5,733
|
Quote:
Could you repeat the test with some high-detail film content, please?
__________________
And if the band you're in starts playing different tunes I'll see you on the dark side of the Moon... |
|
11th February 2018, 14:44 | #5910 | Link |
Registered User
Join Date: Feb 2002
Location: San Jose, California
Posts: 4,407
|
10-bit is still more efficient, only it is a very small improvement with x265 compared to x264. x265 uses a higher bit depth in important places internally, even when set to 8 bit; its internal data structures are not all required to use the same bit depth as the output video.
Also, banding is never good so that is also a quality/size efficiency boost.
__________________
madVR options explained |
11th February 2018, 15:10 | #5911 | Link |
Registered User
Join Date: Dec 2002
Posts: 5,565
|
The problem is x265 can produce banding even at 10 bit. x264 10bit doesn't have those problems, it's "fire and forget". Hard to beat if you aim for high bitrate/high quality.
https://forum.doom9.org/showthread.p...53#post1762253 |
11th February 2018, 19:00 | #5913 | Link | |
Registered User
Join Date: Apr 2004
Posts: 1,315
|
Quote:
Filmgrain is just a noise. Pleasant noise, but still noise. I’d prefer video source without filmgrain than with it. Two reasons for that. First reason, microscopic details aren’t drowned in grain. Second reason, significantly better compressibility. In the end you have better both: visual quality and compressibility. Win-win situation. Good news that new Netflix series/shows have much less filmgrain or don’t have it at all. Instead of blaming x265 developers for not preserving grain it’s time to forget about useless filmgrain to begin with |
|
12th February 2018, 16:30 | #5914 | Link | |||
Registered User
Join Date: Aug 2007
Posts: 79
|
Quote:
Quote:
Quote:
anyways, since the introduction of the new lambda tables (in v2.4) x265 does a great job with keeping grain. for me it has made x264 obsolete. |
|||
14th February 2018, 10:57 | #5916 | Link |
German doom9/Gleitz SuMo
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,784
|
x265 2.6+39-01b685d6fa33
CMake: fix generation of version info from .hg_archival.txt; fix output to pipe on Windows (enable binary mode) |
18th February 2018, 18:24 | #5917 | Link |
Registered User
Join Date: Feb 2007
Location: Sweden
Posts: 483
|
x265 v2.6+42-52782aeb2081 (GCC 7.3.0, 32 & 64-bit 8/10/12bit Multilib Windows Binaries)
Code:
https://bitbucket.org/multicoreware/x265/commits/branch/default |
20th February 2018, 22:09 | #5918 | Link | |
Banana User
Join Date: Sep 2008
Posts: 990
|
Quote:
|
|
22nd February 2018, 13:27 | #5920 | Link |
Registered User
Join Date: Feb 2007
Location: Sweden
Posts: 483
|
https://bitbucket.org/multicoreware/x265/commits/all
Version 2.7 =========== Release date - 21st Feb, 2018. New features ------------ 1. : option: '--gop-lookahead' can be used to extend the gop boundary (set by '--keyint'). The GOP will be extended, if a scene-cut frame is found within this many number of frames. 2. Support for RADL pictures added in x265. : option: '--radl' can be used to decide number of RADL pictures preceding the IDR picture. Encoder enhancements -------------------- 1. Moved from YASM to NASM assembler. Supports NASM assembler version 2.13 and greater. 2. Enable analysis save and load in a single run. Introduces two new cli options `--analysis-save <filename>` and `--analysis-load <filename>`. 3. Comply to HDR10+ LLC specification. 4. Reduced x265 build time by more than 50% by re-factoring ipfilter.asm. Bug fixes --------- 1. Fixed inconsistent output issue in deblock filter and --const-vbv. 2. Fixed Mac OS build warnings. 3. Fixed inconsistency in pass-2 when weightp and cutree are enabled. 4. Fixed deadlock issue due to dropping of BREF frames, while forcing slice types through qp file. Last edited by Barough; 22nd February 2018 at 13:57. |
|
|