MP4 Corruption and HTTP Buffer Truncated Errors - v0.26.3

[DevlTz]

1. I am getting frequent warnings: [WARN] HTTP response truncated (buffer too small) followed by Stream not found in go2rtc.

Observed Behavior: It seems that when go2rtc sends a large JSON payload (especially when snapshots are ~230KB), the internal buffer cuts the response. This causes LightNVR to lose track of the streams, even though they are active in go2rtc.

• Question: Is there a way to increase the internal HTTP buffer size via config, or is this a hardcoded limit?

2. Corrupted MP4 Recordings
   Despite successful detection logs (Successfully detected 1 objects), the generated MP4 files are corrupted.

The Symptoms: * The UI shows a "Video Error" event.

• Downloading the file and trying to play it in VLC fails (file is malformed).

Logs show Starting second pass: moving the moov atom to the beginning of the file, but it seems the finalization fails to write a valid header.

• Attempted Fixes (No success):

• Forced transcoding with ffmpeg:...#video=h264.

• Changed permissions to 777 on all /data subdirectories.

• Tested with setenforce 0 (SELinux) to rule out security blocks.

• Verified disk space (470GB free) and RAM (usage < 10%).

logs

[2026-02-23 14:52:29] [WARN] HTTP response truncated (buffer too small)
[2026-02-23 14:52:29] [INFO] Stream xxx-1 not found in go2rtc (status=200)
[mp4 @ 0x7f59d46cac80] Starting second pass: moving the moov atom to the beginning of the file

I suspect the MP4 writer might be struggling with the faststart process on this specific kernel/environment, or the truncated buffer is causing intermittent stream drops during recording.

[matteius]

No, this is a regression -- will report back when fixed.

[matteius]

Please try v0.26.4 -- I am having better results now @DevlTz

[DevlTz]

Hi @matteius, thank you so much for the quick replies and for all the time and dedication you've put into this; I really appreciate it.

I'm using the current and latest version: 0.26.5!

1. The Symptoms

• Grey Screen on Playback: Live view works, and detections are triggered correctly. However, attempting to play the footage results in a grey screen or a "Video error" toast notification.
• Broken Pipe: The logs are flooded with Write error: broken pipe and h264 decode_slice_header error, indicating the recording process is crashing mid-stream.
• Codec Mismatch: Debug logs show streams: codecs not matched: video:H264 => audio:ANY.

2. The "Ghost" Duration Bug

I have attached a screenshot demonstrating a UI/Playback anomaly that might be related to corrupted file headers:

• The recording list correctly displays the configured duration (e.g., 00:30s).
• However, the moment I open the video player in the UI, the timeline glitches and updates the duration to 00:42s.
• This discrepancy suggests that the MP4 atom/moov header is not being written correctly, likely due to the "broken pipe" interruptions.

3. Attempted Fixes (Failed)

Suspecting a "dirty" RTSP stream from the older cameras, I attempted to force ffmpeg transcoding to clean up the video feed before recording.

I updated the stream configuration in the Web UI to use libx264 and opus:

ffmpeg:rtsp://user:pass@IP:554/path...#video=libx264#audio=opus#transport=tcp

