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 10th February 2018, 17:15   #5901  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 3,294
Quote:
Originally Posted by Dope View Post
I haven't seen x265 to compress more efficiently in 10-bit. x264 - yes. But not x265.
Those are my findings too
poisondeathray is offline   Reply With Quote
Old 10th February 2018, 17:33   #5902  |  Link
Anthonytex
Registered User
 
Join Date: Nov 2015
Posts: 4
Thank you
Anthonytex is online now   Reply With Quote
Old 10th February 2018, 18:28   #5903  |  Link
Selur
Registered User
 
Selur's Avatar
 
Join Date: Oct 2001
Location: Germany
Posts: 5,492
Still 10bit makes sense to avoid introducing banding artifacts,..
__________________
Hybrid here in the forum, homepage
Selur is offline   Reply With Quote
Old 11th February 2018, 14:44   #5904  |  Link
Asmodian
Registered User
 
Join Date: Feb 2002
Location: San Jose, California
Posts: 2,992
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
Asmodian is online now   Reply With Quote
Old 11th February 2018, 15:10   #5905  |  Link
sneaker_ger
Registered User
 
Join Date: Dec 2002
Posts: 4,945
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
sneaker_ger is offline   Reply With Quote
Old 11th February 2018, 17:34   #5906  |  Link
Ma
Registered User
 
Join Date: Feb 2015
Posts: 285
The problem with qg-size could be related to 8bit vs. 10bit question.
I've made tests with 10bit output and I prefer qg-size 64 (for 10bit output).
Maybe the change from 64 to 32 for qg-size was for 8bit output?
Ma is offline   Reply With Quote
Old 11th February 2018, 19:00   #5907  |  Link
IgorC
Registered User
 
Join Date: Apr 2004
Posts: 1,269
Quote:
Originally Posted by sneaker_ger View Post
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
Filmgrain preservation is overrated

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
IgorC is offline   Reply With Quote
Old 12th February 2018, 16:30   #5908  |  Link
Sp00kyFox
Registered User
 
Sp00kyFox's Avatar
 
Join Date: Aug 2007
Posts: 77
Quote:
Originally Posted by Motenai Yoda View Post
I would suggest a possible tune animation:
Code:
aq-mode 3 aq-strength 0.6 aq-motion qg-size 16 rc-lookahead +20 psy-rd 1.2 rdoq-level 2 psy-rdoq 0.3 deblock 1:-1 cbqpoffs -1 crqpoffs -1
can somebody actually provide an encoding example where aq-mode 3 is beneficial? made some tests a while ago and really can't say that it's better or worse than mode 1. both seem better than mode 2 though.

Quote:
Originally Posted by Anthonytex View Post
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
10bit-depth prevents banding artifacts better and since HEVC hardware decoders also support it unlike with AVC I don't see a reason not to use it.

Quote:
Originally Posted by IgorC View Post
Instead of blaming x265 developers for not preserving grain itís time to forget about useless filmgrain to begin with
it's the classic problem of video filtering to distinguish between grain and details. so a video encoder that fails to keep this picture information also has issues with keeping details. despite that grain can also create details over the temporal axis.

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.
Sp00kyFox is offline   Reply With Quote
Old 13th February 2018, 23:18   #5909  |  Link
IgorC
Registered User
 
Join Date: Apr 2004
Posts: 1,269
Quote:
Originally Posted by Sp00kyFox View Post
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.
Great.Thank you for clarifying that as I didn't followed x265 devt last year.
IgorC is offline   Reply With Quote
Old 14th February 2018, 10:57   #5910  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 5,246
x265 2.6+39-01b685d6fa33

CMake: fix generation of version info from .hg_archival.txt; fix output to pipe on Windows (enable binary mode)
__________________

German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 18th February 2018, 18:24   #5911  |  Link
Barough
Registered User
 
Barough's Avatar
 
