DEV Community

ysarawoot-cmd
ysarawoot-cmd

Posted on

Why Your RTSP Camera Works in Its Own App But Shows Nothing in Frigate/Browser

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"
Enter fullscreen mode Exit fullscreen mode

Look for the Video: line in the output. If it says:

Stream #0:0: Video: hevc (Main), yuv420p, 1920x1080, ...
Enter fullscreen mode Exit fullscreen mode

— 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"
Enter fullscreen mode Exit fullscreen mode

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.

Top comments (0)