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 5th April 2020, 23:28   #7501  |  Link
_kermit
Registered User
 
Join Date: Apr 2017
Posts: 63
Quote:
Originally Posted by jlpsvk View Post
yes... it is bad... you need to enter correct values to to source... read the x265 documentation...

--master-display "G(8500,39850)B(6550,2300)R(35400,14600)WP(15635,16450)L(10000000,1)" are correct values for your source
are those values depending on source?
I noticed with other files they are all correct.
It seems that this one was different. Is this common?
_kermit is offline   Reply With Quote
Old 6th April 2020, 02:32   #7502  |  Link
MeteorRain
結城有紀
 
Join Date: Dec 2003
Location: NJ; OR; Shanghai
Posts: 894
Quote:
Originally Posted by filler56789 View Post
Just wondering how and why they (MCW) approve the commits without testing the commits...
I'm guessing because they are still using CVS style committing and branching. If they start using Git style branching bad things would be easier to catch after they commit but before they merge.
__________________
Projects
x265 - Yuuki-Asuna-mod Download / GitHub
TS - ADTS AAC Splitter | LATM AAC Splitter | BS4K-ASS
Neo AviSynth+ filters - F3KDB | FFT3D | DFTTest | MiniDeen | Temporal Median
MeteorRain is offline   Reply With Quote
Old 6th April 2020, 06:01   #7503  |  Link
Patman
Registered User
 
Patman's Avatar
 
Join Date: Jan 2015
Posts: 286
Quote:
Originally Posted by MeteorRain View Post
I'm guessing because they are still using CVS style committing and branching. If they start using Git style branching bad things would be easier to catch after they commit but before they merge.
I used the x265_git and it happened too. Or is it a mirror in preparation for git usage?
__________________
Tools for StaxRip | x264 - x265
Patman is offline   Reply With Quote
Old 6th April 2020, 10:22   #7504  |  Link
foxyshadis
ангел смерти
 
foxyshadis's Avatar
 
Join Date: Nov 2004
Location: Lost
Posts: 9,558
Quote:
Originally Posted by filler56789 View Post
And the problem hasn't been fixed yet

Just wondering how and why they (MCW) approve the commits without testing the commits...
After Steve Borho left, essentially all code review went with him; they just commit every submission and clean up later now. Except assembly; chen still reviews that harshly.
foxyshadis is offline   Reply With Quote
Old 6th April 2020, 19:20   #7505  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,752
Quote:
Originally Posted by _kermit View Post
are those values depending on source?
I noticed with other files they are all correct.
It seems that this one was different. Is this common?
The values are specific to the professional grading monitor that was used to master the HDR. The premise is that the content will have no visible-by-creative-intent values outside of what the mastering monitor was capable of.

You need to use the values that are appropriate to the mastering monitor, which isn't something you can know from anything in the source other than this metadata. So, copy it if you have it. Otherwise leave it blank rather than specifying an incorrect value.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 6th April 2020, 20:02   #7506  |  Link
MeteorRain
結城有紀
 
Join Date: Dec 2003
Location: NJ; OR; Shanghai
Posts: 894
Quote:
Originally Posted by Patman View Post
I used the x265_git and it happened too. Or is it a mirror in preparation for git usage?
That's not what I mean. Note the word style.
__________________
Projects
x265 - Yuuki-Asuna-mod Download / GitHub
TS - ADTS AAC Splitter | LATM AAC Splitter | BS4K-ASS
Neo AviSynth+ filters - F3KDB | FFT3D | DFTTest | MiniDeen | Temporal Median
MeteorRain is offline   Reply With Quote
Old 6th April 2020, 21:10   #7507  |  Link
Patman
Registered User
 
Patman's Avatar
 
Join Date: Jan 2015
Posts: 286
Quote:
Originally Posted by MeteorRain View Post
That's not what I mean. Note the word style.
My fault. I only read your entry quickly when I was on the road and read it correctly again this evening You could be right about that.
__________________
Tools for StaxRip | x264 - x265
Patman is offline   Reply With Quote
Old 6th April 2020, 23:15   #7508  |  Link
_kermit
Registered User
 
Join Date: Apr 2017
Posts: 63
Quote:
Originally Posted by benwaggoner View Post
The values are specific to the professional grading monitor that was used to master the HDR. The premise is that the content will have no visible-by-creative-intent values outside of what the mastering monitor was capable of.

You need to use the values that are appropriate to the mastering monitor, which isn't something you can know from anything in the source other than this metadata. So, copy it if you have it. Otherwise leave it blank rather than specifying an incorrect value.
Not defining it in the command line would re-use what's in the source then?

to add: If so, is that also true for --max-cll ?

Last edited by _kermit; 6th April 2020 at 23:29.
_kermit is offline   Reply With Quote
Old 6th April 2020, 23:59   #7509  |  Link
Blue_MiSfit
Derek Prestegard IRL
 
Blue_MiSfit's Avatar
 
