python-aidot-cameras 1.0.0rc2__tar.gz → 1.0.0rc3__tar.gz

{python_aidot_cameras-1.0.0rc2/python_aidot_cameras.egg-info → python_aidot_cameras-1.0.0rc3}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: python-aidot-cameras
-Version: 1.0.0rc2
+Version: 1.0.0rc3
 Summary: Control AiDot/Leedarson WiFi lights and cameras (WebRTC streaming, two-way audio, PTZ, controls)
 Author-email: cbrightly <chris.brightly@gmail.com>
 License-Expression: MIT
@@ -418,6 +418,7 @@ audio, idle release, the sprop cache path) are documented in
 | `AIDOT_SDES_CONNECTION_MODE` | Which media path the SDES offer proposes: `auto` (default - every reachable candidate, and ICE priority prefers the LAN with the relay as last resort; measured on the full fleet, six of seven cameras stream direct and only the unit with no route to us rides the relay), `lan` (no relay at all - same lever as `AIDOT_SDES_SKIP_TURN_PREALLOC`, and battery cameras keep the relay regardless because a cloud-woken camera has no other path back), or `relay` (EXPERIMENTAL, and on the reference fleet it does not steer: even with `c=`/`m=` moved to the relay allocation and the WAN permission pre-installed, an A001064 and an A001513 both dialed our host address directly, learning it from our own ICE probes - forcing the relay for real would mean suppressing every direct-path outbound, which is unbuilt). Per-open `sdes_connection_mode` beats the env. Every session reports the path its media actually took as `media_stats().media_path` (`direct`/`relay`). | unset (`auto`) |
 | `AIDOT_SDES_ADAPTIVE` | Adaptive fast-with-fallback for the SDES keepalive loop: try the fast path first and fall back to the full relay path if a fast attempt delivers no media. A per-device cache skips the fast attempt on later views once it has failed. Truthy value enables. Ignored for battery cameras, where the fast path cannot win and its short grace truncates the cold start. | unset (off) |
 | `AIDOT_SDES_FAST_LIVEPLAY` | Don't block on the `livePlayResp` wait for eligible SDES cameras (~4.5 s faster cold start). Role-reversal models (A001064 PTZ) always excluded for correctness. **On by default**; set to `0`/`false`/`no`/`off` to disable. | enabled (on) |
+| `AIDOT_SDES_LIVEPLAY_ECHO_S` | How long to wait for the broker to echo our own `livePlayReq` back before sending `webrtcReq`, in seconds (`0` disables the wait). The wait was 5.0 s on the models excluded from fast-liveplay and is pure latency: across 22 h of one deployment it ran 169 times and timed out 169 times, never once ending early, with no inbound `livePlayReq` among 5000+ messages the cameras and broker did send. The code proceeds on timeout anyway, so it never changed behaviour, only delayed it. Measured on an A001064: time to first media 11534 ms -> 6819 ms. Still honoured, so a broker that does echo short-circuits it. | 0.25 s (1.5 s for fast-liveplay models) |
 | `AIDOT_SDES_NACK` | Ask the camera to resend video RTP packets that never arrived (RTCP Generic NACK). A camera losing packets on a weak link otherwise delivers truncated H.264 slices, which a browser's WebRTC decoder conceals but Media Source Extensions treats as fatal. Measured on an A001064 at ~1-2% loss: 98.4% of losses recovered against none at all without it. Costs nothing on a clean link, where no requests are generated. **On by default**; set to `0`/`false`/`no`/`off` to disable. | enabled (on) |
 | `AIDOT_SDES_VIDEO_PT` | Pin the SDES offer to ONE video codec by payload type, so the camera cannot choose. The offer advertises 96 (H264) and 97 (H265) and the camera decides which to send; on an A001064 that means the same request comes back h264 1280x720 most sessions and hevc 2560x1440 occasionally, at a third of the bitrate. Set to `96` for H264 only (measured h264 720p in 4 of 4 sessions). **Do not set it to `97`** - an H265-only offer returned no video at all in 3 of 3 rounds; narrowing to H265 removes the option rather than selecting it. | unset (both offered) |
 | `AIDOT_SDES_VIDEO_PT_ORDER` | Reorder the SDES offer's video codec list without narrowing it, as a comma-separated preference list (`97,96`). RFC 3264 makes the `m=video` payload-type list a preference list, most-preferred first, and ours has always read `96 97` - not by decision, it has simply never been varied. Whatever is named leads and the rest is appended, so this can express a preference and can never produce a narrowed or empty video m-line. **Experimental and untested on hardware:** whether the camera acts on the order is the open question, so the default is deliberately unchanged. **Tested on hardware 2026-08-23 and it does not select the codec.** Eight sessions on an A001064 in blocks of two: H265 came back in 2 of 4 with the order reversed and 2 of 4 without it, receipts confirming the reordered list reached the SDP. The motive was real - an H265 session costs about half an H264 one (766-774 vs 1597-1685 Kbps) - but the camera picks the codec itself, roughly a coin flip, and RFC 3264 preference order does not move it. | unset (`96 97`) |

