Hi, On Wed, Dec 11, 2013 at 11:15 AM, abhilash wrote: > Hi, > > Thanks for your reply. > As you suggested I tried using rtprtxqueue on receiver side(pipeline below): > > gst-launch-1.0 -v rtpbin name=rtpbin udpsrc port=5000 > caps="application/x-rtp, media=audio, clock-rate=8000, encoding-name=PCMA, > payload=8" ! rtpbin.recv_rtp_sink_0 rtpbin. ! rtprtxqueue ! rtppcmadepay ! > alawdec ! > > alsasink udpsrc port=5001 ! rtpbin.recv_rtcp_sink_0 rtpbin.send_rtcp_src_0 > ! udpsink host=192.154.10.21 port=5005 sync=false async=false > --gst-debug=3 > > Still I am not able to see any RTCP packets other than reports from receiver > to sender in wireshark. > Is above pipeline correct? > As per my understanding there should be RTCP request from receiver to sender > to send again lost packets. > Is this correct? > You misunderstood what I said. I said you need to use the do-retransmission=true on the receiver side and that rtprtxqueue needs to be added after the *pay*loader, which lives on the sender side. Regards, George On Wed, Dec 11, 2013 at 11:15 AM, abhilash wrote: > Hi, > > Thanks for your reply. > As you suggested I tried using rtprtxqueue on receiver side(pipeline below): > > gst-launch-1.0 -v rtpbin name=rtpbin udpsrc port=5000 > caps="application/x-rtp, media=audio, clock-rate=8000, encoding-name=PCMA, > payload=8" ! rtpbin.recv_rtp_sink_0 rtpbin. ! rtprtxqueue ! rtppcmadepay ! > alawdec ! > > alsasink udpsrc port=5001 ! rtpbin.recv_rtcp_sink_0 rtpbin.send_rtcp_src_0 > ! udpsink host=192.154.10.21 port=5005 sync=false async=false > --gst-debug=3 > > Still I am not able to see any RTCP packets other than reports from receiver > to sender in wireshark. > Is above pipeline correct? > As per my understanding there should be RTCP request from receiver to sender > to send again lost packets. > Is this correct? > > Thanks, > Abhilash. > > > > On Wed, Dec 11, 2013 at 3:21 PM, George Kiagiadakis [via GStreamer-devel] > <[hidden email]> wrote: >> >> On Wed, Dec 11, 2013 at 10:29 AM, abhilash <[hidden email]> wrote: >> >> > Hi, >> > >> > I am trying out a client-server based audio streaming application >> > using >> > gstreamer 1.2.0 version, running on 2 different Linux machines on >> > network. I >> > want to check the functionality of retransmissions as mentioned in the >> > "rtpbin" element and I tried setting the property >> > "do-retransmissions=true". >> > I am simulating packet loss, packet delay & reorder on the server side. >> > The >> > observation is as follows - >> > 1. I am able to see RTCP Sender and Receiver reports being sent between >> > server and client on Wireshark. >> > 2. I am able to see dropped RTP packet sequence numbers in Wireshark >> > trace, >> > however I am not able to see any RTP retransmissions event going from >> > client >> > to server. >> > >> > The pipelines at the server and client side are as mentioned below - >> > >> > Server: >> > gst-launch-1.0 -v rtpbin name=rtpbin do-retransmission=true audiotestsrc >> > freq=1000 ! audioconvert ! alawenc ! rtppcmapay ! rtpbin.send_rtp_sink_0 >> > rtpbin.send_rtp_src_0 ! udpsink host=192.154.10.20 port=5000 >> > rtpbin.send_rtcp_src_0 ! udpsink host=192.154.10.20 port=5001 sync=false >> > async=false udpsrc port=5005 ! rtpbin.recv_rtcp_sink_0 --gst-debug=3 >> > >> > Client: >> > gst-launch-1.0 -v rtpbin name=rtpbin udpsrc port=5000 >> > caps="application/x-rtp, media=audio, clock-rate=8000, >> > encoding-name=PCMA, >> > payload=8" ! rtpbin.recv_rtp_sink_0 rtpbin. ! rtppcmadepay ! alawdec ! >> > alsasink udpsrc port=5001 ! rtpbin.recv_rtcp_sink_0 >> > rtpbin.send_rtcp_src_0 >> > ! udpsink host=192.154.10.21 port=5005 sync=false async=false >> > --gst-debug=3 >> > >> > Can anyone please let me know if anything is missed out above and >> > why I >> > am not seeing any RTP retransmissions ? >> > >> Hi, >> >> do-retransmission=true should be set on the receiver (client) rtpbin. >> On the sender it has no effect. Also, since you are on 1.2, you need >> to add rtprtxqueue in your pipeline after the payloader. Note though >> that this does not implement RFC4588-compliant retransmission packets. >> An RFC4588-compliant implementation is under review in bugzilla at the >> moment. >> >> Regards, >> George >> _______________________________________________ >> gstreamer-devel mailing list >> [hidden email] >> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel >> >> >> ________________________________ >> If you reply to this email, your message will be added to the discussion >> below: >> >> http://gstreamer-devel.966125.n4.nabble.com/RTP-retransmission-mechanism-in-gstreamer-1-2-0-tp4663965p4663966.html >> To unsubscribe from RTP retransmission mechanism in gstreamer 1.2.0, click >> here. >> NAML > > > > ________________________________ > View this message in context: Re: RTP retransmission mechanism in gstreamer > 1.2.0 > > Sent from the GStreamer-devel mailing list archive at Nabble.com. > > _______________________________________________ > gstreamer-devel mailing list > gstreamer-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel > _______________________________________________ gstreamer-devel mailing list gstreamer-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel