Beiträge von morphinapg

If you want to just make really basic cuts like trimming out a part, without any effects or transitions, you might want to try using AVIDemux for this purpose, as it can perform that task without re-encoding at all. Then if you still want to re-encode it, you can use the file it created and encode directly in ffmpeg, although learning the full command line for something like that might be complex.

But yeah, if you're doing full editing work, I think the preset is the best way to handle that type of footage at least until we can figure something else out. Or I suppose you could use Adobe's HEVC encoder instead, although I'm not a fan of the way that thing works myself.

Hmm I'm having trouble with MP4/MKV files as well (my files are HEVC)

I did this one time successfully. It was with my ProRes footage stored in an MOV file. My Atomos Ninja Inferno can record HDR either with the HDR metadata, or without, and one time I had a recording where I accidentally let it record with the metadata, but I had a short rec709 clip with the same frame rate and resolution and codec, so I used concat to combine the two and it worked great. But I don't seem to be having the same results with my HEVC files. Premiere actually glitches trying to read them which is particularly strange.

Perhaps there is something inherently different and incompatible between SDR HEVC-10bit and HDR HEVC-10bit, while perhaps with my ProRes footage the only difference was in the container's metadata. I would have thought the same codec would be able to mux together like that, but perhaps there's something deeper in HEVC preventing that. I even tried creating two MKV files and using mkvtoolnix to append them and that had the same result, glitchy video that wouldn't play. I'm surprised yours is even playing after concat haha

Unfortunately if you cannot successfully remove the metadata from the file before Premiere reads it, then you'll need to use my preset. I'll keep researching this to see if there is any other way to strip that info but I think it's buried deep in the encoded stream so it may not be possible.

Zitat von dcsimpson

This time I embedded rec709 in the file i was going to pair with the source file and that all seemed to work ok and my output from the concat lists rec 709 in mediainfo so that part was good. But when I import into Premiere the hdr portion still looks really bad with highlights clipped. Bummer.

But let's say it did work for me. How do you actually export from premiere at this point? At what stage did you produce that nice tone mapped image of Ellie? Do you export using all those methods that you described initially that include embedding the rec2020 color in the VUI tab and all that?

The tonemapping is another part of my own personal process as I also produce SDR color graded versions of my videos, but as for how to encode it once you have the video looking like premiere isn't processing the HDR-to-SDR conversion itself, that's listed in the first post. If you've already got the MaxCLL and MaxFALL numbers from the source file, you can skip the HDR Metadata section of the guide, as that's what I use to analyze my source footage (I currently have over 2000 frames captured from my current project for that purpose)

So yeah, just follow along where I say what to put into the VUI section for x265 and it should be good. Skip the part after the edit unless you want to use some other codec.

I would just use premiere and voukoder to make a blank rec709 file to concat with.

But for example, assuming your source is 3840x2160 and 23.976 fps, I would open premiere, create a new sequence that matches those aspects, and insert a "black video" (file->new->black video) into the sequence. By default it's 15 seconds but you can trim it down to just a few seconds, and then in voukoder do something like this:

(this is for x265)

My exported file doesn't list rec709 but that's okay. As long as it doesn't list rec2020 and/or PQ, you should be good.

As for the frame rate, if exporting as MP4 gives you variable frame rate, then try exporting as MKV. I believe ffmpeg might still be able to concat from different containers because it's using the original track data. If not, you can remux the MKV to MP4. Oddly enough, the easiest method I've found to remux MKV to MP4 is in the program OBS, which contains a tool specifically for this purpose. But the app AVIDemux would probably work fine too.

Now, I'm not 100% certain what would happen if you try to concat a video only file with video+audio. It might work, but otherwise you might need to ensure the blank video includes a matching audio codec. If your HDR source has something weird for audio, you might need to trim out the original audio somehow, cut to the same length as your blank clip above. AVIDemux might be able to help you with that as well, but that's a more complicated process. If the source is just AC3 audio or something, you can include that codec in your voukoder settings.

Zitat von dcsimpson

Forgive me but I still don't quite understand. So you're saying if I concatenate a 4k rec 709 SDR file with my actual 4k HDR source file and import that into premiere, premiere will treat it like a rec709 clip and it will look correct to the naked eye without any conversion, presets or anything?

And then are you saying just export from Premiere using Voukoder like normal as a rec709 sdr 4k file?

What I'm saying is, in order to get the most accurate color reproduction out of Voukoder when encoding in HDR, Premiere has to wrongly think the video you imported is SDR. It will display incorrectly, with flat colors and tinting, as shown in the examples in the first post, however, despite displaying incorrectly in the program monitor, voukoder will encode it correctly because the raw ST2084/BT2020 data is being carried over untouched.

