DJI drone footage that stutters or refuses to play on a Mac
Drone footage copies off the card fine, and then plays badly. The picture stutters, scrubbing lurches, and the fans spin up. Or it will not open at all.
Those are two separate problems with two separate answers, and it is worth establishing which you have before changing anything.
Stuttering is a decoding problem, not a file problem
If the clip opens and plays badly, the file is fine. Your Mac cannot decode it fast enough in real time.
Drones record at high resolution, high frame rate and high bitrate, frequently in HEVC, and often at 10-bit colour depth. That combination is demanding. Macs with hardware decoding for HEVC handle it comfortably; without it, decoding falls back to the processor, which struggles with 4K at high bitrate.
Find out what you actually have:
ffprobe -v error -select_streams v:0 \
-show_entries stream=codec_name,profile,width,height,r_frame_rate,bit_rate,pix_fmt \
-of default=noprint_wrappers=1 DJI_0001.MP4
The fields that matter:
codec_name=hevcwithpix_fmt=yuv420p10lemeans 10-bit HEVC, the most demanding common combination.bit_rateabove roughly 100,000,000 (100 Mbps) is heavy for real-time playback on any machine.width=3840upwards with a high frame rate compounds both.
Making it play
Three approaches, in increasing order of effort.
Use a player with better decoding. Some players handle high-bitrate HEVC considerably better than others, and this costs nothing to test.
Make a proxy. This is what editors do, and it is the right answer if you are going to work with the footage. A proxy is a smaller, easier-to-decode copy that you edit against, with the original swapped back in for the final export:
ffmpeg -i DJI_0001.MP4 -vf scale=1280:-2 -c:v libx264 -preset veryfast \
-crf 23 -c:a aac -b:a 128k DJI_0001_proxy.mp4
That produces a file any Mac will scrub smoothly. Keep the original; the proxy is a working copy.
Transcode for keeping. If the footage is finished and you simply want it watchable, convert it to something less demanding:
ffmpeg -i DJI_0001.MP4 -c:v libx264 -crf 20 -preset medium \
-pix_fmt yuv420p -c:a aac -b:a 192k DJI_0001_h264.mp4
-pix_fmt yuv420p converts 10-bit to 8-bit, which is the single biggest compatibility gain. You lose colour grading latitude, so do this only for footage you have finished with. H.264 versus HEVC covers what each buys you.
Manatee will do the same conversion on the Mac without a command line and without uploading footage anywhere, working from a duplicate so the original clip stays as it is.
When the clip will not open at all
Different problem. Test whether the file is structurally sound:
ffprobe -v error -show_entries format=duration,size -of default=noprint_wrappers=1 DJI_0001.MP4
A real duration means the file is fine and the issue is decoding. No duration, or an error, means the index is missing.
This is common with drones for an obvious reason: batteries run down, and a recording interrupted by a power loss never gets its index written. In an MP4 the frame data sits in an mdat block and the index sits in a moov block, and the index goes last because it cannot be completed until recording stops:
ftyp → free → mdat (the video data) → moov (the index)
Lose power mid-flight and you keep every frame and lose the map. The file is large and unplayable at once.
That is repairable when the frames survive. Manatee rebuilds the index from the surviving data and writes a clean copy from a duplicate, so the card original is never modified. Repairing a corrupted GoPro or drone video covers the process, including why a reference clip from the same drone and the same settings improves the result.
The card is worth ruling out too
Drone cards take a beating: heat, vibration, and power cut abruptly at landing. If several clips from one flight are bad, suspect the card rather than each file.
Copy everything off before doing anything else, then check the card:
diskutil list
diskutil verifyVolume /dev/disk4s1
Use the identifier from diskutil list for your card. Format cards in the drone rather than on the Mac, since the drone chooses a layout it can write reliably at high bitrate.
Practical habits
- Copy the whole card before reviewing anything. Reviewing from the card risks the only copy.
- Verify the copy with checksums for footage worth flying twice. Verifying a file arrived intact has the method.
- Land with battery to spare. Most drone file damage is a power failure during writing.
- Make proxies once, at import, rather than fighting playback repeatedly.
Questions
Why does the same file play fine on my newer Mac? Hardware decoding. Newer chips include dedicated HEVC decoding, including 10-bit; older machines decode in software and cannot keep up at high bitrates.
Should I record in H.264 instead? If your workflow struggles with HEVC and you do not need the extra colour information, yes. Files are larger and considerably easier to work with. If you grade your footage, keep HEVC 10-bit and use proxies.
The clip plays but the colours look wrong after converting. That is the 10-bit to 8-bit conversion, and it can look washed out if the source used a flat colour profile. Why a video looks washed out after converting covers what to do.
Some clips from the flight are fine and one is not. Almost always the last one, and almost always a power interruption. The earlier clips completed and got their indexes written; the final one did not.