Recs for using MTS files in FCP X?
I have a card that got corrupted but I was able to save MTS files. I wanna use these clips in a FCP X movie? Recs on how to do that? Should I convert to Pro Res first?
You can import MTS files directly.
If you find that they aren't working you can always optimize the within FCPX. Win, win.
[Noam Osband] " I was able to save MTS files. I wanna use these clips in a FCP X movie? Recs on how to do that? Should I convert to Pro Res first?"
In general FCPX can import and edit the files in native format without transcoding. However AVCHD-format files are re-wrapped automatically during import, hence the "leave files in place" option is greyed out. If the same .MTS files are removed from the AVCHD file bundle, they can be imported with "leave files in place".
I have seen some excessive I/O problems on very large libraries (about 3.5 terabytes, 7,000 clips) apparently caused by a small group of .MTS files which were imported with "leave files in place". The majority of content in this library was H.264 1080p and 4k, with only a few hundred .MTS files. This problem manifested as very sluggish, halting thumbnail generation in the Event Browser in filmstrip mode when scrolling down. In some cases it would halt for 30-60 sec.
During this phase, the command-line Dtrace utilities bitesize.d and iopending indicated a huge number of small I/Os were being done against the .MTS files and associated Info.plist files. The mean I/O size was about 12KB, but the I/O histogram showed many were 4KB. When the .MTS files were deleted from the library and externally re-wrapped using the 3rd-party EditReady utility, then reimported with "leave files in place", the I/O problem went away.
I don't recollect seeing this on properly-packaged AVCHD files but the above problem only became obvious in a huge library. It might exist in smaller libraries but go unnoticed. OTOH, it might only happen with bare .MTS files, not those properly contained in the AVCHD bundle.
I don't know if importing them and transcoding to proxy or optimized media would have avoided this. In general proxy is roughly the size of the original H264 content (1/4 total res but 1/4 the compression). Optimized media is about 8x the size so that would normally increase the I/O load. Even on this huge library, skimming the content was pretty fast. Hardware: 2015 top-spec iMac 27, 16TB OWC Thunderbay 4 in RAID-5.
It is conceivable the MTS files were somehow being dynamically re-wrapped each time the Event Browser needed to show their thumbnails, and maybe that caused excessive I/O.
Of course the best practice is don't copy the MTS files out of the AVCHD bundle, but this is commonly done.
In general I would recommend externally re-wrapping AVCHD media using ClipWrap: http://www.divergentmedia.com/clipwrap, EditReady: http://www.divergentmedia.com/editready, or the free utility ReWrapAVCHD: https://www.macupdate.com/app/mac/39800/rewrapavchd
I have never used ReWrapAVCHD but it supposedly works. I have used ClipWrap and EditReady many times and they work great.
Note the Dtrace utilities cannot be used starting with El Capitan unless System Integrity Protection is first disabled: http://apple.stackexchange.com/questions/208762/now-that-el-capitan-is-root...