gst-launch locked with 2 source 2 sink

[Aurele Traynard]

Hey

Thanks for your answer, which confirms what I saw...
As I wanted to do RTCP communication, I started to try it, I wanted to see
if the behaviour was the same with RTCP, obviously it was the same...
But by trying to tune my RTCP line I noticed some people were using
"sync=false async=false" on their "udpsink", and this fixed my "deadlock"...
So if anyone has the same problem the following line works perfectly :

filesrc location=/dev/pcm0.2 blocksize=1024 do-timestamp=true
num-buffers=-1 ! "audio/x-alaw,rate=8000,channels=1" ! rtppcmapay !
rtpbin1.send_rtp_sink_0 \
rtpbin1.send_rtp_src_0 ! udpsink host=192.168.48.45 port=10802 *sync=false
async=false* \
udpsrc do-timestamp=true port=10800 caps="application/x-rtp,
media=(string)audio, payload=(int)8, clock-rate=(int)8000,
encoding-name=(string)PCMA" ! rtpbin1.recv_rtp_sink_0 \
rtpbin1. ! rtppcmadepay ! filesink "buffer-mode=2" "location=/dev/pcm0.1" \
rtpbin1.send_rtcp_src_0 ! udpsink port=5003 host=192.168.48.45 sync=false
async=false \
udpsrc port=5007 ! rtpbin1.recv_rtcp_sink_0 \
rtpbin name=rtpbin1 \

by removing " sync=false async=false" in "udpsink host=192.168.48.45
port=10802 sync=false async=false" the pipe stay locked until data is
received by the "udpsrc"
by reading the "udpsink" description, I don't really know why, but I
understand that keeping it synchronized to the clock doesn't help...

thanks
Aurèle


2015-09-24 21:19 GMT+02:00 Sérgio Agostinho <sergio.r.agostinho at gmail.com>:

> Hey,
>
> Without receiving data, your udpsrc element won't be able to transition
> into a playing state. Because of this, your pipeline will wait for udpsrc
> before allowing all other elements to start playing. Your easiest option is
> to simply separate your pipeline into two.
>
> gst-launch-1.0 filesrc location=/dev/pcm0.2 blocksize=256
> do-timestamp=true num-buffers=100000 ! "audio/x-alaw,rate=8000,channels=1"
> ! rtppcmapay ! udpsink async=true bind-port=10800 host=192.168.48.45
> port=10800
>
> and in another shell
>
> gst-launch-1.0 udpsrc buffer-size=4096 socket=NULL port=10801
> caps="application/x-rtp" ! rtppcmadepay ! filesink "buffer-mode=1"
> "location=/dev/pcm0.1"
>
> Cheers
>
> 2015-09-24 18:00 GMT+02:00 Aurele Traynard <aurele.traynard at gmail.com>:
>
>> Hi everyone
>>
>>
>> I'm facing an issue with a gst-launch configuration :
>> filesrc -> rtppcmapay -> udpsink
>> udpsrc -> rtppcmadepay -> filesink
>>
>> nothing is received on the udpsrc at first
>>
>> see commandline :
>> gst-launch-1.0 filesrc location=/dev/pcm0.2 blocksize=256
>> do-timestamp=true num-buffers=100000 ! "audio/x-alaw,rate=8000,channels=1"
>> ! rtppcmapay ! udpsink async=true host=192.168.48.45 port=10800  udpsrc
>> buffer-size=4096 socket=NULL port=10801 caps="application/x-rtp" !
>> rtppcmadepay ! filesink "buffer-mode=1" "location=/dev/pcm0.1"
>>
>> after some read (I wrote the driver so I can see how much data is
>> available and how much was read) gstreamer locks himself, nothing is read
>> anymore...
>> If I send some data to the udp socket everything start to be normal even
>> if I stop to send data to the udp port 10801 ... So my understanding is
>> that the udpsrc locks my pipeline, but I can't understand why... or maybe
>> the udpsrc unlock my pipeline...
>>
>> If I launch only the following everything is working :
>> filesrc -> rtppcmapay -> udpsink
>> gst-launch-1.0 filesrc location=/dev/pcm0.2 blocksize=256
>> do-timestamp=true num-buffers=100000 ! "audio/x-alaw,rate=8000,channels=1"
>> ! rtppcmapay ! udpsink async=true bind-port=10800 host=192.168.48.45
>> port=10800
>>
>>
>> The goal is to have a 2 way communication between 2 device, and starting
>> gstreamer at the same time on both device it seems we loose enough data
>> during the startup phase to lock the stream...
>>
>> If anyone has an idea I will be really happy to test ;)
>> Thanks for any help or question
>> Aurele
>>
>> _______________________________________________
>> gstreamer-devel mailing list
>> gstreamer-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>>
>>
>
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20150930/0ebc05a1/attachment.html>