Hard-Coded HTTP Delay

[Scott JHU-ECE]

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

[fkuehne]

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.

[Scott JHU ECE]

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?

[fkuehne]

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.

[Scott JHU ECE]

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

[Scott JHU ECE]

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?