The Issue:
Even after applying this configuration (and verifying it in go2rtc.yaml), the logs indicate that LightNVR is attempting to load multiple sources simultaneously for the same camera (both the raw rtsp:// stream AND the ffmpeg: stream).

Relevant Logs:

[INFO] Adding stream with multiple sources: ... src=rtsp://... & src=ffmpeg:...
...
[ERROR] on_chunk_write_complete: Write error: broken pipe
...
[h264 @ ...] deblocking_filter_idc 10 out of range
[h264 @ ...] no frame!
...
WRN [rtsp] error="streams: codecs not matched: video:H264 => audio:ANY"

Important note: this problem only happens on a subset of cameras — specifically some older/legacy models. Newer cameras appear to record and play back fine.

Questions

It appears the system keeps reverting to or merging with the raw RTSP configuration, preventing the FFmpeg transcoding from isolating the bad stream effectively.

Is there a way to strictly enforce FFmpeg transcoding for recording and prevent LightNVR from attempting to connect to the raw RTSP stream in the background? If so, what configuration changes or workarounds would you recommend? (If there are specific log lines or config snippets I should paste, tell me which and I’ll add them.)

Thank you for your help.

---

[DevlTz]

---

Critical Discovery? "0 FPS" Detection & Event Timing!

I performed the specific tests you asked for, and I believe I found the root cause in the logs combined with a specific behavior in the UI.

1. The Smoking Gun: "0 FPS" Detection
I noticed a distinct pattern in the logs comparing my working cameras vs. the broken ones in v0.27.0. It seems the new native handler isn't parsing the RTSP headers correctly for these older Axis models:

• Working Camera (Newer hardware):
  [INFO] Detected video params: 1280x720 @ 60 fps, codec=h264 (Works perfectly)
• Broken Camera (Axis M1011):
  [INFO] Detected video params: 640x480 @ 0 fps, codec=h264 (FAILS)

2. Detection Works, Playback Fails (Crucial Observation)
Here is the strange part: The detection logic is actually working perfectly (or almost).
When someone walks in front of the camera, the system registers the event in the UI timeline at the exact correct timestamp. This proves the RTSP stream is alive and the system is receiving frames.

However, when I try to view that recording, it fails (corrupted file/grey screen).
This strongly suggests that MAYBE while the system receives the images, the recorder/muxer fails to write a valid MP4 container because it lacks a valid timebase (due to the 0 fps detection), resulting in broken pipe errors.

3. Audio & Recording Tests
Regarding your request to disable audio/recording:

• Audio: "Record Audio" was already unchecked in the UI, yet the logs show v0.27.0 still attempting to verify audio streams, causing codecs not matched errors.
• Live View Only: Even with recording disabled, the logs still flood with timeouts, confirming the issue is in the ingestion/stream parsing layer, not the disk writing.

---

Since the system sees the events but writes broken files due to the "0 FPS" reading, is there a way to force/inject the FPS value in the go2rtc configuration for v0.27.0? Or a specific argument I can pass via the Stream URL to help the parser identify the headers correctly?

I am available to run more tests to get this fixed!

---

[matteius]

Discussion #141 — Root Cause Analysis & Fixes
What was happening (the chain reaction)
DevlTz's cameras (legacy Axis M1011) expose an H.264 stream with no compatible audio track. go2rtc logs codecs not matched: video:H264 => audio:ANY because it cannot negotiate audio for those cameras. The rest of the failures follow directly from this:

Preload hangs → CURL timeout — go2rtc_api_preload_stream issued a PUT /api/preload?src=…&video&audio request, asking go2rtc to keep a consumer alive for both video and audio. go2rtc stalled trying to find audio, so the call never returned. After 10 s CURL fired a timeout error.

Broken pipe → corrupted MP4 — With the producer unstable or not fully started, the recording thread opened an RTSP connection to go2rtc's relay, which then dropped the connection mid-stream. That caused on_chunk_write_complete: Write error: broken pipe, which cut off av_write_trailer / the faststart second pass, leaving a corrupt (no moov atom) file.

0 FPS logged — Axis M1011 (and many older cameras) don't put a frame-rate field in their RTSP SDP. FFmpeg leaves avg_frame_rate = 0/0, so the log shows 640x480 @ 0 fps. This doesn't directly corrupt MP4s (FFmpeg uses time_base from the SDP, not FPS) but it's a diagnostic signal that stream metadata is incomplete.

Fix 1 — src/video/go2rtc/go2rtc_api.c
go2rtc_api_preload_stream now tries video&audio first (10 s timeout). If that times out or gets a non-200, it logs a clear warning and immediately retries with video only. Video is all that's needed to keep the producer alive for HLS and motion/object detection, so cameras with incompatible audio now work cleanly instead of timing out.

Fix 2 — src/video/unified_detection_thread.c & src/video/mp4_writer_thread.c
Both FPS-detection blocks now follow the same fallback ladder:

avg_frame_rate (when non-zero)
r_frame_rate (the container-level rate, usually reliable even when avg is absent)
Hard default of 15 fps — so the database always stores a meaningful value and the log no longer shows "@ 0 fps"

-- Just pushed these changes up to main, not sure if you have a way to build directly that or if you need me to publish new image?

[DevlTz]

Your analysis matches our findings perfectly. The chain reaction (Audio Search → Timeout → Broken Pipe) explains exactly why the system was unstable even with "Record Audio" unchecked in the UI. And the FPS fallback logic is a brilliant addition for these legacy streams.

Regarding the build:
I do not have a build environment set up on this server to compile from source. Could you please publish a new Docker image?
Let me know the tag (e.g., v0.27.1) once it's pushed, and I will pull it immediately to test.

Thank you so much for the quick turnaround.

[matteius]

0.27.1 has been built

[DevlTz]

Hi !! I just pulled and tested v0.27.1.

The Good News:
The system stability is vastly improved. The CURL Timeouts are completely gone, meaning the audio fallback logic is working exactly as intended. The server itself is no longer crashing.

The Remaining Issue (Corrupted H.264 Payload):
While the system is stable and seems to be attempting to finalize the MP4 files (I can see Starting second pass: moving the moov atom to the beginning of the file), the actual recordings from the legacy Axis cameras remain unplayable. When I try to view them in the Recordings tab, they fail to load, and the log throws a bunch of broken pipe errors during playback attempt.

Looking closer at the logs during stream ingestion, i think the decoder is choking on the actual H.264 stream payload coming from these older Axis (M1011) models:

[h264 @ 0x7f00f0005800] deblocking_filter_idc 12 out of range
[h264 @ 0x7f00f0005800] decode_slice_header error
[h264 @ 0x7f00f0005800] no frame!

Still the same... 😔

This repeats endlessly. I have already ensured the camera's GOV length is set to 15 (matching the 15fps limit), but the stream remains "dirty" for this decoder.

It appears the new handling is rejecting or failing to decode the specific H.264 Baseline/Main profile these legacy cameras output, resulting in "empty" or corrupted MP4s despite the moov atom being written.

Is there a specific FFmpeg flag or go2rtc parameter that i can inject via the Stream URL to make the decoder more tolerant of these older H.264 streams.

One quick question regarding the FPS fallback:
You mentioned earlier that the hard default was set to 15 fps for cameras that fail to auto-detect. Did you end up setting it to 15 fps or 30 fps? I'm asking because I noticed it defaulting to 30 fps on my end. Just wanted to clarify if that's expected behavior!

[DevlTz]

Updates!!!

Please ignore the part about the H.264 payload/decoder choking in my message above. I was looking at the wrong log trace for the grey screen issue.

I did a deep dive into the latest v0.27.1 logs during a recording event, and the stream ingestion is actually fine. The MP4 corruption (Grey Screen) is being caused by a phantom audio track issue in the new pipeline.

Here is the exact sequence of what is happening when I use the native H.264 stream (videocodec=h264#audio=ignore):

1. The stream connects perfectly, and WebRTC Live View works flawlessly.
2. The detection triggers, and the MP4 writer starts successfully.
3. Then, go2rtc completely panics trying to find an audio stream that I explicitly told it to ignore, spamming this:
   WRN [rtsp] error="streams: codecs not matched: video:H264 => audio:ANY" stream=Dummy-Cam
DBG [exec] run rtsp args=["ffmpeg"... "rtsp://127.0.0.1:8554/Dummy-Cam?audio&source=ffmpeg:Dummy-Cam%23audio%3Dopus"
Error opening input file rtsp://127.0.0.1:8554/Dummy-Cam?audio...
4. The system still finalizes the file (moving the moov atom), but because of this underlying audio track failure during the muxing process, the resulting MP4 is structurally broken and shows a Grey Screen.

The Bug: The v0.27 MP4 writer/pipeline seems completely incapable of creating a clean Video-Only MP4. It keeps spawning FFmpeg sub-processes trying to force an Opus audio track into the container, even when #audio=ignore is set, ultimately corrupting the final file.

Probably, if there's any way to force the MP4 writer to strictly write video frames and completely skip the audio muxing attempt, maybe it works?

[matteius]

the config to disable audio being passed to go2tc is possibly fixed in 0.27.3

[DevlTz]

Hi @matteius,

First of all, I want to sincerely apologize for spamming this thread so much over the last couple of days! I really appreciate your patience and all the blazing-fast updates. I'll step back now and let you work, but I wanted to leave this final piece of the puzzle here.

I just tested v0.27.3 and we have a huge victory: The audio panic loop is completely gone! The logs are now perfectly clean. The MP4 writer initializes, flushes packets, and closes perfectly without a single broken pipe or codec mismatch error.

---

THE FINAL HURDLE:
Although the files are being saved properly (sizes look normal, ~1MB ), the MP4s are still unplayable (Grey Screen). To isolate the issue, I downloaded the new files and tested them locally in VLC Media Player, and they still only show a solid grey screen (corrupt file).

A humble theory / GUESS:
Since WebRTC plays the stream live flawlessly, the raw H.264 video data is definitely good. While trying to understand why a healthy stream would result in a grey MP4, I read that sometimes this happens if the SPS/PPS headers (extradata) don't get properly written into the MP4 container (moov atom). Could it be that the new v0.27 MP4 muxer is somehow missing these headers for these older baseline H.264 streams? Just a thought that might save you some time!

---

Again, I'm sorry for being a bother! You've already fixed the core stability issues and the audio bugs, which is an amazing step forward. I will leave you to it, but if you ever need me to test or even provide more logs for these legacy cameras, I'm fully available here

Thanks again for your hard work on this project!

[DevlTz]

Hi again, sorry to follow up so soon! I was able to dig deeper into the grey screen issue with some help, and I found something more concrete than my SPS/PPS theory.

Root cause identified: framerate mismatch between SDP and LightNVR detection

These older Axis cameras advertise a=framerate:15.0 in their SDP, but LightNVR is detecting and logging them as 30fps:

Remember when I asked you if the standard was to maintain 30fps or 15fps?

[INFO] Detected video params: 640x480 @ 30 fps, codec=h264

This mismatch causes incorrect timestamps in the MP4 muxer, producing unplayable files.

I can confirm this via the go2rtc API, which shows the real SDP from the camera:

a=framerate:15.0
profile-level-id=420029 (H264 Baseline)
sprop-parameter-sets=Z0IAKeNQFAe2AtwEBAaQeJEV,aM48gA==

The ffmpeg consumer (Lavf61.7.100) reads the stream via internal RTSP without any timestamp correction flags. Adding -fflags +genpts to the ffmpeg input args would likely fix it by regenerating timestamps from the actual frame data.

Affected cameras: All legacy Axis cameras on our setup (Baseline H264, 15fps) — live view works perfectly, only recordings are broken.

Suggested fix: Either read framerate from the SDP correctly, apply -fflags +genpts automatically when framerate mismatch is detected, or allow custom per-stream ffmpeg input flags.

[matteius]

Amazing!!! I look forward to looking more deeply this evening -- for context, I believe the mp4 moov atom logs have something to do with some past requirements I set around beginning and ending recording on a keyframe, and trying to ensure no gap between recordings. If you happen to already have a code patch in mind, feel free to open a PR, otherwise I will look more deeply when I can.

[matteius]

When you have time, try 0.27.4