AI: Incomplete fix for MP4 duration bug — 0.41.4 still writes ~59s duration (error factor == fps) on MJPEG→H.264 transcoded streams

[netmms]

First — thank you for the incredibly quick action on the previous timebase and timeline-logging fixes. The turnaround on both was genuinely impressive, and the regression test you added for the 5/90000 case is exactly the right kind of coverage. This is a follow-up reporting a remaining case that the 0.41.3 fix doesn't cover.

(Note: I use AI assistance to help investigate and write up these reports, hence the AI: prefix — but all logs, tests, and reproductions below are from my actual running system.)

Summary

After updating to 0.41.4 (confirmed: LightNVR v0.41.4, build 2026-09-02), the MP4 duration bug persists on all cameras, on fresh recordings (I deleted all prior recordings first to rule out stale files). 300s segments still report ~59s container duration.

Symptom

ffprobe on fresh post-update files:

espcam7/recording_20260904_050120.mp4  → duration = 59.200000
espcam1/…                              → duration = 59.400000

The database has correct durations; only the MP4 container metadata is wrong:

SELECT (end_time - start_time) AS real_duration, file_path FROM recordings WHERE is_complete=1 ORDER BY id DESC LIMIT 3;
-- real_duration ≈ 300 for all

Full video data is present — a -c copy remux recovers the complete duration — so this is purely wrong container-duration metadata.

Why the 0.41.3 fix doesn't cover this case

The 0.41.3 fix targeted an input→output timebase mismatch (5/90000 input normalized to 1/90000 output) and rescaled packets accordingly.

However, my streams' RTSP output already reports time_base=1/90000 — identical to the muxer output timebase — so there's no mismatch left to rescale, and the fix is a no-op here, yet duration is still wrong.

ffprobe -rtsp_transport tcp rtsp://127.0.0.1:8554/espcam1:

Input #0, rtsp, from 'rtsp://127.0.0.1:8554/espcam1':
  title           : go2rtc/1.9.14+dev.
  Stream #0:0: Video: h264 (High 4:2:2), yuvj422p, 800x600, 5 fps, 5 tbr, 90k tbn, start 0.800000
  r_frame_rate=5/1
  time_base=1/90000

Key clue: the error factor equals the frame rate

The error ratio is 300 / 59 ≈ 5.08 ≈ the frame rate (5 fps).

This suggests the remaining miscalculation is independent of the timebase mismatch that was fixed, and instead lies in how per-frame duration/PTS increments are computed — the container duration appears under-written by a factor equal to the fps. The timebases now match, but a factor of fps still seems to be dropped in the final duration calculation.

Pipeline

All affected cameras are MJPEG sources transcoded to H.264 by go2rtc's ffmpeg, via the generated source:

ffmpeg:http://<cam-ip>:8080/#video=h264

• Real capture/serve rate: ~5 fps (ESP32-based MJPEG cameras)
• go2rtc: 1.9.14+dev
• Output: H.264, timebase 1/90000

Reproducibility

100% of MJPEG→H.264 transcoded cameras, every fresh segment, on 0.41.4.

Happy to provide a sample file, full -show_streams/-show_format output, or test a patch.

[matteius]

Reproduced and fixed in the bundled go2rtc fork.

The remaining duration error was upstream of the LightNVR MP4 muxer. For an HTTP MJPEG source without usable timestamps, the go2rtc FFmpeg process assigned each frame 3,600 ticks at a 90 kHz time base (40 ms / 25 fps), even though frames arrived every 200 ms. A 5 fps source was therefore compressed by almost exactly 5x before LightNVR received it. The LightNVR time-base rescale correctly becomes a no-op for 1/90000 -> 1/90000, and genpts cannot repair timestamps that are already present.

Fixes:

• go2rtc fork: opensensor/go2rtc@4381b7ce
• LightNVR submodule update: 960d8f4f

The fork now supports a validated HTTP input framerate parameter and applies it as input-side -r, before transcoding. For these cameras, update the source to:

ffmpeg:http://<cam-ip>:8080/#framerate=5#video=h264

The patched binary was tested end to end with a synthetic 5 fps HTTP MJPEG source. Its H.264 RTSP output now reports 5 fps and packets advance by 18,000 ticks / 200 ms at 1/90000, instead of 3,600 ticks / 40 ms.

