[Gulli] Resoconto riunione martedi 14.02.06

[Carlo ROATTA]

Ignorando svenevoli ricorrenze para-commerciali, il 14 Febbraio un pugno
di duri si è riunito nella stanza Trio dell'ITIS, per ascoltare il verbo
del Guargua che oggi incantava le folle discettando sui massimi sistemi
multimediali.

Di seguito, gli appunti veloci, presi "on-line" (mi si perdonino errori
minori, avendo privilegiato la rapidità di presentazione alla
correttezza semantica).

CR
---

Questa prima sessione, che si propone un seguito il prossimo martedì, è
centrata sui* CODEC VIDEO*.

L'immagine tipica per le TV è di 352x288 pixel (sistema PAL).
Se per ognuno dei pixel si impiegano 24 bit di colore, si raggiunge una
dimensione di 304.128 byte per fotogramma.

In un flusso video, senza compressione, sarebbero richiesti questi
throughput:
1. in un video "di qualità VHS", 352x288 pixel per frame, 25 frame al
secondo, 12 bit per pixel richiedono un totale di 30,4 Mbps;
2. in un video "tipo DVD", 504x576 pixel per frame comportano un flusso
di 121,7 Mbps

Come paragone, si noti come il più moderno hd arrivi a 150 Mbps per il
trasferimento dati.

Si impiega quindi la *compressione*, per ridurre il throughput
necessario per realizzare un filmato video.
I codec di compressione sono definiti da un gruppo di standardizzazione,
il Motion Picture Expert Group (MPEG).

I *principali codec* sono:
- per l'audio: mp1, mp2 e mp3
- per il video: mpeg1 (per Video CD), _mpeg2_ (per i DVD ed il dvb, tipo
il digitale terrestre), _mpeg4_ (su codec proprietari, come divx, o
liberi, come xvid)

Per l'audio, il più famoso è il _codec mp3_, sviluppato dal Fraunhofer
Institut; codec proprietario, permette nelle ultime versioni di
introdurre dei /watermark /che marchiano il file, per limitare le
"diffusioni illeggittime" (impropriamente chiamate "copie pirata"). In
ambiente libero, si preferisce il _codec ogg-vorbis_, di resa migliore
ma, soprattutto, svincolato da vincoli di impiego.

Per il video, il _codec mpeg4_, ad esempio, le realizzazioni divx e xvid
posseggono estensioni proprie che, pur soddisfacendo lo standard mpeg4
di riferimento, le rendono tra loro non pienamente compatibili. Vedendo
un film con il codec sbagliato, può accadere di riscontrare errori
cromatici (es: film "verde"), o difettose ricostruzioni dei frame
("quadrati grossi", con bassa risoluzione).

Per riuscire a comprimere un frame video, si passa dalla codifica RGB
(che riserva, tipicamente, 8 bit per ciascuno dei tre colori Red, Green
e Blue) ad una _codifica YUV_ (12 bit per pixel, anzichè 24, perchè 8
sono riservati alla luminanza Y, due al Chroma Rosso, due al Chroma
Blue). In pratica, si sfrutta il fatto che l'occhio umano è molto più
sensibile alle variazioni di luminanza (sfumatura bianco-nero), che non
a quelle cromatiche; si approssima quindi con più attenzione la
luminanza, mentre ci si permette di usare meno bit per il colore.

Per un immagine da comprimere, questa viene scomposta in _blocchi di
16x16 bit_; tale valore dev'essere tenuto a mente, quanto si intenda
definire la dimensione del video: inutile impiegare valori che non siano
multipli esatti di 16 (es: scegliere 352x288 bit per frame).

Su ogni blocco 16x16, viene applicata la _DCT (Discrete Cosine
Transform)_ che opera su gruppi di 4 bit, ottenendo una matrice 8x8. Su
questa matrice si opera un "rimescolamento" delle caselle, provvedendo
ad accentrare su uno spigolo quelle più pesanti (come valori YUV) ed
eliminando le caselle più "leggere" (con contenuto informativo, quindi,
trascurabile).

La semplificazione così ottenuta mantiene ancora gran parte del
contenuto informativo originario, ma alleggerisce notevolmente il carico
di bit necessari per ogni frame. Tipicamente, si riduce il carico al 15%
dell'originale, senza decadimento granchè apprezzabile dall'occhio umano.

Come esempio pratico, si veda un'*immagine JPEG*, rispetto all'originale
BMP: per una foto, si ottiene una riduzione delle dimensioni senza
grosse perdite di qualità (per una foto di un testo, i "troncamenti"
possono essere già più avvertibili).

In un *flusso video*, agli accorgimenti sopra descritti si aggiunge un
_modello "predittivo" del movimento_, preferendo la descrizione della
differenza tra fotogrammi piuttosto che quella del fotogramma
successivo. Con fotogrammi simili, la differenza è molto più economica
da descrivere e, quindi, da comprimere. Per oggetti che si spostano,
rispetto ai frame precedenti, si descrive il "vettore movimento". Si
complica l'algoritmo di descrizione delle immagini, ma si risparmia sul
numero di bit da trasmettere (ecco perchè, sui PC, ci possono essere
decoder hardware dedicati, per alleggerire la CPU).

Nella serie di *frame di un video*, distinguiamo:
- _I-Frame_ (Intra-Frame o Key-Frame): codificati come un'immagine JPEG,
senza riferimento ai frames vicini
- _Delta-Frame_ o Inter-Frame, a loro volta distinti in:
     -- P-Frame(Predicted Frame): codificati in funzione dei frame
precedenti; codifica con algoritmo pesante, ma con risparmio di bit
    -- B-Frame (Bidirectional Frame): codificato in funzione del frame
precedente e di quello successivo: necessari 1/4 di bit rispetto ad un
P-Frame

---
ulteriori approfondimenti sulle slide prodotte dal Guarguaglini. Provare
sotto:
http://www.colognole.org/gulli/html/modules/PDdownloads/singlefile.php?cid=3&lid=12
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: http://lists.linux.it/pipermail/gulli/attachments/20060214/08f4c29a/attachment.htm