Join Date: Nov 2003
Location: Los Angeles
Posts: 5,988
Not defining it in the command line will simply not set it. x265 has no vision into the source metadata.

Also yes, this is true for --max-cll.
Blue_MiSfit is offline   Reply With Quote
Old 7th April 2020, 10:31   #7510  |  Link
dREV
Registered User
 
dREV's Avatar
 
Join Date: Jan 2019
Location: Antarctica
Posts: 74
I suppose it's as somebody wrote few posts ago about things breaking when grabbing the latest as I tried the latest build Barough shares x265 v3.3+17-gdf2ac512d https://forum.doom9.org/showthread.p...30#post1905930 appears both --profile main444-12 --input-csp i444 and --profile main444-10 --input-csp i444 are broken (if somebody else can also confirm) and may include 4:2:0 10 bit equivalent. 8 bit works fine.

Hope Barough will see this post.

----------------------------------------------

I don't know if it's related but as of far as I've tested x265 v3.3+2-gbe2d82093 has stopped working telling me Error message for your references: System exception - Access violation when Prefetch(1) is in the end of the script of AviSynth+ 3.5 but runs when (I think its disabled) Prefetch(0) is set. No issues with x265 v3.2+22-a8a2c4c37267.

I'm just writing this in case they may be related or not. I really do not know if Prefetch is even worth using since the AviSynth thread is of no help neither the documentation.

----------------------------------------------

Another question in regards to an interest in figuring out if a speed in my encoding with AviSynth+ is possible.

As I recall the settings for slow and veryslow were changed sometime ago and prior my encodes were a bit faster with my settings which have hardly changed since that implementation (likewise with my AviSynth filtering) but I dunno if choosing slower is the same as veryslow as I cannot tell just doing several encode tests at my end.

These are my current settings:
Quote:
--level 4.1 --crf 16.0 --aq-mode 3 --aq-strength 0.80 --deblock=-1:-1 --me sea --merange 57 --psy-rd 1.00 --rc-lookahead 40 --bframes 16 --ref 6 --subme 7 --qcomp=0.75 --fades --limit-refs=0 --no-limit-modes --rd 6 --psy-rdoq 5 --rdoq-level 1 --tu-intra-depth 4 --tu-inter-depth 4 --ipratio 1.4 --pbratio 1.3 --max-tu-size 32 --ctu 64 --qg-size 64 --limit-tu 0 --max-merge 5 --no-rect --colorprim bt709 --transfer bt709 --colormatrix bt709 --preset veryslow --sar 1:1 --input-depth 16 --profile main444-12 --input-csp i444 --tune animation --no-sao --no-amp --no-strong-intra-smoothing --dither
In 720p if that matters and yeah I am going overboard on some settings. I'm attempting to modify to shorten it some and just found out --ref 8 exists or I wasn't paying much attention to the documentation but doesn't seem to work at this resolution.

Wish the developers would give why the encoder stops to work on some settings instead of just stopping it with no explanation. Well, thanks if anybody gives any suggestions or critique.

Last edited by dREV; 7th April 2020 at 11:18. Reason: stuff
dREV is offline   Reply With Quote
Old 7th April 2020, 13:13   #7511  |  Link
_kermit
Registered User
 
Join Date: Apr 2017
Posts: 63
Quote:
Originally Posted by Blue_MiSfit View Post
Not defining it in the command line will simply not set it. x265 has no vision into the source metadata.

Also yes, this is true for --max-cll.
now I'm confused, sorry that I keep asking:
if used, the correct values must be provided
or
it doesn't matter and they should not be provided?

(for both)

Actually there is more to it:
If I don't provide in particular max-cll, that metadata is missing in the mkv and that data is for example used by the Radiance Pro.
So I think this should be in the new, at least, file since it was in the original?

Last edited by _kermit; 7th April 2020 at 13:16.
_kermit is offline   Reply With Quote
Old 7th April 2020, 13:42   #7512  |  Link
MythCreator
Registered User
 
Join Date: Dec 2007
Location: Beijing,China
Posts: 92
Quote:
Originally Posted by _kermit View Post
now I'm confused, sorry that I keep asking:
if used, the correct values must be provided
or
it doesn't matter and they should not be provided?

(for both)

Actually there is more to it:
If I don't provide in particular max-cll, that metadata is missing in the mkv and that data is for example used by the Radiance Pro.
So I think this should be in the new, at least, file since it was in the original?
It doesn't matter if you provided it or not, because the thing without those preferences is still playable, but if you want to enjoy the "correct" color and light, then you must provide them in command line.

and for the last question, to be honest, I don't know if I need those preferences, why export a new file or something else instead of set them in command line?
__________________
Ryzen 7 3700X
GTX1660S

Ryzen 7 5800X
RTX2060S
MythCreator is offline   Reply With Quote
Old 7th April 2020, 18:28   #7513  |  Link
_kermit
Registered User
 
