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

MediaMouth communque at gmail.com
Fri Apr 14 18:11:30 EEST 2023



> On Apr 14, 2023, at 07:18, Bouke / Videotoolshed <bouke at videotoolshed.com> wrote:
> 
> 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.

Thanks Bouke,

Yeah, so my use of the term "subclip" and the fact of re-importing them into Avid gives the impression of building a process external to Avid where it already has built-in capabilities.

In fact, this is part of a VFX workflow, and the destinations are all external to Avid: file transfer services, VFX trafficking software, reporting applications, archival folders, etc. The only reason the "subclips" are getting imported back into Avid is for testing and workflow integrity checks.  While technically, yes, you could do all these steps inside Avid, it's not particularly efficient; it's a closed box, no API -- any systematic work -- naming conventions, etc -- needs to be done manually.

Basically the goal here is to export one large DNxHD36 file + one EDL -- 2 total ingredients -- and from there push a button to release a kraken of automation:
	- The large export file goes to a facility.
	- The subclips described here are named according to a rigorous convention and uploaded to a VFX tracking service
	- Thumbnails (defined by markups in the EDL) are generated and uploaded to an online reporting application
	etc etc.
Most of this pipeline is already built.  If we get this sub-clipping idea under control it'll improve the workflow & accuracy that much more.


>> 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!)
Yes, exactly.  If we get this to the point where everything's working but for a single tail frame too short or long, I'll be thrilled.

> 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?
Importing is for testing purposes only, as mentioned above.  But to answer the question, importing (fast)

> What does Resolve do with them?
> Etc etc….
> 
> Bouke
> 


More information about the ffmpeg-user mailing list