To be viewed is required videolan VLC 2.2.0 active-x plug-in, downloadable free from www.videolan.org.
By default the active-x plug-in is installed. but beware: the former release (2.1.5) did not support h265, so after the upgrade is better to reboot the browser.
Nothing is free
The way in which this server transmits the stream is really live, without any possibility of local cashing, thus enhancing the drawbacks of any delivery inconvenience.
As known, the reduction of the information entropy to squeeze the bitrate, makes the stream highly sensible to the unavailability even of small but significant portions of information.
This may affect the quality of experience.
In the case of the above stream the constant bitrate must be in the range of about 1.5 Mbps.
In h265 to reach level of compression higher than h264, the concept of Group of Picture (GoP) almost disappears replaced by the Coding Unit (see below).
This extension of the single Coding Unit make the stream extremely sensible to any small lack. In this case, if the available bandwidth is lower than 1.8 Mbps there is the risk to get images like these below
To avoid this side effect you need to add or enforce the Forward Error Correction (FEC) to the Transport Stream as done in broadcast transmissions (such as DVB), thus partly vanishing the further compression obtained.
Another strategy is that of distributing the spikes of bandwidth excess requirements on the entire stream. But increase the latency and make this approach not suitable for live events.
The advantage of transferring slices of the file to the client, that avoid such kind of problems in h264, in h265 becomes more dangerous: the potential lack of reference frame for a longer time than h264 makes more critical the splitting of the movie as done in DASH or HLS delivery.
Squeeze, squeeze always squeeze more
H265 means progressive HD at less than 3 Mbps. It introduces a lot of news.
It supersede the concept of GoP and macroblock dividing the frame in slices and/or tiles (rectangular) with Coding Tree Unit (CTU) divided in Coding Units (CU) after the motion estimation.
The Coding Unit (now up to 64 pixel) which is the replacement of macroblock but in h265 any CU has its own evolution and story, while until h264 it used to work at frame level.
CTUs are grouped in Slices (any number of CTUs) and/or Tiles (rectangular) depending on their temporal and spatial evolution.
To understand something about how h265 works you can get something more readable from Vcodex articles An introduction to High Efficiency Video Coding
or its full version (that require a login). Finally you can download the officila ITU/IEC 23008-2 standard in pdf free from ITU (quite tricky but complete).
If you're going to evaluate the hevc quality, you must remember that it is much more complex to decode than h264.
Hevc is only progressive (but we were already accustomed to deal with progressive videos on the web): the problem is related to the decompression algorithm that is about thrice complex than h264.
This is the load of the decompression of 720p stretched to full screen on my laptop: about the 80%.
My dual core laptop, quietly able to decode progressive HD in h264, exhibit its inadequacy to decode 720p hevc. If the browser is not the only window open, the entire computational power can be easily drained.
Click here if the reproduction is jerky (processor power or network conditions.
But also the constance of network features can be unsufficient. In this case it to save computational power is useless to reduce the video presentation windows size, because before zooming out, any frame must be correctly decompressed.
In hevc any small part of the image has its own story: any slice (group of macroblocs, which in hevc are no more square) has its story and evolution. The GoP almost disappears.
It means that if the decoding cannot carried out within the presentation timestamp, very often the damages strikes much longer than h264.
As expected the compression is extremely computing intensive: on my core2due 2 GHz the compression of its 8 minutes takes about 3 hours.
The wrapper is DVB transport stream, but because in h265 the concept of GoP is quite far, in case of lost of information gray portions of image strike the video for few seconds.
The source stream can be recalled directly as proxed by apache as http://iginomanfre.it/x70_hevc_1200.
