<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Thanks Tim,<div>A queue element didn't solve the problem. </div><div><br></div><div>I found that the problem is caused by the fact that tsparse sends a relatively large buffer to rtpmp2tpay and when the buffer is processed into separate UDP packets, each UDP packet has the same PTS inherited from his parent buffer from tsparse. You can check this by inserting two identity elements before and after rtpmp2tpay. </div><div><br></div><div>To fix this, I slightly modified tsparse and rtpmp2tpay. </div><div><br></div><div>In tsparse.c I've just set the duration of the output buffer as it is calculated by tsparse anyway:</div><div><div><br></div><div>@@ -839,6 +839,7 @@ drain_pending_buffers (MpegTSParse2 * parse, gboolean drain_all)</div><div><br></div><div> GST_BUFFER_PTS (buffer) = out_ts + parse->ts_offset;</div><div> GST_BUFFER_DTS (buffer) = out_ts + parse->ts_offset;</div><div>+ GST_BUFFER_DURATION (buffer) = pcr_diff;</div><div> if (ret == GST_FLOW_OK) {</div><div> ret = gst_pad_push (parse->srcpad, buffer);</div><div> ret = gst_flow_combiner_update_flow (parse->flowcombiner, ret);</div></div><div><br></div><div>In rtpmp2tpay, I set the PTS of the individual UDP packets to a gradually increasing value:</div><div><div><br></div><div>--- a/gst/rtp/gstrtpmp2tpay.c</div><div>+++ b/gst/rtp/gstrtpmp2tpay.c</div><div>@@ -123,11 +123,12 @@ gst_rtp_mp2t_pay_setcaps (GstRTPBasePayload * payload, GstCaps * caps)</div><div> static GstFlowReturn</div><div> gst_rtp_mp2t_pay_flush (GstRTPMP2TPay * rtpmp2tpay)</div><div> {</div><div>- guint avail, mtu;</div><div>+ guint avail, mtu, size;</div><div> GstFlowReturn ret = GST_FLOW_OK;</div><div> GstBuffer *outbuf;</div><div><br></div><div> avail = gst_adapter_available (rtpmp2tpay->adapter);</div><div>+ size=avail;</div></div><div><br></div><div><div>@@ -160,8 +161,8 @@ gst_rtp_mp2t_pay_flush (GstRTPMP2TPay * rtpmp2tpay)</div><div> outbuf = gst_buffer_append (outbuf, paybuf);</div><div> avail -= payload_len;</div><div><br></div><div>- GST_BUFFER_PTS (outbuf) = rtpmp2tpay->first_ts;</div><div>- GST_BUFFER_DURATION (outbuf) = rtpmp2tpay->duration;</div><div>+ GST_BUFFER_PTS (outbuf) = rtpmp2tpay->first_ts + (size-avail)*rtpmp2tpay->duration / size ;</div><div>+ GST_BUFFER_DURATION (outbuf) = rtpmp2tpay->duration*payload_len/size;</div><div><br></div><div> GST_DEBUG_OBJECT (rtpmp2tpay, "pushing buffer of size %u",</div><div> (guint) gst_buffer_get_size (outbuf));</div></div><div><br></div><div>Not sure if these modifications fit into the design of either tsparse or rtpmp2tpay but I thought to share so others can benefit. At least in my use case they seem to work fine.<br></div><div><br></div><div>Best Regards,</div><div>Lajos</div><div><br></div><div><br></div><div><br></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Apr 18, 2019 at 10:48 AM Tim Müller <<a href="mailto:tim@centricular.com">tim@centricular.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Tue, 2019-04-16 at 17:22 +0200, Lajos Okos wrote:<br>
<br>
Hi Lajos,<br>
<br>
> I have a recorded HLS stream created with hlssink2 that I would like<br>
> to stream with the below pipeline:<br>
> <br>
> gst-launch-1.0 \<br>
> 2 souphttpsrc location=http://.../.../playlist.m3u8 ! \<br>
> 3 hlsdemux ! \<br>
> 4 tsparse set-timestamps=true ! \<br>
> 5 rtpmp2tpay ! \<br>
> 6 udpsink sync=true host=239.211.8.222 port=1234<br>
> <br>
> I can play the multicast stream from the pipeline with VLC more or<br>
> less ok, although time to time the picture freezes and I lose audio. <br>
> <br>
> Configuring some logging for tsparse, I can see that it pushes<br>
> buffers out with quite a large variation in duration. Sometimes the<br>
> buffers have duration of 5-6 seconds other time they are just a<br>
> fraction of a second. Checking the stream in Wireshark the bitrate of<br>
> the player's multicast stream varies a lot. Is there a way to keep<br>
> the duration of the pushed buffers from tsparse low? I guess the<br>
> large variation of the output bitrate is due to the fact that the<br>
> elements following tsparse underrun but this is just guessing. Any<br>
> suggestions on how to change the pipeline that the output bitrate<br>
> stays more or less static with just a reasonable variation?<br>
> <br>
> Many thanks for your suggestions!<br>
<br>
If you suspect that the elements following tsparse underrun, then a<br>
generous queue might help (queue max-size-time=30000000000 max-size-<br>
bytes=0 max-size-buffers=0 or somesuch perhaps).<br>
<br>
Cheers<br>
Tim<br>
<br>
-- <br>
Tim Müller, Centricular Ltd - <a href="http://www.centricular.com" rel="noreferrer" target="_blank">http://www.centricular.com</a><br>
<br>
_______________________________________________<br>
gstreamer-devel mailing list<br>
<a href="mailto:gstreamer-devel@lists.freedesktop.org" target="_blank">gstreamer-devel@lists.freedesktop.org</a><br>
<a href="https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a></blockquote></div>