Dalla teoria matematica...all'uso di tutti i giorni.
In questo articolo analizzerò le caratteristiche della compressione mpeg, per cercare di descrivere la funzione di ciascuno degli innumerevoli parametri presenti negli encoder: mi riferirò al freeware tmpeg mpeg encoder (scaricabile direttamente dal mio sito tmpeg), ma ovviamente i principi sono universalmente validi per ogni sw di codifica mpeg.
Una piccola osservazione : ho notato come anche in documenti " ufficiali " ( vedi l' International Standard 13818-2 che descrive l'implementazione dell' mpeg2 video) pur di mantenere uno stile di scrittura " elegante" non manca di frasi di dubbia interpretazione: pertanto conscio che certe questioni sono descrivibili con correttezza solo con formule matematiche, schemi o tabelle, utilizzerò spesso ripetizioni " poco eleganti" ma che spero riescano a chiarire le complesse questioni in esame.
La seconda osservazione è che per capire a fondo pregi e difetti dell' mpeg occorre avere chiara la sua complessa implementazione; per far ciò occorre approfondire alcune questioni che a prima vista possono sembrare eccessivamente " tecniche"; l'alternativa è modificare più o meno ad istinto i parametri disponibili o utilizzare unicamente i preset sempre disponibili negli encoder. Ovviamente chiarito il funzionamento " teorico" dell' mpeg è fondamentale fare test e valutare " sul campo" l'influenza dei diversi parametri e l'implementazione del sw che si utilizza.
Per la visualizzazione di questo articolo è consigliata almeno la risoluzione 1024*768, anche se la visualizzazione ottimale la si ha a 1152*864. In tutti i casi consiglio l'utilizzo della visualizzazione a tutto schermo (F 11 per Internet Explorer) e nel caso di risoluzione 800*600 di utilizzare l'opzione visualizza/carattere/molto piccolo (sempre per I. Explorer).
Buona lettura !!
MPEG (Moving Picture Experts Group, gruppo di esperti nelle immagini in movimento) è nato nel 1988 come un gruppo di lavoro all'interno dell'ISO/IEC con l'intento di definire uno standard di compressione di segnali digitali audio-video. L'MPEG1 è formalmente nato nell' agosto del 1993 con la pubblicazione delle specifiche in 3 documenti (ISO/IEC 11172-1 11172-2 11172-3 Coding of moving pictures and associated audio for digital storage media at up to about 1,5 Mbit/s ).
Fondamentalmente si era realizzato una specie di miracolo: con il bit rate del CD Audio (1,5 Mbit/s = 187,5 KByte/s) si era riusciti a codificare audio compresso di qualità CD e ad aggiungere in più del video caratterizzato da una qualità comparabile a quella della videocassetta (migliore per definizione e pulizia di colori, leggermente in difficoltà nelle scene con più movimento). Se oggi dopo 7 anni, che nel settore dell'informatica sono un' eternità, tale risultato ci può apparire quasi banale, in realtà nasconde un progetto di indiscutibile qualità, nato grazie ai migliori cervelli di matematici e ingegneri, MOLTI DEI QUALI ITALIANI. Algoritmi che oggi sono alla base di ogni video digitale, sono nati durante quegli anni: un esempio tra tutti , la 8x8 Discrete Cosine Trasform (DCT), usata oggi nel DVD, DV, Jpeg, M-jpeg,...è stata formalizzata (IEEE Std 1180-1990) il 6 Dicembre 1990.
Gli ingegneri italiani sono stati di fatto i primi a formalizzare i concetti di ridondanza spaziale e ridondanza temporale (la base della compressione mpeg 1 e 2), progettando una trasmissione in video digitale compresso per i mondiali di calcio del 1990.
L' MPEG1 è in realtà uno
standard implementabile con una infinità di combinazioni e quindi compromessi
tra qualità e bit rate: la sua nascita è legata ad una di queste
implementazioni, l' ultranoto formato VCD (Video CD).
Tale formato nasce, sotto la spinta della Philips, che promuove la produzione di
Film Hollywoodiani in VCD e commercia il famoso player CDi, un clamoroso fiasco
commerciale. Il VCD riscuote successo solamente nei paesi asiatici: ancora oggi
le vendite superano abbondantemente quelle della videocassetta.
I motivi dell'insuccesso sono tanti; credo che il principale risiede nella
fretta della Philips a commercializzare tale formato che se implementato anche
un anno dopo avrebbe potuto usufruire di lettori cd a doppia velocità che con
375KByte/s avrebbero garantito una migliore qualità. La bocciatura degli video
amatori, amanti della alta tecnologia, che avevano come riferimento l'analogico
Laser disk, ha di fatto bloccato il formato.
Ovviamente non tutti i mali vengono per nuocere e, dalle ceneri del VCD è nato il DVD: siamo chiaramente su tutt'altri livelli qualitativi.
L'MPEG2 nasce per migliorare la qualità dell'MPEG1, pur mantenendone il 99% delle caratteristiche. L'idea di un nuovo standard nasce nel 1990, a due anni dalla nascita del gruppo MPEG, e 3 anni prima della formalizzazione dell' MPEG1 (1993). Le specifiche sono state completate nel Novembre 1993, approvate come ISO/IEC 13818-1 ,2 ,3 e 4 l'11 e il 13 novembre 1994 : il testo finale è stato pubblicato nel 1995. Ricordo che ISO è l'abbreviazione di International Organisation for Standardisation mentre IEC sta per International Electrotechnical Commission. Le 4 parti della documentazione ISO/IEC 13818 trattano rispettivamente la struttura multiplexiong dell'mpeg, la parte video, quella audio e le caratteristiche del bitstream da garantire nelle delicate fasi di test.
Una lista degli standard che utilizzano l' mpeg la trovate nell'articolo La Babele dei formati:DVD, MiniDVD, MicroDVD, DivX;-), VCD, SVCD, XVCD
Prima di iniziare, senza offendere nessuno, una banale premessa: l'encoder è il software (Sw) o Hardware (Hw) che partendo da un video (normalmente in formato AVI o Quick Time nel caso degli encoder sw) lo codifica in formato mpeg: viceversa il decoder è il Sw o Hw che partendo da un file in formato mpeg lo trasforma in un filmato visualizzabile: di fatto trasforma il video compresso (mpeg) in video non compresso.
L'mpeg è un formato di compressione in cui è lasciata grande libertà nella scelta dei parametri di codifica: i principali riguardano il bit rate video ( in Kbit/s) , il tipo di codifica ( a bit rate video costante o variabile) oltre che ovviamente la risoluzione: al contraria per l'audio i parametri in gioco sono limitati a poche ragionevoli possibilità.
E' ovvio che a parità di tutti gli altri parametri ( primo tra tutti la qualità dell'encoder) a maggiore bit rate video corrisponde migliore qualità e ovviamente maggiore spazio occupato.
L'mpeg è un formato di compressione a perdita di informazione: anche nel caso di compressioni di qualità il video mpeg è intrinsecamente diverso dal video non compresso; il fine dello standard è quello mascherare il più possibile gli effetti della compressione sfruttando quelli che sono i limiti percettivi dell'utente.
Ricordo che 1 KByte/s= (1 Kbit/s) / 8: pertanto un bit rate video es. di 3000 kbit/s = 375 KByte/s per cui un minuto di video occuperà 60 sec * 375KByte/s = 22500 Kbyte= 21.97 MByte (22500/1024), praticamente 30 Mega. ( per passare dai Kbyte ai Mbyte occorre dividere per 1024 e non per 1000; per questo 22500 kByte/ 1024= 21.97 MB).
Ecco alcune formule che possono essere utili (sono banalmente ricavabili)
| DIMENSIONE
(DIM)
in MBYTE di video avente bitrate (Bit) espresso in Kbits/s e durata in minuti (Min) |
| DIM= Bit * Min /136.53 |
dove 1024*8/60=136.53 |
es.
bitrate 3000 Kbit/s , durata 20 minuti
DIM=3000*20/136.53=439.46 Mbyte = 450 011 Kbyte (439.46 *1024 = 450011 )
Ovviamente per passare da Mbyte a Kbyte occorre moltiplicare per 1024, come visto.
| DIMENSIONE
(DIM)
in MBYTE di video avente bitrate (Bit) espresso in Kbits/s e durata in secondi (Sec) |
| DIM= Bit * Sec / 8192 |
dove 1024*8 = 8192 |
es.
bitrate 3000 Kbit/s , durata 15 secondi
DIM=3000*15/8192=5.49 Mbyte = 5625 Kbyte (5.49 *1024 = 5625 )
Solo nel caso di bit rate costante ( tipicamente nel caso di mpeg1 ) è possibile sapere il bit rate video esatto: nei casi di bit rate variabile è solo possibile fare delle stime conoscendo il bit rate video medio.
Nel caso è
presente pure il l'audio occorre sommare al bitrate video quello audio:
Bit = bitrate video (kbits/s)
+ bitrate audio (Kbit/s)
I tipici bit rate audio sono:
224 kbit/s
(mpeg layer II stereo 44100 byte/s)
384 o 448 kbit/s per audio ac3 5.1
192 o 256 kbit/s per audio ac3 Stereo surround
Riguardo lo spazio disponibile sui supporti CDR, CDRW vi rimando alla FAQ n 6.
Sia l'Mpeg 1 che 2 ( in seguito vedremo le differenze) considerano un filmato video come una serie di immagini (fotografie) in successione.
Tali immagini sono ovviamente digitali, cioè descritte da numeri secondo delle regole semplici e ovviamente formalizzate; di tali immagini occorre definire:
- la dimensione in pixel (size) - il
rapporto larghezza altezza con cui il video dovrà - il frame rate -il
formato interallacciato o progressivo con cui - il
campionamento dei colori - profile e level - E'
ovviamente sottinteso che qui in Italia
|
 |
Gli altri parametri presenti nella sezione configure/video di tmpeg li analizzerò in seguito in coerenza con l'ordine con cui tratterò le diverse questioni.
Dimensione in pixel: size
Ciascuna immagine è digitalizzata cioè trasformata in un insieme di punti per ciascuno dei quali si definisce il colore tramite un numero. Per ogni immagine si devono definire il numero di pixel orizzontali (pixel per riga) e il numero di pixel verticali (il numero di di righe orizzontali). Si parla anche di risoluzione orizzontale e verticale.
Una immagine 720*576 ad esempio è formata da 576 righe orizzontali ciascuna formata da 720 punti.
Le risoluzioni orizzontali concesse dall'mpeg sono quelle multiple di 16 : pertanto se è concessa la 352*288 non lo è ad esempio la 353*288 ( 352 è multiplo di 16, 353 no)
Le risoluzioni più usate sono:
352*288
tipica dell' XVCD, mpeg1
352*576 usata ad esempio per gli per SVCD mpeg2 non standard
480*576 è lo standard SVCD mpeg2
720*576 usata praticamente da tutti i DVD commerciali.
Rapporto dimensioni: aspect ratio
La cosa importante è che all'interno del filmato mpeg è indicato al decoder (software o hardware) con quali rapporto di dimensioni tale video deve essere presentato. In tmpeg il parametro da settare è aspect ratio nella sezione configure/video. Ovviamente non ha senso dire al decoder "trasforma l'immagine in un formato pari a 15*18 centimetri", ma ha senso indicare il rapporto larghezza altezza dell'immagine ; se si dice al decoder di trasformare in una immagine con il formato 4:3 (4/3=1.33) allora se visualizzata su un piccolo tv questa ad esempio avrà dimensioni 26.6* 20 cm , su un maxischermo 1.33*1 metro!!!
Un approfondimento sui diversi formati video e in particolare sul video anamorfico lo trovate sull'articolo: I formati video:4/3,anamorfico 16/9 ,1.33:1, letterbox 1.85:1, widescreen 2.35:1,.........Teoria, formule, codifica con Tmpeg, FlaskMpeg, e il Panasonic encoder.Il vero aspect ratio dei DVD in commercio.
Consideriamo per esempio un mpeg avente dimensioni 352*576 con provenienza digitalizzazione di un video PAL visualizzato su un tv 4:3 o sul monitor del pc: il decoder prima ricaverà le immagini decodificando i 352*576 pixel da mpeg a video non compresso (successioni di immagini) e poi a secondo dell' aspect ratio ridimensionerà tale video. Ovviamente la qualità con cui avviene il ridimensionamento dipende dalla qualità del SW o HW di decodifica: ci sono dei filtri che permettono ad esempio l'attenuazione delle seghettature o di discontinuità.
Vediamo come un player perfettamente compatibile con lo standard dovrebbe ridimensionare tale video 352*576:
| Aspect ratio 1:1
VGA
Viene mantenuto
il video |
 |
| Aspect ratio 4:3 Display |  |
| Aspect ratio 16:9 Display |  |
| Aspect ratio 2.11:1 Display |  |
Da quanto visto nell'esempio è ovvio che la scelta dell'aspect ratio è legata dal formato del video originale: nel caso appena visto è ovvio che occorre scegliere l'aspect ratio 4:3.
Nel caso di conversione con provenienza video DVD ho solo due possibili casi: video non anamorfico a cui devo legare l'aspect ratio 4:3 e video anamorfico ( che nel DVD è sempre e solo video anamorfico 16/9) a cui devo legare aspect ratio 16:9. Ciò vale ANCHE NEL CASO DI FILM ANAMORFICO IN FORMATO 2.11:1 in cui la distorsione verticale è sempre realizzata con un fattore 16/9: non a caso in un film DVD anamorfico 2.11:1 nei 720*576 pixel del frame ci sono delle righe orizzontali nere.
Da segnalare che non tutti i decoder mpeg riconoscono l'aspect ratio !! Ad esempio l'opzione full screen del Windows Media player 6.4 è in grado di riconoscere tale parametro nel caso di video mpeg 1; al contrario sw quali Windvd2000 o PowerDVD 2.55 non lo riconoscono e pertanto il ridimensionamento del video va fatto manualmente lavorando in finestra.
Praticamente tutti i player sw ignorano l'aspect ratio nella visualizzazione a finestra e utilizzano una finestra con aspect ratio pari alla risoluzione dell' mpeg:
| nel caso dell'esempio visualizzeranno | |
Se si utilizza il Windows media player v 6.4 si possono forzare le dimensioni della finestra , ridimensionandola mantenendo premuto il tasto shift.
Frame rate
Indica banalmente il numero di fotogrammi al secondo con cui sarà visualizzati l'mpeg: nel caso di video Pal tale valore è 25 fps (frame al secondo).
Interallacciato o progressivo: interlaced
Utilizzerò l'analisi di tale delicata opzione per chiarire molte delle questioni generali relative all'mpeg: pertanto NON PASSATE AL PARAGRAFO SUCCESSIVO !!!
L' opzione è valida solo per l'mpeg 2 poichè l'mpeg1 non è in grado di gestire il video interallacciato e pertanto è come se tale opzione fosse sempre disattivata.
Per capire correttamente questo punto è fondamentale avere le idee chiare sul video interallacciato: vi rimando all'articolo Il video nel formato Pal: interallacciamento e video digitale per approfondire la questione. Ricordo, come ripetuto più volte nell'articolo, che qualsiasi video proveniente da telecamera o videocamera è interallacciato (ad eccezione delle ultimissime videocamere progressive), mentre i video provenienti da telecine ( origine pellicola) sono progressivi: entrambi questi video quando sono visualizzati sui televisori attuali sono SEMPRE in modalità interallacciata: le uniche eccezioni sono i player sw per pc che visualizzano film DVD su monitor , le future accoppiate DVD player progressivo + televisore progressivo ed alcuni costosissimi videoproiettori.
In breve consideriamo il caso di video Pal 720*576 usato per i DVD (questo discorso vale per ogni video xxx*576 cioè con risoluzione 576 righe): i 25 frame 720*576 in tutti i casi saranno visualizzati sui normali televisori in maniera interallacciata, visualizzando prima le righe pari, poi le dispari a distanza di 1/50 di secondo.
Nessun televisore o encoder può sapere cosa quel frame 720*576 in realtà contiene : esistono due possibilità
1) il frame 720*576 contiene al suo interno video interallacciato, cioè due immagini 720*288 provenienti da istanti distanti 1/50 di secondo che sono stati inseriti nelle righe pari e dispari. A tutti gli effetti il video 720*576 25fps lo si può vedere come video 720*288 50 semiquadri al secondo. (è quello che poi farà il sw di encoding se è inserita l'opzione interallacciato (interlaced)). Il singolo frame 720*576 contiene le tipiche discontinuità del video interallacciato in corrispondenza dei particolari che nei due istanti si sono mossi.
2) il frame 720*576 contiene al suo interno video progressivo ( è il tipico caso dei film su DVD) in cui il filmato è in realtà la successione di 25 "fotografie" al secondo provenienti da istanti distanti 1/25 di secondo: in tal caso il frame 720*576 non conterrà MAI le discontinuità viste poiché deriva dalla " fotografia" di un solo istante e non dalla composizione di due immagini provenienti da istanti successivi.
Consideriamo il caso 1 in cui il frame 720*576 contiene al suo interno video interallacciato
|
E'
il caso ad esempio |
 |
(per problemi di spazio ho inserito solo un ritaglio del frame 720*576:in alto e in basso ci sono delle bande nere che completano il frame)
|
........che
altro non è che la |
|
|
semiquadro 1 (720*288) |
 |
|
semiquadro 2 (720*288) |
 |
In questo esempio è evidente che nei due istanti successivi (di 1/50 di secondo) c'è un cambio di ripresa che fa si che i due semiquadri sono COMPLETAMENTE DIVERSI.
|
Se
considero
|
 |
ho che nei due istanti successivi (di 1/50 di secondo) c'è un leggero movimento dei personaggi che fa si che nel frame 720*576 , somma dei due semiquadri 3 e 4 ci sono le tipiche linee di discontinuità.
Ovviamente i semiquadri 3 e 4 sono tra loro molto simili con piccolissime differenze
|
semiquadro 3 (720*288) |
|
|
semiquadro 4 (720*288) |
 |