Join Date: Apr 2017
Posts: 63
Quote:
Originally Posted by MythCreator View Post
It doesn't matter if you provided it or not, because the thing without those preferences is still playable, but if you want to enjoy the "correct" color and light, then you must provide them in command line.

and for the last question, to be honest, I don't know if I need those preferences, why export a new file or something else instead of set them in command line?
Ok, I stick with providing the parameters then.
If that information isn't there, the Radiance Pro is using default values
(AFAIK), so they are rather important and can not be provided otherwise.
And since I provide max-cll in the command line as parameters, that is fine.
The primaries seem only to have two variants so far:

R: x=0.708000 y=0.292000, G: x=0.170000 y=0.797000, B: x=0.131000 y=0.046000, White point: x=0.312700 y=0.329000

and

R: x=0.680000 y=0.320000, G: x=0.265000 y=0.690000, B: x=0.150000 y=0.060000, White point: x=0.312700 y=0.329000

thank you all!
_kermit is offline   Reply With Quote
Old 7th April 2020, 19:36   #7514  |  Link
onekmilesbehind
Registered User
 
Join Date: Mar 2019
Posts: 14
Quote:
Originally Posted by _kermit View Post
The primaries seem only to have two variants so far:

R: x=0.708000[...]
and
R: x=0.680000[...]
Took me too long to realize those correspond with BT.2020 (top) and DCI-P3 (bottom), both very common with HDR media.
onekmilesbehind is offline   Reply With Quote
Old 7th April 2020, 20:46   #7515  |  Link
_kermit
Registered User
 
Join Date: Apr 2017
Posts: 63
Quote:
Originally Posted by onekmilesbehind View Post
Took me too long to realize those correspond with BT.2020 (top) and DCI-P3 (bottom), both very common with HDR media.
ah, that's good to know

thanks.
_kermit is offline   Reply With Quote
Old 9th April 2020, 21:13   #7516  |  Link
Patman
Registered User
 
Patman's Avatar
 
Join Date: Jan 2015
Posts: 286
Quote:
Originally Posted by filler56789 View Post
And the problem hasn't been fixed yet

Just wondering how and why they (MCW) approve the commits without testing the commits...
They could fix the problem. Look here. I think there will be an official fix soon.
__________________
Tools for StaxRip | x264 - x265
Patman is offline   Reply With Quote
Old 10th April 2020, 21:29   #7517  |  Link
filler56789
SuperVirus
 
filler56789's Avatar
 
Join Date: Jun 2012
Location: Antarctic Japan
Posts: 1,351
Quote:
Originally Posted by Patman View Post
They could fix the problem. Look here. I think there will be an official fix soon.
Thanks!

https://bitbucket.org/multicoreware/...a725d4fa84a084
filler56789 is offline   Reply With Quote
Old 11th April 2020, 06:13   #7518  |  Link
tuanden0
Registered User
 
Join Date: Oct 2016
Posts: 111
Unable to finish encode after using x265 version 3.3+19 and 3.3+21 on http://msystem.waw.pl/x265/

So i have to turn back on version 3.3+10

I got stuck after they encode to last frame
tuanden0 is offline   Reply With Quote
Old 12th April 2020, 15:04   #7519  |  Link
filler56789
SuperVirus
 
filler56789's Avatar
 
Join Date: Jun 2012
Location: Antarctic Japan
Posts: 1,351
Quote:
Originally Posted by tuanden0 View Post
Unable to finish encode after using x265 version 3.3+19 and 3.3+21 on http://msystem.waw.pl/x265/

So i have to turn back on version 3.3+10

I got stuck after they encode to last frame
Thanks for the useful information,
I have just reported the latest-and-greatest problem to the x265 devils.
filler56789 is offline   Reply With Quote
Old 13th April 2020, 02:30   #7520  |  Link
MythCreator
Registered User
 
Join Date: Dec 2007
Location: Beijing,China
Posts: 92
My encoding work stuck on 3.3.19 & 3.3.21 too. It won't stuck on 3.3.10 with exact same settings, video and compiler. And it doesn't matter what compiler is, GCC or VS stuck on 3.3.19 and all goes well on 3.3.10. So the problem has to be in those commits between 3.3.19 and 3.3.10.

vspipe 2>NUL "RAW.vpy" - | C:\Encoder\x265_64_10bpp.exe --input-res 1280x720 --fps 29.970 --input-depth 16 --force-flush 0 --ctu 32 --no-strong-intra-smoothing --selective-sao 0 --no-sao --bframes 8 --weightb --no-open-gop --ref 6 --rc-lookahead 48 --aq-strength 1.0 --psy-rd 2.5 --rd 6 --aq-mode 1 --aq-motion --hme --hme-search "2,2,3" --hme-range "24,24,36" --me star --subme 6 --merange 64 --crf 18 --output “RAW.hevc" -

here's the command line that I'm using.
__________________
Ryzen 7 3700X
GTX1660S

Ryzen 7 5800X
RTX2060S
MythCreator 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 01:25.


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