{python_aidot_cameras-1.0.0rc2 → python_aidot_cameras-1.0.0rc3}/README.md

@@ -378,6 +378,7 @@ audio, idle release, the sprop cache path) are documented in
 | `AIDOT_SDES_CONNECTION_MODE` | Which media path the SDES offer proposes: `auto` (default - every reachable candidate, and ICE priority prefers the LAN with the relay as last resort; measured on the full fleet, six of seven cameras stream direct and only the unit with no route to us rides the relay), `lan` (no relay at all - same lever as `AIDOT_SDES_SKIP_TURN_PREALLOC`, and battery cameras keep the relay regardless because a cloud-woken camera has no other path back), or `relay` (EXPERIMENTAL, and on the reference fleet it does not steer: even with `c=`/`m=` moved to the relay allocation and the WAN permission pre-installed, an A001064 and an A001513 both dialed our host address directly, learning it from our own ICE probes - forcing the relay for real would mean suppressing every direct-path outbound, which is unbuilt). Per-open `sdes_connection_mode` beats the env. Every session reports the path its media actually took as `media_stats().media_path` (`direct`/`relay`). | unset (`auto`) |
 | `AIDOT_SDES_ADAPTIVE` | Adaptive fast-with-fallback for the SDES keepalive loop: try the fast path first and fall back to the full relay path if a fast attempt delivers no media. A per-device cache skips the fast attempt on later views once it has failed. Truthy value enables. Ignored for battery cameras, where the fast path cannot win and its short grace truncates the cold start. | unset (off) |
 | `AIDOT_SDES_FAST_LIVEPLAY` | Don't block on the `livePlayResp` wait for eligible SDES cameras (~4.5 s faster cold start). Role-reversal models (A001064 PTZ) always excluded for correctness. **On by default**; set to `0`/`false`/`no`/`off` to disable. | enabled (on) |
+| `AIDOT_SDES_LIVEPLAY_ECHO_S` | How long to wait for the broker to echo our own `livePlayReq` back before sending `webrtcReq`, in seconds (`0` disables the wait). The wait was 5.0 s on the models excluded from fast-liveplay and is pure latency: across 22 h of one deployment it ran 169 times and timed out 169 times, never once ending early, with no inbound `livePlayReq` among 5000+ messages the cameras and broker did send. The code proceeds on timeout anyway, so it never changed behaviour, only delayed it. Measured on an A001064: time to first media 11534 ms -> 6819 ms. Still honoured, so a broker that does echo short-circuits it. | 0.25 s (1.5 s for fast-liveplay models) |
 | `AIDOT_SDES_NACK` | Ask the camera to resend video RTP packets that never arrived (RTCP Generic NACK). A camera losing packets on a weak link otherwise delivers truncated H.264 slices, which a browser's WebRTC decoder conceals but Media Source Extensions treats as fatal. Measured on an A001064 at ~1-2% loss: 98.4% of losses recovered against none at all without it. Costs nothing on a clean link, where no requests are generated. **On by default**; set to `0`/`false`/`no`/`off` to disable. | enabled (on) |
 | `AIDOT_SDES_VIDEO_PT` | Pin the SDES offer to ONE video codec by payload type, so the camera cannot choose. The offer advertises 96 (H264) and 97 (H265) and the camera decides which to send; on an A001064 that means the same request comes back h264 1280x720 most sessions and hevc 2560x1440 occasionally, at a third of the bitrate. Set to `96` for H264 only (measured h264 720p in 4 of 4 sessions). **Do not set it to `97`** - an H265-only offer returned no video at all in 3 of 3 rounds; narrowing to H265 removes the option rather than selecting it. | unset (both offered) |
 | `AIDOT_SDES_VIDEO_PT_ORDER` | Reorder the SDES offer's video codec list without narrowing it, as a comma-separated preference list (`97,96`). RFC 3264 makes the `m=video` payload-type list a preference list, most-preferred first, and ours has always read `96 97` - not by decision, it has simply never been varied. Whatever is named leads and the rest is appended, so this can express a preference and can never produce a narrowed or empty video m-line. **Experimental and untested on hardware:** whether the camera acts on the order is the open question, so the default is deliberately unchanged. **Tested on hardware 2026-08-23 and it does not select the codec.** Eight sessions on an A001064 in blocks of two: H265 came back in 2 of 4 with the order reversed and 2 of 4 without it, receipts confirming the reordered list reached the SDP. The motive was real - an H265 session costs about half an H264 one (766-774 vs 1597-1685 Kbps) - but the camera picks the codec itself, roughly a coin flip, and RFC 3264 preference order does not move it. | unset (`96 97`) |

