[richiemcilroy]

A recording whose source lost a single reference frame (a gap in H.264 frame_num) decodes without any error, but FFmpeg withholds the frames behind the gap until the frame numbering comes back around. The decoded frame count then falls short of the packet count, and verification fails the same way on every retry, so the recording never gets an MP4.

Most lost frames are concealed by the decoder and already pass. Only a gap that lands where the counter wraps makes frames go missing from the decode, so whether a recording passed depended on where the frame was lost.

When the decoded video is short, verification now runs one diagnostic pass over the source. It accepts the shortfall only if FFmpeg reports frame number gaps and the missing frames fit within one frame number cycle per gap (read from the stream's SPS). Every packet is still proven byte for byte by the packet proof, the audio check is unchanged, and any other shortfall or surplus still fails. The pass only runs on the path that currently fails outright, so recordings that verify today pay nothing.

Tests build fragmented H.264 sources with one packet dropped:

• the packet at the wrap verifies in one pass and in chunks with the same frame count, logging recording_reference_gaps_accepted
• a shortfall with no gaps, or larger than the gaps can explain, is still refused
• a dropped packet the decoder conceals verifies as before, without the gap check

Confidence Score: 4/5

The PR appears safe to merge, with a non-blocking resource-use concern in the diagnostic decode.

Findings

1.  Gap check ignores thread limits ▶

Fix with agent prompt

### Issue 1
apps/media-server/src/lib/recording-verification.ts:1317-1319
`referenceGapsExplaining` decodes the entire source without honoring `MEDIA_SERVER_VERIFY_DECODE_THREADS`. The normal verification decode uses that setting and defaults to one thread, but this pass lets FFmpeg choose its thread count. On large recordings, that can raise CPU and memory use despite an explicitly configured limit.

Pass the same decoder thread setting before `-i`, and keep the filter thread limits used by `decodeRecording`.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

Summary

The PR allows a decoded-frame shortfall when source diagnostics report reference-frame gaps large enough to explain it.

• Recording checks accept frame shortfalls explained by H.264 reference gaps.

_{Reviews (1) · Last reviewed commit: "fix(media-server): accept frames withhel..." · Reviewed by Greptile}

[richiemcilroy]

@greptileai review

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated
cap-status	Skipped		Oct 28, 2026 7:25pm UTC