[vlc-devel] will streaming protocols survive OR will http become the protocol of choice?!

[Rémi Denis-Courmont]

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" 
protocol.

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 
parameters.

> (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 
for :(

> 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 
(http://nice.freedesktop.org/).

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). 

-- 
Rémi Denis-Courmont
http://www.remlab.net/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20080204/f5f80a87/attachment.sig>
-------------- next part --------------
_______________________________________________
vlc-devel mailing list
To unsubscribe or modify your subscription options:
http://mailman.videolan.org/listinfo/vlc-devel