FORUMS: list search recent posts

Add Source Frame Count To Filename Issue

COW Forums : DaVinci Resolve

<< PREVIOUS   •   VIEW ALL   •   PRINT   •   NEXT >>
Ben Harris
Add Source Frame Count To Filename Issue
on Mar 26, 2018 at 1:26:34 pm

Hi,

I'm currently assistant editing for a documentary feature and having an issue with the export in Da Vinci as was wondering if anybody else had experienced the same issue and might know a fix for the problem.

We are using Resolve to colour in the end and so are using the round trip workflow described here http://droppedframe.com/2017/10/09/resolve-to-avid-a-dailies-workflow/ to create our proxies.

It is working fine for all our other cameras apart from the Drone (DJI) footage. When exporting Da Vinci fails to add the source frame count to filename on export. Instead of the frame count it is adding 00000 to every export. I am worried that this will prevent Da Vinci from being able to link back the footage efficiently on import once the edit is made.

If anybody can help or advise that would be much appreciated

Thanks

Ben


Return to posts index

Tero Ahlfors
Re: Add Source Frame Count To Filename Issue
on Mar 26, 2018 at 1:39:54 pm

Well the drone footage probably doesn't have a timecode track so it starts at zero.


Return to posts index

Ben Harris
Re: Add Source Frame Count To Filename Issue
on Mar 26, 2018 at 1:47:20 pm

How do I find out if this is the case? It doesn't seem to be having problems with GoPro, Z90, EVA1, A7S, FS7 footage.. but DJI don't burn in timecode metadata? Is there a way for me to do so?


Return to posts index


Marc Wielage
Re: Add Source Frame Count To Filename Issue
on Mar 30, 2018 at 8:49:00 am

My opinion is that most drone footage is problematic for post. If I'm asked by the client, my preference is for them to take 8-bit drone footage, give it a unique name with a date (like "33018_C001"), and transcode it to something simple like ProRes 422HQ with sequential non-conflicting timecode. From that point forward, consider the transcoded footage the new "negative" and only use that for offline and online.

If the drone material is 10-bit (rare) but still H.264, I would still transcode it but go to DNxHD 444 or DNxHR 444 or ProRes 444, whatever is easiest for your systems to handle. GoPros, A7S, all that stuff is just a nightmare. I recently did an A7S feature, and I'm considering a "never again" policy because of issues during that conform.

What is not a problem is if the editor opts to just render out a flattened file for color, and then all we have to do is just slice it up with scene detection, color-correct it, and hand back a finished version. That can work just fine, assuming the transcodes are done well. (Watch the levels carefully and check them on a scope just in case.)


Return to posts index

<< PREVIOUS   •   VIEW ALL   •   PRINT   •   NEXT >>
© 2018 CreativeCOW.net All Rights Reserved
[TOP]