ONVIF Motion Recording: Pre-Detection Buffer Not Functional

[origin2000]

Problem
When ONVIF motion recording triggers, recordings have a long and uncontrollable pre-roll ( more than 2 minutes) because start_mp4_recording_with_trigger() opens a fresh RTSP connection to go2rtc, which delivers from the start of its own internal segment buffer regardless of the configured pre_detection_buffer value.

Current State (from source audit)
The architecture for a proper fix already exists but is incomplete:

• packet_buffer_t and feed_packet_to_event_buffer() are implemented and correct
• motion_recording_context_t already holds a packet_buffer_t *buffer and the full state machine (BUFFERING → RECORDING → FINALIZING)
• However, flush_packet_callback() in onvif_motion_recording.c is a stub that only logs — no packets are actually written
• feed_packet_to_event_buffer() has no callers outside its own file — the buffer is allocated but never filled
• The flush happens before the mp4_writer exists, so even a real callback would have nothing to write to

The working reference is unified_detection_thread.c, which runs a persistent RTSP reader per stream, fills packet_buffer continuously, and flushes directly into an mp4_writer on detection — no new go2rtc connection needed.

Proposed Fix
Port the unified_detection_thread approach to the ONVIF recording path:

1. Add a persistent feeder thread per ONVIF stream (permanent RTSP connection to go2rtc)
2. Feed every packet into the existing packet_buffer via feed_packet_to_event_buffer()
3. Implement the real flush_packet_callback (using mp4_writer_initialize + mp4_writer_write_packet, same pattern as UDT)
4. On motion event: create mp4_writer first, flush buffer, then continue writing live packets directly — no new RTSP connection

This completes Phase 2 of ONVIF_MOTION_RECORDING.md (Buffer Management).

Question
Are you OK with me submitting a PR for this? Happy to align on anything before I start.

[matteius]

Hey @origin2000 that seems to make sense, and I'd love if you wanted to make a shot at a PR.

[origin2000]

OK, will give it a try. Once I have something figured and tested I'll post a PR. May take some time though.

[dpw13]

Before you spend too much time on that PR, I'm not actually sure the "ONVIF motion recording" system makes sense at all. The unified detection thread (UDT) code already has all of this stuff implemented (at least, it appears to be implemented). The packet buffer, pre- and post-detection packet buffer, file rotation, the whole thing. I think it makes more sense to treat built-in detection events and ONVIF detection events basically the same and manage the mp4 streaming using the same code path.

It looks to me like a UDT is already spun up, backed by the same go2rtc stream. In fact I see the UDT heartbeat logs:

[2026-04-13 23:40:39.013] [INFO] [Detection] [cam_a] [cam_a] Heartbeat: state=BUFFERING, packets=154800, detections=4, last_check=8s ago
[2026-04-13 23:40:44.384] [INFO] [Detection] [cam_b] [cam_b] Heartbeat: state=BUFFERING, packets=154851, detections=4, last_check=4s ago

Looking through the code, I can't think of a reason for the ONVIF stream to be managed any differently from any other RTSP stream; the only thing that's different is the detection mechanism.

[matteius]

Yeah that makes a lot of sense @dpw13 and is the architectural direction we should head in, that ONVIF motion recording is a detection mechanism.

[origin2000]

I have spent a lot of time on the UDT ONVIF Detction the last days. Whereas the UDT itself looks architectually OK, there is interference with ONVIF reconnect, uncontrolled buffer flashes from go2rtc and as a result distorted recordings with pre-recordings of several mintues. I currently run tests. If this turnes out to be stable with timely quality videos, I'll post a PR tomorrow or the day after.

[origin2000]

In regards to ONVIF motion recording. I had it switched on which resulted in competing recordings with the detection mode. I disabled it for now and focused in getting detection mode right.

[dpw13]

Yep that's my concern; the ONVIF motion recording is mostly duplicated code. I've got a PR in work that removes that code. It shouldn't have any impact on the UDT-based detection mode; it would essentially just remove the "ONVIF motion recording" option entirely.

It's interesting that you get long pre-recordings. I definitely see logging indicating that a lot more packets are in the packet buffer than are needed for pre-buffering, but my recordings seem to come out with approximately the expected duration. I wonder if there's anything different about the RTSP stream or go2rtc itself. My cameras are currently set up for 4k 15 fps, maybe that has an impact?

What issues are you seeing with ONVIF reconnection?

Looking forward to your PR!

[origin2000]

@dpw13 I couldn't provide a short, crisp answer to your question "What issues are you seeing with ONVIF reconnection?", so u urged me to get the PR ready ;-)