Hi Sebastian, Unfortunately mtu is fixed in this case, and is around 700 bytes. I am able to stream H264 for 30-40 seconds now. After that the decoder reports corrupted data. But in case of H263 I am getting errors from the beginning. Does the limited mtu have an effect on it? Do I need to collect enough data in a buffet before passing it on to next element? Hi Chuck, I am setting mtu on the Payloader itself. Sorry I was not clear about it in the mail. Thanks, Prasad <div class="gmail_quote">On Aug 17, 2015 7:48 PM, "Chuck Crisler" <<a href="mailto:ccrisler@mutualink.net">ccrisler@mutualink.net</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">For RTP shouldn't the MTU be set on the payloader rather than the sink? Otherwise, the payloader will generate packets with a 1400 byte MTU and they will get fragmented later. However, often the DNF (do not fragment) bits get set and that causes a real mess. <div><div class="gmail_extra"> <div class="gmail_quote">On Sun, Aug 16, 2015 at 3:32 AM, Sebastian Dröge <<a href="mailto:sebastian@centricular.com" target="_blank">sebastian@centricular.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On So, 2015-08-16 at 10:30 +0530, Prasad Bhat wrote: > Hi All, > > I am writing source and sink plugins for a custom GStreamer pipline, > and facing an issue. > The medium that transports the video has a mtu limitation, So I am > setting mtu property in the transportsink. > > [...] > In the myvidsink I have a bin, which has capsfilter, rtph264pay and > transportsink. The mtu property is set on rtph264pay. > > [...] > > The problem I am facing is, the video streams properly for 10-15 > seconds, and then it gets corrupted. Could anyone please help me by > pointing out what I am doing wrong? Check with e.g. wireshark if packets get lost, or if any packet fragmentation is happening. RTP packets have a sequence number, and that's supposed to be monotonically increasing by one. Also make sure that you have large enough kernel-side buffers for the UDP sockets on both sides, and try increasing them if you didn't do so yet. -- Sebastian Dröge, Centricular Ltd · <a href="http://www.centricular.com" rel="noreferrer" target="_blank">http://www.centricular.com</a> _______________________________________________ gstreamer-devel mailing list <a href="mailto:gstreamer-devel@lists.freedesktop.org" target="_blank">gstreamer-devel@lists.freedesktop.org</a> <a href="http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" rel="noreferrer" target="_blank">http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a> </blockquote></div> </div></div></div> _______________________________________________ gstreamer-devel mailing list <a href="mailto:gstreamer-devel@lists.freedesktop.org">gstreamer-devel@lists.freedesktop.org</a> <a href="http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" rel="noreferrer" target="_blank">http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a> </blockquote></div>