If you concat a rec709 4K file (same resolution, codec, frame rate, and audio) with the HDR file, premiere will think you're importing a rec709 file, and therefore not perform any conversion on the colors. Because it doesn't perform any conversion, you won't need my preset to "undo" what Premiere typically does with HDR files normally, and it's already ready for export.

For an example, here is a project I'm working on right now. Here's what it looks like in Premiere:

This is the raw unprocessed ST2084/BT2020 footage. Because of this I can use voukoder without my preset. Premiere (wrongly) thinks it's loading rec709 footage because my footage looks like this in MediaInfo:

and here is how the same frame appears with the HDR tonemapped to SDR correctly:

much more natural

and here's what Premiere WOULD have looked like if it originally recognized my source footage as HDR:

Colors and highlights quite a bit more blown out. While I've used a Lumetri preset to simulate what Premiere does with HDR footage, it's essentially the same idea. They apply a conversion to the original raw data to make it viewable on an SDR screen, but just as a flat 100nit clip instead of tonemapping. Thankfully because of the floating point nature of their video processing, I can reverse this conversion for the most part with my preset, but because that then becomes two colorspace conversions in a row, some loss of color accuracy occurs in the process.

I don't believe premiere tells you whether it thinks the video is SDR or HDR unfortunately. You just have to look at the video. Do the colors look more natural? Are some of the highlights blown out? If it was displaying the raw data, the color would look flat and unnatural, slightly yellow/green tinted, and no highlights would be blown out (unless they're just clipped in the source)

The way you can tell Premiere is going to read a video that way is by opening it in MediaInfo. If the clip mentions having BT2020 color and/or PQ transfer characteristics, rather than rec709, then premiere will read it as HDR. Basically, you want to retain the same encoded video data, without those pieces of metadata in there. So appending it to a non HDR video with the same resolution, frame rate, codec, audio format, and container will trick the metadata into thinking it's SDR, and premiere will be tricked too.

If you want to bypass all this work, it might just be easier to use Premiere's own H265 encoder now with HDR options turned on, but if you want to use Voukoder for better control over the encode, it might be worth trying.

Note that HDR clips will usually have more saturated colors than their comparable SDR versions, and some movies also have different color grading in HDR as well, but it's possible something could be happening here.

There will likely be some inaccuracies in color, because of the way Premiere handles HDR source files. Premiere converts them to rec709 first, for display purposes. The format they use is okay if you want to use Premiere's own H265 HDR export, but for Voukoder, the gamma and color needs to be converted back to the raw ST2084-BT2020 data using my preset. Unfortunately, because premiere already converted it into a rec709 color space, converting it back is not going to be 100% perfect. While I do use accurate rec709 to rec2020 conversion calculations, you're going to lose a bit of the original wider color gamut, and there may be rounding errors in both conversions that create that effect you're describing. Gradation between colors though should remain just as smooth as the conversions happen in floating point.

Ideally, the best way to encode these videos with Voukoder would be to ensure Premiere doesn't recognize them as HDR to begin with, so it doesn't perform that conversion, and you can then output 1:1 color information perfectly (or as accurate as the encoder itself is anyway). One way I've found that can work with this is if you append the HDR video, to a video file that has the same resolution, codec, frame rate, and bit depth, but is encoded with rec709 instead of rec2020 metadata. Maybe encode a blank video with the same attributes, including audio codecs, and then use ffmpeg to concatenate the two files together. After concatenating, the output file will use the first file's metadata, so it will ignore the HDR metadata from the second file, and premiere will think the whole thing is rec709. Then you won't need the preset to pre-format the color correctly, as it will already be ready to export. If you can successfully get Premiere to ignore the HDR metadata in the file, you'll create a much more accurate encode in voukoder, but my preset should still get you pretty close.

Zitat von Edragyz

Can someone tell me where to do this? What to change, and where to find it. Thanks.

You don't need to. I've provided the preset above that already accomplishes this

I noticed while testing 8bit output of a video where I tonemap HDR to SDR (performing some color grading) that there was some banding in the output. I'm guessing this is due to premiere reading the source as 8bit, and applying the filter in an 8bit calculation, resulting in rounding issues. I know this wouldn't happen if I outputted in 10bit (tested, looks great), but I don't want 10bit output for a project like this. The maximum depth option in other encoders usually would solve an issue like this by making sure the source and any effects are calculated with 32bit precision.

Zitat von Wickyed

I'm back ! (from holidays ofc :))

I've recorded some 4K HLG HD footages but each file is around 200 MB.

Do you have any preference of the plateform to use for sharing the files ?