Per la cronaca le immagini vengono dal film Titanic che in realtà come tutti i film è realizzato in progressivo: dovrei con un piccolo sforzo mentale pensare ad un Titanic girato con una telecamera e non su pellicola: nella realtà il frame è interallacciato a causa della digitalizazione del video con la Matrox Marvel g200 che usa una convenzione dei frame opposta alla Creative DVD dxr-2 da cui proviene il video.
2) La seconda possibilità è che il frame 720*576 provenga da video progressivo ( è il tipico caso dei film su DVD): in tal caso,per quanto visto, il frame non conterrà MAI le discontinuità del video interallacciato poiché deriva dalla "fotografia" di un solo istante. Qualsiasi fotografia pensate rappresenta un frame progressivo.
Chiarito questo entra in gioco l'mpeg che sfrutta fondamentalmente 2 caratteristiche dei filmati video: la ridondanza spaziale e la ridondanza temporale.
Frequenze video, ridondanza spaziale e temporale
Prima di tutto si deve chiarire il concetto di frequenza video: nel caso dell'audio le alte frequenze sono i suoni acuti (il verso dei pipistrelli, lo stridio di un coltello su di un piatto....) mentre le basse frequenze sono i suoni gravi (il rombo di un tuono o le note gravi di un contrabbasso). Nel video le basse frequenze corrispondono ai colori uniformi (un cielo sereno senza nubi , il colore di una automobile) mentre le alte frequenze video corrispondono alle immagini frastagliate tipo le foglie di un albero visto da lontano, i quadrettini minuti di una giacca, o i caratteri minuti della pagina di un giornale).
Chiaramente ciascuna immagine in ogni sua zona ha particolari con alte, medie, basse frequenze video ed è altrettanto ovvio che il concetto di alte e basse lo inserisco per comodità di esposizione: nell'Mpeg ciò che trasforma un pezzo di immagine nel suo contenuto di frequenza è la DCT (Discrete Cosine Trasform) in cui esistono valori numerici e non concetti come alto o basso. Ci ritorneremo dopo quando si parlerà di matrici di quantizzazione.
Nel momento in cui l'mpeg è una compressione video di tipo " No loseless" (a perdita di informazione), chi ha inventato il formato si è chiesto quale informazione se scartata o memorizzata con maggior approssimazione causa il minor fastidio all'occhio : la risposta è " le alte frequenze video" ( cosa assolutamente non vera per l'audio).
In pratica un cielo azzurro in cui non descrivo bene le basse frequenze video mi apparirà come suddiviso in blocchetti e con fasce di colori che invece di sfumare variano " a scatti ". Al contrario per un albero visto sullo sfondo in cui a causa di un " cattivo trattamento" delle alte frequenze è visualizzato leggermente meno dettagliato sarà molto più difficile accorgersi degli artefatti. Se poi l'immagine è in movimento (non l'albero che cammina ma una carrellata della cinepresa... battutaccia ! ) allora tali artefatti sulle alte frequenze saranno del tutto coperti dalla incapacità del nostro occhio e del nostro cervello ad accorgerci della cosa.
Questa maggior attenzione del nostro occhio alle basse frequenze video che se trattate male ci portano ad accorgerci della presenza di artefatti e il fatto che la natura è fondamentalmente continua (i colori uniformi sono molto più frequenti degli oggetti con tantissimi dettagli) hanno fatto sì che l'mpeg ha un migliore riguardo delle basse frequenze video piuttosto che le alte.
In termini corretti l'mpeg sfrutta quella che è detta la RIDONDANZA SPAZIALE dell' informazione video che matematicamente si può riassumere "se un pixel in un certo frame ha un certo colore, nei pixel vicini e nello stesso frame, con buona probabilità avrà un colore simile"; basta pensare al colore della maggior parte degli oggetti: dal cielo, al colore di una automobile.... al colore del case dei nostri computer. Non è ovviamente un caso che si parla di buona probabilità e non di certezza !!
Questa caratteristica la si trova nella quantizzazione dei macroblocchi, che approfondiremo in seguito: per adesso basta sapere che l'encoder cerca ridondanza spaziale (uniformità nei colori) in blocchetti 8*8 pixel e dove può elimina le alte frequenze.
L'altra caratteristica dei video in movimento prontamente sfruttata nell'mpeg è la RIDONDANZA TEMPORALE dell' informazione video "se un pixel in un certo frame ha un certo colore, lo stesso pixel o quelli vicini , nei fotogrammi successivi o precedenti con buona probabilità avranno un colore simile" : basta pensare ad una telecamera fissa che inquadra il volto di una persona mentre parla o alla partita di calcio in cui, nel caso sempre di ripresa fissa, le parti del terreno in cui non c'è nessun giocatore rimangono praticamente identiche tra fotogrammi successivi e viceversa sempre tra fotogrammi successivi ciascun giocatore occuperà pixel vicini ( a meno di teletrasporto Trekkiano ! ).
Questa caratteristica la si trova nella creazione dei vettori di movimento e nella compensazione del moto che approfondiremo in seguito: per adesso basta sapere che l'encoder cerca ridondanza temporale (similitudine) tra blocchetti 16*16 pixel e dove può memorizza la differenza tra l'iesimo blocchetto del frame che sta comprimendo con blocchetti simili presenti in frame precedenti e/o successivi.
Ritornando al video interallacciato , questo ha la INCREDIBILE CAPACITA' di annullare completamente i due principi fondamentali su cui è basato l'mpeg : le ridondanze spaziali e temporali. Vediamo subito il perché.
Consideriamo il caso in cui due frame 720*576 provenienti da video interallacciato (telecamera o videocamera..... o l'ipotetico Titanic girato con la telecamera)
Ho 3 possibilità
1) Mpeg2 - opzione interlaced selezionata 2) Mpeg2 - opzione interlaced deselezionata 3)
Mpeg1 che non ha la possibilità di scelta |
|
Considero il caso 2) Mpeg2 - opzione interlaced deselezionata (o il caso 3) mpeg1) con il video che è chiaramente di origine interallacciato. Quindi, scusate se mi ripeto, comprimo video interallacciato con codifica di tipo non interallacciato .
Cosa significa ? Si ha che il sw di compressione considererà ( nel nostro esempio) unicamente 2 frame (quadri) e non 4 semiquadri con risultati scadenti. Infatti:
|
frame 1 |
|
|
frame 2 |
|
Il frame 1)
contraddice del tutto il principio di ridondanza spaziale "se un
pixel in un certo frame ha un certo colore, nei pixel vicini, con buona
probabilità avrà un colore simile"; due righe successive in questo
caso sono del tutto diverse!
La conseguenza è che dopo la compressione, poiché per come è fatto l'mpeg
si cercheranno di eliminare le alte frequenze , si avrà una orribile marmellata
sfocata che mischia in maniera più o meno indecente le righe. Il televisore che
come sempre disegnerà prima le righe pari e poi le dispari disegnerà di due
semiquadri sporchissimi poiché nelle righe pari ci sarà la "
marmellata" prodotta dalle dispari e viceversa. Il risultato finale è un
video pieno di rumore ovunque!
Nel frame 2) ho un discorso analogo che vale solo dove ho le linee seghettate e cioè nei particolari in movimento: il risultato è che visualizzando il filmato avrò una buona qualità nei punti in cui ho video statico mentre nei particolari in movimento avrò un rumore video che me li fa apparire sfocati, innaturali e con i colori confusi.
E' ovvio che per ovviare al problema ed avere video di qualità dovrei ridurre la compressione del video, cosa che mi impedirebbe di usare i tipici bit rate dell' mpeg per i video 720*576 ( 5000-7000 Kbit/s): dovrei elevare il bit rate anche di 3-4 volte tanto.
Ma come visto l'mpeg comprime anche sfruttando la RIDONDANZA TEMPORALE dell' informazione video "se un pixel in un certo frame ha un certo colore, lo stesso pixel o quelli vicini , nei fotogrammi successivi o precedenti con buona probabilità avranno un colore simile" . Nel caso dei due frami 1 e 2 ridondanza temporale, che permette di risparmiare bit rate cercando la similitudine tra frame successivi di fatto non esiste. La totale seghettatura del frame 1 impedisce il riconoscimento di ogni similitudine.
A prova di quanto detto basta codificare il video interallacciato 720*576 ( o in generale xxx*576) proveniente ad esempio da una videocamera e comprimerlo con bit rate di 4000-5000 kbit/s o in mpeg 1 o in mpeg2 non interallacciato: tutti i particolari in movimento saranno caratterizzati da una scarsissima qualità !!!
Nel caso 1) Mpeg2 - opzione interlaced selezionata le cose cambiano del tutto: in pratica il sw di compressione avrà in memoria sia i frame 1 e 2 sia i semiquadri 1,2,3,4: tra tutti questi liberamente (sempre nella sintassi che vedremo dopo) cercherà ridondanza spaziale e temporale che oculatamente gli faranno eliminare informazione inutile ( nel caso di ridondanza spaziale verranno in parte eliminate le alte frequenze e nel caso di ridondanza temporale si sfrutterà la codifica delle differenze tra blocchetti simili, come vedremo).
|
frame 1 |
|
|
frame 2 |
|
|
semiquadro
1 |
|
|
semiquadro
2 |
|
|
semiquadro
3
|
|
|
semiquadro
4 |
|
E' evidente che non riuscirà mai a trovare ridondanza spaziale nel frame 1 ( le alte frequenze in blocchetti 8*8 sono elevatissime a causa delle righe discontinue) mentre certamente la troverà nelle zone non in movimento ( non seghettate) del frame2 e in tutti i semiquadri 1,2,3,4.
Nella stessa maniera non esiste evidente ridondanza temporale (blocchi 16*16 simili) tra i frame 1 e 2 a causa delle seghettature del frame 1, mentre sono evidenti quelle tra i semiquadri 2,3,4 che sembrano molto simili tra loro.
E' evidente inoltre che tra i semiquadri 1 e 2 non c'è alcuna ridondanza temporale tranne che per alcune fortunate coincidenze (tipo la luce chiara in alto a destra del semiquadro1 con la corrispondente parete bianca del frame 2 nella stessa posizione).
Come test, consiglio di ricomprimere il video 720*576 visto prima ( o in generale xxx*576) proveniente ad esempio da una videocamera e comprimerlo sempre con bit rate di 4000-5000 kbit/s in mpeg2 interallacciato: la qualità sarà incomparabilmente superiore.
Ecco una serie di osservazioni legate a quanto detto
1) Lo stesso discorso del trattamento interallacciato (quello che come visto prevede l'analisi sia del frame completo che dei semiquadri separati) vale per qualsiasi codec di compressione: il DivX;-) che con il suo mpeg4 sfrutta gli stessi principi della ridondanza spaziale e temporale dell' mpeg1 e 2 , NON PREVEDE IL TRATTAMENTO INTERALLACCIATO e pertanto se da un lato è ottimo per la compressione del video progressivo dei film DVD al contrario crea elevatissimo rumore video nel caso di video interallacciato proveniente da telecamere e videocamere
2) Poichè l'XVCD prevede l'uso di mpeg1 anche nei casi in cui si comprime video 720*576 o 352*576 ( rispetto al tipico 352*288) il risultato anche con elevati bit rate è sempre inferiore rispetto all'mpeg2 interallacciato.
3) La gestione del video interallacciato è la principale differenza tra l'mpeg 1 e 2: quello che a parole può essere una banalità, a livello di sintassi è in realtà molto più complesso poiché occorre inserire nuovi tipi di blocchi 16*16 (lo vedremo in seguito); di volta in volta l'encoder deve chiarire se ci si sta riferendo al fotogramma visto come frame o al semiquadro superiore o inferiore. Non è un caso che l'mpeg 1 è nato per la codifica di video 352*288 PAL o 352*240 NTSC in cui il video è sempre progressivo poiché uno dei due semiquadri è banalmente ignorato.
4) Non c'è da meravigliarsi se il formato DVD obbliga all'encoder l'utilizzo di trattamento interallacciato anche in presenza di video progressivo ( nei DVD i film sono sempre in progressivo e gli inserti speciali sempre in interallacciato). Infatti non a caso il template DVD di tmpeg non permette la modifica del parametro interlaced che è sempre selezionato.
Significa semplicemente che nella codifica dei film, l'encoder considererà di ciascun frame progressivo 720*576 che è ovviamente privo delle tipiche discontinuità, anche due sottoimmagini ( che di semiquadro hanno solo il nome) formate dalle righe pari e dispari. La differenza è che questi due semiquadri provengono dalla stessa immagine e non da due immagini successive di 1/50 di secondo.
Analizzando i flussi mpeg con sw quali Dprobe si vede, come ovvio, che solo raramente si riferisce ai semiquadri piuttosto che ai frame (tipo 1 volta ogni 100) e che tale casi hanno come causa una fortuita coincidenza matematica piuttosto che una reale convenienza: non aggiungo altro poichè il discorso potrebbe allungarsi inutilmente.
5) Nel caso di codifica MPEG2 SVCD è lasciata libertà nella scelta della opzione interlaced: ovviamente nel caso SVCD XXX*576 di video interallacciato è FONDAMENTALE selezionare l'opzione interlaced; nel caso di video progressivo diventa indifferente a livello di qualità ma conviene DESELEZIONARE l'opzione interlaced perché si guadagna con tmpeg circa 10% di tempo di codifica
Ricordo che sto parlando dell'opzione interalaced presente in configure video e non quella presente in configure/ advanced che serve solo agli algoritmi di tmpeg nei casi, raramente utilizzati, in cui il sw ridimensiona le immagini PRIMA della compressione video.
Il
campionamento dei colori (YUV format
4:4:4 4:2:0 4:1:1)
Profile e Level
Tali opzioni sono modificabili solo nel caso di mpeg2, ma per i nostri usi (DVD, SVCD e MiniDVD) occorre semplicemente scegliere YUV format 4:2:0 e Main Profile & Main level
Per quanto riguarda i Profile e Level questi limitano le tantissime possibilità di formati video in classi precise.
| Level | Max. frame, width, pixels |
Max.
frame, height, lines |
Max. frame, rate, Hz |
Max. bit
rate, Mbit/s |
Buffer
size, bits |
Buffer
size, Kbyte | |||||
| Low | 352 | 288 | 30 | 4 | 475136 | 58 | |||||
| Main | 720 | 576 | 30 | 15 | 1835008 | 224 | |||||
| High-1440 | 1440 | 1152 | 60 | 60 | 7340032 | 896 | |||||
| High | 1920 | 1152 | 60 | 80 | 9781248 | 1194 |
Il
livello High-1440
è utilizzato nello standard televisivo ad alta definizione (HDTV) formato
4:3 , mentre il livello High è pensato per il formato 16:9: le trasmissioni
HDTV sono iniziate in America verso novembre 1999, mentre per l'Europa .... non
si muove ancora nulla..
Giacché parliamo di futuro, un accenno all'HD DVD, secondo gli ottimisti in commercio tra almeno 5 anni: risoluzione 1920*1080 per il NTSC e 1920*1152 per il PAL (risoluzione 5 volte superiore rispetto ai "miseri" 720*576 del DVD), dischi da 27.4 GB per lato ( più di tre volte rispetto gli attuali 8.5 GB di un DVD9) e massimo bitrate di 32.4 Mbit/s rispetto ai 9.8 attuali.
I level Low, Main High limitano altre caratteristiche quali ad esempio il tipo di YUV format, la presenza di frame di tipo B. etc etc.
Il campionamento dei colori (YUV format) chiarisce come sono attribuiti i colori ai singoli pixel: se nel mondo dei PC si utilizzano i fattori RGB ( rosso, verde e blu) per descrivere il colore di un pixel nel campo del video digitale ci si riferisce a
Y: luminanza
( è la luminosità del pixel)
U,V : crominanza (sono due fattori che definiscono il colore)
Senza entrare troppo nel dettaglio è banale passare dalla descrizione di un pixel tramite la triade RGB a quella YUV e viceversa. A seguito delle limitazioni dell'occhio basta 1 byte ( = 8 bit = valore numerico compreso tra 0-255) per descrivere il singolo fattore R,G,B,Y,U,V e pertanto occorrono 3 bit = 24 bit per descrivere il colore di un pixel.
Si può pertanto scegliere il metodo con cui descrivere il colore di un pixel: ad esempio
(R,G,B)=(255,0,0)
pixel rosso chiaro
(R,G,B)=(50,50,50) pixel grigio scuro......
(Y,U,V)=(255,0,0) pixel bianco....... etc
Nel momento
in cui invece di descriverei colori di un singolo pixel si sceglie di descrivere
quelli di un gruppo di pixel ci sono le tipiche descrizioni YUV 4:4:4
4:2:2 4:2:0 4:1:1
. Ci si riferisce a gruppi di 4 pixel.
YUV 4:4:4 ; per descrivere il colore di un gruppo di 4 pixel ( due in orizzontale e due in verticale) si utilizzano 12 byte ovvero 3 byte per pixel ovvero 24 bit per pixel : come si evince dalla tabella ogni pixel è descritto dal suo byte Y,U e V .
|
I quattro pixel sono descritti dai 12 Byte Y1,Y2,Y3,Y4,U1,U2,U3,U4,V1,V2,V3,V4
|
|
|
Una immagine 720*576 occupa 1.224.160 byte (720*576 * 3 byte per pixel)
YUV 4:2:2 ITU-R 601 (chiamato YUY2 in ambito Windows Direct Draw) ; per descrivere il colore di un gruppo di 4 pixel ( due in orizzontale e due in verticale) si utilizzano 8 byte : ciascun pixel ha il suo valore di luminosità Y mentre i pixel 1 e 2 hanno lo stesso colore U12,V12 e i pixel 3 e 4 hanno lo stesso colore U34,V34.
U12 è in generale la media dei singoli valori U1 e U2 del caso 4:4:4: U12=(U1+U2)/2. Analogamente V12=(V1+V2)/2......
Facendo un pò di calcoli si ha che ogni pixel è descritto IN MEDIA da 2 byte=16 bit ( 8 byte totali/ 4 pixel ) con un risparmio rispetto al caso 4:4:4 del 33% (16/24=0.666 ; 1 - 0.666 = 0.33= 33%)
|
I quattro pixel sono descritti dagli 8 Byte Y1,Y2,Y3,Y4,U12,U34,V12,V34
|
|
|
Una immagine 720*576 occupa 829.440 byte (720*576 * 2 byte per pixel).
Tale compressione dei colori appare poco evidente ai nostri occhi che sono molto sensibili alle variazioni spaziali luminosità piuttosto che di colore: non a caso ogni pixel ha la sua descrizione di luminosità Y. Tale formato standardizzato come YUV 4:2:2 ITU-R 601 è utilizzato per le digitalizzazioni di video PAL che non ricaverebbero NESSUN BENEFICIO nell'utilizzo del formato 4:4:4 poichè il PAL utilizza per i colori una banda video dimezzata rispetto al bianco/ nero; il motivo sta nel fatto che il PAL è nato B/N e i colori sono stati infilati nel segnale b/n con una serie di artifici..... mi fermo qui !!!
YUV 4:2:0 ( chiamato YV12 in ambito Windows Direct Draw). E' il formato che si utilizza per l'mpeg 1 e 2. Per descrivere il colore di un gruppo di 4 pixel ( due in orizzontale e due in verticale) si utilizzano 6 byte : ciascun pixel ha il suo valore di luminosità Y mentre i 4 pixel hanno lo stesso colore U e V: incredibile ma vero.
U12 è in generale la media dei singoli valori U1,U2,U3,U4 del caso 4:4:4: U=(U1+U2+U3+U4)/4. Analogamente V=(V1+V2+V3+V4)/4
Facendo un pò di calcoli si ha che ogni pixel è descritto IN MEDIA da 1,5 byte=12 bit ( 6 byte totali/ 4 pixel ) con un risparmio rispetto al caso 4:4:4 del 50% (12/24=0.5= 50%)
|
I quattro pixel sono descritti dai 6 Byte Y1,Y2,Y3,Y4,U,V
|
|
|
Una immagine 720*576 occupa 622.080 byte la metà rispetto al caso 4:4:4.
Per
convincervi di quanto tale risparmio non influisce sulla qualità , basta
dare una occhiata ai film in DVD: il motivo è che 4 pixel su un frame di
720*576 pixel occupano una una porzione piccolissima: solo ingrandendola è
possibile accorgersi della carenza di informazione di colore.
YUV 4:1:1 E' il formato analogo al 4:2:0 ma utilizzato in certi rari casi per il video NTSC : non è comunque previsto dall'mpeg e lo riporto semplicemente per completezza. Numericamente è analogo al caso 4:2:0 riguardo byte utilizzati.
La differenza sta nel fatto di utilizzare 4 pixel di una stessa riga: non è un caso il suo utilizzo nel video NTSC in cui ho solo 480 righe invece che 576: la compressione 4:2:0 lascerebbe solo 240 possibili colori diversi in una riga verticale.
|
I quattro pixel sono descritti dai 6 Byte Y1,Y2,Y3,Y4,U,V
|
|
|
Una immagine 720*576 occupa 622.080 byte la metà rispetto al caso 4:4:4.
Facendo un po' di conti è possibile determinare il bit rate di un flusso video ( es. 720*576 25 fps dei DVD) di un filmato codificato con uno di questi metodi: è di fatto considerato il bit rate di video NON compresso, poiché questi tipo di riduzione di colore (4:2:2 e 4:2:0) normalmente non lo si considera una compressione:
4:4:4: 720 x 576 x 25fps x 8 bit x 3 = 237.3 Mbit/s = 29.7 MByte/s
4:2:2: 720 x 576 x 25fps x 8 bit + 360 x 576 x 25 x ( 8 + 8 ) = 158.2 Mbit/s = 19.8 MByte/s
4:2:0: 720 x 576 x 25fps x 8 bit + 360 x 288 x 25 x ( 8 + 8 ) = 118.6 Mbit/s = 14.9 MByte/s
Da quest' ultimo calcolo è evidente come ad esempio nei DVD che hanno un bit rate video medio di 5 Mbit/s la reale compressione media è di circa 1:24.
Intra frame, Macroblocchi, ICT
Vediamo in dettaglio come l'mpeg sfrutta la ridondanza spaziale e temporale presente in un video.
L'mpeg suddivide i fotogrammi di un video in 2 tipi: i fotogrammi di tipo I ( gli Intra frame) che sono codificati dall'encoder e decodificati dal decoder in maniera autonoma, cioè indipendente da fotogrammi successivi o precedenti. Per tale motivo i frame di tipo I NON SFRUTTANO la ridondanza temporale ma solo quella spaziale
Il secondo tipo di fotogrammi sono quelli di tipo P (Predictive frame) e di tipo B (Bidirectionally-predictive frame ) che contengono informazioni relative alla differenza tra l'iesimo frame e frame successivi o precedenti: sono frame che sfruttano la ridondanza temporale del video, cioè il fatto che fotogrammi vicini hanno spesso molta informazione video comune. Vista la complessità della loro funzione, non aggiungo altro, poichè tali frame (P e B) gli analizzerò tra un pò in dettaglio.
La maniera con cui i frame I,P,B sono disposti prende il nome di GOP sequence dove GOP sta per 'Group of Pictures': anche l'analisi di questa caratteristica la vediamo dopo. Normalmente il GOP lo si sceglie "IBBPBBPBBPBB"
Frame di tipo I
Consideriamo i fotogrammi di tipo I ( gli Intra frame ): per avere una analogia la loro compressione è molto simile a quella del formato jpeg, mjpeg o DV sia a livello di principio che come implementazione. In pratica si deve sfruttare la ridondanza spaziale dell'immagine ("se un pixel in un certo frame ha un certo colore, nei pixel vicini e nello stesso frame, con buona probabilità avrà un colore simile"). Tale ridondanza la si elimina lasciando praticamente il più possibile inalterate le basse frequenze video ( colori più o meno uniformi) e approssimando invece le alte frequenze video (frastagliature, discontinuità). Nella pratica lo si fa in due maniere:
1) decidendo numericamente come le diverse frequenze video debbano essere trattate : trattare bene una frequenza video significa memorizzarla praticamente come nell'immagine non compressa, trattarla male significa approssimarla o addirittura trascurarla. Tale decisione la si fa tramite le MATRICI DI QUANTIZZAZIONE e nel caso in esame nella Intra matrix (tra breve spiegherò a che servono)
| block matrix |  |
2) scegliendo che percentuale di compressione applicare all'intero I frame: ciò ovviamente dipende dal bit rate video che si è scelto e dalla percentuale di tale bit rate che l'encoder assegna agli I frame. Ovviamente l'encoder decide questa percentuale in base al numero di I frame presenti nel video , numero che dipende dal GOP: nel caso del tipico GOP "IBBPBBPBBPBB" ovviamente assegnarà meno bit rate agli I frame rispetto ad un GOP IBPBI in cui gli I frame sono molto più frequenti.
Nella pratica l'utente decide la GOP sequence e il bit rate video ( es. il tipico valore medio di 5000Kbit/s per un buon 720*576) e l'encoder assegna una percentuale di tale bit rate all' I frame e lo comprime . Ovviamente MAGGIORE E' IL BIT RATE VIDEO, MINORE SARA' LA COMPRESSIONE E MIGLIORE SARA' LA QUALITA' del video a parità di tutti gli altri parametri. ( mi vergogno quasi a dirlo, tanto è ovvio !!)
E' fondamentale che gli I frame dopo la compressione abbiano la migliore qualità possibile poiché tutti i P frame altro non fanno che cercare delle differenze dell'ennesimo frame con il frame I ( i frame B lo fanno direttamente con gli I o indirettamente con i P ): un errore sulla compressione dell'I frame determina una reazione a catena di errori nei frame successivi, fino all'I frame seguente.
Per questo motivo i frame I sono quelli meno compressi (ad esempio un frame 4:2:0 720*576 che non compresso occupa 607.5 Kbyte nel caso di una buona compressione mpeg2 occupa in media dai 70 ai 100 KByte con una compressione tipica di che va da 1:6 1:9 che è la tipica compressione Jpeg o mjpeg usata rispettivamente con le immagini ferme o video) . Per i più curiosi l'occupazione in Byte dei singoli frame la si può visualizzare in tmpeg tramite l'opzione options/show encoding log .
Sempre a
causa dell'importanza della codifica degli I frame Tmpeg come tutti i migliori
encoder mpeg, ha la possibilità di svincolare la scelta degli I frame
dall'ordine imposto dai GOP, ma liberamente tmpeg inserisce un I frame nei punti
più indicati, che sono I CAMBI SCENA. Il motivo è ovvio: in un cambio di scena
è inutile cercare legami con le immagini passate, ma si fissa un I frame e i
fotogrammi successivi potranno calcolarsi con migliori esiti le differenze con tale
frame.
Approfondiremo
in seguito con un esempio tale questione.
Tmpeg offre addirittura la possibilità di inserire manualmente gli I frame ( oltre che i B e P) : per i più smanettoni lo si fa in Configuration/Gop structure/force frame types/configure. Click sinistro sul fotogramma per settare gli I frame e destro per settare gli altri. Cliccando su auto-set la scelta degli I frame verrà fatta automaticamente. Per la codifica occorre impostare in Video/Rate control Mode Manual VBR (MVBR): ottimo per studiare a fondo come funzionano gli mpeg. Anche tale possibilità sarà analizzata dettagliatamente dopo.
Per la cronaca è molto didattico utilizzare il SW Virtual DUB http://www186.pair.com/vdub/ per ingrandire e analizzare i singoli frame mpeg (funziona solo per l'mpeg 1); in basso per ogni fotogramma è indicato il tipo di frame (I,P,B)
Ma l'encoder come procede esattamente nella compressione degli I frame ? : per comprendere la cosa occorre riferirsi alla DCT (Discrete Cosine Trasform) che è l'algoritmo matematico che permette la trasformazione di un blocco di 8*8 pixel dell'immagine ad un insieme di 8*8 numeri (coefficienti DCT) che descrivono il contenuto di frequenza ( alte e basse) di tale blocco.Se i pixel sono ciò che appare ai nostri occhi, il contenuto in frequenza descrive COME VARIANO tali pixel all'interno del blocco.
La DCT (Discrete Cosine Trasform) è utilizzata dall'encoder mentre il Decoder utilizzerà la IDCT che è la trasformata DCT inversa che fa esattamente il contrario ( passa dal contenuto di frequenza al bitmap 8*8).
L'mpeg per comprimere i singoli fotogrammi suddivide l'immagine in blocchi di 16*16 pixel che a causa del formato colore 4:2:0 corrispondono a 6 blocchetti 8*8 pixel , 4 blocchi di luminanza e 2 di crominanza
 |
