Oh yeah you could probably include that on the same page as the video settings without making things too complicated.
You could probably include the filters within the video and audio tabs. I would probably recommend having them appear before the advanced codec settings if so. Are there a lot of filters that can be chained together, or just a few basic things? If it's fairly basic like resize/crop, I'd just put them in a panel on the same page with checkboxes to activate them, but if there's a lot of complexity with them, maybe linking to a separate window with a button might be a better option. If they're multi-path node like filters, then something like virtualdub used to do would be a good design, but if they're just layered on top of each other, then something like Avidemux does would be good.
I would group encoder options and presets together on the same page. Make sure the most basic settings are displayed first, such as bitrate/crf, and then the further down they go, the more advanced it gets. You could separate out the most advanced stuff into an additional tab if you want, but that may or may not be necessary as long as the more basic stuff is seen first. Perhaps hide the more advanced stuff away in a collapsable panel that is collapsed by default, and only opens if the user is interested in making those tweaks. Something like this
I would also probably have Voukoder remember whether they opened the advanced panel or left it closed.
Here are some screenshots from a slightly more modern rewrite I was working on before I abandoned the project. This is the window that would open only if the user wanted to modify settings. The "other" tab at this point only included subtitles. The source tab was for adjusting preprocessing and adding audio tracks. The advanced tab would include every possible x264 setting. In the older version I actually hid the advanced settings behind another window. There were also built in presets for different devices and quality settings if people didn't want to mess with any of these settings at all.
I think there were probably still some things I could have done to improve this design, but the basic idea was that things could be as simple or as advanced as the user needed, and this worked pretty well from the feedback I got at the time.
A long time ago I developed an app called ASXGui which was an x264 gui that could be as simple or as complex as the user needed it to be. You could simply drag, drop, and encode if you knew nothing about encoders. If you knew a little, there were some basic filters and codec options, and if you were a power user, there was the ability to tweak every little setting you might want to do. Maybe that app could give you some basic ideas you could build on. This was the last version I released, 10 years ago:
You might need to run as administrator for it to work.
Perfect. Just did a short test with a standard 10bit encode (no HDR, just encoded normally in 10bit), reimported it and applied a custom HDR-to-SDR LUT I made and indeed, no color banding like my other tests.
Looking forward to 2.0.7!
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?
In Version 2.0.7 there will be these additional fields (with all their parameters according to https://x265.readthedocs.io/en/default/cli.html):
I guess that will be helpful to you, right?
Awesome yes this will be very helpful.
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:
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:
--colormatrix bt2020nc (It may also be a good idea to allow bt2020c)
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:
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:
(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:
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.