AVCHD file Rewrapped to .mp4 in Shutter Encoder Jitters badly in FCP 12

[Ian Brown]

I don’t have any problem with normal AVCHD files. They have always worked perfectly on my Intel iMacs in the past and the M2 and M4 minis I use now.

FCP 12 handles them perfectly so long as I don’t rewrap them.

[Jeff Alldridge]

Late to this one, but it’s a good puzzle and I think it’s fixable without re-encoding anything.

I grabbed the .mp4 you posted on the 12th, the one you flagged as the dodgy upload. That’s actually the useful one, since it’s the file that misbehaves.

Good news first. The timing is clean. 552 video samples, all exactly the same length, dead constant. So this isn’t ragged timestamps or a variable frame rate, which is where I’d usually start looking.

The problem is that those 552 samples only decode to 276 pictures. The stream is field coded, so each field got stored as its own sample instead of the pair being packaged as one interlaced frame. The sample table says 50 pictures per second. There are 25.

That’s the judder. Final Cut believes the container, lays 552 half-pictures on the timeline as though they were whole ones, and you get what you’re seeing. QuickTime, VLC, and Resolve decode the stream and pair the fields themselves, so they never notice the sample table is wrong. And your .mts has no sample table at all. A transport stream is just a stream, and the decoder pairs fields as it goes. That’s why the original imports fine and the rewrap doesn’t.

It also explains the thing that was nagging you. Progressive footage off the same camera rewraps fine because there’s one picture per sample. Nothing to pair, so nothing to get wrong. This isn’t Final Cut being weird about AVCHD. It reads your AVCHD fine. It’s this particular rewrap.

And it explains both workarounds. The ProRes transcode read the already-split file, so it just re-encoded the bad interpretation. The H.265 version went back to the original and almost certainly deinterlaced along the way, which is why it looks right and also why it isn’t quite the same footage anymore.

Now the annoying part. I tried a few stream-copy routes to get those fields paired back up, including a round trip out to a transport stream and back. None of them worked. A copy moves packets one for one, so once they’re split they stay split. One route quietly dropped two frames, which tells you something about how much to trust it. So this particular .mp4 is a write-off. The pairing decision got made when Shutter Encoder wrote it.

Worth digging around in Shutter Encoder for a setting that controls how it packages interlaced streams, since the run that matters is straight from the .mts. If there isn’t one, I’d keep the .mts and call it done. For what started all this, the rewrap only saves you the transport stream’s packet overhead, a few percent. Thin prize for giving up a format Final Cut already reads.

If you want to check a file yourself:

ffprobe -v error -select_streams v:0 -count_frames \
  -show_entries stream=r_frame_rate,nb_read_frames,duration \
  -of default=nw=1 yourfile.mp4

Divide nb_read_frames by duration. If you get 25 while r_frame_rate says 50, that’s this.

One warning. Don’t use ffprobe’s field_order to diagnose it. I checked it on a source file, a rewrap, and a full re-encode, and it said “tt” every time. It reads the H.264 headers rather than the container, so it’ll tell you everything’s fine while Final Cut clearly disagrees.

Full disclosure, I hit this same wall a while back and ended up building a Mac app for it. It doesn’t fix your file either. I ran yours through before posting to check, and it normalizes the timebase but leaves the field pairing alone, so it came out the same shape it went in. Figured I’d tell you what I actually found instead of what I’d have liked to find.

00057-mts.mov 22 MB Quicktime - Click to view

• Copy Download Link

[Jeff Alldridge]

@Devrim, I owe you a thank you. I’ve been working on a Mac project that prepares footage for Final Cut, and your replies here ended up fixing three things in it.

Start with the missing sound on your MOV rewrap, because that one is crazy. A transport stream labels its AC-3 audio with the tag “AC-3”, in capitals. A straight rewrap copies that label into the MOV, and Apple’s apps only recognize “ac-3”, in lowercase. So the audio is sitting right there in the file, completely intact, and QuickTime and Final Cut play silence over characters being in the wrong case. I kid you not.

If you rewrap with ffmpeg, one flag fixes it:

ffmpeg -i 00057.MTS -c copy -tag:a ac-3 00057.mov

I checked it on Ian’s clip with afinfo, Apple’s own audio tool. The plain rewrap reports 0 frames per packet, which is Core Audio saying it can’t make sense of the stream. With the flag it reports 1536, exactly right for AC-3.

The judder is a different animal. I measured the MP4 Ian posted: 552 samples, all exactly the same length, but only 276 pictures inside. The rewrap stored each interlaced field as its own sample, so the file tells Final Cut it’s 50 frames a second when it’s really 25, and Final Cut lays half-pictures on the timeline. QuickTime and VLC pair the fields up on their own, which is why they never noticed. There’s no flag for that one. A stream copy moves packets one for one, so once they’re split they stay split.

And the slowness you saw with MTS files in Final Cut is very likely the file not saying where its complete pictures are, so Final Cut decodes forward from the START of the clip every time you scrub or step back a frame. It re-reads the WHOLE thing.

All three went into an update of that project this week, and I only chased them down because you took the time to download Ian’s file and test it yourself. So thank you, genuinely.