dove ogni blocchetto |
|
è un insieme di 8*8 pixel |
contenenti valori numerici (0-255) relativi a luminanza Y o crominanza U V.
Ciascun insieme di 16*16 pixel prende il nome di MACROBLOCCO
Un frame 720*576 contiene pertanto 1620 macroblocchi di 16*16 pixel disposti come una matrice 45*36
|
Come procede l'encoder per comprimere gli I frame? Per quanto visto ciascuno dei 1620 macroblocchi del singolo I frame è in realtà fatto da 6 blocchi 8*8 pixel ciascuno caratterizzato dai valori di colore e luminosità dei rispettivi pixel: pertanto l'encoder considera i 9720 (1620*6) blocchi per ciascuno dei quali cerca di eliminare la ridondanza spaziale cercando il più possibile di approssimare le informazioni di alta frequenza a cui la nostra vista è meno sensibile. Qui entrano in ballo le Matrici di quantizzazione.
Per ciascuno dei 9720 blocchi l'encoder esegue la DCT che trasforma gli 8*8 pixel nel loro contenuto nel campo delle frequenze. In pratica si crea una nuova matrice di 8*8 valori detti COEFFICIENTI DCT in cui in alto a sinistra ci sono le basse frequenze e in basso a destra le alte frequenze ( che dovranno essere il più possibile scartate): un esempio
Immagine (pixels)
gM64
pixel con una luminosità simile tra loro 0 = nero 255 = bianco
|
-----> DCT ---->
|
Frequenze
(coefficienti DCT)hg
g in alto a sinistra: basse frequenze in basso a destra: basse alte 0 = presenza nulla di quella frequenza 255 = presenza massima di quella frequenza
|
Osservo che il coefficiente DCT dell'angolo in alto a sinistra , in rosso, rappresenta il valor medio di luminosità di tutto il blocco: occorre rappresentarlo ( vedi dopo) nel migliore dei modi.
Vediamo un esempio reale:
|
||||||||||
 |
||||||||||
|
| la striscia in alto contiene 10 blocchetti di pixel 8*8 di una immagine mentre quella in basso i 10 corrispondenti 8*8 coefficienti DCT ( frequenze video riferite alla luminosità; ricordo che ci sono poi quelle riferite ai due fattori di crominanza U e V). Nella DCT il bianco =255=valore max del coefficiente per quella frequenza e il nero =coefficiente 0 cioè frequenza assente. Per la cronaca l'immagine è presa dal film Jurassic Park 2; le parti chiare sono lo sfondo di un cielo, quelle viola sono alcuni fiori in primo piano mentre le parti verdi sono lo sfondo della foresta , il tutto rappresentato con un grosso zoom che permette la visualizzazione dei pixel : l'immagine da cui è stata prelevata la striscia è qui a destra (il particolare ingrandito è in alto al centro ) . |  |
E' evidente
come il blocchetto 1 contiene uno sfondo pressoché uniforme e nel
campo delle frequenze l'unico coefficiente fortemente
diverso da zero (il puntino bianco) è quello in alto a sinistra : gli altri sono quasi tutti = 0 (puntini
neri).
Nei blocchetti 3,4,5 la presenza dei fiori ( il viola) crea delle discontinuità
e pertanto delle alte frequenze : nelle relative DCT esistono dei valori sempre
concentrati in alto a sinistra in cui ho le diverse gradazioni di grigio:
osservo come anche in questo caso le altissime frequenze video sono pressoché
nulle: i puntini in basso a destra sono tutti neri.
Nei blocchetti 7, 10 ho una specie di gradiente di colore che va dal chiaro (il
cielo in alto) allo scuro ( il verde della foresta in basso): nel campo delle
frequenze ho la presenza di una riga verticale di valori ben diversi da zero; al
contrario un gradiente di colori che vanno dal chiaro allo scuro da
sinistra a destra nel campo delle frequenze darebbe una riga orizzontale di
valori diversi da zero.
Quanto visto dimostra in maniera evidente come sono distribuiti i coefficienti della DCT di un blocco di 8*8 pixel di una immagine. Nel campo delle frequenze si hanno coefficienti DCT con valori significativi (molto diversi da zero) nelle zone vicine all'angolo in alto a sinistra ( le basse frequenze) e valori tendenti sempre più a zero quanto più ci si avvicina all'angolo in basso a destra (le alte frequenze): per quanto visto anche la prima riga orizzontale e quella verticale tendono ad avere valori diversi da zero.
Questa caratteristica è di fatto dovuta alla ridondanza spaziale delle immagini reali "se un pixel in un certo frame ha un certo colore, nei pixel vicini e nello stesso frame, con buona probabilità avrà un colore simile": le alte frequenze in una immagine reale sono attenuate e spesso praticamente nulle.
La DCT di per se non crea nessuna compressione: se il decoder ( il player mpeg) esegue l'operazione inversa ( la IDCT) si riottiene il blocco di 8*8 pixel senza aver guadagnato nulla: infatti come visto nelle due tabelle numeriche e negli esempi grafici , per memorizzare la luminanza (luminosità) degli 8*8 pixel mi occorrono 64 byte: lo stesso servono 64 byte per memorizzare i 64 coefficienti della DCT. Il vantaggio della DCT è quello di aver "trasportato" i valori significativi in alto a sinistra e valori quasi tutti uguali a zero in basso a destra.
A questo punto per risparmiare bit preziosi devo "trattare bene" le basse frequenze video e male le alte ! Trattare bene una frequenza video significa memorizzarla esattamente come nell'immagine non compressa, trattarla male significa approssimarla o addirittura trascurarla. Tale decisione la si fa realizzando una QUANTIZZAZIONE tramite le MATRICI DI QUANTIZZAZIONI
Un variabile non quantizzata è quella che può assumere tutti i suoi possibili valori : nel caso della singola frequenza video ciascuna frequenza può assumere i valori 0,1,2,4,5,6,.......255.
Una variabile quantizzata è quella che può assumere solo alcuni possibili valori: es. solo i multipli di dieci 0,10,20,30,.....250 . ( i matematici non si strappino i capelli visto il contesto in cui ne sto parlando).
Maggiore è la quantizzazione che applico , minore è il numero dei valori che quella variabile può assumere: una variabile che può assumere solo i valori 0,60,120,180,240 è più quantizzata di una che può assumere es.tutti i multipli di 5 : 0,5,10,15,20,25,..............255.
Per decidere quanto quantizzare ciascuno dei 64 coefficienti DCT si ricorre alla matrice di quantizzazione che in tmpeg trovate in Configure/Quantizer Matrices. ( nel nostro caso stiamo considerando quella di sinistra, la Intra block matrix)
 |
I numeri che si trovano indicano la entità di quantizzazione del relativo coefficiente: maggiore è tale numero, maggiore sarà la quantizzazione di quel coefficiente DCT e con maggiore approssimazione sarà memorizzato tale coefficiente.
Non a caso i valori di quantizzazione in alto a sinistra sono piccoli ( sono le basse frequenze = colori uniformi che dovranno essere memorizzati con accuratezza cioè quantizzati il meno possibile) e al contrario i valori di quantizzazione in basso a destra sono grossi ( sono le alte frequenze = frastagliature che potranno essere memorizzate con minore accuratezza cioè quantizzati maggiormente).
I due casi estremi sono :
- angolo in
alto a sinistra (il valor medio) in cui ho 8: significa che tale coefficiente
potrà assumere solo i valori multipli di 8 (ho in tutto 32 valori possibili:
0,8,12,24,32,40,..........240,248)
- angolo in basso a destra (componente alla massima frequenza) in cui ho
83: significa che tale coefficiente potrà assumere solo i valori multipli di 83
(ho in tutto 4 possibili valori possibili: 0,83,166,249) : qualsiasi altra
sfumatura sarà approssimata al numero più vicino tra i 4 possibili valori;
QUALSIASI VALORE ASSUNTO MINORE DI 42 (83/2) sarà approssimato con lo 0, cioè
tale frequenza se non supera tale soglia è considerata come se non presente.
Quindi l'encoder altro non fa che dividere ciascun valore della matrice dei coefficienti DCT per i corrispondenti della matrice di quantizzazione e memorizzare la parte intera del quoziente ( al limite arrotondata al valore più prossimo)
|
Frequenze (coefficienti DCT)h
g
|
--> diviso--> |
g
|
g =
|
Risultato della quantizzazione:h frequenze quantizzate
g
|
La nuova matrice delle frequenze quantizzate grazie alla enorme presenza di zeri e al particolare ordine dei sui valori, viene memorizzata nel flusso mpeg con pochissimi bit : si sfruttano tecniche matematiche loseless , senza perdita di informazione che sfruttano " l'entropia della sorgente" ovvero il grado di disordine dei coefficienti.
Senza approfondire la cosa si utilizzano tecniche quali la memorizzazione dei coefficienti in un ordine particolare ( es. lettura a ZIG ZAG ) , assegnazione di minori bit ai numeri più frequenti e codifica, nel caso di numeri ripetuti, con il valore e il numero di volte con cui tale valore è ripetuto.
Ovviamente il decoder (player mpeg) farà la operazione diversa: ricava la matrice delle frequenze quantizzate, la moltiplica per la intra block matrix e tramite la IDCT ricava il blocchetto di 8*8 pixel: per quanto detto prima sia l'encoder che il decoder PER UN SINGOLO I frame 720*576 devono fare le operazioni viste ben 9720 volte (1620macroblocchi * 6 ); per i B e P frame la cosa si complica di molto !!!.
Tale processo di quantizzazione produce, come ovvio, un deterioramento della qualità dell'immagine che il player visualizzarà; tale deterioramento dipende anche da altri due fattori :
1) Livello globale di quantizzazione
2) DC coefficient precision
1) Livello globale di quantizzazione : nel discorso visto non entra in ballo il data rate video imposto dall'utente: come ultranoto maggiore è il bit rate video, a parità degli altri parametri, migliore sarà la qualità del video e minore la compressione (e quindi meno artefatti). L'encoder a secondo del data rate fissato decide che livello di quantizzazione globale applicare a ciascun blocco di 8*8 pixel . Per vedere tale valore ( che può assumere per l'mpeg 2 valori compresi tra 0 e 31 ) consiglio lo shareware Bit rate Viewer ( www.tecoltd.com ) che ne visualizza il valore medio per ogni secondo. Tutti i diagrammi, che troverete in seguito , usati per l'analisi delle diverse tecniche di compressione, sono stati realizzati con tale sw. Il livello globale di quantizzazione medio (Q) è rappresentato in verde .
Normalmente la scelta del livello globale di quantizzazione la si compie, indirettamente, fissando il bit rate e direttamente in tutte le codifiche a bit rate variabile in cui si fissa una qualità costante tramite il parametro QUALITA'.
Le codifiche a bit rate variabile sono video mpeg con data rate (bit al secondo) che varia nel tempo e aventi come limite superiore una soglia massima fissata (Max bitrate).
ln Tmpeg il parametro " qualità" lo si fissa in setting /video/ rate control mode nei metodi a bit rate variabile cq_vbr, cq, rt_cq . Ci ritorneremo dopo.
2)
DC coefficient precision :
è un parametro che è fisso a 8 bit nell'mpeg 1 e si può settare a 8, 9
o 10 bit nell'mpeg 2: tale parametro indica i bit che si allocano per
memorizzare il VALOR MEDIO DI LUMINANZA E CROMINANZA che sono quelli
relativi al coefficiente DCT presente in alto a sinistra nelle matrici
8*8 di luminanza e crominanza. Tale coefficiente prende il nome di "coefficiente
DC" ed è
fondamentale per definire correttamente colore e luminosità del
singolo blocchetto: un valore approssimato renderebbe il blocchetto 8*8
leggermente più chiaro o scuro e con dominanti di colori particolari (es.
leggermente più verde o rosso). Se tali dominanti sono invisibili
all'occhio quando il blocchetto è visto singolarmente appaiono evidenti quando
ho blocchetti simili, vicini tra loro e ciascuno con una dominante di colore o
luminosità diversa. Il tipico esempio è quello di un cielo azzurro in cui, con
una DC ad esempio pari a 8, in certi casi tende a non apparire uniforme ma
costellato da blocchi tutti leggermente diversi in luminosità e colore.
I DVD commerciali utilizzano tutti il valore 9 bit che consiglio pertanto come il miglior compromesso. Assegnare più bit al DC coefficient significa garantire quindi delle migliori sfumature nel caso di sfondi uniformi e sopratutto in presenza di scene molto buie in cui occorre codificare le più piccole sfumature di colore. Tali problemi aumentano nel caso di bassi bit rate e pertanto in presenza di eccessive compressioni.
Prima di fare altre considerazioni ecco una immagine di 32 blocchi 8*8 pixel che visualizza: il frame originario, i relativi coefficienti DCT, l'immagine compressa in mpeg con una pesante compressione (e quindi elevata quantizzazione), un immagine che visualizza gli errori tra il frame originale e quello prodotto dalla compressione, cioè le informazioni scartate.
E' evidente come nei blocchi con più dettagli ho molti coefficienti DCT pesantemente diversi da zero ( il nero=0) che dopo la compressione provocano il famoso effetto di quadrettamento. Il bitmap degli errori che visualizza le informazioni scartate, mostra come la maggior parte delle alte frequenze a causa della forte compressione sono state soppresse. L'immagine rappresenta la testa di una bimba ( la sfortunata bimba che incontra i dinosauri di jurassic park 2): il forte rumore video è dovuto all'origine del filmato ( vhs) e al fatto che in realtà tale immagine occupa una piccolissima parte dell'intero fotogramma.
 |
|
Alcune considerazioni:
- il famoso mpeg I frame altro non è che un sottoformato dell'mpeg che utilizza solo gli I frame, e pertanto opera come appena visto su tutti i fotogrammi: non viene utilizzata la compensazione del moto e la codifica dei movimenti. Per avere un 720*576 di buona qualità occorre avere bit rate pari ad almeno 25 Mbit/s = 3.1 MByte/s che è lo stesso bit rate del DV : un illustre HW che utilizza tale compressione è la Matrox Rt2000 : le soluzioni professionali prevedono invece 50 Mbit/s = 6.2 MByte/s . Poichè ,come visto il flusso non compresso nel caso di video 720*576 4:2:0 è di 118.6 Mbit/s ( 720 x 576 x 25fps x 8 bit + 360 x 288 x 25 x ( 8 + 8 ) = 118.6 Mbit/s = 14.9 MByte/s) si ha che il 50Mbit/s corrisponde ad una blanda compressione di 1 : 2.37, praticamente indistinguibile rispetto al video non compresso.
Nel caso delle risoluzioni dell'XVCD (352*288) occorre almeno avere un bit rate di 8Mbit/s = 1 MByte/s: con bit rate inferiori i quadrettini fanno da padrone.
- è finalmente chiaro il discorso della compressione di video interallacciato con codifica di tipo interallacciata infatti:
| Consideriamo
( in basso)
un particolare ( 4 blocchi di 8*8 pixel) di un tipico frame interallacciato ( a destra
): è una banalissima sfera blu che si muove verso sinistra e che a
seguito dell'interallacciamento crea le tipiche
discontinuità. Passando nel dominio delle frequenze in basso appare evidente come i coefficienti della DCT sono fortemente diversi da zero pur in presenza di una immagine semplice (una sola dominante di colore) con sfondo perfettamente uniforme. |
 |
 |
 |
|
Quando l'encoder va a quantizzare i coefficienti approssimando le alte frequenze si ottiene una grave perdita di qualità nelle zone in cui ci sono le discontinuità : pertanto quando sarà decodificato il frame le righe di scansione saranno sfocature poco definite e circondate da blocchetti .
|
 |
