Cameras

Frigate: no frames have been received

Decode Frigate's 'No frames have been received' error — the RTSP path, the codec, and the go2rtc restream wiring behind it.

Problem summary

Frigate's 'No frames have been received, check error logs' means ffmpeg isn't producing video for that camera. It's almost always the stream URL, an H.265-vs-H.264 codec mismatch, or pulling the camera directly instead of restreaming through go2rtc — prove the raw stream outside Frigate first.

Operator snapshotEvidence first

First proof

Play the exact RTSP URL in VLC or run ffprobe against it.

Screen to open

ffprobe -rtsp_transport tcp "rtsp://USER:PASS@IP:554/<path>"

Expected signal

The stream opens and ffprobe reports a video codec and resolution.

Stop boundary

If the camera is unreachable at all, treat it as camera-offline, not a Frigate config issue.

Layer path

1Frigate's 'No frames have been received, check error logs' means the ffmpeg process feeding that camera isn't producing video — it's almost always the stream URL, the codec, or how the stream is wired, not Frigate itself.

2The companion log lines tell you which: 'ffmpeg process is not running', 'Invalid data found when processing input', or 'Unable to read frames from ffmpeg process'.

3The right architecture is to restream the camera once through go2rtc and point Frigate's detect/record at the local restream (rtsp://127.0.0.1:8554/<name>), rather than each role hitting the camera directly.

4Confirm the raw stream plays outside Frigate first (ffprobe/VLC) — that splits a camera/URL problem from a Frigate-config problem.

Runbook

Step-by-step runbook

Start here. Do each check in order, compare it to the expected result, and stop when the evidence explains the failure or the safe stop point applies.

Prove the stream outside Frigate

Check: ffprobe or VLC the exact RTSP URL the camera uses.

Expected result: The stream opens with a video codec reported.

If not: If it won't open, fix the URL/credentials/codec before any Frigate change.

Restream through go2rtc

Check: Define the camera once in go2rtc and confirm it connects in the 1984 UI.

Expected result: go2rtc shows the stream connected with a known codec.

If not: If go2rtc can't pull it, resolve the source/network first.

Point Frigate at the restream with the right preset

Check: Set detect/record to rtsp://127.0.0.1:8554/<name> and use preset-rtsp-restream.

Expected result: Frigate consumes the clean restream and frames arrive.

If not: If you must pull the camera directly, use preset-rtsp-generic (or the UDP preset for flaky cams).

Match codec and transport

Check: Set the consumed stream to H.264 if the path is failing on H.265, and switch RTP transport for cameras throwing RTP errors.

Expected result: Frames are stable with no Invalid-data errors.

If not: For Reolink HTTP-FLV use preset-http-reolink, NOT on an rtsp restream.

Confirm and right-size detection

Check: Verify the camera shows frames, then ensure detection runs on a low-res substream (~5 fps).

Expected result: The camera is live and detection load is sane.

If not: If detection is heavy, plan the detector with the Frigate hardware planner.

Decision tree

If: The URL won't play in VLC/ffprobe either.

Then: Camera, URL, or credentials problem — not Frigate.

Action: Fix the RTSP path/credentials (percent-encode special characters); see /cameras/rtsp-url-not-working.

If: It plays in VLC but Frigate logs 'Invalid data'/'ffmpeg not running'.

Then: Codec or preset mismatch.

Action: Set H.264 (or restream via go2rtc) and match the ffmpeg preset to the source.

If: It worked, then drops frames intermittently.

Then: Connection-limit exhaustion or RTP transport instability.

Action: Restream once through go2rtc; switch RTP transport (UDP/TCP) for the affected camera.

If: go2rtc can't pull the stream.

Then: Source/network problem upstream of Frigate.

Action: Resolve in go2rtc (URL, codec, network) first; Frigate consumes the restream after.

Safe stop: If the camera is unreachable at all, treat it as camera-offline, not a Frigate config issue.

Evidence

Evidence table

Symptom	Evidence to collect	Likely layer	Next action
No frames on one camera, others fine.	ffprobe/VLC result for that camera's URL; its codec.	URL / codec for that camera	Fix the URL or set H.264 / restream that camera.
'Invalid data found when processing input'.	The configured ffmpeg preset vs the actual source type.	Preset mismatch	Use preset-rtsp-restream for go2rtc sources; preset-http-reolink only for Reolink HTTP-FLV.
Frames drop after a while.	Whether multiple roles pull the camera directly; RTP errors in the log.	Connection limit / RTP transport	Restream via go2rtc; switch UDP/TCP transport.
All cameras of one brand fail.	Brand-specific URL/codec/transport quirk (e.g. Reolink).	Vendor stream quirk	Apply the vendor's known preset/transport workaround.

Reference

Commands and settings paths

Probe the raw stream

ffprobe -rtsp_transport tcp "rtsp://USER:PASS@IP:554/<path>"

