Receiving RTP without udpsrc

[Peter Maersk-Moller]

Hi Tim

On Sun, Dec 25, 2016 at 1:48 PM, Tim Müller <tim at centricular.com> wrote:

> The reason replacing udpsrc with a filesrc or fdsrc doesn't work is
> that with RTP/UDP the packetisation of the data matters. The RTP
> elements need to know where a packet starts and ends, and by convention
> one buffer represents one UDP/RTP packet received.
>
> If you just dump the RTP data into a pipe or file, then you turn it
> into a stream and the packetisation is lost.
>

What you write is true, however on Linux and OS X, it appear that when you
can create two processes connected with an unnamed pipe, packetization
seems to be maintained. It will not work for named pipes, where
packetization is lost. Using xinetd/fdsrc or fdsink/fdsrc and subseqently
using unnamed pipe from stdout to stdin, whenever the sending process sends
a packet, the reading process appear to read the data in the data chunk
size it was sent. Admittedly though I can not find this substatiated in the
original Unix specs, it seems to work. It might however be a good idea, if
the writing process flushes it output after each packet. Would that be an
idea for an option to set for fdsink?

You can use the rtpstreampay/rtpstreamdepay elements to maintain the
> packetisation, but there are more things to look out for.
>
> The RTP elements (esp. rtpjitterbuffer) expect that packets are
> timestamped with the capture time, so that it can calculate clock drift
> between sender and receiver. So even if you use rtpstreampay/depay that
> won't give you timestamps. It'll still work for testing purposes to
> some extent, but it won't work nicely in real-world scenarios.
>

If the sender is sending live data (and sets the sync option), on a
non-overloaded receiver system, setting do-timestamp to true seems to make
it work, although this is an approximation. But would not audiorate fix
this for raw data?



> In an app you could write some code to timestamp buffers coming out of
> rtpstreamdepay with the clock running time. (ignoring the delay/jitter
> between actual capture and sending it through the pipe).
>
> In case it doesn't have to be a pipe, there's also e.g. shmsink/src:
>

Can you sandbox the reader with chroot if you use shmsink/src? Doesn't it
have to be able to read /dev/shm or is it just something I imagine?

--Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20161225/d5ceefee/attachment.html>