| originale |
dopo
la |
Il video quando visualizzatoa 25 fotogrammi al secondo , apparirà nelle zone in movimento sfocato e sporco nei contorni: infatti ad esempio il bianco che nella immagine originale è presente nella parte alta dei frame pari è diventato blu sporco nelle vicinanze della sfera !.Quando
Tramite la codifica mpeg2 di tipo interallacciato l'encoder crea separatamente i due semiquadri
|
--->
|
|
che avranno coefficienti DCT tutti concentrati in alto a sinistra poiché privi delle grosse discontinuità create dalle righe dell' interallacciamento: per tale motivo il SW applica la compressione sui due semiquadri ottenendo dei risultati sicuramente migliori. Ovviamente il player mpeg2 deve essere in grado di ricostruire il frame originario interallacciato ( quello di sinistra) per poi visualizzarlo, cosa che comporta un maggior lavoro computazionale. Per i più curiosi lo si può constatare osservando come i player sw incrementano l'utilizzo di CPU nella visualizzazione dei contenuti speciali dei DVD che sono sempre interallacciati e pertanto sfruttano pesantemente questa caratteristica dell' mpeg2.
Dovrebbe pertanto essere finalmente chiaro perchè è impossibile ottenere dei buoni risultati comprimendo un video xxx*576 di origine interallacciata in mpeg1, che non prevede la codifica di tipo interallacciato ( idem se si usa l'mpeg 2 non interallacciato).
Concludo facendo un accenno alla possibilità di modificare le matrici di quantizzazione degli I frame (in tmpeg lo si fa in Configure/Quantizer Matrices) .
|
Tmpeg, contempla 2 matrici: quella di default ( che è analoga a quella mpeg standard) e poi la matrice CG ( computer graphics / animation).
Riguardo
quella di default c'è poco da dire: dopo anni di studi e test è stata
formalizzata ed è considerata quella ottimale nei casi più generici : la
matrice CG (
computer graphics / animation ) contiene tutti valori pari a 32. In pratica
tutte le frequenze video sono considerate di pari importanza. E' chiaramente
sconsigliata nella compressione di video prodotti " dalla
natura" ( filmati di scene reale) in cui vale senza eccezione il
principio della ridondanza spaziale e le alte frequenze possono essere approssimate
tranquillamente.
Al contrario nei cartoni animati sono frequentissimi gli sfondi
uniformi e i bordi neri ( i contorni dei personaggi), cosa che consigliano un
diverso trattamento video; discorso analogo per la Computer Grafica in cui il video è in formato
4:4:4 e sono spesso presenti altissime frequenze video a causa della natura
artificiale delle immagini ( basta pensare ad alcune finissime texture
procedurali di sw quali 3d Max ). In entrambi i casi credo che sia opportuno
fare dei test e scegliere la matrice preferita, lasciando magari quella di
default se si ricerca una immagine più morbida e naturale.
E' ovviamente possibile modificare manualmente le matrici di quantizzazione e memorizzarle: chiarito ( spero) il significato dei coefficienti..... si può " giocare" con tali valori e fare dei test ( magari anche provocando volutamente artefatti !!). Con tmpeg è addirittura utilizzare matrici diverse a secondo della scena da convertire ( vedi impostazioni manuali)
Ridondanza temporale e compensazione del moto
Tutti i discorsi fatti fino ad ora, sono relativi alla compressione dei singoli fotogrammi, indipendentemente dal fatto che sono parte di un filmato e che pertanto ci sono delle chiare similitudini tra frame successivi !!
Voglio
osservare come quanto visto per gli I frame è perfettamente analogo alle note
compressioni jpeg ( per le immagini), Mjpeg per i video in movimento e DV: le
differenze tra questi formati sono veramente minime: TUTTI utilizzano la DCT e
le matrici di quantizzazione: ciò che cambia è la "grammatica" , come sono impacchettati i dati e altri piccoli particolari : ad esempio il jpeg
per le immagini prevede maggiori tipi di spazio colore primo tra tutti il
formato RGB usato normalmente per le immagini su PC .
La più importante
differenza tra la mjpeg ( usata ad esempio nelle Matrox Marvel g200 e g400 e
nelle dc-10 e dc-30) e il
DV è che quest'ultimo può scegliere il livello globale di quantizzazione per
ogni macroblocco, mentre nell' mjpeg il codec lo sceglie una volta per tutte all'interno
del singolo frame e vale per ogni blocco del frame. L'effetto è una minore ottimizzazione
del mjpeg rispetto al DV in tutte quelle immagini che sono composte in parte
da una zone con sfondi uniformi ( maggiormente comprimibili) e in parte da
zone ricche di particolari ( alte frequenze ): in tal caso se l'encoder
sceglie un livello globale di quantizzazione molto elevato (alta
compressione) , soddisferà le zone uniformi, creerà un bit rate basso ma
causerà artefatti nelle zone con più dettagli: al contrario se sceglie
un basso livello di quantizzazione (scarsa compressione ) si otterrà una
buona qualità nelle zone a maggior dettaglio, ma una scarsa ottimizzazione per
le zone uniformi in cui si sarebbe potuto tranquillamente comprimere di più.
Con il DV e l'mpeg è possibile scegliere in livello diverso di quantizzazione (
e quindi di compressione) per ogni blocchetto di pixel 16*16.
L'mpeg ( ad eccezione della versione a soli I frame), sfrutta anche la ridondanza temporale del video : "se un pixel in un certo frame ha un certo colore, lo stesso pixel o quelli vicini , nei fotogrammi successivi o precedenti con buona probabilità avranno un colore simile".
Lo fa alternando agli I frame (che sono codificati dall'encoder e decodificati dal decoder in maniera autonoma, poiché indipendenti da fotogrammi successivi o precedenti) dei frame di tipo P e B che contengono informazioni relative alla differenza tra l'iesimo frame e frame successivi o precedenti. Per questo motivo un P o B frame non potrà mai essere decodificato autonomamente ma occorrerà avere in memoria uno o più frame precedenti o successivi: per il montaggio video pertanto si preferisce utilizzare formati diversi quali il DV, mjpeg o l'mpeg I frame grazie ad una loro più semplice implementazione..
Per distinguere l'mpeg I frame da quello che contiene frame P e B si parla normalmente di MPEG IPB, anche se spesso è sottinteso. Più in generale per tutti i codec video che sfruttano la codifica delle differenze tra frame si parla di intra frame per i frame che non fanno riferimento a differenze tra fotogrammi successivi ( gli I frame dell'mpeg) e inter frame per quelli che codificano le differenze ( gli P e B dell'mpeg).
Vediamo di capire come sono implementati i fotogrammi di tipo P (Predictive frame) e di tipo B (Bidirectionally-predictive frame ) .
Vediamo come funzionano i P frame. Consideriamo ad esempio il caso di un mpeg avente GOP di tipo IPIPIPIP...Il primo frame è considerato un I frame, il secondo P frame e così per gli altri fotogrammi.
| frame 1 | frame 2 | frame 3 | frame 4 | frame 5 |
| I | P | I | P | I |
| Analizziamo come l'encoder comprime i primi due frame: per i successivi il metodo è identico. Considero ad esempio i seguenti 2 fotogrammi: |  |
Il frame 1 è un I frame ed è compresso come visto nei seguenti passi:
1) il frame
è diviso in macroblocchi 16*16 pixel ( 1620
nel caso di frame 720*576)
2) ciascun macroblocco produce 6 blocchi 8*8 pixel ( 4 di luminanza e 2 di
crominanza) (1620*6=9720
nel caso di frame 720*576)
3) per ciascun blocco 8*8 viene fatta la DCT: fino a questo momento nessuna
informazione è persa e non si è ancora guadagnato un solo bit.
4) finalmente si comprime guadagnando bit preziosi grazie alla quantizzazione
(che deteriora la qualità ) e al risparmio "matematico" dovuto
all'entropia, il tutto per ciascuno dei 9720 blocchi.
Il frame 2 è un P frame: per tali frame e per i frame B si utilizza la compensazione del moto detta anche predizione inter frame ( in inglese Motion-compensated inter-frame prediction ).
Consideriamo il P frame. Il principio è semplice: l'encoder per ciascuno dei macroblocchi di 16*16 pixel del P frame va a cercare nel frame I PRECEDENTE (o se non lo trova nel frame P precedente) un blocchetto di 16*16 pixel il più possibile simile al macroblocco che si sta cercando di codificare. Una volta trovato si calcola la differenza tra se stesso e il blocchetto individuato nel frame I precedente e viene memorizzata tale differenza sempre come matrice di 16*16 pixel . Con tale nuovo blocco si procede esattamente come per un macroblocco visto per gli I frame (creazione dei 6 blocchi 8*8, DCT , quantizzazione e codifica matematica ).
Tale processo molto dispendioso in termine di calcoli, produce se ben implementato un grande vantaggio: la matrice 16*16 pixel ricavata dalla differenza del macroblocco da codificare con un blocco preso dal frame precedente ha il vantaggio di avere spesso un contenuto di alte frequenze molto basso e pertanto per quanto visto può essere compresso pesantemente ( con una elevata quantizzazione) senza grosse perdite qualitative.
Riprendiamo l'esempio:
|
Consideriamo come comprimere il frame 2, avendo in memoria il frame 1 senza del quale non è possibile fare nessun tipo di codifica intra frame. Ricordo come già visto che i macroblocchi di ciascun frame sono fissi e sono quelli aventi coordinate multiple di 16; nel frame 720*576 sono
|
Ciascun macroblocco contiene 16*16 pixel.
Per comodità li rappresento con le quadrettature in nero.
| Consideriamo il primo Macroblocco di 16*16 pixel del frame 2 (in alto a sinistra) che devo cercare di comprimere: questo è |  |
L'encoder
cerca nel frame I precedente (frame1) il blocchetto di 16*16 pixel che sia
il più simile possibile al macroblocco attuale che si vuole comprimere. Nel
caso dell'esempio la cosa è semplice, poiché è esattamente quello che ha le
stesse coordinate. Poi l'encoder calcola la differenza tra i due blocchi che
essendo uguali produce una matrice 16*16 fatta da tutti zeri (visivamente è un
blocco 16*16 pixel tutto nero). Nei casi di video reali
tale differenza non è mai zero: per esempio in un video ripreso da una telecamera
fissa , il minimo movimento della camera o dell'oggetto sullo sfondo o la
semplice grana della pellicola fa si che la differenza tra i due blocchi è nei
casi migliori fatta da valori molto prossimi a zero e in tutti i casi circa
uguali ma mai perfettamente =0. Di tale matrice differenza viene calcolata la DCT che
essendo a valori tutti più o meno uguali (basse frequenze) produce coefficienti tutti concentrati in alto a sinistra che possono pertanto
essere compressi molto bene risparmiando preziosi bit. Rispetto al caso in cui avessi codificato tale
macroblocco come negli I frame (senza la codifica delle differenze) avrei
occupato molti più bit senza praticamente nessun vantaggio qualitativo poichè
la DCT del blocco contiene
parecchi coefficienti diversi da zero anche lontani dall'angolo in alto a
sinistra ( le due linee bianche essendo delle discontinuità provocano
certamente delle componenti ad alta frequenza che in fase di quantizzazione
negli I frame devono necessariamente essere approssimate).
Nel caso del
macroblocco del frame 2 
il blocco più simile è 
presente nel frame 1 leggermente più in alto e a sinistra (come indica la
freccia) La differenza tra i due produce un nuovo blocchetto 
che
come si vede è nero (=0) dove i due blocchi sono uguali e sempre più chiaro
dove ci sono differenze. L'encoder deve fare di tale blocco la DCT e poi
comprimere quantizzando i coefficienti. Sia il blocco dopo la compressione
(molto approssimato
rispetto a quello non compresso e peranto caratterizzato da colori sfumati). E' possibile comprimere maggiormente tale
differenza senza eccessivi peggioramenti del risultato finale poiché gli errori prodotti dalla quantizzazione sono sempre
relativi alle differenze tra i blocchi e non ai blocchi presi singolarmente.
Inoltre spesso le alte frequenze del blocco delle differenze contengono molto
rumore video che può essere tranquillamente scartato. Detto in altri termini
se la ricerca dei blocchi simili è stata realizzata correttamente, i
blocchi differenza contengono meno informazione video rispetto al blocco
dell'immagine e pertanto possono essere maggiormente compressi applicando una maggiore quantizzazione ai coefficienti DCT.
Il player
(decoder) deve procedere esattamente all'inverso: parte dal blocco
che è presente nel frame1 lo somma al blocco delle differenze
e ricava un blocco che sarà sicuramente molto simile all'originale non
compresso. Nel nostro esempio tutti gli errori relativi al blocco delle
differenze creeranno solo una leggera sfumatura in corrispondenza dei contorni
del disco azzurro e del righino bianco.
Vediamo brevemente la terminologia usata nell'mpeg:
La ricerca dei blocchetti 16*16 più simili al macroblocco corrente ( quello da codificare) la si definisce normalmente stima del movimento o compensazione del moto o predizione inter frame ( in inglese Motion-compensated inter-frame prediction ) o predizione dei macroblocchi (macroblock prediction).
La posizione del blocco da cui calcolare la differenza viene descritta dal vettore di movimento: il vettore es.(x,y)=(-3,5) comunica che il blocco del passato da cui calcolare la differenza si trova 3 pixel a sinistra (-3) e 5 pixel in basso (+5).
| Nel
caso dell'esempio
il vettore di movimento è (x,y)=(-21,-5): il blocco da cui calcolare le
differenze deriva da
che è spostato in alto a sinistra rispetto alla posizione corrente nel
frame 2 |
|
l'encoder fa quindi
|
- | |
= | |
| Forward Predicted Block (FP) | - | Motion Compensated Prediction block | = | Prediction Error block |
Ovviamente
dopo la compressione a causa della quantizzazione dei coefficienti DCT il Prediction
Error block si trasforma da
a
.
Il
player invece ricava:
|
= | |
+ | |
| Forward Predicted Block (FP) | = | Prediction Error block | + | Motion Compensated Prediction block |
Iblocchi così predetti prendono il nome di Forward
Predicted Block (FP).
Il nome è esplicativo: sono " blocchi predetti in avanti" in cui si
preleva informazione dal passato ( il frame I da in cui si cerca il blocco più
simile è precedente nel tempo). E' facile ricordarlo osservando la freccia che
punta in avanti.
Una serie di osservazioni:
1) La quantizzazione dei coefficienti DCT del blocco differenza (Prediction Error block) lo si fa sfruttando un'altra matrice diversa da quella usata dagli I frame: nel caso di tmpeg tale matrice è (configure/quantizer matrices)
| Non-intra block matrix
( quella a destra) |
|
Ricordando
il significato dei coefficienti si vede come nella Non-intra block le alte
frequenze ( in basso a destra) vengono trattate meglio rispetto ai blocchi degli
I frame ( ho valori più piccoli, a parità di posizione). Il motivo è
semplice: sto parlando delle frequenze video delle differenze di due blocchi,
frequenze che sono distribuite in maniera diversa rispetto alle immagini: non è
un caso che il blocco
contiene molte più frequenze elevate ( la doppia discontinuità del
bordino verde ) rispetto alla immagine
in cui cui ho una singola discontinuità; nel blocco differenza infatti si passa
rapidamente dal nero al verde e poi di nuovo al nero (doppia discontinuità);
viceversa nella immagine si passa solo dal verde al blue.
Se si vedono gli altri due preset ho che la Non-intra block contiene tutti valori costanti (16) a prova che nei blocchi differenza ha senso trattare tutte le frequenze nella stessa maniera senza grosse preferenze delle basse frequenze (sfondi uniformi)
2) I blocchi differenza, visto il loro contenuto informativo inferiore, vengono compressi maggiormente rispetto ai blocchi degli I frame; viene cioè applicato un livello globale di quantizzazione superiore. Il risultato è che normalmente un P frame occupa la metà dello spazio occupato da un I frame. Nel caso dell'esempio visto per gli I frame (video 720*576 mpeg 2 con una buona compressione ) se un I frame occupa in media dai 70 ai 100 KByte, un P frame attorno ai 30-40 KByte.
3) Nella delicata ricerca dei blocchi più simili ovvero nella ricerca della miglior compensazione del moto l'encoder deve trovare il giusto compromesso tra qualità- tempo.
Se consideriamo un frame 720*576 esistono la bellezza di 394240 ( 704*560) blocchetti 16 * 16: tra questi occorre scegliere IL BLOCCO 16*16 più simile al macroblocco di cui si sta cercando di fare la compensazione del movimento. Pertanto a livello teorico una ricerca completa del blocchetto più simile comporterebbe PER CIASCUNO DEI 1620 macroblocchi la bellezza di 394240 differenze tra due matrici 16*16: scusate se sparo numeri ma per curiosità dovendo fare tale operazione per tutti i macroblocchi di un P frame, ciò comporterebbe 16*16*394240*1620=163.499.212.800 sottrazioni che con le potenze di calcolo attuali (1000 Mips) corrispondono a circa tre minuti di calcolo per un singolo P frame ( che in realtà vanno raddoppiati nel caso dei B frame).
Questo semplice calcolo vuole solo dimostrare come in realtà l'mpeg lascia una tale libertà tale di implementazione che è demandato al sw la scelta del migliore compromesso tempo-prestazioni.
Ritornando all'esempio nessun sw farebbe una ricerca di 6 minuti per comprimere un singolo B frame e ovviamente il gioco non ne vale la candela. Il motivo è banale: tra fotogrammi successivi, i blocchi simili non sono mai distanti troppi pixel; basta pensare ad un aereo inquadrato nel cielo , al pallone che scorre sul campo di calcio o ad una carrellata di una telecamera; molti dei blocchi si sposteranno solo di pochi pixel.
Rimane chiaro che se la ricerca non è fatta bene si è costretti a comprimere blocchi differenza (Prediction Error block) molto pieni di informazione video poiché prodotti dalla differenza di due blocchi molto diversi: la loro compressione crea grossi artefatti.
Ciascuno degli encoder utilizza un approccio diverso nella ricerca della miglior compensazione del moto: la qualità del video compresso e il tempo della compressione sono fortemente legata a tale operazione; gran parte delle altre operazioni (DCT, quantizzazione, compressione matematica) sono ormai ottimizzate anche nei sw freeware in cui i sorgenti sono liberamente scaricabili (vedi la sezione link) .
Per limitare
i tempi di ricerca dei macroblocchi simili la prima cosa che si fa è porre
un limite all'ampiezza dei vettori di movimento (x,y) : se ad esempio
fisso i valori max pari a + - 24 pixel , per quanto visto significa al massimo
ricercare blocchi 16*16 distanti 24 pixel sia orizzontalmente che verticalmente:
in tutto ci sono 2304 (48*48) blocchetti possibili molto meno dei 394240 (
704*560) teorici. L'mpeg permette vettori di movimento ampi sino a + - 256 pixel
ma non c'è nessun sw che fa una ricerca del genere. Se si analizzano gli mpeg
dei DVD che senza ombra di dubbio spesso sono il miglior risultato ottenibile
con i sw e le potenze di calcolo attuali, è facile vedere che in media non si
superano i 7-8 pixel .
Per risparmiare i tempi di ricerca ci sono comunque i così detti "
algoritmi intelligenti" di ricerca: questi ad esempio considerano i vettori
di movimento dei macroblocchi vicini ( se un pezzo di aereo si sposta di 3 pixel
da destra a sinistra, è molto probabile che succeda la stessa cosa per l'altro
pezzo !!!) o si studia l'andamento degli errori nei macroblocchi ( se
analizzando i blocchi spostati in alto, mi accorgo che gli errori si
incrementano all'aumentare della distanza, è stupido continuare a cercare in
quella direzione ma conviene ad esempio cercare in basso).
All'utente in certi casi è data la possibilità di fissare la massima ampiezza dei vettori ( ad esempio nei sw lsx encoder, si può fissare con i parametri P/B frame motion vectors ) mentre per quasi tutti è possibile scegliere quanto tempo dedicare alla ricerca della miglior compensazione del moto.
In tmpeg
il parametro che quantifica la qualità della compensazione del moto, e quindi
il tempo impiegato per tale preziosa operazione è "motion search accuracy"
Negli altri sw prende i nomi più diversi : search range ( SW. Expert DVD),
performance mode (SW Lsx Program), motion algorithm (SW DVMPEG).
In tmpeg b12a ci sono 5 possibilità : ecco un esempio delle velocità di compressione con PII 400 per mpeg1 XVCD 352*288 (ovviamente i tempi a parità di parametri dipendono linearmente dalla potenza della CPU e sono anche condizionati dal tipo di video: la tabella da solo una idea dei tempi ottenibili )
Motion search accuracy |
Fotogrammi al secondo |
tempi rispetto alla normal quality |
hightest quality (la codifica più lenta) |
1.3 |
+343% (X 4.43) |
high quality |
3.4 |
+70% (X 1.70) |
normal quality |
5.8 |
0% |
lowest quality |
7.6 |
-23% (X 0.77) |
low quality (la codifica più veloce) |
8 |
-28% (X 0.72) |
In pratica un video che per essere compresso richiede 1 ora in normal quality richiede 4.43 ore in hightest quality e 0.72 ore=43 minuti in low quality. Ovviamente il miglioramento della qualità è evidente in maniera chiara solo nelle scene dinamiche in cui a causa dell'elevato movimento la compensazione del moto diventa fondamentale: nelle scene più statiche la differenza è spesso inavvertibile. Una cattiva stima del moto al contrario produce degli artefatti che appaiono come blocchetti 8*8 e 16*16 pixel presenti nei punti con maggiore movimento. Chiaramente se si imposta un bit rate troppo basso o se il video è molto rumoroso (il tipico segnale tv proveniente da una cattiva ricezione) gli algoritmi di compensazione per quanto ottimizzati non possono fare miracoli !!.
Una breve nota per i più curiosi
(agli altri potete passare direttamente al punto 4): per determinare il
macroblocco più simile si utilizza il metodo dei minimi quadrati : praticamente
si calcola la differenza tra il macroblocco da "compensare" e i
blocchetti ( del passato per i P frame) individuati dall'algoritmo di ricerca,
si calcola il blocco differenza e si calcola la radice quadrata del quadrato
degli elementi. Si sceglie il blocco con il valore più piccolo. Ci si riferisce
alla luminanza e si ignora la crominanza.
Un banale esempio (per semplicità uso macroblocchi 2*2 mentre in realtà sono
16*16):
| sia il macroblocco Forward Predicted Block (FP) da compensare |
|
| e siano i due potenziali macroblocchi ( Motion Compensated Prediction block) da cui calcolare le differenze : |
|
e |
|
| I Prediction Error block (blocchi differenza) sono banalmente |
|
e |
|
| La radice quadrata del quadreto degli elementi Prediction Error block (blocchi differenza) sono : |
|
e |
|
| Il valore più piccolo è 3,16 e pertanto il Motion Compensated Prediction block è |
|
4) L'encoder in realtà non è obbligato a codificare ciascuno dei macroblocchi del P frame come Forward Predicted Block (FP) ma gli è lasciata una maggiore libertà. Ritorniamo all'esempio:
Per quanto detto, e per quanto frettolosamente scritto in molti articoli dedicati all' mpeg , si potrebbe erroneamente pensare che per ciascuno dei macroblocchi del frame 2 di tipo P occorre trovare nel frame 1 il blocchetto più simile e associare il vettore di movimento e il blocco delle differenze: in realtà ciascuno dei macroblocchi di un P frame può essere compresso ( e quindi memorizzato) secondo uno di queste possibili alternative:
a) Intra coded Block : il macroblocco è compresso esattamente come un macroblocco di un I frame, ovvero senza l'utilizzo dei vettori di movimento e del blocco delle differenze. Tali blocchi sono molto comodi quando il sw si accorge che il blocco in esame ha un contenuto frequenziale ( coefficienti DCT) molto più facile da comprimere rispetto ad un blocco differenza. Ad esempio in presenza di un macroblocco uniforme ( es. cielo sereno) delle volte è inutile cercare le differenze con " porzioni di cielo del passato", poiché in tutti i casi non si ottiene un blocco differenza più semplice. Ci sono altri casi in cui può convenire codificare intra coded, come ad esempio nelle situazioni in cui l'encoder ha un buon margine di bit a disposizione in un certo gruppo di fotogrammi e desidera codificare un P frame con la massima qualità possibile o il caso in cui il P frame si trova subito dopo un cambio di scena e l'encoder ovviamente non trova blocchi simili (in tal caso gli encoder intelligenti quali tmpeg piazzano un I frame al posto del P frame, come vedremo in seguito).
b) Forward Predicted Block (FP) E' il caso che abbiamo esaminato : ricerca del macroblocco più simile che è memorizzato tramite il vettore di movimento, calcolo e compressione del blocco delle differenze (Prediction Error block).
c) Not coded Block. E' il caso in cui il blocco delle differenze è nullo e pertanto il blocco è descritto unicamente dal vettore di movimento: il decoder copia semplicemente il blocco 16*16 del frame I precedente indicato dal vettore di movimento, nella posizione occupata dal macroblocco così codificato.
d) Skipped Block. E' il caso in cui si comunica al decoder di lasciare il blocco esattamente come era nel fotogramma precedente. Serve tutte le volte in cui tra i due frame successivi (I e P) ci sono blocchi che rimangono invariati. E' proprio il caso di molti dei macroblocchi dell'esempio che sono perfettamente uguali nei frame 1 e 2. E' utilizzato ad esempio nella codifica delle bande nere dei film in cui tali bande sono ovviamente fisse nel tempo. Chiaramente uno skipped Block è memorizzato con pochissimi bit, cosa che fa si che la codifica delle bande nere impieghi praticamente un bit rate nullo.
Nel caso dell'mpeg2 ci sono altre possibilità nel momento in cui è possibile gestire il video nella modalità interallacciata: esattamente come per gli I frame è possibile fare le predizioni e la compensazione del moto riferendosi al frame visto come composto da due semiquadri; in tal caso per ciascun Macroblocco occorre fare la predizione del moto per 2 blocchi di dimensioni 16*8 a ciascuno dei quali si associa un vettore di movimento: a secondo che si punta al semiquadro delle righe pari o a quello delle righe dispari si parla di Forward top field Block o Forward Bottom field Block . E' evidente come tale doppia compensazione necessita di maggiore tempo e pertanto la codifica mpeg2 interallacciata normalmente è più lenta rispetto alla analoga non interallacciata ( con tmpeg questo aggravio di tempo è dell'ordine del 10%.)
5) Un accenno al parametro "half pel - motion" che viene spesso inserito negli encoder. Per capirne il significato ritorniamo all'esempio di prima con il macroblocco che contiene il disco blu.
La compensazione del moto è stata fatta identificando il blocchetto 16*16 del frame 1 come il più simile, e tale blocco è identificato dal vettore di movimento (x,y)=(-21,-5) : l'encoder calcola la differenza e ottiene il Prediction Error block
|
- | |
= | |
| Forward Predicted Block (FP) | - | Motion Compensated Prediction block | = | Prediction Error block |
Osservo come il Prediction Error block (che ricordo è prodotto facendo bit a bit la differenza dei due blocchi 16*16) contiene un cerchio verde che deriva dal fatto che il cerchio non è centrato nella stessa maniera nei due blocchi da cui si è calcolata la differenza. Nella realtà un oggetto non si sposta mai "con multipli" esatti di un pixel : non viviamo in un mondo quantizzato !!!!!
Per capire la cosa basta pensare ad esempio ad un palo nero ripreso su uno sfondo grigio in un filmato in cui la cinepresa fa una leggera panoramica da destra verso sinistra (panning). Nelle ipotesi in cui tale palo, lontano e sottile, occupa sempre meno di un pixel nel quadro es. 720*576, facendo un ingrandimento dell'immagine nei tre fotogrammi successivi ho:
 |
