Video freezes but audio continues: causes and fixes

If a video freezes but the audio continues in every player you try, the file itself holds a still frame: its picture stops, pauses, or runs out before its sound does. If it freezes in only one player or on one device, the file is fine and the problem is playback, which this post doesn't cover. In a Sume Timeline render, three layouts hold a frame, and the render reports each one in its warnings[].

The ffprobe and FFmpeg facts come from the ffprobe and ffmpeg documentation, and the Sume facts from the Timeline 1.0 and Video inspect docs and the Sume API reference, all read on 2026-09-28. The warning codes and anything described as current behavior are read from Sume's code.

How do I check whether the file itself freezes?

Compare how long the picture runs with how long the sound runs. ffprobe prints each stream's type and duration; in this file the video stream ends at 3 seconds and the audio at 5, so the last 2 seconds have sound and no new picture:

ffprobe -v error -show_entries stream=codec_type,duration -of csv=p=0 input.mp4
# video,3.000000
# audio,5.000000

Why does a Sume Timeline render freeze while the audio plays?

A render's output always runs for audio.duration_seconds, so when the picture has nothing new to show, the render holds a frame rather than ending early. Three layouts cause it. The warnings are soft: the job still completes, and they come back in warnings[] on the result.

What does render.pad_mode change?

Only the third layout. render.pad_mode decides how a slot longer than its source is filled: loop replays the source, freeze holds its last frame, and the default, auto, loops short sources instead of holding a long freeze. When auto loops and when it holds is spelled out in how to increase video length by looping. No mode fills a gap or a short last slot: in current code both always hold a frame, so fix those in the layout itself. A freeze you want is covered in how to freeze frame a video.

How do I catch a freeze before I pay?

Send the same body to POST /v1/timeline-1.0/plan. It is unbilled and doesn't download media, and it returns duration_seconds next to coverage_seconds, where the last slot ends. If coverage is shorter, the last frame will hold for the difference. In current code the plan's warnings already list gaps and a short last slot, since both follow from the starts and durations you declare.

The plan can't predict short-source pad or loop warnings, because it never sees the files. Check each source's length first with an unbilled probe (POST /v1/video-inspect with frames: false returns probe.duration_seconds), and keep every slot's source_in plus duration inside it. Validate a timeline before rendering covers the plan in full.

How do I fix a video that freezes?

• Close the gaps: start each slot where the previous one ends, at its start plus its duration.
• End the last slot at audio.duration_seconds, or shorten the audio to match the picture.
• For a short source, shorten the slot, move source_in earlier, or set render.pad_mode to "loop" to replay it. In current code a source under 0.5 seconds still holds its last frame, even with loop.
• For a file made elsewhere, FFmpeg's -shortest finishes the output when the shortest stream ends, which drops the sound that plays over the missing picture: ffmpeg -i input.mp4 -c copy -shortest output.mp4. -c copy keeps both streams as they are, without re-encoding.
• If both streams run the same length, the still is inside the picture itself, so fix the edit that made it. If the picture never appears at all, see MP4 plays audio but no video.