This is a blog on video compression

It's written - depending by my willing - often in Italian only, sometimes in English only (in my English), sometimes in both languages.

    

Questo e' un blog sulla compressione

E' scritto come me la sento, spesso solo in italiano, a volte solo in inglese (nel mio inglese), a volte in entrambe le lingue.



i trucchi dell'LCEVC (mpeg5 parte 2)

L'MPEG5 (ISO 23094) diviso in due parti introduce due filoni: individuazione degli agenti ostativi alla diffusione di algoritmi di compressione standard (quindi - in pratica - ricerca della possibilita' di trovare algoritmi senza royalty come x264 e x265) e la Compressione Video di Base a Bassa Complessita (Low Complexity Essential Video Coding, LCEVC). A seguito dell'incontro sulle nuove tecnologie tenuto on line dalla sezione Italiana del'SMPTE (interamente disponibile su Youtube, la conferenza vera e propria comincia dopo circa 5 minuti), mi viene voglia di dire la mia .

Un po' di storia

Mi occupo di compressione video dal 1987: a quel tempo collaboravo in quota Stet in una joint venture Microsoft-Stet (Eikon).

Quell'anno Intel rilascio' il DVI, acronimo per Digital Video Interactive (da non confondere con la interfaccia fisica Digital Visual Interface dallo stesso acronimo che sarebbe venuta fuori oltre 10 anni dopo e che ora e' stata pressoche' eliminata dall'HDMI), una compressione che adesso si definirebbe a dir poco rozza, che su un intel 386 con windows aveva bisogno di tre doughtercard computazionali per effettuare la compressione in tempo reale. Malgrado i roboanti annunci di Intel, cio' che si otteneva era poco piu' di una curiosita'.
La qualita' a 1.2 Mbps era piuttosto scarsa (15 fotogrammi al secondo), la risoluzione, sebbene nominalmente full D1 (720x576) era praticamente limitata dalla instabilita' termica del sistema (le tre schede erano un vero ferro da stiro), ma anche se il sistema Intel DVI costava circa 20000 dollari (un'ira d'iddio per il tempo, ma visti gli azionisti, spesso non c'erano problemi di soldi) il risultato oggi sarebbe stato giudicato assolutamente insufficiente.
Ma era un primo passo, denotava la voglia di occuparsi della compressione video che avrebbe portato in breve allo standard Mpeg1 (Eikon collaborava con lo Cselt di Chiariglione, il papa' dell'MPEG).
Lo stesso h261 - che non era ancora standardizzato - non era gran che, l'MPEG non c'era e ancora per un paio d'anni non ci sarebbe stato.
Solo due anni dopo sarebbe stata rilasciata una scheda con due Risc-array processor per la compressione in motion-jpeg e in mpeg1.

Il sistema DVI dell'Intel a 1 Mbps riusciva a realizzare un 360x240 fluido. Vedi comunque l'articolo citato.
Seppure pensato per la distribuzione video su CD (bitrate 1.2 Mbps) era sicuramente inadatto alla distribuzione di massa, anche perche' nel 1989 i CD 4x (in grado di leggere circa 5 Mbps) erano un'altra curiosita' da patiti della tecnologia.

E' tipico di chi si e' trovato a lavorare negli sviluppi della tecnologia dalla fine degli anni 80 ripensare a cio' che al tempo sembrava all'avanguardia ed ora non sarebbe nemmeno degno di un portachiavi.
Ricordo verso la fine degli anni '70 con quale emozione il professore di elettronica ci porto' a vedere uno dei primi display LCD prodotti nel suo laboratorio: circa un pollice di diagonale, scarso contrasto (si sarebbero detti grigio e grigio scuro), inadatto quindi anche agli orologi che sarebbero usciti di li a qualche anno.
Ed ora abbiamo gli OLED HDR 8k!

Le modalita' di realizzazione erano a dir poco artigianali: si utilizzava una scheda in grado di acquisire il full-D1 (prodotta dalla inglese videologic, inventrice - tra l'altro - della VGA, Video Graphical Array, il cui connettore a 15 poli e oggi sinonimo di video analogico per computer) e la compressione software impiegava fino a 24 ore per 8 minuti.


Il video originale di questo piccolo segmento era compresso in IV32
(derivato dal DVI nei primi anni '90) ed era un flusso a 1.2 Mbps
link al file originale Multimedia 2 Go people (19950222).avi


formato avi 1995


formato .mp4 basso bitrate

Generale
Nome completo
Formato
Formato/Informazioni
Impostazioni formato
Dimensione
Durata
Bitrate totale
Creato con


Multimedia 2 Go people (19950222).avi
AVI
Audio Video Interleave
rec
19,1MiB
2 min 7s
1.257 kb/s


Multimedia 2 Go people (19950222)_a.mp4
MPEG-4
Base Media
isom (isom/iso2/avc1/mp41)
3,16MiB
2 min 7s
208 kb/s
Lavf56.25.101

Video
ID
Formato
ID codec
ID codec/Informazioni
Impostazioni formato
Impostazioni formato, CABAC
Impostazioni formato, RefFrames
ID codec
ID codec/Informazioni
Durata
Bitrate
Larghezza
Altezza
Rapporto aspetto visualizzazione
Frame rate
Bit/(pixel*frame)
Frame rate
Frame rate minimo
Frame rate massimo
Frame rate originale
Spazio colore
Croma subsampling
ProfonditÓ bit
Tipo scansione
Dimensione della traccia
Compressore
Impostazioni compressione












Codec configuration box


0
Indeo 3
IV32
Intel Indeo Video 3.2





2 min 7s
1.100 kb/s
320 pixel
240 pixel
4:3
25,000 FPS
0.573





4:1:0


16,8MiB (88%)














-


1
AVC
Advanced Video Codec
High@L1.3
CABAC / 4 Ref Frames
Si
4 frame
avc1
Advanced Video Coding
2 min 7s
150 kb/s
320 pixel
240 pixel
4:3
Variabile
0.081
24,247 FPS
6,250 FPS
25,000 FPS
25,000 FPS
YUV
4:2:0
8 bit
Progressivo
2,22MiB (70%)
x264 core 146 r2538 121396c
cabac=1 / ref=3 / deblock=1:0:0 / analyse=0x3:0x133 /
me=hex / subme=7 / psy=1 / psy_rd=1.00:0.00 /
mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 /
8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 /
chroma_qp_offset=-2 / threads=3 / lookahead_threads=1 /
sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 /
bluray_compat=0 / constrained_intra=0 / bframes=3 /
b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 /
weightb=1 / open_gop=0 / weightp=2 / keyint=250 /
keyint_min=25 / scenecut=40 / intra_refresh=0 /
rc_lookahead=40 / rc=2pass / mbtree=1 / bitrate=150 /
ratetol=1.0 / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 /
cplxblur=20.0 / qblur=0.5 / ip_ratio=1.40 / aq=1:1.00
avcC

Audio
ID
Formato
Impostazioni formato
Profilo formato
ID codec
Durata
ModalitÓ bitrate
Bitrate
Canali
Frequenza campionamento
ProfonditÓ bit
Dimensione della traccia
Allineamento
Durata intervallo
Intervallo pre caricamento
Modo compressione
Default
Alternate group


1
PCM
Unsigned

1
2 min 7s
Costante
88,2 kb/s
1 canale
11,025 kHz
8 bit
1,34MiB (7%)
Audio allineato
40 ms (1,00 frame)
760 ms


-


2
MPEG Audio
Version 1
Layer 3
mp4a-6B
2 min 7s
Costante
56,0 kb/s
1 canale
48,0 kHz

72 KiB (27%)



Con perdita
Si
1

l'inizio della compressione video industriale

Nel 1995 entrai in Stream dove divenni responsabile del laboratorio MPEG del Digital Production Studio.

Stream - lo stesso nome era un avventura - era una iniziativa mirabolante di Miro Allione, precedente amministratore delegato di Stet (nominato da Prodi).
Lo stesso nome della societa' (ora un normale concetto, 25 anni fa un sogno) era futuribile, il logo erano le due mani di Dio e Adamo dal giudizio universale di Michelangelo.

Miro Allione incastro' la Bell Atlantic (oramai solo uno dei telecom operator di New York, dopo lo spezzatino imposto da Reagan) e fregandola sul tempo le impose - contrattualmente - di attivare il sistema VideoMagic (clone del sistema Stargazer progettato dalla stessa Bell Atlantic), primo Video Over Dialtone del mondo, prima che negli USA stessi: insomma VideoMagic fu il primo sistema di Video On Demand (VoD) digitale del mondo, la prima applicazione commerciale (commercialmente molte attivita' di Stream furono fallimentari) di Video Over Dialtone.

Video Over Dialtone (era anche il titolo del libro di Daniel Minoli pubblicato da McGraw-Hill nel 1995 con questo nome), perche' per la prima volta si usavano dei doppini telefonici per la distribuzione mediante ADSL di larga banda (al tempo 1.5 Mbps), circa 500 volte in piu' della banda nominale del doppino di 3 KHz che mi avevano fatto studiare a scuola
Tra l'altro la rete SIP (che poi divenne Telecom Italia) con una distribuzione capillare sul territorio - specie in citta' - possedeva una rete particolarmente adatta all'ADSL per la capillare diffusione di nodi di rete a su tutto il territorio nazionale.
Stargazer-Videomagic prevedeva la trasmissione di video compresso in MPEG a circa 1.5 Mbps di banda. Il formato di test fu il CIF, poi al momento del lancio si uso' l'halfD1, 720x288.
I contenuti erano wrappati in transport stream mpeg2 (esattamente come il contemporaneo DVB), ma non c'era gran che a parte un elementary stream video a 1200 Mbps ed un elementary stream audio mpeg1 layer2 a 192 Kbps (sembra una cosa fossile ed incredibile, ma il layer3 era considerato ancora troppo complesso).

Quando ho cominciato ad occuparmi in modo industriale di compressione video MPEG (a quel tempo 1&2) il problema era riuscire a fare la DCT (Trasformata Discreto-Coseno) molto velocemente, almeno quanto bastava a trattare tutti i macroblocchi nei quali i singoli field erano suddivisi (circa 160000 al secondo in PAL, che - con la DCT inversa - corrisponde a doverne calcolare circa 600 mila al secondo).
Per questo si potevano sfruttare dei mainframe/mini (come voleva fare l'IBM e la Digital) oppure dei RISC array processor: circuiti integrati contenenti matrici di calcolatori molto semplici (circuiti integrati RISC a set di istruzioni ridotto, appunto) prodotti dalla C-cube.
Per comprimere l'MPEG in tempo reale ne servivano almeno 2 per processare il formato CIF (360x288, 1/4 del PAL), ma poiche' questa scheda ospitava 4 RISC array, il sistema base era in grado di comprimere qualcosa in piu' del CIF: nacque il formato HalfD1 che comprimeva in pratica solo solo meta' delle righe (un field invece di un frame) per un formato di 720x288 (essendo il D1 era il formato video 720x576), realizzato ignorando uno dei due field di ogni frame.
Pare impossibile ma nel 1995 era questo lo stato della tecnologia video.

I compressori video realtime (al tempo Tandberg, NTL, Scientific Atlanta) utilizzavano delle FPGA di ultima generazione (il massimo della potenza computazionale del tempo), che non avevano applicazioni per scrivere dei file (producevano stream ed avevano dei prezzi esorbitanti).
A quel tempo i processori (486 o pentium che fossero) erano delle autentiche carriole se li rapportiamo a quelli di oggi.
Di piu' si poteva fare, ma solo partendo da un file che poneva il non indifferente problema di acquisire video non compresso, oltre 20 MB al secondo, per un paio di ore oltre 14 GB (a quel tempo i piu' grossi hard disk erano da 2 GB).
In seguito (parliamo del 1997) usci' una seconda card con 10 RISC array processor che riusciva a comprimere tutto il formato PAL (720x576) in tempo reale.
C'era il sistema di compressione Minerva (di Mauro Bonomi) che prevedeva una compressione in due fasi - simile a quello che e' fatto oggi in modo automatico - ma con un possibile intervento umano per specificare passaggi complessi.
Minerva risolveva brillantemente la acquisizione del non compresso con un sistema di acquisizione di dimensioni adatte, ma era l'intervento umano che non mi convinceva.
Comunque neanche i trucchi di marketing riescono a fare la compressione in due fasi in tempo reale, ma con il processamento automatico in due fasi da file la faccenda e' diversa.

Si, va bene, ma oggi?

Oggi, dopo l'orgia di potenza di calcolo che vede l'HEVC (h265, bada bene, sempre standard definition) essere 10000 volte piu' oneroso in termini computazionali rispetto all'MPEG2 o il VVC (o il suo partner non standard AV1) essere cosi' complesso da rispetto all'MPEG2 da porsi il problema con che macchina lo facciamo, oggi con LCEVC (Low Complexity Essential Video Coding, MPEG5 parte2) ci si sta preoccupando della utilizzabilita' di algoritmi di compressione video sempre piu' complessi.

Ci si e' resi conto che se si comprime una versione scalata del video (in genere 1/4 ma anche 1/16 in HD), lo si decomprime e riaumenta (x4 o x16) per confrontarlo con il video originale ricavandone le differenze e aggiungendo queste differenze come un elementary stream di metadati al multiplex complessivo, il processo, malgrado l'apparente arzicogolosita', diviene estremamente meno oneroso e - soprattutto - lo disaccoppia dalla complicatezza del processo di compressione base (qualsiasi esso sia h264, h265, av1 o vvc).
Avevo scritto rende indipendente, che sarebbe chiaramente un bel desiderio
.



Se la riduzione viene effettuata in una sola direzione si parla di D1, se in entrambe di D2.
Non voglio farla troppo semplice, ma si tratta di utilizzare degli upconverter ad alta efficienza.
La tecnologia al riguardo ha fatto i salti mortali, basti vedere come un segnale PAL viene portato a riempire uno schermo UHD e tale ingrandimento regge anche agli esami piu' complessi.
Nella mia ignoranza gli l'interpolazione di Lanczos e' tra le migliori.

prova materiale

E' questo che ho fatto per realizzare i seguenti 4 video che seguono in free run.
Purtroppo con l'html base che utilizzo io non e' possibile riallargare il video la cui larghezza o altezza e' stata dimezzata per riportare cosi' il formato "dimezzato" nella dimensione originale.
Quindi - come illustrato nella immagine seguente - puoi richiamare con quattro istanze di VLC i quattro segmenti video (23 secondi ciascuno).
Copiando il relativo link potrai aprirlo entro VLC nel aspect ratio dichiarato (16:9).
pezzetto_3Mbp.mp4 pezzetto_1.4Mbps_D1h.mp4
pezzetto_1.4Mbps_D1v.mp4 pezzetto_600kbps_D2.mp4



originale: pezzetto_3Mbp.mp4

dimezzamento orizzontale: pezzetto_1.4Mbps_D1h_.mp4

dimezzamento verticale: pezzetto_1.4Mbps_D1v.mp4

dimezzamento bidirezionale: pezzetto_600kbps_D2.mp4

L'aspect ratio corrotto di questi video e' a dir poco spiacevole, ma in realta' - come mostra l'immagine precedente - e' solo un problema di presentazione.
In realta' il dimezzamento orizzontale o verticale non e' cosa rara. Tra l'altro si deve considerare che con gli schermi a raggi catodici la risoluzione orizzontale reale era inferiore a quella orizzontale (circa la meta') e' da li' che veniva l'accettazione dell'halfD1

