ID 454019 - Nuke 12 and later releases unable to correctly interpret QuickTime files encoded as h264 avc1 codec

Follow

Problem summary
When importing mp4 QuickTime files encoded as avc1 h264 into Nuke 12.1 (Mac/Linux) or 12.2/13.0 releases (Windows), users can encounter a crash or an error when reading in the file.

This cause of this issue appears to be associated with the specific avc1 h264 codec not being able to be correctly interpreted, possibly due to the depreciation of the QuickTime codecs in the above mentioned releases per operating system.
 
The result will either be a crash, or the last and first frames will error.

Customer reported version
nuke.12.2v3

Customer reported platform
10.14

Steps to reproduce

1) Create a new screen recording on a mac machine (or import a mp4-based h264 avc1 Quicktime file)

2) Open a new Nuke 12.2v1 (or later) session

3) Read in the QuickTime file
Result: Nuke crashes, or errors on the first and last frame.

Expected behaviour
Nuke 12 releases and later should not crash when importing QuickTime files

Actual behaviour
Nuke 12 releases and later have errors or crash when importing QuickTime files that are h264 avc1 of origin.

Workaround
It is currently possible to open these files by forcing the legacy mov32 readers

To do this, you will need to amend 'mov32:' to the existing file path.

The easiest way to do this is to do this without crashing on import, is to:

1) Open an existing Read node that is connected to footage

2) Copy and paste the file path of the QuickTime file from your browser, adding in 'mov32:' before the file path, then open.

 
Note: This workaround does not work within Nuke 13 releases, as mov32 is entirely depreciated

Reproduced by support
This bug has been reproduced in:
Nuke 13.0v2 - Windows 7 - MacOS 10.15.3 - Centos 7
Nuke 12.2v3 - Windows 7 - MacOS 10.15.3 - Centos 7
Nuke 12.2v1 - Windows 7 - MacOS 10.15.3 - Centos 7 - regression
Nuke 12.1v5 - MacOS 10.15.3 - Centos 7
Nuke 12.1v1 - MacOS 10.15.3 - Centos 7 - regression

Unable to reproduce bug in:
Nuke 12.0v7 - Windows 7 - MacOS 10.15.3 - Centos 7

Earliest version tested
Nuke 12.0v7
- This issue doesn't appear in this version and has regressed

    We're sorry to hear that

    Please tell us why