640x360 progressive hevc stream

The stream embedded below is compressed in HEVC (High Efficiency Video Compression), known also as h265.
In order to be more decodable by the greater part of computers, it is only 640x360 pixel (one quarter of the original size).
The video is encoded at 300 Kbps plus 192Kbps of mp3 stereo audio all wrapped in a DVB transport stream
Click here to see the original 720p. Click here to know something more about the unicast streaming I'm using.

Beware, on mobile phones
the embed area is empty
because no VLC plug-in
is availabile.
On smartphone you must recall
directly the source stream

To be viewed is required the VLC 2.2.0 active-x browser plug-in, freely downloadable 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.

It has been encoded using VLC 2.2.0 that apply x265 APIs from the FFmpeg initiative.

I got this video produced by Sony and shooted with a PXW-X70 camera.

H265 means progressive HD at less than 3 Mbps. It introduces a lot of news. It supersede the concepts of GoP and macroblocks dividing the frame in slices and/or tiles (rectangular) with Coding Tree Unit (CTU) divided in Coding Units (CU) after the motion estimation, each one with its own history and evolution. 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 read something about how h265 works you you can download from Vcodex website the article An introduction to High Efficiency Video Coding or its full version (this download requires the registration). Finally you can download the official 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.

The performance of my laptop deconding the stream embedded in this page are quite acceptable (45%).

This page has been set up because my dual core x86 laptop (as all its class x86 processor), quietly able to decode progressive HD in h264, exhibit its inadequacy to decode 720p hevc. If the browser must share the power with olter tasks, the entire computational power can be easily be unsufficient.
The decompression of hevc can easily be out of the capability of former generation processors: for this reason this page include a smaller version of the video (640px360).
Nevertheless, if you enlarge full screen the received video (probably at least doubling its size) you can feel the quality of this compression scheme

But also the constance of network features can be unsufficient: a greater compression means an higher reduction of the redundance so a heavily squeezed stream could not be suitable for noisy connection excluding the usage of a wrapper with an efficient error correcting code (that vanishes the compression savings). 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_300.

mediainfo analysis


ID : 19980 (0x4E0C)
Complete name : F:\video\420 to 422\x70_hevc_640p_300.ts
Format : MPEG-TS
File size : 34.1 MiB
Duration : 8mn 23s
Overall bit rate mode : Variable
Overall bit rate : 567 Kbps


ID : 69 (0x45)
Menu ID : 1 (0x1)
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main@L2.1
Codec ID : 36
Duration : 8mn 23s
Bit rate : 345 Kbps
Width : 640 pixels
Height : 360 pixels
Display aspect ratio : 16:9
Frame rate : 23.976 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Bits/(Pixel*Frame) : 0.063
Stream size : 20.7 MiB (61%)
Writing library : x265 1.3:[Windows][GCC 4.9.1][32 bit]
Encoding settings : no-wpp / ctu=16 / tu-intra-depth=1 / tu-inter-depth=1 / me=1 / subme=2 / merange=57 / no-rect / no-amp / max-merge=2 / no-early-skip / no-fast-cbf / rdpenalty=0 / no-tskip / no-tskip-fast / strong-intra-smoothing / no-lossless / no-cu-lossless / no-constrained-intra / no-fast-intra / open-gop / interlace=0 / keyint=250 / min-keyint=23 / scenecut=40 / rc-lookahead=20 / bframes=4 / bframe-bias=0 / b-adapt=2 / ref=3 / weightp / no-weightb / aq-mode=2 / aq-strength=1.00 / cbqpoffs=0 / crqpoffs=0 / rd=3 / psy-rd=0.00 / psy-rdoq=0.00 / signhide / lft / sao / sao-lcu-bounds=0 / sao-lcu-opt=1 / b-pyramid / cutree / rc=abr / bitrate=300 / ratetol=1.0 / qcomp=0.60 / qpmin=0 / qpmax=51 / qpstep=4 / ipratio=1.40 / pbratio=1.30


ID : 68 (0x44)
Menu ID : 1 (0x1)
Format : MPEG Audio
Format version : Version 1
Format profile : Layer 3
Mode : Joint stereo
Mode extension : MS Stereo
Codec ID : 3
Duration : 8mn 24s
Bit rate mode : Constant
Bit rate : 192 Kbps
Channel(s) : 2 channels
Sampling rate : 48.0 KHz
Compression mode : Lossy
Delay relative to video : -186ms
Stream size : 11.5 MiB (34%)
Writing library : LAME3.99.5