queue problem

[Hoggins!]

Hello list,

I'm new here, and I'm posting for the first time with a little problem,
mostly due to my lack of knowledge. I'm sure it has already been
discussed here, but I can't find it in the list's archives.

I'm trying to receive audio from another Gstreamer sender (which works
perfectly, I'm able to receive clear sound on a test machine), and
duplicate it in several flavours on an Icecast server. So the Gstreamer
receives the CELT data, depays, decodes, and then uses different queues
to encode it in mp3 (320kbps, 192kbps, and so on), and send it as
different mountpoints on the Icecast server.

I'm able to send it once, but I cannot duplicate the streams, using the
queue element. Can anyone tell me what I'm doing wrong ? The following
syntax throws an error : "pipeline error : can't connect shout2send0 to
queue1".


gst-launch gstrtpbin name=rtpbin udpsrc port=5000
caps='application/x-rtp, media=(string)audio, clock-rate=(int)44100,
encoding-name=(string)CELT, encoding-params=(string)2,
frame-size=(string)480, payload=(int)96' ! rtpceltdepay ! celtdec !
queue ! audioconvert ! lame bitrate=320 ! shout2send mount=/live320.mp3
port=8000 password=xxxx ip=127.0.0.1 ! queue ! audioconvert ! lame
bitrate=320 ! shout2send mount=/live320.mp3 port=8000 password=xxxx
ip=127.0.0.1

Thanks in advance,

    Hoggins!


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

[Mike Mitchell]

Hoggins,

If you try "gst-inspect shout2send", you will see that it only has a sink.  A queue is just a buffer that creates a thread, but there is still only one pipeline and no output from your fitrst shout2send. What you need is a 'tee' to divide the pipes into duplicates.  You would use queues to thread your encoding. I could not test this without your environment, but this should get you close.

gst-launch gstrtpbin name=rtpbin udpsrc port=5000 \
caps='application/x-rtp, media=(string)audio, clock-rate=(int)44100, encoding-name=(string)CELT, encoding-params=(string)2, frame-size= (string)480, payload=(int)96'  \

! rtpceltdepay ! celtdec ! queue ! audioconvert !  tee name=t \

t. ! queue ! lame bitrate=320 ! shout2send mount=/live320.mp3 port=8000 password=xxxx ip=127.0.0.1

t. ! queue ! lame bitrate=192 ! shout2send mount=/live320.mp3 port=8001 password=xxxx ip=127.0.0.1

A diagram of what this might look like is below, it just encodes in stereo and mono but is similar.

http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gstreamer-plugins/html/gstreamer-plugins-tee.html

Mike Mitchell

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

[Hoggins!]

Wow ! Thanks a lot ! That did the trick, it's just perfect !

Now I'm facing a strange (well, not so strange) behaviour, maybe there is something that can be done.

The link providing our RTP stream is not 100% secure. Sometimes, it goes down. The streaming stops (as expected, of course), but when the link is back up, the receiving process exits with a "broken pipe" error. I suspect the shout2send element cannot keep up with the Icecast server when it is not fed anymore. My only solution is to use an ugly watchdog script that will restart the GStreamer receiving process whenever it goes down.

    Hoggins!

Le 02/10/2011 02:16, Mike Mitchell a écrit :

Hoggins,

If you try "gst-inspect shout2send", you will see that it only has a sink.  A queue is just a buffer that creates a thread, but there is still only one pipeline and no output from your fitrst shout2send. What you need is a 'tee' to divide the pipes into duplicates.  You would use queues to thread your encoding. I could not test this without your environment, but this should get you close.

gst-launch gstrtpbin name=rtpbin udpsrc port=5000 \
caps='application/x-rtp, media=(string)audio, clock-rate=(int)44100, encoding-name=(string)CELT, encoding-params=(string)2, frame-size= (string)480, payload=(int)96'  \

! rtpceltdepay ! celtdec ! queue ! audioconvert !  tee name=t \

t. ! queue ! lame bitrate=320 ! shout2send mount=/live320.mp3 port=8000 password=xxxx ip=127.0.0.1

t. ! queue ! lame bitrate=192 ! shout2send mount=/live320.mp3 port=8001 password=xxxx ip=127.0.0.1

A diagram of what this might look like is below, it just encodes in stereo and mono but is similar.

http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gstreamer-plugins/html/gstreamer-plugins-tee.html

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

[Wes Miller]

Hi Hoggins!

Let me introduce you to ytour Bgstreamer Best Friend, gst-inspect.  It
amounts to help for the elements.  If you gst-inspect shout2 sne d you;ll
see it has no src pads.  In other words, it is a terminal element, a sink,
into which data flows from the pipeline and ouyt of which data flows into
something else, in this case, the icecast server.

What that means is, you can't hook shout2send to a downstream element like
queue.  That's where your error is coming from.

