Platform: Jetson Orin NX, JetPack 6.2 (L4T R36.4.3). The relevant plugin code is unchanged in R36.5 and R39.2.1.
Topic 257363 was closed as “fixed in DeepStream 7.1”, but the issue still occurs on R36.4.3:
- Input: live source, no B-frames, PTS taken from the source’s own clock, so frame spacing is close to but not exactly 1/framerate of the caps (e.g. 20/1).
- Output: after some time (hours in our case), the encoder now and then emits two neighbouring frames with swapped PTS: N, N+2, N+1, N+3. No frame is lost, only the PTS order is wrong. Downstream muxers report non-monotonic DTS.
- Both nvv4l2h264enc and nvv4l2h265enc, fed from the same tee, swap the same input frames at the same moment.
In gstv4l2videoenc.c, gst_v4l2_video_enc_find_nearest_frame() maps each encoded buffer to the pending frame with the nearest PTS, using the timestamp of the capture buffer. With copy-timestamp=false (the default), that timestamp does not seem to be the input timestamp. If it is generated from the framerate, it drifts against real input PTS, and once the drift exceeds half a frame period the wrong pending frame is picked whenever two frames are queued.
Questions:
1. Is copy-timestamp=true the intended setting for live sources whose PTS do not follow the caps framerate?
2. If so, should find_nearest_frame() not rely on capture timestamps when copy-timestamp is false?