The VideoLAN Forums

I recall coming across past postings regarding there being a hard coded HTTP delay bulit into VLC - I can't seem to find a post referencing this again though. If this is indeed the case, which file is it in, and is there a good reason for it existing?

Much thanks,

Scott

Well, VLC caches data before displaying / sending them. The default caching time when using the http-input is 1200 ms, which is a good compromise between delay and stutter-free playback/streaming.
The http-output doesn't have any caching times, while the UDP-one does 300 ms of caching by default.

I've turned down all available settings, with the http cache set down to 100ms (this is as low as I can go before it stutters). Still, there's a good 1-2 seconds that just isn't there if I keep it all in UDP land.

Would using VLS make a difference?

I don't think so. VLS should do the same and I'm not really sure whether it supports HTTP-streaming at all.
As you probably know HTTP is based upon TCP which is by definition slower than UDP. You might want to try out streaming with RTP which is based upon UDP while keeping advanced features such as packet-reordering etc. pp.
RTP does exist both in a uni- and a multicast variant.

HTTP gets me behind routers and such - I haven't seen that RTP can do this, am I mistaken? I'll look into it some more. Any other thoughts on getting behind routers?

-Scott

I suppose, more accurately, http streams make it through a NAT, as I understand it, while RTP streams don't. Any faster way to do make this fly?