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. |
28th October 2016, 20:21 | #4361 | Link | |
Registered User
Join Date: Apr 2002
Location: Germany
Posts: 4,926
|
Quote:
__________________
all my compares are riddles so please try to decipher them yourselves :) It is about Time Join the Revolution NOW before it is to Late ! http://forum.doom9.org/showthread.php?t=168004 |
|
29th October 2016, 09:17 | #4362 | Link |
Registered User
Join Date: Nov 2011
Posts: 66
|
@Boulder:
Deblocking filter in HEVC, in my opinion, should always be set lower than what you've been using in H264. For example, I used values of -1 (sometimes -2) in H264, but now use -2 and also, often, -3 in HEVC. Reducing strength of this filter does increase visibility of coding artifacts like blocking and (even more pronounced) ringing, but they seem to be less disturbing and present in smaller areas than in H264, possibly because of different block sizes. I also prefer sharper, detail-rich image with some artifacts better than completely smooth one, especially as newer kind of video content (HD) is often recorded differently than older media and it helps reducing visibility of artifacts (objects in foreground in modern media content are very sharp/focused with a smooth/unfocused/simplified background (that means lower visual complexity and better optimization for low bitrate encoding)). I haven't tried encoding with deblock filter completely off, and some people advised to keep it on at all times anyway, but set to lowest value (-6) if desired. |
29th October 2016, 13:12 | #4363 | Link | |
Registered User
Join Date: Jun 2016
Posts: 116
|
Quote:
|
|
30th October 2016, 18:56 | #4364 | Link |
Registered User
Join Date: Feb 2007
Location: Sweden
Posts: 480
|
x265 v2.1+36-d216cb9b3b47 (MSYS/MinGW, GCC 6.2.0, 32 & 64bit 8/10/12bit multilib EXEs)
|
30th October 2016, 21:26 | #4365 | Link |
German doom9/Gleitz SuMo
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
|
Me too:
x265 2.1+36-d216cb9b3b47 (MSYS/MinGW, GCC 6.2.0, 32 + 64 bit, 8+10+12 bit single EXE + DLL and multi-lib EXE) More advanced options: Code:
--[no-]opt-qp-pps Discard optional HRD timing information from the bistream. Default enabled --[no-]opt-ref-list-length-pps Discard optional HRD timing information from the bistream. Default enabled --[no-]multi-pass-opt-rps Enable storing commonly RPS in SPS in multi pass mode. Default disabled |
30th October 2016, 22:56 | #4366 | Link | |
Registered User
Join Date: Aug 2014
Posts: 50
|
Quote:
Also, as for size, I've been doing testing with 1 minute from The Matrix lately. People mostly standing around talking, lots of fine textures and a decent amount of grain. Using Hybrid, 1080p, CRF 20... Intra/Inter 2 is slightly bigger file than Intra/Inter 1. I did the test again to double check, CRF23, again Intra 2 is slightly bigger. I thought it's supposed to be the opposite. |
|
31st October 2016, 15:51 | #4367 | Link | |
Registered User
Join Date: Jun 2016
Posts: 116
|
Quote:
Also, what are you full settings? |
|
1st November 2016, 03:26 | #4368 | Link | |
Registered User
Join Date: Jan 2014
Posts: 45
|
Quote:
|
|
1st November 2016, 07:24 | #4369 | Link | |
Registered User
Join Date: Aug 2016
Posts: 4
|
Quote:
TU node in quad tree is traversed by depth first search process to find the best TU partition. Aim of limit-tu feature is to limit the depth search range. By limiting the depth search range, the encoder can early exit thus improving the performance with minimal compromise in quality. In limit tu 1, the depth search is limited using breath first search traversing. Here all partitions of current depth are processed before deciding if next depth should be traversed In limit tu 2, depth search is limited by allowing the first partition to recurse fully to maximum allowed depths (--tu-inter/intra-depth value determines the maximum TU depth the encoder is allowed to traverse) and limits the depth search of other partitions by reusing the maximum best depth that the first partition chooses. Since --tu-inter-depth 1 allows the encoder to traverse only upto current depth, limit-tu has no scope to optimize the depth range. Hence limit-tu is enabled only if tu-inter-depth > 1 From the test results: performance : limit-tu 2 > limit-tu 1 quality : limit-tu 1 > limit-tu 2 |
|
1st November 2016, 15:12 | #4371 | Link | |
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
|
Quote:
So, the difference between ctu 64 tu-inter/intra 2 and ctu 32 tu inter-intra 1 is that the first gives the option of a 32x32 tu. Both can down to 16x16 and 8x8. I strongly suspect that some of the benefit of a smaller ctu with faster presets is that they allow smaller tu sizes. The default CTU 64 an tu inter/intra of 1 only gives the option of 32x32 and 16x16 tu sizes. Comparing ctu size impact on its own merits should probably use tu-inter 4 and tu-intra 4 to make sure that the minimum tu size is always 4x4. |
|
1st November 2016, 15:16 | #4372 | Link | |
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
|
Quote:
It is completely predictable that different parameters can have different optimal CRF values to hit the same perceptual quality or the same ABR. |
|
1st November 2016, 15:20 | #4373 | Link | |
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
|
Quote:
|
|
1st November 2016, 15:25 | #4374 | Link | |
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
|
Quote:
Again, I recommend making these comparisons at fixed ABR, or even CBR, since using CRF is going to yield simultaneous changes in ABR and perceptual quality, and we're better off understanding first how changes impact quality at the same bitrate. |
|
1st November 2016, 15:51 | #4375 | Link | |
Registered User
Join Date: Jun 2016
Posts: 116
|
Quote:
|
|
2nd November 2016, 20:32 | #4376 | Link | |
Pig on the wing
Join Date: Mar 2002
Location: Finland
Posts: 5,718
|
Quote:
However, I need to make some more tests with a better source such as The Hobbit. While I'm writing, I'd like to thank for the much improved encoder and --tune grain. It now looks like I can switch to x265 for good. Hopefully I can get me an Intel NUC that supports HW decoding of 10-bit HEVC soon
__________________
And if the band you're in starts playing different tunes I'll see you on the dark side of the Moon... |
|
2nd November 2016, 20:33 | #4377 | Link | |
Pig on the wing
Join Date: Mar 2002
Location: Finland
Posts: 5,718
|
Quote:
__________________
And if the band you're in starts playing different tunes I'll see you on the dark side of the Moon... |
|
3rd November 2016, 05:53 | #4379 | Link |
Derek Prestegard IRL
Join Date: Nov 2003
Location: Los Angeles
Posts: 5,988
|
Damn. --tune grain is amazing.
With a very grainy movie I was able to achieve a 2:1 reduction versus x264 with no quality loss visible during motion. Still frame a:b comparison reveals differences, but nothing earth shattering. |
Thread Tools | Search this Thread |
Display Modes | |
|
|