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

[Marc E. Fiuczynski]

Rémi Denis-Courmont wrote:
>> 1) easily save streams to disk using various media players,
>>     
>
> RTSP is not "easy" to save, but it is doable, and would become easier if there 
> was more demand.
>   

I've heard rumors that the latest release of Real Player lets one do 
this.  Have not validated this myself
>> 2) trick play is now supported either through the use of HTTP range
>> queries or on the server side via a CGI (see youtube), and
>>     
>
> Assuming you know where to seek. Yes.
>   

Well, I've used VLC via a http server to seek forward and backwards in a 
HD mpeg file.  Seems to work well enough for me.  It might not be 
perfectly accurate, but I doubt that the average user actually cares 
about that.
>> 3) http servers designed for delivering multimedia "just in time"
>> (versus ASAP bulk downloads) in ways that mirrors what streaming
>> protocols (again a simple experiment with youtube reveals that they pace
>> the outgoing data delivery).
>>     
>
> Even if the server does not pace, the client could do it at TCP level. This is 
> not really an issue. The only use is to rate limit clients.
>   

Agreed. The complaint is that clients in the past did not did not limit 
themselves and so this functionality needed to put into the servers.  
Consider youtube, dailymotion, etc., where someone has to pay for the 
bandwidth by the GB sent.  It is wasted money if the user wont watch the 
whole video, which is quite common for those types of websites.

> Probably the main reason why RTSP mostly failed so far is that it is so 
> unfriendly to NATs and firewalls. Hence people come with non-compatible 
> solutions, and there is no big incentive to interop.

Agreed.

> Also companies want to sell and buy proprietary solutions for media...
>   

Not sure I follow this statement.
> For video-on-demand, where you may actually want to have big receive buffers 
> and reliable reception, it is actually better to use HTTP than RTSP. And then 
> you get firewall and NAT traversal as an added bonus. So yeah, I don't see 
> much point in using more dedicated protocols, such as RTSP there.
>   

Glad to hear it.  Now if we could just educate the rest of the world. :)

> As far as I can tell, the one and only real advantage of UDP (beyond 
> multicasting) is low latency. But you typically don't care so much about 
> latency when streaming, as you would when conferencing.
>   

Agreed.

> You can argue whether TCP (HTTP) is good or bad for live streaming (not VoD) 
> then, but obviously VoD is much more common an usage.
>   

I think live streaming can also be done fairly effectively using HTTP.  
The real challenge in this space is more with scaling to many users.  
RTP multicast is the real solution for this, but it turns out to be 
impractical as it often simply does not work across ISPs or even within 
an ISP.

Thanks for your comments.

Marc