RTP Multicast issue

[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