Let us start with the part most comparison pages would hide: ClipReady runs ffmpeg. Two command-line helpers, ffmpeg and ffprobe, built from published FFmpeg sources under the LGPL, invoked as separate processes. There is no secret engine.

So this is not “our technology versus theirs.” Every frame ClipReady copies is copied by essentially the same code you would run yourself. What differs is which invocation gets built, what happens after it finishes, and three small changes to the muxer that we wrote, published, and describe below.

If you are comfortable in a terminal and only need one file moved, ffmpeg -c copy is a legitimate answer and you should use it.

What `-c copy` gets right

It copies the encoded video without decoding it. That is the correct mechanism, it is fast, and the picture that comes out was never decoded and rebuilt. Everything below assumes you already know this.

What it leaves behind

The timestamps come with it. MKV stores time in whole milliseconds, so a 23.976 film lands on a 41/42 ms cadence that Final Cut averages to about 23.81 fps. A stream copy copies that cadence faithfully into the new file. Fixing it means rewriting the timestamps onto an exact rational grid: a setts bitstream filter against a shared anchor, plus an explicitly declared output rate, with the arithmetic right for each 1001-family rate.

Surround loses its layout. Write six channels into a MOV without a named channel layout and Apple guesses, which is how center dialogue ends up in the wrong speaker. The tag has to be written deliberately, and it has to be the right variant. 5.1 and 5.1(side) are not interchangeable.

Audio Apple cannot decode stays undecodable. -c copy will happily carry a DTS-HD Master Audio track into a MOV where QuickTime plays it as silence. Converting it means choosing PCM, the right bit depth, the right channel count, and the layout tag to go with it.

Timecode gets invented or lost. MKV has nowhere to store SMPTE timecode. -map_metadata 0 can lead the MOV muxer to synthesize a tmcd track from whatever source tag it finds, which is worse than having none. The details are here.

HEVC needs re-tagging. An hev1-tagged HEVC stream shows as unplayable in Apple apps. It needs hvc1, and that tag is the only thing that should change.

Open-GOP entry points get over-promised. This is the one item on the list that is not about flags you could have passed. An unpatched MOV or MP4 muxer marks every H.264 and HEVC I-frame as a place a decoder can start cold, and on Blu-ray and UHD sources many of them are not. A measured remux advertised 606 entry points where 200 were real. Final Cut decodes long-GOP media in parallel segments beginning at those points, so it starts one where it cannot and renders a single macroblocked frame, at the same timecode every time. FFmpeg draws this distinction for MPEG-2 already; extending it to H.264 and HEVC is one of our three patches, and it is published. The full account, with the measurements.

Nothing checks the result. The command exits 0. Whether Final Cut can actually open what you made is discovered later, by opening it.

The honest framing

Every one of those is solvable with ffmpeg. People do solve them, and the solutions end up in a shell script that grows a case for MPEG-2, a case for soft telecine, a case for the sources whose flags lie, and a comment nobody remembers writing.

ClipReady is that script, with the cases already worked out against a reference corpus, plus two things a script usually does not have: it shows you what it is going to do to every track before it runs, and it opens the finished file back through AVFoundation and VideoToolbox to confirm the result is playable, decodable, correctly timed, and correctly mapped. If a check fails, nothing is saved.

When to stay in the terminal

One file, and you already know the flags.
Something ClipReady deliberately will not do: transcoding, filtering, scaling, burning in subtitles.
A format outside what ClipReady carries. It handles H.264, HEVC, MPEG-2 and ProRes and declines the rest by name.
Automation inside a larger pipeline. ClipReady is a Mac app with a window, not a CLI.

When the app earns its price

You have a folder of them.
You want to see what will happen before it happens.
You want the result checked rather than assumed.
You would rather not maintain the special cases yourself.

On the license

ClipReady’s helpers are built in an LGPL-v2.1-only configuration, run as separate processes, and are never linked into the app. Settings → Acknowledgments names all three local patches and what each one does, links the license, and ships the license text, the patches, and the build recipe inside the app. The modified tree is published in full at ffmpeg-clipready. Using ffmpeg is not something to be coy about; it is the correct tool, and the terms it comes with are worth honoring visibly.

What -c copy gets right