The influence of local buffer (network cashing parameter>

As explained in hd_streaming the fluent reproduction and proxying through apache had not been a simple stuff.

After finding the cashing parameter of Apache was not finished, because while in presence of a sufficient downlink connection, VLC client was able of a fluent reproduction of the high bitrate streams, the same streams was still not reproduced correctly when framed in a web page.
This was non explained by the scattered documentation of VLC, nor of its plug-in, which lack of documentation is heavier.
Oh, boys, it's an open source product which development require a lot of efforts from the Videolan project people... but something better would appreciated, I think.

Using the same approach I've adopted to solve what I called the Apache bandwidth bottleneck, I've changed the cache parameters of the plug-in, and really it seems go better.
Because the high bandwidth stream are reproduced correctly by the VLC client, it means the streams are transmitted correctly (if the bandwidth of your downlink connection is sufficient (30% more than the stream bandwidth).
On the contrary the same streams are not reproduced fluently when recalled by the active-x (under Internet Explorer) or by the VLC plug-in for Netscape derivated browsers (installed with VLC). Please test the possible enhancement opening (in sequence) the different pages of the following table where you can recall the same stream with 300 (normal) mSec network cache, with 1000 (high), or 3000 (higher) and last 5000 mSec of cache.

source stream cache in milliseconds
300 mSec 1000 mSec 3000 mSec 5000 mSec
h264 720p 2.7 Mbps home_720p_300.html home_720p_1000.html home_720p_3000.html home_720p_5000.html
h264 1080p 3.2 Mbps home_1080p_300.html home_1080p_1000.html home_1080p_3000.html home_1080p_5000.html
mpeg2 1080p 4.3 Mbps mpg2_4.3_300.html mpg2_4.3_1000.html mpg2_4.3_3000.html mpg2_4.3_5000.html
mpeg2 1080p 6.4 Mbps mpg2_6.4_300.html mpg2_6.4_1000.html mpg2_6.4_3000.html mpg2_6.4_5000.html

Try to understand what cache is better for your connection. Consider that VLC client by defaut uses 1000 milliseconds (1 Second).
It is also evident that the greater the network cache longer will be the time before the beginning of the reproduction.
If you do not find appreciable changes, consider also that the downlink bandwidth must be at least 30% more than the nominal stream bandwidth (8 Mbps should be enough for all).

Due to the difference of the call between Explorer and Netscape derivated browser it is mandatory to duplicate the parameters in the object section as well in the embed section.
The VLC active-x plug-in lacks of documentation, but it seems that the change of the network-caching parameter affect (in better) the reproduction.
On the web I found an initiative of a FireBreath VLC plug-in client (Firebreath is a plug-in architecture for Internet Explorer active-x as well NPAPI - Netscape Plugin Application Programming Interfacefor for Netscape derivated browsers) where there is written something more.
But be careful: I'm using the original VLC active-x and the embed call, which parameters could not be the same.