-
MXF extreme sluggishness
I was quite happy that I could bring mxf files directly into my projects now.
Most of my editing requires me to pull mxf off of our Sony server. I used to rewrap them with Sony’s XDcam Transfer software. This saves me a step.
But wait…
I noticed frequent and lengthy beachballs whenever I would try to browse these mxf clips.
I created a project with an mxf version of the clip, and also a quicktime rewrapped .mov version of the clip.
The .mov version is nice and snappy. The mxf version gives me beachball after beachball.
Here are the facts. The clip is 20 minutes. It’s xdccm 35 codec. The .mov version is rewrapped, not transcoded.
Simply scrubbing the clip in the browser: the .mov clip plays immediately, the mxf clip will lag a few seconds, but it seems that it lags mostly if I’m trying to play a latter portion of the clip.
I should also note that the mxf clip has 8 channels of audio, and the .mov has 4. We shoot with 4 audio channels recording, but the server adds an extra four, even though 5-8 are totally blank.
Someone may have a detailed explanation about how .mov and mxf work differently with av foundation.
Anyone else having issues with raw mxf?
It takes a lot of the luster off the jewel, if mxf files don’t perform as well as .mov files.
———
Don’t live your life in a secondary storyline.Mark Morache
FCPX/FCP7/Xpri/Avid
Evening Magazine,Seattle, WA
https://fcpx.wordpress.com -
10 Replies
-
I’ve been using MXF in FCP7 and FCPX for a very long time (first with MXF4mac, and now with Apple). I don’t see the sluggishness.
However, I don’t use XDCam 35. I mostly use AVC-I and XAVC. I’d send feedback to Apple.
-
Have you done any comparison with media on local drives? It could be server-related.
Oliver
Oliver Peters Post Production Services, LLC
Orlando, FL
http://www.oliverpeters.com -
I pull everything off the server and edit on an internal 1tb secondary drive on my MBP.
The only difference is that I generally rewrap the mxf. When 10.1.4 came out I started bringing the mxf files directly into FCPX, but noticed the sluggishness and wondered if the performance was different between the rewrapped mxf and the raw one.
I suppose it’s possible the 8 channels of audio might be slowing things down. I often wonder how FCPX deals with waveforms when I’m turning tracks on and off in the event browser, and FCPX has to redraw a 20 minute clip.
That’s why I was wondering if anyone else was having any issues.
———
Don’t live your life in a secondary storyline.Mark Morache
FCPX/FCP7/Xpri/Avid
Evening Magazine,Seattle, WA
https://fcpx.wordpress.com -
The files I use are routinely 8 channels of audio as well. I usually turn off what don’t need in the inspector.
As a test, if you optimize the MXF files, does it get any better?
-
Also, it may not be a bad idea to trash prefs, and perhaps the cache.
-
I just made a few over 20 minute 8ch XDcam 35 HD clips and they all perform flawlessly.
You don’t have any other MXF software on the machine do you? Demo or otherwise?
-
No other mxf software on my computer.
I’ll keep doing experiments with the native mxf files.
I find that there seem to be activities that FCPX does under the surface that don’t show up in the background processes. Occasionally my fans will kick in like the app is doing something in the background, even though the background process indicator shows it’s resting at 100% done.
Then when I close the app, I’ll get a warning that background processes are underway, even though there’s no indication of anything running in the background.
Perhaps this is some extension of that issue.
I’ll keep experimenting, since no one else is having any issues with the native mxf files.
-Mark
———
Don’t live your life in a secondary storyline.Mark Morache
FCPX/FCP7/Xpri/Avid
Evening Magazine,Seattle, WA
https://fcpx.wordpress.com -
If that’s the case, I would certainly trash prefs and reset your cache.
I don’t know what those hidden processes are either. I thought it may have been the auto save loop that was supposed to have been fixed in this release.
Since it seems to be related to this one file of yours, I’d trash the entire cache bundle and rebuild the cache and see if that helps.
-
[Jeremy Garchow] “I don’t know what those hidden processes are either. I thought it may have been the auto save loop that was supposed to have been fixed in this release. “
I have a sneaking suspicion it’s somehow related to analyses/waveforms or something. I occasionally see the waveforms redrawing sluggishly (or not at all) which is solved by a relaunch. It seems these phantom BG processes are always running when I quit in this situation.
Or not… 🙂
————————————————————-
~ My FCPX Babbling blog ~
~”It is a poor craftsman who blames his tools.”~
~”The function you just attempted is not yet implemented”~ -
I keep all my FCPX Caches in one folder on the boot drive (which are now all SSD no matter what machine I’m using). Now that X puts all of the cache in a convenient package, it as easy as going in to the one folder and trashing any cache all at once. It seems to work well.
I haven’t seen these types of redraw slow downs in a while.
Reply to this Discussion! Login or Sign Up