The X1C's RTSPS server emits unreliable decode timestamps (wildly
non-monotonic jumps, sometimes none at all). The previous AVC1 path in
gstbambusrc forwarded sample.decode_time straight into the pipeline as
DTS, which made GStreamer's basesink wait for the pipeline clock to
catch up with timestamps that were thousands of seconds in the future,
freezing playback after a few seconds of streaming.
Replace the trust-the-printer approach with synthesized monotonic
timestamps, the same trick mpv uses when it reports "No video PTS!
Making something up.":
* stamp PTS = sttime + frame_count * period
* adapt period to the real inter-arrival rate via EWMA (the announced
frame_rate is also unreliable -- X1C reports 30 fps but delivers
~28 fps), keeping the synthesized timeline aligned with arrival
* apply a 100 ms lead so the sink has a small jitter buffer to
absorb the bursty 2-3-frames-then-gap delivery pattern of the
Bambu tunnel
* re-anchor only on large divergence (printer pause, stream resume,
fps change) instead of every few seconds
The MJPEG path was already wall-clock-stamping arrivals; this unifies
both formats on the same scheme.
Confirmed on an X1C in LAN-only mode (RTSPS) on Fedora 43; not tested
on P1/A1 hardware. Other Bambu printers share the same Linux source
and could see the same fix where their decode timestamps or announced
framerate are similarly unreliable, but that has not been verified.
No effect on Windows/macOS -- gstbambusrc.c is Linux-only. Trade-off
is +100 ms of camera-view latency, which is invisible for a print-
monitor use case.
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Co-authored-by: SoftFever <softfeverever@gmail.com>
0f3fec89f0