Le 30 octobre 2010 10:27, Rémi Denis-Courmont <span dir="ltr"><<a href="mailto:remi@remlab.net">remi@remlab.net</a>></span> a écrit :<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Le samedi 30 octobre 2010 09:00:29 Pierre Ynard, vous avez écrit :<br><div class="im">
> > This is a silly problem. Payload types are scoped to the RTP session<br>
> > / the SDP m-line. Since VLC never streams more than one payload<br>
> > format per RTP stream, there is no risk of conflict. We might as well<br>
> > hard-code value 96 for all dynamic payload types.<br>
><br>
> We could also implement streaming several payload types in the same RTP<br>
> session,<br>
<br>
</div>Yes, but that's rarely useful. First, the design of RTP implicitly limits this<br>
to payload types with equal timestamp frequency. Otherwise delay jitter<br>
computations and synchronization would go crazy. Second, I have to expect many<br>
receivers will fail miserably, including current VLC.<br></blockquote><div><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="im">
> that would provide an alternative to TS muxing in order to<br>
> stream without needing SDP.<br>
<br>
</div>You are not supposed to multiplex concurrent streams on the same RTP session.<br></blockquote><div><br>I second this...<br><br>The whole point in RTSP+RTP is that you use RTSP to gather information about various "uniplex" concurrent stream describe into an SDP format and then make as many individual RTP connection for each stream (audio, video, ...).<br>
<br>There is however one well known multiplexing in use and documented that VLC support on the client side: rtsp-over-http also known as QT http fallback.<br>Basically it take a single TCP connection for control and data and it multiplex the stream on this connection. There is a trick<span dir="ltr"></span> with a POST and a GET that are link together to make it work. Unfortunately some (but not all) proxy (I mean http proxy) do not play nicely with that way of streaming.<br>
<br>I don't know if it is relevant to your work on the VoD module... but it is definitively something that lack inside VLC to make it look like a real Streaming Server (such as Darwin Streaming Server) and have a chance to be access by user behind NAT or Firewall that are not RTP/UDP friendly.<br>
<br>David Glaude<br></div></div>