<div dir="ltr">Hi Tim<br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Dec 25, 2016 at 1:48 PM, Tim Müller <span dir="ltr"><<a href="mailto:tim@centricular.com" target="_blank">tim@centricular.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The reason replacing udpsrc with a filesrc or fdsrc doesn't work is<br>
that with RTP/UDP the packetisation of the data matters. The RTP<br>
elements need to know where a packet starts and ends, and by convention<br>
one buffer represents one UDP/RTP packet received.<br>
<br>
If you just dump the RTP data into a pipe or file, then you turn it<br>
into a stream and the packetisation is lost.<br></blockquote><div><br></div><div>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?<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
You can use the rtpstreampay/rtpstreamdepay elements to maintain the<br>
packetisation, but there are more things to look out for.<br>
<br>
The RTP elements (esp. rtpjitterbuffer) expect that packets are<br>
timestamped with the capture time, so that it can calculate clock drift<br>
between sender and receiver. So even if you use rtpstreampay/depay that<br>
won't give you timestamps. It'll still work for testing purposes to<br>
some extent, but it won't work nicely in real-world scenarios.<br></blockquote><div><br></div><div>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?<br><br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
In an app you could write some code to timestamp buffers coming out of<br>
rtpstreamdepay with the clock running time. (ignoring the delay/jitter<br>
between actual capture and sending it through the pipe).<br>
<br>
In case it doesn't have to be a pipe, there's also e.g. shmsink/src:<br></blockquote><div><br></div><div>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?<br> <br></div>--Peter<br></div></div></div>