If they're Canon MXFs, my suspicion is that they're 422 color space XDCAM files and that our fallback importer isn't doing a very good job of handling them. I'm actively working on improving 422 MXF support in the next version, so if you have a short sample file that you can upload somewhere, I'd like to take a look & confirm the issue (and test against the new implementation).
In the meantime, you might check to see whether you can find an option on the camera to shoot in 420 color space (as that goes through a different importer), or else find a way to rewrap these files to a different format.
Thanks. I can certainly create a short clip. How long do you need?
Should I assume it's the same case for Sony XDCAM HD 4:2:2 audio looping bug? No fix for this before CS6?
@ExactImage: I think 20 seconds would be plenty - enough to evaluate the playback without being fooled by frame caching.
@Roberio: I don't speak for product management, but in my opinion, probably not. Reason being, our 422 MXF support in CS 5.x was not directly implemented by us, it goes through Main Concept components. Consequently, to get a fix, we'd need to take a new drop of the Main Concept SDK. This impacts not just 422 MXF support, but all MPEG support in the product, so it's a more risky proposition, one that generally doesn't happen in a dot release. Evaluating a new SDK drop is something that normally happens during a regular product cycle.
I can vouch that the audio looping bug is gone in CS6, as I was asked to test a file with this problem against my implementation. Going forward, our 422 support will be easier to maintain, as we do all the file handling/container navigation, and only rely on using the Main Concept SDK for the actual essence decoding, so we'll have more control for fixing issues such as the looping audio bug.
Thank you very much for the plain answer. We will plan accordingly.
By the way, in our tests Sony XDCAM HD 420 (aka HD HQ / 35Mbps) did not present the problem.