G100 RTSP main stream (ch1) sends broken / keyframe-less H.264 — unusable in NVRs like Frigate, while HKSV and the app look perfect (likely firmware bug)
Posting this in case others are fighting the same thing, and hoping it gives the Aqara devs something specific to target. I spent several days assuming this was my Wi-Fi or my network. It wasn’t — and I can now isolate it down to the camera’s RTSP encoder.
Setup
Several Aqara G100 cameras (8x) feeding Frigate (running as Fregata on a Mac mini) over RTSP, alongside HomeKit Secure Video. HKSV and the Aqara app are flawless on every camera. But in Frigate, several cameras constantly flap between recording and unavailable, drop recordings, and miss person detections.
Each camera exposes ch1 (main, ~1080p), ch2 (720p), and ch3 (360p). RTSP enabled per-camera in the app (“RTSP LAN Preview”).
The symptom
On the affected cameras, the ch1 main RTSP stream stops emitting valid keyframes / SPS-PPS parameter sets. Any ffmpeg-based consumer (Frigate, go2rtc, raw ffprobe) floods:
[h264] non-existing PPS 0 referenced
[h264] decode_slice_header error
[h264] no frame!
[rtsp] Could not find codec parameters for stream 1 (Video: h264, none): unspecified size
It often can’t even determine the resolution. Frigate joins the stream, waits for a keyframe that comes extremely rarely or never, hits its ~20s no-frames watchdog, restarts, and flaps forever.
How I isolated it (this is the important part)
I pulled the stream with raw ffmpeg, completely bypassing Frigate, go2rtc, and my config — so there’s nothing left to blame but the camera and the network path:
ffmpeg -hide_banner -rtsp_transport tcp -i "rtsp://USER:PASS@CAMERA_IP:8554/ch1" -t 15 -f null -
- On a broken camera, ch1 floods the PPS errors above and decodes ~0–9 frames in 15 seconds.
- On a healthy G100, the same command on ch1 locks
1920x1080and decodes ~300 frames cleanly. - On the exact same broken camera,
ch2(720p) locks1280x720instantly and decodes cleanly.
So it’s per-unit, per-channel: specific cameras whose ch1 encoder has gone into a bad state, while ch2 on those same cameras is fine, and ch1 on my other G100s is fine.
(Note: a short “non-existing PPS” burst at the very start is normal — ffmpeg joins mid-GOP and has to wait for the next keyframe. The bug is that the keyframe/parameter set then never reliably arrives. Let the command run the full 15s before judging.)
Key points for the devs
- It is not signal. The affected cameras were pulling −20 dBm RSSI on a close AP and loading instantly in HomeKit and the Aqara app. A strong radio link carrying a broken H.264 bitstream is still broken.
- It is stateful and sticky. A camera reboot does not fix it. Toggling RTSP off/on in the app does not fix it — and notably that toggle does not roll the RTSP username/password (the app says only a factory reset does that). Bumping ffmpeg
-analyzeduration/-probesizealso does nothing. - It degrades on its own. At least one of mine was healthy on ch1 one day and broken the next, with no setting change on my end. So something in firmware drops into a bad ch1 state and doesn’t recover. (If this correlates with a staggered OTA, that would explain a lot — see my question below.)
- HKSV is completely unaffected, which is exactly why this hides. The camera “looks perfect” everywhere except a real continuous RTSP/NVR consumer, so it’s easy to misdiagnose as a network problem for days.
This isn’t just me, and isn’t just Frigate
Same fingerprint shows up across unrelated stacks, which points squarely at the camera firmware rather than any one integration:
- go2rtc #1775 — a G100 owner reported ch1 flooding the identical
non-existing PPS 0 referenced/no frame!errors in ffmpeg, while the same stream played fine in VLC and Scrypted. That detail suggests the video may still be encoding but the parameter-set signaling isn’t ffmpeg-consumable. - Frigate discussion #23041 — the sibling G410 doorbell, same PPS error flood, dropping offline until Frigate is restarted, while the Aqara app shows it working fine.
- Aqara forum “Aqara g100 rtsp bug” — a user running three G100s into a Dahua recorder via RTSP reports the recorder stops recording after a while unless reloaded, while HomeKit and the app stay perfect. That’s the same symptom on dedicated NVR hardware, not a Mac and not Frigate.
Questions for the community / Aqara
- Is anyone else seeing G100 ch1 go keyframe-less in an NVR (Frigate, Blue Iris, Synology, Dahua, etc.) while HKSV / the app stay perfect?
- Does it correlate with a specific firmware version? I’ve noticed G100 OTA rolls out staggered (different cameras on different versions), and the recent 4.5.x line has been rocky. If the broken units share a firmware version and the healthy ones don’t, that’s a strong lead.
- Does a factory reset durably restore ch1 for you, or does the bad state come back?
- Does a specific ch1 bitrate / resolution setting trigger it?
My workaround for now
Point the NVR at ch2 (720p) instead of ch1. It decodes cleanly and is plenty for person detection, and I keep full-resolution recording via HKSV separately. But 720p shouldn’t be the only reliable option on a 2K camera — ch1 needs a firmware fix so it reliably emits keyframes / SPS-PPS on the RTSP main stream.
Happy to share full ffmpeg logs and exact firmware versions per camera if it helps track this down.
