La modalità YUV e i Sw che la supportano

Qualsiasi video in formato mpeg è memorizzato in modalità YUV 12 bit detta in ambiente Windows YV12, come da specifiche Direct X; ciò vale per mpeg 1 (VCD,XVCD,...), mpeg2 ( SVCD, DVD,...) e mpeg4 ( DivX;.) , DivX...).

Vediamo prima di tutto cosa è esattamente il formato YUV: riprendo quanto scritto nell'articolo sull'mpeg.

Per descrivere il colore di un singolo pixel molto spesso si utilizza il fattore RGB ( rosso, verde e blu). In pratica, qualsiasi colore è possibile esprimerlo come somma di 3 contributi elementari: non a caso ciascun monitor o televisore è realizzato come una griglia di triadi RGB che a secondo della luminosità dei 3 componenti di ciascuno dei pixel crea ogni possibile immagine. Numerosi formati di immagini fisse ( Gif, BMP, Tiff...) memorizzano le singole immagini come triadi RGB.

Nel momento in cui si raggruppano più pixel, cosa che succede ovviamente per ogni immagine fissa o in movimento, si ricorre spesso alla rappresentazione detta YUV.

Y è detta componente di luminanza , ovvero la luminosità del pixel (ciò che normalmente viene definito come chiaro o scuro)
U,V sono detti componenti di crominanza o componenti differenza: sono due fattori che definiscono la quantità di colore. Spesso U è detto anche Cb, componente differenza del blu e V è detto Cr,  componente differenza del rosso.

La relazione che lega YUV e RGB, è la seguente:

Y                                               =   0,2990 R + 0,5870 G + 0,1140 B
U (Cb) =  0,5635 ( B - Y ) + 128  = - 0,1684 R - 0,3316 G  +  0,5 B  +  128
V (Cr) =   0,7133 ( R - Y ) + 128  =         0,5 R - 0,4187 G - 0,0813 B  + 128
 

La relazione vista, mostra come c'è un legame univoco tra rappresentazione RGB e quella YUV; un medesimo colore può cioè essere indifferentemente rappresentato in una delle 2 maniere. 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 o Y,U,V e pertanto occorrono 3 bit = 24 bit per descrivere il colore di un pixel, sia se si usa la triade RGB che la YUV.

Ecco ad esempio alcuni colori nella rappresentazione RGB e YUV :osservo che i vari grigi hanno rappresentazione (X,X,X) in RGB e (X, 128,128) in YUV.

	RGB	YUV
	255,0,0	76,85,255
	100,100,100	100,128,128
	255,255,255	255,128,128
	100,200,0	147,83,94

Nel momento in cui occorre trasformare una immagine dal formato RGB a YUV ( o viceversa) occorre per ciascun pixel  applicare i calcoli visti: poichè le CPU sono molto più lente nell'eseguire le moltiplicazioni e le divisioni rispetto a tutte le altre operazioni, i programmatori dei codec risolvono la cosa semplicemente memorizzando in alcune tabelle i fattori di conversione così da annullare del tutto le moltiplicazioni. Per chi ha un po' di esperenza in programmazione, vengono in pratica utilizzate le così dette LookupTable: si  occupa un pò di memoria ma si velocizza tantissimo la conversione.

In pratica per ogni pixel da convertire da RGB a YUV ( o viceversa) occorre eseguire 6 addizioni, 2 operazioni di shift (la divisione per 2) e 2 somme per 128 (facili da implementare in assembler): si evitano del tutto le moltiplicazioni anche se le operazioni da compiere impiegano un numero non trascurabile di cicli di clock della CPU. Ad esempio per convertire un secondo di filmato 720*576 da RGB a YUV, calcoli alla mano occorrono circa 62 milioni di addizioni e 20 milioni di istruzioni shift: ipotizzando che in media vengono impiegati 4 cicli di clock per le addizioni ( le operazioni più onerose) occorrono circa 300 milioni di cicli di clock, in pratica un terzo della capacità di calcolo di una CPU a 900 Mhz.
Grazie alle istruzioni MMX e SSE è possibile velocizzare i calcoli, grazie al minor numero di cicli di clock che occorrono per l'esecuzione delle addizioni, e shift.

