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. |
![]() |
#7621 | Link |
Derek Prestegard IRL
![]() Join Date: Nov 2003
Location: Los Angeles
Posts: 5,998
|
3.4 has been tagged for release!
https://bitbucket.org/multicoreware/...ch/Release_3.4 Release notes - v3.4 ----------------------------- New features ------------------ • Edge-aware quadtree partitioning to terminate CU depth recursion based on edge information. --rskip 2 enables the feature and --rskip-edge-threshold <0..100> denotes the minimum expected edge-density percentage within the CU, below which the recursion is skipped. Experimental feature. • Application-level feature --abr-ladder for automating ABR ladder generation. Shows ~65% savings in the over-all turn-around time required for the generation of a typical HLS ladder in Intel(R) Xeon(R) Platinum 8280 CPU @ 2.70GHz over a sequential ABR-ladder generation approach that leverages save-load architecture. Enhancements to existing features ---------------------------------------------- • Improved 2-pass rate-control algorithm. The savings in the bitrate is ~1.72% with visual improvement in quality in the initial 1-2 secs. Encoder enhancements -------------------------------- • Faster ARM64 encodes enabled by ASM contributions from Huawei. The speed-up over no-asm version for 1080p encodes @ medium preset is ~15% in a 16 core H/W. • Strict VBV conformance in zone encoding. Bug fixes ------------ • Multi-pass encode failures with --frame-dup. • Corrupted bitstreams with --hist-scenecut when input depth and internal bit-depth differ. • Incorrect analysis propagation in multi-level save-load architecture. • Failure in detecting NUMA packages installed in non-standard directories. |
![]() |
![]() |
![]() |
#7622 | Link |
Registered User
Join Date: Jan 2015
Posts: 287
|
I've updated my x265 builds. x265-3.4+1 is built from the stable branch (stable release) and x265-3.4+6 is built from the master branch. Both builds are 64-bit multilib windows binaries.
Last edited by Patman; 31st May 2020 at 12:25. |
![]() |
![]() |
![]() |
#7624 | Link | |
Testeur de codecs
Join Date: May 2003
Location: France
Posts: 2,530
|
Quote:
__________________
Le Sagittaire ... ;-) 1- Ateme AVC or x264 2- VP7 or RV10 only for anime 3- XviD, DivX or WMV9 |
|
![]() |
![]() |
![]() |
#7628 | Link |
Registered User
Join Date: Aug 2009
Posts: 91
|
I have been stuggling for months with ugly distortions (smearing that kinda looks like motion blur with banding) in fast moving scenes and finally found out that x265's CUTree is to blame.
Turning it off solves it, but the bitrate blows up when trying to keep the same overal quality in other scenes. Is there any way to make CUTree 'less agressive' or set it to 50% for example or some threshold parameter? Last edited by K.i.N.G; 8th June 2020 at 22:49. |
![]() |
![]() |
![]() |
#7630 | Link | |
Registered User
Join Date: Aug 2009
Posts: 91
|
Quote:
For this footage, lets say arround 15K since its for streaming. I restarted the encode with --ctu 32 (instead of --ctu 64) Last edited by K.i.N.G; 9th June 2020 at 00:15. |
|
![]() |
![]() |
![]() |
#7632 | Link |
Pig on the wing
Join Date: Mar 2002
Location: Finland
Posts: 5,812
|
By your description, it looks like the infamous onion artifacts. Have you tried --rd 6 with --rd-refine?
__________________
And if the band you're in starts playing different tunes I'll see you on the dark side of the Moon... |
![]() |
![]() |
![]() |
#7634 | Link | ||
Registered User
Join Date: Aug 2009
Posts: 91
|
Quote:
I will make sure to try those out next after this encode, which will run for a few days. Quote:
Normally I raise the qcomp to something like 0.70-0.75 and raise the CRF by ±0.5 which 'fixes' it to more acceptable levels. Though... I always wondered if there was another (more efficient) way to control CUTree's strength/agressiveness more directly... (if I understand correctly qcomp controls a lot more than just things that are influenced by cutree). Hence my question here. Last edited by K.i.N.G; 10th June 2020 at 12:37. |
||
![]() |
![]() |
![]() |
#7635 | Link | ||
Pig on the wing
Join Date: Mar 2002
Location: Finland
Posts: 5,812
|
Quote:
![]() Quote:
__________________
And if the band you're in starts playing different tunes I'll see you on the dark side of the Moon... |
||
![]() |
![]() |
![]() |
#7636 | Link | |
Moderator
![]() Join Date: Jan 2006
Location: Portland, OR
Posts: 4,955
|
Quote:
> This patch does the following: > 1. Automatically decides the AQ Mode for each frame, using its scene > statistics, such as luma intensity and edge density. > 2. Add option "--auto-aq" to enable auto detection of AQ Mode per frame. |
|
![]() |
![]() |
![]() |
#7637 | Link |
Registered User
Join Date: Oct 2014
Posts: 23
|
CUTree granularity depends on CU depth recursion. --rskip 0 or 2 reduces onion effect. More early exits from CU recursion = bigger CUs = higher chances of wrong CU propagation and artifacts in motion.
x265 RDO loves to skip blocks, and CUTree artifacts are a consequence of this. Decreasing max-merge also helps, reducing artifacts and skipped blocks. Sometimes even setting bframes=0 decrease artifacts in motion. Last edited by fauxreaper; 10th June 2020 at 23:29. |
![]() |
![]() |
![]() |
#7638 | Link |
Pig on the wing
Join Date: Mar 2002
Location: Finland
Posts: 5,812
|
I've never understood why max-merge gets increased in the slower and supposedly higher quality profiles. I always have it at '2'.
__________________
And if the band you're in starts playing different tunes I'll see you on the dark side of the Moon... |
![]() |
![]() |
![]() |
#7639 | Link | |
Pig on the wing
Join Date: Mar 2002
Location: Finland
Posts: 5,812
|
Quote:
Code:
rskip 1 rskip 2 Intra 64x64 DC 0,00 % 0,00 % Intra 64x64 Planar 0,00 % 0,00 % Intra 64x64 Ang 0,00 % 0,00 % Intra 32x32 DC 2,03 % 1,24 % Intra 32x32 Planar 1,21 % 0,79 % Intra 32x32 Ang 9,08 % 3,61 % Intra 16x16 DC 0,92 % 0,36 % Intra 16x16 Planar 0,43 % 0,15 % Intra 16x16 Ang 8,00 % 2,46 % Intra 8x8 DC 0,25 % 0,14 % Intra 8x8 Planar 0,06 % 0,04 % Intra 8x8 Ang 3,75 % 1,61 % 4x4 0,45 % 0,44 % Inter 64x64 6,50 % 49,71 % Inter 64x64 (Rect) 0,29 % 15,61 % Inter 32x32 19,90 % 6,50 % Inter 32x32 (Rect) 1,05 % 0,91 % Inter 16x16 16,78 % 4,27 % Inter 16x16 (Rect) 0,91 % 0,05 % Inter 8x8 6,65 % 2,21 % Inter 8x8 (Rect) 0,83 % 0,30 % Skip 64x64 0,00 % 0,00 % Skip 32x32 0,81 % 0,24 % Skip 16x16 3,73 % 1,04 % Skip 8x8 4,27 % 1,91 % Merge 64x64 0,27 % 1,63 % Merge 32x32 2,49 % 0,82 % Merge 16x16 4,86 % 1,67 % Merge 8x8 4,47 % 2,27 %
__________________
And if the band you're in starts playing different tunes I'll see you on the dark side of the Moon... |
|
![]() |
![]() |
![]() |
#7640 | Link |
Registered User
Join Date: Apr 2018
Posts: 61
|
the comparatively enormous number of 64x64 blocks with rskip 2 to me, though-- from a total of 6.79% (normal + rect) to 65.33% (normal + rect)!
Is there any way to get CU-type in a more readable format than setting csv-log-level=1 and viewing the generated file in an Excel/CSV viewer? Would greatly help with some comparison's I've been doing for myself. |
![]() |
![]() |
![]() |
Thread Tools | Search this Thread |
Display Modes | |
|
|