rtpjitterbuffer outputs same buffer timestamp after input gap

[Gst-Geek]

I am using below pipeline to decode RTP over UDP stream. Pipeline works perfectly when input stream is seamless. But When there is discontinuity (input missing for some time) in the input then decoder repeats same buffer time stamps roughly equal to current running time after that. Below is the pipeline used for decoding.
 
gst-launch-1.0 udpsrc port=9000 caps=application/x-rtp,clock-rate=90000,payload=33 ! rtpjitterbuffer latency=400 ! rtpmp2tdepay ! decodebin ! video/x-raw ! checksumsink sync=true


Here I have stopped input after 9 secs of pipeline and input is resumed after 10 secs, 0:00:09.824687222 timestamp is repeated 230 times with decreasing timestamp log from base decider class.

0:00:09.624687222 e6006007e4f5c51e9ba669ec789d34bbd268ac02
0:00:09.664687222 f8f0651d17a537251383798d459125ad723e3e3f
0:00:09.704687222 882e2f2d5ff798509a6fb937c3e38a9cacfa4ace
0:00:09.824687222 bffd412b9e84f819335f8864fc3f65cdd6f61e08
0:00:09.824687222 ec66b9fd3052a4e51a1b76d93d231cda6421cec1
0:00:09.824687222 26c00dafb4a67bd3c74e833e138ad9e85cd8084d
0:00:09.824687222 1a546bde7272c09edd2b90cc5e961af0ec21e0c8
Redistribute latency...
0:00:09.824687222 882e2f2d5ff798509a6fb937c3e38a9cacfa4ace
Redistribute latency...
0:00:09.824687222 8e8511801a526f0048b756359b406c6cfdb0ae22
0:00:09.824687222 236b576c9d0f8a4d5478f028bc0d0e49e9190a8d
0:00:09.824687222 8f01fdbffb15d54a7bf5900087a5db77d6b41d0d
0:00:09.824687222 3187170c348d5036b51cbf6159886eea711cac93
0:00:09.824687222 9ebcae6ad6c1df5b377b55f5def438d95035c6bc
0:00:09.824687222 c6dc5daedc5a6707fe22bf71928ac840cd55e854
0:00:09.824687222 b715910425a0ed72d855931094e9436ca732ea72
0:00:09.824687222 9a2dc9dea4b3ac809cd7e4dee39f772ed53ee79d
0:00:09.824687222 a82f0a9cad4bb961e6ea91c08fd905faf2b3e6e7
0:00:09.824687222 4f6b5ad75fa5e1344bef2d9475cfcb992276a06b
0:00:09.824687222 98681289bab2971a0188c83574c95133b9fd5b44

This warning log is seen with every frame when buffer has same time stamp.
WARN videodecoder gstvideodecoder.c:2775:gst_video_decoder_prepare_finish_frame:<avdec_mpeg2video0> decreasing timestamp (0:00:00.646061732 < 0:00:09.624687222)



This issue is not seen when rtpjitterbuffer is removed from the pipeline.

Am I missing some thing while configuring rtpjitterbuffer ??
The expected output is after input gap the buffer timestamp should be adjusted to the running time of the pipeline.

[Gst-Geek]

One more observation.

output of rtpjitterbuffer outputs same buffers timestamp always. Is this the expected behaviour ??

[Gst-Geek]

I root caused the issue. I think tsdemux is not handling discontinuity properly.

When there is discontinuity in the RTP input stream rtpjitterbuffer tags bufferas GST_BUFFER_FLAG_DISCONT after discontinuity.

tsdemux reset segment and timestamp when buffer is received with discontinuity. In mpegts_base_chain function below marked code flushes the demuxer and resets the time stamp and segmet due to which the next buffer onward timestamps and segment base starts again from 0. Stream time stamps goes past and all pluigins cribs about the timestamp.

 if (GST_BUFFER_IS_DISCONT (buf)) {
    GST_DEBUG_OBJECT (base, "Got DISCONT buffer, flushing");
    res = mpegts_base_drain (base);
    if (G_UNLIKELY (res != GST_FLOW_OK))
      return res;

    mpegts_base_flush (base, FALSE);
    /* In the case of discontinuities in push-mode with TIME segment
     * we want to drop all previous observations (hard:TRUE) from
     * the packetizer */
    if (base->mode == BASE_MODE_PUSHING
        && base->segment.format == GST_FORMAT_TIME) {
      mpegts_packetizer_flush (base->packetizer, TRUE);
      mpegts_packetizer_clear (base->packetizer);
    } else
      mpegts_packetizer_flush (base->packetizer, FALSE);
  }

In above case tsdemux should generate new segment with current time as base time ??

I have raised bug for the same https://bugzilla.gnome.org/show_bug.cgi?id=786667