Riporto per i più curiosi la parte le routine in C, tratte dal codice del DivX, relative alla conversione e alla creazione della tabella di lookup.

In breve la conversione di una immagine dalla modalità RGB---> YUV è una operazione non estremamente gravosa dal punto di vista computazionale, ma in tutti i casi impegnativa, capace di impiegare preziosi cicli di clock della CPU e pertanto rallentare le altre operazioni da svolgere. Stesso discorso per la conversione opposta, RGB---> YUV. Se è possibile, vediamo tra breve come, conviene cercare di evitare tale conversione.

La descrizione YUV è utilizzata nella rappresentazione di gruppi di pixel e in numerosissimi formati di video per cercare di risparmiare il numero di byte da elaborare e di conseguenza velocizzare le operazioni di compressione e decompressione. Vediamo come.

Il tutto nasce dal fatto che l'occhio umano è molto più sensibile alle differenze di luminosità piuttosto che a quelle di colore: la causa sta nella anatomia del nostro occhio. In pratica  per noi è molto più semplice osservare differenze di luminosità piuttosto di colore: in altri termini riconosciamo molto più facilmente la differenza tra 2 grigi, piuttosto che le differenze di sfumature cromatiche di due rossi, verdi o azzurri.

Tale caratteristica è stata sfruttata nel passato, nel momento in cui è stata inventata la televisione a colori , in un'epoca in cui occorreva minimizzare l'informazione video da trasmettere, cosa che occupava banda di radiofrequenza; oggi  la medesima limitazione dell'occhio umano si la si sfrutta nel campo del video digitale in cui risparmiare informazione video significa velocizzare i calcoli ( sono elaborati meno byte) e in più significa risparmiare in bitrate e di conseguenza di spazio occupato sui vari media: DVD, CDR,....

Lo scopo delle varie modalità YUV utilizzata nell'mpeg è quello di rappresentare un gruppo di pixel, con un numero inferiore di byte rispetto alla analoga descrizione in RGB, cercando di memorizzare più informazione di luminanza piuttosto che di crominanza. Si utilizzano le tipiche descrizioni YUV 4:4:4   4:2:2  4:2:0  4:1:1 riferite a gruppi di 4 pixel. In pratica per ciascuno dei 4 pixel si memorizza la sua luminosità, mentre si risparmia sulla informazione colore e si descrive il colore di un gruppo di pixel invece che del singolo pixel.

Osservo come delle volte le formule relative alla conversione RGB--> YUV sono implementate in maniera leggermente diversa a causa del fatto che è possibile lavorare sull'intervallo di valori 0-255 o 16-235 per ciascun componente R,G,B,Y,U,V. Quando si lavora sull'intervallo di valori 16-235 ci si riferisce alle specifiche ITU-R BT. 601-5,

La prima rappresentazione possibile è la YUV 4:4:4 che non approssima nulla e pertanto non produce nessun tipo di risparmio: tale modalità non è utilizzata nell'mpeg, ma serve per capire poi le altre modalità..

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 e cioè 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) esattamente come una analoga immagine memorizzata in RGB

La prima rappresentazione in cui si sopprimono informazioni di colore, in coerenza con la incapacità dell'occhio di osservarle è la modalità YUV 4:2:2

YUV 4:2:2 ITU-R 601 (chiamato YUY2 in ambito Windows Direct Draw e disponibile in Xmpeg4.2a e DVD2avi)  ; 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 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.

YUV 4:2:0 ( chiamato YV12 in ambito Windows Direct Draw). E' il formato che si utilizza per l'mpeg 1 , 2 e 4.
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. 
 

Truscuro la modalità 4:1:1 utilizzata per la TV Americana, che utilizza lo standard NTSC.

