Transcoding: Add handling of default DNxHD bitrates

[iLLiCiTiT]

Changelog Description

Added DNxHD bitrate handling when looking for ffmpeg codec arguments to copy the source as close as possible.

Additional info

The code changes were submitted by a client who did hit an issue if the bitrate was not stored in the ffmpeg arguments.

NOTE: Validate if the bitrates are actually correct.

Testing notes:

I don't know how to create review that does product DNxHD and is not going through ExtractReview.

1. DNxHD bitrates are kept untouched even if ffmpeg arguments that created the source don't contain the bitrate information.

[BigRoy]

The fact that this is even needed. What a mess is this codec 🤮

Anyway, _DNXHD_VALID_BITRATES can do with a small comment as to what the values are supposed to be. It's clear if I read the full PR, but not if just glance over that variable.

[iLLiCiTiT]

The fact that this is even needed. What a mess is this codec

It is our fault we want to edit the video which requires to decode the video -> that means we loose all information about input and we have to try replicate it as close as possible. It is mess because it has so many options. Other codes have them too, we just don't have them in such granular way.

[BigRoy]

The code changes were submitted by a client who did hit an issue if the bitrate was not stored in the ffmpeg arguments.

Do we know how to reproduce such a scenario? 🤔

We have this in Extract Review for a client for FFMPEG arguments

{
  "video_filters": [],
  "audio_filters": [],
  "input": [],
  "output": [
    "-codec:v dnxhd",
    "-profile:v dnxhr_hq",
    "-pix_fmt yuv422p",
    "-color_range tv",
    "-colorspace bt709",
    "-color_primaries bt709",
    "-color_trc bt709",
    "-metadata reel_name={folder[name]}_{product[name]}_v{version:0>3}"
  ]
}

And that's working fine - even before this PR.

[Copilot]

🟡 Changes recommended

Missing metadata can suppress the required bitrate entirely, and the new selection logic lacks tests.

Get a fresh assessment by requesting another Copilot review.

Pull request overview

Adds DNxHD bitrate normalization when reconstructing FFmpeg codec arguments.

Changes:

• Defines valid DNxHD bitrates by format.
• Selects the closest valid bitrate when source arguments omit it.

File summaries

File	Description
client/ayon_core/lib/transcoding.py	Adds DNxHD bitrate lookup and codec argument handling.

Review details

• Files reviewed: 1/1 changed files
• Comments generated: 2
• Review effort level: Balanced

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[iLLiCiTiT]

Do we know how to reproduce such a scenario?

I don't know. I guess nuke does allow to bypass core's extract review?

[rdelillo]

Confirmed it works as expected, base case-test scenario I could find was DNxHD media ingest on Hiero.
Basically extract_otio_trimming_video will call this code when ingesting a plate if the media is dnx and the clip on the timeline is shorter than the actual video range. It'll trim the input media to the shorter clip source frame range.

• Tested DNxHD36 4:2:2 made from Nuke = all good found the closest bitrate with the function
• Tested DNxHD350x 444 made from Nuke = not within the constant, default to stream bitrate = failed as usupported by ffmpeg

The DNxHD bitrate values within the constant looks correct according to the DNxHD specs

I didn't go through going to my version of FFmpeg and checking the constant contained ALL of the supported flavor.
Shall we do that ?