streaming recorded TS over UDP

[Lajos Okos]

Thanks Tim,
A queue element didn't solve the problem.

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.

To fix this, I slightly modified tsparse and rtpmp2tpay.

In tsparse.c I've just set the duration of the output buffer as it is
calculated by tsparse anyway:

@@ -839,6 +839,7 @@ drain_pending_buffers (MpegTSParse2 * parse, gboolean
drain_all)

     GST_BUFFER_PTS (buffer) = out_ts + parse->ts_offset;
     GST_BUFFER_DTS (buffer) = out_ts + parse->ts_offset;
+    GST_BUFFER_DURATION (buffer) = pcr_diff;
     if (ret == GST_FLOW_OK) {
       ret = gst_pad_push (parse->srcpad, buffer);
       ret = gst_flow_combiner_update_flow (parse->flowcombiner, ret);

In rtpmp2tpay, I set the PTS of the individual UDP packets to a gradually
increasing value:

--- a/gst/rtp/gstrtpmp2tpay.c
+++ b/gst/rtp/gstrtpmp2tpay.c
@@ -123,11 +123,12 @@ gst_rtp_mp2t_pay_setcaps (GstRTPBasePayload *
payload, GstCaps * caps)
 static GstFlowReturn
 gst_rtp_mp2t_pay_flush (GstRTPMP2TPay * rtpmp2tpay)
 {
-  guint avail, mtu;
+  guint avail, mtu, size;
   GstFlowReturn ret = GST_FLOW_OK;
   GstBuffer *outbuf;

   avail = gst_adapter_available (rtpmp2tpay->adapter);
+  size=avail;

@@ -160,8 +161,8 @@ gst_rtp_mp2t_pay_flush (GstRTPMP2TPay * rtpmp2tpay)
     outbuf = gst_buffer_append (outbuf, paybuf);
     avail -= payload_len;

-    GST_BUFFER_PTS (outbuf) = rtpmp2tpay->first_ts;
-    GST_BUFFER_DURATION (outbuf) = rtpmp2tpay->duration;
+    GST_BUFFER_PTS (outbuf) = rtpmp2tpay->first_ts +
(size-avail)*rtpmp2tpay->duration / size ;
+    GST_BUFFER_DURATION (outbuf) = rtpmp2tpay->duration*payload_len/size;

     GST_DEBUG_OBJECT (rtpmp2tpay, "pushing buffer of size %u",
         (guint) gst_buffer_get_size (outbuf));

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.

Best Regards,
Lajos




On Thu, Apr 18, 2019 at 10:48 AM Tim Müller <tim at centricular.com> wrote:

> On Tue, 2019-04-16 at 17:22 +0200, Lajos Okos wrote:
>
> Hi Lajos,
>
> > I have a recorded HLS stream created with hlssink2 that I would like
> > to stream with the below pipeline:
> >
> > gst-launch-1.0 \
> >   2   souphttpsrc location=http://.../.../playlist.m3u8 ! \
> >   3   hlsdemux ! \
> >   4   tsparse set-timestamps=true ! \
> >   5   rtpmp2tpay ! \
> >   6   udpsink sync=true host=239.211.8.222 port=1234
> >
> > I can play the multicast stream from the pipeline with VLC more or
> > less ok, although time to time the picture freezes and I lose audio.
> >
> > Configuring some logging for tsparse, I can see that it pushes
> > buffers out with quite a large variation in duration. Sometimes the
> > buffers have duration of 5-6 seconds other time they are just a
> > fraction of a second. Checking the stream in Wireshark the bitrate of
> > the player's multicast stream varies a lot. Is there a way to keep
> > the duration of the pushed buffers from tsparse low? I guess the
> > large variation of the output bitrate is due to the fact that the
> > elements following tsparse underrun but this is just guessing. Any
> > suggestions on how to change the pipeline that the output bitrate
> > stays more or less static with just a reasonable variation?
> >
> > Many thanks for your suggestions!
>
> If you suspect that the elements following tsparse underrun, then a
> generous queue might help (queue max-size-time=30000000000 max-size-
> bytes=0 max-size-buffers=0 or somesuch perhaps).
>
> Cheers
>  Tim
>
> --
> Tim Müller, Centricular Ltd - http://www.centricular.com
>
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20190425/ea6ae96e/attachment.html>