This website uses many stream supplied by the server itself. Many of these streams are in HD at high bitrate. See this page for a complete (and hopefully updated) list
To stream HD is required HD material. The first HD material I used are 282 seconds of the movie Home realised by Yann Arthus Bertrand in 2009, copyright Europa Corp, publicly viewable on many web sites. I've added a specific page with all the disclaimer, additional informations and all the related links.
The first HD stream I erogated were these ones:
1080p h264 VBR with a peak of 3.2 Mbps(about 111 MB). Stream http://126.96.36.199/home_1080p
720p h264 VBR with a peak of 2.7 Mbps (about 99 MB). Stream http://188.8.131.52/home_720p
1080p mpeg2 VBR with a peak of 4.3 Mbps (about 143 MB). Stream http://184.108.40.206/mpg2_4.3
1080p mpeg2 VBR with a peak of 6.4 Mbps (about 211 MB). Stream http://220.127.116.11/mpg2_6.4
other stream The streams (as all the streams used here) use different versions pre-encoded files of the same sample 282 seconds long. The first couple (one 1080p and the other 720p) have been compressed in h264 with mpeg1 layer3 (mp3) audio (in italian) through x264 (open source h264) in two steps., the second couple, added on September 9th, are both mpeg2 HD 1080p streams with mp3 audio encoded at two different bitrates.
The scope of these last files is to make some test of different behaviour of mpeg2 and h264 TS when stream.
Http is all but the ideal protocol to stream, but it passes all firewall and it is based on tcp/ip.
At infinite time the stream should be delivered (almost) perfect, potentially as it is.
The problem arise from the uneven flow of information, not correctly delivered to the player in time to be decoded and presented at the right time.
This can be metered by Media Delivery Index, introduced in 2006 with RFC 4445 by Welch (Ineoquest) and Clark (Cisco).
It is explained in the Wikipedia's lemma but perfectly shown by the following graphic taken from Ineoquest's document
Media Delivery Index Application Note
The image refers to a UDP stream, but it can be extended to any ordinary live stream, including mine.
It clearly represents why a player may be unable to show correctly a flow of 3,75 Mbps despite it get all the required bits: all but not at the right time
Using VLC you can capture the stream creating a file with the following command line
"[vlc path]\vlc" http://18.104.22.168/mpg2_6.4 :http-caching=1200 :demux=dump :demuxdump-file="c:\stream.ts"
The default VLC path is c:\program files\videolan\vlc (in any case you can find the path from the icon properties).
Beware: the stream is live: it never starts and never ends, so -- even in case of narrowband stream as in the image below -- if you forget it can become a big file.
I'm a newby of Apache but I was quite sure that there were a problem of Apache configuration, because it is the only block between the network and VLC.
I searched the web and also on the rich Apache documentation.
Well: it seems to work! It streams correctly even with 6.4 Mbps video, at least as the native VLC generated streams.
A big step for me, nothing for mankind
No, it is not finished, because while in presence of a sufficient downlink connection, VLC client is now able to reproduce fluently the high bitrate streams, the same streams are still not reproduced correctly when framed in a web page
using the VLC plug-in, that lacks of documentation.
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.