I
quadretti rappresentano i pixel, enormemente ingranditi. Poiché nelle immagini digitalizzate non ha senso il concetto di mezzo pixel, ogni pixel avrà un colore che è una media di tutto ciò che si ha all'interno dello spazio di immagine codificato da tale pixel. Nel caso del frame 1 in cui ho un palo nero sullo sfondo grigio, nelle ipotesi in cui il palo è leggermente più sottile di un pixel, ho che la colonna dei pixel avrà un colore quasi nero (il quasi deriva dal fatto che per ogni pixel occorrerà inserire il piccolo contributo del pezzetto di sfondo grigio) Nel frame 2, a causa del panning della telecamera verso sinistra, il palo si è spostato in una posizione in cui occupa metà spazio codificato dagli stessi pixel di prima e metà codificato dalla colonna di pixel più a sinistra. Il risultato è una doppia colonna di pixel ma più chiara. I pixel sono più chiari poiché ciascun pixel avrà " al suo interno" metà contributo di sfondo e metà di palo. Nel frame 3 mi ritrovo nelle stesse condizioni del frame 1 : la colonna è spostata a seguito della rotazione della camera. Detto in altri termini ho descritto a parole come ad esempio il CCD di una telecamera o di un apparecchio telecine digitalizza una immagine: per convincersene basta ingrandire ad esempio del 800% una qualsiasi fotografia digitalizzata o un fotogramma di un DVD. . |
Chiaramente l'esempio " disegnato ad hoc" e ci sono altre questioni legate per esempio al formato colori ( il 4:2:0 per l'mpeg che campiona diversamente luminanza e crominanza): in tutti i casi l'mpeg cerca di sfruttare tale caratteristica.
Ritornando alla stima del moto , proprio a causa del fatto che non esiste il "mezzo pixel" di una immagine si ha che
| la differenza tra | |
e | |
produce | |
Infatti
il bordino verde del blocco differenza deriva dal fatto che il cerchio blu non
è mai perfettamente centrato all'interno dei pixel e "lascia" in
corrispondenza dei pixel che rappresentano i bordi una quantità di blu che
dipende dalla sua esatta posizione. Pertanto il cerchio blu sarà centrato
diversamente nei 2 blocchi 16*16 da cui calcolo la differenza e il risultato del
Prediction
Error block è .
Per la compensazione del moto l'mpeg prevede la compensazione half pel (half pel block prediction : pel è l'abbreviazione di pixel ): in pratica dopo aver trovato il potenziale blocco da cui calcolare la differenza (il MCP, Motion Compensated Prediction block) l'encoder prova a vedere se si ottiene una migliore differenza sottraendo non tale MCP ma un blocco 8*8 di pixel ottenuto matematicamente facendo la media (interpolazione lineare) tra l'MCP e un blocco a lui adiacente ma spostato di un pixel (per esempio spostato a destra di un pixel).
In pratica è come se calcolasse la differenza con un blocco prodotto da una ipotetica telecamera reale che si sposta di mezzo pixel rispetto al blocco MCP individuato come più simile. L'encoder dovrebbe tra l'altro provare a fare le medie nei 4 possibili casi di blocchi adiacenti di un pixel: quello in alto a destra, in alto a sinistra, in basso a destra e in basso a sinistra; spesso la direzione dei vettori di movimento evitano l'analisi dei 4 casi.
Nel caso
dell'esempio visto è probabile che una compensazione half pel
possa generare un Prediction
Error block non più
ma quasi tutto nero
. Chiaramente l'annullamento
assoluto delle differenze è impossibile, ma è evidente come in questo secondo
caso il blocco differenze contenendo meno discontinuità è più facilmente
comprimibile.
Il problema della compensazione half pel è che nel caso di sfondi fissi un rumore video quale ad esempio la grana della pellicola può indurre in errore l'encoder: l'effetto è un tremolio delle parti delle immagini che in realtà dovrebbero essere fisse. In tmpeg encoder è possibile eliminare tale rischio selezionando l'apposita opzione presente in configure /quantizer matrices
l'encoder nei casi in cui le scene sono statiche ( vettori di movimento che tendono a 0) disabilita la compensazione half pel.
L'opzione " Use floating point DCT " utilizza i numeri a virgola mobile al posto degli interi per il calcolo della DCT, con un aggravio dei tempi di calcolo nel momento in cui lasciando deselezionata tale opzione, grazie ad ottimizzazioni del codice ( linguaggio macchina, istruzioni MMX, SSE, ...) per tale operazione viene sfruttata al 100% la reale velocità di calcolo delle CPU. I vantaggi dell'uso della floating point DCT sono solo teorici e inseriti, di fatto, solo a scopo di test.
Rimangono da analizzare i frame di tipo B (Bidirectionally-predictive frame ): li vediamo tra breve.
Per adesso abbiamo analizzato solo le strutture ( GOP sequence ) del tipo Mpeg I frame (IIII...) e il caso semplice IPIPIP in cui si alternano I frame e P frame. In realtà è possibile scegliere altre combinazioni in tmpeg tramite configure/GOP structure
Consideriamo il caso in cui non ci sono B frame e cioè GOP B frame count = 0; sia inoltre GOP I frame count = 1 .
Il GOP P frame count descrive quanti P frame ci sono tra due I successivi: pertanto
| GOP P frame count | GOP | Seccessione di frame |
| 1 | IP | IPIPIPIP.... |
| 2 | IPP | IPPIPPIPPIPP.... |
| 3 | IPPP | IPPPIPPPIPPPIPPI.... |
Il principio di funzionamento è che i Forward Predicted Block (FP) presenti nei P frame si riferiranno per il calcolo delle differenze ai blocchi simili (Motion Compensated Prediction) presenti nel frame I o P precedente più vicino.
Banalmente nel caso di IPIPI...
| frame 1 | frame 2 | frame 3 | frame 4 | ... |
| I | P | I | P | ... |
i
macroblocchi del frame 1 sono tutti codificati come Intra frame,
i macroblocchi del frame 2 cercheranno i blocchi simili nel frame 1 (I),
i macroblocchi del frame 3 sono tutti codificati come Intra frame,
i macroblocchi del frame 4 cercheranno i blocchi simili nel frame 3 (I),....
Nel caso di IPPIPPI...
| frame 1 | frame 2 | frame 3 | frame 4 | frame 5 | frame 6 |
| I | P | P | I | P | P |
i
macroblocchi del frame 1 sono tutti codificati come Intra frame,
i macroblocchi del frame 2 cercheranno i blocchi simili nel frame 1 (I),
i macroblocchi del frame 3 cercheranno i blocchi simili nel frame 2 (P),
i macroblocchi del frame 4 sono tutti codificati come Intra frame,
i macroblocchi del frame 5 cercheranno i blocchi simili nel frame 4 (I),
i macroblocchi del frame 6 cercheranno i blocchi simili nel frame 5 (P)....
I B frame nascono dall'esigenza di codificare i macroblocchi come differenza o con i blocchi presenti nel frame I o P precedente o con i blocchi presenti nel frame I o P seguente.
I macroblocchi codificati come differenza dal frame (I o P) precedente prendono il nome di Forward Predicted Block (FP) così di come per i P; i macroblocchi codificati come differenza dal frame (I o P) seguente prendono il nome di Backward Predicted Block (BP)
La prima ragionevole considerazione da fare è che non essendo stata ancora inventata la macchina del tempo..... occorrerà fornire all'encoder e al decoder alcuni frame temporalmente successivi per permettere la compressione o la decodifica dei B frame.
Consideriamo il caso utilizzato nella gran parte delle codifiche mpeg in cui si cerca la migliore compressione e qualità possibili: è la famosa successione IBBPBBPBBPBBI. Appunto un po' la terminologia per non appesantire la scrittura:
f = frame, ma = macroblocco
| f 1 | f 2 | f 3 | f 4 | f 5 | f 6 | f 7 | f 8 | f 9 | f 10 | f 11 | f 12 | f 13 |
| I | B | B | P | B | B | P | B | B | P | B | B | I |
i ma del f 1
sono tutti codificati come Intra f,
i ma del f 2 cercheranno i blocchi simili nel f 1 (I) e nel f 4 (P)
i ma del f 3 cercheranno i blocchi simili nel f 1 (I) e nel f 4 (P)
i ma del f 4 cercheranno i blocchi simili nel f 1 (I)
i ma del f 5 cercheranno i blocchi simili nel f 4 (P) e nel f 7 (P)
i ma del f 6 cercheranno i blocchi simili nel f 4 (P) e nel f 7 (P)
i ma del f 7 cercheranno i blocchi simili nel f 4 (P)
i ma del f 8 cercheranno i blocchi simili nel f 7 (P) e nel f 10 (P)
i ma del f 9 cercheranno i blocchi simili nel f 7 (P) e nel f 10 (P)
i ma del f 10 cercheranno i blocchi simili nel f 7 (P)......
Ecco uno schema grafico:
E' evidente come l'encoder e il decoder debbano processare i frame in un ordine diverso: ovviamente ciò viene fatto automaticamente dai sw senza bisogno di alcun intervento nei parametri. L'ordine è il seguente:
|
1 |
4 |
2 |
3 |
7 |
5 |
6 |
10 |
8 |
9 |
13 |
11 |
12 |
|
I |
P |
B |
B |
P |
B |
B |
P |
B |
B |
I |
B |
B |
Il motivo è ovvio: ad esempio l'encoder non può comprimere il frame B 2 se non conosce già il frame 4 da cui potenzialmente può calcolarsi le differenze: per questo occorre prima comprimere il frame 4 (P) e poi il 2 (B); stesso discorso per il player che non può visualizzare il frame 2 se non ha già decompresso il frame 4 (ovviamente il frame 4 verrà poi visualizzato al momento giusto cioè dopo il frame 3)
La rappresentazione grafica più corretta è comunque quella in cui le frecce partono dal frame da cui cercare i blocchi e calcolare la differenza e sono dirette verso il frame che si sta comprimendo il tutto in coerenza con i nomi Forward Predicted Block (FP) (blocchi predetti in avanti) e Backward Predicted Block (BP) (blocchi predetti all'indietro)
Ritornando ai parametri che determinano il GOP
se il GOP P frame count determina quanti P frame ci sono tra due I successivi il GOP B frame count determina quanti B frame ci sono tra 2 frame P e I consecutivi. Nel caso I=1 e P=3 (il caso più frequente)
| GOP B frame count | GOP | Seccessione di frame |
| 1 | IBPBPBPB | IBPBPBPB IBPBPBPBI ... |
| 2 | IBBPBBPBBPBB | IBBPBBPBBPBB IBBPBBPBBPBB ... |
| 3 | IBBBPBBBPBBBPBBB | IBBBPBBBPBBBPBBB IBBBPBBBPBBBPBBB... |
In realtà per le tipiche applicazioni di compressione che richiedono la migliore qualità possibile, e contemporaneamente elevata compressione ( DVD, XVCD, SVCD...) si utilizza la GOP rappresentata in figura :I=1 P=3 B=2 IBBPBBPBBPBB .
Normalmente la compressione che utilizza I, P e B frame prende il nome di Mpeg IPB (spesso è sottinteso); come già visto l'MPEG che utilizza solo I frame, utile per l'editing video prende il nome di MPEG I frame. Ovviamente vista la blanda compressione dell' MPEG I frame a parità di qualità occorre avere bit rate 2-3 volte maggiori rispetto l'MPEG IPB.
Formati che non utilizzano i B frame, come il IPPP IPPP IPPP.... pur non caratterizzati da buoni fattori di compressione (circa 30-40% meno compressi rispetto ad un video compresso IPB e analogo per qualità), sono usati a volte negli encoder SW o HW funzionanti in tempo reale in cui la velocità di calcolo che occorre per fare una buona compensazione con i B frame normalmente non è disponibile.
In realtà per le normali compressioni non conviene preoccuparsi più di tanto del GOP poichè gli encoder quali Tmpeg modificano automaticamente il GOP a secondo delle caratteristiche del video, semplicemente piazzando dove servono gli I frame: il motivo di tale intervento deriva dal fatto che per come è strutturata la successione dei frame in un mpeg IPB gli errori dovuti alla compressione si sommano nel tempo: ad esempio nel caso
| f 1 | f 2 | f 3 | f 4 | f 5 | f 6 | f 7 | f 8 | f 9 | f 10 | f 11 | f 12 | f 13 |
| I | B | B | P | B | B | P | B | B | P | B | B | I |
il frame 10 (P) è ricavato (in alcuni dei suoi macroblocchi) dalle differenze con il frame 7 (P) a sua volta ricavato dalle differenze con il 4 (P) a sua volta ricavati dalle differenze con il frame I il primo ad essere totalmente indipendente.
Per quanto detto se ad esempio il frame 7 (P) per una cattiva compensazione del moto produce un video di scarsa qualità, tutti i frame successivi (8,9,10,11,12) saranno caratterizzati da artefatti poichè non troveranno grosse similitudini con il frame 7 che è praticamente sbagliato (i frame 11 e 12 possono cercare maggiori similitudini con il frame 13(I) che è compresso come si deve essendo un inter frame !!)
Un tipico caso in cui ciò succede è quello dove ad esempio ho un cambio di scena nel frame 7 (ad esempio dall'inquadratura di una persona allo sfondo della foresta: in tal caso il frame 7(P) dovendo cercare similitudini con il frame 4 (P) non ne troverà poiché il frame 4 appartiene ad una scena che è cambiata del tutto; l'unica alternativa sensata per non creare accumulo di errori è quella di inserire al frame 7 un I frame.
Ricordo nuovamente come il posizionamento corretto degli I frame è fatto automaticamente da Tmpeg con l'opzione configure/GOP structure
L'opzione "create bitstream for editing", crea i così detti "closed GOP": in pratica per rendere ciascun GOP indipendente dal successivo, l'encoder modifica il GOP facendo si che termini con un frame P e non un frame B: tale opzione è utile nel caso si utilizzi l'mpeg IPB in software di editing non lineare, per semplificare il compito del sw e quindi incrementare le prestazioni (velocità nell' editing).
Perchè inserire i B frame, visto che per la compensazione del moto comportano una ricerca doppia e che creano il problema del riordino dei frame ? (frame da decodificare in anticipo rispetto alla loro visualizzazione significa dover incrementare la memoria dell' encoder e del decoder, cosa che nel caso dell' Hw comporta maggiori spese e complessità architetturale).
La risposta è che in molti casi senza il riferimento a frame futuri è impossibile trovare blocchi simili per la ricerca e la codifica delle differenze; cioè è impossibile fare la compensazione del moto e occorre ricorrere alla codifica inter frame per il macroblocco, codifica che occupa bit preziosi e fa inevitabilmente salire il bit rate del flusso video (a meno di accontentarsi di una bassa qualità).
Lo si capisce con un esempio: una panoramica da destra a sinistra sul volto della bellissima 7di9 di Star Trek Voyager
Sia il
GOP ad esempio un semplice IBPBPBP e consideriamo i primi 3 frame (suppongo il
formato non interallacciato).
L'encoder come prima cosa codificherà il frame 1 di tipo I nel modo più volte
descritto.
Poi andrà compresso il frame 3 (P) per permettere al frame 2(B) di calcolarsi
le differenze anche con il frame 3(P) senza...ricorrere alla macchina del
tempo.
Riguardo al frame P per ciascun macroblocco l'encoder deve decidere se codificare Intra frame ( Intra coded Block (IC) ) o cercare di fare compensazione del moto e pertanto codificare come Forward Predicted Block (FP) fissando così vettori di movimento e calcolando il blocco delle differenze : la ricerca dei blocchi da cui calcolarsi le differenze va fatta nel frame 1(I).
Dall'immagine è evidente come un buon encoder si accorgerà che le prime due
colonne di macroblocchi a sinistra nel frame 3 non hanno alcun blocco simile nel
frame 1 a causa del fatto che la camera si è spostata a sinistra
scoprendo il profilo destro di 7di9: per tale motivo tali macroblocchi andranno
codificati come intra coded block (IC in giallo). Viceversa tutti i rimanenti
macroblocchi del frame 3 troveranno dei blocchi praticamente identici nel frame
1 tutti spostati a sinistra e leggermente in basso: tali blocchi saranno
compressi come Forward
Predicted
Block (FP) (nell'esempio
ne ho disegnati 3 , in azzurro, ma il discorso vale per tutti gli altri.)e
Terminata la compressione del frame 3 tocca al frame B in cui ho 3 possibilità:
Forward
Predicted
Block (FP)
macroblocchi predetti in avanti calcolando le differenze da blocchi dal frame 1
(I)
Backward
Predicted
Block (BP)
macroblocchi predetti all'indietro calcolando le differenze da blocchi dal frame
3 (P)
Intra
coded Block (IC) macroblocchi
codificati intra block
E' evidente come ad esempio il macroblocco A va codificato come Forward Predicted Block (FP) poichè non esistono blocchi simili nel frame 3 mentre esiste nel frame 1 un blocco praticamente uguale; al contrario il macroblocco B va codificato come Backward Predicted Block (BP) poichè non esistono blocchi simili nel frame 1 mentre esiste nel frame 3 un blocco praticamente uguale . Per come è strutturata la sequenza dei 3 frame è evidente come per il frame 3 è inutile codificare dei blocchi come intra block poichè esistono sempre blocchi simili nei frame 1 o 3.
Alcune osservazioni :
a) esattamente come per i frame di tipo P esistono anche altri modi per codificare i macroblocchi di tipo B: ecco le possibilità
Forward
Predicted
Block (FP)
macroblocchi predetti in avanti calcolando le differenze da blocchi dal frame I
o P precedente;
Backward
Predicted
Block (BP)
macroblocchi predetti all'indietro calcolando le differenze da blocchi dal frame
I o P successivo;
Intra
coded Block (IC) macroblocchi
codificati Intra block;
Not coded Block. E' il caso in cui il blocco delle differenze è nullo e pertanto il blocco è descritto unicamente dal vettore di movimento: il decoder copia semplicemente il blocco 16*16 del frame I o P precedente o successivo indicato dal vettore di movimento, nella posizione occupata dal macroblocco così codificato.
Skipped Block. E' il caso in cui si comunica al decoder di lasciare il blocco esattamente come era nel fotogramma precedente .
Il caso maggiormente utilizzato nei frame B ( diciamo almeno nel il 90% dei macroblocchi ) è l'uso degli Interpolated Block: in pratica viene trovato il blocco più simile nel frame precedente (Forward Predicted Block), il blocco più simile nel frame successivo (Forward Predicted Block) e si calcola la differenza dal blocco che è la media dei due blocchi trovati.
Grazie a tale metodo è possibile tener conto contemporaneamente delle variazioni con i frame I o P immediatamente passato o futuro.
Nel caso dell'mpeg 2 esistono altre possibilità perfettamente analoghe a quelle dei P frame nel caso di codifica interallacciata: forward top field block, backward top field block, forward bottom field block, backward bottom field block a secondo che la predizione è fatta con il semiquadro pari o dispari.
b) E' evidente la grande libertà lasciata ai sw di encoding che nella pratica fanno si che ciascun encoder ha una sua "personalità" nella codifica: lo si può notare nei DVD commerciali in cui al di là della qualità del master video che condiziona pesantemente la codifica del film vi è una certa uniformità di caratteristiche video nei DVD prodotti dalla stessa azienda ( Universal, Columbia, Cecchi Gori...) che normalmente utilizzano lo stesso encoder per tutti i loro film.
c) Riguardo
la occupazione media di byte di un B frame questa è normalmente pari al 30-40%
rispetto ad un P frame e quindi circa pari al 20% (1/5) rispetto a un I frame.
Nel caso dell'esempio visto (video 720*576 mpeg 2 con una buona compressione ) se un I frame
occupa in media dai 70 ai 100 KByte, un P frame attorno ai 30-40 KByte, un B
frame tra i 12 e 15 KByte. (ovviamente parlo di valori medi).
Metodi di gestione del Bit-rate
Esistono fondamentalmente due metodi di codifica: la CBR (costant bit rate, codifica a bit rate costante) e la VBR (variable bit rate, codifica a bit rate variabile).
La codifica CBR l'unica realmente riconosciuta da tutti i player nel caso dell'MPEG 1, ma scarsamente utilizzata nell'Mpeg 2, è il metodo meno ottimizzato: si fissa un bit rate video ( bit al secondo) e si comprime tutto il video utilizzando tale flusso costante. La scarsa ottimizzazione deriva dal fatto che fissato un bit rate, diciamo così, medio (per avere una idea 4000 Kbit/s per un video progressivo 720*576) nelle scene statiche tale bit rate è eccessivo (in certi casi bastano anche 2500-3000 Kbit/s) , mentre nelle scene particolarmente dinamiche in cui per avere una buona qualità occorrono spesso anche più di 6000-7000 Kbit/s) si ottengono immagini piene di artefatti ( blocchetti, colori sporchi,......). L'alternativa sarebbe quella di mantenere fisso un bit rate ad esempio di 8000 Kbit/s garantendo sempre ottima qualità: lo svantaggio è la elevata occupazione di spazio spesso molto prezioso.
Ad esempio un DVD5 che contiene al max 4.700.000.000 byte (4.38 GByte), nel caso in cui ho delle tracce audio che occupano circa 1000 Kbit/s ( es un paio di DD 5.1 448Kbit/s ) e in cui ho un bit rate fisso di 8000 Kbit/s ( ottimi risultati se in presenza di video di qualità) facendo un po' di calcoli, ho 1125 KByte/s, pari a circa 70 minuti su un DVD5 e 126 minuti su un DVD9: con una compressione del genere occorre un DVD 9 per inserire un film di max 126 minuti, senza avere spazio per altro ( servizi speciali, trailer,...)
Il discorso è ben diverso se si utilizza il metodo VBR: in tal caso l'encoder utilizza un maggior bit rate nelle scene più dinamiche e al contrario minore bit rate nelle scene statiche, ottimizzando lo spazio occupato: il criterio con cui viene scelto il modo di assegnare il bit rate dipende dall'encoder.
Per permettere una analisi oculata dei risultati ecco una tabella riassuntiva che chiarisce al variare della risoluzione video quali bit rate medi (ad esempio su filmati di una certa durata che contengono un mix di scene di azione e scene più statiche) e quali valori di picco (tipicamente nelle scene dinamiche) , è ragionevole attendersi nel caso di codifica mpeg 2 a bit rate variabile.
Ovviamente tali valori sono ASSOLUTAMENTE INDICATIVI e frutto della mia personale esperienza; sono relativi al caso in cui il video da comprimere è in ottime condizioni ( provenienza Computer Grafica, Betacam, DV o DVD): un video di qualità non elevata al contrario mette sempre in crisi gli encoder che introducono con più facilità artefatti: in quei casi conviene filtrare i video di origine con filtri che mascherano il più possibile il rumore o accontentarsi di qualità finali inferiori. Nei casi di forte rumore anche elevando di molto il bit rate gli artefatti non vengono mai completamente neutralizzati e spesso sono visibili anche senza ricorrere al fermo immagine.
|
||||||||||||||||
|
||||||||||||||||
|
Non mi soffermo più di tanto su queste tabelle poichè dovrei stare a chiarire cosa intendo per qualità sufficiente o media e ovviamente ci sono infiniti altri parametri primo tra tutti la luminosità del video, la percentuale della presenza di scene dinamiche....... in tutti i casi penso sia un buon punto di partenza per fare dei test. Voglio solo osservare come nel caso di codifica di filmati all'interno dei quali ci sono bande nere (tipo film 2.35:1 anamorfici e non o 1.85:1 non anamorfici) a parità di qualità è possibile diminuire tali valori anche sino al 20%) .
Consideriamo come si comporta tmpeg nella versione beta12a, nel caso di un video costruito da me ad hoc per valutarne l'implementazione.
Il video 720*576 dalla durata di 24 secondi è strutturato in questa maniera:
| secondi 0-2 |  |
semplice bitmap (il volto di 7 di 9) fisso per 2 secondi (50 frame); essendo una immagine fissa serve per valutare la capacità dell'encoder ad ottimizzare il bit rate video. |
| secondi 2-5 | |
Lo stesso bitmap di prima ma in movimento in diagonale grazie ad una lento panning della telecamera (realizzato con 3d Studio Max); inserito per valutare la capacità di compensazione del moto. |
| secondi 5-8 |  |
La stessa animazione dei secondi 2-5 con in più una pianeta in computer grapichs che attraversa lo schermo complicando leggermente la stima del moto. |
| secondi 8-10 |  |
Sequenza abbastanza statica con dei dialoghi e scarsi movimenti. |
| secondi 10-14 |  |
Sequenza in grafica 3d che da statica (primo secondo) diventa molto dinamica: un asteroide che attraversa lo schermo con una scia di fiamme. |
| secondi 14-24 |  |
Altra sequenza molto dinamica: esplosioni, fumo, fiamme.... prese dal DVD del film W.W.West |
Il video è stato compresso con il parametro motion search accuracy = normal il migliore compromesso qualità/tempo di codifica.
Per analizzare i diversi metodi di compressione utilizzerò il seguente diagramma:
 |
 |