Con l'istruzione video dell'html5 non c'e' modo di cambiare l'aspect ratio o scalare il video e mostrarlo nella dimensione desiderata mentre con l'applicazione VLC (o eventuali invocazioni del suo plug-in quando era possibile) si puo' (vedi immagine sopra ai video).

Analisi con Mediainfo dei pezzetti video utilizzati

Generale
Nome completo
Formato
Profilo formato
ID codec
Dimensione
Durata
Bitrate totale
Creato con


pezzetto_3Mbp.mp4
MPEG-4
Base Media
isom (isom/iso2/avc1/mp41)
8,61MiB
24s 360 ms
2.964 kb/s
Lavf57.71.100


pezzetto_1.4Mbps_D1h_.mp4
MPEG-4
Base Media
isom (isom/iso2/avc1/mp41)
4,02MiB
24s 360 ms
1.384 kb/s
Lavf57.71.100


pezzetto_1.4Mbps_D1v_.mp4
MPEG-4
Base Media
isom (isom/iso2/avc1/mp41)
4,02MiB
24s 360 ms
1.383 kb/s
Lavf57.71.100


pezzetto_300kbps_D2.mp4
MPEG-4
Base Media
isom (isom/iso2/avc1/mp41)
887 KiB
24s 360 ms
298 kb/s
Lavf57.71.100


pezzetto_600kbps_D2.mp4
MPEG-4
Base Media
isom (isom/iso2/avc1/mp41)
1,72MiB
24s 360 ms
594 kb/s
Lavf57.71.100

Video
ID
Formato
Formato/Informazioni
Profilo formato
Impostazioni formato
Impostazioni formato, CABAC
Impostazioni formato, RefFrames
ID codec
ID codec/Informazioni
Durata
Bitrate
Larghezza
Altezza
Rapporto aspetto visualizzazione
Rapporto aspetto originale
ModalitÓ frame rate
Frame rate
Frame rate minimo
Frame rate massimo
Frame rate originale
Spazio colore
Croma subsampling
ProfonditÓ bit
Tipo scansione
Bit/(pixel*frame)
Dimensione della traccia
Compressore
Impostazioni compressione

















































Codec configuration box


1
AVC
Advanced Video Codec
High@L3.1
CABAC / 4 Ref Frames
Si
4 frame
avc1
Advanced Video Coding
24s 360 ms
3.000 kb/s
1.024 pixel
576 pixel
16:9

Variabile
24,754 FPS
8,333 FPS
25,000 FPS
25,000 FPS
YUV
4:2:0
8 bit
Progressivo
0.205
8,60MiB (100%)
x264 core 152 r2854 e9a5903
cabac=1
ref=3
deblock=1:0:0
analyse=0x3:0x133
me=hex
subme=7
psy=1
psy_rd=1.00:0.00
mixed_ref=1
me_range=16
chroma_me=1
trellis=1
8x8dct=1
cqm=0
deadzone=21,11
fast_pskip=1
chroma_qp_offset=-2
threads=3
lookahead_threads=1
sliced_threads=0
nr=0
decimate=1
interlaced=0
bluray_compat=0
constrained_intra=0
bframes=3
b_pyramid=2
b_adapt=1
b_bias=0
direct=1
weightb=1
open_gop=0
weightp=2
keyint=250
keyint_min=25
scenecut=40
intra_refresh=0
rc_lookahead=40
rc=2pass
mbtree=1
bitrate=3000
ratetol=1.0
qcomp=0.60
qpmin=10
qpmax=51
qpstep=4
cplxblur=20.0
qblur=0.5
ip_ratio=1.40
aq=1:1.00
avcC


1
AVC
Advanced Video Codec
High@L3
CABAC / 4 Ref Frames
Si
4 frame
avc1
Advanced Video Coding
24s 360 ms
1.400 kb/s
512 pixel
576 pixel
16:9
0,889
Variabile
24,754 FPS
8,333 FPS
25,000 FPS
25,000 FPS
YUV
4:2:0
8 bit
Progressivo
0.192
4,01MiB (100%)
x264 core 152 r2854 e9a5903
cabac=1
ref=3
deblock=1:0:0
analyse=0x3:0x133
me=hex
subme=7
psy=1
psy_rd=1.00:0.00
mixed_ref=1
me_range=16
chroma_me=1
trellis=1
8x8dct=1
cqm=0
deadzone=21,11
fast_pskip=1
chroma_qp_offset=-2
threads=3
lookahead_threads=1
sliced_threads=0
nr=0
decimate=1
interlaced=0
bluray_compat=0
constrained_intra=0
bframes=3
b_pyramid=2
b_adapt=1
b_bias=0
direct=1
weightb=1
open_gop=0
weightp=2
keyint=250
keyint_min=25
scenecut=40
intra_refresh=0
rc_lookahead=40
rc=2pass
mbtree=1
bitrate=1400
ratetol=1.0
qcomp=0.60
qpmin=10
qpmax=51
qpstep=4
cplxblur=20.0
qblur=0.5
ip_ratio=1.40
aq=1:1.00
avcC


