MTS Files really slowing FCPX down, even with proxy

Yup - that's where I'm leaning too. And I can reconnect, but it seems I have to do it one by one. about 300 clips - not the worst job I've ever had.

definitely not normal, but that was what I noticed when dealing with extracted AVCHDs as well.

(

In regards to long verification, not reconnecting one at the time)

I actually feel ClipWrap was a good suggestion as the one clip I tested it with works faster (nothing scientific here, but I seem to notice that the thumbnail filmstrip loads faster). I just don't want to throw $50 for a one time fix. Might be worth it though. I have a lot of editing to do!

Do you have any other programs that can re-wrap an .MTS? Premiere? :dry:

I do have Premiere! I will try that. *Times when a CC subscription comes in handy *

Well that's a first...

I really need to learn Premiere, just because I believe an editor should have all the tools and this doc I'm on was first started in Premiere before the editor left for an opportunity he couldn't pass up. I've transferred everything (except those MTS files) perfectly... but still I should probably learn all the tools I pay for. My problem is that I haven't found any tutorials as good as those from Ripple and I haven't found a community as awesome as fcp.co for premiere This is one of the few places I can go where people generally don't moan and belittle others with problems.

I don't have much MTS material because we either shoot other formats or use ClipWrap to convert.

However I found about 32 old 1080i/60 files from a Canon HF100 (about 2 GB total). These were separate from the original AVCHD container. Test results:

(1) Import using un-optimized and leave in place -- they worked mostly OK. Rapid JKL manipulation was a little laggy on my 2013 iMac 27 with 3.5Ghz i7, 32GB RAM, 3TB Fusion Drive and 8TB Pegasus R4 RAID5 array.

(2) Re-wrap with ClipWrap and re-imported without optimization and leave in place. Same thing -- mostly OK, a little laggy.

(3) Re-imported MTS files using optimized media option (no proxy). JKL editing was very fluid and fast, with no lag.

(4) Re-imported MTS files using proxy media (not optimized). It was better than non-optimized, no proxy, but not as smooth as optimized. I don't know if that's normal -- just reporting what I observed.

I don't think you ever said whether you've tried optimized media, or just proxy.

It takes a while to optimize a lot of material on import but if you haven't tried that maybe it's the best solution.

However even the above worst case -- MTS "leave in place", non-optimized, no proxy -- it was still usable just somewhat laggy when making very rapid JKL edits.

Agree with ronny , FCP X can handle this MTS files , it not , then try to convert them into Apple Prores and reload them again.....

I have the same problem with FCPX and MTS files from a Sony Handycam. FCPX is almost unusable. And this is on two different systems. Started using Clip-Wrap and I can finally get my work done on time.

JT

Similar issue here. MTS files were used by another editor for import and to make an edit. FCP X (10.3.4) is painfully slow working with these files on a 5K iMac. I tried using EditReady to wrap those files into mov instead, but I can't reconnect the files.

Rewrapping was the easy part. I can't reconnect so it's a no go.

tangierc wrote: Similar issue here. MTS files were used by another editor for import and to make an edit. FCP X (10.3.4) is painfully slow working with these files on a 5K iMac. I tried using EditReady to wrap those files into mov instead, but I can't reconnect the files...I can't reconnect so it's a no go.

There is a significant I/O performance problem in FCPX when dealing with extracted AVCHD .MTS files which are imported with "leave files in place". This problem may not appear at smaller library sizes -- I'm not sure what the threshold is. However at larger library sizes it can dramatically slow down Event Browser operations if using "filmstrip" mode. If switched to list mode it doesn't seem as bad. I'm not sure how it affects timeline performance, as it is so bad in the Event Browser I usually notice and correct it before the content is tagged and ready for the timeline.

I examined FCPX I/O patterns with the command-line Dtrace utilities bitesize.d, iosnoop and iopending. When scrolling down the Event Browser in filmstrip mode, the I/O histogram from bitesize.d and file access data from iosnoop shows an excessive number of small I/Os. Removing and re-wrapping those MTS files with EditReady eliminates this. It seems that transcoding to proxy or optimized media may also avoid this, but this essentially requires proxy files for all imported media, otherwise you can't easily browse library content. This behavior is AVCHD-only, I have not seen it on XAVC-S.

Likewise importing the AVCHD content without using "leave files in place" will automatically re-wrap the files, which seems to avoid the problem whether you use proxy or not. However I've seen a few reports which claim otherwise.

Unfortunately once the data is imported and work is committed (whether metadata tagging or timeline work) there is no way to externally re-wrap those files and preserve the work. There are two levels of pointers to media files within the library. The visible pointers called symlinks which are simply pathnames to the external files. One level above that there is a series of pointers and data structures to the symlinks and those have the file attributes such as filename, audio config, etc. If any of those attributes differ from the media file, relink will fail. There is no way to access or change those.

Tangier, in your case the best option is transcode the "in place" .MTS files to optimized or proxy media, then evaluate the performance. This preserves the work done and may solve the performance problem.

The lesson is never, ever import bare AVCHD .MTS files "in place". Even a few "in place" .MTS files sprinkled throughout a large library of mostly non-AVCHD media can degrade Event Browser performance. I personally prefer externally re-wrapping .MTS or AVCHD files with EditReady before import.

Thanks for the detailed explanation. It was something that the editor hadn't encountered before and effectively just thought that any file can be imported if FCP X will allow it. I learned the hard way many years ago.

Generally we use EditReady to preprocess all of our [AVCHD] files and for unique file naming. It's a shame we have to and can't do it inside FCP X, but that's mostly because any custom naming is bound to the FCP X database and not the file name in the FINder as was possible in FCP 7.

I ended up doing what you suggested anyhow - transcoding in place the ones that were committed to a project. The ability to transcode files or even rewrap the mts files to mov and relink to those would be amazing. Oh well. moving forward.