Why is 10-bit ProRes 422 HQ detected as rgb/4:2:0/8/tv on macOS? (Hybrid 2026.08.21.1

[suomen digitointiyhdistys]

Hi everyone,
I'm using the latest macOS build on an Apple Silicon M2 Mac:

• Hybrid version: 2026.08.21.1
  
• Python version: 3.14.7
  

When I load a 10-bit Apple ProRes 422 HQ .mov file (PAL 720x576, 25fps, Top Field First), Hybrid displays this under the Video info on the Base tab:
Color: rgb/4:2:0/8/tv
Under Show All Data, the XML shows:

• Color Space: rgb
  
• Color: 4:2:0
  
• Bit depth: 8
  

However, MediaInfo and ffmpeg report the file as YUV 4:2:2 10-bit:

• MediaInfo CLI: <ColorSpace>YUV</ColorSpace>, <ChromaSubsampling>4:2:2</ChromaSubsampling>, <BitDepth>24</BitDepth>
  
• ffmpeg: yuv422p10le
  

Because Hybrid sees the input as RGB24, the generated VapourSynth script inserts this line right before QTGMC:

# adjusting color space from RGB24 to YUV444P8 for vsQTGMC
clip = core.resize.Bicubic(
    clip=clip,
    format=vs.YUV444P8,
    matrix_s="470bg",
    range_in_s="full",
    range_s="limited",


This causes the contrast to get washed out and blacks turn gray.
I tried changing the settings in:

• Filtering -> (De-)Interlace/Telecine -> Overwrite input luminance
  
• Filtering -> Vapoursynth -> Misc -> Overwrite output: color matrix / luma
  
• Unchecking "Convert to target color space after source filter"
  

...but none of these prevented Hybrid from inserting that RGB24 -> YUV444P8 conversion before QTGMC.
Is there a way or a setting to make Hybrid recognize this file properly as YUV 4:2:2 10-bit instead of RGB 8-bit, or is this an input parsing issue with ProRes on macOS?
Any help would be greatly appreciated!

---

Hello again!

When loading a 10-bit ProRes 422 HQ interlaced .mov on macOS (Hybrid 2026.08.21.1 ARM64), the file gets treated as rgb/4:2:0/8, which triggers an unwanted RGB24 -> YUV444P8 conversion before QTGMC and washes out contrast.
Looking through the Debug Output (level 9), I noticed this section during the analysis:
FFmpeg output:
Stream #0:00x1: Video: prores (HQ) (apch / 0x68637061), yuv422p10le(top coded first (swapped)), 720x576, 58705 kb/s, 25 fps, 25 tbr, 2500 tbn (default)
Followed by:
Analyzing ffmpeg data...
-> found video_luminancescale: tv
-> found video_colorspace: rgb
-> found video_color: 4:2:0
-> found video_bitDepth: 8

Could it be that the additional tag "(top coded first (swapped))" right after "yuv422p10le" might confuse the parser here?
I have attached the full Debug Output Level 9 and a small sample file for you to check.
Thanks for your time and help!
Best regards

[Selur]

Does the latest dev behave the same way?
Also can you share a short sample of such a source? (can't reproduce this here with any of my ProRes samples)

Cu Selur

[suomen digitointiyhdistys]

Also does the same with the newest build.

EDIT:
For context, the source .mov file is captured using an AJA Io LA with AJA VTR Xchange, which encodes the signal on-the-fly directly to ProRes 422 / ProRes 422 HQ (10-bit)

[Selur]

Okay, this also happens with the latest dev on mac os (not on Windows or Linux).
=> I'm looking at it an will report back.

Cu Selur

[suomen digitointiyhdistys]

Thank you! 

Given the ongoing setup and parsing hurdles on macOS ARM, would you recommend switching to a Windows environment—either a dedicated Windows PC or running the Windows build inside a Windows 11 ARM VM (via Parallels/VMware)—if my main priority right now is a stable, production-ready Hybrid workflow for QTGMC and filtering?

[Selur]

It is an issue with the parser that parses the ffmpeg analysis output. (parser fails and rgb is used as fallback)
=> working on it

Cu Selur

[suomen digitointiyhdistys]

Thank you for confirming and looking into it! Really appreciate your help.

[Selur]

Uploaded a new dev version, which seems to fix the problem here.
Let me know whether that version, fixes the problem for you too.

Cu Selur

[suomen digitointiyhdistys]

Thank you so much! The new build completely fixed the issue. The file is now correctly identified as YUV422P10, and that unwanted RGB conversion before QTGMC is completely gone. Contrast and black levels are now preserved perfectly.

I have one quick follow-up question regarding dfttest:
Do I actually need dfttest for anything if I'm not explicitly using it as a standalone denoiser? Does QTGMC or any other standard workflow rely on it under the hood on macOS, and is it even available / supported anymore with the new Python/ARM64 setup?
Thanks again for the lightning-fast fix and all your hard work on this!

[Selur]

DFTTest/DFTTest2 are used in GradFun3D, SMDegrain (when selected as prefilter), TemporalDegrain2 (when used for postFFT), QTGMC, QTempGaussMC, MCTemporalDenoise in LSF (when used for preBlur).

Note that the latest dev, does not rely on locally installed python, Vapoursynth&co, but bundles it all.
(Hybrid.app/Frameworks/python/lib/python3.14/site-packages/vapoursynth/plugins/libdfttest.dylib is the one currently used, iirc. that one is from https://github.com/yuygfgg/Macos_vapoursynth_plugins)

Cu Selur

Ps.: but yes, that nobody seems to care to update dfttest/dfttest2 for API4&pip and also arm neon is a pain.
PPs.: QTGMC only needs dfttest for medium, slow, slower presets. (but Hybrid atm. requires it without this distinction, due to the option to add custom options)
PPPs.: the only binary that atm. requires rosetta is the old MKVToolnix currentliy used in the MacOS app. (mainly since I haven't foudn the time to update and test newer versions)