1
AVC
Advanced Video Codec
High@L3
CABAC / 4 Ref Frames
Si
4 frame
avc1
Advanced Video Coding
24s 360 ms
1.400 kb/s
1.024 pixel
288 pixel
16:9
3,556
Variabile
24,754 FPS
8,333 FPS
25,000 FPS
25,000 FPS
YUV
4:2:0
8 bit
Progressivo
0.192
4,01MiB (100%)
x264 core 152 r2854 e9a5903
cabac=1
ref=3
deblock=1:0:0
analyse=0x3:0x133
me=hex
subme=7
psy=1
psy_rd=1.00:0.00
mixed_ref=1
me_range=16
chroma_me=1
trellis=1
8x8dct=1
cqm=0
deadzone=21,11
fast_pskip=1
chroma_qp_offset=-2
threads=3
lookahead_threads=1
sliced_threads=0
nr=0
decimate=1
interlaced=0
bluray_compat=0
constrained_intra=0
bframes=3
b_pyramid=2
b_adapt=1
b_bias=0
direct=1
weightb=1
open_gop=0
weightp=2
keyint=250
keyint_min=25
scenecut=40
intra_refresh=0
rc_lookahead=40
rc=2pass
mbtree=1
bitrate=1400
ratetol=1.0
qcomp=0.60
qpmin=10
qpmax=51
qpstep=4
cplxblur=20.0
qblur=0.5
ip_ratio=1.40
aq=1:1.00
avcC


1
AVC
Advanced Video Codec
High@L2.1
CABAC / 4 Ref Frames
Si
4 frame
avc1
Advanced Video Coding
24s 360 ms
300 kb/s
512 pixel
288 pixel
16:9

Variabile
24,754 FPS
8,333 FPS
25,000 FPS
25,000 FPS
YUV
4:2:0
8 bit
Progressivo
0.082
879 KiB (99%)
x264 core 152 r2854 e9a5903
cabac=1
ref=3
deblock=1:0:0
analyse=0x3:0x133
me=hex
subme=7
psy=1
psy_rd=1.00:0.00
mixed_ref=1
me_range=16
chroma_me=1
trellis=1
8x8dct=1
cqm=0
deadzone=21,11
fast_pskip=1
chroma_qp_offset=-2
threads=3
lookahead_threads=1
sliced_threads=0
nr=0
decimate=1
interlaced=0
bluray_compat=0
constrained_intra=0
bframes=3
b_pyramid=2
b_adapt=1
b_bias=0
direct=1
weightb=1
open_gop=0
weightp=2
keyint=250
keyint_min=25
scenecut=40
intra_refresh=0
rc_lookahead=40
rc=2pass
mbtree=1
bitrate=300
ratetol=1.0
qcomp=0.60
qpmin=10
qpmax=51
qpstep=4
cplxblur=20.0
qblur=0.5
ip_ratio=1.40
aq=1:1.00
avcC


1
AVC
Advanced Video Codec
High@L2.1
CABAC / 4 Ref Frames
Si
4 frame
avc1
Advanced Video Coding
24s 360 ms
600 kb/s
512 pixe
288 pixel
16:9

Variabile
24,754 FPS
8,333 FPS
25,000 FPS
25,000 FPS
YUV
4:2:0
8 bit
Progressivo
0.164
1,72MiB (100%)
x264 core 152 r2854 e9a5903
cabac=1
ref=3
deblock=1:0:0
analyse=0x3:0x133
me=hex
subme=7
psy=1
psy_rd=1.00:0.00
mixed_ref=1
me_range=16
chroma_me=1
trellis=1
8x8dct=1
cqm=0
deadzone=21,11
fast_pskip=1
chroma_qp_offset=-2
threads=3
lookahead_threads=1
sliced_threads=0
nr=0
decimate=1
interlaced=0
bluray_compat=0
constrained_intra=0
bframes=3
b_pyramid=2
b_adapt=1
b_bias=0
direct=1
weightb=1
open_gop=0
weightp=2
keyint=250
keyint_min=25
scenecut=40
intra_refresh=0
rc_lookahead=40
rc=2pass
mbtree=1
bitrate=600
ratetol=1.0
qcomp=0.60
qpmin=10
qpmax=51
qpstep=4
cplxblur=20.0
qblur=0.5
ip_ratio=1.40
aq=1:1.00
avcC

Compressione in due fasi

Si, d'accordo, si sta desiderando di effettuare una compressione video altrimenti complessa in tempo reale, ma per i comuni mortali e' anche importante avere un risultato accettabile (come dicevano gli antichi: accontentiamoci!): piuttosto che raggiungere le vette della qualita' a scapito della potenza di calcolo da impegnare, non e' meglio inventare un workflow che unisca l'utile al dilettevole?.

I due video che seguono sono compressi in h264 con ffmpeg a 600 e 300 Kbps con la compressione in due fasi (non possibile in lavorazioni in tempo reale).
Ho scelto apposta le ecoballe con quella texture terribile quando ruotata e scalata
Gli artefatti ci sono (chi lo vuole negare?), considerato poi che sono la ricompressione di una compressione (originale era un h264 a 3 Mbps), ma a sinistra siamo a 600 Kbps ed a destra alla meta', 300 Kbps: ci si puo' stare?

dimezzamento bidirezionale: pezzetto_600kbps_D2.mp4

dimezzamento bidirezionale: pezzetto_300kbps_D2.mp4



Scalare e ripristinare

Dunque alla base del LCEVC c'e' la scalatura ad 1/4 delle dimensioni originali ed il successivo ripristino alle dimensioni originali di un video.
Mentre con l'applicazione VLC (o eventuali invocazioni del suo plug-in quando era possibile) si puo' cambiare l'aspect ratio scalare il video e mostrarlo nella dimensione desiderata mentre con l'istruzione video non c'e' modo:

height attribute

https://www.w3schools.com/tags/att_video_height.asp

The height attribute specifies the height of a video player, in pixels.

Tip: Always specify both the height and width attributes for videos. If these attributes are set, the required space for the video is reserved when the page is loaded. However, without these attributes, the browser does not know the size of the video, and cannot reserve the appropriate space to it. The effect will be that the page layout will change during loading (while the video loads).

Note: Do not rescale video with the height and width attributes! Downsizing a large video with these attributes forces a user to download the original video (even if it looks small on the page). The correct way to rescale a video is with a program, before using it on a web page.

width attribute

https://www.w3schools.com/tags/att_video_width.asp

The width attribute specifies the width of a video player, in pixels.

Tip: Always specify both the height and width attributes for videos. If these attributes are set, the required space for the video is reserved when the page is loaded. However, without these attributes, the browser does not know the size of the video, and cannot reserve the appropriate space to it. The effect will be that the page layout will change during loading (while the video loads).

Note: Do not rescale video with the height and width attributes! Downsizing a large video with these attributes forces a user to download the original video (even if it looks small on the page). The correct way to rescale a video is with a program, before using it on a web page.




latest added (the UHD landing)

    

ultimi aggiunti (lo sbarco in UHD)

hls5 realtime simulation of audio-video rtp connection via internet at very low cost and retransmission in realtime of its hls version.
Beware! the pc browsers do not play hsl metafile (extension .m3u8) as on smartphones the same browsers do.



I've moved the UHD video to a specific page because to play an UHD video on a PC is about a curiosity, but - computational speaking - an extremely eavy curiosity that can easily overload the system bringing it the to a halt state.

    

hls5 Simulazione in tempo reale di un collegamento rtp audio-video attraverso internet realizzabile a costo irrisorio con sua trasmissione simultanea in tempo reale in hls.
Attenzione! i browser dei PC non riproducono il metafile hls (estensione .m3u8) mentre sugli smartphone gli stessi browser lo fanno.



Ho spostato i video in UHD ad una apposita pagina perche' riprodurre un video UHD su un PC e' poco piu' di una curiosita', ma una curiosita' estremamente onerosa in termini computazionali che puo' sovraccaricare il sistema fino a poterlo bloccare.




