Losing Packets When trasmitting data over UDP through RTP.

[prasanth123]

I have developed an application which takes data from file and add metadata to each frame and transfer that data to client through udp over rtp.

At receiver end client removes that metadata and has to play the video.

for that I used At server End:

    pipeline1 :: gst-launch-1.0 filesrc ! videoparse ! appsink

at appsink adding metadata and push that buffer to appsrc.

    pipeline 2 :: gst-launch-1.0 appsrc ! rtpgstpay ! udpsink

At Receivers end ::

    pipeline1 :: gst-launch-1.0 udpsrc ! rtpgstdepay ! appsink

at appsink removing the metadata and push the buffer to appsrc.

    pipeline2 :: gst-launch-1.0 appsrc ! videoparse ! autovideoconvert ! autovideosink

Losing Packets at Receiver END..

The Problem is At receivers end i am not getting all the frames and the video also not playing properly. Only one frame playing and stopping and again playing only single frame.

Can anyone provide some solution or suggestion?

[Arjen Veenhuizen]

Try to add a rtpjitterbuffer in the receiving pipeline before the depayloader. I am not to familiar with rtpgstpay  and rtpgstdepay, but shouldn't you specify some caps on the receiving pipeline?

[prasanth123]

I Specified the caps using capsfilter component. Actually I am playing the video which is of YUV. Format.


And at depay i am getting warning as 'event string not 0 terminated'.

If you know how to resolve this warning let me know.

[Peter Maersk-Moller-2]

Hi

On Tue, Nov 24, 2015 at 6:17 AM, prasanth123 <[hidden email]> wrote:

The Problem is At receivers end i am not getting all the frames and the
video also not playing properly. Only one frame playing and stopping and
again playing only single frame.

How do you detect that you "at receiver end" are "not getting all the frames" ?

How many Mbps are you sending ?

What kind of hardware and which OS is the "receiver end"?

What is the system load of the "receiver end"?

I have had similar problems loosing RTP packets on both heavy loaded XEON based Linux servers as well as Raspberry PI based systems. I suspected network packet loss, but saw no loss when using tcpdump to inspect RTP sequence number yet the udpsrc module was not picking up all the packets. It turned out that improving the systems UDP receiver buffer was the answer. On a Raspberry Pi 2 I used the following

sysctl  -w net.core.rmem_max=2621440

This increased the default udp receiver buffer by a factor 16 for a RaspPi2 running Ubuntu. Other distros may have other defaults. Other OSs have similar ways to increase the system default UDP receiver buffer.

Best regards

Peter

 

Can anyone provide some solution or suggestion?



--
View this message in context: http://gstreamer-devel.966125.n4.nabble.com/Losing-Packets-When-trasmitting-data-over-UDP-through-RTP-tp4674613.html
Sent from the GStreamer-devel mailing list archive at Nabble.com.
_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[prasanth123]

Thanks for that,

I actually resolved that issue,

but the problem is when i am using rtpgstdepay to depay the load, i am getting warning as 'missing caps 0' && sometimes 'event string 0 not terminated'.

Why i am getting this ?? and how to resolve this issue??

[wilson1994]

Hi,

For people experiencing this problem: when depayloading with rtpgstdepay
your application needs a "caps string". you can find this by printing the
caps of the rtpgstpay element at the transmitter, eg:

 application/x-rtp, media=(string)application, clock-rate=(int)90000,
encoding-name=(string)X-GST,
caps=(string)"dmlkZW8veC1yYXcsIGZvcm1hdD0oc3RyaW5nKUdSQVk4LCB3aWR0aD0oaW50KTY0MCwgaGVpZ2h0PShpbnQpNDYwLCBpbnRlcmxhY2UtbW9kZT0oc3RyaW5nKXByb2dyZXNzaXZlLCBwaXhlbC1hc3BlY3QtcmF0aW89KGZyYWN0aW9uKTEvMSwgY29sb3JpbWV0cnk9KHN0cmluZykxOjQ6MDowLCBmcmFtZXJhdGU9KGZyYWN0aW9uKTI1LzE\=",
capsversion=(string)0, payload=(int)96, ssrc=(uint)1971573585,
timestamp-offset=(uint)4106561678, seqnum-offset=(uint)18771,
a-framerate=(string)25;

Here the caps string is
"dmlkZW8veC1yYXcsIGZvcm1hdD0oc3RyaW5nKUdSQVk4LCB3aWR0aD0oaW50KTY0MCwgaGVpZ2h0PShpbnQpNDYwLCBpbnRlcmxhY2UtbW9kZT0oc3RyaW5nKXByb2dyZXNzaXZlLCBwaXhlbC1hc3BlY3QtcmF0aW89KGZyYWN0aW9uKTEvMSwgY29sb3JpbWV0cnk9KHN0cmluZykxOjQ6MDowLCBmcmFtZXJhdGU9KGZyYWN0aW9uKTI1LzE\="
.

Note that when adding this caps string to your capsfilter at the receiver,
you should add a null terminator ( \0 ) to the end of the string. That
explains your warnings: either it complains that the caps string is missing,
or that it is not null terminated.



--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel