[vlc] Re: Timeout in live.com

[Derk-Jan Hartman]

On 28 jun 2005, at 23:09, Peter Maersk-Moller wrote:
> Hi.
>
> Jonas Larsen wrote:
>> livedotcom warning: no data received in 900ms. Switching to TCP
>> Can i control this timeout value somewhere in vlc?
>
> One can always recompile ;-)
>
> Anyway (to Ross F.) minimizing this delay is important to improve the 
> experienced
> feeling of quality. I personally don't particular like the long 
> switching time
> in the Quicktime player. To speed things up (and automating it), two 
> strategies
> can be suggested
>
>   a) Measure the the time it takes to establish the RTSP TCP-connection
>      either by setting it up and tear it down with socket option 
> SO_LINGER
>      or by issuing a 'RTSP OPTIONS' command and measure the delay in 
> the
>      answer. The first might be more reliable, the latter might be more
>      inaccurate, since it might require a swapped out server to wake 
> up. On
>      the other hand, you get an indication of how long it takes before 
> a PLAY
>      should result in a stream - unless the server was swapped out. 
> Alternatively,
>      try a ping and measure the RTT - though a ping might be blocked.
>
>   b) Cache information about using UDP or TCP linked to the server IP. 
> Cache
>      info should be grouped according to client network numbers (IP 
> plus netmask)
>      and used within that network. Cache info should time out within a
>      day/week/moth/year depending on choice. RFC1918 client address 
> needs to
>      time out before next reboot (or network down in rare cases).
>      Regardsless of cache value, it should still switch from UDP to TCP
>      if a stream was not present within a timeout value.
>
> That said, though I prefer UDP for aestetic reasons, living with 
> Internet
> designed by Bell-heads rather netneards and implemented with DSLAM/ATM
> with practical no buffer ram and a rather fasistic dropping policy,
> UDP streaming is a pain if you take it near the BW limit, and using
> TCP by default often helps.

TCP sucks for streaming :D As does buffering btw.
Still they are necessary evils in the world in which some people 
thought that TCP was "IT", and UDP actually didn't have a reason to 
exist (the Fools).

The order for RTSP protocol usage is:

1: RTP over UDP
Unreliable network connection method. If you DO get data you usually 
get it almost immediately. That's why we used to have the 900ms 
timeout. However apparently MPEG4 streams can take up to 10 secs before 
they start sending data. (That's why QT uses that value as well).

2: RTP over TCP
The connection is opened immediately. Failure can quickly be detected. 
However atm liveMedia doesn't have a clean method for exporting this 
failure to VLC. We therefore use a timeout again. again 10secs is 
required because of MPEG4 streams.

There is definitely room for improvement here. However in an 
auto-detection setup, there isn't much you can do about the 10sec UDP 
timeout. I'm not for caches. They have a habit of breaking and 
obscuring the proces. complicate problem tracking
as well. We could have a setting to always do 2, but it cannot be 
default of course, and most ppl will then never find it anyways. Still 
I prefer that over a cache.



DJ
---
Universiteit Twente
Derk-Jan Hartman (d.hartman at student.utwente dot nl)
http://www.sidequest.org

-- 
This is the vlc mailing-list, see http://www.videolan.org/vlc/
To unsubscribe, please read http://www.videolan.org/support/lists.html