If your camera plays perfectly in its manufacturer's app, but Frigate, go2rtc, Home Assistant, or a plain browser tab shows a black screen, a spinner that never resolves, or nothing at all — this is almost never a Frigate bug or a config mistake. It's a codec problem.
The real cause: H.265, not H.264
Most cameras from the last several years default to H.265 (HEVC) for the main stream, because it uses roughly half the bandwidth of H.264 at the same quality. That's great for storage and bandwidth — and it's exactly why your camera's own app plays it without any trouble, since manufacturer apps ship their own native decoders (often hardware-accelerated on your phone or PC).
Browsers are a different story. No major browser can decode H.265 over HLS or WebRTC — this isn't a missing plugin or a setting you forgot to enable, it's a licensing and patent issue that's kept H.265 out of browser media stacks for years. It doesn't matter whether you're using Frigate, go2rtc, Blue Iris, or hand-rolling your own player — if the stream is H.265, a browser tab cannot show it, full stop.
How to confirm this is actually your problem
Don't guess — check the stream directly with ffprobe:
ffprobe "rtsp://user:pass@192.168.1.50:554/your/stream/path"
Look for the Video: line in the output. If it says:
Stream #0:0: Video: hevc (Main), yuv420p, 1920x1080, ...
— that hevc is your answer. If it says h264 instead, this isn't your issue, and you should look elsewhere (check for auth errors, wrong RTSP path, or a network/firewall block instead).
Two ways to fix it
Option 1 — Change the camera's encoding (recommended, close to free)
Almost every camera that supports H.265 also supports H.264, and lets you choose per-stream. Log into the camera's web interface and look for:
- Video → Encoding → Video Compression, or
- Video/Audio → Stream settings
Switch the stream you're feeding into your NVR software to H.264. You'll use somewhat more bandwidth and storage, but it'll play in any browser with zero further changes. This is the right fix for the vast majority of setups — one setting, no ongoing cost.
Option 2 — Transcode with go2rtc (only if your camera genuinely has no H.264 option)
A small number of budget or older cameras only offer H.265. In that case go2rtc can transcode on the fly:
streams:
my_camera:
- "rtsp://user:pass@192.168.1.50:554/stream1#video=h264"
The #video=h264 tells go2rtc to re-encode from H.265 to H.264 in software before serving it to browsers. This works, but transcoding is CPU-intensive — fine for one or two cameras on a reasonably modern box, but it adds up fast if you're doing this for many cameras at once. Prefer Option 1 whenever the camera allows it.
Why this matters more than it seems
This single issue — H.265 vs H.264 — is one of the most common reasons people conclude "my NVR software is broken" and spend hours debugging the wrong layer, when the fix is a two-minute setting change on the camera itself. If you check nothing else before opening a support thread or a GitHub issue, check this first.
This is one of four setup issues covered in more depth — with brand-specific RTSP paths and drop-in Frigate/go2rtc config — in the RTSP Toolkit, built from running a 24/7 commercial CCTV network with 480+ cameras.