Join Date: Feb 2007
Location: Sweden
Posts: 275
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
Barough is offline   Reply With Quote
Old 20th February 2018, 22:09   #5912  |  Link
VoodooFX
Registered User
 
Join Date: Sep 2008
Posts: 12
Quote:
Originally Posted by sneaker_ger View Post
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
Definitely I had same problem with aq-mode=2 (and maybe with 3 too, I don't remember now), using default aq-mode=1 solved exact banding like in those screenshots.
VoodooFX is offline   Reply With Quote
Old 22nd February 2018, 13:15   #5913  |  Link
hajj_3
Registered User
 
Join Date: Mar 2004
Posts: 810
x265 v2.7 is out, can't find a changelog though.
hajj_3 is offline   Reply With Quote
Old 22nd February 2018, 13:27   #5914  |  Link
Barough
Registered User
 
Barough's Avatar
 
Join Date: Feb 2007
Location: Sweden
Posts: 275
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.
Barough is offline   Reply With Quote
Old 22nd February 2018, 13:47   #5915  |  Link
Barough
Registered User
 
Barough's Avatar
 
Join Date: Feb 2007
Location: Sweden
Posts: 275
x265 v2.7+1-2aa737a99f51 (GCC 7.3.0, 32 & 64-bit 8/10/12bit Multilib Windows Binaries)

Code:
https://bitbucket.org/multicoreware/x265/commits/all
Barough is offline   Reply With Quote
Old 22nd February 2018, 21:30   #5916  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 5,246
Is there possibly a merge missing with the default branch?! I get only v2.6+49 there. apparently I need to get the stable branch or the tip, because the merge happened before the milestone...

There used to be reasons why I prefer the default branch.
__________________

German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 22nd February 2018, 22:33   #5917  |  Link
Midzuki
Unavailable
 
Midzuki's Avatar
 
Join Date: Mar 2009
Location: offline
Posts: 1,450
Quote:
Originally Posted by LigH View Post
Is there possibly a merge missing with the default branch?! I get only v2.6+49 there. apparently I need to get the stable branch or the tip, because the merge happened before the milestone...

hg clone -r 2aa737a99f51 https://bitbucket.org/multicoreware/x265
Midzuki is offline   Reply With Quote
Old 22nd February 2018, 22:43   #5918  |  Link
Barough
Registered User
 
Barough's Avatar
 
Join Date: Feb 2007
Location: Sweden
Posts: 275
Quote:
Originally Posted by LigH View Post
Is there possibly a merge missing with the default branch?! I get only v2.6+49 there. apparently I need to get the stable branch or the tip, because the merge happened before the milestone...

There used to be reasons why I prefer the default branch.
I used MABS as usual and it output v2.7. Haven't made any adjustments/tweaks to it. (My knowledge in that area is close to zero.)

Sent from my SM-G935F via Tapatalk
Barough is offline   Reply With Quote
Old 22nd February 2018, 22:45   #5919  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 5,246
In this case, the main issue was knowing that the tip was in stable, not in default. Which ever branch or state you select, there is always a possible case where it would miss one or more commits. I may always have to study the current network of branches, commits, and merges, to decide which revision to update to.

MABS may always use tip; this can be wrong when the most current commit belongs to the rarely updated stable branch, and there was no merge with the often updated default branch yet. Therefore, my additional x265 building scripts prefer the default branch, usually, but it takes only one additional parameter to update to a custom target.
__________________

German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid

Last edited by LigH; 22nd February 2018 at 22:48.
LigH is offline   Reply With Quote
Old 24th February 2018, 20:07   #5920  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 5,246
New upload: x265 2.7+1-2aa737a99f51

limitTU: Save intra CU's TU depth when analysis save/load is enabled; dHDR10 parsing fixes; ipfilter kernels split into several separate source files; v2.7 milestone
__________________

German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid

Last edited by LigH; 24th February 2018 at 20:11.
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 20:40.


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