Repository navigation
Fix two ffmpeg 7.1 regressions: lost blends and an overlay deadlock - #13
Merged
Merged
Conversation
ffmpeg 7 leaves a trimmed stream with no frame rate (1/0), and xfade refuses one: "The inputs needs to be a constant frame rate". Every run of a chunked stitch that starts or ends inside a shot trims it, so on the Docker image's ffmpeg 7.1 the blended stitch failed and the render fell back to joining every shot with a cut. ffmpeg 6.1, which the tests and CI run, keeps the rate, so nothing caught it. An fps filter at the shot's own rate puts it back without dropping or repeating a frame. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WJkfhgbVRktPf2Lg6XXfNs
Each overlay was an input that started late, via -itsoffset. On Debian's ffmpeg 7.1.5 that deadlocked when the picture reached the first layer: ffmpeg sat idle, the preview stuck on "Drawing overlays", until the pass timed out an hour later. It did not reproduce on 6.1, 7.0.2 or 7.1.1. A layer is now its PNG read once as a single frame and repeated inside the graph for its window only (loop, trim, setpts), so no input waits on ffmpeg's scheduling and the overlay pulls frames as it needs them. The window keeps its last frame (ceil), and the frames sit on AV_TIME_BASE rather than the image demuxer's 1/25, which would round the fades to 40 ms. Against the -itsoffset output on 7.1.1, 59.6 dB average, with the remaining difference inside the fades: the layer now starts at its own time instead of the 1/30 s grid. 30 layers: 359 -> 293 MB, 7 s -> 3-5 s. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WJkfhgbVRktPf2Lg6XXfNs
davior
changed the title
davior
marked this pull request as ready for review
October 23, 2026 00:44
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This fixes two problems with #12 on the Docker image's ffmpeg (Debian trixie, 7.1.5). Neither shows up on the 6.1 that the tests and CI run.
1. Blends were joined as cuts
Wherever one run of the chunked stitch ends inside a shot and the next one starts, the stitch trims that shot. On ffmpeg 7.x,
trimleaves the stream with a frame rate of 1/0, andxfadethen refuses to run:The render caught the failure and fell back to joining every shot with a plain cut, showing the warning "Blends were joined as cuts". The fix restores the rate after the trim with an
fpsfilter at the shot's own frame rate. The frames are already at that rate, so no frame is dropped or repeated.2. The overlay pass deadlocked
#12 made each overlay an input that starts late, using
-itsoffset. On 7.1.5 the pass froze as the picture reached the first overlay. ffmpeg sat at 0.2% CPU and the preview stayed on "Drawing overlays" until the step's time limit, about an hour for a 10-minute video. The partialoverlaid.mp4had stopped about 135 s in, and the first overlay starts at 139.85 s. The same command doesn't hang on 6.1, 7.0.2 or 7.1.1.Each overlay is now its PNG read once as a single frame and repeated inside the filter graph, for its window only (
loop→trim→settb→setpts). No input starts late, so nothing depends on how ffmpeg schedules its inputs. The window keeps its last frame. The timestamps move onto AV_TIME_BASE first, because the PNG demuxer's 1/25 timebase would round the fades to 40 ms.Testing
-itsoffsetoutput it gives 59.6 dB average and 32 dB minimum. The only differences are inside the fades: an overlay now starts at its own time instead of being snapped to the 1/30 s grid. 30 overlays went from 359 MB and 7 s to 293 MB and 3–5 s. I couldn't get a 7.1.5 build in this sandbox, so the deadlock fix is verified by taking away the mechanism that hung (late-starting inputs), not by reproducing it.pytest -q: 674 passed on 6.1. The render tests also pass against 7.1.1.🤖 Generated with Claude Code
https://claude.ai/code/session_01WJkfhgbVRktPf2Lg6XXfNs