Come detto l'mpeg 1, 2 e 4 utilizzano il formato colore YUV 4:2:0: ciò significa che l'encoder ( chi comprime in mpeg) prima di comprimere il video, se le immagini di ingresso sono in modalità RGB, deve prima di tutto effettuare la conversione RGB--> YUV,. Come seconda cosa l'encoder deve preventivamente eliminare, come visto, parte dell'informazione del colore che SARA' DEL TUTTO trascurata e pertanto in fase di visualizzazione sarà irrecuperabile. In pratica l'encoder prima di comprimere il video in mpeg trasforma ciascun gruppo di 4 pixel ( e nel complesso tutta l'immagine) nella modalità YUV 4:2:0 e poi in seguito effettua la compressione.

Gli encoder si distinguono in base alla capacità o meno di leggere il formato colore dei video che poi comprimeranno. Normalmente i formati possibili sono quelli visti:  
RGB,   YUV 4:2:2 (YUY2),    YUV 4:2:0 (YV12)

Ecco una tabella relativa alla compatibilità degli encoder e codec più importanti: ricordo che gli encoder sono software di compressione video, mentre i codec sono dei formati di compressione  video utilizzabile in qualsiasi software capace di creare file avi

Ho inserito nella tabella due codec molto utilizzati in ambito digital video: il freeware HUFFYUV e il codec di formato DV , della Main Concept. I discorsi sul formato colori, valgono anche per tali codec. A questi 2 codec è possibile aggiungerne altri, ad esempio il WMV della Microsoft, derivato dall'mpeg4 e i numerosi codec Sw mjpeg ( Mainconcept MJPEG codec, Morgan Multimedia MJPEG codec, PICVideo ) tutti nativi nel formato YUV 4:2:2 (YUY2) o YUV 4:2:0 (YV12) . Per questi valgono gli stessissimi discorsi.

Nella pratica quando si utilizza uno dei software in tabella o si uno dei codec indicati ( DivX, Huffyuv ad esempio all'interno di Xmpeg) occorre  fornire il video che poi sarà compresso, se è possibile nel formato indicato nella tabella a destra, quello più simile all'mpeg. Ciò garantisce a parità di qualità ottenuta, una velocizzazione del processo di compressione , poichè il software  ( o il codec) di compressione evitano di effettuare la conversione RGB---> YUV.

Consideriamo ad esempio Tmpeg: come indicato in tabella è in grado di operare solo su video RGB. Se carichiamo all'interno di Tmpeg un normale file avi o in generale un qualsiasi video che Tmpeg è in grado di leggere ( Avi, Quicktime, mpeg1,...) automaticamente tmpeg comunica ai codec di lettura che è in grado di leggere solo video RGB e questi gli forniscono il video, ad esempio avi,  in formato RGB. Tmpeg poi si preoccuperà di elaborare tali video (filtraggi, correzione colore, ridimensionamenti,..), di convertirli in YUV 4:2:0 e per ultimo li comprimerà in mpeg.  Se il video che tmpeg legge (in ingresso) è in formato YUV, ad esempio un DivX , ci sarà l'inutile doppia elaborazione YUV-->RGB fatta dal decoder DivX che fornisce il video a tmpeg  e successivamente la conversione RGB--> YUV, fatta da tmpeg. (se ad esempio tmpeg converte un video mpeg1-->mpeg2, la conversione YUV-->RGB la esegue il codec Mpeg 1 Direct Show di Windows mentre la RGB--> YUV la esegue Tmpeg ).
L'utente non può fare in tal caso assolutamente nulla !!!!!
La doppia conversione potrà essere evitata solo quando e se sarà disponibile una nuova versione di Tmpeg in cui è implementata la lettura diretta nel formato YUV : a riguardo pare che questa possibilità sia abbastanza remota poichè  tutte le elaborazioni di post processing di Tmpeg (filtraggi vari,..) sono implementate dall'autore  utilizzando il formato RGB e l'autore di Tmpeg dovrebbe  modificare numerosissime routine.
Quanto visto per Tmpeg vale anche per il Ligos LSX Encoder e per BBmpeg.

Consideriamo il caso del Cinema Craft Encoder (CCE) versione stand alone: come indicato in tabella è in grado di operare sia su video RGB e sia su video YUV 4:2:2. Nel caso analogo a quello visto , in cui con il CCE si deve effettuare una conversione DivX--> mpeg, CCE comunica al codec DivX che è in grado di leggere video YUV 4:2:0 e questo NON EFFETTUA la conversione YUV--> RGB ma una banalissima conversione YUV 4:2:2--> YUV 4:2:0 che il codec DivX esegue molto rapidamente. Il CCE ottiene il video direttamente in formato YUV 4:2:2 che riconverte in YUV 4:2:0 e poi in mpeg. In questo caso il lentissimo doppio passaggio YUV--> RGB e poi RGB--> YUV visto nel caso di tmpeg, Ligos e BBmpeg è sostituito dal banale e veloce doppio passaggio YUV 4:2:2--> YUV 4:2:0 e YUV 4:2:0--> YUV 4:2:2: il risultato è una velocizzazione globale della conversione. Osservo comunque come CCE è più veloce rispetto a Tmpeg solo in piccola percentuale grazie a quanto visto: la sua maggiore velocità deriva dalla ottimizzazione delle routine di compressione rispetto a Tmpeg: l'eventuale operazione di conversione di formato in tutti i casi è sempre notevolmente più rapida della conversione in Mpeg,operazione  molto più onerosa in termini di calcolo.
Anche in questo caso l'utente non può fare assolutamente nulla !!!!!

Nella pratica i casi in cui diventa importante la compatibilità vista in tabella, sono quelli in cui l'utente può scegliere il tipo di formato con cui fornire il video all'encoder o al codec. Ciò succede quando si utilizzano software quali XMPEG, DVDX o Vidomi. In tal caso se possibile è conveniente utilizzare la modalità YUV. Da notare come il collegamento tra XMPEG e le versioni stand alone CCE, Ligos , Tmpeg può avvenire sia  tramite avisynth che tramite il Video Server Plugin. Stesso discorso per DVDX. Al contrario il collegamento con i plug-in ( CCE, LSX , BBmpeg plug-in ) è diretto: si setta all'interno del sw il plug-in richiesto, si inseriscono i parametri  e si avvia la conversione.

Vediamo in pratica i casi più importanti in riferimento a Xmpeg.

XMPEG: consente di utilizzare i 3 formati settandoli in opzioni/opzioni globali progetto/post trattamento. Tale possibilità è presente anche nella versione Mpeg Xis 3.0e Expert Edition V2

	RGB
	YUV 4:2:2 (YUY2)
	YUV 4:2:0 (YV12)

Nella Mpeg Xis 3.0e Expert Edition V2 a fianco di YV12 è indicato "for DivX" per ricordare quello che vedremo tra un pò .

Xmpeg
Compressione e software utilizzato	Modalità consigliata	Note
Creazione di avi con video in formato DivX e  Divx;-)		Per poter utilizzare la modalità YV12 occorre utilizzare uno degli AVI plug-in forniti insieme con Xmpeg: utilizzando ad esempio il vecchio avi plug-in v.0.58 fornito con le versioni di flask della serie 0594, si è costretti ad utilizzare la modalità RGB, l'unica possibile.r
Creazione di avi con video in formato HUFFYUV		Stesso discorso del DivX: per poter utilizzare la modalità YUY2 occorre utilizzare uno degli AVI plug-in forniti insieme con Xmpeg: utilizzando ad esempio il vecchio avi plug-in v.0.58 fornito con le versioni di flask della serie 0594, si è costretti ad utilizzare la modalità RGB, l'unica possibile.r
Creazione di mpeg tramite uno dei seguenti plug-in installati nella directory di Xmpeg: Ligos LSX Encoder,BBmpeg, Cinema Craft Encoder .		Con tali plug-in è possibile utilizzare solo la modalità RGB: osservo che per utilizzare i plug-in con Xmpeg, dopo l'installazione, occorre rinominarli secondo la sintassi Nome.cm.Xmpeg. Per i tre plug-in visti basta chiamarli, bbmpeg.cm.Xmpeg, lsx.cm.Xmpeg, ccet.cm.Xmpeg.
Creazione di mpeg tramite una delle seguenti "catene": XMPEG-->avisynth--> Tmpeg XMPEG-->Video Server Plugin--> Tmpeg XMPEG-->avisynth--> LSX Encoder stand alone XMPEG-->Video Server Plugin--> LSX Encoder stand alone XMPEG-->Video Server Plugin--> Virtual Dub		Nonostante la compatibilità del videoserver e avisynth con la modalità YUV, questa non può essere usata a causa della impossibilità di Tmpeg e del Ligos encoder di leggere video YUV. E' necessario pertanto lasciare la modalità RGB. Osservo come non ho considerato il caso del collegamento di Xmpeg con BBmpeg stand alone poichè tale versione è identica con il BBmpeg plug-in: al contrario il LSX encoder stand alone comprime con una qualità superiore rispetto alla versione plug-in e per una migliore qualità conviene utilizzare una delle 2 catene viste. La catena XMPEG-->Video Server Plugin--> Virtual Dub può essere utile per creare degli avi e contemporaneamente utilizzare gli ottimi filtri di virtual dub; è inoltre possibile poi passare ulteriormente i dati ad un altro sw, grazie al frame serving di Vdub; si può creare ad esempio la catena (con 2 avi virtuali) XMPEG-->Video Server Plugin--> Virtual Dub--->frame serving---->Tmpeg
XMPEG-->Video Server Plugin--> Cinema Craft Encoder stand alone		Attenzione a non utilizzare il formato YV12 che risulta incompatibile .

Un software analogo ad Xmpeg è DVDX http://www2.labdv.com/dvdx giunto alla versione 1.8: personalmente lo considero un buon software che comunque ha ancora un certo margine di miglioramento: ottima la possibilità di collegarlo tramite il videoserver plug-in a tmpeg o a CCE Encoder. Chi non è interessato a tale sw può tranquillamente passare al paragrafo successivo.

DVDX rispetto a XMPEG ha il vantaggio di disporre di un convertitore mpeg incorporato con il quale creare direttamente video per SVCD, XVCD, VCD; la qualità è inferiore rispetto a tmpeg, ma in tutti i casi discreta. Inoltre ha ancora un bug relativo al ridimensionamento nel caso in cui si creano SVCD, XVCD non anamorfici , partendo da DVD anamorfici, il caso normalmente più utilizzato; il video che ne risulta è deformato (troppo schiacciato). Per ovviare alla cosa occorre inserire i seguenti parametri:

Nell'ipotesi di SVCD 480*576,

Setting/output setting/

Setting/crop/edit coordinates

Per risoluzioni quali 352*288, 352*576, 704*576 e 720*576 occorre sempre inserire Setting/crop/edit coordinates , mentre in Setting/output setting/ occorre ovviamente inserire la risoluzione scelta: 352*288, 352*576,.....

La prima  analogia  con Xmpeg deriva intanto dal fatto che DVDX legge i DVD e esattamente come Xmpeg è in grado di convertire i DVD direttamente da DVD-ROM, decriptandoli grazie alle capacità Deccs: il grosso vantaggio di DVDX è che memorizza temporaneamente su HD o in memoria parte dei DVD da convertire (la dimensione la si può scegliere liberamente) evitando di "stressare" la meccanica del DVD-Rom. Con un buffer di 50 MByte (fattibile per chi ha almeno 256 MB di RAM, il DVD rom viene utilizzato ogni minuto o due, a secondo della velocità di conversione).

Ritornando al discorso compatibilità con i diversi formati video in uscita, DVDx si comporta in maniera simile a Xmpeg: è possibile convertirei DVD in:
- Mpeg 1,2, e quindi VCD, SVCD, XVCD sfruttando direttamente l'encoder interno
- Avi utilizzando i codec presenti nel sistema
- è possibile utilizzare un qualsiasi plug-in Premiere compatibile installato all'interno della directory di Xmpeg: i plug-in devono avere la stessa estensione utilizzata dai plug-in di Premiere, ovvero Nome.prm (si possono copiare quelli presenti nella directory plug-in di premiere senza bisogno di rinominarli come nel caso di Xmpeg).

La scelta del formato di uscita la si fa tramite setting/output setting
Selezionando VideoCD e Super Video CD è possibile creare mpeg 1 e 2, tramite l'encoder interno: in tal caso automaticamente questo utilizza la modalità YUV. Selezionando AVI output è possibile creare file avi con uno dei codec presenti nel sistema: in tal caso il formato video RGB o YUV lo si seleziona tramite l'opzione setting/output setting .
Qui valgono tutti i discorsi visti con Xmpeg: per velocizzare le operazioni occorre utilizzare la modalità YUY2 ( la YUV 4:2:2) per DivX, DivX;-), DV e HUFFYUV: la YV12 teoricamente la più indicata, non è ancora disponibile (probabilmente lo sarà nelle prossime versioni). Osservo come per gli altri codec sono disponibili 2 modalità RGB: conviene usare la RGB 24 di fatto identica alla RGB 32 ( che sfrutta il canale alpha normalmente inutilizzato).