|
 |
In basso sono indicati i
secondi del filmato e sono colorati diversamente gli spezzoni che ho
descritto (azzurro e giallo).
I due tracciati rappresentano il bit rate video espresso in kbit/s
(in
giallo) e il livello di quantizzazione medio
Q (in verde).
Ovviamente per avere i Kbyte/s basta dividere per 8 (3000 Kbit/s=375 KByte/s).
Vediamo bene come tali diagrammi vanno interpretati.
Il valori disegnati
rappresentano il valor medio in un secondo che sono quelli che si trovano in
corrispondenza delle righe verticali: pertanto l'aspetto spigoloso delle curve
deriva unicamente dalle giunzioni tra tali punti, gli unici che esprimono il
reale valore. Il diagramma si riferisce al valori medi DEL SECONDO APPENA
TRASCORSO: non a caso la tabella inizia con sec = 1 e non sec=0.
Nell'esempio qui sopra , il diagramma inizia (prima colonna sec = 1) con Q=2 e
Bitrate=2500Kbit/s; cioè nell'intervallo 0-1 sec ho 2 e 2500 come valori medi;
nella seconda colonna (sec=2 cioè valori medi nell'intervallo 1-2 sec) ho
sempre Q=2 e bit rate 2000. Terminata la scena completamente statica passo al
valore corrispondente a 3 sec ( Q=4, bitrate=4500): è quanto mi aspetto poiché
nell'intervallo 2-3 sec mi ritrovo una la scena del lento panning della
telecamera e pertanto ho un raddoppio del bitrate e una maggiore quantizzazione.
Una importante osservazione: poiché il flusso mpeg prevede all'inizio del file l'immissione delle caratteristiche del formato e quindi di un certo numero di byte di "header" (intestazione) , il bit rate del primo secondo (il punto in cui inizia il grafico) è falsato essendo sovradimensionato. Per i più curiosi negli "header" di Tmpeg si trova memorizzato nome e la versione dell'encoder usato (......µ# B ² · ² ‚ · ²encoded by TMPGEnc b12a ¸ @ ..........).
| Per questo motivo il bit rate della scena statica compresa tra 0 e 2 secondi è correttamente indicata solo dal valore che c'è in corrispondenza della colonna " 2 secondi". In questo esempio 2000 Kbit/s e non il 2400-2500 da cui inizia il grafico. L'osservazione non deriva da una stupida pignoleria ma dal fatto che la sequenza iniziale dei primi due secondi ( l'immagine |  |
fissa, ovvero la compressione di 50 frame perfettamente uguali) è importante per capire come l'encoder si comporta nel caso più statico possibile di una immagine fissa, ovvero permette di capire quanto l'encoder, con certi parametri, considera prioritario il risparmio di bit : è quindi un indice del livello di ottimizzazione dell'encoder con quel tipo di compressione.
Con i test fatti ho constatato che nel caso dell'immagine fissa basta un bit rate di 1400-1500 Kbits/s per garantire una immagine di fatto identica a quella non compressa: posso pertanto dire che con un video 720*576 il limite minimo di bit rate che garantisce qualità nelle immagini completamente statiche ( o giù di li') è tale valore.Tale analisi ha ad esempio fatto crollare il mito della ottimizzazione assoluta della "compressione a doppia passata" che sempre nel caso di Tmpeg, come vedremo dopo, ha utilizzato per i primi due secondi il " sovrabbondante" valore di 3500 kbit nonostante avessi impostato un bit rate medio di 4500 Kbit e che il filmato nella seconda metà utilizza scene molto più impegnative e quindi più " bisognose" di bit rate.
Prima di passare all'analisi delle tabelle voglio ricordare come la risoluzione usata nel test è quella utilizzata dal DVD (720*576): per tale formato esiste una casistica pertanto molto vasta.
Sulla rivista AF Digitale chiunque può esaminare il diagrammi del bitrate dei film ( cosa che con il computer può fare chiunque grazie al sw freeware DVD Bitrate Viewer e ad un DVD ROM. Nel settore dei DVD video,dopo un periodo di assestamento, diciamo di 3-4 anni, in cui gli encoder ultra milionari delle aziende di authoring si sono notevolmente evoluti e grazie alla esperienza maturata, nel caso di master di buona qualità (telecine fatto con assoluta attenzione alla qualità) è possibile dire che per scene particolarmente statiche 3000 Kbits/s sono già più che sufficienti a garantire ottima qualità; per le scene di media complessità il valore sale attorno ai 5000 e si devono raggiungere i 7000-8000 nei picchi di massima dinamica (le tipiche scene in cui tutto si muove e in cui la compensazione del movimento non è in grado di fare miracoli e occorre ricorrere a basse compressioni e numerosi intra block ) . A prova di quello che dico basta segnalare i titoli di settembre 2000 di Cecchi Gori in cui si adotta una codifica in cui il bit rate video si mantiene con scarsissime oscillazioni sempre tra i 5000-5500 Kbits/s (es Nirvana, La nona porta, Il pesce innamorato e uomo d'acqua in cui il bitrate video è attorno ai 4500 Kbit/s); parlo chiaramente del bit rate video ricavato da quello totale, indicato da dvd bitrate viewer meno quello occupato dalle tracce audio.
Il fattore Q
disegnato in verde esprime il valor medio in un secondo del livello globale di quantizzazione
che come più volte
detto varia per ogni macroblocco di ogni frame: pertanto nel filmato di esempio
che ha risoluzione 720*576, ogni frame ha 1620
macroblocchi 16*16 pari a 9720
(1620*6) blocchi 8*8 di luminanza e crominanza a ciscuno dei quali nel calcolo
della DCT è associato un livello globale di quantizzazione; poichè in un
secondo ho 25 frame, il Q
è la media di
243000 (9720*25) livelli globali di quantizzazione
. Ricordo come Q (che può assumere valori 1-32) caratterizza la quantità di
approssimazione nella memorizzazione delle immagini ed è quindi un indice della
qualità:
Q=1 corrisponde
alla massima qualità e minore compressione; Q=31 è il caso di minima qualità
( blocchetti a non finire!!) e massima compressione. MAGGIORE E' Q MINORE E' LA
QUALITA' E
VICEVERSA
Osservo come non è vero
che qualità e bit rate debbano andare perfettamente a braccetto, poichè assume
un ruolo fondamentale il tipo di video (rumoroso o di qualità, con scene
statiche o dinamiche,...). Infatti nei diagrammi i tracciati di Q e bitrate
NON SONO PARALLELI
Se in teoria l'encoder volesse mantenere Q costante perché
così richiesto dall'utente (es. Q=2 che garantisce video perfetto) nel caso di
scene statiche (720*576) possono bastare bit rate di 3000-4000 , ma per
mantenere Q=2 nelle scene molto dinamiche occorrerebbero bit rate improponibili
(tipo 13000-15000 kbit/s) ben al di là del max consentito dallo standard DVD
(9800 Kbit/s): l'encoder per questo motivo deve conoscere il MAX bit rate
consentito e nel caso tale valore viene superato, deve aumentare la compressione
e pertanto aumentare Q a più di 2. Ovviamente ciò che è banale a parole non
lo è altrettanto per l'encoder.
Al contrario se ad esempio per un 352*288 si richiede un Q=2 e si è disposti ad accettare anche bitrate di es. 8000 Kbit/s è molto probabile che l'encoder riesca a mantenere per tutta la durata del film un Q=2 costante.
Ovviamente quando associo Q (livello medio di quantizzazione) al discorso qualità, tutto è relativo alla qualità della sorgente video non compressa; se mantengo Q=2 per un video non compresso di qualità, otterrò un mpeg praticamente uguale all'originale; ma se tale video è pieno di rumore ( es. i disturbi di una cattiva ricezione tv, i famosi puntini !) in tal caso anche con Q =1 avrò una serie di blocchetti interminabile (facilmente visibili nei fermo immagini): per un video del genere l'mpeg per come è strutturato non può che introdurre artefatti visibili; per ovviare alla cosa occorre filtrare il video non compresso di origine ad esempio con i noti filtri di riduzione di rumore che agevolano così il compito dell'encoder nella delicata operazione della compensazione del moto.
Una ultima osservazione va fatta sull'indicazione del bit rate che in certi casi è differente da quello indicato dal file log, prodotto da tmpeg ( options/auto save future encoding logs ): il motivo sta nel fatto che tmpeg calcola il bit rate medio per ogni Gop mentre Bit rate viewer lo fa per ogni secondo: le differenze non sono eccessive ma ci sono. Per questo motivo non ci si deve meravigliare se il bit rate max impostato nei parametri delle volte viene superato (al max di un 5%): il mio suggerimento è quello di inserire un bit rate max inferiore del 5% rispetto a quello tollerabile: ad esempio nel caso di SVCD che al max tollera un video pari a 2376 Kbit/s (2600max - 224 per l'audio) non conviene inserire più di 2260 Kbit/s come valore max.
In realtà il problema dei picchi del bit rate vale anche nel caso di " bitrate costante" in cui in realtà il bit rate oscilla attorno ad un valore fissato: ciò deriva dal fatto che l'mpeg per come è strutturato non è in grado di produrre flussi di dati costanti. Il problema è che al contrario , i canali di trasmissione dati sono sempre a bit rate costante: se pensiamo ad esempio al bus ( canale dati ) che collega il DVD Rom al resto dell' hardware di un DVD player da tavolo o da un PC, questo funziona con un bit rate costante.
Senza approfondire la cosa (occorrerebbe studiare le reti di comunicazioni asincrone !!), il problema si risolve con una memoria RAM in cui parcheggiare i flussi dell'mpeg per poter assorbire i picchi e in tutti i casi ricevere dal DVD rom un bit rate costante. Il parametro che fissa la dimensione di tale memoria è il VBV Buffer size, valore che deve essere fissato a priori dall'encoder per "impacchettare i dati".
| Con Tmpeg tale
parametro lo si setta in configure/video.
Nel caso del DVD, VBV
buffer è pari a 224 mentre nel SVCD Pertanto i casi più noti; DVD
vbv = 224 KByte = 112 Blocchi |
 |
I metodi di compressione a bit rate fisso o variabile, in tmpeg vengono scelti in
|
Configure/video/ Rate control mode |
 |
Iniziamo con il metodo a bit rate costante, unico metodo che nel caso dell'mpeg 1 garantisce ampia compatibilità ( non acaso sono pochi i lettori DVD stand alone che permettono la visualizzazione di XVCD con mpeg 1 a bit rate non costante).
 |
L'unico parametro modificabile è appunto la scelta del bit rate in Kbit/s. Vediamo i risultati (Bitrate statico e Q statico si riferiscono ai primi due secondi di video): nella tabella i parametri in rosso si riferiscono ai parametri impostati, gli altri sono quelli misurati.
|
|
Dall'andamento (verde) del fattore Q essendo il bit rate fisso e "provocatoriamente basso" , si nota come Q è il minimo possibile (1) nella scena dell'immagine fissa , salta a 6 nelle colonne 3,4,5 secondi ( cioè nel tratto compreso tra 2 e 5 secondi dove c'è il panning sul volto di 7di9 ) e a causa del basso bit rate imposto è costretto a quantizzare discretamente (Q=6); in seguito la quantizzazione sale sino a 19 nel tratto finale molto dinamico (il picco è attorno ai 22 secondi, punto in cui ci saranno i maggiori artefatti) .
La qualità è accettabile anche se siamo proprio al limite della sufficienza nelle scene dinamiche in cui è evidente la "quadrettatura" con blocchetti 8*8 all'interno di blocchi più grandi (i macroblocchi 16*16).
Vediamo un secondo metodo: il metodo
 |
|
I parametri modificabili sono : Qualità
( 0= la peggiore; 100 la migliore) Gli altri due parametri che fissano il livello di deterioramento dell'immagine introdotto dai B e P frame conviene lasciarli come sono, a meno di sperimenti particolari: le degradazioni vanno da 100 a -100, rispettivamente massimo e minimo deterioramento rispetto agli I frame, per i quali il deterioramento è fissato a 0. |
 |
Ma come funziona il metodo Costant Quality CQ ?
L'encoder procede cosi: a
secondo del parametro Quality
fissato dall'utente,
viene fatta una maggiore o minore compressione; per valori di Quality elevati
viene prodotto video di alta qualità (alti bitrate) e bassa
compressione ( Q bassi
) mentre
per valori di Quality bassi , bassa qualità (alti bitrate) e elevata
compressione ( Q elevati).
Mentre tmpeg comprime analizza il bit rate prodotto: appena questo supera il
valore bitrate
Max impostato dall'utente, tmpeg aumenta la compressione (
aumenta la quantizzazione Q
) sino a garantire che il bit rate non superi il valore max impostato.
Vediamo l'esempio in cui sempre con il video test 720*576, ho impostato il valore max a 8000 Kbit/s ( = 1 Mbye/s valore molto vicino al limite massimo permesso dal DVD che al max permette 9800 Kbit a cui occorre eliminare il bit rate audio): ho compresso il video con qualità crescente; Quality 20 (qualità relativamente bassa ), 50, 60.
Anche qui nella tabella i parametri in rosso si riferiscono ai parametri impostati, gli altri sono quelli misurati.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Nel caso di qualità peggiore (Quality = 20 ) si vede come tmpeg fissa la quantizzazione a Q = 9 e poichè il bitrate tende a mantenersi ben al di sotto degli 8000 massimi riesce a mantenere Q a 9 tranne nel tratto 13- 14 secondi in cui abbassa Q ad 8 ( la differenza con Q=9 è di fatto inesistente): pertanto in questo primo esempio avendo impostato una qualità scadente e contemporaneamente non avendo posto grossi limiti al bit rate , tmpeg ha potuto mantenere tale qualità senza peggiorarla ancora.
Chiariamo come il parametro quality in tmpeg è sempre molto " generoso": quality 20 NON significa video di scarsissima qualità: nelle scene dinamiche l'mpeg prodotto arriva a superare i 5000 kbit/s che ricordo è il bit rate utilizzato ( con certe oscillazioni di pochi punto percentuali) in film DVD in vendita . Non a caso il video prodotto mantiene sempre una qualità dignitosa senza grossi artefatti visibili.
Incrementando la qualità (Quality = 50 ), tmpeg associa a tale qualità il valore Q = 3, valore che riesce a mantenere fino all'istante secondi= 12; poi è costretto ad aumentare la compressione (Q varia tra 5 e 7) nelle scene più dinamiche per non superare gli 8000 kbit/s di bitrate. La Quality = 50 garantisce un video eccellente come confermato dal bit rate che tranne nelle scene super statiche è sempre al di sopra dei 5000 kbit/s.
Nell' ultimo caso (Quality = 60) tmpeg cerca di mantenere Q = 2 cosa che riesce a fare solo in rari punti: il bit rate come confermato dal bit rate medio ( 6736 ) è quasi sempre al di sopra dei 6000 sfiorando il max ( 8000) più di una volta.
Una breve considerazione sulla scena iniziale dell'immagine fissa: con Quality = 20 il bitrate statico è di 818 kbit/s (meno del bitrate del videocd) e la qualità praticamente indistinguibile rispetto all' immagine non compressa: dando una occhiata al file log in cui sono segnate le dimensioni in Byte occupate dai frame:
Frame= 36 [I] Compressed size= 40493
Frame= 34 [B] Compressed size= 360
Frame= 35 [B] Compressed size= 360
Frame= 39 [P] Compressed size= 1800
...............
è evidente come i B e i P frame di fatto non occupano spazio mentre (360 byte sono praticamente un bit e mezzo a macroblocco, considerando come ho 1620 macroblocchi in un frame), mentre l'I frame occupa 40493 byte (circa 40 Kbyte) che è in pratica l'immagine 720*576 (formato colore 4:2:0 pari a 622.080 byte) compressa 1:15 , valore tipico di una discreta immagine compressa in jpeg ; tra l'altro la visualizazzione sul televisore pulisce ulteriormente gli artefatti che sono più evidenti sul monitor del PC.
Nel caso di Quality 60 (bitrate
statico di 1860) ho
Frame= 36 [I] Compressed size= 90605
Frame= 34 [B] Compressed size= 909
Frame= 35 [B] Compressed size= 909
Frame= 39 [P] Compressed size= 6476
...............
L'I frame è compresso di un fattore 6.8 valore al di sotto del quale non si ricavano benefici evidenti: pertanto il bitrate di 1800 è il limite di bit rate al di sopra del quale non ha molto senso andare: la cosa curiosa ( vedi dopo) che tmpeg arriverà con altri metodi a sprecare bit imponendo degli inutili bit rate di 4000 Kbit/s sempre per la scena iniziale dell'immagine fissa.
A prova di quanto sia
elevata la qualità prodotta dal parametro Quality
per valori attorno a 50-60 ho provato a comprimere lo stesso file con quality 60 ( che è ben al di sotto
di 100, massimo consentito ) sia
con video 720*576, come già visto, sia con video 352*288. I rispettivi
diagrammi sono qui sotto.
Come si deduce dal diagramma di destra del caso 352*288, il fattore Q è
mantenuto costante a 2 grazie al fatto che non sono così mai superati gli 8000
Kbit/s massimi consentiti, ma il bit rate nelle scene dinamiche si assesta tra
i 3000-5000 kbit/s valore obbiettivamente troppo alto: con 352*288 bastano
e avanzano bit rate di 2000-2500 Kbit/s.
Nel caso 720*576 è evidente ,come già detto, che è impossibile mantenere Q=2;
considerando come nei tratti in cui Q=2 il diagramma di sinistra ha
bit rate 3 volte superiori rispetto a quelli di destra, è ragionevolmente
ipotizzabile che per mantenere sempre Q=2 anche nel caso di 720*576
occorrerebbero picchi di circa 16000 Kbit: per questo motivo l'encoder è spesso
costretto ad aumentare la compressione. Detto in altri termini pur mettendo
Quality= 60 il bit rate max di 8000 nel caso 720*576 costringe tmpeg ad
abbassare quasi sempre la qualità comprimendo nella stessa maniera di una
selezione di qualità inferiore (tipo quality = 50-40).
Si spiega così il motivo per cui nei 3 diagrammi visti sopra, nei punti con scene dinamica (oltre i 13 secondi) i bit rate tra il caso Quality 50 e 60 sono praticamente identici ! ; tmpeg non potendo mantenere il bit rate teoricamente richiesto da impostazioni di qualità così alte, è costretto a diminuire la qualità aumentando in entrambi i casi la compressione che si avvicina quasi sempre al max impostrato.
|
||||||||||||||||||||||||||||||||||||||||||
|
Vediamo ( nelle tabelle qui sotto) come si comporta tmpeg nel caso in cui fissando una elevata qualità (quality = 60) si impostano bit rate max decrescenti 8000 ,5000 e 2000.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Poichè è stata impostata quality = 60 , tmpeg cerca di comprimere con un fattore di quantizzazione Q=2: riesce a farlo fino a che tale blanda compressione produce bit rate inferiore a quello max; appena ciò non è più possibile l'encoder è costretto ad aumentare la compressione ( e di conseguenza Q) producendo un bit rate circa costante e pari al Max impostato.
Tale intervento nel caso di bit rate max di 8000 lo si ha dall'istante secondi= 11 e in un tratto 6-8 sec; nei casi bitrate max 5000 e 2000 il "taglio" del bit rate lo si ha subito, al termine dei 2 secondi di immagine fissa: da lì in poi il bitrate rimane circa costante attorno al valore max impostato.
Nel caso di bitrate max = 2000,valore esageratamente basso si hanno quantizzazioni elevatissime con picchi di Q =25 e artefatti a non finire: del resto con tale bitrate è possibile codificare video di qualità 352*288 che sono un quarto dei pixel presenti in frame 720*576.
Ecco in breve le conclusioni riguardo il metodo CQ ( costant quality).
1) E' il metodo da utilizzare in tutti quei casi in cui è fondamentale risparmiare il più possibile sulla dimensione dei file, e pertanto cercare di guadagnare il più possibile spazio nelle scene statiche dove si può ragionevolmente abbassare il bit rate: è il caso dei DVD con problemi di spazio (es 130 minuti in un DVD 5), e nei MiniDVD o SVCD in cui a seguito del limite di spazio del CDR il risparmio di bit può significare inserire preziosi minuti di video.
2) Spesso a causa della
grossa variabilità nel bit rate risulta difficile prevedere lo spazio
occupato dal filmato: ovviamente il tutto è legato ai parametri impostati, e
l'esperienza di chi fissa i parametri diventa fondamentale nella previsione
dello spazio occupato: ad esempio se si utilizza video 720*576 , quality 50 e un
bitrate max di 3000 è ovvio che il bit rate medio sarà all'incirca pari al max
poichè 3000 è troppo poco. Otterrò quindi in media circa 3000 Kbit/s cioè
375 Kbyte/s pari a 21.9 Mbyte per ogni minuto di video.
Al contrario se elevo il bitrate max a 5000 è ragionevole supporre che la
media sarà al di sotto del max: come appare nel diagramma qui sotto ottengo un
bitrate medio di 4300 buon compromesso compressione / qualità.
|
|
3) Il parametro quality se settato a valori alti (50-65) di fatto ha influenza diretta solo nelle scene più statiche: nelle scene dinamiche chi in realtà fissa la qualità è il bit rate max impostatoin : ovviamente il discorso non vale nel caso di bit rate max troppo bassi (il famoso 3000 kbit/s per video 720*576) in cui il parametro quality di fatto non condiziona niente poiché il bit rate diventa fisso e pari al massimo mentre la qualità varia a causa della complessità della scena.
4) Il parametro Quality oltre i valori quali 60-65 non arreca nessuna variazione apprezzabile poiché chi crea il limite è il bit rate max.
5) Riguardo ai valori di picco da inserire un buon punto di partenza sono le tabelle riassuntive prima viste.
Il CQ è il metodo che conviene utilizzare per la codifica nel formato SVCD, 480*576: infatti il limite max imposto dal formato (2600 kbit/s per audio +video che limita a 2376 Kbit/s (2600max - 224 per l'audio) il max bitrate video) fa si che a seguito dei bassi bitrate max possibili e a seguito della bassa capienza dei cdr si deve cercare di risparmiare bit rate nelle scene statiche . Poichè il bitrate max è fissato, e ovviamente non ha senso scendere ancora di più, l'unico parametro variabile è quality (0-100).
Per tutti i discorsi fatti solo con valori di quality inferiori a 50 è possibile abbassare , se pur di poco, il bit rate medio.
Ecco una tabella riassuntiva nelle ipotesi di risoluzione 480*576 e bit rate max = 2260 Kbit/s. Come valore max mi sono attenuto al caso di perfetta aderenza allo standard (2376 max che con il margine del 5% per l'assorbimento dei picchi mi da 2260). Ovviamente è possibile salire di bit rate facendo dei SVCD fuori standard: ad esempio con il Pioneer DV 525 e con l'Olidata 1999E è possibile salire sino a 2500 kbit/s per il video; i con i player per PC è possibile salire sino a 9800 Kbit/s ( una panoramica completa la trovate su Formati digitali e compatibilità con i player DVD ).
| Quality | Bitrate medio | Dimensione
file (audio224 kbit/s + video) |
| 100 | 2260 | 7.41 Mbyte |
| 75 | 2260 | 7.41 Mbyte |
| 65 | 2254 | 7.40 Mbyte |
| 58 | 2190 | 7.20 Mbyte |
| 50 | 2110 | 6.96 Mbyte |
| 45 | 2043 | 6.76 Mbyte |
| 40 | 1963 | 6.52 Mbyte |
| 30 | 1826 | 6.11 Mbyte |
| 20 | 1665 | 5.64 Mbyte |
| 0 | 1294 | 4.64 Mbyte |
Si nota come salendo oltre 65 non c'è assolutamente nessuna differenza o guadagno nel bit rate: al contrario dai diagrammi qui sotto (3 casi significativi) si vede come nelle quality comprese tra 45 e 65 è possibile guadagnare qualcosina sulle scene statiche: oltre il punto secondi= 11, i bit rate e le quantizzazioni sono identiche. Al contrario scendendo sotto 45 si risparmia bit rate in tutte le scene non particolarmente dinamiche mentre i quelle dinamiche non è possibile guadagnare quasi nulla (le scene successive al punto sec.=12)
Riguardo la qualità questa è ancora sufficiente per quality>= 45: per valori sotto 45 gli artefatti sono spesso molto visibili anche nelle scene statiche. Con quality=0 ovviamente ci sono sempre artefatti e quadrettini. Ecco le tabelle di 3 casi significativi del formato SVCD 480*576
|
Passiamo ad un'altro metodo di codifica: il
|
Bit rate video auto variabile a qualità costante CQ_VBR |
 |
|
I parametri modificabili sono : Qualità
( 0= la peggiore; 100 la migliore) Riguardo al Minimo bit rate consentito conviene lasciare 0: considerando l'approccio utilizzato dal metodo CQ_VBR i bit rate minimi in realtà non si allontaneranno molto dai valori massimi e pertanto nulla cambia se si immette un valore diverso da zero. L'unica possibile alternativa è immettere un valore molto vicino a quello massimo ma normalmente tale scelta conviene lasciarla fare in maniera intelligente a tmpeg (come vedremo) |
 |
Se nel metodo CQ Tmpeg fissa la qualità in base al parametro quality e taglia il bit rate ogni volta che questo tende a superare il max consentito, l'approccio del metodo CQ _VBR è esattamente speculare: tmpeg in base al bit rate max fissato cerca fare oscillare il bitrate al di sotto del MAX bit rate impostato, di una quantità che è tanto maggiore quanto più basso è il fattore di qualità Q. A Q=0 corrispondono le max oscillazioni del bit rate al di sotto del MAX, mentre per Q=100 (ma spesso basta 60) si hanno le minime oscillazioni (bir rate quasi costante e pari al max).
L'effetto di questo approccio è che:
1) Ho una compressione spesso troppo blanda anche nelle scene statiche a seguito di oscillazioni troppo piccole: ciò comporta uno spreco di bit anche eccessivo in tali scene in cui si potrebbe incrementare la compressione anche senza aggiungere artefatti visibili.
2) Come ovvia conseguenza il bit rate medio tende molto facilmente a raggiungere quello massimo consentito e ciò è evidente quando si immettono valori di quality superiori a 55-60; si arriva spesso al caso in cui ulteriori incrementi del parametro quality non arrecano nessun miglioramento della qualità di compressione poichè le oscillazioni attorno al max bitrate sono le minime consentite dal metodo e si ha una compressione molto simile a quella a bit rate fisso: vedremo dopo l'esempio di mpeg prodotti con valori di quality compresi tra 48 - 100 e bit rate max 5000, che producono un file bit a bit pari al caso quality =48.
3) Il vantaggio del metodo CQ _VBR è che per quanto appena detto è più semplice prevedere il bit rate medio e pertanto l'occupazione del file; tali valori sono molto meno sensibili al tipo di scene presenti nel filmato ( statiche o molto dinamiche) che nel caso CQ.
Per quanto detto è consigliabile usare il metodo CQ_VBR in tutte quelle situazioni in cui non è prioritario il risparmio di spazio occupato e pertanto pur di garantire la qualità si è disposti anche ad uno spreco di bit. I casi possibili sono tanti: ad esempio back-up di materiale video di particolare importanza o authoring di DVD nei casi in cui il supporto è sovradimensionato rispetto ai propri bisogni. (Ricordo che un DVD 9 con i suoi 8 500 000 000 byte nel caso di max bit rate consentito dallo standard, 9800 Kbit/s, può contenere sino a 115 minuti di video: se pertanto devo codificare un film di 100 minuti e null'altro, il problema del risparmio di bit non si pone !).
Ciò ovviamente non significa che il metodo CQ non consente codifiche di qualità: significa solo che tende maggiormente a risparmiare bit e quindi è potenzialmente "più a rischio" nel creare artefatti a parità di parametri quality e max bitrate rispetto al caso CQ_VBR.
Analizziamo i grafici del bit rate e fattore di quantizzazione: per valutare le differenze con il caso CQ ho inserito nelle tabelle i valori del caso CQ scritti in piccolo a destra dei corrispondenti valori del caso CQ_VBR ( a parità di parametri); per i grafici ho inserito prima i 3 casi CQ_VBR e più giù nello stesso ordine gli analoghi casi ( già visti e commentati) della codifica CQ. Viste le dimensioni delle tabelle suggerisco la visualizzazione del browser a tutto schermo ( F 11 per Microsoft Internet Explorer)
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Nel primo caso (a
sinistra) in cui Quality=20 e bit rate = 8000, nel caso CQ
avevo visto come tmpeg, associa a Quality=20 il valore Q
= 9 e comprime quasi
sempre con tale fattore (linea verde orizzontale tranne in sec 13-14) poiché a
seguito della pesante quantizzazione (Q=9) il bit rate si mantiene sempre al di
sotto dei 8000 Kbits/s.
Nel caso CQ_VBR invece
il valore relativamente basso di Quality suggerisce delle ampie oscillazioni
verso il basso del bitrate , sotto il max (8000 Kbit).
Vediamo quali sono gli effetti dell'approccio CQ_VBR: è evidente un incremento del bit rate in tutte le scene statiche (la prima metà del video), cosa che innalza il bitrate medio da 3233 (CQ) a 4425 (CQ_VBR) con un incremento del 37% di spazio occupato. Nelle scene dinamiche l'incremento del bit rate è più contenuto. Interessante notare come il bit rate statico ( i primi due secondi) passa da 818 (CQ) ad un esagerato 2198 (CQ_VBR); quasi si triplica.
Riguardo la qualità visiva le differenze ci sono ma non sono evidenti ad un osservatore non allenato: ovviamente chiunque può fare dei test e valutare se l'incremento di occupazione coincide realmente con un incremento di qualità visibile.
Considerando gli altri
due casi (Quality 50 e 60) si vede chiaramente come ho delle oscillazioni
al di sotto di 8000 più contenute rispetto al caso quality= 20; ne è
prova il bit rate statico che passa da 2198 (quality 20) a 4725 (quality
50).
E' importante notare come i diagrammi dei casi quality=50 e quality=60 sono
praticamente identici se si elimina il primissimo tratto (immagine ferma) che è
un caso limite che nei film in realtà non si trova mai: non a caso i bit rate
medi e pertanto le occupazioni di spazio dei file sono di fatto uguali.
Rispetto al caso CQ è evidente come la compressione è sempre inferiore e in particolar modo nelle scene statiche: per convincersene basta osservare come quality 50 CQ_VBR (bit rate medio 7536) produce una compressione minore e quindi qualità potenzialmente superiore rispetto al caso quality 60 CQ (bit rate medio 6736). Dico "potenzialmente" perché andrebbe verificato come tale migliore qualità sia effettivamente visibile: nella pratica le qualità sono analoghe poiché le differenze di bit rate le si hanno unicamente nelle scene statiche in cui il bitrate prodotto dalla codifica CQ_VBR è sovrabbondante. Ciò dimostra come il metodo utilizzato in certi casi è più importante del valore numerico del parametro Quality. Riporto per comodità i due casi affiancati.
|
||||||||||||||||||||||||||||||||||||||
|
Una ulteriore osservazione sul
dato del bit
rate statico che ricordo è un caso limite (immagine fissa ripetuta per 50
frame) inserito per valutare la capacità dell'encoder nell'ottimizzare il bit
rate: come già detto da prove visive appare evidente come un bit rate
attorno a 1850 kbit/s basta a garantire un frame praticamente identico al caso
non compresso (è il valore del caso CQ e Quality = 60).
Nel caso CQ_VBR ho un
valore 2.5 volte superiore assolutamente sovradimensionato rispetto a quanto
realmente serve. Ecco in parallelo le occupazioni dei frame (ricordo come
il frame 720*576 non compresso 4:2:0 occupa) 622.080 byte
|
CQ_VBR |
CQ |
| Frame= 36 [I]
Compressed size= 142817 (compres. 1 : 4.3) Frame= 34 [B] Compressed size= 9518 Frame= 35 [B] Compressed size= 7329 Frame= 39 [P] Compressed size= 26471 |
Frame= 36 [I] Compressed size= 90605 (compr. 1 : 6.8) Frame= 34 [B] Compressed size= 909 Frame= 35 [B] Compressed size= 909 Frame= 39 [P] Compressed size= 6476 |
E' evidente nel caso di sinistra enormi sprechi nel bit rate : uno tra tutti il frame 39 (P) che occupa 4 volte lo spazio occupato nel caso di destra: e sto parlando di un P frame che in realtà può essere codificato con dei banali skipped Block che occupano pochissimi bit (sono i macroblocchi che comunicano al decoder di lasciare il blocco esattamente come era nel fotogramma precedente con un esiguo spreco di spazio !! ).
A prova di come in realtà nella compressione CQ_VBR un valore di Quality pari a 60 di fatto tende a creare una compressione a bit rate costante, attorno al valor max, seguono 3 casi in cui ciò che cambia è il bit rate max: 8000, 5000 e 2000. I bit rate medi tendono ad essere quasi pari a quelli max impostati.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Voglio osservare come tale comportamento è molto simile a quello prodotto da alcuni DVD video in commercio, tra cui alcuni film recenti di Cecchi Gori (Nirvana, La vita è Bella....) in cui l'andamento è molto simile a questo appena visto. Al contrario per i DVD in cui l'andamento del bit rate fluttua anche all'interno di una finestra di 3000-3500 Kbits (uno tra tutti Tarzan) l'approccio è quello CQ.
Concludo la lunga carrellata degli esempi con un caso (bit rate Max = 5000 e quality variabile da 0 a 100) in cui appare evidente come superato un valore di quality (nell'esempio 48) il video prodotto rimane sempre lo stesso: cioè per qualsiasi valore di quality compreso tra 48 e 100 il file prodotto è lo stesso.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
E' evidente come nel caso di quality = 0, avendo
un fattore Q pari compreso tra 28 e 30 ( il massimo consentito ) più che un
video ho un insieme di pixel giganti aventi dimensioni 8*8: assolutamente
inguardabile, come ovvio visto il bitrate prodotto. Già con quality pari a 10 e
un bitrate medio di circa 2200 Kbits/s la qualità è sufficiente e gli
artefatti sono visibili ma fortemente mascherati. Gli ultimi 3 casi che
producono un bitrate medio poco sotto il max consentito sono praticamente
identici e di ottima qualità ( le minime differenze appaiono solo sui diagrammi
nei primi secondi di video ): visivamente non è possibili osservare differenze.
Dovendo concludere riguardo la scelta tra CQ e CQ_VBR il mio consiglio è usare CQ nel caso in cui è prioritario risparmiare sullo spazio occupato dal file e CQ_VBR se è prioritaria la qualità.
Riguardo i parametri Quality e bitrate max è fondamentale la scelta del bitrate max che ovviamente dipende dalla qualità che si vuole ottenere e dallo spazio a disposizione per i file.
Per il parametro quality nel caso di CQ_VBR valori tra 10-25 sono da utilizzare per ottenere video di qualità compresa tra il sufficiente e il buono , mentre tra 25-50 per ottenere qualità tra il buono e l'ottimo: superare i 50 quasi sempre non produce alcun incremento di qualità.
Nel caso del metodo CQ il parametro quality va settato con valori leggermente superiori: tra 15-35 per video di qualità compresa tra il sufficiente e il buono e valori tra 35 e 60 per ottenere qualità tra il buono e l'ottimo: superare i 60 quasi sempre non produce alcun incremento di qualità, poichè vi è sempre un taglio dovuto al max bitrate.
Con una analisi attenta dei grafici, una serie di test " mirati" insieme ai valori che ho indicato nelle tabelle sarà possibile, spero, una certa padronanza nell'utilizzo dei parametri.
Passiamo ad un'altro metodo di codifica: la
|
Codifica a due passaggi, con bit rate variabile VBR |
 |
|
I parametri modificabili sono : Bit rate medio (Average
bit rate) (in Kbit/s) |
 |
Il metodo utilizzato consiste in un primo passaggio in cui viene analizzato tutto il filmato per valutarne il grado di complessità nei diversi punti (% di scene statiche, dinamiche...) e in un secondo passaggio, la compressione vera e propria, in cui in base ai parametri immessi tmpeg realizza un mpeg avente esattamente il bit rate medio impostato e delle oscillazioni che dipendono da come si sviluppa il video nel tempo e ovviamente limitate dai min e max impostati.
Dai test fatti appare chiaro come nel caso di bit rate minimi lontani dalla media, tali minimi non vengono mai neanche lontanamente sfiorati (vedi i due esempi che seguono); per il massimo il bit rate tende spesso a mantenersi a " debita distanza".
Il vantaggio di tale metodo è che è possibile prevedere esattamente la dimensione del file come nel caso del bitrate costante con i vantaggi dell'utilizzo di una codifica a bitrate variabile e quindi ottimizzata rispetto al tipo di scene presenti nel filmato. Lo svantaggio è che l'encoder impiega esattamente il doppio del tempo per la compressione.
Dall'analisi dei grafici appare una impostazione di base che tende a non ottimizzare al massimo le scene statiche per le quali il bitrate utilizzato mi sembra delle volte eccessivo (vedi gli elevati bitrate statici che alla luce di quanto detto prima sono assolutamente non ottimizzati.)
Ecco due esempi: anche qui nella tabella i parametri in rosso si riferiscono ai parametri impostati, gli altri sono quelli misurati:
|
||||||||||||||||||||||||||||||||||||||||||
|
Da osservare come tale metodo a doppia passata non funziona nel caso si crea la catena Flaskmpeg-->avisynth-->tmpeg mentre funziona tranquillamente nella catena Premiere-->avisynth-->tmpeg, che tra l'altro ho usato per i test.
Riguardo l'utilizzo della catene che permettono di sfruttare tmpeg come plug-in per premiere vi rimando agli innumerevoli articoli presenti nella sezione Digital Video del mio sito.
Tmpeg permette altri due metodi di codifica che sono appositamente pensati per la compressione per flussi mpeg da trasmettere via streaming, ovvero in tempo reale su canali di trasmissione a larga banda, visto i tipici bitrate dell'mpeg. Considerando come il caso più rapido di una linea ISDN a 128 Kbits/s è un ordine di grandezza sotto il minimo richiesto per un video mpeg al minimo della decenza (almeno 1000 Kbits/s per un 352*288) e considerando come per le linee a banda larga occorrerà aspettare ancora un bel po', per la " normale utenza italiana " tali metodi sono assolutamente inutili.
In pratica tmpeg in tali codifiche deve ottimizzare il flusso del bitrate all'interno di brevi istanti temporali (la dimensione dei GOP che hanno durata inferiore al secondo) per evitare di creare dei picchi che in fase di streaming creerebbero problemi di bitrate in trasmissione.
A causa della scarsa ottimizzazione della compressione all'interno dei singoli GOP e poichè non c'è alcun guadagno qualitativo rispetto agli analoghi metodi esaminati non c'è alcun motivo per usarli se non ci sono esigenze di streaming: i due possibili casi sono .
|
Qualità costante, modalità streaming RT_CQ |
 |
|
Bitrate costante, modalità streaming RT_CBR |
 |
Per il metodo RT_CQ ho i medesimi parametri dell'analogo metodo CQ
|
Seguono le due tabelle da cui si evince come in realtà dal punto di vista del bitrate le differenze sono assolutamente trascurabili ( le differenze sono fondamentalmente nella distribuzione del bit rate all'interno dei GOP)
|
||||||||||||||||||
|
Il metodo RT_CBR essendo un metodo a bit rate costante ha come unico parametro il bit rate.
L'ultimo metodo da analizzare è il metodo
|
Bit rate variabile manualmente MVBR |
 |
In pratica con tale metodo è possibile scena per scena fissare il bitrate manualmente entro il limite fissato a priori dal parametro Max bit rate.
|
I parametri modificabili sono gli stessi del caso CQ : Qualità
( 0= la peggiore; 100 la migliore) Gli altri due parametri che fissano il livello di deterioramento dell'immagine introdotto dai B e P frame conviene lasciarli come sono, a meno di sperimenti particolari: le degradazioni vanno da 100 a -100, rispettivamente massimo e minimo deterioramento rispetto agli I frame, per i quali il deterioramento è fissato a 0. |
|
Tmpeg, ha la incredibile capacità di poter forzare manualmente per tutti i metodi visti la caratteristica dei singoli frame (I,P,B) : è in grado addirittura di poter fissare per ciascun I frame una diversa matrice di quantizzazione. In più, e questo SOLO con il metodo MVBR è possibile come già detto fissare per ciascuna scena e con la precisione del singolo fotogramma il bit rate.
Ciò viene fatto potendo vedere i fotogrammi in striscia, cosi come per i sw di editing non lineare, tipo premiere; comodissimo e immediato: non esiste assolutamente nulla di simile nei sw in commercio..
Grazie a tali potenzialità è possibile manualmente fare una infinità di test poiché si è in grado di modificare praticamente ogni parametro disponibile.
Ovviamente è possibile ottimizzare la compressione senza poi fare tantissimo lavoro; in particolare si possono variare i bit rate anche su scene molto lunghe. Per esempio per un video 720*576 si può decidere di fissare 7000 Kbits/s per le scene dinamiche e 5000 per quelle statiche. Normalmente una scena di un certo tipo ( d'azione o statica) dura spesso parecchi minuti ed è pertanto necessario modificare il bitrate solo poche volte. Non avrebbe senso per filmati di lunga durata variare il bitrate magari ogni 2 o 3 secondi; un lavoraccio per cui non ne vale certamente la pena ( immagino che tortura per un film di 2 ore).
Per accedere al settaggio
dei frame e i bitrate occorre selezionare Configure/GOP structure selezionare
force frame type e cliccare su configure
.
Sarà automaticamente deselezionato "Detect scene changes", operazione che si potrà far compiere automaticamente a tmpeg tramite l'opzione Auto-set. (vedi sotto)Automa
 |
Per selezionare le caratteristiche di ogni frame basta cliccarci sopra con il tasto destro del mouse. Le modifiche saranno poi indicate sia sotto il singolo frame sia nella colonna a sinistra (che si potrà memorizzare).
Auto-set
: seleziona automaticamente gli I frame identificando i cambi scena ( è
possibile selezionare il parametro di sensibilità).
Rate-info
: utilissimo nel caso del metodo MVBR
in cui variando il
bitrate manualmente è possibile sapere il bit rate massimo , minimo e medio:
quello medio permette il rapido calcolo dello spazio occupato (con la formula
che avevo visto all'inizio) .
Clear
: cancella la lista (azzera le impostazioni) .
I parametri che possono essere selezionati per ogni frame (click destro con il mouse) sono:
I
: ( tasto I o click sinistro mouse) forza I frame
P
: ( tasto P) forza P frame
B
: ( tasto B) forza B frame
P copy
: ( tasto shift +P) forza il frame ad essere un P frame formato da macroblocchi
di tipo Skipped
Block: con una
occupazione di pochissimi byte il frame così impostato fa si che il decoder
deve lasciare visualizzato il frame I o P precedente: è il caso
ideale dei primi due secondi del filmato di test in cui c'è una immagine
statica. Nella pratica può servire per fare degli slide show in cui si lasciano
gli I frame con le immagini e tramite i P o B frame cosi impostati si bloccano
tali immagini con un consumo irrisorio di bit. E' possibile fare una
impostazione di questo tipo sfruttando la tastiera ( tasto shift+P per settare
il frame e la freccia -> per andare al frame successivo)
B copy
: ( tasto shift+B) forza il frame ad essere un B frame formato da macroblocchi
di tipo Skipped
Block: analogo
al caso di prima.
None
: ( tasto N) cancella per il frame selezionato ogni impostazione
Set Bitrate
: ( tasto Invio) opzione funzionante solo per il metodo MVBR
, fissa il
bitrate costante
a partire dal frame selezionato sino ad un nuovo settaggio. (nella pratica ci
sono delle leggere oscillazioni al di sotto del max fissato, normalmente
contenute ad un 5-10%)
Qualità
dell'immagine : (
tasto M) seleziona quante volte migliore rispetto ad un I frame di
riferimento debba essere la qualità del frame selezionato (1,2 significa
qualità 20% superiore, 1,5 qualità 50% superiore, mentre 0,8 significa
qualità 20% inferiore 0,5 qualità 50% inferiore........); nei test fatti tali
impostazioni sembrano non produrre alcun effetto !!
Matrice di quantizzazione : (
tasto Q ) è possibile inserire una nuova matrice di quantizzazione che verrà
usata a partire da tale punto: automaticamente il frame diventa di tipo I
Set frames......:
seleziona i tipi di frame secondo un GOP fissato (es ibbpbpb): tale impostazione
verrà imposta per tutti i frame successivi , sino al frame (seguente) in cui è
settato un nuovo bit rate.
Per spostarsi sui diversi frame è possibile farlo sia con il mouse, sia cliccando sul relativo frame presente nella colonna a sinistra, sia usando i tasti.
Per usare la tastiera occorre per la prima volta selezionare un frame cliccando con il mouse sul suo numero (e non la immagine): poi
-> (freccia a destra)
frame successivo (con shift si sposta di 2 frame)
<- (freccia a sinistra) frame precedente (con shift si sposta di 2 frame)
ctrl e -> (tasto ctrl e freccia a destra) ultimo frame
ctrl e <- (tasto ctrl e freccia a sinistra) primo frame
freccia in alto o in basso: modifica ciclicamente il frame tra I,P,B o nessuna
selezione.
Concludo sottolineando anche l'uso didattico di un tale livello di intervento sulla compressione; per valutarne gli effetti conviene visualizzare il file di log (option/show encoding log) e memorizzarlo (option/auto save future encoding logs).
Ovviamente Tmpeg per rimanere conforme alle specifiche dello standard ignora le "forzature" che renderebbero il video fuori standard: non ci si deve meravigliare se impostazioni molto strane vengano poi ignorate !.
Prima di terminare un breve accenno alle opzioni presenti in configure/ advanced:
 |
Tale sezione è relativa all'elaborazione dell'immagine che è fatta al video PRIMA di essere convertito in mpeg: per modificare i parametri basta un doppio click sulla relativa elaborazione; il segno di selezione (X) applica o meno l'effetto.
E' importante osservare come tali opzioni NON sono memorizzate nei Presets (i template che si caricano e memorizzano con load e save in basso a destra della schermata principale)
Vediamo le opzioni di video source settings :
Video source
type: interallacciato o non
interallaciato. Tale opzioni non hanno nulla a che
vedere con il metodo di compressione (interallacciato o meno ) dell'mpeg 2,
metodo selezionabile nella sezione configure/video che ricordo permette la
corretta compressione del video interallacciato.
L'opzione in questo caso INFLUENZA SOLAMENTE IL METODO CON CUI EVENTUALMENTE E'
RIDIMENSIONATO IL VIDEO
Consideriamo
come esempio un video che contiene il seguente frame ( che se memorizzato in
formato BMP, potete tranquillamente usare come test).
Tale frame (720*576) che ho scelto a due colori per non appesantire i tempi di caricamento (così occupa solo 2 Kbytes) , è il tipico frame proveniente da un video interallacciato.
Vediamo come l'opzione interlaced o non interlaced modifica il ridimensionamento.
Tutte le opzioni di ridimensionamento dal filmato originario (di dimensioni che chiamo Fx, Fy) all'mpeg (di dimensioni che chiamo Mx , My) dipendono da tre parametri:
1) Risoluzione video scelta per l'mpeg (Mx, My) (configure/video/size xxx*xxx pixels): sono i tipici valori dell'mpeg 720*576, 704*576, 480*576, 352*576, 352*288 e ovviamente tutte le risoluzioni non standard ( raramente usate)
2) Source aspect ratio : decide quale è il rapporto larghezza altezza del video originale Fx, Fy (1:1 vga, 4:3 625 linee PAL,16:9 625 linee PAL...)
3) Image positioning method: descrive come il video originale (Fx, Fy) , con le proporzioni scelte dal parametro Source aspect ratio deve essere inserito nel frame mpeg avente dimensioni (Mx,My)Le
Riguardo l'opzione Field order, questa è importantissima ogni volta che si comprime un video interallacciato con una risoluzione del tipo XXX * 576, che comprende cioè entrambi i campi video. Poiché le diverse schede di digitalizzazione possono utilizzare la convenzione secondo cui il primo campo da digitalizzare è quello pari (Even, detto anche field A) o al contrario dispari (Odd, detto anche field B), occorre semplicemente fare un banale test: comprimere XXX*576 un mpeg2 con l'opzione interallacciata (video /interlaced) e vedere quale dei due casi (field A o B) va bene: è facile accorgersene poiché nel caso errato l'immagine si muoverà a scatti e sarà come divisa in due metà orizzontali. Il test andrà fatto con un player mpeg HW su di un televisore poiché i player sw tendono a compensare tale errore.
Occorre osservare che per la maggior numero dei casi NON OCCORRE FARE ALCUN RIDIMENSIONAMENTO: cioè normalmente digitalizzo 720*576 e comprimo 720*576 o digitalizzo 352*288 e comprimo 352*288.
In tutti
questi casi l'opzione
interlaced o non interlaced è assolutamente ininfluente
così come lo è Source
aspect ratio:
l'unica cosa che occorre settare è
Image positioning
method
( nelle versioni precedenti alla b12a tale opzione era detta Full Screen).
Ovviamente non posso elencare tutti i casi possibili , ma vi ricordo che per vedere gli effetti dei tre parametri visti, le corrette dimensione del l'mpeg prodotto e l'effetto di tutti i filtri applicati , si può utilizzare la opzione preview (file/preview): preview visualizza esattamente come viene passato il video all'encoder mpeg, o detto in altri termini visualizza il filmato mpeg supposto di qualità massima (pari cioè al video non compresso).
Cliccando con il tasto destro è possibile ingrandire sino a 4X o copiare il frame elaborato nella clipboard: tmpeg diventa rapidamente un programma di fotoritocco, considerando che può tranquillamente avere in ingresso un Bitmap.
Considero solo certi casi , nel momento in cui grazie al preview è banale fare prove e scegliere i parametri giusti.
1)
Digitalizzazione di video PAL con risoluzione 384*288
e realizzazione di un mpeg 352*288
( dimensione del VCD e del XVCD) : è un caso frequente poichè esistono delle
schede che non permettono la digitalizzazione 352*288. Poichè le schede
digitalizzano mantenendo il corretto rapporto larghezza/ altezza occorre
lasciare tutto come nel caso di digitalizzazione 352*288: cioè
Image positioning method
e ovviamente risoluzione del video 352*288. La correzione del formato la si ha
guardando in full screen il video o ridimensionando la finestra in formato
avente proporzioni 4:3. Se il player riconosce il tag mpeg di formato, che ho
visto lo si setta in video/aspect ratio, occorre metterlo con il valore
"4:3 display" per video non anamorfico o "16:9
display" per video anamorfico. Uno dei pochi player che riconosce tale Tag
è il windows media player 6.4 con l'opzione full screen.
2)
Digitalizzazione di video PAL con risoluzione 768*576
o 704*576 e
realizzazione di un mpeg 720*576
(DVD)
o 480*576 e 352*576 (SVCD)
. Anche in questo caso non occorre fare alcuna elaborazione e lasciare come
sopra Image
positioning method .Il
player dovrà poi ridimensionare nelle giuste proporzioni.
3) Conversione da video anamorfico 16:9 720*576 a video non anamorfico 720*576 o 480*576 o 352*576: è il caso non raro in cui partendo dal video di un DVD anamorfico desidero convertirlo in mpeg2 ma con un bitrate più basso (ad esempio quello del SVCD. In tal caso conviene trasformare il video in non anamorfico , poichè grazie alla presenza di bande nere e quindi di una minore risoluzione è possibile diminuire gli artefatti causati dal basso bitrate.
In tal caso occorre settare: Source aspect ratio = 16:9 625 linee PAL e Image positioning method fit to frame/preserve aspect ratio. Sono nell'ipotesi in cui il video d'origine è anamorfico, ad esempio film anamorfico passato a tmpeg tramite Flaskmpeg/avisynth SENZA l'opzione di flask "mantieni il rapperto larghezza/altezza". Nel caso in cui in flask si seleziona "mantieni il rapperto larghezza/altezza", occorre al contrario lasciare tutto come nei casi 1 e 2 poichè il ridimensionamento la fa flask
In questo caso è importante l'opzione Video source type: interallacciato o non interallaciato che deve essere settata in base al tipo di video ( gran parte dei servizi speciali di un DVD sono in formato interallacciato). Nel caso dell'opzione "interallacciato" viene rispettata l'alternanza dei campi pari e dispari, nel caso "non interallacciato" viene fatta l'interpolazione del frame distruggendo i campi pari o dispari.
 |
|
|||||
 |
|
Nel secondo caso è evidente che un eventuale video così convertito presenterebbe un forte rumore video nei punti in movimento.
4) Digitalizzazione di video PAL interallacciato con risoluzione 768*576 o 704*576 e realizzazione di un mpeg 352*288.
In questo
caso occorre utilizzare uno dei filtri che realizzano il deinterallacciamento:
la questione è stata affrontata nell'articolo Il
video nel formato Pal: interallacciamento e video digitale.
Con Tmpeg è
possibile fondamentalmente lasciare il campo pari o dispari o fare il blend tra
i campi : esistono altri metodi più complessi che considerano pure l'andamento
dei frame precedenti. Il filtro da utilizzare è DEINTERLACE.
Riguardo l' image
positioning method basta normalmente settare
Voglio invece far osservare che se non utilizzo nessun filtro di deinterallacciamento, tmpeg ovviamente fa la interpolazione lineare tra i campi realizzando la "orribile marmellata" tra campi diversi che si traduce in rumore video.
 |