I use Google Drive myself

Zitat von scarbrtj

All...
If I have a P3D65 colorspace file... and want to output in that space of course... correct workflow to use NVENC for that? TIA.

I'm thinking you'd probably want to do it this way. Setparams filter:

Then just make sure to set the correct transfer characteristics to match your video clip

Don't use the Lumetri Panel for it. Drag it onto your clip from the Presets folder of the Effects panel

Adobe claims that it affects scaling quality, so if your edits have been scaled in premiere (this may include time remapping), it may improve the quality. If you haven't done anything like that, it probably does nothing.

It's likely something that's applied before Voukoder gets the video data from Premiere.

I don't think Premiere natively supports 7.1. I wish it did. Don't know about the others.

Zitat von Vouk

I guess you are the first one how tried to encode a >3hrs video with Voukouder. Does the error also occur on a 1pass encode? I'd also recommend to use CRF instead of ABR/VBR if you don't target a specific filesize.

I regularly encode videos longer than that, in 4K. I've encoded a 5 hour 4K HDR video with Voukoder without any issue.

Zitat von Kleinrotti

If the values are set correcly it should look something like this in mediainfo:

Params used:

Code

-x265-params :colorprim=bt2020:transfer=smpte-st-2048:colormatrix=bt2020nc:master-display="G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(12000000,200)":max-cll=0,0

Source

You set those with x265. These particular flags are set before the encoder gets the data. The idea being (if they had worked) they could pass that data to any encoder that supported it. In particular, if it had worked, it would have been useful for NVENC.

Ooh good find. Also this one:

https://ffmpeg.org/doxygen/trunk/…ayMetadata.html

Yes I think those do have the potential to help, although I have no experience with them

MaxFALL, MaxCLL, and mastering display characteristics are not some universal flag that ffmpeg can pass to any encoder. They need to be specified by the encoders themselves.

Like I said, you can do HDR without it, it's just not fully HDR10 compliant and may not tonemap as well since the display doesn't have any idea of how bright the content gets.

Zitat von Vouk

Well, I put a 30 fps file on a 60 fps project / sequence / timeline. That's not under voukoders control, it will be handled by premiere / the NLE. The NLE will send a 60fps frames stream to voukoder. These frames can be anything. Applying a decimate filter at this staged doesn't make any sense, right? Setting cycle to 3 would just output a 40fps file.. but... why?

Well yeah that example wouldn't make any sense to do other than testing what happens with the filter. For practical purposes I'm talking about situations where your source recording has a higher frame rate than the underlying content. Such as tv with 24fps in a 60fps recording, or my example where the PS4 outputs 60hz so my capture device records a 60fps file no matter if the game itself is rendering at a lower rate.

Basically, what you could test is import a 24fps video, set the timeline to 30fps,make some cuts (especially trimming out the start), and then export. Then, re-import that 30fps and try to get it back to 24fps. Using normal methods, it may or may not work. Either you'll get something smooth, or there will be a lot of judder. This may also change scene to scene depending on the cuts you made.

Instead of using normal frame rate conversion methods, use decimate with a cycle of 5, and you will be able to fully reconstruct the original 24fps frame rate of the source. Decimate is about reconstructing an original frame rate that is embedded in a higher fps source, and doing so with precise results (no judder).

Zitat von Vouk

Ok, crop and pad added.

Not sure about decimate as it adjusts the output framerate.

On a clip with 25 fps "decimate=cycle=3" would generate a 16.66666 fps file. Wouldn't it make sense to put such file on the timeline and then let the NLE convert it to the desired framerate?

If there is a consistent frame pacing in the source, then yes, letting the timeline do it (or the connector) is absolutely fine.

However, if for example if you have a 24fps source that somehow got encoded as 30fps, then what you have is a 1, 1, 1, 2 pattern, meaning the fourth frame is duplicated. It would be very difficult to ensure the frame rate down conversion would exactly remove the duplicated frame, rather than one of the unique frames. When editing gets involved, it's even harder to guarantee that. If the wrong frame gets dropped, you get severe frame judder as a result.

It's too bad the filter doesn't seem to support removing more than one frame per cycle, as removing two frames from a cycle of 5 would be particularly useful in extracting a 24fps video from a 60p source as well at the correct pacing. However this could probably be accomplished by setting frame rate in sequence/connector to 30fps and then using Decimate with a cycle of 5.

My issue is specifically with video game footage. 30fps inside a 60fps container. Ideally, just dropping every other frame SHOULD be good enough, but with video games sometimes a frame is rendered early or late, so if you use decimate you're more likely to be able to detect which of the two frames in the cycle is a duplicate, to better improve the downconversion.