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

[MediaMouth]

> On Apr 13, 2023, at 01:44, Bouke / Videotoolshed <bouke at videotoolshed.com> wrote:
> 
> 
> 
>> On 13 Apr 2023, at 00:49, Media Mouth <communque at gmail.com> wrote:
>> 
>> I've got a 90 minute source DNxHD36-encoded source clip (Exported from Avid)
>> Frame rate is 23.976
>> 
>> Intended subclip would be from 0 to 778.041666 seconds.
>> Testing the following
>> ffmpeg -i {Source} -ss 0 -t '778.041666' -c copy {Dest}
>> ffmpeg -i {Source} -ss 0 -to '778.041666' -c copy {Dest}
>> 
>> The resulting clips, when re-imported to Avid come up 18 frames short.
>> Should be TRT 12:58:01 but imported clip's TRT is 12:57:07
> 
> TRT as in Timecode, or as in TRT? I suspect you’re looking at TC and you did not clock it with a stopwatch.

TRT = Total Running Time

TC of source clip is actually from 1:00:00:00, so the math includes an offset to accommodate. More below.


>> I'm thinking it has to do with the frame rate?
> 
> Yes, your 12:57:07 is probably timecode. 00:12:57:07 converted to frames is 18655
> A frame in 23.976 = 1000 / 23.976 = 0.0417083 seconds
> That times 18655 makes ‘about’ the intended length.
> 
> Keep in mind that 23,976 timecode is always Non drop, and since it runs slightly slower than the time on the wall, your outcome is as expected.
> The total running time will be correct. 
> 
> You need to read into the 1000 / 1001 math for 23.976 and 29.97.
> 
> Hth,
> Bouke

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?

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?

Thanks again.