Test sugli encoder mpeg2: Tmpeg, LSX Encoder, BBmpeg, CCE Encoder 

Quello che trovate è il resoconto, per adesso provvisorio , di una serie di test fatti prima di tutto per valutare le velocità dei software con il  mio P4 1700 Mhz, e poi per dare un giudizio il più possibile obbiettivo della qualità degli encoder. Poiché, ovunque sulla rete, si parla di una superiorità indiscussa di Tmpeg e CCE encoder, ho cercato di analizzare in profondità sopratutto questi 2 encoder, per  cercare di vedere se è possibile decretarne un vincitore.

In breve, Tmpeg comprime sempre meglio di CCE, anche se le differenze ad una analisi superficiale potrebbero non essere visibili: lo scotto da pagare è una velocità inferiore dal 50 al 60% per le conversioni DVD--> SVCD e DVD---> XVCD, e velocità dimezzata ad esempio per le conversioni DV-->DVD. La superiorità di Tmpeg con gli altri encoder è invece evidente anche ad occhi non particolarmente allenati.

Fare una analisi comparativa, è semplice se si devono solo calcolare le velocità di conversione: al contrario per una analisi obbiettiva della qualità degli encoder, occorre :
- Creare uno o più video ad hoc, che scena per scena testano la capacità dell'encoder di comprimere quel particolare tipo di scena: scene statiche, dinamiche, chiare, scure, immagini rumorose (vhs), cartoni animati, originali in computer grafica.
- creazione dei formati più utilizzati: VCD o CVCD ( capacità dell'encoder di gestire elevate compressioni), XVCD con bitrate medio/alti, SVCD con bitrate standard (compressione medio alta) e bitrate fuori standard; DVD con qualità medio-alta (5000-6000 Kbits/s); DVD con massima qualità possibile (720*576 , bitrate circa 9000-9500 Kbits/s)
- comportamento nell'utilizzo di bitrate costante, bitrate variabile e compressione a doppia passata.
- comportamento a secondo del rapporto velocità/qualità di compressione che si è settato: molti encoder sono in grado di velocizzare la compressione o rallentarla per favorire o meno la qualità.

E' evidente che ciascun encoder può può avere comportamenti diametralmente opposti in condizioni diverse e la scelta dell'encoder deve essere fatta sopratutto in base alle proprie esigenze: un esempio tra tutti, il classico film del matrimonio (40-50 minuti) da inserire in un DVD-R che non crea nessun vincolo sul bitrate, che può tranquillamente essere pari a 8000-8500Kbits/s costante; in tal caso diventa assolutamente inutile la predisposizione di un encoder nel gestire bene il bitrate variabile, la doppia passata o le basse compressioni. Sugli alti bitrate, la qualità tende ad uniformarsi e può diventare prioritario scegliere l'encoder più veloce.

Dopo aver fatto i test occorre analizzare i risultati: ciò consiste intanto nel valutare i dati oggettivi come la velocità di compressione, l'andamento del bitrate e della quantizzazione, e la verifica del bitrate medio ottenuto, in relazione ai parametri immessi. Segue poi la più difficoltosa valutazione della qualità visiva, da fare sui fermi immagini, immagini in movimento e immagini ingrandite. Non ultimo occorre fare attenzione ad esempio a non analizzare  dei fermo immagini e magari paragonare un I frame con un B frame ottenuto da un'altra conversione, che è ovviamente inferiore in qualità : sulla rete ho trovato numerosissimi esempi di paragoni del genere !!!!.

E' evidente che una analisi di questo genere è molto impegnativa, ed è necessario concentrare l'attenzione magari su di un numero minore di caratteristiche: è quello che ho fatto. Nei test eseguiti ho sempre analizzato compressioni con bitrate costante: la gestione del bitrate variabile sarà oggetto dei prossimi test. Ricordo come fissato un bitrate, la compressione a bitrate costante ( esempio a 2500 Kbits/s) è sempre qualitativamente superiore di una compressione fatta con gli stessi parametri, ma gestita con il bitrate variabile avente come bitrate massimo tale medesimo valore ( 2500 Kbits/s nell'esempio)

Per adesso mi sono limitato ad 3 casi particolari: creazione di un XVCD (mpeg1, 352*288, bitrate 2100 Kbits/s costante, video full screen) e di un SVCD standard (mpeg2, 480*576, bitrate 2450 Kbits/s costante, video letter box 1.85:1) partendo dal video di un DVD.
Per ultimo ho testato la creazione di video adatto alla creazione di DVD (mpeg2, 720*576, bitrate 6000 Kbits/s costante, video full screen), a partire da materiale DV:  la compressione è fatta in modalità interallacciata.
I risultati ottenuti, nonostante la semplicità dei test, danno comunque una idea già abbastanza chiara sulla qualità degli encoder testati.

Le velocità sono ottenute tramite la media di 2 test successivi con il buon metodo del "cronometro manuale" , nel momento in cui spesso le statistiche indicate dai Sw sono poco attendibili e non tengono conto ad esempio dall'esatto istante in cui inizia la conversione. Naturalmente le velocità ottenute comprendono sia il tempo impiegato da Xmpeg per la decodifica del DVD e per il ridimensionamento ( modalita Bressenham), e sia il tempo  della compressione fatta dagli encoder.

Gli encoder utilizzati ( ad oggi le versioni più recenti disponibili) sono:

- Tmpeg 2.51 (identico per velocità e qualità alla versione 2.01)
- BBmpeg plug-in v1.24
- CinemaCraft Encoder (CCE) plug-in v.2.64
- CinemaCraft Encoder (CCE) stand alone v.2.64
- Lsx Encoder plug-in v.1.2

Per Tmpeg e LSX Encoder, ho utilizzato  due modalità di Motion Search precision , ovvero il tempo impiegato alla stima del moto che si ripercuote sulla velocità di compressione: alla migliore stima corrisponde la codifica più lenta e la qualità migliore.
Ho utilizzato la modalità di default (Motion estimate search per tmpeg e Motion Est=16 per il LSX) e 2 modalità leggermente più lente, rispettivamente Motion S. precision=Normal per Tmpeg e Motion Est=20 per il LSX. Tmpeg consente di utilizzare stime ancora più accurate , rispetto alla "normal", grazie alle modalità high e highest(non testate) mentre per LSX, con Motion Est=20 si ottiene  la massima qualità possibile

Riguardo la qualità, c'è da dire che tutti gli encoder testati hanno creato video di qualità sempre tra il buono e l'ottimo: sto analizzando sw al top della loro categoria, e siamo ben lontani dalla qualità insoddisfacente degli encoder  di 1-2 anni fa': l'Xing encoder, le prime versioni del LSX sono ormai un ricordo del passato !!!

Naturalmente non significa che la qualità degli encoder analizzati è la medesima: solo ad una analisi superficiale e in alcune scene gli mpeg ottenuti possono sembrare uguali: ma appena si analizzano scene più complicate da comprimere salgono a galla i difetti di ciascun encoder.

La prima  cosa che salta subito alla vista è la grossa differenza di velocità tra le versioni: Cinema Craft raggiunge la velocità così elevata grazie alla massiccia presenza di codice ottimizzato per le istruzioni SSE o Enhanced 3D Now ! , che lo rendono compatibile solo con processori dotati di tali istruzioni: Intel Pentium 3, Pentium 4, Amd Athlon e i nuovi Intel Celeron dotati di core P4. Cinema Craft inoltre vanta nella documentazione allegata al software un algoritmo di stima del moto superottimizzato, presumibilmente il responsabile della ottima velocità misurata.

Cinema Craft Encoder raggiunge velocità così elevate solo grazie alla ottimizzazione del suo codice o a questa velocità contribuisce una certa approssimazione dei calcoli e quindi una qualità non al top? La premessa è che in realtà esistono 2 tipi di ottimizzazioni.
Il primo tipo di ottimizzazioni sono quelle fatte ottimizzando i calcoli (ottimizzazioni matematiche), il codice di programmazione ( trucchetti vari o utilizzo diretto di codice in assembler),  e sfruttando al massimo il set di istruzioni di ciascun processore:MMX, SSE, SSE2, 3d Now!!. Questo tipo di ottimizzazione non ha alcun effetto collaterale: si ottengono esattamente gli stessi risultati ma con velocizzazioni spesso anche dell'ordine del 200-300%. : un esempio tra tutti, il più "clamoroso", è il calcolo della IDCT che a parità di risultati, se ottimizzato arriva ad essere anche 8-10 volte più veloce del medesimo calcolo implementato in maniera standard.
Su questo tipo di ottimizzazioni, l'esperienza dei programmatori di tutto il mondo e la diffusione gratuita di codice ottimizzato, hanno fatto si che più si va avanti e più è difficile aspettarsi "miracoli": riprendendo l'esempio della IDCT, è impensabile che i programmatori  del CCE, non abbiano in una certa maniera attinto alle incredibili implementazioni liberamente disponibili sulla rete e sono certo che

Il secondo tipo di ottimizzazioni deriva dell'algoritmo mpeg, che lascia una ampia libertà al programmatore nell'implementare la compressione: fondamentalmente ci sono 2 punti in cui è possibile lavorare nell'ottimizzazione; il calcolo delle Idct, che può essere approssimato e l'algoritmo della stima del moto, ovvero la parte dell'algoritmo che cerca la similitudine dei blocchetti ( macroblocchi) di 8*8 e 16*16 pixel, appartenenti a fotogrammi successivi. Quest'ultimo si presta a infinite scorciatoie  che influenzano pesantemente la qualità della compressione e la velocità con cui viene effettuata.
Sta nell'intelligenza del programmatore la capacità di scegliere le approssimazioni e le scorciatoie che deteriorano la qualità in maniera  il più possibile invisibile.

C'è da chiarire che pur eliminando tutte le approssimazioni nei calcoli,  la compressione perfetta nella pratica non esiste, poiché la stima del moto se fatta testando tutti possibili macroblocchi occuperebbe sino a 50- 100 volte il tempo normalmente usato dagli encoder. Ciò sarebbe possibile solo tramite una potente elaborazione parallela di un numero elevato di processori, cosa fattibile in HW tramite architetture proprietarie, ma non certamente in ambito PC. I vantaggi rispetto ad una buona implementazione software sarebbero comunque minimi e spesso invisibili.

Spero di non avere contro l'intera comunità di internet, quando dico che il pluri milionario e famoso CCE ( costa 3980 dollari www.cinemacraft.com , più di 8 milioni di lire....oops circa 4000 euro) comprime peggio del "quasi" freeware Tmpeg (la codifica mpeg 1 è freeware, mentre per l'mpeg 2 basta scaricare da internet mensilmente la versione aggiornata del Sw, o comprare la versione pro www.pegasys-inc.com che costa 48 dollari, 83 volte meno del CCE).

Vediamo un pò più in dettaglio i risultati del test: per la analisi visiva dei risultati ho utilizzato WinDVD2000 3.1 e VirtualVdub. Con Windvd, è utilissima la possibilità di caricare delle playlist di video e richiamarli velocemente tramite tastino numerico (numero del video + invio). VirtualDub è direttamente compatibile con l'mpeg1 e ha la capacità di mostrare il video ingrandito di 2X o 4X oltre che di indicare il tipo di frame analizzato:I, P, B. Con VirtualDub è facile fare il confronto tra diversi mpeg, grazie alla possibilità di aprire senza problemi, più sessioni e di muoversi tra i singoli fotogrammi in maniera molto comoda. Per visualizzare gli mpeg2, nativamente incompatibili con Virtual dub, ho creato avi virtuali tramite DVD2avi e VFAPIConv-EN, e li ho visualizzati in VirtualDub; anche in questo caso nessun problema con più sessioni attive contemporaneamente.
Tramite Windvd200 e VirtualDub ho così analizzato e confrontato i vari video in moto e per singoli fotogrammi, ingranditi e non.

Ecco una immagine che chiarisce i difetti incontrati: utilizzate profondità colori 32 bit, per una corretta visualizzazione (occorre poi cliccare su aggiorna  se avete modificato la profondità colore)

Premetto che l'immagine rappresentata è solo un esempio, ma esplicativo poiché i difetti che mi appresto a descrivere sono sempre presenti nei video prodotti dai rispettivi encoder, anche se in entità molto diversa a secondo dei parametri scelti e dal video compresso. Osservo poi che ho sempre analizzato distintamente li fotogrammi I; B e P che hanno sempre caratteristiche diverse.
I frame: massima qualità e TOTALE INDIPENDENZA dalla qualità della compensazione del moto!!! Non si può pertanto valutare la capacità di compensazione del moto analizzando un frame di tipo I.
P frame: media compressione e discretamente influenzato dalle capacità di compensazione del moto del SW.
B frame: forte compressione (i dettagli sono molto attenuati) e fortemente influenzato dalle capacità di compensazione del moto

La immagine che vedete a sinistra in piccolo è l'originale (sono delle liane con lo sfondo di un cielo al tramonto) mentre le immagini a destra sono quelle compresse dai diversi encoder in mpeg1 e ingrandite del 400%.

Un breve ripasso degli artefatti introdotti dall'mpeg: i due più importanti sono ringing ( detto spesso effetto "moschito") e il blocking.

L'effetto ringing ("moschito") è il tipico artefatto che si ha nei cambi netti di colore e in particolare nei bordi delle immagini reali, ai contorni di eventuale testo e che è molto evidente tra l'altro nei cartoni animati in corrispondenza dei bordi dei personaggi, normalmente neri. Si manifesta con una serie di punti colorati assolutamente non presenti nell'originale.
L'artefatto detto blocking è quello che si nota in corrispondenza di sfumature di colori, che vengono approssimate con dei blocchi di colore di 8*8 e 16*16 pixel.

Nell'esempio, l'immagine di Tmpeg sembra praticamente non compressa, perfetta dal punto di vista cromatico e priva di blocking (8*8 e 16*16 pixel). Di tmpeg c'è solo da sperare un leggero miglioramento nella velocità: le ottimizzazioni SSE2, inserite a partire dalla versione 2.0, hanno in un sol colpo incrementato le prestazioni del 20% senza alcuna diminuzione della qualità e non è da escludere che c'è ancora un certo margine di miglioramento. Come dichiarato dall'autore la qualità rimarrà sempre  una assoluta priorità. Tra le due modalità di stima del moto (Motion S. precision=Motion estimate search di default o la modalità normal) nel test in esame apparentemente non c'è nessuna differenza qualitativa; è comunque prematuro affermare che non ci sono vantaggi nell'usare la modalità normal, poiché la migliore stima del moto produce vantaggi visibili solo nelle condizioni più critiche: basso bitrate e scene molto dinamiche; solo una analisi più approfondita potrà quantificare l'entità del miglioramento. Dal punto di vista velocistico, con la modalità normal c'è un rallentamento limitato al 7-8%.
La bontà dell'algoritmo Motion S. precision=Motion estimate search è confermata dal fatto che tutti i preset di tmpeg, forniti dall'autore, utilizzano tale modalità. Da testare i vantaggi con le modalità ancora più lente: high e highest quality.

CCE introduce un evidente "moschito effect" che nell'esempio si evidenza con singoli pixel aventi un colore ben diverso dallo sfondo uniforme.
ECCO SPIEGATA LA MAGGIORE VELOCITA' del CCE. Il moschito effect si produce quando si quantizzano  fortemente  le componenti d'alta frequenza delle IDCT ed è lo stesso effetto che si ottiene  con le forti compressioni jpeg. Molto probabilmente per velocizzare i calcoli CCE trascura o approssima i calcoli sulle alte frequenze della IDCT con i risultati che vedete. Poichè tale problema è evidente anche negli I frame, la causa non sta nella cattiva compensazione  ma dal processo IDCT- quantizzazione.

E' importante chiarire che il problema del "moschito effect" di CCE è più evidente nell'utilizzo di basse risoluzioni (352*288) rispetto alle alte (720*576), poichè i singoli pixel su immagini più grosse essendo più piccoli, tendono a non essere visibili ad occhio nudo; l'occhio al contrario fa una "media pesata" di tali pixel che producono globalmente un colore più uniforme. Questo "mascheramento" vale ancora di più durante la visione normale del filmato: al contrario con i fermo immagini, slow motion e magari zoom, la visibilità del moschito aumenta.
Il moschito, come gran parte degli altri artefatti dell'mpeg, tende a diminuire all'aumentare del bitrate video: pertanto il moschito introdotto da CCE è più evidente negli mpeg più compressi ( vedi SVCD standard) mentre tende a scomparire del tutto per alti bitrate, vedi il classico 720*576 a 5000-6000 del DVD.

Altro artefatto da verificare è il blocking: la scelta dell'esempio non è casuale, poiché ogni effetto di blocking lo si vede chiaramente sopratutto sulla liana di destra che appare spezzettata. Il CCE anche in questo caso ha alcuni piccoli problemi di blocking non presenti in tmpeg ma evidentissimi nel LSX "famoso" per la sua "attitudine naturale" ad aggiungere artefatti di blocking.

A conferma di quanto detto, altri due esempi, relativi ad un P frame, che mostrano in maniera indiscutibile i problemi di moschito (in basso a sinistra con un cielo costellato di numerosi pixel pluricolorati, non presenti nell'originale) e del blocking + moschito (in basso a destra) del CCE. Osservo a difesa del CCE come in movimento tali artefatti sono molto meno evidenti, ma ci sono e sfido chiunque a dimostrarmi il contrario. In conclusione si può dire che il CCE è non lontano dal top per la creazione di mpeg2 per DVD, probabilmente il formato per cui è stato ottimizzato: 720*576 di risoluzione e bitrate medio-alti, 5-6000 Kbits/s. Scendendo di risoluzione e di bitrate la qualità peggiora  gradatamente rispetto ad analoghe compressioni fatte da Tmpeg: con la 352*288 l'effetto moschito rende il CCE inferiore in maniera visibile rispetto a Tmpeg, nonostante la qualità nel complesso rimane sempre mediamente elevata. Le versioni stand alone e plug-in di CCE, sono identiche per qualità: la velocizzazione della versione stand alone deriva dal supporto della modalità YUV, impossibile invece per il plug-in compatibile solo con la modalità RGB; la minore velocità deriva dalla doppia conversione YUV-->RGB ( fatta da Xmpeg) e RGB--> YUV, (fatta dal plug-in CCE).

Riguardo il LSX encoder, c'è da dire che la sua qualità video, pur non allo stesso livello di Tmpeg e CCE, è mediamente buona: il punto debole dell'encoder sta in una sua più naturale tendenza a creare blocking; per migliorare la cosa occorre utilizzare la modalità più lenta (Motion Est=20), che rallenta la conversione sino a renderla il 25-30% più lenta di tmpeg. L'altro problema del plug-in LSX è la qualità dell'audio che in tutte le situazioni in cui il volume  è medio-basso ( vedi tutti i casi in cui ci sono solo dialoghi), tende a produrre un fastidiosissimo rumore di quantizzazione chiaramente avvertibile e molto fastidioso: è veramente inconcepibile come un software così pubblicizzato abbia un simile bug, considerando come esistono numerosissime ottime implementazioni freeware di encoder audio mpeg, da cui poter liberamente "prelevare" e rielaborare il codice. Ecco un esempio in cui il blocking dell'LSX è evidentissimo.

Nel primo esempio, che riporto,
 
appare evidente la presenza del blocking, chiaramente maggiore rispetto agli altri encoder, che rende la liana sulla destra la più spezzettata.

Concludo con BBmpeg, che è dotato anche lui di una buona qualità video, paragonabile a quella prodotta dall' LSX. Il suo maggior problema è la velocità, non elevata: le conversioni sono quasi il doppio più lente di quelle effettuate con Tmpeg e sino a 3 volte più lente rispetto al CCE. Il vantaggio di BBmpeg è che è totalmente freeware: dal sito ufficiale http://members.home.net/beyeler/bbmpeg.html è possibile scaricare anche i sorgenti, prezioso oggetto di studio. Critica in certe occasioni la compensazione del moto, che sopratutto nei B frame tende a creare tracce di blocchi di fotogrammi precedenti o successivi, evidente manifestazione di una compensazione non perfettamente riuscita.

Termino con un esempio che è esplicativo della cura con cui l'autore di tmpeg ha progettato il suo gioiellino: il cambio scena. Tutti i sw analizzati individuano il fotogramma in cui c'è un cambiamento di scena e inseriscono un I frame: il problema sta nella compressione dei 2 fotogrammi precedenti che se si mantiene il classico ordine IBBPBBPBBPBBPBBI può capitare siano due frame B (statisticamente accade ad un cambio scena su 3). In un caso del genere tmpeg utilizza un ordine diverso, come indicato in tabella.

L'intelligenza di Tmpeg preserva la qualità dei 2 fotogrammi N-2 e N-1, grazie al fatto che quest'ultimo viene compresso come frame P e non B. Il motivo è semplice: la sintassi dell'mpeg fa si che i frame B in rosso, sono calcolati come media della differenze con i fotogrammi N-3 (P)  e N (I), con l'inconveniente che il frame N è del tutto inutilizzabile come "sorgente di compensazione" perché appartiene ad una scena diversa; il risultato, evidentissimo in BBmpeg e LSX, e un pò meno in CCE, è che i due fotogrammi N-2 e N-1 appaiono pienissimi di artefatti: la cosa succede ovviamente molto di rado ma è un particolare che la dice tutta sulla scrupolosa codifica di Tmpeg. Tmpeg, infatti, inserisce un P frame nel fotogramma N-1 che è compensato da un I frame precedente e pertanto della stessa scena; il frame N-2  si trova a cavallo di 2 frame P, entrambi della stessa scena e pertanto può essere compresso mantenendo la qualità.

Termino con una tabella riassuntiva: una sintetica pagella con dei voti: voto maggiore corrisponde a qualità maggiore, in relazione all'artefatto indicato  o alla qualità

E' tutto, in attesa di nuovi test più approfonditi e dell'analisi di altri encoder.

26 febbraio 2002

Ritorna alla pagina digital video