Leaving this open pending confirmation against the ESP32 cameras.

[netmms]

Thank you — really appreciate the fast turnaround on this, and the clear write-up of the root cause (the go2rtc ffmpeg assigning 25fps/3600-tick timestamps to a ~5fps MJPEG source). That explains perfectly why the LightNVR-side rescale was a no-op and why genpts couldn't help — the timing was already baked in wrong upstream.

I can see the fix landed in 0.41.7 ("Preserved MJPEG transcode timing to prevent frame rate inconsistencies during video streaming"). I'm currently on the Home Assistant add-on, which is still at 0.41.6, so I can't test yet — waiting for the add-on to catch up to 0.41.7.

As soon as the add-on updates, I'll:

Update to 0.41.7
Change my camera sources to the #framerate=N#video=h264 form
Verify with ffprobe that a 300s segment now reports ~300s (instead of ~59s), and confirm the RTSP output shows correct packet spacing

Will report back with results from the actual ESP32 cameras. Thanks again for the quick fix.

[netmms]

Confirmed fixed on real ESP32 hardware — thank you.

Tested 0.41.8 end-to-end against the actual ESP32/ESP32-S3 cameras. With the source set to #framerate=N#video=h264 (N matched to each camera's real rate), durations are now correct. ffprobe on two fresh segments:

Steady camera (ESP32-CAM / OV2640, 800×600, framerate=5):

duration=290.200000
r_frame_rate=5/1
avg_frame_rate=5/1
nb_frames=1451   → exactly 5.0 fps over 290.2s

A ~5-minute segment reports ~4:50 — the small sub-5:00 is just normal per-frame jitter / keyframe-boundary rounding on a software-timed capture, not the bug. Perfectly acceptable.

Variable-rate camera (ESP32-S3 with a cheap YUV sensor, 320×240, framerate=2):

duration=310.500000
r_frame_rate=2/1
avg_frame_rate=1246/621   → ~2.007 fps actual
nb_frames=623 over 310.5s

A full ~5-minute segment, correct duration. This one was the wildcard — its real rate is genuinely variable, but the ESP's own log (Received 111 images in last 60s ≈ 1.85 fps) gave me a measured average, and declaring framerate=2 landed it accurately.

Before the fix, both of these reported ~59s (the ~5× compression). Both are now correct. The fix holds — happy to close this.

One observation for the future (not a blocker): the fix requires the user to manually determine and declare each camera's real frame rate via #framerate=. For steady cameras that's easy (declare the configured fps). For variable-rate MJPEG sources it took measuring the actual average (via the ESP's frame-count log) and some trial and error — declaring the wrong value produces confusingly wrong durations (e.g., for the variable camera, framerate=5 gave 2:45 and framerate=9 gave 1:17 — non-monotonic, since the declared rate fought the genuinely variable input).

It would be a nice future enhancement if the framerate could be auto-deduced — e.g., the transcoder measuring the actual inter-frame arrival timing of the incoming MJPEG stream over the first few seconds and using that, rather than requiring a hardcoded #framerate=. That would make it work correctly out-of-the-box for both steady and variable sources without user tuning. Fully understand that's non-trivial (variable-rate sources make "the" framerate ambiguous), and the manual parameter is a perfectly good solution in the meantime — just flagging it as a potential polish item.

Thank you again for the fast, thorough work across all three issues — the diagnosis and turnaround have been excellent.

[matteius]

Thanks for testing this on the actual ESP32 and ESP32-S3 cameras and sharing the ffprobe results. Your confirmation on 0.41.8, with #framerate=N#video=h264 matched to each camera's measured rate, is enough to close this as fixed. I appreciate the detailed reports and follow-through across these issues.

The automatic frame-rate/timestamp handling suggestion makes sense as a future enhancement, especially for variable-rate MJPEG sources. An initial average may still drift as the capture rate changes, so that deserves a separate investigation. For now, the explicit #framerate= setting remains the supported solution for this case. If the original duration compression returns with the correct setting, please let us know and we can reopen this.

Also, if you're getting value out of lightNVR, especially if you're relying on it in a production environment, please consider sponsoring the project through GitHub Sponsors, even for a few months. That support helps sustain development, testing, and maintenance. It's entirely optional, and your testing and bug reports are already appreciated.

Closing as completed. Thanks again!