End of support for interlaced H.264 since FCP 12.2 / Compressor 5.2

Question

Level 1

42 points

End of support for interlaced H.264 since FCP 12.2 / Compressor 5.2

Hello,

Since Final Cut Pro 12.2 and Compressor 5.2, exporting to interlaced H.264 is no longer supported. Any previously created presets are now disabled. This is a huge regression, as it is no longer possible to have a native end-to-end workflow for footage recorded on 50 Hz AVCHD camcorders sold in Europe. It would seem that Apple has decided to focus the Final Cut suite on TikTok or YouTube "content creators."

My workflow used to be: import AVCHD files into Final Cut, edit, and export a ProRes 422 master at 1920x1080 25 fps interlaced TFF (exactly matching the source). I would then compress it to H.264 using Compressor, keeping the resolution, interlacing, and frame rate identical. It was also possible to export directly to interlaced H.264 from FCP using the Compressor preset. From there, I could either author a Blu-ray (which I stopped doing) or simply put the H.264 file on a USB drive to watch on a TV. This yielded the best playback quality I found, as the TV is capable to synchronize at 50 Hz. Every attempt to deinterlace to 60 Hz for viewing on computer screens or devices failed due to severe quality degradation. As you can imagine, I was very attached to this workflow, which is now ruined.

Have you run into the same issue, or perhaps found a solution? My only lead so far is testing DaVinci Resolve to see if this alternative Mac software (available in a free version or for €350) still supports encoding my ProRes masters to interlaced H.264. However, that represents significant complexity and a steep learning curve that I am quite reluctant to take on.

Thank you!

HomePod mini

Posted on Aug 9, 2026 10:43 AM

Reply

Answer 1

Top-ranking reply

terryb

Level 4

3,682 points

Aug 9, 2026 4:28 PM in response to Stephan-S

ffmpeg? https://ffmpeg.org You could make an automator or folder action that calls a bash script.

Claude says,

Replace the Compressor step — encoding the master to interlaced H.264:

ffmpeg -i master.mov \
  -c:v libx264 -profile:v high -level 4.0 -preset slow \
  -x264-params "tff=1" \
  -crf 18 \
  -c:a aac -b:a 320k \
  -movflags +faststart \
  output.mp4

-x264-params "tff=1" is the whole trick — it puts x264 in interlaced mode, top field first, and the 1920×1080 / 25 fps pass through unchanged from the ProRes master. Level 4.0 covers 1080i25.

One thing worth adding since ProRes doesn't always carry the field-order flag reliably through every tool: assert it explicitly on the input side so x264 and ffmpeg agree. You can do that with a filter:

ffmpeg -i master.mov \
  -vf setfield=tff \
  -c:v libx264 -profile:v high -level 4.0 -preset slow \
  -x264-params "tff=1" \
  -crf 18 \
  -c:a aac -b:a 320k \
  -movflags +faststart \
  output.mp4

The setfield=tff and tff=1 are belt-and-suspenders — the filter stamps the field order on the decoded frames, the x264 param tells the encoder to code them interlaced TFF. If your ProRes master already has field_order=tt, the filter is redundant but harmless. Check the ProRes master field order with:

ffprobe -v error -select_streams v:0 \ 
-show_entries stream=width,height,r_frame_rate,field_order \ 
-of default=nk=1:nw=1 master.mov

If you want to match a Compressor bitrate target rather than CRF quality, swap -crf 18 for -b:v 20M -maxrate 25M -bufsize 25M or whatever your delivery spec calls for.

Reply

Answer 2

Stephan-S Author

Level 1

42 points

Aug 10, 2026 10:50 PM in response to terryb

Success! I only got the error below (because ProRes 422 has 4:2:2 chroma subsampling whereas H.264 @High expects 4:2:0)

x264 [error]: high profile doesn't support 4:2:2

... that I was able to overcome by adding the option -pix_fmt yuv420p

Output video attributes were correct as checked with MediaInfo, and I was able to view the smooth and crisp compressed footage on my TV, so this works end-to-end.

Interestingly, I found success also with HandBrake (vs past failures) with same settings overall, no deinterlacing, and entering the same tff=1 in the encoder options box. I think I'll further explore that path now that it's proved valid because it's a bit, well, more user-friendly ;-)

So sorry I have to let go of Compressor, but I might try it later this year when hopefully I buy a new Mac because on Apple silicon there's a new retiming setting with "bidirectional optical flow" that might help me convert my 50 Hz edited footage to 60 Hz. The previous years-old optical flow exhibited unacceptable occlusion artifacts.

Anyway, thanks a lot for your help! It's a pity ffmpeg and x264 documentation is such an undecipherable maze (very undocumented actually) but we now have the LLMs to make sense of it all, don't we.

Reply

Answer 3

BenB

Level 6

13,698 points

Aug 9, 2026 12:47 PM in response to Stephan-S

Take a look at HandBreak, it'll do what you need, easier, faster.

https://handbrake.fr/

Reply

Answer 4

