ID 306040 - QuickTime files with a non-constant frame rate incorrectly interpret frames within the Read nodes mov64 encoder

Follow
  1. The Foundry SANDBOX
  2. Bug Tracker
  3. Nuke

Problem summary
It has been discovered for some QuickTime mov and mp4 files, that there is a difference in frame interpretation between QuickTime's mov64 and mov32 encoders within Nuke's Read node.

This issue appears to be relevant to QuickTime encoded files that contain a non-constant frame rate (variances in sample length) and in user cases is related to media directly encoded from a camera source.

This will cause a duplicate frame (or frames) at intervals throughout the clip duration. This appears to be isolated to just the mov64 encoder.

This issue occurs on all operating systems and only occurs in Nuke 10.5 releases and later.

 

Customer reported version

Nuke 11.0.3

 

Customer reported platform

Windows 10

 

Steps to reproduce

1) Open a new Nuke session

2) Using a Read node, import the affected footage (or use the netshare linked footage)

3) Ensure that the Read node is set to encode as mov64 and several frames into the clip

4) Duplicate the Read node

5) In this new Read node, alter the encoding method to mov32

6) Compare the results of both Read nodes through the viewer

Result: There is a difference between the two Read nodes in the viewer

 

To confirm that mov32 is correct and this issue is related to the mov64 encoder:

7) Open the mov/mp4 clip file from step 1 in QuickTime player on the same frame as Nuke.

8) Compare the results between QuickTime Player and the Nuke viewer

Result: The two frames match visually between Nuke and QuickTime Player

 

Workaround

After Nuke 10.5 releases avoid using the mov64 encoder for affected footage and use the mov32 encoder as an alternative.

 

Reproduced by support

This problem has been reproduced in:

Nuke 11.2v2 - Windows 7 - MacOSX 10.12 - CentOS 6.9
Nuke 11.2v1 - Windows 7
Nuke 11.1v5 - Windows 7
Nuke 11.1v1 - Windows 7
Nuke 11.0v4 - Windows 7
Nuke 11.0v1 - Windows 7
Nuke 10.5v7 - Windows 7
Nuke 10.5v1 - Windows 7 - MacOSX 10.12 - CentOS 6.9 - regression
 

Unable to reproduce bug in:

Nuke 10.0v6 - Windows 7 - MacOSX 10.12 - CentOS 6.9

 

Earliest version tested

Nuke 10.0v6

- This issue no longer appears in this version and has regressed


Expected behaviour
There should be no frame difference between mov64 and mov32 encoding methods

Actual behaviour
There is a frame difference between mov64 and mov32 encoding methods

    We're sorry to hear that

    Please tell us why