Where: From the Frigate host (or any machine on the camera's network).

Expected: ffprobe prints a video stream with codec (h264/hevc), resolution, and fps.

Failure means: Errors or a hang mean the URL/credentials/codec/transport is wrong — not Frigate.

Safe next step: Correct the URL (percent-encode the password), set H.264, or switch transport, then re-probe.

Check the go2rtc restream

Open http://<frigate-host>:1984 (go2rtc UI)

Where: In a browser on the LAN.

Expected: The camera appears connected with a known codec; the stream plays.

Failure means: If go2rtc can't connect, the problem is the source/network, upstream of Frigate.

Safe next step: Fix the source in go2rtc first, then point Frigate's roles at rtsp://127.0.0.1:8554/<name>.

Read Frigate's logs

Frigate UI > Logs (or docker logs <frigate>)

Where: On the Frigate host.

Expected: The exact ffmpeg error (Invalid data / not running / unable to read frames) is shown.

Failure means: The specific line tells you codec vs preset vs transport vs URL.

Safe next step: Match the fix to the error and restart Frigate.

Hardware boundary

Hardware and platform boundary

Change only when

Add go2rtc restreaming the moment you have more than one role (detect + record + live) or any H.265 camera — it removes most no-frames failures at the source.

Evidence that matters

Cameras that expose a stable RTSP URL and a low-res substream, and a host that can decode all your streams (iGPU/GPU).

Evidence that does not matter

Headline megapixels — a 4K camera with a flaky stream is worse than a reliable 1080p substream for detection.

Avoid

Pointing every Frigate role directly at the camera (connection-limit exhaustion) or using the Reolink HTTP preset on an RTSP restream.

Related tool/calculator

Use the linked calculator or tool to turn this runbook into numbers for your exact setup.

Frigate hardware planner

Last reviewed

2026-06-02 · Reviewed by HomeTechOps. Built from June-2026 research verified against the Frigate camera-setup and ffmpeg-presets docs and go2rtc; leads with prove-the-stream-outside-Frigate, the go2rtc restream pattern, and the codec/preset/transport causes behind the canonical no-frames error. Frigate config schema moves fast — cite the stable docs pages and re-verify YAML before publishing snippets.

Sources/assumptions

Assumes Frigate (recent version) pulling IP-camera RTSP, ideally restreamed through go2rtc.
Frigate's config schema changes between versions — verify YAML keys/presets against the current docs before copying snippets.
Compatibility is protocol-level (the camera exposes RTSP/ONVIF); no per-model guarantees.

Source-backed checks

HomeTechOps turns official docs and conservative safety rules into a shorter runbook. These links are the source trail for the page direction.

Frigate docs: Recommended hardwareUsed for detector inference times, the cameras ≈ (1000 ÷ inference_ms) ÷ detect_fps capacity model, and the current 'Coral no longer recommended for new installs' guidance.Frigate docs: Camera setupUsed for the detect-on-substream / record-on-main pattern and recommended stream roles.FS.com: Understanding PoE standards and wattageUsed for the 802.3af/at/bt source-vs-delivered power figures and the switch total-PoE-budget constraint.Frigate documentationUsed as the first-party reference for Frigate camera setup, detectors, recording, and configuration.Frigate docs: FFmpeg presetsUsed for the preset-rtsp-* / preset-http-reolink presets and the go2rtc restream source (rtsp://127.0.0.1:8554).go2rtc (AlexxIT) — READMEUsed for go2rtc restreaming, the default ports (web 1984 / RTSP 8554 / WebRTC 8555), and MSE vs WebRTC low-latency live view.

Diagnostic rule

1. Check the simplest signal first.
2. Change one thing at a time.
3. Prove the stream/reachability before deep config.
4. Stop when the evidence says the risk moved.

FAQ

Why does my camera stream in VLC but Frigate says no frames?

If VLC plays it, the URL and credentials are fine — the failure is inside Frigate's pipeline, usually an H.265 stream where the consumer expects H.264, or the wrong ffmpeg preset. The reliable fix is to restream the camera once through go2rtc and point Frigate's detect/record at the restream (`rtsp://127.0.0.1:8554/<name>`) with `preset-rtsp-restream`. See RTSP URL not working if VLC also fails.

What does 'Invalid data found when processing input' mean?

It's ffmpeg rejecting the stream it was handed — most often a codec/preset mismatch. Set the consumed stream to H.264 (or restream via go2rtc, which handles H.265), and make sure the preset matches the source: `preset-rtsp-generic` for direct RTSP, `preset-rtsp-restream` for a go2rtc source, and `preset-http-reolink` only for Reolink HTTP-FLV (never on an RTSP restream).

Should every Frigate role pull the camera directly?

No. Pulling the camera separately for detect, record, and live can exhaust the camera's connection limit and cause dropped frames. Restream once through go2rtc and have all roles consume that single restream — it removes a whole class of no-frames failures.