{python_aidot_cameras-1.0.0rc2 → python_aidot_cameras-1.0.0rc3}/aidot_cameras/camera/protocol.py

@@ -1058,6 +1058,11 @@ class _DirectTsServer:
         self._pmt: "Optional[bytes]" = None
         self._pmt_pid: "Optional[int]" = None
         self._synced = False        # has the current consumer been given a start
+        # Set by the mux immediately before it writes a video keyframe, so a new
+        # consumer can be spliced where the picture is actually decodable.
+        self._kf_pending = False
+        self._kf_ever = False
+        self._waiting_since: "Optional[float]" = None
 
     @property
     def port(self) -> int:
@@ -1141,6 +1146,51 @@ class _DirectTsServer:
         except (IndexError, ValueError):
             return
 
+    #: How long a new consumer may wait for a keyframe signal before the old
+    #: PID-blind random-access test is allowed to start it anyway. The signal is
+    #: the correct trigger, but a stream that never sends one must not hang
+    #: forever - gating solely on a video-pid flag served ZERO bytes when tried
+    #: (2026-08-29), because the muxer does not set it.
+    _LEGACY_SYNC_AFTER_S = 5.0
+
+    def mark_keyframe(self) -> None:
+        """Tell the server the next bytes written begin a video keyframe.
+
+        The mux knows this and used to throw it away: it pulls ``(data, ts, kf)``
+        off the queue and ``kf`` came from ``_h264_has_keyframe`` at the tap.
+        Everything downstream then tried to rediscover it from the container,
+        which does not carry it - PyAV's mpegts muxer does not set
+        ``random_access_indicator`` on the video PID in this stream, so a sync
+        gated on that flag never fires at all.
+
+        Splicing a consumer anywhere else hands it video mid-GOP referencing an
+        SPS/PPS it never received, which decodes as "non-existing PPS 0
+        referenced": a video track that never produces a frame.
+        """
+        if not self._kf_ever:
+            _LOGGER.debug("direct-ts: first keyframe signal reached the server")
+        self._kf_ever = True
+        self._kf_pending = True
+
+    def _legacy_sync_ok(self, pkt: bytes) -> bool:
+        """The pre-signal behaviour, allowed only after a grace period.
+
+        Kept because a source that never calls ``mark_keyframe`` must still be
+        servable. Deliberately NOT the first choice: this test accepts a
+        random-access point on ANY pid, and AAC audio sets that flag ~50x/s, so
+        before the signal existed a late joiner was spliced onto audio and never
+        received a decodable picture.
+        """
+        if self._kf_ever:
+            return False        # this source signals; wait for the real thing
+        if not self._is_random_access(pkt):
+            return False
+        now = time.monotonic()
+        if self._waiting_since is None:
+            self._waiting_since = now
+            return False
+        return (now - self._waiting_since) >= self._LEGACY_SYNC_AFTER_S
+
     def write(self, b: bytes) -> int:
         data = self._tail + b if self._tail else b
         out = bytearray()
