Blackmagic Forum

Hi guys,

I'm entirely new to the Da Vinci Resolve Lite's workflow and I have been using Magic Bullet Looks for my color grading up until now.

Though Resolve Lite is an awesome piece of software and definitely much better than Magic Bullet, to incorporate it into a Premiere CS6 workflow is such a pain.

XMLs don't work properly, you have to bake in the video and use scene detection to cut it all up again.

Is it really that worth it to use Resolve Lite instead of Magic Bullet Looks for an all H264 DSLR project?

Thanks.

Color grade in resolve first then edit in your NLE? No need to scene detect if you make the "scenes" after the grade.

I work with Raw and dont even use xml or proxies of any kind.

That makes sense... but still my main issue here is this -

Is it worth taking the extra steps just for a pure H264 workflow? I know Resolve is a go to when working with Raw but I rarely handle Raw footages since these aren't big projects. Everything is shot on a DSLR.

surfgn wrote:That makes sense... but still my main issue here is this -

Is it worth taking the extra steps just for a pure H264 workflow? I know Resolve is a go to when working with Raw but I rarely handle Raw footages since these aren't big projects. Everything is shot on a DSLR.

I can suggest something that will guaranty issue free XML workflow. Buy a QT Change from these guys:
http://www.videotoolshed.com/product/42/qtchange
It allows for writing of the non repeatable timecode and also reel names into your DSLR .mov files. This allows for trouble free round tripping between NLE and resolve using XML.
In my case I use ffmpeg bat scripts to rewrap mts wrapped h264 into .mov wrapper.
Just don't forget to clear your NLE cache and re-output the XML file first.
Conforms with no problems every time.

Dmitry Kitsov wrote:

surfgn wrote:That makes sense... but still my main issue here is this -

Is it worth taking the extra steps just for a pure H264 workflow? I know Resolve is a go to when working with Raw but I rarely handle Raw footages since these aren't big projects. Everything is shot on a DSLR.

I can suggest something that will guaranty issue free XML workflow. Buy a QT Change from these guys:
http://www.videotoolshed.com/product/42/qtchange
It allows for writing of the non repeatable timecode and also reel names into your DSLR .mov files. This allows for trouble free round tripping between NLE and resolve using XML.
In my case I use ffmpeg bat scripts to rewrap mts wrapped h264 into .mov wrapper.
Just don't forget to clear your NLE cache and re-output the XML file first.
Conforms with no problems every time.

Thanks! I'll give it a shot and see if I face any problems.

As said .h264 footage from a DSLR does not have proper timecode.

You are better off transcoding the footage to DNxHD or ProRes and applying time code at that point.

The the workflow issues should be sorted. Resolve will also perform better as its not having to decode .h264 on the fly.

I posted this Mac workflow a little while back regarding AVCHD in FCPX and Resolve:
http://www.adamroberts.net/blog/a-workf ... d-resolve/

Tho it does not cover the time code issue this can be dealt with if you transcode with ClipWrap or 5DtoRGB.

H.264 by definition cannot have a timecode, neither can dnxhd nor ProRes. However .mov wrapped dnxhd, ProRes and h.264 can. Timecode is a part of the container architecture and currently supported best by QuickTime .mov wrapped files. There are special cases (Cineform) that are generally not compatible with QuickTime architecture and relies on API and API use by software companies to support timecode and other metadata features. This is of course different for tape based media.
One of the reasons I suggest not transcoding and rather rewraping files or leaving them as camera original .mov is to preserve maximum original signal. I have not had any issues with camera produced h.264 files be that .mov, .mts or mts re-wrapped to .mov files in the last 4 years. Computers are that fast now, given you do not edit in Fcp 7 or earlier. I that vase no amount of processing power will help you with performance.

adamroberts wrote:As said .h264 footage from a DSLR does not have proper timecode.
You are better off transcoding the footage to DNxHD or ProRes and applying time code at that point.

The the workflow issues should be sorted. Resolve will also perform better as its not having to decode .h264 on the fly.

I posted this Mac workflow a little while back regarding AVCHD in FCPX and Resolve:
http://www.adamroberts.net/blog/a-workf ... d-resolve/

Tho it does not cover the time code issue this can be dealt with if you transcode with ClipWrap or 5DtoRGB.

You can use Magic Bullet Grinder (or perhaps MagicBulletProof) to generate TOD timecode dailies from your H264 camera originals. I usually make a duplicate of the files, and then run Grinder to rename the files and inject timecode. At that point, I run Dualeyes to sync external audio to these newly created TC files. At this point, you can bring these into your editing software and the XML handoff to Resolve will work correctly.