L'altra possibilità è quella di utilizzare i plug-in premiere compatibili, installati nella directory di DVDX: per selezionare tale possibilità basta cliccare su setting/output setting

Valgono tutti i discorsi visti per Xmpeg: occorre settare sempre la modalità RGB 24  con l'unica eccezione della catena  XMPEG-->Video Server Plugin--> Cinema Craft Encoder stand alone per la quale conviene usare la modalità YUY2.

Concludo dicendo come ho provato la catena DVDX-->Video Server Plugin--> Tmpeg ottenendo degli ottimi risultati qualitativi grazie alla superiore capacità di compressione di Tmpeg rispetto all'encoder interno di DVDX; a livello di velocità, con il mio P4 1700, sfruttando la versione di DVDX ottimizzata per il P4, per la creazione di un SVCD standard (480*576 2500 Kbits/s) ottengo con la catena vista 9,5 fotogrammi al secondo contro gli 8,7 dell'encoder interno. Che dire: migliore velocità e qualità grazie al mitico Tmpeg.
A titolo di esempio con Xmpeg-->Video Server Plugin--> Tmpeg ottengo circa 9,9 fotogrammi al secondo, praticamente la stessa velocità.

Ci tengo a sottolineare come non ho ancora fatto test approfonditi sulla qualità con cui DVDX decodifica i DVD (so di certo che XMPEG non aggiunge nessun artefatto mentre è da confermare che lo stesso vale per DVDX): ad occhio la qualità di decodifica sembra la stessa (da non confondere con la qualità di compressione mpeg che non è di certo al top) , ma mi riservo di fare ulteriori verifiche. Altra cosa da verificare, il mantenimento del sincronismo audio-video: occorre comprimere almeno 2-3 film interi per poter esprimere una valutazione obbiettiva. In tutti i casi DVDX sembra essere un ottimo software potenziale "concorrente" di Xmpeg.

