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 14th December 2017, 05:14   #5781  |  Link
WhatZit
Registered User
 
Join Date: Aug 2016
Posts: 60
Quote:
Originally Posted by Stephen R. Savage View Post
I am afraid that you must be either blind or misinformed. With 2.6 and even the latest hg version, it is still impossible to disable SAO
SAO?! You think I was talking about SAO?

"Misinformed"... hahah, pot meet kettle.

Quote:
Originally Posted by Stephen R. Savage View Post
In fact, since they changed the lambda tables a few versions ago, it has regressed further.
Sure, I had to extensively test & retune for the new tables, but it wasn't hard, just very time consuming (involving hundreds of frame comparisons).

After that, it was back to transparent x265 encoding at bitrates that would leave x264 exploding into lego blocks.

So, if you love x264 so much, then keep using it! But don't come here poking your neanderthal spear at those who've evolved beyond it.
WhatZit is offline   Reply With Quote
Old 14th December 2017, 08:14   #5782  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,007
Still no shared samples to compare objectively?
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 14th December 2017, 10:15   #5783  |  Link
jd17
Registered User
 
Join Date: Jun 2017
Posts: 89
Quote:
Originally Posted by WhatZit View Post
I recently spent two weeks explaining to everyone how one single option utterly neutralises this default behavior. You must have missed it.
I must have missed that too.
Would you be so kind as to enlighten me?

I am not unhappy with the performance of x265, a combination of 10bit, CRF17, no-sao and preset slow looks transparent to me.

However, I am very interested in the option you are talking about and I would like to do some comparisons myself, so please share!


Edit:
I searched for even older posts from you than I did before and stumbled over this:
https://forum.doom9.org/showthread.p...61#post1800261

Is that what you are talking about? Using --tune grain?

If that is the case, I agree that --tune grain can work wonders, I used to encode with that option too.
However, while I am convinced of the --tune grain results when using --preset medium, I found that --tune grain added to --preset slow (or slower presets than slow) does too much.
This may sound weird, but it looked to me as if it then introduces noise/grain where there is none in the source.
I assume that the high --psy-rdoq (10) might be the root cause for what I consider artificial noise/grain.

Last edited by jd17; 14th December 2017 at 10:46.
jd17 is offline   Reply With Quote
Old 14th December 2017, 12:07   #5784  |  Link
WhatZit
Registered User
 
Join Date: Aug 2016
Posts: 60
Quote:
Originally Posted by jd17 View Post
I found that --tune grain added to --preset slow (or slower presets than slow) does too much.
This may sound weird, but it looked to me as if it then introduces noise/grain where there is none in the source.
You're not imagining any of it, JD.

The slower the preset, the more "overboard" the detail retention gets (ridiculously so at veryslow). Also, the new lambda tables seem to have made the phantom grain effect more pronounced.

That's why you always need to think in opposites with --tune grain: go faster with lower bitrates, and let the special algorithms for stable quantization & high-frequency bias do the work of traditional slower presets and higher bitrates.


Quote:
Originally Posted by LigH View Post
Still no shared samples to compare objectively?
Having to use 3rd party sites to host these dissuades a lot of people, I reckon. Including myself, who's already wasted too much time on frame-grab comparisons that are now auto-deleted.

Now, if doom9 had it's own flick-tool feature...
WhatZit is offline   Reply With Quote
Old 14th December 2017, 13:04   #5785  |  Link
jd17
Registered User
 
Join Date: Jun 2017
Posts: 89
Quote:
Originally Posted by WhatZit View Post
You're not imagining any of it, JD.

The slower the preset, the more "overboard" the detail retention gets (ridiculously so at veryslow). Also, the new lambda tables seem to have made the phantom grain effect more pronounced.

That's why you always need to think in opposites with --tune grain: go faster with lower bitrates, and let the special algorithms for stable quantization & high-frequency bias do the work of traditional slower presets and higher bitrates.
That is interesting, I'm glad that you share my assessment.

After my trials, I pretty much concluded that I get very comparable results by either going medium/grain or slow/no-sao, both with CRF17.
While the medium/grain version is quicker to encode, the resulting bitrate is considerably higher.
This is why I use the before mentioned slow/no-sao now.


