<div dir="ltr"><div>By manually setting the PTS (Presentation Timestamp) and using the liveadder plugin before wavenc and not using rtpjitterbuffer, it actually works: the missing packets which correspond to silence are rightly considered as silence.</div><div>I found the liveadder plugin by mistake. I would suggest to add a reference to liveadder in the rtpjitterbuffer documentation. Something like: "if you would like to create silence for missing RTP packets, use the liveadder plugin".</div><div><br></div><div>Pipeline:  <br></div><div>    appsrc caps="application/x-rtp, media=(string)audio, clock-rate=(int)8000, encoding-name=(string)PCMA" emit-signals=true format=3 block=true ! decodebin ! liveadder ! wavenc ! filesink location=/tmp/out-file.wav<br></div><div><br></div><div>However, I would like rtpjitterbuffer to set the PTS for me using the RTP timestamps. I am not able to achieve this. Even if I use the liveadder plugin, the pipeline blocks at EOS.</div><div><br></div><div>Pipeline:</div><div>    appsrc caps="application/x-rtp, media=(string)audio, clock-rate=(int)8000, encoding-name=(string)PCMA" emit-signals=true format=3 block=true ! rtpjitterbuffer mode=0 latency=0 max-dropout-time=3600000 ! decodebin ! liveadder ! wavenc ! filesink location=/tmp/out-file.wav</div><div><br></div><div>I tried with and without format=3 and with latency=0.</div><div><br></div><div>Best regards.<br></div><div>  <br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Il giorno gio 3 ott 2019 alle ore 18:36 Andrea Lo Pumo <<a href="mailto:alopumo@movia.biz">alopumo@movia.biz</a>> ha scritto:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>I played with gstreamer-java, using an appsrc as the source of RTP packets given to rtpjitterbuffer (instead of rtpfilesrc).</div><div>In this test, I set the Presentation Timestamp of all generated buffers (in the right way, i.e. (timestamp-firstTimestamp)/160*20 milliseconds).</div><div>And I removed "mode=0" as an option to rtpjitterbuffer.</div><div>However, the behaviour, is the same. After, the source has finished ( appsrc.endOfStream() ), the pipeline remains blocked.<br></div><div>This does not happen if the streams does not have jumps in the rtp timestamp.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Il giorno gio 3 ott 2019 alle ore 09:50 Andrea Lo Pumo <<a href="mailto:alopumo@movia.biz" target="_blank">alopumo@movia.biz</a>> ha scritto:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">P.S. here attached the source code of rtpfilesrc<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Il giorno mer 2 ott 2019 alle ore 18:14 Andrea Lo Pumo <<a href="mailto:alopumo@movia.biz" target="_blank">alopumo@movia.biz</a>> ha scritto:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>I have a dump of RTP traffic (a single ssrc stream) and I would like to decode it with gstreamer.</div><div>What I am trying works, but it fails if there are jumps in the timestamps because there is silence in between (no packets sent during the silence). The result is an audio without the right silence.<br></div><div>Note that the RTP timestamp advances correctly, so one knows how much time passed before the jump and after it.<br></div><div>Thus, I was trying "rtpjitterbuffer mode=0" however, when I use mode=0, I get the following:</div><div>....<br></div><div>INFO         rtpjitterbuffer gstrtpjitterbuffer.c:2559:calculate_expected:<rtpjitterbuffer0> lost packets (1, #23086->#23086) duration too large 0:00:00.800000000 > 0:00:00.200000000, consider 0 lost (0:00:00.200000000)<br>INFO         rtpjitterbuffer gstrtpjitterbuffer.c:2559:calculate_expected:<rtpjitterbuffer0> lost packets (2, #23112->#23113) duration too large 0:00:00.740000000 > 0:00:00.200000000, consider 1 lost (0:00:00.293333332)</div><div>...<br></div><div>INFO                 basesrc gstbasesrc.c:2839:gst_base_src_loop:<rtpfilesrc0> pausing after gst_base_src_get_range() = eos<br>INFO                    task gsttask.c:316:gst_task_func:<rtpfilesrc0:src> Task going to paused</div><div><br></div><div>and at this point it remains blocked.</div><div><br></div><div>This is the pipeline I am using: <br></div><div><br></div><div>    gst-launch-1.0 rtpfilesrc location=/tmp/input.rtp ! "application/x-rtp, 
media=(string)audio, clock-rate=(int)8000, encoding-name=(string)PCMA" !
 rtpjitterbuffer mode=0 max-rtcp-rtp-time-diff=-1 ! decodebin ! wavenc !
 filesink location=/tmp/out.wav</div><div><br></div><div>Rtpfilesrc is a plugin I have written that reads an RTP dump and becomes a source of UDP packets. I used PushSrc as the base class and have overridden "fill".</div><div> In init() I am using the following configuration:</div><div>  gst_base_src_set_live (GST_BASE_SRC (rtpfilesrc), TRUE);<br>  gst_base_src_set_format (GST_BASE_SRC (rtpfilesrc), GST_FORMAT_TIME);<br>  // do not make rtpfilesrc set timestamps on outgoing buffers based on the running_time when they were captured<br>  gst_base_src_set_do_timestamp (GST_BASE_SRC (rtpfilesrc), FALSE);</div><div><br></div><div>What should I do? <br></div><div><br></div><div>Thank you in advance.<br></div></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>