• AnyStream is having some DRM issues currently, Netflix is not available in HD for the time being.
    Situations like this will always happen with AnyStream: streaming providers are continuously improving their countermeasures while we try to catch up, it's an ongoing cat-and-mouse game. Please be patient and don't flood our support or forum with requests, we are working on it 24/7 to get it resolved. Thank you.

Best GUI encoder for UHD Blu-rays

I'm trying to figure out why this shows this. If my findings are correct 1.7 is transferring the WRONG color RGB in its self automatic add in values.

Original metadata from test file image. You will see the RGB does NOT match my test file. The min max luma light level appears to be ok with the decimal point missing out of the L(40000000,50)

This was copied from the master display in 1.7 notice the mismatch RGB


G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(40000000,50)

2018.01.29-15.20.png
 
lol theres no missmatch here.. this is how the master display command line is written

G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(40000000,50) = 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
 
What math are they using to convert the RGB then? Those numbers DO NOT match my hdr meta data on the disk
 
i dont know what math they are using , but the cmd-line is correct... if you dont use one of these command line, the metadata will be reported as ''unknown properties'' by madvr

there are 2 cmd-line
G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450) = DCI-P3
G(8500,39850)B(6550,2300)R(35400,14600)WP(15635,16450) = BT2020


 
Last edited:
So now I have to find out how straxrip converts the master display info values. The min man luma light is straight forward but the other vales are not. Got to be like the same thing when converting decimal to registry values the number changes for each value when using visual basic programming to write values to a file. I had this problem with kodi hdr project had to address it as the sotred values for color saturation and contrast ect was not the values being sent out of the variables to the windows registry. Things can never be simple in the life.
 
I asked on doom9 (StaxRip support thread) how to get that on 10bit.
 
http://x265.readthedocs.io/en/latest/cli.html#cmdoption-master-display

--master-display <string>

SMPTE ST 2086 mastering display color volume SEI info, specified as a string which is parsed when the stream header SEI are emitted. The string format is “G(%hu,%hu)B(%hu,%hu)R(%hu,%hu)WP(%hu,%hu)L(%u,%u)” where %hu are unsigned 16bit integers and %u are unsigned 32bit integers. The SEI includes X,Y display primaries for RGB channels and white point (WP) in units of 0.00002 and max,min luminance (L) values in units of 0.0001 candela per meter square. Applicable for HDR content.

Example for a P3D65 1000-nits monitor, where G(x=0.265, y=0.690), B(x=0.150, y=0.060), R(x=0.680, y=0.320), WP(x=0.3127, y=0.3290), L(max=1000, min=0.0001):

G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,1)
Note that this string value will need to be escaped or quoted to protect against shell expansion on many platforms. No default.


any more doubt gereral lol ???
 
ok your right the meta data in master display is off. I removed the posts. Guess the set display data is correct with the adjusted luma max light level is the only thing you change. Sorry for rubbing you the wrong way imhh1
 
Example for a P3D65 1000-nits monitor, where G(x=0.265, y=0.690), B(x=0.150, y=0.060), R(x=0.680, y=0.320), WP(x=0.3127, y=0.3290), L(max=1000, min=0.0001):

G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,1)
Note that this string value will need to be escaped or quoted to protect against shell expansion on many platforms. No default.

Interesting that if you take G13250 divide it by x=.265 you get 50,000 and the RBG values all use this formula
G(x=0.265, y=0.690) G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,1)
34500 divided 0.690 = 50,000
Not that it means anything
 
Answer from sneaker_ger at at doom9.


AVS Filters -> Edit Code

But I see now it converts to 8 bit by default.
Edit from:
Code:
FFVideoSource("%source_file%", colorspace = "YUV420P8", \
cachefile = "%source_temp_file%.ffindex")
to;
Code:
FFVideoSource("%source_file%", cachefile = "%source_temp_file%.ffindex")
and try again.

Note that this may break certain filters.


https://forum.doom9.org/showthread.php?t=172068&page=142
 
yep changing the code worked for me too Thankyou 1.7 now does 10bit pipeline. Ill rar up my version and offer a link so no one has to figure how to change the script code. it will be stored. Thankyou

2018.01.29-17.41_02.png
 
have to reupload......give me a sec

This is IMHH1 file fixed with the new script code. This now passes 10bit pipeline in thru and out the program and encoder.
 
Last edited:
awesome, this is not how i fixed my Staxrip 1.7 but i'm glad it now works for both of you
 
Answer from sneaker_ger at at doom9.


AVS Filters -> Edit Code

But I see now it converts to 8 bit by default.
Edit from:
Code:
FFVideoSource("%source_file%", colorspace = "YUV420P8", \
cachefile = "%source_temp_file%.ffindex")
to;
Code:
FFVideoSource("%source_file%", cachefile = "%source_temp_file%.ffindex")
and try again.

Note that this may break certain filters.


https://forum.doom9.org/showthread.php?t=172068&page=142

I'm sure we only need the UHD one LOL
 
ALERT when you reload the fixed script it returns to the unedited one so Ill have to get the source files and find the script and change the code. The change only lasts tell you shut down 1.7 straxrip and defautls to the original script. Sorry guys Looks like its written in C++
 
Back
Top