I have not seen the negative effects of --no-sao Stephen R. Savage refers to. Not even at close inspection during my trials.

Accordingly, I too would like to see a sample demonstrating the phenomenon.
jd17 is offline   Reply With Quote
Old 14th December 2017, 14:42   #5786  |  Link
Barough
Registered User
 
Barough's Avatar
 
Join Date: Feb 2007
Location: Sweden
Posts: 343
x265 v2.6+14-f09f3b4a2115 (GCC 7.2.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 14th December 2017, 16:06   #5787  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,007
x265 2.6+14-f09f3b4a2115

New options:

Code:
   --fullhelp                    Show all options and exit
   --gop-lookahead <integer>     Extends gop boundary if a scenecut is found within this from keyint boundary. Default 0
_

I wonder ... how much GOP lookahead would you consider sensible, in relation to min and max keyframe intervals.
__________________

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

Last edited by LigH; 14th December 2017 at 16:38.
LigH is offline   Reply With Quote
Old 14th December 2017, 22:34   #5788  |  Link
divxmaster
Registered User
 
Join Date: Mar 2015
Location: New Zealand
Posts: 45
Quote:
Originally Posted by burfadel View Post
I don't see how you could be having so many issues with it. Have you eliminated other possibilities like the video decoder? In any case, if you don't like it don't use it! Constructive criticism with examples would help. Upload a small troublesome clip, take a screenshot of frames with issues, and then they could maybe recreate the issue and work on it. B!tch!ng helps no one.
Thanks Burfadel, I was about to post exactly that, but you beat me to it!

And just to confirm, I have calculated (roughly) 10GB/hr is a bit rate of 22.755mbps.... bad output of x265 1080p at 22.755mbps??? I dont think so.

Last edited by divxmaster; 14th December 2017 at 22:50.
divxmaster is offline   Reply With Quote
Old 15th December 2017, 12:10   #5789  |  Link
Weyoun
Registered User
 
Join Date: Jul 2017
Posts: 11
Quote:
Originally Posted by Stephen R. Savage View Post
I could not care less about your "end users." x265 does not deliver good quality for me.
I am so glad x265 was not created for you.
Weyoun is offline   Reply With Quote
Old 16th December 2017, 10:38   #5790  |  Link
birdie
.
 
birdie's Avatar
 
Join Date: Dec 2006
Posts: 152
Quote:
Originally Posted by Stephen R. Savage View Post
Sorry, but if the quality is bad at 10 GB/hr, it can't be better at 1 GB/hr.
This topic was created to discuss x265 development.

If you have issues with the codec, please create a new thread and post your sources and encoding settings, so that we could all decide whether what you're trying to convey is true or not, and if there's something we or you have overlooked.

As mentioned earlier, 10GB/hr translates to 10*1024*1024*1024*8/3600/1024/1024 = 22.755Mb/sec which will be 100% transparent (unless you want a lossless compression) using x264.
birdie is offline   Reply With Quote
Old 16th December 2017, 20:21   #5791  |  Link
divxmaster
Registered User
 
Join Date: Mar 2015
Location: New Zealand
Posts: 45
Quote:
Originally Posted by birdie View Post

As mentioned earlier, 10GB/hr translates to 10*1024*1024*1024*8/3600/1024/1024 = 22.755Mb/sec which will be 100% transparent (unless you want a lossless compression) using x264.
Haha, I think you meant "100% transparent (unless you want a lossless compression) using x265" ??
divxmaster is offline   Reply With Quote
Old 17th December 2017, 14:53   #5792  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Hollola, Finland
Posts: 4,672
Out of interest, there was earlier some discussion that --qcomp 0.8 would be better than the default 0.6. Has anyone made any recent tests, especially with --tune grain?
__________________
And if the band you're in starts playing different tunes
I'll see you on the dark side of the Moon...
Boulder is offline   Reply With Quote
Old 17th December 2017, 21:10   #5793  |  Link
birdie
.
 
birdie's Avatar
 
Join Date: Dec 2006
Posts: 152
Quote:
Originally Posted by divxmaster View Post
Haha, I think you meant "100% transparent (unless you want a lossless compression) using x265" ??
I did mean x264.
birdie is offline   Reply With Quote
Old 18th December 2017, 02:33   #5794  |  Link
divxmaster
Registered User
 
Join Date: Mar 2015
Location: New Zealand
Posts: 45
Quote:
Originally Posted by birdie View Post
I did mean x264.
Oh Ok,
Well 22.755Mbps will be transparent in x264 or x265. Thats a higher bitrate than some bluray masters.

Cheers,
Divxmaster
divxmaster is offline   Reply With Quote
Old 18th December 2017, 15:11   #5795  |  Link
Barough
Registered User
 
Barough's Avatar
 
Join Date: Feb 2007
Location: Sweden
Posts: 343
x265 v2.6+15-57eaef9abfd8 (GCC 7.2.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 18th December 2017, 17:43   #5796  |  Link
Majorlag
Registered User
 
Join Date: Jul 2016
Posts: 10
Quote:
Originally Posted by Boulder View Post
Out of interest, there was earlier some discussion that --qcomp 0.8 would be better than the default 0.6. Has anyone made any recent tests, especially with --tune grain?
I found --qcomp 0.8 to work perfectly for my needs, but I use --rc-grain since I don't want to change my --qpstep to 1. I use the higher qcomp since x264 days. I lean towards less fluctuation in quantizer compression so I change a few of the settings to reflect that, such as"--qpmin 4 --qpmax 44 --qpstep 4 --qcomp 0.8 --rc-lookahead 30 --rc-grain"
Majorlag is offline   Reply With Quote
Old 19th December 2017, 00:19   #5797  |  Link
Motenai Yoda
Registered User
 
Motenai Yoda's Avatar
 
Join Date: Jan 2010
Posts: 706
I found a discrepancy between documentation and source about qg-size, docs sayz [maxCUSize], source 32, maybe it's related to f0b9b9e?
also dc5d584 set it to 32 for "commandlines with medium and all slower presets", but as fast and faster doesn't change it againg, actually it's 32 for all presets
__________________
powered by Google Translator

Last edited by Motenai Yoda; 19th December 2017 at 00:26.
Motenai Yoda is offline   Reply With Quote
Old 21st December 2017, 16:25   #5798  |  Link
Barough
Registered User
 
Barough's Avatar
 
Join Date: Feb 2007
Location: Sweden
Posts: 343
x265 v2.6+17-7a6d244c922b (GCC 7.2.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 25th December 2017, 02:18   #5799  |  Link
pingfr
Registered User
 
Join Date: May 2015
Posts: 185
Merry Christmas to all!
pingfr is offline   Reply With Quote
Old 25th December 2017, 19:21   #5800  |  Link
dipje
Registered User
 
Join Date: Oct 2014
Posts: 270
This might have been posted, but if I wanted to re-encode some youtube-HDR files to make them compatible with my set, how do I translate the HDR metadata?
ffprobe gives this:
Code:
      Content Light Level Metadata, MaxCLL=2000, MaxFALL=300
      Mastering Display Metadata, has_primaries:1 has_luminance:1 r(0.6800,0.3200) g(0.2649,0.6900) b(0.1500 0.0600) wp(0.3127, 0.3290) min_luminance=0.009900,max_luminance=2000.000000
and this:
Code:
Stream #0:0(eng): Video: vp9 (Profile 2), yuv420p10le(tv, bt709/bt2020/smpte2084), 3840x2160, SAR 1:1 DAR 16:9, 60 fps, 60 tbr, 1k tbn, 1k tbc (default)
am I correct that x265 needs:
Code:
--master-display "G(2649,6900)B(1500,0600)R(6800,3200)WP(3127,3290)L(99,20000000)" --max-cll 2000,300 --range limited --colorprim bt2020 --colormatrix bt709 --transfer smpte2084
Specially the order for --max-cll which is listed as cll,fall in the help text, and the master-display string where I did every ffprobe value * 10000, is that correct?
dipje 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 19:02.


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