Posts by Vouk

  • Input node color space settings do nothing (tested in Premiere)

    Quote from morphinapg

    While most people would never need this, those settings should be there to fix an issue when the editor potentially sends the wrong metadata about those aspects of the video.

    Yes, it is actually exactly there for this case. It allows you to change the color space info that gets sent from the host nle to voukoder. But just, this won't get used in most cases.

    But ... can you ask again in a small, simple sentence what you want me to change? :D

  • Vegas - Voukoder ... Pro rendering questions

    Quote from rif

    If I set the Vegas Pro project settings to 8bit, will it output 8bit material for VOUKODER?
    Or the settings of the Vegas project are not relevant here?
    And VOUKODER renders (from Vegas output) 10bit video according to the encoder settings? (the original material is imported to 10bit to Vegas)
    If this is not the case! Then should I select Pixel format: 32-bit floating point in the Vegas project settings? To get a real 10-bit video to VOUKODRER input and encoder output.

    What finally decides about the actual export color format is this dropdown here:



    In VEGAS Pro you can just select the format which is sent to Voukoder Pro. So if you send 8 bit data to Voukoder Pro and export 10 bit data to a file, Voukoder just converts 8 bit data to 10 bit, but effectivly it is just 8 bit data packaged as 10 bit. In theory you could do this, but the other way around (10 [or more] bits -> 8 bits) would actually make better results.

  • Not Showing up in Vegas Pro 2026?

    Good Idea! But I installed the v143 CRT libraries for ages by default with the installer.

    I have upgraded this today to the latest v145 version as i have changed/updated the C++ version some times before without upgrading this file. Please give me a feedback if this helped in the 2026.2.5 version.

  • No rendering in Vegas pro 23

    The likely culprit is a mismatch in the color range description. The buffer source declares range=1 (full range), but the scale filter is told in_range=tv (limited range). There's also a possible height issue — 1620 is unusual and the scale filter here isn't actually resizing, just converting format/range, so a scale init failure often traces back to inconsistent color parameters like this range conflict. Error -11 is EAGAIN, which FFmpeg surfaces when the graph can't be configured with the given parameters.

    What to try in Voukoder Pro:

    • Make the color range setting consistent — either full everywhere or limited everywhere. Check the output/encoder color settings and set range to match the source (the source says full).
    • If you have an explicit "color range" or "range flag" option in the encoder config, set it to match rather than leaving it on an auto/conflicting value.
    • If the source really is full-range BT.2020 HDR footage, make sure the encoder profile you picked actually supports 10-bit 4:2:2 (yuv422p10le) — some hardware encoders don't, which can also break graph init.
    • What if you set your video height to 1600? Does that work?
    • Please also set the log level to TRACE. Then restart and try again, this outputs more data on failures.

  • Where is hevc_nvenc (Nvidia NVENC HEVC)?

    Yes, sorry, you are right. I was confused with NVidia's naming strategy and mixed up the Quadro RTX 4000 series with the usual gaming series (like RTX 4090, 4080, and so on).

    To be completely open, this depends entirly on the FFmpeg you are using. The listed formats in the designer are auto detected and read from FFmpeg. So you can either build your own FFmpeg (in version 8, dynamic libs, NVidia headers in at least version 13.0) or you have to wait for an update from me (if you prefer to use my installer).

    When will i do the update? I can't tell exactly, but I'm building it right now. But i need check if everything is in there.

    Edit: The correct pixel formats are already there, they are just wrongly labelled:

    • nv16: An 8-bit YUV 4:2:2 semi-planar format (one chroma plane with interleaved U/V samples, sampled at 4:2:2).
    • p210le: A 10-bit YUV 4:2:2 semi-planar format (little-endian).
    • p216le: A 16-bit YUV 4:2:2 semi-planar format (little-endian).

    I'll fix that! But you are anyway good to go now. :)

  • Vegas - Voukoder ... Pro rendering questions

    Hi,

    You've actually already discovered the important part yourself. Let me try to explain why it behaves the way it does, and answer your final question.

    1. Why AMF replaces HLG with PQ and drops the matrix

    This is a limitation of the AMD AMF HEVC encoder itself, not of Voukoder or your Scene setup. The color node in your Scene (range: tv, matrix: bt2020nc, primaries: bt2020, transfer: arib-std-b67) is correct — that's exactly what you want. But hevc_amf doesn't reliably write the VUI color signalling into the bitstream:

    • It tends to hardcode/assume PQ (SMPTE ST 2084) for 10-bit BT.2020 HDR, which is why HLG comes out as PQ.
    • It frequently omits the matrix coefficients (bt2020nc) altogether.

    The reason it "just works" in the Voukoder Pro Transcoder is that a transcode copies the color metadata straight from the source and hands ffmpeg an already-tagged stream. When rendering from Vegas, Vegas feeds raw frames into Voukoder, so the color tagging has to be produced by the encoder — and AMF doesn't do it correctly. Changing the Vegas "Scene / Video Input" color params won't fix it because the problem is downstream at the AMF encode stage.

    So this is not something you're doing wrong. AMF simply can't tag HLG properly here.

    2. Your x265 approach is the correct fix

    What you did is exactly right:

    Code
    colorprim=bt2020:colormatrix=bt2020nc:transfer=arib-std-b67

    Those three params write the VUI signalling explicitly into the stream, which is why the metadata now matches the original. arib-std-b67 is HLG, so that's correct. Adding level=5.1:profile=main10:tier=high to match the source's Main 10@L5.1@High is fine too (note the source is actually L5.1, as you found — L5 vs L5.1 only changes the declared level ceiling, it doesn't affect image quality).

    One small note: you have both colorprim=... in the params string and the color values set in the Scene input node. That's fine — they're consistent — but the x265 param string is what ultimately guarantees the tags in the output.

    3. Your actual question: is the rendered file "close to the original"?

    A few things to separate here:

    • Metadata: With the x265 params above, yes — your output carries the same color primaries / transfer / matrix as the source, so players will interpret HLG correctly and the colors will be right.
    • Quality: With crf=15, preset=slow, profile=main10 (10-bit), you're encoding at very high quality — visually this will be effectively indistinguishable from the ~80 Mb/s source for archival/viewing. Understand that it is still a re-encode, not a lossless copy: the frames pass Vegas → (your project is 32-bit float, ACES, Rec.2020 HLG view transform) → Voukoder → x265. So it's a new generation, not a bit-for-bit copy of the original. For "archival + viewing" that's a perfectly reasonable tradeoff, and CRF 15 slow is more than enough.
    • One thing worth checking: your Vegas project is set to full ACES pipeline (ACES 1.2, ACES2065-1, Rec.2020 HLG 1000 nits view transform). That's a real color transform, so the rendered pixels are the result of that pipeline, not the untouched camera pixels. If your goal is a faithful archive of the original look, consider whether you actually want ACES in the chain, or whether a simpler HLG (Rec.2020) project setup that passes the material through more directly is closer to your intent. Keep your render profile's YCbCr output at Limited to match the source (Limited/tv) — don't switch to Full, or the levels won't match the original.

    Short version: AMF can't tag HLG correctly from a Vegas render — that's an encoder limitation, not your fault. Your x265 + transfer=arib-std-b67:colorprim=bt2020:colormatrix=bt2020nc route is the right way to get matching metadata, and at CRF 15 / slow / 10-bit the quality is excellent for archival, keeping in mind it's still a re-encode (and your ACES view transform does alter the pixels).

    Hope that helps!

  • Where is hevc_nvenc (Nvidia NVENC HEVC)?

    The hevc_nvenc encoder is exactly the NVIDIA (GPU) HEVC encoder.

    But my info reports that yuv422 10 bit got introduced with the rtx 50 series, not with the rtx 40 series.

    Quote

    Prior to this architecture, NVIDIA GPUs strictly did not support YUV 4:2:2 in hardware:

    • RTX 40 Series (Ada Lovelace) and older: The hardware blocks were physically restricted to 4:2:0 and 4:4:4 chroma subsampling.
    • The Issue: If you imported 10-bit 4:2:2 footage (a standard format for cameras like the Sony α7 IV, Canon R5, or Panasonic GH6) on an older RTX card, your system had to hand the workload entirely over to the CPU for software decoding and encoding. This frequently resulted in laggy editing timelines and slow export times.

    By adding native 4:2:2 pipelines directly into the silicon of the RTX 50 series, NVIDIA finally closed a long-standing gap that had previously given Intel's Quick Sync and Apple's Silicon Media Engines a distinct advantage for video editors.

  • Ingestor - An Importer for Premiere Pro

    Starting with this build, Ingestor ships FFmpeg with the installer. You no longer need to grab FFmpeg yourself or add anything to your PATH — a complete, matching set of libraries is placed right next to the plug-in.

    A few things worth knowing:

    • It's FFmpeg 9.x (stock LGPL, no GPL/non-free components), built with hardware-decode backends enabled.
    • AV1 works out of the box. The bundled build includes the dav1d software decoder, so AV1 clips (OBS captures, etc.) decode even without GPU AV1 support.
    • Not sure what your install can decode? Ingestor writes a SUPPORTED-CODECS.md report on every startup listing every decoder, container, and hardware backend it found. Attach it if you hit an import issue.

    Full details are in FFMPEG_DEPENDENCY.md.

    Instructions:
    - Here you can order a 2 month valid trial license (for free): https://buy.voukoderpro.com/ingestor-trial.php
    - You need to add the key to this file: %LOCALAPPDATA%\Ingestor\ingestor.prefs

    It is still in BETA. You might find errors. Please comment them here.