You download the AI-generated video, open it, and a chunk in the middle is just black. Or playback freezes on one frame. Or it plays in VLC but not in your browser. Or the last 2 seconds are blank.
Fastest fix: open the file in VLC first. If VLC plays it clean, the pixels are fine and the problem is downstream (your browser or editor can’t read the codec) — re-encode to H.264 MP4 with ffmpeg and it will play everywhere. If VLC also shows black, the file itself is broken (a timed-out or truncated render) and you need to regenerate. Everything below is how to tell which case you’re in and fix it for good.
Which bucket are you in?
Run two checks before you do anything else: (1) does it play in VLC, and (2) where exactly are the black frames? That alone narrows it to one cause.
| Symptom | Plays in VLC? | Black frames are | Most likely cause | Fix |
|---|---|---|---|---|
| Browser black, VLC fine | Yes | Whole clip | Codec (H.265/HEVC) your browser can’t decode | Re-encode to H.264 |
| Editor shows black, plays elsewhere | Yes | A section | Editor rejects the export profile / VFR | Transcode to ProRes / DNxHD |
| Stutters, audio drifts | Yes | Scattered | Variable frame rate (VFR) | Force constant frame rate |
| Black at the very end | Yes/No | Tail only | Render timed out, padded with black | Regenerate shorter |
| Clip shorter than requested | Yes | Tail only | Tier duration cap truncated it | Stay within tier limit |
| Garbage / freeze near end, file small | No | Tail | Interrupted download | Re-download |
| VLC also black throughout | No | Whole clip | Bad render | Regenerate |
Step 0: Identify the file before guessing
Don’t guess the codec — read it. ffprobe ships with ffmpeg (install via brew install ffmpeg on macOS, apt install ffmpeg on Linux, choco install ffmpeg on Windows):
# What codec, frame rate, duration, pixel format?
ffprobe -v error -select_streams v:0 \
-show_entries stream=codec_name,profile,width,height,avg_frame_rate,r_frame_rate,pix_fmt,duration \
-of default=noprint_wrappers=1 input.mp4Read the output like this:
codec_name=hevc-> it’s H.265; many browsers can’t decode it without a hardware decoder (see cause 1).avg_frame_ratediffers fromr_frame_rate-> likely variable frame rate (cause 4). Confirm with the dedicated detector:
# vfrdet reports the share of variable-rate frames (FFmpeg 4.0+)
ffmpeg -i input.mp4 -vf vfrdet -an -f null - 2>&1 | grep VFRdurationshorter than what you requested -> tier truncation (cause 3).
Common causes
Ordered by hit rate, highest first.
1. Browser can’t decode the codec, but the file is fine
Most AI video platforms export MP4 with H.265 (HEVC) to keep file size down. Here is the part that confuses people in 2026: Chrome (107+), Edge, Opera, and Firefox all do support HEVC now — but only when the device has a hardware HEVC decoder that the OS exposes. There is no software fallback. On a machine without the hardware path (older Intel HD Graphics, low-end ARM, most cloud VMs), the same Chrome shows a black frame while the timeline keeps ticking and audio keeps playing. Safari decodes HEVC reliably. Firefox enables HEVC by default only on recent builds and per platform — Firefox 134+ on Windows, 136+ on macOS, 137+ on Linux/Android — and still relies on the same hardware decoder. VLC bundles its own software decoder, so it always plays.
How to spot it: ffprobe reports codec_name=hevc; the file plays in VLC and Safari but shows black in Chrome/Firefox on one specific machine.
2. Generation timed out, tail is empty
The render timed out at second N, and the platform padded the file with black frames to hit the requested duration.
How to spot it: black frames are always at the END, and VLC shows them too (the pixels really are black, not a decode failure).
3. Tier duration cap silently truncated it
Free and lower tiers cap clip length. As of June 2026, common per-generation limits are roughly: Kling free tier 5 or 10s per clip (720p, watermarked); Runway Gen-4 generates 5s or 10s clips natively (longer runtimes come from chaining with the Extend Video tool, not a single render); Sora 2 up to 15s standard and 25s for ChatGPT Pro on web via Storyboard (note: OpenAI shut down the standalone Sora web/app experience on April 26, 2026, and Sora 2 now lives inside other surfaces). If you requested 10s but your tier maxes at 5s, you get 5s of content plus black, or a hard cut.
How to spot it: ffprobe duration is shorter than requested, or content plus black equals exactly the tier max.
4. Variable frame rate confuses players and editors
Some AI MP4s ship with variable frame rate (VFR). Quicktime, browsers, and most NLEs (Premiere, Final Cut) choke on VFR — you get stutter, frozen frames, or audio drift. VLC and DaVinci Resolve tolerate it.
How to spot it: vfrdet reports a non-zero VFR share; plays in VLC but stutters or shows black sections in an editor.
5. Corrupted / interrupted download
The download was cut off, leaving a partial file with garbage or a freeze near the end.
How to spot it: file size is noticeably smaller than the tool’s quoted size; VLC also fails near the end. Re-download.
6. Editor doesn’t support the export profile
You imported into Premiere/FCPX and a section shows black, but the file plays fine in every player. The NLE doesn’t like the codec/profile (often 10-bit HEVC or VFR).
How to spot it: plays everywhere except inside your editor.
Shortest path to fix
Step 1: Test in VLC first
VLC plays virtually any codec/container with its own software decoders. This is your single most useful diagnostic.
1. Download VLC if you don't have it (free, vlc.org)
2. Open the AI-generated file
3. Plays clean -> the file is good; fix the player/editor side (Steps 2 & 5)
4. VLC also black -> the file is broken; regenerate (Step 3)Step 2: Re-encode to a universal format
If VLC plays but your browser or editor doesn’t, transcode. H.264 in MP4 is the safe default that plays everywhere:
# H.264 in MP4 — plays in every browser and editor
ffmpeg -i input.mp4 -c:v libx264 -preset slow -crf 18 \
-pix_fmt yuv420p -c:a aac -b:a 192k -movflags +faststart output.mp4
# WebM (VP9) — smaller for the open web
ffmpeg -i input.mp4 -c:v libvpx-vp9 -b:v 2M \
-c:a libopus output.webmThe -pix_fmt yuv420p flag matters: some AI exports use yuv444p or 10-bit, which browsers reject even in an H.264 container. Forcing yuv420p is what makes the result truly universal.
Step 3: Force constant frame rate (fixes VFR stutter)
If vfrdet flagged VFR, normalize to a fixed rate. The modern flag is -fps_mode cfr (it replaced the deprecated -vsync 1 in FFmpeg; -vsync still works but prints a deprecation warning):
# Convert VFR -> constant 30 fps
ffmpeg -i input.mp4 -fps_mode cfr -r 30 \
-c:v libx264 -crf 18 -pix_fmt yuv420p -c:a aac output.mp4Match -r to your project frame rate (24, 25, 30, or 60) so the editor doesn’t conform it again.
Step 4: Regenerate if VLC also shows black
1. Check ffprobe duration vs. what you requested
2. Reduce the requested duration to within your tier cap (Step in cause 3)
3. Regenerate; watch whether the same black tail returns
4. If it persists, contact platform support with the exact prompt + timestampStep 5: Re-download if the file is suspiciously small
ls -lh input.mp4 # mac/linux
dir input.mp4 # windowsCompare against the tool’s quoted size. If it’s significantly smaller, the download was incomplete — re-download via right-click “Save link as” or the direct asset URL, and avoid closing the tab mid-download.
Step 6: Transcode to ProRes / DNxHD before editing
Premiere, Final Cut, and DaVinci all prefer an intra-frame edit codec over a delivery codec. ProRes profile values: 0=proxy, 1=lt, 2=standard, 3=hq.
# ProRes 422 HQ — best edit quality
ffmpeg -i input.mp4 -c:v prores_ks -profile:v 3 \
-pix_fmt yuv422p10le -c:a pcm_s16le output.mov
# ProRes Proxy — lighter, for cutting on a laptop
ffmpeg -i input.mp4 -c:v prores_ks -profile:v 0 \
-vendor apl0 -pix_fmt yuv422p10le output_proxy.movOn Windows-centric Premiere setups, DNxHR is the equivalent: -c:v dnxhd -profile:v dnxhr_hq -pix_fmt yuv422p.
Step 7: Trim out black frames manually
If only the tail or a middle section is black and you don’t need it, just cut it without re-encoding. First find the exact black interval, then trim around it:
# Locate the black frames (prints black_start / black_end timestamps)
ffmpeg -i input.mp4 -vf "blackdetect=d=0.1:pix_th=0.10" -an -f null - 2>&1 | grep black_start
# Lossless trim, keep seconds 0 to 6 (adjust to taste)
ffmpeg -i input.mp4 -ss 0 -to 6 -c copy trimmed.mp4See the FFmpeg blackdetect filter docs for tuning d (minimum black duration) and pix_th (black-pixel threshold).
How to confirm it’s fixed
Re-run ffprobe on the output and verify the three things you changed:
ffprobe -v error -select_streams v:0 \
-show_entries stream=codec_name,avg_frame_rate,r_frame_rate,pix_fmt,duration \
-of default=noprint_wrappers=1 output.mp4Expect codec_name=h264, avg_frame_rate equal to r_frame_rate, pix_fmt=yuv420p, and the full duration. Then open the file in the player or editor that originally failed — it should play end to end with no black.
Prevention
- After every export, test in VLC AND your actual target player/editor before you build a timeline around it.
- Default to re-encoding AI output to H.264 MP4 (
yuv420p, constant frame rate) before editing. - Stay a second or two inside your tier’s duration cap — don’t request exactly the maximum.
- Keep
ffmpeg/ffprobeinstalled as your universal sanitizer between platforms and editors.
FAQ
Why does it play in VLC but not Chrome? VLC ships its own software decoders, so it plays H.265/HEVC on any machine. Chrome (107+) only decodes HEVC when the device has a hardware HEVC decoder the OS exposes and ships no software fallback, so without one you get a black frame and silent failure. Re-encode to H.264 (Step 2) and it plays in every browser regardless of hardware.
Are the black frames a sign the AI generation failed? Usually no. If VLC plays the clip cleanly, the render is fine and it’s purely a codec/container issue. The render only failed if VLC also shows black — that points to a timeout or truncation (causes 2 and 3).
The last 2 seconds are black every time. What’s wrong?
Either the render timed out and was padded with black to fill the requested duration, or your tier’s duration cap truncated the content. Check ffprobe duration against what you asked for, then regenerate at a shorter length inside your tier’s limit.
How do I find the exact timestamps of the black frames?
Use FFmpeg’s blackdetect filter — it prints the start, end, and duration of every black interval so you know precisely what to trim:
ffmpeg -i input.mp4 -vf "blackdetect=d=0.1:pix_th=0.10" -an -f null - 2>&1 | grep black_startIf blackdetect reports intervals here, the pixels really are black (a real render problem). If it reports nothing but a player still shows black, the file is fine and you have a decode/codec issue — re-encode (Step 2).
ffmpeg says -vsync is deprecated. Should I worry?
No, it still works. Newer FFmpeg builds prefer -fps_mode cfr for forcing constant frame rate; switch to that flag to silence the warning. Don’t use both -vsync and -fps_mode in the same command.
My editor shows black even after re-encoding to H.264. Now what?
Transcode to an edit codec instead of a delivery codec: ProRes 422 HQ (-c:v prores_ks -profile:v 3) on macOS, or DNxHR HQ on Windows (Step 6). NLEs decode those far more reliably than browser-grade H.264/H.265.