Mi fermo qui, osservando come lo stesso discorso visto per Xmpeg e DVDX vale per ogni software di compressione, capace di scegliere il formato   colore da passare al codec di compressione o plug-in; in particolare per le compressioni DivX e DivX;-) conviene sempre utilizzare  la modalità YUV 4:2:0 (YV12) o al limite  YUV 4:2:2 (YUY2) .

In conclusione che vantaggi o svantaggi ci sono nell'utilizzare la  modalità di colore YUV (quando possibile) rispetto alla generica RGB ?

Svantaggi, non ce ne sono. Naturalmente sono nell'ipotesi in cui si sta utilizzando il YUV per comprimere in mpeg 1 ,2, 4 ( DivX;-), DivX, compresi) o si sta usando un codec che usa nativamente la modalità YUV (ho visto il codec DV e l'Huffyuv, WMV, Mjpeg..) : è ovvio che se parto da un originale RGB e converto il video in un formato RGB, se utilizzo un plug-in in modalità colore YUV, perdo parte dell'informazione video . Non penso esista una diabolica combinazione SW- plug-in che permetti una cosa simile!!!

Riguardo i vantaggi ce ne sono 2.
La doppia conversione colore YUV--> RGB e RGB--->YUV a seguito delle approssimazioni dei calcoli porta ad un leggero errore sui colori così che ad esempio un pixel (100, 100, 100) dopo la doppia conversione si trasforma in  (100, 99, 101). Nella pratica eventuali errori del genere, si manifestano in una leggera differenza cromatica. Molto probabilmente tale variazione deriva dalla diversa formula con cui sono effettuate le conversioni: esistono diverse "interpretazioni" della relazione che passa tra la modalità RGB e YUV, che nascono dal fatto che è possibile lavorare sul range di valori 0-255 o 16-235 per ciascun componente RGBYUV.

