<div dir="ltr">Hi Nicolas.<br><div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 23, 2015 at 5:37 PM, Nicolas Dufresne <span dir="ltr"><<a href="mailto:nicolas.dufresne@collabora.com" target="_blank">nicolas.dufresne@collabora.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">Le mardi 23 juin 2015 à 12:37 +0200, Peter Maersk-Moller a écrit :<br>
> Why not use a multiplexer like<br>
> mpegtsmux and have audio/video encoded and muxed and sent in a single<br>
> pipeline and then in another pipeline receiving multiplexed stream,<br>
> demuxing it, decoding it and then played?<br>
<br>
</span>Because the "Lab work" says he wanted to do RTP.<br></blockquote><div><br></div><div>True, but still possible to mux AND use RTP. To get sync you will need either a mux or RTSP protocol or the complicated partly manually RTP/RTCP thing we talk about in another thread.<br><br></div><div>I have never experienced a RTSP setup that did not add a lot of delay, which is not good for a video chat. That smallest delay I have experienced is with RTP, but for sync then a mux or the more complicated RTCP-setup is needed and I don't know if the manual RTCP-setup will add as much delay as RTSP does. After all RTSP is a protocol wrapper around the more complicated RTP/RTCP setup. Okay to be fair to RTSP, implementations sometimes have a latency/jitterbuffer you can tune, but, delay-wise I still have <b>not</b> seen an implementation that blew me away.<br><br></div><div>Peter<br></div></div></div></div></div>