Add native Reolink/Baichuan support - #2413
Conversation
|
"Use a separate camera connection for talkback" Maybe I misintrepet this, but is this beneficial? Less simultaneous connections equals more stable Reolink camera. |
Good question. A separate connection is not required by the protocol; I chose it to isolate talk setup and teardown from preview, and it permits talk alongside main-stream preview in testing. However, I have not established that it is more stable than sharing the authenticated preview connection and it consumes an additional transient camera session, as you said. Your connection-limit concern is valid. This was me prematurely optimizing. I'm going to test shared-client talk while retaining an independent logical talk lifecycle; unless that exposes a firmware-specific conflict, shared should be the default. |
2 participants
** This was generated by a mix of AI suggestions and human editing **
This PR adds a native
reolink://source using Reolink's Baichuan protocol over direct LAN TCP or local UID-discovered LAN-P2P. It carries video, audio, and two-way audio directly from the camera, without using RTSP, RTMP, HTTP-FLV, or FFmpeg as the camera input.One configured source can feed recording, live view, and other go2rtc consumers through the normal fanout. Users configure the camera once, then choose its streams, lenses, audio, and talkback as native features.
Why it exists
Without a native source, this camera setup needed a continuously running FFmpeg process for each configured input to bridge Reolink's HTTP-FLV feed into go2rtc. Direct Baichuan input removes those processes, reduces CPU use, and makes Reolink streams and talkback part of go2rtc's normal source model.
It also addresses the failures that motivated this work: malformed or incomplete keyframes, timing discontinuities, and downstream decoder/FFmpeg crashes when using full-resolution streams. The adapter validates access units and codec parameter sets, suppresses invalid video, resumes only on a valid keyframe with established parameter sets, and keeps RTP timestamps moving forward across reconnects. In final testing, 4K HEVC segments had the expected frame and keyframe cadence, complete PTS/DTS, no DTS regressions or non-positive video durations, and clean FFmpeg 8.1 strict decoding. FFmpeg 8.1 was used only to validate the output; the source does not invoke FFmpeg or require a particular FFmpeg version. The observed keyframe, timing, and transport-related crash symptoms did not recur in the tested production workload.
Performance
The prior non-Baichuan setup used go2rtc's generic HTTP-FLV support through one source-side FFmpeg process per configured source, then loopback RTSP. Native Baichuan removes that process. Matched tests on the same cameras and Intel Core i7-12700H host preserved codec, resolution, frame rate, keyframe cadence, and strict-decode results:
CPU points are Frigate-reported process CPU attributable to one source path, not whole-host percentages. Results may differ elsewhere, but every matched profile used less CPU.
Validation
Hardware testing covers E1 Zoom/E340 cameras and both lenses of dual-lens TrackFlex cameras: main and sub streams, TCP and same-LAN UID/LAN-P2P connections, H.264, H.265, AAC, camera ADPCM, and repeated talkback setup and teardown. A production system has exercised 16 profiles from six cameras.
Verification includes focused normal and race tests, malformed-input tests, nine fuzz targets with about 12 million final executions, vet, strict FFmpeg decode and timestamp checks, and Linux, Windows, macOS, and FreeBSD builds.
This implementation versus fzurita
The fzurita branch showed that native Baichuan support in go2rtc is practical. This PR covers the same core streaming and talkback use case while keeping Reolink work isolated from the rest of go2rtc. It also adds stricter safeguards and recovery behavior. The implementations differ at the protocol, lifecycle, and shared-code boundaries, so this is submitted as an independent alternative rather than a patch stack.
The implementation lives in three new packages:
pkg/baichuanpkg/reolinkinternal/reolinkOutside those packages, existing files change only to register and document the source. Shared H.264, H.265, RTP, WebRTC, and stream-lifecycle code is untouched; the pinned fzurita branch changes several of those shared paths. That limits the blast radius: Reolink protocol and recovery changes stay on Reolink camera paths. Configuration, camera sharing, media conversion, talkback, lifecycle, and health checks are separated for review and maintenance. This follows go2rtc's usual thin internal registration plus protocol/adapter package split.
This PR also adds safeguards that are absent from the current fzurita branch. The protocol safeguards do not restrict supported resolutions, bitrates, codecs, or normal go2rtc fanout.
fcbd6109Performance versus fzurita
For a direct Baichuan comparison, both implementations were built with Go 1.24 and identical Linux build flags, then tested against the same 3840x2160/20 HEVC camera. Each ran alone in a Debian 13 Proxmox LXC with 8 assigned cores and 16 GiB RAM on the same host.
CPU use was close enough to treat as equivalent at this load. This PR used 2.6 MiB less memory with one viewer and 1.4 MiB less with two. Both produced matched recordings with complete, forward-moving timestamps and no strict-decode errors. These are short, single-camera measurements rather than fleet-wide performance claims.
The feature and engineering differences—not a claimed universal speed advantage—are the main reasons for this implementation.
Implemented feature coverage
The comparison below uses the current
fzurita/reolink_protocol@fcbd6109. This PR remains experimental; checks indicate implemented behavior, not universal camera or firmware support.main,sub, andexterncamera streamsUnsupported (so far)
Baichuan should be used only on a trusted local network.
AI disclosure
This implementation was developed with assistance from OpenAI Codex and Anthropic Claude. Its architecture, acceptance criteria, and engineering standards were human-directed. The final branch was reviewed, tested, benchmarked, and exercised on physical cameras. The code was repeatedly reduced and reorganized for reviewability without removing the protocol, safety, lifecycle, or test coverage described above.