administrator/frigate
1
0
Fork 0
mirror of https://github.com/blakeblackshear/frigate.git synced 2026-10-12 01:32:48 +03:00
Code Issues Actions 3 Packages Projects Releases Wiki Activity

Miscellaneous fixes (0.18 beta) (#23828)
CI / AMD64 Build (push) Canceled after 0s
Details
CI / ARM Build (push) Canceled after 0s
Details
CI / Jetson Jetpack 6 (push) Canceled after 0s
Details
CI / AMD64 Extra Build (push) Canceled after 0s
Details
CI / ARM Extra Build (push) Canceled after 0s
Details
CI / Synaptics Build (push) Canceled after 0s
Details
CI / Assemble and push default build (push) Canceled after 0s
Details

Browse Source 
* widen the logger name field in the per-process log level settings

* add details to timestamp error faq

* tweak genai docs

* tweak vector language

* Combine Qwen3.5 and Qwen3.6 listings

* fix openvino yolox detector crashing on every detection

The intermediate (N, 7) array in the yolox branch shadowed the pre-allocated (20, 6) detections buffer, so writing a detection into it raised "could not broadcast input array from shape (6,) into shape (7,)" on the first frame with anything above the confidence threshold. An empty frame also returned a (0, 7) array instead of the (20, 6) buffer.

Regressed in #13794, which renamed the intermediate from dets to detections as part of a cspell cleanup. Broken since 0.15.0.

---------

Co-authored-by: Nicolas Mowen <nickmowen213@gmail.com>
This commit is contained in:
Josh Hawkins
2026-07-28 11:02:15 -06:00
committed by GitHub
co-authored by Nicolas Mowen
parent 66f5511a51
commit 860772f9f4
7 changed files with 140 additions and 11 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/docs/troubleshooting/common_errors.md
+7 -3
View File
@@ -34,11 +34,15 @@ The detect FFmpeg process exited on its own. This message is only the notificati
</FaqItem>
<FaqItem id="non-monotonically-increasing-dts" question="Application provided invalid, non monotonically increasing dts to muxer">
<FaqItem id="non-monotonically-increasing-dts" question="Non-monotonic DTS / non monotonically increasing dts to muxer / Queue input is backward in time">
An FFmpeg message meaning the camera sent packets with out-of-order timestamps. Because recordings are copied without re-encoding, FFmpeg cannot fix them, and the segment muxer often splits early, producing one-second segments and a cache backlog. The usual cause is a camera "Smart Codec" / H.264+ / H.265+ mode or a camera clock that jumps.
These are FFmpeg messages indicating the camera sent packets with out-of-order timestamps, either on the video or the audio stream. Timestamp jitter like this is common with WiFi cameras and restreamed or proxied sources; other causes are a camera "Smart Codec" / H.264+ / H.265+ mode or a camera clock that jumps. A sustained flood of these messages usually precedes the stream stalling and the watchdog restarting FFmpeg.
See [Recordings: segments are only 1 second long](/troubleshooting/recordings#segments-are-only-1-second-long).
In most cases, the fix is to improve the network, reduce system resource usage, or switch to non-WiFi cameras. In general, WiFi cameras are [not recommended](https://ipcamtalk.com/threads/multiple-cameras-high-bandwidth.77100/#post-861110).
On the video stream, this can affect recordings: because they are copied without re-encoding, FFmpeg cannot fix the timestamps, and the segment muxer often splits early, producing one-second segments and a cache backlog. See [Recordings: segments are only 1 second long](/troubleshooting/recordings#segments-are-only-1-second-long).
On the audio stream, the messages can come from the output's audio encoding. If the audio stream is the problem, it may help to have go2rtc transcode it by adding `#audio=aac` to the camera's go2rtc stream to produce clean timestamps for everything consuming the restream.
</FaqItem>