Posts by Andy

  • Prores very slow on resolve 17

    Use DNxHR or Cineform which is direct ProRes alternative.

    Both should work fine in Vegas (and in Resolve).


    For lossless option you can use 10bit uncompressed (v210) or RGB 10bit, but files will be big.

  • too dark image (cut blacks) in prores 422HQ renders (Resolve 17.3.2 Build 8, Win10)

    ProRes by its spec should be always limited range. There is no flag in its private stream nor in MOV headers which specifies video range.

    You can create full range ProRes, but then you have to ALWAYS manually interpret such a files as full range as not a single app will know it's full range. Some apps (like Premiere) assume by default that full range is used for ProRes444, but there is no rule to it. Resolve itself still loads all ProRes files as limited range which is how it should be.

  • Prores very slow on resolve 17

    Quote from willyfan

    Ok I will send log file tonight, anyway the DVR project is very simple because is only a test: a 4K clip, with a LUT applied, scaled at 1080p. As I wrote, export to a similar codec (dnxhd) is faster, around real time. Vokoder prores take 5 times.
    A info: if I encode on the same PC a prores file using ffmpeg is a lot faster.

    Plugin uses prores_ks which is closer with bitrates etc. to official encoder and ffmpeg default ProRes encoder is prores, which is way faster than _ks version. Use prores_ks in ffmpeg then then compare times.

  • Davinci Resolve now allows for third party render

    ProRes 444 is 12bit, but ffmpeg is still encoding at 10bit.

    Decoding is fixed and preserves 12bit.


    You can add Auto option which has some logic to pick best format depending on encoding format.

    Other options will be for those who know what they are doing.


    Name could be "Pixel format", "Intermediate format"...

  • Davinci Resolve now allows for third party render

    No way to get some documentation from BM?

    I don't believe API has no documentation, but I can understand BM won't share it with "small developers". Poor approach though.


    Yes, you need correct YUV data to encode for sure. You need levels to be correct as well. Fixing it by setting full range in codec flags is not very good workaround (sometimes not possible) as some apps don't read range flags.

  • Davinci Resolve now allows for third party render

    Within the time we should have few pixel formats supported:

    - yuv420 10bit for h264/5 etc

    - yuv422 10bit ProResHQ, DNxHR etc

    - yuva444 12 bit (for things like ProRes 444, DNxHR 444)- does ffmpeg properly encode now 444 at 12bit or they just fixed decoder?

    - rgba 16bit -for anything RGB based


    I assume bit depth scaling is not the issue, so those higher values will cover smaller bits depths.

    Key point is to have YUV data when codecs require YUV data. Let Resolve do proper RGB->YUV conversion based on project settings etc. You don't want to do RGB<-> YUV as this would require all the color space etc. math behind it. Resolve does it well, so better to use final data.



    For ProRes you want to add extra bits to ffmpeg command ( I assume you're adding color space, etc. already), so it looks more like Apple encode:

    -metadata:s "encoder=Apple ProRes 422" -c:v prorers_ks -vendor apl0 -bitexact -movflags write_colr


    These should be correct encoder names:

    Apple ProRes 422 Proxy
    Apple ProRes 422 LT
    Apple ProRes 422
    Apple ProRes 422 HQ
    Apple ProRes 4444
    Apple ProRes 4444 XQ


    for interlaced encoding (this will properly set ProRes private frame header as well) also add:

    -vf "setfield=1, fieldorder=tff/bff" " -flags "ildct+ilme"


    prores_ks is much slower but keeps bitrate in better control (still not perfectly as Apple encoder and affects quality a bit).

    prores encoder is much faster, but it doesn't really restrict bitrate in the same way as Apple encoder. It will be most likely around 10-20% higher than Apple reference (but also quality is closer to Apple).


    When it comes to PAL/NTSC aspect ratio just pass -aspect 16:9/4:3 and ffmpeg does set it properly by default based on frame size.


    When you get timecode working then:

    -timecode 10:00:00:00 -metadata:s reel_name=ABCD123


    no sure if you can get reel name as variable.


    Later we can add audio tracks language and name setting, which is useful.

  • Davinci Resolve now allows for third party render


    Resolve internal processing etc is meaningless here. Explained here:

    https://forum.blackmagicdesign…&hilit=full+range#p711929



    We need full range data as well, but be careful with it.


    ProRes private frame headers have no tag (neither MOV container) to specify range. By design ProRes should be always limited range. You can send full range YUV data to it (ProRes also always stores data as YUV, even if you send RGB to it) and it will preserve it, but reading app will have no clue what is the real range of the file. Only by manual intervention (like we have in Resolve) you can force app to read it as full range. In some apps (like Premiere) it's all hard coded and there is no way to overwrite it. If I'm correct Premiere expects full range for 444 ProRes files and Resolve by default exports limited range, so you always need to set it manually in order to have good mapping between these 2 apps.