400p video compressed in h264 at 300 Kbps
the tiny version of the uhd one (see page uhd
any pc with any operating system is able to decode it.






360p version of the left one compressed in h265 (aka hevc) at 200 Kbps
firefox and chrome do not decode h265 (but they play the mp3 audio),
microsoft edge should (but I do not know how),
apple safari from version 11 should (but I've never seen it)
vewd browser on android-tv does it (it uses the hardware decoding of the tv)
To view it you can use VLC to open the network file
http://iginomanfre.it/video/Yosemite_hevc_SD100.mp4
(even a dual core should be able to decode it. Browsers will play only the audio).


hls metafile with hevc payload 720x400p (Standard Definition, the image is scaled to 640x360)
This metafile and the related chops are permanent
This is a plain link that the browser, being unable to play m3u8 playlists,
requires what it must do: save or open with an external application.
If you associate to m3u8 association an external player such as VLC
a click over the image will open an overlay window that will start
to reproduce the video.

You can make this action permanent and after modify it from firefox. preferences
The hls slicing in small portion will reduce the waiting to few seconds.

<a href="http://iginomanfre.it/hlsB/hlsB.m3u8"> <img border=0 src="../jpg/yosemite_poster.jpg" height="360" width="640"> </a>













<a href="../video/x70_hevc_360p_300.ts"> <img border=0 src="../jpg/vlc opening x70.jpg"> </a>

Transport stream with hevc payload 640x360p (about 2/3 of a Standard Definition video)
Despite of all this streaming noise it is not a streaming because the browsers are unable to play transport stream.
It is a local copy of a local copy of a remote file (iginomanfre.it/video/x70_hevc_360p_300.ts) followed by the launch of a task able to play that file: as you can see the image is a plain link that the browser, if you haven't already associated to .ts extension an external player (I suggest you VLC), the system will require you what to do: save as temporary file and open or open with an external application.
clicking over the image will anyhow download the file (32 MB!) to a temporay file and after having downloaded it will launch the download it will opened in an overlay window that will start to reproduce the video.
The browsers do not this.

If you have'n create the association, you will see a window like this

Through the browser application manager You can make this action permanent.
After the end of the reproduction VLC must be closed by hand.
The file is an ordinary local in the player's playlist, so you can loop stop browse through the timeline.
The file is saved in the browser temporary dir (on mine windows 7 %user%\AppData\LocalLow\Mozilla and will be deleted if you choose to open the file (if you choose to download it, depending of the browser settings, you could be required where to save the file and the file will be permanent.



List of all the streams provided by this server

list updated at january 2021 - mp4 files in /video - mp4 files in /media

Last file added have been many permanent hls stream, permanent because their chops are always presents such as: hls2, hl5, hls8w, hls8z, hlsB, hlsC (180 MB, 4k UHD, h265), hlsD (360 MB, 4K UHD h264), directories where you find the metafiles with extension .m3u8 and the chops (excluding hls2 that is slight different).
You can open them with videolan vlc, e.g., for hls8w.m3u8 ( http://iginomanfre.it/hls8w/hls8w.m3u8 ) as told above clicking over the panel you'll get a similar image asking what you want to to do with these chops: open with the default opener (on my browser the m3u8 extension is associated to vlc) or save it where you like (completely useless)

    

Elenco di tutti gli stream erogati da questo server

lista aggiornata al gennaio 2021 - file mp4 in /video - file mp4 in /media

Gli ultimi file aggiunti sono diversi file (stream) hls permanenti, permanenti perche' le loro porzioni (chops) sono sempre presenti come : hls2, hl5, hls8w, hls8z, hlsB, hlsC (180 MB, 4k UHD, h265), hlsD (360 MB, 4K UHD h264), directory dove puoi trovare i metafile con estensione .m3u8 ed i segmenti (fatta esclusione di hls2 che e' un po' piu' articolata).
Puoi aprirli con videolan vlc, ad esempio, per hls8w.m3u8 ( http://iginomanfre.it/hls8w/hls8w.m3u8 ) come scritto sopra cliccando sul pannello mostrato ti verra' richiesto cosa vuoi fare con questi chops: aprirli con il player di default (sul mio browser l'estensione m3u8 e' associata a videolan VLC) o salvarli dove ti pare (cosa completamente inutile)


click to Open hlsB.m3u8 with hevc payload

The difference with the former is the payload nature: these 41 transport streams chops are h265 (aka hevc) that browsers cannot play.

May be interesting to try the differences with vlc 4.0.0 nightbuilds 32 bit or 64 bit maybe is better to download and expand the 7z or zip package to not damage the official VLC installation.)

    

La differenza con le precedente e' la natura del payload: questi 41 chops di transport stream contengono elementary stream h265 (noto anche come hevc) che i browaser non riproducono.

Puo' essere interessante provare la differenza con vlc 4.0.0 nightbuilds 32 bit o 64 bit (forse e' meglio scaricarli in formato 7z o zip ed espanderli per non danneggiare l'installazione ufficiale di VLC)

Clicking over the image it is downloaded the metafile hlsB*.m3u8 with a progressive index (hlsB-1.m3u8, or hlsB-2.m3u8 as in this case) and this file is passed - as a playlist - to videolan VLC (because on my pc as it is the default opener of this extension).
This is not required on smartphone because the mobile browsers are able to open the m3u8 metafiles.

    

Cliccando sulla immagine e' scaricato il metafile hlsB*.m3u8 (l'asterisco indica un indice progressive (hlsB-1.m3u8, o hlsB-2.m3u8 come in questo caso) ed il file e' passato - come una playlist - a videolan VLC (perche' sul mio pc perche' e' l'applicazione di default associata a tale estensione).
Questo non server sugli smartphone perche' i browser dei cellulari sono in grado autonomamente di aprire i metafile m3u8.



MPEG5, Essential Video Coding (EVC)

20 years after the publication of mpeg4 standards the mpeg5 aims to define a royalty free essential compression coding in basic and enhanced. It practically recognise that the pervasive royalty war killed the video standardization.
In the meantime worldwide is increasing the usage of x264 and x265 GPL-2 licensing scheme (royalty free for non commercial applications).

JVET or VVT (Versatile Video Coding)

The next h266 will be (by name) the future video compression standard about which you can read more on the web.
The latest papers (as of writing the draft 10 elaborated on september 4, 2020) and much more can be found on fraunhofer JVET web page
The compression should offer 30-50% better compression at the price of the usual 10 time more complex compression than hevc (h265) while only a double decompression complexity should occur.
All in the spirit of Moore law, with its current about 30 billions transistor per chip.

The nice twin of the former video on Yosemite park

These videos have been made by projectyose.com and are tributed to Colin Dolehanty and friends.

yosemite_HD_h264_404p_300.mp4 (by browser with <video> tag)

<video id="yosemite_HD_h264" poster="../video/yosemite_HD.jpg" controls> <source src="../video/yosemite_HD_h264_404p_300.mp4" type="video/mp4" /> </video>

Using VLC it is possible to view its twin Yosemite II (already used many times above), streamed in realtime http (not dash or hls, true realtime streaming) compressed in hevc stream (wrapped ISO mp4) http://iginomanfre.it/Yosemite_SD200 720x404 encoded at a bitrate between 80 and 500 kbps (or http://95.110.164.61:64036/Yosemite2 if you want to reach the source stream not proxed by Apache). As told many times hevc payload wrapped mp4 streams cannot be played by the browsers (they can reproduce only h264 and vp8 video payloads).

And in this case you cannot use any trick nor associate a task to the stream download because - being looped - this is a real infinite file: the download starts but never ends....

But... but maybe... embedding the streaming instructions in the mp4 header it could work...
I will try...

uniform colours (360p)

sliding colors
flashing colors
sliding (fastly) colors

All videosize are 640x360 pixel but can stretched as required.
for more informations see here

older stuff

for problem of stability of VLC only two hls stream are always available are hls2 and hls8z

interesting panorama of streaming methods I use on this server
applied to h265 and h264 compressed streams.

Once upon a time there was the video streaming

Nowadays is basically only a tricky remote copy of a file.
I wrote the article True unicast streaming has lost his appeal about.

Video within page

Putting away any negative approach, today I say that Yes, it is possible, with any browser, but natively only in h264 (or VP8) and not in HSL/DASH: only in plain streaming, something alike the old progressive download.

Only h264 (or VP8) video can be embedded in html page, and it is reproduced from a copy in the terminal cache.
Not all the terminals could be able to download it seamless, because not all the terminals could have enough cache for this purpose.
On the contrary almost all terminals have enough computational power to decode h264 (and generally speaking much much more).
The video is locally downloaded as it is (thanks to the TCP/IP) and reproduced through the commands.
For the peace of the sense of rights people this content will be deleted and will be hardly reacheable from outside.

This is not correct from my point of view.
You can feel this looking the timeline, which (depending on the available bandwidth) become gray since the beginning of play.


On the contrary, if the video would be downloaded while it plays, the bandwidth would be the following:

payload bitrate of the video embedded in this page.
It has no sense in progressive download, because all the available bandwidth may be used to copy the slices or the entire file.

To be html5 compliant the browsers must be able to play mp4 or webm wrappers with h264 or vp8 video and aac, mp3 or ogg audio payloads.
It is not a problem of complexity: no-one care how much power the compression drain because all is done in cloud by powerful (but not free) servers. h265 is about ten times more heavy than h264: the same video my quite old core2duo 32bit employ 2 minutes to compress a video in h264, require more than 20 to be compressed in h265.
The result is really much better. You can test the differences comparing the h264 one with what can open directly with VLC as
http://iginomanfre.it/yosemite_hevc_SD100.
To see something more (such as embedded h265) you need of a plug-in that's all but free because the VLC plug-in is no more supported by the most diffused browser.

The next image shows how the page yosemite.html can be see with an old version of the most diffused browsers (). It contains embedded h265 video in true real time streaming, but the latest versions (Firefox after 51.0b9) do not support anymore VLC plug-ins




above the section of yosemite.html with an old version of most diffused browser. Below the most diffused browsers (such as what you're using now such as chrome, firefox, internet explorer, opera)

Original live http streaming with VLC
(no more supported by current browsers)








Segmented stream in HLS generated with VLC
(no more supported by current browsers)

(http://iginomanfre.it/hsl8w/hls8w.m3u8 is always available,
while http://iginomanfre.it/hsl8/hls8.m3u8 is only available on request) The playlist (.m3u8 file is a playlist) can be recalled with any editor but has a extremely rigid syntax as explained here (RFC from IETF)and here (from apple developer).

As probably you can see, because the browsers are unable to open the stream (because they do not support anymore the VLC NPAPI plug-in) the videos simply disappears and - hopefully - you see in their place the banned VLC cone i've added as error image.

Here you can read more about the probable reason of end of support of VLC plug-in.
In the meantime VLC plug-in has been corrected and the security problem should not exist any more.
But its ban continue and browsers do not support any more plug-ins.

The following paragraph shows the playout section of the realtime streaming cell (the leftmost), i.e. no sliced at all is produced but the stream is generated by VLC as sequence of video and audio packets.

<OBJECT classid="clsid:E23FE9C6-778E-49D4-B537-38FCDE4887D8" codebase="http://downloads.videolan.org/pub/videolan/vlc/latest/win32/axvlc.cab" width="360" height="200" id="yosemite_SD100" events="True"> <param name="Src" value="http://www.iginomanfre.it/Yosemite_SD100"> <param name="ShowDisplay" value="True"> <param name="AutoLoop" value="True"> <param name="network-caching" value="1000"> <param name="AutoPlay" value="True"> <param name="Volume" value="0.0"> <embed type="application/x-vlc-plugin" pluginspage="http://www.videolan.org" src="http://www.iginomanfre.it/Yosemite_SD100" type="video/mpeg" width="360" height="200" network-caching="1000"/> <object data="../jpg/vlc_forbidden_360x200.jpg" type="image/jpg"> </object> The following paragraph shows the playout section of the offline (once realtime) sliced cell (the rightmost)
<OBJECT classid="clsid:E23FE9C6-778E-49D4-B537-38FCDE4887D8" codebase="http://downloads.videolan.org/pub/videolan/vlc/latest/win32/axvlc.cab" width="360" height="200" id="hls8" events="True"> <param name="Src" value="http://www.iginomanfre.it/hls8w/hls8w.m3u8"> <param name="ShowDisplay" value="True"> <param name="AutoLoop" value="True"> <param name="network-caching" value="1000"> <param name="AutoPlay" value="True"> <param name="Volume" value="0.0"> <embed type="application/x-vlc-plugin" pluginspage="http://www.videolan.org" src="http://www.iginomanfre.it/hls8w/hls8w.m3u8" type="video/mpeg" width="360" height="200" network-caching="1000"/> <object data="../jpg/vlc_forbidden_360x200.jpg" type="image/jpg"> </object>

The above syntax with the usage of vlc plug-in is no more supported by current browsers, so to see a video instead of a barred cone you can use VLC recall http://www.iginomanfre.it/hls8w/hls8w.m3u8, or safari 5 for windows (latest 5.1.7 version available did it).
No chance to see the or its source http://www.iginomanfre.it/Yosemite_SD100

As told above the file http://www.iginomanfre.it/hls8/hls8.m3u8 (and the related chops) are only available in request,
while the file http://www.iginomanfre.it/hls8w/hls8w.m3u8 (and the related chops) is offline splitted and always available The m3u8 playlist can be played with VLC using open network stream (and the result):
(now replaced by hls8w)



To split permanently the file in chops I've used the following VLC call

"c:\program files\vlc\vlc" sourcefilewithpath --file-caching=3000 <br> :sout=#std{access=livehttp{seglen=10,delsegs=false,<br> index="webserverroot\hls8w\hls8w.m3u8",<br> index-url=http://iginomanfre.it/hls8w/hls8w-########.ts},mux=ts{use-key-frames},<br> dst="webserverroot\hls8w\hls8w-########.ts"}

It is hard to be done by hand: be careful to what you write, the <br> has been added to highlight the spaces

All around is moved by the profit...

In progressive download the downloaded video will occupy its entire size in the cache of your terminal (since this one is less than 7 MB it is quite fast), while using HLS or DASH it would be copied in slices of few seconds one after the other pointed by a metafile.
Either last versions of HLS or DASH allow to adapt the video download to the speed of the connection, but this is a trick to compress live the video or to increase the number of compressions a single video may require: a 5 minute video would be splitted in 30 slices about 10 seconds long each by the number of compression and resolution planned. If you plan to serve 10 bitrates and/or resolutions, you need 10 different pre-compressions (and 300 slices), or, as the encoders companies prefere, you need to add a real time encoding capability to your media asset management.

TIM vision compressions for 8 channels source in 5 possible languages and 3 resolutions (HD, SD 16:9 and 4:3)
This considering a couple of language a time, with and without subtitle, but not multichannel audio (e.g. ITA 5+1, stereo ITA, ENG)
TIM vision uses h265 because its STB has the capability to decode it. This cannot be the case of a general purpose website.

This embedding video is different from the video present in my homepage because that video comes from youtube and it is invoked through a iframe tag, quite general purpose tag to embed a web object in another (it can be used to create a scrollable page within another).
<iframe width="400" height="225" src="https://www.youtube.com/embed/4GX6a2WEA1Q" frameborder="0" allowfullscreen> </iframe>
while this is recalled through the video tag
<video id="yosemite_h264" poster="../jpg/yosemite_poster.jpg" controls> <source src="../media/Yosemite_h264_SD100.mp4" type="video/mp4" /> </video>

hls streaming

This is the list of the hls file generated with vlc
The slices generated are pointed by the m3u8 playlist file
Due to a VLC bug (something alike a memory management) when you use VLC command-line interface at any loop is drained a little bit of memory, and this my bring the server to instability. This is particularly true in splitting, so I avoid to use the realtime splitting and production of .m3u8 files (even because only VLC can read it)

Welcome to HEVC thread

And now we must wait JVET (may 2018)

JVET stays for Joint Video Exploration Team, we must become familiar with this acronym as we did with hevc or simpler h265 few years ago.
JVET, is the next chapter the ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11 team is planning to squeeze video.
These webpages from ITU website and from Fraunhofer are maybe more detailed.

The meetings of VCEG (Video Coding Expert Group) started in october 2015, aside the Geneva Lake, when most of us just hear something of hevc.
Now, as usual, there is reference a software for the JVET group, called JEM (Joint Exploration Model) which probably let us see the stars....

The page all meetings of the JVET document management system hold by University of Sud Paris lists the documents divided by the meetings related to JVET (the rest of the site - as the draft standard - seems quite in progress): but going back of about 30 years, how many would spent a cent for mpeg?

As it is written in a paper of July 2017 but diffused in the Macau meeting :

For many applications, compression efficiency is the most important property of a future video coding standard. A substantial improvement in compression efficiency compared to HEVC Main Profile is required for the target application(s); at no point of the entire bit rate range shall it be worse than existing standard(s). 30% bitrate reduction for the same perceptual quality is sufficient for some important use-cases and may justify a future video coding standard. Other use-cases may require higher bit-rate reductions such as 50%.

We all must stay Tuned!

Darkening the welcome (january 2017)

About 20 years ago, video on the web was all but diffused as today: Youtube did not exist, but more important, to stream something it was required to produce at least three files compressed in three proprietary similar but mutually uncompatible compression schemes (quicktime, windows media and real video).

In these years we passed through flash, mpeg4, dynamic streaming, h264, DASH and last h265. Recently I've worked on the catalogue of TIM vision to address the contents to the many profiles to be compressed in h265 not exactly in cloud (it could be named how we can get all the inconveniences of cloud, as you can imagine, it's a long story, not to be dealt now).

h265 confirms an asthonishing compression scheme. It is possible to compress in HD at 1 Mbps. Compression artifacts almost disappears, but after the licensing scheme related problems (see below what I wrote about one year ago), there is a main question: the match between DASH and HEVC does not convince me a lot. In HEVC disappears the I frames but in order to break the file in chops for DASH needs, we must introduce artificial (not video related) break points (say every 5 seconds) to be able to switch in sync for bandwidth adaptation.

The DASH playlist file (officially .mpd) may contains 10 references to many audio and video resolutions. It means that you may pass from a 45 GB of source MXF file to 10 GB hevc file set. The providers of compression engines and storage are happy because they sell their services or systems on the pound, but I'm asking why do not apply chromatic and spatial resolution scalability?

To understand what is hevc scalability extension, read this article SHVC, the Scalable Extensions of HEVC, and Its Applications from ZTE corp (Shenzen, PRC) website.
Practically with scalable extensions instead of many versions of the same content encoded at different bitrate and size, are produced one basic level and some enhancements that adds informations. These enhancements may be transmitted though a DASH approach. Since you're in, read also this article about multilayering in HEVC, from the same source.

The above picture (from Multi-Layer Extension of the High Efficiency Video Coding (HEVC) Standard, same source of the former) sketches an example SHVC bitstream of spatial scalability with two layers, one base (BL) of lower resolution, and one (here, only one) enhancement layer (EL), a delta toward a higher resolution. You must consider that since in HEVC disappears the Group of Picture (GoP) concept as it was until h264 (so IBP frames do not exist anymore), any tile and/or slice in which the images sequence is decomposed has its own history and evolution. The sense is that: instead of switching between different resolution and bitrates files, the receiver get a base layer and many deltas.

Licensing of HEVC

It may be extremely interesting to read (and download) the HEVC licensing scheme from the HEVC advance, consider this website and take a look to the frequently updated licence section.
At the moment I do not know about real broadcasting test of HEVC, despite the marketing efforts. My biggest concern is related to the potential bandwidth of a transport stream broadcasted by air, cable or satellite.
The quality vs bitrate of hevc is really asthonishing, but its lack of GoP do not marry with conventional wave transmitting way such as transport stream or the DASH which segmentation is at the moment GoP prone (I mean: breaking in segment before an I-frame works better). The test I'm conducting on (360p24 and 720p24 show a high sensitivity to the bandwidth characteristics: if your connection is really broadband you'll never experience any problem... otherwise...

In february 2015 the availability of open source HEVC codec (High Efficiency Video Compression, known also as h265) means it is ready to be used by all us.

To read/download the standard reach the ITU website and select the latest available version (as of writing, on may 23rd, the latest release of april 2015 was still not available). All the ITU standards are downloadable for free in pdf format. It is extremely valuable that standards are made public at no cost. For media industries the most known are h262 (mpeg2) and h264 (avc). Please consider how all the international bodies that sell the standards damage the interoperability and the progress of technology, forbidding an easy access the reference documents to the interested audience.

The more than 500 pages of the h265 standard may be too complex at first sight.
For basic informations you may read these Wikipedia articles about the h265 standard or its tiers and levels (the profiles and levels of former MPEG standards).

Yes, Wikipedia, please do not be disturbed! I think that the lack of simple and accessible information is one reason of the wide technology misconceptions, too much limited to a restricted public. All the things available over the web requires knowledge to be filtered out from dust and mistakes.
Wikipedia - one of the greatest things available on the web, I think - may back the first steps (and often the further ones) of this knowledge gain.

something already seen

It is terrible, but after any technological risks HEVC might suffer, it seems that a number of lawyers are trying to assault this new train of technology before of its roll out

HEVC Advance produced in april last year a pricelist (officially Patent Pool pricing) updated in december in reaction of which initiative of april and december 2015 has been founded the Alliance for open media (a joint initiative of Amazon, Cisco, Google, Intel, Microsoft, Mozilla and Netflix) to create a new, royalty-free, open-source video compression format.

Last arrives the initiatives of MPEG LA (that literally killed MPEG4 in 2001) that later than other aggressive colleagues, define a specific new initiative).

What do they want to do? A proprietary open standard like VPn ?
Doesn't MPEG story teach anything to this people

At the moment I'm still trying to understand how HEVC is compatible with dynamic streaming (excluding a simpler profile enabling something like a GOP aligned segmentation) which would vanify a lot of compression gains. Even the naive way of streaming (what I'm using above) suffer of bandwidth fluctuation, but the quality gains from the algorithm.

Now these Lawyers-standards-killers (which performance we were already able to understand in 2001) could now kill even HEVC.
I hope not.

interesting articles

4K HEVC Video Is Years Away From Being a Streaming Reality
from streaming media.com (april 2015)

Ozer's presentation about Producing and distributing HEVC from streaming media.com (april 2015)
of which is also available the Video on YouTube recorded at Streaming media west convention of 2015

HEVC demistified
from Elemental Technologies website (it requires a registration)

My voice

I remember in 1989 when the first MPEG1 standard papers comes out. A plenty of time passed by, but we must not forget it has been the first brick (even a stone: think to mp3 success!) that affected the technology of media as never before.

I was in. Maybe you could be interested to read A lot of passes have been done...

And today, being HEVC an hot subject, I've not been able to refrain me from writing down something:

embedded 360p24 HEVC embedded html page (february 2015)
It requires videolan VLC player version 2.2.0 (or greater) to be decoded. VLC is available in LGPL from videolan website.
Video embedding is not performed on smartphones for which browsers plug-ins have not been released (and probably will never done).
Smartphones - after installing VLC for android of iOS - may access to the stream http://www.iginomanfre.it/x70_hevc_300

embedded 720p24 HEVC embedded html page (february 2015)
This reproduction requires an hardware base with at least powerful as a Core2duo or a quadricore ARM on http://www.iginomanfre.it/x70_hevc_1200

Before (CPU load at 15%) and after starting the 1.2 Mbps 720p24 stream reproduction on my core2duo laptop

Welcome HEVC (may 2015)

I wrote this post three months later the former ones in which I published two embedded HEVC videos.

HEVC quality is asthonishing (take a look to my 300 kbps SD video), and any enhancement is welcome.

The first question is How much welcome?

Yes, because the entropy reduction of the HEVC is so high that any small impulsive bottleneck in ip distribution pipe may destroy a plenty of unreplaceable information, affecting a many coding units in their slices and/or tiles grouping.
In terms of viewing it means a gray/green stripes across the screen, and the probability of this increases at the size and the framerate increasing.
My samples are basic: a small 360p30 and a bigger 720p30 , but HEVC will reach 8k at high refresh rate (up to 300 Hz, because - in order to avoid sliding - increasing the size requires a faster frame speed).
This can be recovered copying the segments to the clients (as it happens in ordinary HLS streaming or DASH) but it makes mandatory the usage of FEC (Forward Error Correction) in unidirectional streaming such as plain UDP or satellite broadcasting.
This FEC can vanishes a lot of compression savings and require a delay.
So, the delay up to a couple of seconds between DTT and HLS delivery will be required still in the future.

Consequences of Moore law

The hevc compression is much much more complex than MPEG2 (not less than 300 times more) and the decompression requires a plenty of computational power (about 30 times). It means that whenever YouTube would adopt HEVC (but I do not think so) my core2duo laptop would be unable to decompress their 720p30 standard size videos.
All the new compression schemes may rely on Moore's law hardware forecast: every 18 months the power of a processor will double. So a plenty of more computational power is available every year, and in this consumistic society no-one will behave in a more sustainable way.
It was not a secret. Already in february 2014 it had been announced by this Intel article, but one thing is to read the other find that my mobile android quadricore smartphone decodes what my older Core2duo don't.

And obviously neither the Atom based net PC decodes it smoothly, even the small 360p24.

Again, How much welcome?.

In broadcasting HEVC has been long awaited as the solution for bandwidth crowding, to deliver more HD channels with the SD bandwidth.
But the above mentioned more complexity imply the replacement/introduction of the decoder because the former one do not perform HEVC decoding in realtime or at all.
This could not be a problem in proprietary or brand new delivery platform (such as pay-tv) but at a cost for the broadcaster or for the consumer.
And - we know - in these times of crysis, savings more than long RoI (Return of Investment) expenses are welcome...
Despite Mr. Draghi is printing money almost free, there is not a plenty of money to invest...

In free to air delivery, satellite or DTT, HEVC will not be adopted easily because it could affect the share: the greater part of the receiver are still limited to SD MPEG2 decoding.

So, who will pay? I would not be negative, so I refrain to continue....

In any case, as the story should teach us, nothing else than a standard can find a wide market success: see the rise and fall of all non-standard (proprietary) compression schemes, even last Microsoft VCx or Google VPx.
As usual a plenty of studies has been done and will be carried out (e.g. this comparison between HEVC, VP9 and AVC, but all the honest and independent professional operators will choose nothing, absolutely nothing else than a standard.

back

Nothing is free

Listening the Telco's advertisments our homes should be surrounded by fiberoptics and multimegabit-per-second last miles.
This is partially true, at this can be tested through these pages.

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.
It can be felt comparing the reception of the same stream at different bitrate and size, at 3-400 Kbps and 1500 Kbps, and -- as recalled above -- the bitrate is tightly required.
In h265 to reach level of compression higher than h264, the concept of Group of Picture (GoP) 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



These images from a Vodafone ADSL (not fiber backed) at my home. of 1.5 Mbps stream.

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.

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.

Click here if the reproduction is jerky (processor power or network conditions.

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
http://iginomanfre.it/x70_hevc_300.
but depending on the state of the server,
this stream could not be available

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

General

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

Video

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

Audio

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

apropos 4k

Other things are coming, 4k (4:2:0) with source downloaded from the web... but the time to compress them on my small core2duo is terrible.
Not only, but in july 2015 VLC stopped to compress in hevc with x265 library.
No problem, I can use ffmpeg, the open source software which developed the library. But there are few problems about which I'm investigating, not only the speed.

4k e 8k: what's the worth of this high resolution race?

The 1602 fašade of Carlo Maderno is 114,69 wide by 45,44 meters tall (from wikipedia) so the pitch of the projection done at the jubilaeum opening night show has been 1.4 cm, one pixel every 1.4 centimeter



Consider that scanning an A4 sheet (21 by 29.7 cm) at 300 dpi (dot per inch, about 12 pixel per millimeter). That sheet landscape oriented is a 3K (3507 pixels).
Projecting the smallest "8k" screen (7680x4320) on a 4 mm pitch professional LED composable display (used in theatrical background) generate 30.72 wide by 17.28 meters tall image. But at home, do we need of such sizes ?
The market continously requires us to buy wider and wider screens.
The following table shows the sizes in mm and the optical viewing distances of screens by diagolan inches sizes



A 100 inches screen hosting true 8k resolution of 2.21 by 1.24 meters, it means a resolution if about 36 dots per centimeter, 90 dot per inch, about 4 dots per millimeter.
Our visual acuity is about half degree: at 3.5 meter it is about few millemeters.

When in summer 2020 we went to buy a new flat screen tv (a 4k) the selling person told us this screen technology is much much poorer than the other [the nanoled tech]: it has a led every 8 pixel.
I made a quick count: about 2000 pixels on 80 cms, it means that you could notice luminosity gradient on squares of 4 mm. But if this is true for OLED where coloured light is emitted pixel per pixel (but OLED screen suffers other problems) and partially for nanoled lecnologies, the light Luminosity behind the LCD screen does not changes.

Consumism, the soul of commerce..

Welcome to HEVC thread

And now we must wait JVET (may 2018)

JVET stays for Joint Video Exploration Team, we must become familiar with this acronym as we did with hevc or simpler h265 few years ago.
JVET, is the next chapter the ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11 team is planning to squeeze video.
These webpages from ITU website and from Fraunhofer are maybe more detailed.

The meetings of VCEG (Video Coding Expert Group) started in october 2015, aside the Geneva Lake, when most of us just hear something of hevc.
Now, as usual, there is reference a software for the JVET group, called JEM (Joint Exploration Model) which probably let us see the stars....

The page all meetings of the JVET document management system hold by University of Sud Paris lists the documents divided by the meetings related to JVET (the rest of the site - as the draft standard - seems quite in progress): but going back of about 30 years, how many would spent a cent for mpeg?

As it is written in a paper of July 2017 but diffused in the Macau meeting :

For many applications, compression efficiency is the most important property of a future video coding standard. A substantial improvement in compression efficiency compared to HEVC Main Profile is required for the target application(s); at no point of the entire bit rate range shall it be worse than existing standard(s). 30% bitrate reduction for the same perceptual quality is sufficient for some important use-cases and may justify a future video coding standard. Other use-cases may require higher bit-rate reductions such as 50%.

We all must stay Tuned!

Darkening the welcome (january 2017)

About 20 years ago, video on the web was all but diffused as today: Youtube did not exist, but more important, to stream something it was required to produce at least three files compressed in three proprietary similar but mutually uncompatible compression schemes (quicktime, windows media and real video).

In these years we passed through flash, mpeg4, dynamic streaming, h264, DASH and last h265. Recently I've worked on the catalogue of TIM vision to address the contents to the many profiles to be compressed in h265 not exactly in cloud (it could be named how we can get all the inconveniences of cloud, as you can imagine, it's a long story, not to be dealt now).

h265 confirms an asthonishing compression scheme. It is possible to compress in HD at 1 Mbps. Compression artifacts almost disappears, but after the licensing scheme related problems (see below what I wrote about one year ago), there is a main question: the match between DASH and HEVC does not convince me a lot. In HEVC disappears the I frames but in order to break the file in chops for DASH needs, we must introduce artificial (not video related) break points (say every 5 seconds) to be able to switch in sync for bandwidth adaptation.

The DASH playlist file (officially .mpd) may contains 10 references to many audio and video resolutions. It means that you may pass from a 45 GB of source MXF file to 10 GB hevc file set. The providers of compression engines and storage are happy because they sell their services or systems on the pound, but I'm asking why do not apply chromatic and spatial resolution scalability?

To understand what is hevc scalability extension, read this article SHVC, the Scalable Extensions of HEVC, and Its Applications from ZTE corp (Shenzen, PRC) website.
Practically with scalable extensions instead of many versions of the same content encoded at different bitrate and size, are produced one basic level and some enhancements that adds informations. These enhancements may be transmitted though a DASH approach. Since you're in, read also this article about multilayering in HEVC, from the same source.

The above picture (from Multi-Layer Extension of the High Efficiency Video Coding (HEVC) Standard, same source of the former) sketches an example SHVC bitstream of spatial scalability with two layers, one base (BL) of lower resolution, and one (here, only one) enhancement layer (EL), a delta toward a higher resolution. You must consider that since in HEVC disappears the Group of Picture (GoP) concept as it was until h264 (so IBP frames do not exist anymore), any tile and/or slice in which the images sequence is decomposed has its own history and evolution. The sense is that: instead of switching between different resolution and bitrates files, the receiver get a base layer and many deltas.

Licensing of HEVC

It may be extremely interesting to read (and download) the HEVC licensing scheme from the HEVC advance, consider this website and take a look to the frequently updated licence section.
At the moment I do not know about real broadcasting test of HEVC, despite the marketing efforts. My biggest concern is related to the potential bandwidth of a transport stream broadcasted by air, cable or satellite.
The quality vs bitrate of hevc is really asthonishing, but its lack of GoP do not marry with conventional wave transmitting way such as transport stream or the DASH which segmentation is at the moment GoP prone (I mean: breaking in segment before an I-frame works better). The test I'm conducting on (360p24 and 720p24 show a high sensitivity to the bandwidth characteristics: if your connection is really broadband you'll never experience any problem... otherwise...

In february 2015 the availability of open source HEVC codec (High Efficiency Video Compression, known also as h265) means it is ready to be used by all us.

To read/download the standard reach the ITU website and select the latest available version (as of writing, on may 23rd, the latest release of april 2015 was still not available). All the ITU standards are downloadable for free in pdf format. It is extremely valuable that standards are made public at no cost. For media industries the most known are h262 (mpeg2) and h264 (avc). Please consider how all the international bodies that sell the standards damage the interoperability and the progress of technology, forbidding an easy access the reference documents to the interested audience.

The more than 500 pages of the h265 standard may be too complex at first sight.
For basic informations you may read these Wikipedia articles about the h265 standard or its tiers and levels (the profiles and levels of former MPEG standards).

Yes, Wikipedia, please do not be disturbed! I think that the lack of simple and accessible information is one reason of the wide technology misconceptions, too much limited to a restricted public. All the things available over the web requires knowledge to be filtered out from dust and mistakes.
Wikipedia - one of the greatest things available on the web, I think - may back the first steps (and often the further ones) of this knowledge gain.

something already seen

It is terrible, but after any technological risks HEVC might suffer, it seems that a number of lawyers are trying to assault this new train of technology before of its roll out

HEVC Advance produced in april last year a pricelist (officially Patent Pool pricing) updated in december in reaction of which initiative of april and december 2015 has been founded the Alliance for open media (a joint initiative of Amazon, Cisco, Google, Intel, Microsoft, Mozilla and Netflix) to create a new, royalty-free, open-source video compression format.

Last arrives the initiatives of MPEG LA (that literally killed MPEG4 in 2001) that later than other aggressive colleagues, define a specific new initiative).

What do they want to do? A proprietary open standard like VPn ?
Doesn't MPEG story teach anything to this people

At the moment I'm still trying to understand how HEVC is compatible with dynamic streaming (excluding a simpler profile enabling something like a GOP aligned segmentation) which would vanify a lot of compression gains. Even the naive way of streaming (what I'm using above) suffer of bandwidth fluctuation, but the quality gains from the algorithm.

Now these Lawyers-standards-killers (which performance we were already able to understand in 2001) could now kill even HEVC.
I hope not.

interesting articles

4K HEVC Video Is Years Away From Being a Streaming Reality
from streaming media.com (april 2015)

Ozer's presentation about Producing and distributing HEVC from streaming media.com (april 2015)
of which is also available the Video on YouTube recorded at Streaming media west convention of 2015

HEVC demistified
from Elemental Technologies website (it requires a registration)

My voice

I remember in 1989 when the first MPEG1 standard papers comes out. A plenty of time passed by, but we must not forget it has been the first brick (even a stone: think to mp3 success!) that affected the technology of media as never before.

I was in. Maybe you could be interested to read A lot of passes have been done...

And today, being HEVC an hot subject, I've not been able to refrain me from writing down something:

embedded 360p24 HEVC embedded html page (february 2015)
It requires videolan VLC player version 2.2.0 (or greater) to be decoded. VLC is available in LGPL from videolan website.
Video embedding is not performed on smartphones for which browsers plug-ins have not been released (and probably will never done).
Smartphones - after installing VLC for android of iOS - may access to the stream http://www.iginomanfre.it/x70_hevc_300

embedded 720p24 HEVC embedded html page (february 2015)
This reproduction requires an hardware base with at least powerful as a Core2duo or a quadricore ARM on http://www.iginomanfre.it/x70_hevc_1200

Before (CPU load at 15%) and after starting the 1.2 Mbps 720p24 stream reproduction on my core2duo laptop

A couple of months after considerations (may 2015)

Further consideration of November 2015

Other things are coming, 4k (4:2:0) with source downloaded from the web... but the time to compress them on my small core2duo is terrible.
Not only, but in july 2015 VLC stopped to compress in hevc with x265 library.
No problem, I can use ffmpeg, the open source software which developed the library. But there are few problems about which I'm investigating, not only the speed.

4k e 8k: what's the worth of this high resolution race?

The 1602 fašade of Carlo Maderno is 114,69 wide by 45,44 meters tall (from wikipedia) so the pitch of the projection done at the jubilaeum opening night show has been 1.4 cm, one pixel every 1.4 centimeter



Consider that scanning an A4 sheet (21 by 29.7 cm) at 300 dpi (dot per inch, about 12 pixel per millimeter). That sheet landscape oriented is a 3K (3507 pixels).
Projecting the smallest "8k" screen (7680x4320) on a 4 mm pitch professional LED composable display (used in theatrical background) generate 30.72 wide by 17.28 meters tall image. But at home, do we need of such sizes ?
The market continously requires us to buy wider and wider screens.
The following table shows the sizes in mm and the optical viewing distances of screens by diagolan inches sizes



A 100 inches screen hosting true 8k resolution of 2.21 by 1.24 meters, it means a resolution if about 36 dots per centimeter, 90 dot per inch, about 4 dots per millimeter.
Our visual acuity is about half degree: at 3.5 meter it is about few millemeters.

When in summer 2020 we went to buy a new flat screen tv (a 4k) the selling person told us this screen technology is much much poorer than the other [the nanoled tech]: it has a led every 8 pixel.
I made a quick count: about 2000 pixels on 80 cms, it means that you could notice luminosity gradient on squares of 4 mm. But if this is true for OLED where coloured light is emitted pixel per pixel (but OLED screen suffers other problems) and partially for nanoled lecnologies, the light Luminosity behind the LCD screen does not changes.

Consumism, the soul of commerce..

A lot of passes have been done...

I remember in 1993-95, to compress in AVI with Radius Cinepack codec or the Intel Indeo 3.2 compressors from a PAL signal precropped to CIF format (352x288 pixels) , running on a 486 or one of the first pentium based PC's (the maximum available at the time), required an entire day (23 hours). After all the output quality was very poor if compared to today's codecs. The audio has been compressed in linear PCM with a sampling rate of 11025 KHz because at that time mpeg 1 layer 2 -- despite at that time it would be already available -- was correctly played only by dedicated hardware.

If you want you may download to play a small video (the "credits", the people that worked on Multimedia 2 go), 2 minutes long I've found on the original CD we made, compressed in Intel Indeo 3.2 (19.6 MB), in current h264 with mp3 audio (about 3.2 MB) and current h264 with aac audio (about 2.4 MB).
Expecially the first version, a quite big file, compressed with a very old codec, could be reproduced only by VLC (despite it should be playable by default by Windows), and in any case could be good to download it before through the right mouse click and "save as".
When I tested this page, I remained quite surprised to see that the entire 2 minute video, compressed in h264, was played immediately by mozilla firefox, not - as I though - through VLC after it had been choosed as default opener of mp4 files. Evidently the browser itself in a way similar to what required by HTML5 compliancy, can decode those file (they are not stream, but file seen in progressive download).
It is all but a curious note. Html5 compliancy is a big problem, as it has been interpreted by Google Chrome: the management of video compressions cannot be performedthrough external plug-ins, but must be performed by the browser itself.
Mobile phones' browsers do not use plug-ins while workstations ones allow them. But the new releases of Chrome don't accept VLC plug-in as dangerous for navigation safety.

Comparisons between the three version of the same video (mediainfo)
:
General
Filename H:\video\Multimedia 2 Go people (19950222).avi
(not downloadable because seen unsafe by many browsers)
H:\video\Multimedia 2 Go people (19950222)_a.mp4H:\video\Multimedia 2 Go people (19950222)_d.mp4
FormatAVI, Audio Video Interleave, recMPEG-4, Base Media, isomMPEG-4, Base Media, isom
File size19.1 MiB3.16 MiB2.38 MiB
Duration2mn 7s2mn 7s2mn 7s
Overall bit rate1 257 Kbps208 Kbps157 Kbps
Video
ID011
Format, Codec, Version/Profile/LevelIndeo 3, IV32, Intel Indeo Video 3.2AVC, Advanced Video Coding, High@L1.3AVC, Advanced Video Coding, High@L1.3
DetailsCABAC, Reframes=4CABAC, Reframes=4
Width, Display Aspect Ratio, Frame Rate320x240, 4:3, 25 fps320x240, 4:3, 25 fps320x240, 4:3, 25 fps
Frame Rate25 fpsvariable: mean 24.247 fps, min 6.250 fps, max 25.000 fpsvariable: mean 24.247 fps, min 6.250 fps, max 25.000 fps
Bits/(Pixel*Frame)0.5730.0810.054
Color space, Chroma subsampling, Bit Depth, ScanY'UV, 4:2:0, ProgressiveYUV, 4:2:0, 8bit, ProgressiveYUV, 4:2:0, 8bit, Progressive
Stream size16.8 MiB (88%)2.22 MiB (70%)1.48 MiB (62%)
Writing Libraryx264 core 146 r2538 121396cx264 core 146 r2538 121396c
Detailscabac=1, ref=3, deblock=1:0:0, analyse=0x3:0x133, me=hex, subme=7, psy=1, psy_rd=1.00:0.00, mixed_ref=1, me_range=16, chroma_me=1, trellis=1, 8x8dct=1, cqm=0, deadzone=21,11, fast_pskip=1, chroma_qp_offset=-2, threads=3, lookahead_threads=1, sliced_threads=0, nr=0, decimate=1, interlaced=0, bluray_compat=0, constrained_intra=0, bframes=3, b_pyramid=2, b_adapt=1, b_bias=0, direct=1, weightb=1, open_gop=0, weightp=2, keyint=250, keyint_min=25, scenecut=40, intra_refresh=0, rc_lookahead=40, rc=2pass, mbtree=1, bitrate=150, ratetol=1.0, qcomp=0.60, qpmin=10, qpmax=51, qpstep=4, cplxblur=20.0, qblur=0.5, ip_ratio=1.40, aq=1:1.00
Audio
ID122
Format, Endianness, Sign, Codec IDPCM, Little, Unsigned, 1MPEG Audio, Version 1, Layer 3, 6BAAC (lav), Advanced Audio Codec LC, 40
Bitrate88.2 Kbps56.0 Kbps50.8 Kbps (max 56 Kbps)
Bitrate mode, Sampling rate, channelsConstant, 11.025 KHz, 1 channelConstant, 48.0 KHz, 2 channelsConstant, 48.0 KHz, 2 channels
Alignement, interleave durationAligned on interleaves, 40 ms (1.00 video frame)
Stream Size1.34 MiB (7%)872 KiB (27%)791 KiB (32%)

Un solo modo di streammare

Oggi e' praticamente impossibile inserire un video in una webpage html se il video non e' codificato in un formato direttamente supportato dal browser perche' i piu' usati tra questi non supportano piu' plug-in video esterni.

Fin dagli albori dell'html5 lo scopo principale dell'W3C e'stato quello di ripulire il codice html.
In realta' questa semplificazione ha portato alla necessita' di integrare l'html base con chiamate a decodificatori esterni. Esattamente come si faceva prima con il tag object ed i plug-in esterni.

Tra le molte istruzioni deprecate in html5 ci sono gli oggetti correlati alla architettura NPAPI derivata da Netscape.

A causa della fine del supporto dei plug-in NPAPI da parte di Firefox, Chrome e Opera, utilizzando questi browser le pagine web che incorporano video che ho scritto finora non lo includeranno in corso testo.
Finora, per la indisponibilita' di plug-in, sugli smartphone le mie pagine non mostravano video in corso testo. Era comunque possibile richiamare i flussi con applicazioni come VLC utilizzando la URL dell stream.

Al momento in ho scritto inizialmente queste righe (4 maggio 2017) l'unico modo di continuare a vedere le mie pagine con il video in corso testo e' usare Apple Safari (nell'ultima versione per Windows, ma ora non piu' supportata da Apple) perche' nel frattempo anche Microsoft Internet Explorer non lo supporta piu'. Midori e' un possibile browser alternatico, ma non sembra una cosa realmente proponibile.

Una discussione completa relativa a Firefox puo' essere trovata in questa pagina ufficiale di mozilla firefox.

Only one way of Streaming

Today it is practically impossible to embed video in webpage if video is not encoded in formats directly supported by the browser because the most used ones does not support any more plug-ins

Since the beginning of html5 the main goal of W3C has been to clean the html.
Really this semplification brought to the need of integrate basic html with call to external decoders. Exactly as did before with object tag and external plug-ins.

Between the many deprecated instructions in html5 there are the usage of objects related to the
NPAPI architecture derived from Netscape.

Due to the end of support of NPAPI plug-ins by Firefox, Chrome and Opera, using these browsers the webpages that embed video I wrote up to now will not show any more embedded video within text.
Until now I used to stream with VLC and play the video with an external call vlc plug-in, and for this reason, due to the lack of plug-ins, on the smartphones my web pages did not show text with embedded video. It was anyhow possibile to recall the streams through applications such as VLC using the URL of the stream.

Since I wrote initially this page (may 4th 2017) the only way to continue to see the webpages embedding video with plug-ins is Apple Safari (in its last windows available version but no more supported by Apple) because in the meantime Microsoft Internet Explorer also do not support it. Midori is a possible alternative browser, but it does not seem a real alternative.

A complete discussion about firefox can be found in this official mozilla firefox page.


I browser con il tag video non riproducono l'hevc ma solo l'h264 o il webm. Di seguito, usando un iframe provo ad invocare un player esterno per riprodurre un hls contentente elementary stream hevc:

With video tag the browsers are unable to reproduce hevc but only h264 and webm. In the next I try using an iframe to call an external player to reproduce an hls containing hevc elementary stream:

<iframe width="640" height="360" seamless src="http://iginomanfre.it/hls7/hls7.m3u8" frameborder="1" allowfullscreen> </iframe>
Now the automatic start is commented, it does not bory your browsing any more
Ora ho commentato la partenza automatica dell'iframe, non ti infastidira' piu'
Per ulteriori informazioni dai una occhiata a questo file: e' relativo all'hls di un wrapper mpeg4 con elementary stream h264, ma e' la stessa cosa
Se qualcosa va storto, prima di mandarmi a quel paese, prova ad aprire direttamente http://iginomanfre.it/hls7/hls7.m3u8 con vlc (versione 2.2.6 o successiva): apri flusso...

For further informations take a look to this file: it is related to the hel of a mpeg4 wrapper containing h264 elementary stream, but it is the same thing.
If something goes bad, before damning me, please try to recall directly http://iginomanfre.it/hls7/hls7.m3u8 with vlc (version 2.2.6 or later): open stream...


Maybe can be interesting to browse this article where may be compared the two ways of streaming


In realta' non c'e' nessuno che proibisce nulla a nessunaltro: puoi stream-are come vuoi ma il progetto della tua pagina deve accordarsi con le possibilita' rese disponibili dai browser. Quindi - se tu vuoi usare uno dei piu' usati (oserei dire standard) - devi pensare la pagina come loro ti permettono.

Really no-one forbids anything to anyother: you can stream as you want but your page design must match with the possibilities made available by the browsers, then - if you want use one of the most used standard browser - you must conceive the page as they let you.

La nuova release 52.0 di FireFox non supporta piu' plug-ins (a parte Flash, Silverlight, Java, Acrobat) (VLC Q&A).
Di conseguenza, di che risorse pensi avremmo bisogno di raccogliere per sviluppare un plug-in affidabile sia per Chrome che per Firefox? Io penso che lo dovremmo lanciare!
Il plugin e' un importante elemento di VLC. Perdere i plug.in per Chrome e' stato duro, ma ora perdere anche quello per Firefox e' stato . VLC e' un grande esempio di comunita' di sviluppatori che deve essere mantenuta e a cui non deve poter perdere componenti come i plugin. Penso al dispiacere per tutti gli sviluppatori. (VLC Q&A,2).

The new Release 52.0 of FireFox is dropping support for plug-ins (except for Flash. Silverlight, Java, Acrobat) (VLC Q&A).
As a ball park, what funding do you think will be needed to be raised to ensure mature plugins for both Chrome and Firefox? I think we should we crowd fund this!
The plugin is an important element of VLC. Losing the Chrome plugin was difficult and now to lose Firefox is . VLC is a great example of a community developed app that must be maintained and not lose components such as the plugin. I felt the pain of all the original developers. (VLC Q&A,2).


This is the most diffused way to stream all around the world: Youtube like (vimeo or other are similar)

Do not forget: you are allowed to exist only if you consume
This video is available also in English as well in many other languages.

The next video comes from Youtube, Google empire. It is embedded through the following call

<iframe width="400" height="225" src="https://www.youtube.com/embed/oktdSO_J3Vc" frameborder="0" allowfullscreen> </iframe> It is played through the browser capabilities, that can play also webm.
The following two videos are the same in terms of content but a completely different story.


This comes from youtube servers through the following call:

<iframe width="640" height="218" src="https://www.youtube.com/embed/7FvCaQhh1Z0" frameborder="0" allowfullscreen> </iframe>
Really behind this address Youtube streams this video in 7 times for formats and codecs:

This one from this server through the html following video markup
<video src="../video/google_pizza.mp4" type="video/mp4" poster="../jpg/google pizza poster.jpg" width="640" height="218" controls> </video>
But this one is one only file stored in that directory that apache streams on request.

Google make this video available in many formats and bitrate
Google rende disponibile questo video in diversi formati e bitrate

While this one comes from this server in one only resolution and bitrate in progressive download


At left a html5 video instruction that realize a practical old progressive download video embedded video. Video is downloaded locally before and while playing. This video is on the server, is mute is 19 minutes long and it is highly compressed in h264 (29 MB 480x270). Crosshairing the pointer two timelines are showns: the blue one is the current playing position while in gray is hown the latest downloaded point
Positioning is quite fast, but in any case is not fast as HLS where every single video chunk is pointed by the metafile.
Practically progressive download is the only native way to embed video by browser characteristics.

<video width="480" height="270" controls> <source src="../video/tevere_200.mp4" type="video/mp4"> </video>

A sinistra l'applicazione della istruzione video dell'html5 che realizza il vecchio progressive download embedded video. Il video e' scaricato localmente prima e mentre viene riprodotto. Questo video e' sul server, e' muto, dura 19 minuti, e fortemente compresso in h264 (29 MB 480x270). Attraversando il video col mouse vengono mostrate due timeline: in blu la posizione corrente, in grigio l'ultimo frame scaricato.
Il posizionamento e' abbastanza veloce, ma in ogni caso non come in HLS dove ogni singolo segmentino video e' puntato dal metafile.
Praticamente il progressive download e' l'unico modo nativo html di inserire video in corso testo grazie alle capacita' del browser.


Il vantaggio e' che si vede anche sul cellulare (qui sul mio note2)
The advantage is that can be seen also on smartphones


Come dicevo all'inizio, in realta' nessuno impedisce nulla a nessun altro: tu puoi stream-mare come vuoi, ma la tua pagina deve accordarsi con quanto reso disponibile dai browser, quindi - se vuoi usare quelli piu' usati e standard - devi concepirla come ti e' permesso.

Infatti da questo sito io sto continuando a stream-mare in mpeg2, h264 e anche h265 wrapp-ati principalmente in Transport Stream o in HLS (vedi questa lista), e questi stream possono essere visionati con un player (come media player o videolan, eventualmente ricompilati in forma di app appositamente realizzata) ma non puoi inserirli in un browser perche' questi non ammettono piu' plug-in video (salvo quelli commerciali). Infine puoi utilizzare una versione obsoleta di un browser open source che supporti ancora il plug-in video di VLC.

In questa pagina utilizzo iframe per richiamare una applicazione esterna (io ho associato vlc) per aprire un video. iframe e' abbastanza pericolosa perche' puo' richiamare qualsiasi cosa, compresi malware o virus. Ma per quanto ne so - escluso il progressive download e dopo la eliminazione dei plug-in video - e' l'unico modo di richiamare un video all'interno di una pagina.

As I said at the beginning, really no-one forbids anything to anyother: you can stream as you want but your page design must match with the possibilities made available by the browsers, then - if you want use one of the most used standard browser - you must conceive the page as they let you.

In fact from this site I'm continuing to stream mpeg2, h264 and even h265 wrapped mainly in transport stream or in HLS (see this list), and these stream can be loaded with a stream viewer (such as media player or videolan) or a stand alone app but you cannot see these video within a browser because no plug-in (excluding commercial ones) are any more supported for this purpose. Last you can use an obsolete version of an open source browser at the time it still support VLC video plug.in

In this page I use iframe to recall an external app (I choose vlc) to open the video. iframe is quite dangerous because can recall everything, including malware or virus. But for my knowledge - excluding progressive download and after video plug-in execution - is the only way to recall a video within a page .