Il secondo vantaggio è quello più importante: la velocizzazione della compressione a causa della mancata, inutile conversione YUV--> RGB e RGB--->YUV. Quantificare il risparmio non è possibile in assoluto perchè tutto dipende dal tipo di conversione che si sta facendo (dimensione video, codec, tipo di video da convertire,....).

Ecco un test eseguito con il mio P4 1700 Mhz,  384 MB SDRAM, Matrox G450 riferito ad un minuto di video estratto da un DVD (l'episodio "il dominio del Drago" della serie Spazio 1999).

Prima di tutto ho valutato la velocità con cui viene decodificato il filmato (720*576 pixel) sia nel caso in cui si attiva la visualizzazione e sia quando questa è disattivata; la maggiore lentezza del caso "preview attivato", deriva naturalmente dal tempo impiegato per il passaggio dei dati dalla memoria centrale alla scheda video. Non è riportato il caso RGB con previsualizzazione disattivata poiché ciò non è possibile con Xmpeg.

Segue il caso in cui lo stesso filmato è ridimensionato a 512*288, classica risoluzione dei DivX per film 1.78:1 da comprimere in un solo CD. La velocizzazione della modalità YUV è minore a causa dei calcoli del ridimensionamento che sono impegnativi a causa del filtraggio (ho usato la modalità Bressenham), operazione onerosa in termini di calcolo.
Segue il test più importante, ovvero quello relativo alla compressione del video ridimensionato a 512*288 e compresso in DivX 4.12, con quality = Slowest (migliore qualità): l'audio è stato lasciato in PCM non compresso. La velocizzazione nella modalità 4:2:0 è del 23%, valore indiscutibilmente notevole. Sottolineo ancora una volta, come tale velocizzazione NON comporta nessun peggioramento nella qualità che in teoria dovrebbe essere migliore rispetto al caso RGB a causa della mancata doppia conversione YUV-->RGB e RGB--> YUV ; nella pratica confrontando le due conversioni (modalità RGB  o modalità YUV12) , è possibile osservare una leggera variazione cromatica e in più una immagine leggermente più chiara nella modalità YUV.)

Concludo con una breve nota sul legame tra il formato colore dei video digitale e i decoder che li visualizzano.

I DVD player (WinDVD, PowerDVD, il Cinemaster,....)  e in generale tutti player capaci di leggere visualizzare video mpeg 1,2, e 4 / media player compreso), leggono il flusso mpeg, lo decodificano e ottengono così una serie di immagini in modalità YUV 4:2:0. Terminata questa operazione, passano alla scheda video le immagini in YUV, e quest'ultima trasforma tali immagini in RGB effettuando eventualmente il ridimensionamento.
Il motivo della delega alla scheda video è triplo:
- il primo perchè le schede video sono ormai ottimizzate ad eseguire le opazioni di trasformazione YUV---> RGB e il ridimensionamento; in tutti i casi è utilizzato il ridimensionamento tramite bilinear filtering (ad esempio tutte le Matrox); pare invece che le ultime ATI Radeon utilizzino il più evoluto filtro trilineare.
- il secondo motivo è che in questa maniera non è minimamente appesantita la CPU, che molto spesso non ha la potenza di calcolo per fare conversione colore + ridimensionamento;
- il terzo motivo è legato alla dimensioni del flusso dati che viene trasferito dalla memoria del computer alla scheda video; un video 720*576 in formato YUV ha un bitrate di 14,83 Mbyte/s, mentre ad esempio se si delegasse al software la completa elaborazione del video, occorrerebbe fornire alla scheda video ad esempio video il full screen 1024*768 in formato RGB che ha un bitrate di 56,25 Mbyte/s,  quasi 4 volte superiore al caso di prima e capace di saturare il bus dati del PC.

Per le operazioni di ridimensionamento e conversione YUV--> RGB, le schede video utilizzano l'overlay, in pratica una modalità che visualizza sempre 16 milioni di colori, indipendentemente dalla profondità di colore selezionata nel desktop. Questo è il motivo per cui i filmati appaiono cromaticamente corretti anche se si utilizza il desktop ad 8 bit ( 256 colori)  o 16 bit, ( 65536 colori).

26 febbraio 2002

Ritorna alla pagina digital video