RTP Multicast issue

[de_ninja]

Hey,

I am streaming from one Raspberry Pi to another using RTP.

my sending pipeline:
gst-launch-1.0 alsasrc device=plughw:Device ! opusenc ! rtpopuspay ! udpsink host=192.168.1.107 port=8001

my receiving pipeline:
gst-launch-1.0 udpsrc port=8001 caps="application/x-rtp" ! rtpopusdepay ! opusdec ! audioconvert ! alsasink

device=plughw:Device is my soundcard. I use it to receive sound from a TV and send the audio to the other Raspberry. I have no noticeable latency or other issues whatsoever.

But I need my stream to be received by multiple Raspberry Pi's. Now when I try following pipelines with multicast, I have massive issues.

sending:
gst-launch-1.0 alsasrc device=plughw:Device ! opusenc ! rtpopuspay ! udpsink host=224.0.0.1 port=8001

receiving:
gst-launch-1.0 udpsrc multicast-group=224.0.0.1 port=8001 caps="application/x-rtp" ! rtpopusdepay ! opusdec ! audioconvert ! alsasink

The quality drops dramatically, so I dont understand a word. I guess with multicast the Raspberry sends the audio signal to every possible receiving end at once which is inefficient, when there is only one Raspberry Pi connected to the stream.
Now my question is whether I can improve the quality or maybe there is a better solution for multicast streaming.
Because wouldn't it be easier to send the stream to one "place" and every receiving end would "download" it, instead of sending it to every single receiving end?

EDIT: Decided to try sending multiple unicasts at once, seems like this solves my problem. Requires testing with more devices to be sure.

[Tim Müller]

On Thu, 2016-07-21 at 07:43 -0700, de_ninja wrote:

Hi,

For what it's worth, it's usually a good idea to add a 'queue' element
after your capture source (alsasrc).

Maybe check the depayloader logs with GST_DEBUG to see if there are any
clues as to what might cause the issues.

> my receiving pipeline:
> gst-launch-1.0 udpsrc port=8001 caps="application/x-rtp" !
> rtpopusdepay !
> opusdec ! audioconvert ! alsasink

Usually you'll want an rtpjitterbuffer here between the udpsrc and
rtpopusdepay as well. That will introduce some latency but you can
configure that on the rtpjitterbuffer element with the latency
property. The jitterbuffer will take care of things like duplicate
packets or packet reordering. It will depend on your network setup if
this is needed or not, and on whether you can accept the extra latency.

For an alternative approach, you could also have a look at gst-rtsp-
server. If you mark a media factory as shared there, it means multiple
clients can connect to the same stream you produce.

e.g.

gst-rtsp-server/examples$ ./test-launch 'alsasrc ! queue ! audioconvert
! opusenc ! rtpopuspay name=pay0'


and on the client side e.g.:

gst-launch-1.0 rtspsrc location=rtsp://127.0.0.1:8554/test latency=5 ! rtpopusdepay ! queue ! opusdec ! pulsesink
Just something else for you to experiment with if you feel so inclined
:)

Cheers
 -Tim

--

Tim Müller, Centricular Ltd - http://www.centricular.com



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