<div dir="ltr"><div><div><div><div><div>This is an issue that I have observed a few times but postponed looking into. Now it has become critical. I have an app that is transmuxing MP2T into RTP. With problems i have had with RTP I have added a small amount of logging. I got lucky and the log file shows that gst_basertppayload_push() took 27 seconds to complete in this one case. Here are log messages:<br>
<br>Aug  7 12:11:58 imsvcctl[32229]: 0:00:55.201035830 32229  0x89c5fd8 DEBUG             rtph264pay gstrtph264pay.c:799:gst_rtp_h264_pay_payload_nal:<RTPPayloader> Copying 1133 bytes to outbuf<br>
Aug  7 12:11:58 imsvcctl[32229]: 0:01:22.485585907 32229  0x89c5fd8 INFO              rtph264pay gstrtph264pay.c:805:gst_rtp_h264_pay_payload_nal: Pushed buffer w/ SeqNbr: 9099<br><br></div>
Here is the source code.<br><br>      payload = gst_rtp_buffer_get_payload (outbuf);<br>      GST_DEBUG_OBJECT (basepayload, "Copying %d bytes to outbuf", size);<br>      memcpy (payload, data, size);<br><br>      ret = gst_basertppayload_push (basepayload, outbuf);<br>
    }<br>//CMC<br>    GST_INFO("Pushed buffer w/ SeqNbr: %u", gst_rtp_buffer_get_seq(outbuf));<br>//CMC<br><br></div>The GST_DEBUG_OBJECT is line 799.<br><br></div>I am using GStreamer 0.10.30 with good plugins 0.10.25. Upgrading is currently not an option.<br>
<br></div>I have observed this numerous times, including simply running scripts that use gst-launch. The RTP processing will (usually) run for a brief time, then stall, then run, then stall, etc.<br><br></div>I suspect a network buffer issue. Does anyone know anything about this issue?<br>
<br>Thank you,<br>Chuck<br></div>