Creative Communities of the World Forums

The peer to peer support community for media production professionals.

Activity Forums DaVinci Resolve Add Source Frame Count To Filename Issue

  • Add Source Frame Count To Filename Issue

    Posted by Ben Harris on March 26, 2018 at 1:26 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 https://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

    Marc Wielage replied 8 years, 1 month ago 3 Members · 3 Replies
  • 3 Replies
  • Tero Ahlfors

    March 26, 2018 at 1:39 pm

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

  • Ben Harris

    March 26, 2018 at 1:47 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?

  • Marc Wielage

    March 30, 2018 at 8:49 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.)

We use anonymous cookies to give you the best experience we can.
Our Privacy policy | GDPR Policy