@@ -1164,7 +1214,11 @@ class _DirectTsServer:
                 self._pmt = pkt
             if self._synced:
                 out += pkt
-            elif self._is_random_access(pkt):
+            elif self._kf_pending or self._legacy_sync_ok(pkt):
+                _LOGGER.debug(
+                    "direct-ts: spliced a consumer via=%s signals=%s pid=%s",
+                    "keyframe-signal" if self._kf_pending else "legacy-rai",
+                    self._kf_ever, pid)
                 # Start this consumer here: tables first, then the keyframe.
                 if self._pat is not None:
                     out += self._pat
@@ -1172,6 +1226,8 @@ class _DirectTsServer:
                     out += self._pmt
                 out += pkt
                 self._synced = True
+                self._kf_pending = False
+                self._waiting_since = None
         self._tail = data[i:] if i < n else b""
 
         with self._lock:
@@ -1568,6 +1624,16 @@ def _dtls_av_mux_run(vq, aq, out_fileobj, progress, stop_flag) -> None:
         def close(self):
             self._f.close()
 
+        def mark_keyframe(self):
+            """Forward the keyframe signal when the sink understands it.
+
+            The sink is a _DirectTsServer on the direct path and an os pipe to
+            ffmpeg otherwise; only the former can use this.
+            """
+            fn = getattr(self._f, "mark_keyframe", None)
+            if fn is not None:
+                fn()
+
     wsink = _FailFlagWriter(out_fileobj)
     try:
         # max_interleave_delta (default 10s of stream time): with an AAC stream
@@ -1659,6 +1725,10 @@ def _dtls_av_mux_run(vq, aq, out_fileobj, progress, stop_flag) -> None:
             pkt.stream = vs
             pkt.pts, pkt.dts = video_pts_dts(_ts_state, _rel, _slack)
             pkt.time_base = Fraction(1, 90000)
+            if kf:
+                # Announce it BEFORE muxing: the bytes this produces are where a
+                # new consumer can safely be spliced, and only we know that.
+                wsink.mark_keyframe()
             try:
                 out.mux(pkt)
                 progress[0] = _t.monotonic()

{python_aidot_cameras-1.0.0rc2 → python_aidot_cameras-1.0.0rc3}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "setuptools.build_meta"
 
 [project]
 name = "python-aidot-cameras"
-version = "1.0.0rc2"
+version = "1.0.0rc3"
 description = "Control AiDot/Leedarson WiFi lights and cameras (WebRTC streaming, two-way audio, PTZ, controls)"
 readme = "README.md"
 license = "MIT"

{python_aidot_cameras-1.0.0rc2 → python_aidot_cameras-1.0.0rc3/python_aidot_cameras.egg-info}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: python-aidot-cameras
-Version: 1.0.0rc2
+Version: 1.0.0rc3
 Summary: Control AiDot/Leedarson WiFi lights and cameras (WebRTC streaming, two-way audio, PTZ, controls)
 Author-email: cbrightly <chris.brightly@gmail.com>
 License-Expression: MIT
@@ -418,6 +418,7 @@ audio, idle release, the sprop cache path) are documented in
 | `AIDOT_SDES_CONNECTION_MODE` | Which media path the SDES offer proposes: `auto` (default - every reachable candidate, and ICE priority prefers the LAN with the relay as last resort; measured on the full fleet, six of seven cameras stream direct and only the unit with no route to us rides the relay), `lan` (no relay at all - same lever as `AIDOT_SDES_SKIP_TURN_PREALLOC`, and battery cameras keep the relay regardless because a cloud-woken camera has no other path back), or `relay` (EXPERIMENTAL, and on the reference fleet it does not steer: even with `c=`/`m=` moved to the relay allocation and the WAN permission pre-installed, an A001064 and an A001513 both dialed our host address directly, learning it from our own ICE probes - forcing the relay for real would mean suppressing every direct-path outbound, which is unbuilt). Per-open `sdes_connection_mode` beats the env. Every session reports the path its media actually took as `media_stats().media_path` (`direct`/`relay`). | unset (`auto`) |
 | `AIDOT_SDES_ADAPTIVE` | Adaptive fast-with-fallback for the SDES keepalive loop: try the fast path first and fall back to the full relay path if a fast attempt delivers no media. A per-device cache skips the fast attempt on later views once it has failed. Truthy value enables. Ignored for battery cameras, where the fast path cannot win and its short grace truncates the cold start. | unset (off) |
 | `AIDOT_SDES_FAST_LIVEPLAY` | Don't block on the `livePlayResp` wait for eligible SDES cameras (~4.5 s faster cold start). Role-reversal models (A001064 PTZ) always excluded for correctness. **On by default**; set to `0`/`false`/`no`/`off` to disable. | enabled (on) |
