Posts by morphinapg

    Ah, crap. I just realized the format I was piping over the command line was actually 8bpc. I originally thought RGB32 meant 32bpc. Well, that's not going to work. I definitely notice banding so the output, while 10bit, isn't actually true 10bit. When 2.0.7 comes, I'm assuming this will this be delivering proper 10bit per channel from the source, not from RGB32 like the pipe?

    Btw, after much testing, I just figured out a solution using 1.2.1 and the piping out functionality (I couldn't find that feature in R2)

    First, the program that I'm piping to is a build of ffmpeg that supports 10bit x265. I used Zeranoe Windows x64, but if it supports 10bit x265 it should work.

    The piping command I used for my project (MaxCLL 1075 and MaxFALL 226) was this:

    1. -i - -pix_fmt yuv420p10 -c:v libx265 -x265-params crf=18:colorprim=bt2020:colormatrix=bt2020c:transfer=smpte2084:chromaloc=2:hdr-opt=1:master-display="G(8500,39850)B(6550,2300)R(35400,14600)WP(15635,16450)L(10000000,0)":max-cll="1075,226" D:\Movie.mp4

    You would obviously need to tweak your MaxCLL/MaxFALL and preferably your mastering display values, as well as the output location. This produces only video, but it could probably be tweaked to include audio as well. I found the output location had trouble with longer directory+file names (Such as D:\Users\Andy\Desktop\Movie.mp4) so I decided to stick it on the root of my drive since I wouldn't know where it would go if I just said Movie.mp4.

    For now this will be my solution until you can release an update with built in functionality. Maybe this sample command line will also help you.

    I can only help with x265. (Not sure if the other codecs even support HDR right now) These are the settings that need to be applied with every HDR encode:

    --colorprim bt2020

    --colormatrix bt2020nc (It may also be a good idea to allow bt2020c)

    --transfer smpte2084

    --output-depth 10

    --chromaloc 2


    the user may optionally also want --uhd-bd which enforces compliance with the UltraHD Blu-ray spec.

    they will also need the metadata. These will need to be inputted manually by the user, although you may use these as defaults

    First, the user will need to define their monitor's capabilities. You have RGB chromaticity points, and max/min luminance. The following is for a monitor with rec2020 chromaticity points, 1000 nit maximum luminance, and 0 nit minimum luminance. Notice the chromaticity points are multiplied by 50000 and the luminance numbers are multiplied by 10000:

    --master-display "G(8500,39850)B(6550,2300)R(35400,14600)WP(15635,16450)L(10000000,0)"

    Next, the user will need to define the MaxCLL and MaxFALL metadata. MaxCLL refers to the brightest pixel in the entire content, and MaxFALL refers to the frame with the brightest average light level. These are described in integer nits. Here is an example with the common 1000 nit MaxCLL, and 400 nit MaxFALL:

    --max-cll "1000,400"

    (for a "correct" encode, these values should be different for each sequence)


    The tricky thing here is there are essentially two different ways to approach HDR in premiere. The way I'm doing it, you can edit the raw PQ-formatted HDR video in the default rec709 space. Premiere thinks you're working with rec709 video and it will look all washed out and flat on a rec709 monitor, but when displayed on an HDR monitor, it looks correct. This would be fully compatible with the above options without changing anything else.


    The other way, however, is that premiere actually has some (limited) native HDR functionality. If you pull in an HDR video and Premiere recognizes it as HDR video, it will display colors correctly, but it will clip the video at the 100nit level. Which means you can't display it correctly on an HDR monitor, and more than likely it will look blown out on an SDR monitor. As far as I know, currently the only way to view this in HDR is to export it back out using Premiere's built-in HEVC codec, with the HDR option enabled. What I assume this does, is before applying similar options to those listed above (without the metadata part), it takes the video information as linear floating point values with 1.000 representing 100 nits and 100.000 representing 10,000 nits, and then applies a transform to the ST2084 PQ space (sort of HDR's gamma), before encoding as HDR video.

    If you can obtain this raw HDR linear floating point data, then an equation to translate this to ST2084 compatible values between 0 and 1 would be:

    y = ((1.10147*x^0.1593+0.101713)/(x^0.1593+0.111442))^78.8438 / 1023

    y represents the final output in a floating point value between 0 and 1. If you skip the /1023 at the end, you can also get values between 0 and 1023, which may be useful for 10bit encoding.

    x represents a floating point value where 1.000 is 100 nits and 100.000 is 10,000 nits. If x is 0, make sure to manually translate that to y=0, as that won't work with the equation.

    I would also check to see if premiere has any option to natively do that conversion from native HDR to ST2084 for you, similar to that checkbox in the built in HEVC encoder.

    This second method is messy, but it's more in line with how premiere does HDR natively. I don't personally recommend people to use Premiere's native HDR workflow right now as it's severely limited, but if they so happened to use that method, it would be nice to have a way to export that as well. Not really sure how you would be able to explain that in voukoder however. Perhaps a checkbox, selected by default that says something like "preformatted for HDR/ST2084". The box being checked would skip the ST2084 transformation formula from above.

    If you have to pick one, go with the first option for now until premiere gets better at its HDR workflow.

    I hope you can get this done, because I just exported a project using x265vfw with these options, through Premiere's AVI output, and it's clear premiere is clamping to 8bit before encoding in that mode, even though x265 is encoding in 10bit. This is causing banding issues in my HDR colors. While I can export 10bit HEVC through voukoder, I don't know how to inject the correct metadata into the stream after it's been encoded, plus the encoding won't be as "correct" or efficient if it doesn't know those things about the luma/color format during the process either. Is there currently a way to type commands manually into Voukoder R2? Because even if something isn't implemented in the UI, being able to type it manually would at least provide the option.

    I'm also fairly new to doing this so I only know x265 for now. I did finally get it working through x265vfw after originally having some errors in premiere. I used direct HEVC track output instead of MP4 in the x265 settings. I don't embed it in the AVI because I eventually intent to remux with my audio to MP4/MKV/M2TS depending on what I'm doing with it.

    I don't know if all of these are necessary or not, but these are the final settings I used to encode an HDR compatible file (verified working in both HDR youtube and native on my TV):

    --max-cll "4000,250" --master-display "G(8500,39850)B(6550,2300)R(35400,14600)WP(15635,16450)L(40000000,0)" --colorprim bt2020 --colormatrix bt2020nc --transfer smpte2084 --output-depth 10 --uhd-bd

    These are x265 cli arguments, so I don't know how libx265 might differ

    I had to change the --master-display RGB values to match BT2020. In the earlier post I had DCI-P3 values, which youtube didn't like when I uploaded it.

    the --max-cll values and at least the final parameter in the --master-display value will vary depending on the content, so ideally the user should be able to enter these such as:

    MaxCLL: 4000

    MaxFALL: 250

    Mastering Display Maximum Nits: 4000
    Mastering Display Minimum Nits: 0

    You could also use the common values if users don't enter them. I often see people use MaxCLL 1000 MaxFALL 400, with the mastering display as 1000/0.005, although ideally people would want to enter these correctly to ensure the image tonemaps properly on different displays.


    These are also assuming you have the source in its flat ST2084 source, which is what I've been using (it looks like viewing something at the wrong gamma, low contrast, etc). Premiere likely outputs this in the same range of values it does for standard rec709 content, just in a higher bit depth precision.

    Premiere also has a native HDR implementation, and I don't know how that data is sent to the exporter though. If standard data is exported as 0.0-1.0 floating point, I would imagine the native HDR implementation would expand into the above 1.0 space, up to 100.0 for 10,000 nits. If that's the case, I believe you would need to make sure to map these to the correct range of input values based on the ST2084 transfer function before applying the above settings.

    I don't know for sure whether premiere would be able to signal to you whether the native HDR functionality is being used at all or not. It's possible premiere may not even be able to know for sure, since even regular color grading could unintentionally extend into that HDR range. So you may need to include an option asking whether the input is raw preformatted ST2084 values, or whether they need to be reformatted first.

    Sorry if this is all really confusing. I know HDR is a very different beast from regular encoding.

    I just came across this plugin looking for ways to export HDR video from premiere. I'd like to add that HDR is more than just color space. In x265 I would need to include these commands to specify metadata values, which also triggers the correct HDR output settings as well:

    --max-cll "4000,250" --master-display "G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(40000000,0)"

    That represents content that has a MaxCLL of 4000 nits, and a MaxFALL of 250, with a mastering display defined at 4000 nits.

    I was trying to use x265vfw to output this but I get error compiling movie with that one, which is why I went googling and found this plugin. It would be nice to be able to simply include command line options like that for any features the encoder doesn't currently support, the way the x264vfw and x265vfw encoders do (I bypass the avi output and output directly to mp4 with those)

    Note that premiere does have native HDR editing which allows values greater than 100 nits in the editor, but it's also possible to work on an unprocessed 10bit HDR capture (I have an external HDR monitor which can handle that data so this is useful to me), so it would be nice to be able to export either way. The above x265 command would assume the raw 10bit source (which looks like a washed out image with wrong gamma when displayed on a non-HDR monitor). I couldn't say how natively edited HDR content gets sent to the exporter, so I don't know if there would be something different about how you'd set that up either.