IEEE o MMX?

Di recente la Tom's hardware guide pubblicò un test relativo ai nuovi Intel Pentium4. Tom fece anche un test usando FlaskMpeg e le sue conclusioni furono che il P4 presentava performance decisamente migliori rispetto a qualunque CPU AMD. Molto presto quel test cominciò a suscitare qualche curiosità. Qualcuno suggerì di usare l' IEEE-1180 iDCT al posto dell' MMX iDCT di default. Tom fece un altro test, ma questa volta le sue conclusioni in termini di performace furono abbastanza differenti. Contro la superiorità delle FPU dei processori Athlon, il chip di Intel ottenne punteggi piuttosto scarsi. Effettivamente anche il P4 di 300 Mhz superiore, non ebbe alcuna chance contro tutti i microprocessori della famiglia Athlon durante il test.

Immediatamente dopo l'uscita di quell'articolo ci fu scompiglio nella scena del ripping. Molte persone volevano sapere se avevavno fatto male ad usare l' MMX iDCT, come veniva suggerito in tutte le guide relative al FlaskMpeg. Chiaramente era giunto il momento di fare i propri test, e queste sono le mie conclusioni al riguardo.

Test Setup

Contrariamente a come fece Tom, io vi fornisco gli esatti parametri del mio test, così sarà possibile a tutti ripeterlo modo trasparente.

E' stata usata la prima release R1 del film The Matrix. Sono stati rippati i capitoli 28 - 30 in files separati usanto SmartRipper. Il Capitolo 28 è l'interrogatorio di Morpheus nel palazzo della polizia: ha molti disturbi nel grigio dei muri e quindi è chiaramente una scena low-motion. Il Capitolo 29 è lo scontro con i guardiani e probabilmente è la scena più famosa del film. Chiaramente questa scena comporta azioni pesanti e pertanto spinge il codec al suo limite. Il Capitolo 30 include il combattimento sul tetto e l'esplosione dell'ascensore - la scena più complessa in tutto il film.

Ho avviato 3 test con i seguenti settaggi:

Tutti i test sono stati eseguiti usando FlaskMpeg 0.594, con l' AVI Output plugin 0.591 ed il codec DivX 0.311 alpha in modalità low-motion. Ho settato il crispness a 100. L'algoritmo del resizind usato dal FlaskMpeg è stato l' HQ bicubico, il processo audio disabilitato. Ogni test è stato fatto 2 volte: la prima volta usando l' MMX iDCT e la seconda volta usando l' IEEE-1180 reference iDCT.

I risultati

Per prima cosa diamo un'occhiata al file README che accompagna il programma FlaskMpeg. Esso dice:

Le informazioni video contenute nei files MPEG vengono espresse nel dominio della frequenza al contrario delle informazioni del caso reale (ovvero ciò che vediamo normalmente). Infatti tutta l'informazione viene compattata, e tale compattazione viene usata per comprimere (ridurre) la quantità totale d'informazione che poi andrà inviata lungo il canale di trasmissione. MPEG usa il DCT (Discrete Cosine Transform o Trasformata Discreta del Coseno) per poter trasportare ciò che vediamo nel dominio della frequenza. Per ottenere nuovamente la normale informazione reale dal file MPEG ecco che occorre applicare la cosiddetta iDCT (inverse Discrete Cosine Transform o Trasformata Discreta Inversa del Coseno), che , appunto, provvede ad eseguire il procedimento inverso.

Nonostante il fatto però che l'MPEG sia piuttosto rigido (praticamente tutti i decoders danno lo stesso flusso MPEG in uscita), lo standard ha un grado di libertà proprio nella scelta dell' iDCT da usare. In pratica, il decoder lavora meglio in base al proprio hardware. Ciò che lo standard richiede dal decoder è che l' iDCT rispetti le specifiche IEEE-1180, ovvero in termini più pratici, che l'errore proveniente dall' iDCT non oltrepassi il valore fissato dall' IEEE-1180.

Per l'appunto, FlaskMPEG possiede 3 algoritmi per l' iDCT, tutti conformi all' IEEE-1180. Uno basato MMX, uno basato sull'integrazione (integer) ed infine uno basato su virgola mobile ( flating point ). Dal momento che tutti sono conformi IEEE-1180, ecco che la modalità a virgola mobile è la più precisa, ma richiede moltissimo tempo di lavoro alla CPU. Il metodo ad integrazione dovrebbe andare bene per tutti coloro che non hanno istruzioni MMX, mentre il metodo MMX iDCT dovrebbe essere la scelta di default per chiunque.

In parole povere: tutti i 3 algoritmi sono conformi IEEE-1180 ed il Flask stesso suggerisce di usare l' MMX iDCT.

Iniziamo il lungo cammino....

La differenza di velocità è stata abbastanza considerabile: in un clip a 1800kbit/s il FlaskMpeg codificava a 6.82fps su un P3-550 dove, per lo stesso clip, il tutto scendeva a 2.08fps usando come riferimento qualità l' iDCT. La qualità è davvero così importante tanto da richiedere tempi più lunghi per la codifica?

mmx idtc

ieee reference

Allora...come riconoscerle? E' una bella domanda. Ma non voglio togliervi il divertimento...Se lasciate il cursore fermo sull'immagine allora apparirà una piccola nota che vi svelerà tutto. Di seguito però ci sono alcuni ingrandimenti delle aree evidenziate in rosso.

