Beiträge von morphinapg

  • HDR support in x265 and nvenc HEVC

    Zitat von Vouk

    I think about adding 3 dropdown boxes to voukoder. The most common values will be preselected. Reason for this that these values are independent from premiere and need also to be set when using an other NLE (i.e. VEGAS)

    Filters will only be applied when the frame data from the NLE differs to the output setting.

    Examples:

    • premiere delivers rec709 limited - output is set to rec709 limited -> No Conversion
    • premiere delivers rec601 limited - output is set to rec2020 something -> Conversion

    Due to the fact that premiere will never deliver rec2020 there will be always a conversion. There needs to be a ruleset defined.

    The issue here is that if you want to be able to output HDR correctly in premiere, then premiere must interpret it as rec709. I really don't think there's a reason for conversion. If you use the ispace, itrc, iprimaries filters then you're defining what the input space is, which is what the main reason for using those options should be. If the user wants to do a conversion, then that should be a separate option on the video filters section of voukoder.

    Perhaps as a compromise, maybe you could keep it the way it is (plus the other two drop downs when bt2020 options are selected) but add "Override Input Color Space" to the video filters section, where the user can override those values for the input, in case something in the NLE is sending the data incorrectly. Also, I would recommend requesting the rec709-based input for anything that isn't rec601 selected.

    Premiere just has a particularly weird way of handling HDR when HDR is flagged correctly. It will never work with voukoder as it is, because it will be sending data in an unclipped rec709 format. Like, there will be values "brighter than white" and the only way to process it correctly would be to perform a manual mathematical conversion from THAT source, into the correctly selected transfer function. Furthermore, I'm pretty sure Adobe is clipping black in this mode as well. It's just a mess on that end and simply won't be sending the data in the way x265 expects, and it will likely stay that way for a while.

  • HDR support in x265 and nvenc HEVC

    It's certainly possible for there to be weird combos, like I've seen 4K Blu-rays with DCI-P3 primaries, even though they all use rec2020 color space. It's also technically possible to use rec709-based trc with rec2020 colors, but this is rare. This would be for example, an SDR video with Wide Color Gamut. And then you also have HLG, which uses the ARIB STD-B67 trc. Some broadcast providers use this format, as well as Wickyed's camera, apparently.

    Maybe what I would suggest is leave the drop down as it is when the user first opens the Premiere Export page, but once they select bt2020nc or bt2020c, then two additional dropdowns appear for transfer fuction and primaries, with st2084 and bt2020 as defaults. I think most people dealing with bt2020 color will have some familiarity with those concepts, but they most likely won't be necessary for rec709 or rec601 formatted videos.

    If you do this, the x265 options for those may not be necessary, but only if you can ensure that no color space conversion is happening. I fear those filters above will still cause a conversion. Changing them to ispace/itrc/iprimaries may fix that. If not, keep the x265 options as a failsafe. I believe that the options on x265 will simply re-interpret what ffmpeg passes to it, without any further conversion. If ffmpeg's filters are doing a conversion, then x265's options won't undo that. They will simply assume the already-converted colors are in the space you specify.

    Also, in the above code, bt2020nc and bt2020c are handled the same. Might want to fix that.

  • HDR Issue - Color is apparently being converted from rec709 to rec2020 space when rec2020 output options are selected

    Zitat von Vouk

    First some questions:

    1. Did this work with version 2.2 properly?

    2. Can you please take a look in your log file (%LOCALAPPDATA%\Voukoder) and tell me the pixel format that is mentioned next to:

    "Requesting pixel format:"

    [03:52:20] Requesting pixel format: yuv420p10le

    [03:52:21] Applying video filters: colorspace=range=mpeg:space=bt2020ncl:trc=bt2020-10:primaries=bt2020,format=pix_fmts=yuv420p10le

    I wonder if that's the problem right there, the video filters. Those are most likely performing conversions. You shouldn't need those. Just set the correct options in x265, as described above. Or, perhaps you should be using ispace, itrc, and iprimaries instead maybe?

    Most likely ffmpeg is assuming bt709 as the input color space, so when you tell it what the output color space should be, it feels the need to do a conversion, causing this issue. That being said, it's not performing a conversion on transfer characteristics, so I'm not entirely sure. But maybe that part's because of the yuv420p10le format.

    2.2 doesn't save any of my advanced x265 settings, so I can't exactly encode HDR properly, but outputting with bt2020 settings in the main Premiere window does in fact cause the same color shift.

    ----

    In the meantime I've found using a rec2020 to rec709 conversion LUT, applied in Lumetri Color is a workaround to this issue, but of course this limits the color gamut to SDR color, so it's not ideal.

  • HDR support in x265 and nvenc HEVC

    Zitat

    However if I refer to this post, Premiere does not outputs in RGB32 or maybe RGB32 -> YUV 444 -> yuv444p16 -> yuv420p10 ?

    Oh okay, you're right, I was mistakenly remembering the bit about piping.

    Zitat

    In my case, I have a Sony AX 700 which outputs those kind of files:

    This... is an issue, actually. For voukoder HDR output to work, it needs to be sent the unprocessed raw yuv data, and while Premiere may be outputting yuv, it's doing so in a floating point SDR transfer function. So your video will be clipped to 100nit SDR, and outputting to HDR would severely distort the image. This is why I specifically tell my Ninja Inferno to record HDR data in "rec709 mode" which maintains all 10bit source pixels unmodified, but simply flags it as rec709 instead of rec2020. This way, voukoder gets the data unmodified, meaning it gets the correct transfer function and chroma values, even though Premiere thinks its rec709.

    While Premiere supports HDR input, the workflow for it isn't something we can use Voukoder with, since it would require a conversion from floating point SDR (which contains values "above white") to PQ or HLG, which use a very different gamma transfer functions. It's a pretty complicated process that would severely slow down the encoder I'm sure, so it's not optimal. The only way to edit a correctly flagged HDR input file and output it in HDR as well, is to use Premiere's own H265 output encoder, with the HDR flag selected. It's not great, since you can't use CRF and other advanced options, but until Premiere improves on its workflow options, I think that's all you can do.

    To do proper HDR through Voukoder, you're going to need to find a way to convince Premiere that your video is rec709. You may need to reencode using something that preserves the pixel data correctly but doesn't preserve the rec2020/HLG flags, such as avidemux, unless you can find some kind of program that will modify video track flags. Possibly ffmpeg or MP4box? I'm not sure.

  • HDR support in x265 and nvenc HEVC

    The options are there, they just work differently. You set color space in the regular premiere export window, and then set the other HDR options in the advanced settings.

    The problem is, the color space settings result in a color space conversion that messes up the HDR colors, because voukoder or premiere treats the footage as rec709 SDR.

    However, yes, there's no option for HLG right now, just HDR10 using the options available as they are now. Reverting fine control of those x265 tags would be good, because they allow more options for color space and transfer characteristics, such as --transfer arib-std-b67 for HLG

    However, as per my other post, the color space setting in the Premiere export window should not be performing color space conversions. They should be telling the encoder what color space the footage already is. I realize the problem is Premiere outputs in RGB32. Basically, this needs to be converted to rec709/yuv420, and then encoded to whatever color space we select without further conversion.

    Refer to the ffmpeg command I typed from a previous post for an idea of how this works:

    Code
    -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

    This interprets the RGB32 video as yuv420p10, then encodes that directly to whatever color space I wanted (in this case, bt2020c). No color conversion is performed.

  • HDR Issue - Color is apparently being converted from rec709 to rec2020 space when rec2020 output options are selected

    MediaInfo from my source file, the one I'm editing in Premiere?

    I specifically tell my Ninja Inferno to record in rec709 mode, so that the footage appears in its raw form in Premiere, which is what's necessary for monitoring in HDR, and what's necessary for the Voukoder HDR output. But it's 10bit, PQ, rec2020, in a rec709 container.

    As I said before, if I allow Premiere to import it as correctly tagged HDR footage, then Premiere will display it somewhat correctly on an SDR monitor, but there will be no way to monitor it correctly in HDR, and the output won't be in the correct format for what x265 needs, as it will essentially pass a 100-nit clipped SDR version to Voukoder, instead of the raw HDR video.

  • HDR Issue - Color is apparently being converted from rec709 to rec2020 space when rec2020 output options are selected

    I'm working on another HDR project, and with the newest beta of Voukoder I'm having some issues with color in HDR. Working with HDR in Premiere is a bit of a weird thing. Basically, you have to import in the raw, unprocessed 10bit footage, which Premiere will assume as rec709 color. This will look all washed out and incorrect, unless you have an HDR monitor that can take this raw ST2084 encoded footage, and display it in HDR correctly, which I have.

    So, Premiere thinks you're working with rec709 footage, even though the footage is actually rec2020 underneath. This is necessary, because if you give Premiere an actual correctly-flagged rec2020/st2084 video, it will convert those colors into something that will display more correctly on an SDR display, but can not be encoded to HDR correctly aside from Adobe's own codec, and can not be displayed on an HDR monitor correctly, for monitoring while editing.

    When I select rec2020 for output in Voukoder, there appears to be some color space conversion going on, which causes a serious shift in colors, making everything appear greenish. I'm guessing Voukoder sees the footage as rec709, and wants to convert the colors to rec2020, but even though Premiere interprets it as rec709, the footage is actually rec2020 and so should need no conversion. Here is a raw frame as it appears in Premiere on a normal monitor:

    and here is how that frame gets encoded with Voukoder set to rec2020:

    Right away, even in the unprocessed raw footage you should be able to tell that colors appear more washed out, and more green tinted. But here are the same two images, with HDR-to-SDR tonemapping applied, to give you a more "correct" look at how the images would display:

    That's a major shift in color, and looks really bad.

    I actually noticed this issue before, while encoding my previous project in Voukoder 2.0.8. However, that version had two different options for color space. In the normal Premiere window, I set color space to rec709, because that's essentially what Premiere assumes it is, but then in Voukoder's advanced x265 settings I set these options that specified to encode in rec2020 and ST2084/PQ

    --colorprim bt2020

    --transfer smpte2084

    --colormatrix bt2020nc

    This allowed the raw image to pass through mostly unaffected (although there's always a slight tint seemingly applied to all encodes I make with x264 & x265 from Premiere, voukoder or not). These options are apparently gone now, in favor of a single color space selector in the main window.

    Since Voukoder appears to correctly assume that the transfer characteristics (ST2084/PQ) are inherent to the source, and not something that needs to be converted, it should do the same for color space. When you select color space, you should be selecting what the source already is, not what you want to convert it to.

    I hope this is something that could be fixed somewhat soon, but if not I can always go back and install the older version which worked better.

  • Redesign the User Interface

    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.

  • Redesign the User Interface

    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.

  • Redesign the User Interface

    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.

  • Redesign the User Interface

    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:

    https://sourceforge.net/projects/asxgui/files/asxgui/2.5/

    You might need to run as administrator for it to work.

  • As a user I would like to export with HDR.

    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?

  • As a user I would like to export with HDR.

    Awesome yes this will be very helpful.

  • As a user I would like to export with HDR.

    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:

    Code
    -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.

  • As a user I would like to export with HDR.

    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

    --hdr-opt

    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.