+| `AIDOT_SDES_LIVEPLAY_ECHO_S` | How long to wait for the broker to echo our own `livePlayReq` back before sending `webrtcReq`, in seconds (`0` disables the wait). The wait was 5.0 s on the models excluded from fast-liveplay and is pure latency: across 22 h of one deployment it ran 169 times and timed out 169 times, never once ending early, with no inbound `livePlayReq` among 5000+ messages the cameras and broker did send. The code proceeds on timeout anyway, so it never changed behaviour, only delayed it. Measured on an A001064: time to first media 11534 ms -> 6819 ms. Still honoured, so a broker that does echo short-circuits it. | 0.25 s (1.5 s for fast-liveplay models) |
 | `AIDOT_SDES_NACK` | Ask the camera to resend video RTP packets that never arrived (RTCP Generic NACK). A camera losing packets on a weak link otherwise delivers truncated H.264 slices, which a browser's WebRTC decoder conceals but Media Source Extensions treats as fatal. Measured on an A001064 at ~1-2% loss: 98.4% of losses recovered against none at all without it. Costs nothing on a clean link, where no requests are generated. **On by default**; set to `0`/`false`/`no`/`off` to disable. | enabled (on) |
 | `AIDOT_SDES_VIDEO_PT` | Pin the SDES offer to ONE video codec by payload type, so the camera cannot choose. The offer advertises 96 (H264) and 97 (H265) and the camera decides which to send; on an A001064 that means the same request comes back h264 1280x720 most sessions and hevc 2560x1440 occasionally, at a third of the bitrate. Set to `96` for H264 only (measured h264 720p in 4 of 4 sessions). **Do not set it to `97`** - an H265-only offer returned no video at all in 3 of 3 rounds; narrowing to H265 removes the option rather than selecting it. | unset (both offered) |
 | `AIDOT_SDES_VIDEO_PT_ORDER` | Reorder the SDES offer's video codec list without narrowing it, as a comma-separated preference list (`97,96`). RFC 3264 makes the `m=video` payload-type list a preference list, most-preferred first, and ours has always read `96 97` - not by decision, it has simply never been varied. Whatever is named leads and the rest is appended, so this can express a preference and can never produce a narrowed or empty video m-line. **Experimental and untested on hardware:** whether the camera acts on the order is the open question, so the default is deliberately unchanged. **Tested on hardware 2026-08-23 and it does not select the codec.** Eight sessions on an A001064 in blocks of two: H265 came back in 2 of 4 with the order reversed and 2 of 4 without it, receipts confirming the reordered list reached the SDP. The motive was real - an H265 session costs about half an H264 one (766-774 vs 1597-1685 Kbps) - but the camera picks the codec itself, roughly a coin flip, and RFC 3264 preference order does not move it. | unset (`96 97`) |

{python_aidot_cameras-1.0.0rc2 → python_aidot_cameras-1.0.0rc3}/python_aidot_cameras.egg-info/SOURCES.txt

@@ -102,6 +102,7 @@ tests/test_deferred_hardening.py
 tests/test_device_cmd_seq_match.py
 tests/test_device_login_guard.py
 tests/test_device_user_info_cache.py
+tests/test_direct_ts_keyframe_signal.py
 tests/test_direct_ts_serve.py
 tests/test_dormant_camera_cleanup.py
 tests/test_drain_is_cancellable.py

python_aidot_cameras-1.0.0rc3/tests/test_direct_ts_keyframe_signal.py