Stephan-S Author

Level 1

42 points

Aug 11, 2026 2:51 AM in response to Luis Sequeira1

Yes I do and yes it is because the culprit isn't interlacing, it's the d*mn 50 Hz. The value of my TV isn't on-the-fly deinterlacing, it's the capacity to sync the display at 50 Hz - that other digital devices (desktops, laptops, iPhones, iPads) don't have, except maybe the Studio Display XDR and some MacBook Pro models, see Change the refresh rate on your MacBook Pro or Apple display - Apple Support

My footage dates back to an era when the Sony, Canon, etc had the seriously obnoxious habit of segregating their camcorders according to regions of the world (like PAL vs NTSC). Consumer HD camcorders in Europe were sold locked at 50 Hz although it was an altogether new standard that shouldn't have been held in the shackles of the obsolete PAL/NTSC divide.

And there isn't an *affordable* solution to resync video from 50 Hz to 60 Hz (while deinterlacing it for good measure as a by-product) that I know of, except perhaps Compressor's new "bidirectional optical flow" that I mentioned and haven't had capacity yet to test (my iMac is Intel). If you know a solution, please share! Otherwise you would be forgiven because I know by experience that this painful problem is very mysterious and almost unfathomable to people who have only lived with 60 Hz (ish) video footage. If you're in the US, camcorders recorded at 59.94 Hz which explains why this never showed any visible issue on 60.0 Hz digital devices (half a frame skipped every 16s or so) and people have been able to deinterlace satisfactorily by software.

Reply

Answer 5

Stephan-S Author

Level 1

42 points

Aug 12, 2026 6:11 AM in response to joema

Excellent 5* comment @joema

joema wrote: Maybe it was archival material shot decades ago.

Correct! A whole backlog of unedited exotic vacation footage spanning a number of years (don't we all have that). I've done video editing since 2001.

joema wrote: So this was not a broadcast issue, TV issue, or CRT issue.

Yes and no, not entirely true because it is also a delivery issue, even if that's delivery only to one's home or family. What's the point in shooting smooth motion and sharp detail if that's going to ruined at playback by the mismatch between frame/field rate and display refresh rate? Some may not pay attention to the judder and/or loss of detail. I do. YouTube does some reasonable conversion (I even uploaded ProRes 422 master files against YouTube blanket compression requirements), but not quite near viewing the real thing.

AVCHD didn't exist alone in a void, it was part of a broader delivery system. 576i/480i MPEG2 were meant for DVD, 1080i H.264 was meant for blu-ray, 4K HEVC was meant... (well that's the point where YouTube, Netflix, Apple TV, etc seem to be taking over distribution). And like you mentioned, the same 1080i H.264 is the basis for digital broadcast TV, at least in my country with millions of TV sets and a whole audiovideo industry, it is not a whimsically exotic format, by a long shot. Therefore I followed the delivery method that was meant for AVCHD, i.e. I authored blu-ray discs and viewed them on a 50 Hz compatible TV set. Authoring blu-rays is tedious though, so now I put the H.264 files onto a USB stick and the TV set plays them all the same.

And all of a sudden, with FCP 12.2 / Compressor 5.2, Apple decided they would stop supporting blu-ray authoring (the infamous "bag of hurt" like Steve Jobs called it), likely just because they won't spare the few dimes (comparatively) for the recently inflated blu-ray technology license costs I believe.

On this 50 Hz part of the Atlantic, it's difficult to separate video capture and delivery method if you do pay attention to motion and sharpness:

Shooting 60p can be viewed on any display, that's what I do now with my iPhone 16 Pro, it's a breeze with stellar quality both in motion and in detail.
If you've got the misfortune instead of being stuck with legacy Full HD 50i footage (not legacy at all in broadcast TV though), it's got to be delivered to a 50i capable device. That's in vast majority a TV set and there's no point reinventing non-standard delivery methods to deliver that. Hence 1080i H.264.

joema wrote: 1080p cameras recording H.264 to MP4 have been available for over 15 years

When one trusted the big names (Sony, Canon) for a camera that could handle anything you throw at it (think stabilization, sound, exposure, white balance...), there weren't so many options actually and it took a few more years while AVCHD was still dominant for consumer run&gun camcorders. I didn't jump on the video DSLR bandwagon for those reasons, as these required carefully controlled conditions instead. And I didn't jump on 4K because 4K delivery wasn't affordable until years after that.

joema wrote: I think there are some valid cases due to the pervasive 1080i TV infrastructure where shooting 1080i (maybe including AVCHD) has some advantages when handing off material.

True, you might even be required to do that for instance if your intent was to sell a show to broadcast distributors (who have very strict delivery specs).

Reply

Answer 6

joema

Level 4

1,565 points

Aug 11, 2026 7:42 PM in response to fox_m

The majority of US and European digital broadcast TV is interlaced. Both US and Europe each have two standards, one interlaced and the other progressive.

