Timestamps That Stop Moving: Empirical Repairs of PTS Failures in a Dual-Camera GStreamer Pipeline

Real-time stereo vision pairs frames from two cameras by presentation timestamp (PTS), so timestamps must be present and must advance steadily. In the dual-camera GStreamer pipeline studied here, three timestamp failures appeared: buffers with no PTS, consecutive buffers with the same PTS, and a frozen timeline that stalled for seconds in some of the runs before resuming. None involved corrupted values: A timestamp was absent, repeated, or stopped advancing. Two probe-based repairs were built: Patch 1 targets duplicated PTS at the parser output (it also fills in missing ones), and Patch 2 works around stalls, the frozen PTS, by carrying input timestamps across the decoder through a FIFO. The sender firmware writes a PTS for every frame, and every PES packet of the transmitted stream carried one (verified with Wireshark, StreamEye and ffmpeg); the missing and repeated values therefore arise on the receiving side. In further live runs, 2.0–3.5% of the buffers of each camera reached the parser with a repeated or missing PTS (for example up to 177 of 5100 frames in 167 s); after the repairs, all but one of 2000–11,100 buffers per camera and stage carried a valid, increasing PTS (guaranteed by construction) at the parser and decoder outputs; the decoded rate (32.4 fps) matched the received rate (32.3–32.5 fps), and 32.1–32.2 fps were delivered to the application.