[vlc-devel] will streaming protocols survive OR will http become the protocol of choice?!
rdenis at simphalempin.com
Mon Feb 4 16:44:53 CET 2008
Le Tuesday 29 January 2008 22:50:44 Ross Finlayson, vous avez écrit :
> One big benefit of RTSP is that it provides a standard,
We (you and me) wish it would. Unfortunately, feature bloat and corporate
strategies have made RTSP into a noticeably non-interoperating "standard"
For instance, why oh why is the Range: parameter so complicated? Who/what
would ever need to schedule multiple streaming of multiple discontinuous time
ranges? Sure, one could program a would-be RTSP-based DVR to record different
broadcasts from the same TV channel... But it could as well send as many
SETUPs as there are Ranges. And both clients and servers would be way simpler
to implement. In practice, I suspect no server implements the Range parameter
*properly* (VLC definitely does NOT). In turns, it makes it more difficult
for clients to know what they can expeft from server, and IOP goes away.
That's my favorite example of the bloast of RTSP.
> You can't do this usng HTTP, at least not in any standard way.
But it could be standardized easily, using new HTTP headers, or even URI
> (Although you can sometimes do seeking using HTTP
> range queries, this works only for media types that are simple and
> uniform enough for the client to know where to seek.)
Indeed. But any VoD-friendly file format should do this anyway, if only so you
can seek the file *locally*. Also, we need to keep in mind that most if not
all operating systems are only capable of seeking byte ranges. Therefore, to
seek to a "certain time", the server needs to convert the time into a certain
byte offset anyhow. Hence, the file format on the server side needs to
support seeking in any case.
> Another benefit comes from its combination with RTP/RTCP, which is
> the standard transport protocol for 'real time' media - including IP
> telephony and video conferencing.
> This means that if you have an existing software infrastructure for
> delivering and/or receiving RTP/RTCP,
True that RTP is a very well designed, *not* bloated protocol for real-time
loss-tolerant data transmission. In my opinion, there is no arguing that any
RT streaming solution should use RTP.
However, there are significant differences in how to write a duplex RTP stack
for VoIP/conferencing, and how to write a simplex RTP stack for media
streaming (--> VLC). At least, if you want to support symmetric RTP, and any
SIP stack definitely should support it.
I am not surprised that, inspite of many reported attempts, nobody yet came up
with a SIP plugin for VLC. The VLC RTP support simply is "simplex-centric".
> then adding support for VOD etc.,
> using RTSP, is relatively stratighforward.
In the same unfirewalled public IP addresses world that SIP has been designed
> Nonetheless, as Remi notes, the firewall/NAT unfriendliness of these
> protocols remains a major problem
There we go :(
> (but the IETF is working to overcome this).
I beg to differ. The few RTSP folks at IETF have been floating the idea of
standardizing NAT traversal for RTSP for several years, yet nothing concrete
has happened yet. Except for the decision to use ICE as the underlying NAT
traversal mechanism. And that will need RTSP/2.0 which is yet to come too.
Anyway - how to use ICE with RTSP is not so much of a concern to me than the
choice of ICE by itself. ICE is benchmarked to operate in a "peer-to-peer"
symmetric fashion, such as for two VoIP clients to communicate, both from
behind NATs. ICE is as complicated as it is powerful. I daresay know what I
am talking about: I co-authored an open-source ICE stack at Nokia
RTSP is a client/server protocol. It would be only natural to have a much
simpler and more reliable client-to-server "hole punching" schema there,
which would need much fewer changes to RTSP, and much engineering effort, yet
*better* reliability in the common case that the server has a public IP and
the client does not.
Frankly, if VLC had had a built-in RTSP stack (i.e. were not using live555), I
would already have written a proprietary implementation of such a schema.
Alas, it is pretty clear at this point that most people in IETF disagree with
me on this one design choice. And I am very much afraid that this will become
yet another huge IOP bottleneck for RTSP.
> It's certainly true, though, that for many applications, HTTP is sufficient
> (as sites like YouTube have demonstrated).
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 197 bytes
Desc: This is a digitally signed message part.
-------------- next part --------------
vlc-devel mailing list
To unsubscribe or modify your subscription options:
More information about the vlc-devel