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

[Viral Sachde]

Marc E. Fiuczynski wrote:
> 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
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> http://mailman.videolan.org/listinfo/vlc-devel
>
>   
I think P2P streaming will provide much better long term solution.
It can dynamically scale it self. Also if DRM gets involved, it can be 
commercialized.

I think *Multicast will require people to watch movie same time and than 
what about seeking functionality * (Can someone please correct this 
statement if it is wrong, I am not sure.)

Regards,

Viral