If you've ever worked with AVCHD and Resolve, you've almost certainly found that the two do not get along. Resolve cannot (will not) read AVCHD in its native mts wrapper. This can complicate the color process in post. To get around the issue you can rerender to a more compatible codec (ProRes or DNxHD typically) or you can simply rewrap the files to MP4 which saves time and HDD space.
I recently graded a project that shot on both the BlackMagic Cinema Camera 2.5K and the Sony FS700. The BMCC shot log to ProRes and the FS700 shot its native AVCHD. The editor cut the music video within Premiere which handles AVCHD and ProRes natively. He did not transcode (as he had no reason to) which of course introduced compatability issues when the MTS files hit Resolve.
The video had a rushed turn around time so I opted to rewrap instead of rerender (which only takes a couple seconds per clip).
To automate the rewrap I used the open source ffmbc (a professional codec oriented customization of ffmpeg) library automated with this batch script (Windows only) I adapted from a forum online (I've since lost the link). As an aside, you should never run random batch scripts unless you are absolutely certain as to what they do.
The batch runs from the folder you have the files you want to convert in (the MTS source folder). Upon running, the program creates two new folders, one called "mts" and one called "mp4." It proceeds to rewrap the .mts files into .mp4 containers (which Resolve will read) and moves the files (old and new) into the respective sub folder (mts or mp4).
The batch script looks as follows:
DO ( md mts md mp4 ) for %%f IN (*.mts) DO ( "R:\ffmbc\ffmbc.exe" -i %%f -vcodec copy -acodec aac -strict experimental -ab 512k %%~nf.mp4 ) DO ( move *.mp4 "mp4\" move *.mts "mts\" )
Let's break this down.
The first portion (
DO (md mts md mp4)) creates two new folders named "mts" and "mp4" within the folder the batch file is run from.
The middle section is the actual rewrap, file creation, and naming. The first section (
for) takes the file name before the mts, sets it aside, and tells the
DO to run for each mts. The middle section needs to have the correct location of where you unzipped the latest ffmbc package (in my case I had it in a folder named ffmbc in the root of my
R: drive). The command after the file location tells ffmbc to actually do the encoding. The keye here is
-vcodec copy which copies the video stream exactly (ensuring no degradation or quality loss).
-acodec converts the audiostream to MP4 compliant aac.
DO section moves the new and old file to the folders we created within the first
After the batch runs, you should be left with a folder that only holds the batch file, MP4 folder (with rewrapped files), and MTS folder (with the original files).
To physically create this batch, just open Notepad and paste in the code (only after you understand it), edit the path to your ffmbc exe, and save the file as
MTStoMP4.bat. Drop in the folder, run, and you should be rewrapped in no time. From there, Resolve will import the MP4's with no worries.
For those of you scared of batch files, there is a free exe utility I have not tried which comes highly recommended (be sure to click on WinRewrap in the sidebar). It will even update your XML with the new filenames so you don't have to tell Resolve to ignore file extensions/update the XML yourself.
Naturally, not all the clips rewrapped simply. The project was partially media managed which managed to mangle the timecode of a good portion of the FS700 shots (and broke the rewrap of a couple selected clips). These clips needed to be rerendered (I went with ProRes 422HQ) before import. The issue was that I could not get any program to correctly recognize the timecode of the files thus breaking the relink upon import.
Most MTS files handle timecode very poorly. Outside of a few cameras, the metadata (timecode, reel, etc) are recorded outside of the files themself in all those "extra" files the cameras create in the folder structure (XMP's, etc). People often delete these files, fail to copy them over, or (in my case) they're lost in file transfers and media mangement.
I had no timecode to link to at all and did not want to manually sync all these clips. I was looking at the problem MTS files in a couple different players when I realized they were showing two different timecodes depending on which player I was using. It seems the media management did embed the proper timecode but it some programs were reading the new file created time/date (which was the time of the media management command) as the starting code instead.
I found the tool ClipToolz Convert read the timecodes correctly but was unable to actually convert anything. Beyond that, the program is just a GUI interface for ffmpeg with a little customization thrown it, but charges a fee in violation of the ffmpeg license (GNU GPL).
Legal issues aside, the software would load the MTS files and display the correct timecode. I then took this timecode and manually entered it as the starting timecode in EyeFrame Converter (another ffmpeg GUI but one that follows the license). EyeFrame makes it easy to embed TC and RN into the converted files and in fact can read the correct timecode itself in most cases (though in this case it was reading the incorrect "file created" modifier instead).
After manually entering the timecode for each of these files and converting, the files synced perfectly in Resolve and I had no further issues (beyond client revisions naturally).