E'
evidente come i campi pari e dispari vengono banalmente interpolati.
L'immagine in movimento presenta il tipico " effetto scia " nei particolari che sono in moto, che sembrano come seguiti dal loro fantasma ! |
5) Concludo con un caso un pò particolare che è : digitalizzazione di video PAL interallacciato con risoluzione es. XXX*520 ( es. 768*520 720*520 o 704*520 ) e realizzazione di un mpeg 720*576 (DVD) o 480*576 e 352*576 (SVCD).
E' il caso di alcune schede digitalizzatrici che non digitalizzano tutti i campi risparmiando a seguito delle tolleranze dei televisori sulla risoluzione verticale. Grazie alla potenza di tmpeg è possibile realizzare ciò banalmente con l'opzione
dove in pixel occorre inserire 480*520 per ottenere video 480*576 (ovvio che video/size= 480*576) o 352*520 per ottenere video 352*576 (size = 352*576) o 720*520 per ottenere video 720*576 (size =720*576).
Ovviamente nel frame mpeg saranno inserite sopra e sotto due bande nere pari alla differenza tra 576 e 520 diviso 2 (28 pixel per banda).
Riguardo ai filtri video di tmpeg
|
come gia detto sono modificabili con un doppio click e per selezionarli o meno basta il segno di selezione (X) sulla sinistra.
Tutti i filtri permettono la previsualizzazione in tempo reale dei risultati del singolo filtro: tramite "enable filter" si attiva o meno per valuterne le differenze. Per vedere gli effetti globali occorre andare in file/preview.
I filtri disponibili:
1) Source frame range: più che un filtro serve per decidere se convertire solo uno una parte del video o l'intero filmato; permette di selezionare il punto di inizio e di fine conversione (start e end frame). E' possibile fissare un offset positivo o negativo con l'audio per compensare eventuali sfasamenti tra audio e video (audio Skew): utilissimo !
2) Inverse Telecine : metodo utilizzabile per convertire video NTSC XXX*480 30 frame/s o 60 campi al secondo in frame a 24 fps. Fondamentale per l'utenza americana quando si deve convertire video televisivo in video mpeg per il cinema ( 24 fps)
3) Ghost reduction: serve ad attenuare il tipico effetto di immagini sdoppiate che deriva dalla digitalizzazione di video TV proveniente da un segnale captato con una antenna regolata male ( spesso è dovuto a riflessioni del segnale in radiofrequenza a seguito di cattivo adattamento tra l'antenna, i cavi e il televisore o per onde elettromagnetiche riflesse via etere). Il filtro una volta trovati i parametri giusti è potentissimo: il mio consiglio ( lo ho provato su 3 casi diversi, cattiva ricezione di Italia 1, con ottimi risultati) è di procedere così:ADD, layer 1, metod Edge, position con valori compresi tra 3-10 pixel a secondo della distanza dello sdoppiamento e intensity tra 50 -70. Ovviamente occorre dedicarci qualche minuto per trovare il metodo giusto. Non sembra invece funzionare l'opzione automatica ( auto detect) che seleziona sdoppiamenti di 30-40 pixel !!!
4) Noise reduction: elimina il rumore video dovuto ad esempio alla cattiva ricezione ( puntini vaganti ) o a causa della provenienza nastro (il tipico rumore vhs) o pellicola rovinata. Ci sono due tipi di rumori che il filtro cerca di sopprimere: quello spaziale , all'interno del singolo frame e quello temporale che il sw cerca di stimare in base alle differenze tra fotogrammi successivi: range determina la quantità di intervento (e indirettamente i tempi di calcolo). Questo filtro è molto oneroso in termini di tempi di calcolo: con l'impostazione di default le compressioni con tale filtro tendono a triplicare i tempi di conversione.
5) Edge
enhancement: è il
classico filtro sharp/soft che cerca di sfocare o
enfatizzare i dettagli a secondo dei valori rispettivamente negativi o positivi
dei 2 parametri (direzione orizzontale e vericale). Utile nei casi di video
"slavati", per cercare di evidenziare al meglio i dettagli (valori
positivi) e nei casi di immagini troppo dettagliate per cercare di "
ammorbidire " il video ( tipicamente immagini in computer grafica o video
caratterizzati da eccessiva grana).
Poiché l'opzione sharp evidenzia i dettagli più fini, sarà evidenziato anche
un eventuale rumore video: data la totale assenza di tale rumore nelle immagini
in CG, tale filtro può creare un mpeg più dettagliato, sopratutto nelle
conversioni di video in Competer Graphics in formati mpeg a bassa
risoluzione ( tipicamente la 352*288)
6 - 7) Basic e Custom color correction praticamente tutte le possibili correzioni sui colori: dalla semplice correzione delle dominanti.... alla correzione del gamma; il tutto utilizzando lo spazio colori RGB , CMYK o YUV e visualizzando in tempo reale gli effetti delle correzioni . Opzionalmente sono visibili i diagrammi delle distribuzioni RGB che in ascissa riportano le 255 possibili gradazioni e in ordinata (altezza), il numero di pixel dell'immagine che posseggono tale gradazione; ad esempio incrementare di 20 il valore del parametro R (rosso) comporta la traslazione del diagramma verso destra.
8) Deinterlace : deinterallacciamento, che ovviamente ha senso nel caso di video interallacciato avente risoluzione 576 per il PAL (480 per l'NTSC) che deve essere convertito in risoluzioni inferiori (ad esempio la tipica 352*288): ci sono i semplici metodi odd e even che eliminano i campi pari o dispari esattamente come fa una scheda una digitalizzatrice per le risoluzioni XXX*288, sino ai metodi così detti adattativi che analizzano anche l'altro campo ( quello da escludere) cercando di inserire in parte l'informazione del moto che altrimenti andrebbe persa. Presente anche l'opzione Blend che ricostruisce i due semiquadri, li ridimensiona e li somma (blend) esattamente come si farebbe con due lucidi sovrapposti.
9) Crop Video: con tale filtro è possibile ritagliare una porzione di video ( al limite grossa solo una manciata di pixel) che verrà poi ingrandita nelle dimensioni del frame mpeg . Con tale funzione è ad esempio possibile trasformare un video 720*576 non anamorfico (film DVD) in un video 352*288 anamorfico, conversione che garantisce un miglior utilizzo della risoluzione verticale che nel caso di 2.35:1 non anamorfico si ridurrebbe a 164 righe attive (che corrispondono grazie al formato 4:2:0 a sole 82 righe per il colore). Ho già elencato due modi per farlo nell'articolo dedicato ai formati video; nell'ipotesi di un DVD non anamorfico (2.35:1 o 1.85:1 in formato 4/3) e nell'ipotesi dell'utilizzo della catena flashmpeg--->avisynth--->tmpeg occorre:
1) Selezionare in flask mpeg la risoluzione 720*576 , mentre in tmpeg selezionare la risoluzione (video/size) 352*288 e Image position methed: FIT TO FRAME
2) Settare l'opzione crop video e inserire i parametri:
| Top = | 72/ |
| Bottom = | 72/ |
| Left = | 0/ |
| Right = | 0/ |
| Black mask | tutte deselezionate/ |
Tramite Crop video e grazie alle 4 Black Mask è possibile inserire le bande nere utili per eliminare in certi casi sezioni di video disturbate ( tipicamente le prime e le ultime righe nel caso di digitalizzazioni da videocassetta )
10) 3:2 Pulldown : metodo opposto all' Inverse Telecine per convertire video da 24 fps (frame rate del cinema) in NTSC XXX*480 30 frame/s o 60 campi al secondo.
11) Do not change frame rate : nel caso in cui il video da comprimere ha un frame rate diverso dal frame rate del video mpeg da produrre, selezionando questo filtro non viene più ricampionato il video d'origine (eliminando quando necessario i frame in più o aggiungendo duplicati di frame), ma vengono convertiti tutti i frame, perdendo ovviamente il sincronismo dell'audio.
Se ad esempio è convertito in mpeg 25fps un video avente frame rate pari a 30fps e della durata di 10 secondi, verrà prodotto un mpeg della durata di 12 secondi (10sec*30/25) in cui ovviamente l'audio termina dopo 10 secondi. Deselezionando tale filtro, verrà prodotto un mpeg di 10 secondi ottenuto ignorando un fotogramma ogni 6.
12) Audio effects : è possibile incrementare il volume e normalizzarlo eventualmente al 100% ( viene aumentato il volume fino al max consentito prima della distorsione): è possibile creare delle dissolvenze ( fade) all'inizio e alla fine del filmato, con una durata stabilita.
Concludo ricordando la possibilità di tmpeg di memorizzare e caricare i parametri di conversione tramite le opzioni Load e Save in basso a destra : come già detto ricordo come non sono memorizzati solamente i parametri relativi alla sottosezione advanced, i filtri video appena visti.
Tmpeg per proteggere gli utenti inesperti permette di bloccare alcuni parametri che renderebbero inutilizzabile il template per l'uso per cui è stato progettato. Per esempio nei template VCD non viene permessa la scelta dell'mpeg 1 o 2 perchè il VCD è necessariamente un mpeg1.
Per "sbloccare" i parametri occorre semplicemente modificare con un editor di testo il template e sostituire a True il valore False nel parametro in questione.
Se ad esempio il parametro MPEG.Video.StreamType_ReadOnly = True (che non permette la scelta tra mpeg1 e 2) viene modificato in MPEG.Video.StreamType_ReadOnly = False , in tal caso il parametro viene "sbloccato".
Ovviamente dopo una modifica conviene rinominare il template in maniera diversa per mantenere il template originale
Essendo Tmpeg un sw freeware lo ho potuto inserire sul mio sito: ottimo punto di partenza per le codifiche i circa 100 template (preset ) che ho realizzato e suddiviso in 11 diverse categorie.
| Tmpeg
B12a encoder
, preset sito originale giapponese sito in inglese |
Il "protagonista dell'articolo" |
| Bit rate Viewer www.tecoltd.com | Sw freeware per l'analisi dei bit rate degli mpeg |
| DVD Bit rate Viewer | Sw freeware per l'analisi dei bit rate dei DVD |
| mpeg_stat | Ottimo
software di analisi di file mpeg1: dettagliate statistiche sulle diverse caratteristiche dell'mpeg. Per l'esecuzione su riga di comando scrivere mpeg_stat nomefile.mpg >> leggimi.txt |
| http://www.mpeg.org | Ottimo punto di partenza per collegamenti ai siti dedicati all'mpeg |
| MPEG-2 FAQ
MPEG-1 FAQ |
Articoli in inglese sull'mpeg |
| BBmpeg home page | Ottimo encoder freeware: disponibili i sorgenti |
| Virtual dub link1 , link2 | Elaborazioni video compatibile in lettura con l'mpeg 1 |
Siamo arrivati alla fine: per pareri e osservazioni potete scrivere al mio indirizzo di posta benedettodue@tiscalinet.it
14 ottobre 2000
Ultimo aggiornamento 28 ottobre
Vai all'inizio del'articolo
Ritorna alla pagina digital video
Ritorna alla home page