mmx idctieee reference

E' piuttosto difficile distinguerle vero? Se poi aggiungiamo il fatto che nel frame di partenza c'è molto disturbo nei muri...ed è proprio per questa ragione che vi sono molti macroblocchi. Anche usando bitrates più elevati alcuni di questi blocchi rimangono. Questo è proprio il modo in cui il DivX comprime un'immagine. Ho anche testato TMPG nella modalità 2pass e ho visto che il disturbo viene ricreato anzichè generare dei blocchi. Lascio a voi decidere quale sia meglio, e passiamo alla prossima rassegna di immagini.

ieee reference

mmx idct

ieee referencemmx idct

Sono molto differenti dalle originali queste immagini? Io dico di no. Un file però ha occupato un tempo di codifica lungo più del triplo del tempo rispetto a quello richiesto da un altro file.

Diamo un'occhiata alla scena dell'esplosione di qualche istante dopo:

mmx idct

ieee reference

E alla versione ingrandita:

mmx idctieee reference

Ed infine per fare le cose per bene, ecco un'altra serie di immagini:

mmx idct

ieee referencemmx idct

 

Conclusioni

A questo punto viene spontaneo chiedersi: che significa tutto questo? Bene, sarà opportuno esprimere il mio punto di vista.

Io ho osservato queste piccole immagini un paio di volte e non ho notato grandi differenze. Naturalmente le ho guardate senza audio e tenendo le luci della camera spente per avere tutte le sensazioni visive del filmato a disposizione. Ho anche allargato il filamto nella modalità a pieno schermo (1152x864) per far emergere gli errori con più facilità. In base ai test effettuati ed ai bitrates utilizzati avrete capito che in fatto di qualità non sono ricorso ad alcun compromesso. Nonostante ciò, però, ho provato comunque ad individuare con molta attenzione eventuali errori, ma non ne ho trovati.

Potete vederlo anche voi dagli screenshots che la differenza fra MMX iDCT ed il riferimento iDCT IEEE-1180 non si nota. Neppure con la codifica a 1500kbit/s da cui provengono gli screenshots, sia a bitrate alto che basso.

Sulla Tom's hardware guide viene riportato:

In ogni caso, la tendenza a produrre un certo numero di alterazioni nel video MPEG-4 risultante è dovuto al fatto che il valore del pixel in tutti i frames codificati è approssimativo. Pertanto quando una seconda trasformata DCT viene applicata per la conversione inversa dell' MPEG-4, ecco che subentra un'altra approssimazione, producendo in taluni casi dei risultati veramente orribili.

Utilizzando la codifica IEEE molte di queste alterazioni vengono eliminate, e si ottiene un risultato in uscita che è molto vicino ad alcuni filmati DVD il cui bitrate è settato all'incirca al 20% rispetto al bitrate originale (nell'esempio del DVD di Matrix si ha 1.5mbps contro i 7.5mbps originali).

Confermo ciò che è stato appena detto...ho codificato Matrix a 1500kbit/s, e NON CI SONO STATE DIFFERENZE. Scusa Toby, ma ciò che hai detto non è giusto. I miei filmati video sono risultati molto buoni e puoi credemi che ho trovato alcuni errori di codifica dove chiunque altro non sarebbe riuscito ad individuare alcuno difetto. In questo caso l'algoritmo relativo all'IEEE non ha prodotto alcun effetto particolarmente evidente, se non un tempo di codifica almeno 3 volte superiore a quello normale.

In parole povere: dormite sonni tranquilli e non preoccupatevi di recodificare tutti i vostri DVD. Inoltre non è neanche il caso di correre ad acquistare un Athlon a 1.2GHz solo per poter essere in grado di creare DivX ad un orribile 6fps.

Ciò che diceva in pratica l'articolo di Tom era questo: AMD ha una FPU nettamente migliore di quella Intel. Forse questo è importante nella codifica MPEG-2 ma certamente non lo è più nella codifica MPEG-4. Io penso che il riferimento iDCT della qualità sia legato all'implementazione MPEG del gruppo software di simulazione. Di solito queste implementazioni sono buone in termini di qualità, ma persono un po' in termini di velocità. Se un software che funge da player DVD utilizza il riferimento iDCT, potrete guardare immagini per i prossimi 5 anni....tutti gli algoritmi iDCT più usati saranno al massimo ottimizzati MMX  ma questo non vuol necessariamente dire che quello usato dal FlaskMpeg sia il migliore...ce ne sarà sicuramente un altro ancora più valido.

C'è anche da considerare un ultimo fatto: nella parte iniziale dell'articolo relativo al DivX c'erano anche un paio di errori sulla parte di Tom. Su www.inmatrix.com emergono molti di questi. Fra tanti c'era anche il dubbio che l'utilizzo del neighbor resizing producesse dei risultati veramente pessimi. Come è stato sottolineato però, è anche stato scritto che per files di dimensioni ridotte è possibile usare questo tipo di filtraggio. Credete a me, non fatelo...è disastroso. Inoltre non penso affatto che l'algoritmo di riferimento IEEE sia in grado di riparare ciò che un certo tipo di filtraggio ha distrutto.



Traduzione svolta il 30 / 7 / 2002