Beiträge von biont

Just a quick extra, nothing to do with color shift, but something I've noticed regarding the difference between versions 2 and 3. I've listened to a file encoded in v3 and thought the sound has too many artifacts at 128kbps. So, I've taken the original file and encoded it using the same template but in v2. Then I opened the audio in both files in Audition to do a frequency analysis. And here's what I see:

V2 (orange) does a proper frequency cutoff at 20000 Hz, as instructed in Encoder Properties. While V3 (yellow) doesn't perform any cutoffs (although it's the same template). And therefore introduces noticeable artifacts in high frequencies.

I'm seeing a subtle but clearly visible color/contrast shift when exporting from DaVinci Resolve using Voukoder Pro 2026.0.18.0.

I tested the following:

• Same Resolve project
• Same source footage
• Same GPU (RTX 5060 Ti)
• Same NVENC encoder

Results:

• Voukoder Pro 2026.0.18.0 → visible color shift
• Voukoder 13.4.1 → colors match the timeline correctly
• Resolve native CineForm export → colors match correctly

I also tested different Voukoder input formats (YUV 4:2:0, YUV 4:4:4, etc.) and RGB Mode settings. No change.

Most importantly, the shift appears not only with HEVC/NVENC, but also with ProRes exported through Voukoder Pro. This suggests the issue happens before the encoder stage.

MediaInfo reports correct BT.709 metadata, so the problem does not seem to be missing color tags.

A while ago I had a similar FFmpeg issue (when converting videos via script) and fixed it by explicitly forcing Rec.709 conversion:

-vf colorspace=all=bt709:iall=bt709
-color_primaries bt709
-color_trc bt709
-colorspace bt709
-color_range tv

Could there be a color conversion regression in the Voukoder Pro pipeline compared to Voukoder 13.4.1?

I'm uploading the original video and two conversions:

VoukoderProTest

Shared folder VoukoderProTest

k00.fr

This color shift makes Voukoder Pro unreliable for me. I didn't find a way to resolve this, so I'm going back to v13 for now.

This is original:

This is converted in Voukoder Pro:

I even tried forcing correct parameters – same result, subtle color/contrast shift.

Okay, I've actually tried to downgrade to v2.0.10, and guess what, everything is fine - no color shift. So, you've broken something in 2026 version. And not only that. The overall responsiveness of the software seems to have degraded, with noticeable lag when opening the Scene Designer. And the Scene Designer no longer respects the scene selected in DaVinci Resolve. Instead, it consistently opens the first scene by default, requiring me to manually select the correct one every time. The arrow to resize Properties window (such as Encoder Properties) doesn't show up (you have to guess where to click to adjust the window size). That's just few of the things I've noticed.

Sorry, mate, I'm here to report only. It will only take a minute for you to test: Muxer Properties > MP4 > Faststart=true, if the rendered file actually plays back – congratulations, you've fixed it. I'll be upgrading my Voukoder to a newer version, once the adjustable NVENC codec tag is implemented. Otherwise it's all good, don't wanna mess up anything in my current workflow.

Sure, everything's inside. When faststart (movflags 64) is enabled in the MP4 muxer, the resulting file is unreadable. The same file processed with standalone FFmpeg (-movflags +faststart) works fine. Maybe the post-processing step to move the moov atom is failing or corrupting the file.

Sorry, forgot to mention. It's MP4.

Hi, I get faulty file that doesn't open, when using NVENC and setting faststart to true in MP4 container in Voukoder Pro.

There is a practical compatibility issue with HEVC files encoded via NVENC. By default, Voukoder writes the hev1 codec tag, and such files do not play on iPhones. iOS expects the hvc1 tag – with it, the same file opens and plays without any issues.

As a result, after encoding I have to do an extra remux step via ffmpeg just to change the tag using -tag:v hvc1, without re-encoding. This is purely a container-level fix, but it adds unnecessary friction to the workflow.

It would be very helpful to have a simple option in the settings to specify a custom codec tag for HEVC output (or override the default), so this remux step can be avoided entirely.

This does not affect quality or encoding itself, only playback compatibility on iOS devices.