The majority of US ATSC digital TV system has always consisted of 1080i at 29.97 interlaced frames per second (59.94 fields per second), plus a lesser percentage at 720p at 59.94 frames per second.

The European standard is similar, in that most of the content is on 1080i at 25.0 interlaced frames per second (50 fields per second), plus a low percentage at 720p at 50 frames per second. For both US and European HD TV systems, the % of content broadcast at 720p is relatively low, about 25% in the US and about 10% in Europe. Most of it is 1080i.

Had both US and European HD TV architects had access to a "magic" CRT, they still likely wouldn't have implemented 1080p at 29.97 or 25 fps. Motion on progressive material at that frame rate doesn't look good. That's why both US and European HD 720p standards run at 59.94 and 50 frames per second.

What about 1080p at 59.94 or 50 fps? They did not remotely have the technology in the 1990s. The encoders, decoders, bandwidth, silicon and recorders simply did not exist. 1080i at 29.97 or 25.0 was at the edge of feasibility at that time.

Why not just upgrade? YouTube went from 1080p to 4k, no problem. A streamer like YouTube negotiates every session. Each person with 4 K equipment is handled individually. But broadcast must serve every receiver with one signal, and the entire broadcast infrastructure must be upgraded.

The OP was using AVCHD which is only 1080i. So this was not a broadcast issue, TV issue, or CRT issue. It was a recording format issue based on a given camera and codec. AVCHD has long been obsolete for most new productions, and there have been affordable 1080p cameras since around 2008 recording to MP4. So the OP case was not dictated by limitations of available, cost-effective progressive recording. It was because he wanted to keep using AVCHD, which means 1080i at a low bitrate. Maybe it was archival material shot decades ago. Or maybe it was just using what cameras were available, even though 1080p cameras recording H.264 to MP4 have been available for over 15 years. But I think there are some valid cases due to the pervasive 1080i TV infrastructure where shooting 1080i (maybe including AVCHD) has some advantages when handing off material.

Reply

Answer 7

Stephan-S Author

Level 1

42 points

Aug 9, 2026 1:18 PM in response to BenB

Hi, I tried that already. It should work in theory, but I couldn't find a way to make it output interlaced TFF like the source, it would always deinterlace despite any attempt to insert the proper x264 CLI options where expected.

Have you successfully output interlaced TFF video with Handbrake? If so, it would be very helpful to share how you did it.

Reply

Answer 8

Stephan-S Author

Level 1

42 points

Aug 9, 2026 9:54 PM in response to terryb

terryb wrote:

Claude says,

Haha, I have a Gemini subscription and guess what, it didn't even occur to me asking Gemini about this. No wonder I still have old AVCHD footage and my 20-yr-old reflex was to ask user forums as a first line of support.

Thanks a lot for the detailed tips, very helpful. I suspect I gave x264 the wrong options via HandBrake (another wrapper) and you're pointing me towards good directions. I will try later this week and report here.

Btw, to check detailed footage attributes (like the field order, codec) like you mentioned, I use MediaInfo https://apps.apple.com/fr/app/mediainfo/id510620098?mt=12 which is nice, I don't know if it is also available on the US macOS App Store.

Reply

Answer 9

Aug 11, 2026 1:41 AM in response to Stephan-S

I’m curious to know whether you actually get better results this way. All tv sets currently existing are progressive, so you are watching the result of your tv deinterlacing your content on the fly. Is it worth the extra effort rather than de interlacing once and for all and working with progressive media?

Reply

Answer 10

Aug 11, 2026 12:01 PM in response to Stephan-S

I am puzzled.

I am in Europe as well.

I can't see how interlaced has to do with 50 vs 60Hz.

The frame rate you use may be different, of course.

50Hz is the standard electricity frequency in Europe. Going with 50Hz refresh rate, or 25 or 50fps frame rate, has nothing to do with compatibility with PAL. PAL used 25fps (or rather, interlaced 50 fields per second) for the same reason. I film at 25fps or 50fps in my iPhone, and that works just fine (and obviously no interlaced material in the iPhone).

Note: for a long time, the iPhone camera app had no support for 25 or 50fps, but this option has now existed for years.

Reply

Answer 11

fox_m

Level 6

13,594 points

Aug 11, 2026 2:43 PM in response to Luis Sequeira1

I was under the impression that interlacing was only required for CRT (cathode-ray tube) display devices since these made use of the power supply standards (50Hz European, 60Hz American) to apply "half-frames" (every other odd or even line) at those rates (Hz = Frames), then the other half-frame would be applied completing a "full frame" at half the Hz rate of the power supply.

Who is still using CRT displays? If the answer is nobody, what is the point of interlacing? Is there a "legacy"? (I know about 10-15 years ago, some flat panel displays used interlacing for 1080 frames... but I haven't seen any of those types available lately.)

Reply

Answer 12

terryb

Level 4

3,682 points

Aug 10, 2026 11:56 AM in response to Stephan-S

MediaInfo is great, especially for $0.99, and yes it's available in the US. Good luck with the encode and let us know how it goes.

Reply