Being very visual, here is a better picture of your pipe.  Pullling the
elements to a single column shows you the flow of data free from the
extraneous stuff in the other column(s).  I omitted the "string" and "int"
decorators to improve readability.  They are not required with gst-launch.
 They don't hurt, though, and may be needed occasionally, so feel free to
use them or not.

gst-launch
        Gstrtpbin
                name=rtpbin
        Udpsrc
                port=5000
                caps='application/x-rtp, media=audio, clock-rate=44100,
                encoding-name=CELT, encoding-params=2,
                frame-size=(string)480, payload=96'
        ! Rtpceltdepay
        ! Celtdec
        ! Queue
        ! Audioconvert
        ! Lame
                bitrate=320
        ! shout2send
                mount=/live320.mp3
                port=8000 password=xxxx ip=127.0.0.1
        ! Queue
        ! Audioconvert
        ! lame
                bitrate=320
        ! shout2send mount=/live320.mp3
                port=8000 password=xxxx ip=127.0.0.1


Here we see that shout2send is wupposed to flow into queue.  But
gst-inspect tells us that won't work.

I believe what you're missing is a "tee" after the celtdec element.  Tee
accepts a stream on its sink pad and can copy it to multiple src pads.
You use a tee by giving iy a name and then later hooking up its second,
third, etc. outputs by using the tee's name.  The first stream flows
straight out the other side of the tee.

gst-launch
        Gstrtpbin
        Udpsrc
        ! Rtpceltdepay
        ! Celtdec
        ! Tee name=myTee.
        ! Queue
        ! Audioconvert
        ! Lame
        ! shout2send            <==== first pipe "ends" here
        myTee.                  <==== no !, period is required, starts 2nd pipe
        ! Queue                 <==== always good after a tee for sync and starvation reasons
        ! Audioconvert
        ! lame
        ! shout2send mount=/live320.mp3



Now, I have never used shout2send.  But you ought to be able to move the
tee/queue pairs to just before the shout2sned element and avoid
duplicating work in the two pipelines.

gst-launch
        Gstrtpbin
        Udpsrc
        ! Rtpceltdepay
        ! Celtdec
        ! Audioconvert
        ! Lame
        ! Tee name=myTee.
        ! Queue
        ! shout2send
        myTee.
        ! Queue
        ! shout2send mount=/live320.mp3



One other thought.  Gst-inspect will also tell you the type for each
property of an element.  In you case, Frame-size is an int, not a string

Wesley J. Miller









On 10/1/11 10:40 AM, "Hoggins!" <[hidden email]> wrote:

>Hello list,
>
>I'm new here, and I'm posting for the first time with a little problem,
>mostly due to my lack of knowledge. I'm sure it has already been
>discussed here, but I can't find it in the list's archives.
>
>I'm trying to receive audio from another Gstreamer sender (which works
>perfectly, I'm able to receive clear sound on a test machine), and
>duplicate it in several flavours on an Icecast server. So the Gstreamer
>receives the CELT data, depays, decodes, and then uses different queues
>to encode it in mp3 (320kbps, 192kbps, and so on), and send it as
>different mountpoints on the Icecast server.
>
>I'm able to send it once, but I cannot duplicate the streams, using the
>queue element. Can anyone tell me what I'm doing wrong ? The following
>syntax throws an error : "pipeline error : can't connect shout2send0 to
>queue1".
>
>
>gst-launch gstrtpbin name=rtpbin udpsrc port=5000
>caps='application/x-rtp, media=(string)audio, clock-rate=(int)44100,
>encoding-name=(string)CELT, encoding-params=(string)2,
>frame-size=(string)480, payload=(int)96' ! rtpceltdepay ! celtdec !
>queue ! audioconvert ! lame bitrate=320 ! shout2send mount=/live320.mp3
>port=8000 password=xxxx ip=127.0.0.1 ! queue ! audioconvert ! lame
>bitrate=320 ! shout2send mount=/live320.mp3 port=8000 password=xxxx
>ip=127.0.0.1
>
>Thanks in advance,
>
>    Hoggins!
>

CONFIDENTIALITY NOTE:

This e-mail and any attachments are confidential. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of this e-mail or any attachment is prohibited. If you have received this e-mail in error, please notify us immediately by returning it to the sender and delete this copy from your system. Thank you for your cooperation.
_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Hoggins!]

Well then there is a bug, because I just pasted the contents of the whole string served by the sending process in debugging mode. I'll just remove the types.

    Thanks !

        Hoggins!

Le 03/10/2011 14:03, Wesley J. Miller a écrit :

In you case, Frame-size is an int, not a string

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

[Mike Mitchell]

Any network will have hickups. Your only defense is to delay playback enough to absorb them. Try "rtpbin latency=10000" to give 10 seconds of buffer.  This will reduce your outages to only those that last longer than 10 seconds. 

Maybe someone else has a better answer for restarting on a broken pipe. 

Mike Mitchell

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