[FFmpeg-user] Problem extracting subclips of Avid DNxHD 36 to-the-frame

[Bouke / Videotoolshed]

On 13 Apr 2023, at 16:40, MediaMouth <communque at gmail.com> wrote:
> 
> 
> Thanks Bouke, indeed the math did the trick in terms of getting FFmpeg to create the proper TRT.
> 
> It even creates a series of playable QTs whose starts and ends seem correct (almost.. more below. The offset seems fine, visually, and we get the proper TRT when imported to Avid)
> 
> BUT Avid is not able to play the imported files.  In other words they play in QuickTime Player but in Avid the video plays as black from, with a flickering error message.
> Not expecting anyone to trouble-shoot Avid, or understand its notoriously cryptic 1990s-style messages. Only posting this in case it gives a clue.
> SWDecodevtr::ExecuteRequest()
> CONSISTENCY CHECK FAILURE
> !?! : [<idNum>]
> 
> Also these quirks, when looking at the generated subclips in QuickTime Player v7,
> The first frame of video is black.  There are no black frames anywhere in the original source. 
> Also, being QuickTime 7, there's a little pulldown in the lower left to volley between "Standard", "TimeCode", and "Frame Number".
> "Time Code" shows BOTH the first (black) frame and second as 1:00:00:00 (frame does not advance).  From there everything counts up as normal.
> "Frame Number" shows 1st (black) and 2nd (picture) frames as frame 0.  From there everything counts up as normal.
> It gives the impression of a kind of flubby first frame of video.
> 
> Since we're using the '-c copy', and the import worked perfectly when we didn't calculate for the 23.976 offset,
> I wonder if the failing import is because the math tweaks something by a small fraction creating some kind of slight offset Avid doesn't like?
> 
> Any ideas?

I have no clue, I have done tons of FFmpeg jobs with DNxHD, and I don’t recall any issues like this.
What I don’t get, why are you doing this?

You can consolidate in Avid, would be as fast without all the hassle.

> 
> Here's the workflow/math:
> 
> Taking Master TCs from an EDL from Avid, so "hh:mm:ss:ff" calculate Seconds = ((hh-1)*60*60) + (mm*60) + (ss) + (ff/24)
> Then add .1% to those start/end times: Secs = Secs * (1001/1000)
> 
> Perhaps the algorithm isn't right?


No clue, note that TCout is not the same as TC last frame. (And frame 0 is also a frame!)

But that won’t be of any influence of the files not being playable by Avid.
Are you importing (fast) or AMA’ing the clips?

What does Resolve do with them?
Etc etc….

Bouke