@@ -0,0 +1,140 @@
+"""A late joiner is spliced where the mux says a keyframe starts.
+
+`_DirectTsServer` holds a new consumer until it can hand over a decodable start.
+It used to decide that from the container: any TS packet with the adaptation
+field's random_access_indicator set. That flag is per-PID, and AAC audio sets it
+roughly 50x/s against a video keyframe every ~2 s, so a late joiner was spliced
+onto audio and received video mid-GOP against an SPS/PPS it never got -
+"non-existing PPS 0 referenced", a video track that never produces a frame.
+Only a consumer present from byte 0 escaped, and go2rtc pulls lazily when a
+viewer connects, so it is always late.
+
+Gating on the flag being set on the VIDEO pid instead was tried on hardware
+(2026-08-29) and served ZERO bytes: PyAV's mpegts muxer does not set it on video
+in this stream, so the condition never became true. That attempt was reverted.
+
+The mux already knows. It pulls ``(data, ts, kf)`` off the queue, where ``kf``
+came from ``_h264_has_keyframe`` at the tap, and then threw it away. It now
+announces it, and the legacy container test survives only as a bounded fallback
+for a source that never signals - so a stream that does not use the signal can
+still be served rather than hanging forever.
+"""
+import os
+import sys
+import threading
+
+sys.path.insert(0, os.path.dirname(os.path.dirname(os.path.abspath(__file__))))
+
+from aidot_cameras.camera.protocol import _DirectTsServer
+
+VIDEO_PID = 0x0100
+AUDIO_PID = 0x0101
+
+
+def _ts(pid: int, *, rai: bool = False) -> bytes:
+    """One 188-byte TS packet, optionally flagging a random-access point."""
+    hdr = bytearray(4)
+    hdr[0] = 0x47
+    hdr[1] = (pid >> 8) & 0x1F
+    hdr[2] = pid & 0xFF
+    hdr[3] = 0x30 if rai else 0x10       # adaptation+payload, or payload only
+    body = bytes([1, 0x40]) if rai else b""   # adaptation_field_length=1, RAI
+    pkt = bytes(hdr) + body + b"\xde\xad"
+    return pkt + b"\xff" * (188 - len(pkt))
+
+
+def _server():
+    srv = _DirectTsServer.__new__(_DirectTsServer)
+    srv._tail = b""
+    srv._pat = b"P" * 188
+    srv._pmt = b"M" * 188
+    srv._pmt_pid = 0x1000
+    srv._synced = False
+    srv._kf_pending = False
+    srv._kf_ever = False
+    srv._waiting_since = None
+    srv._lock = threading.Lock()
+    sent = bytearray()
+
+    class _Sock:
+        def sendall(self, b):
+            sent.extend(b)
+
+    srv._client = _Sock()
+    return srv, sent
+
+
+def test_audio_random_access_does_not_splice_a_signalling_source():
+    """The defect: audio RAI used to start the consumer mid-video-GOP."""
+    srv, sent = _server()
+    srv.mark_keyframe()                    # source signals, so it is trusted
+    srv._kf_pending = False                # ...but no keyframe pending yet
+    srv.write(_ts(AUDIO_PID, rai=True) * 20)
+    assert not srv._synced
+    assert bytes(sent) == b""
+
+
+def test_keyframe_signal_splices_with_tables_first():
+    srv, sent = _server()
+    srv.write(_ts(AUDIO_PID, rai=True) * 3)
+    assert not srv._synced
+    srv.mark_keyframe()
+    srv.write(_ts(VIDEO_PID))
+    assert srv._synced
+    out = bytes(sent)
+    assert out[:188] == b"P" * 188, "PAT first"
+    assert out[188:376] == b"M" * 188, "then PMT"
+    assert len(out) == 3 * 188, "then the keyframe's packet"
+
+
+def test_pending_flag_is_consumed_so_a_later_consumer_waits_again():
+    srv, _ = _server()
+    srv.mark_keyframe()
+    srv.write(_ts(VIDEO_PID))
+    assert srv._synced and not srv._kf_pending
+
+
+def test_everything_flows_once_synced():
+    srv, sent = _server()
+    srv.mark_keyframe()
+    srv.write(_ts(VIDEO_PID))
+    before = len(bytes(sent))
+    srv.write(_ts(AUDIO_PID) + _ts(VIDEO_PID))
+    assert len(bytes(sent)) == before + 2 * 188
+
+
+def test_non_signalling_source_still_starts_after_the_grace_period():
+    """A writer that never calls mark_keyframe must not hang forever.
+
+    This is the regression that gating solely on a video-pid flag caused:
+    zero bytes, which is worse than the bug it was fixing.
+    """
+    srv, sent = _server()
+    srv.write(_ts(AUDIO_PID, rai=True))
+    assert not srv._synced, "must wait out the grace period first"
+    srv._waiting_since -= _DirectTsServer._LEGACY_SYNC_AFTER_S + 1
+    srv.write(_ts(AUDIO_PID, rai=True))
+    assert srv._synced, "a non-signalling source must still be servable"
+    assert bytes(sent), "and must actually receive bytes"
+
+
+def test_a_signalling_source_never_falls_back():
+    """Once a source has signalled, the container test must never win."""
+    srv, _ = _server()
+    srv.mark_keyframe()
+    srv._kf_pending = False
+    srv._waiting_since = 0.0               # grace long expired
+    assert srv._legacy_sync_ok(_ts(AUDIO_PID, rai=True)) is False
+
+
+def test_mux_forwards_the_signal_only_to_sinks_that_understand_it():
+    """The fail-flag wrapper must not raise on an os pipe, which has no hook."""
+    import inspect
+
+    from aidot_cameras.camera import protocol
+
+    src = inspect.getsource(protocol._dtls_av_mux_run)
+    assert "wsink.mark_keyframe()" in src, "the mux must announce keyframes"
+    assert 'getattr(self._f, "mark_keyframe", None)' in src, (
+        "forwarding must be optional - the ffmpeg path's sink is a pipe"
+    )

