[vlc] Re: Timeout in live.com

[Peter Maersk-Moller]

Hi Derk-Jan

Derk-Jan Hartman wrote:
> 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).

Hmm, never heard that. All my streams starts within a few hundred ms.

However, come to think of it, you may be right. DSS has a config value
where you set how much DSS should cache of a live source before it starts
relaying. That only applies to the first request of each live source. The
next request (of the same source) is started right away. The default
cache value is probably 10 secs. I set it to 1 since I relay live TV
channels. The DSS config value is reflector_buffer_size_sec.
Caching 10 secs on DSS of a live stream before relaying is very unnecessary
unless you really have no quality control over the source what so ever.

BTW, one can set DSS reflector_buffer_size_sec to 11 secs in which case
VLC then wont work then.

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

Ross, got an opinion here ?

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

What would be really nice would be if one could control UDP or TCP

    a) via javascript to the plugin
    b) some option in the playlist
    c) url (somehow)

As a content provider, being able to suggest on the fly to people which
method to use (though javascript for the plugin and option in a playlist
for the standalone) would really help me help the not so able users
to get a better streaming experience.

Relying on the UDP to TCP switchover is not very good, when an embedded
player is loaded, then playing, then relaesed and then reloaded with a new
movie if the (embedded) player has to timeout on UDP every time.

For me, channel surfing then takes a long time.

Ok, avoiding loading, unloading, reloading helps, but sometimes thats
just necessary and wating 10 secs seems a bit execessive.

So controlling both timeout and method (udp/tcp) via javascript and playlist
optiosn would be useful.

Kind regards

Peter Maersk-Moller
-- 
+----------------------------------------------------------+
| Kabel-TV over Internettet   --   http://www.streamtv.dk/ |
+----------------------------------------------------------+

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