AVCHD stutter bug or camera specific issue?

[John Rofrano]

[James Culbertson] ” I just read about the earlier AVCHD stutter playback bug from (I assume) an earlier version of FCPX 10.4.X but since I am able to fix this stutter by transcoding perhaps it is camera format specific?”

I have seen different manufacturers “interpretation” of AVCHD differ. The problem is that MPEG4/AVC is an extremely broad specification and AVCHD was an attempt to subset it to make it easier to get compatibility but unfortunately, even within the smaller AVCHD subset there are differences because camera manufacturers interpret the spec differently.

[James Culbertson] “I’ve never worked with 59.94fps before so could also be related to that?”

One test you can do is record 29.97 from the same camera and see if that plays back smoother. It very well could be because you are pushing twice as many frames through at 59.94 and that is what’s causing the stutter. You said that switching to Better Performance solved the problem. Dropping frames is something the Better Performance uses to get smoother playback so it may be the frame rate. If 29.97 still stutters, then it’s probably an incompatibility with that camera’s files. Just transcode them.

~jr

http://www.johnrofrano.com
http://www.vasstsoftware.com

[Joe Marler]

We have a DVX200, but we never use AVCHD but the UHD 4k/29.97 .mp4 format. To me AVCHD is a hassle because (1) FCPX cannot import using “leave files in place” (without causing problems), and (2) The re-wrapped files are copied into the library which prevents “lean library” media management (3) AVCHD appears as a bundle at the Finder level, and (4) It’s 1080p only, not 4k.

If you are copying the .MTS video files out of the bundle and importing those using “leave files in place”, that should never be done on FCPX and may cause I/O performance problems. This is apparently due to FCPX trying to repeatedly re-wrap the .MTS files upon each reference, which causes a huge number of small random I/Os. FCPX needs to statically re-wrap the AVCHD content once during ingest, or else you need to re-wrap it using EditReady. If the AVCHD media is externally re-wrapped using EditReady, then (and only then) can they be safely imported using “leave files in place”.

AVCHD is a variant of H.264 and the 2013 Mac Pro does not have Quick Sync to accelerate decode/encode of this. Normally it’s no problem for 1080p but maybe the specific 60 fps AVCHD flavor is causing a performance problem.

The DVX200 won’t do UHD 4k at 60 fps, only DCI 4k (2160p). All our other cameras are shooting UHD 4k at 29.97, and even though DCI 4k is only a small compositional change in post it’s easier to keep them the same. Also 4:2:0 8-bit 4k (whether DCI or UHD) can theoretically be transcoded to 10-bit 4:4:4 1080, so shooting 4k gives better quality for 1080 distribution. More info: https://pro-av.panasonic.net/en/dvx4k/pdf/ag-dvx200_tech_brief_vol1_en.pdf

[James Culbertson]

[Joe Marler] “To me AVCHD is a hassle because”

It’s low budget at this point, and they decided to go with 1080p AVCHD to match the resolution limits of the C100 mkII. It’s fine for this project, the footage looks good. While I would avoid AVCHD if I could, in practice I have never had any issues importing and working with AVCHD natively. I’ve not needed to transcode for a couple of years up to this point. I’m assuming it is the 59.94 that is causing the dropped frames, in any case, I only need to transcode the DVX200 footage as the rest is playing fine as usual.

For shorter projects (30 minutes or less) with no more than 25-35 hours of source footage, I tend to just import all footage into the library. Never had any issues with such Libraries.