Problem summary: Certain MXF files are given incorrect pixel aspect ratios when read by Nuke
This issue affects DNxHR MXF footage in OP-1a and OP-Atom patterns, and all five Codec Profiles available in Nuke 14.0v5 ("4:4:4 12-bit", "HQX 4:2:2 12-bit", "HQ 4:2:2 8-bit", "SQ 4:2:2 8-bit", "LB 4:2:2 8-bit"). DNxHD MXF footage can also be affected.
Customer reported version: Nuke 14.0v5
Customer reported platform: macOS 12 Monterey
Steps to reproduce: 1) Open Nuke and create a CheckerBoard node in the Node Graph.
2) Create a Write node and set the file path to a MXF file, such as "example.mxf".
3) Click the Render button to export the MXF.
4) Create a Read node, select the MXF file, and observe its pixel aspect ratio:
This is also visible in the Read node's Metadata tab under the input/pixel_aspect key:
Expected behavior: MXF files should maintain their original pixel aspect ratios and not be set to incorrect values when read into Nuke.
Actual behavior: Reading certain types of MXF footage in Nuke results in an incorrect pixel aspect ratio. For MXF files created outside of Nuke, the incorrect pixel aspect ratio may be the same as the aspect ratio of the footage. However, reading MXF files that were created in Nuke seems to consistently assign 1.778 as the pixel aspect ratio.
This issue also occurs if the footage has an original pixel aspect ratio other than 1:1. For example, exporting the CheckerBoard MXF with the 2K_Cinemascope format (1828 x 1556, pixel aspect 2) still results in a pixel aspect ratio of 1.778 when the file is read back into Nuke.
Workaround: No known workaround at this time.
Reproduced by Support in: Nuke 14.0v5 - Windows 10, CentOS 7 - Regression
Nuke 13.2v8 - Windows 10 - Regression
Unable to reproduce bug in: Nuke 14.0v4 - Windows 10, CentOS 7
Nuke 13.2v7 - Windows 10
Earliest version tested: Nuke 14.0v4 and 13.2v7 - This issue doesn't appear in these versions and has regressed