{python_aidot_cameras-1.0.0rc2 → python_aidot_cameras-1.0.0rc3}/tests/test_direct_ts_serve.py

@@ -39,6 +39,13 @@ this server or in go2rtc: a `proc.returncode` dereference when there is no
 ffmpeg process, binding an ephemeral port instead of the advertised one when no
 relay holds it, and the missing join-awareness below. The server itself
 describes cleanly against real go2rtc (`rc: 0, h264,video`).
+
+These drive the server directly, so they must announce keyframes the way the
+mux does (`mark_keyframe`). The container's random_access_indicator is no longer
+the primary trigger: it is per-PID, AAC audio sets it ~50x/s, and syncing on it
+spliced a late joiner onto audio with video mid-GOP. It survives only as a
+bounded fallback for a writer that never signals - covered in
+test_direct_ts_keyframe_signal.py.
 """
 import os
 import socket
@@ -133,6 +140,7 @@ def test_a_consumer_gets_an_http_response_then_the_media():
                 if srv.has_consumer():
                     break
                 time.sleep(0.05)
+            srv.mark_keyframe()                    # the mux announces it
             srv.write(_ts(0x100, pusi=1, rai=1))   # keyframe: releases the join
             for _ in range(10):
                 srv.write(_ts(0x100, pusi=1))
@@ -255,6 +263,7 @@ def test_a_late_consumer_gets_tables_then_a_keyframe():
         sock, head = _get(srv.port, read_bytes=1)
         assert _wait_consumer(srv)
         body = head.partition(b"\r\n\r\n")[2]
+        srv.mark_keyframe()                       # the mux announces it
         srv.write(_ts(0x100, pusi=1, rai=1))      # the next keyframe
         srv.write(_ts(0x100, pusi=1))
         body += _drain(sock, n=4)
@@ -276,6 +285,7 @@ def test_once_synced_it_keeps_forwarding():
         srv.write(_pat()); srv.write(_ts(0x1000, pusi=1))
         sock, head = _get(srv.port, read_bytes=1)
         assert _wait_consumer(srv)
+        srv.mark_keyframe()
         srv.write(_ts(0x100, pusi=1, rai=1))
         for _ in range(6):
             srv.write(_ts(0x100, pusi=1))
@@ -295,6 +305,7 @@ def test_a_reconnecting_consumer_resyncs():
         srv.write(_pat()); srv.write(_ts(0x1000, pusi=1))
         s1, _ = _get(srv.port, read_bytes=1)
         assert _wait_consumer(srv)
+        srv.mark_keyframe()
         srv.write(_ts(0x100, pusi=1, rai=1))
         s1.close()
         time.sleep(0.3)