flaskMPEG

Introduzione

Le versioni con il Decss

Velocità di decodifica

Le diverse IDCT

Le specifiche IEEE-1180

L'accumulo di errori in un GOP

Gli errori invisibili: il test

Le varie versioni di FlaskMPEG: il test

La iDCT "qualità di riferimento" e il "caso Pentium 4"

Qualità ed errori delle diverse versioni di FlaskMPEG

Altre caratteristiche

La versione 06 preview

Conclusioni: guida rapida alla scelta

Comparazione di Flaskmpeg con gli altri metodi

Links e installazione

Il software freeware FlaskMpeg , scritto originariamente da Alberto Vigatá, è in grado di decodificare file mpeg 1 e 2 e vob (il formato audio-video usato nei DVD) e tramite dei plug-in esterni compatibili con lo standard "Premiere plug-in" è in grado di convertire tali mpeg in altri formati e/o risoluzioni : avi o mpeg 1 o 2.

Un'altra importante caratteristica di FlaskMpeg è la capacità di interpretare i file vts_*.ifo, quelli che contengono le informazioni sui flussi audio-video (durata, lingue,...) così da permettere con maggiore facilità la conversione : basta in tal caso indicare il file *.ifo relativo al video da convertire che automaticamente saranno individuati i file vob corrispondenti e l'utente potrà direttamente accedere all'intero film.

A partire dalla versione 06 preview, disponibile dal 6 Marzo 2001, che è a tutti gli effetti una versione Beta della futura versione 06), per una serie di motivi legati ai diritti sul formato DVD, la interpretazione dei file *.ifo è stata eliminata dalla versione ufficiale di Flaskmpeg (cosa che avrebbe certamente creato dei problemi ad A. Vigatà). In realtà in concomitanza con la disponibilità della 06 preview nel sito ufficiale di Flaskmpeg, sul sito Doom 9, è apparsa una versione con incorporato il supporto ai file *.ifo e in più per chi ha scaricato la versione 06 dal sito "ufficiale", il plug-in thunder.mism.flaskm che la rende ugualmente compatibile ; la contemporanea disponibilità di tale file con la 06 preview dimostra come in realtà è stata fornita direttamente da Vigatà attraverso "canali alternativi".

Dopo appena 3 giorni si è resa disponibile sempre sul sito Doom 9, un plugin che implementa l'algoritmo di DECSS che permette alla nuova 06 la lettura diretta dei DVD decriptati su DVD-ROM; se la prima revisione è inutilizzabile ( si pianta dopo pochi secondi), la seconda versione del plug-in Decss, del 11 marzo, appare già molto stabile, nonostante le cautele dell'autore che simpaticamente parla di una stabilità paragonabile ad un sw in versione 1.0 prodotto da Microsoft.

Non mi dilungo sulla questione del mancato supporto "ufficiale" dei file IFO, ma questa vicenda sembra una fotocopia di quello che è successo per l'encoder freeware tmpeg, per il quale nelle ultime versioni la compatibilità con l'mpeg2 è stata limitata a 30 giorni per questioni di diritti sul formato mpeg2; tale limitazione si è mostrata in realtà una vera e propria farsa , nel momento in cui il limite dei 30 giorni è stato inserito in maniera facilmente superabile, tanto che in pochi minuti sono riuscito a trovare il modo di superarlo ( NON sono un Hacker e non ho nessuno strumento particolare per crackare i sw): non a caso dopo un paio di giorni è apparsa sulla rete una versione modificata senza alcun limite sull'mpeg 2. Credo che queste due vicende ci dovrebbero insegnare come alcune licenze devono essere applicate con un minimo di buon senso sopratutto nel momento in cui vengono imposte a posteriori e su sw freeware. Ben diverso è il discorso commerciale, in cui giustamente chi brevetta un formato ne vuole ricavare profitto nel momento in cui questo è utilizzato per prodotti in vendita: per ogni disco o lettore DVD venduto sulla faccia della terra un contributo non indifferente è versato a chi ne detiene i diritti.

Altra data importante, il 19 marzo 2000, in cui sono stati resi disponibile le implementazioni IDCT di Miha (datate 16 marzo), che tramite un plug-in accelerano e migliorano le caratteristiche della 06 preview.
Per intenderci ogni volta che trovate indicata la versione "06 preview-Miha " mi riferisco alla versione 06 preview a cui è stato aggiunto il plug-in Miha.idct.flask.
L'elenco delle novità presenti nella 06 preview li trovate nel capitolo relativo.

Un piccolo consiglio per la lettura di questo articolo. vista la presenza di tabelle e immagini spesso molto grosse è consigliabile la visione della pagina a tutto schermo (F11 per il Microsoft Internet explorer) e a risoluzioni elevate (la pagina è ottimizzata per la 1152*864, ottima risoluzione per i 19 pollici). Per risoluzioni inferiori è consiabile l'utilizzo di caratteri più piccoli (visualizza carattere/molto piccolo o piccolo)

Riguardo l'uso di flaskmpeg per le conversioni mpeg1 (XVCD) , mpeg2 (SVCD o MiniDVD) e AVI (DivX;-) o altro) vi rimando agli articoli corrispondenti che trovate nella sezione Digital Video del mio sito che appunto utilizzano flaskmpeg come base per tali conversioni.

Consiglio inoltre la lettura dell'articolo Il Css e il ripping dei DVD su Hard Disk: possibili applicazioni per chiarimenti sulla struttura dei file del DVD e su come decriptare i DVD, nel momento in cui parecchie versioni di flaskmpeg sono solo in grado di convertire DVD privi della protezione Css, e quindi rippati su HD.

I due maggiori pregi di FlaskMpeg stanno nella immediatezza della sua interfaccia e nel fatto che i sorgenti in C++ e in assembler sono di pubblico dominio. Chiunque li può prelevare dal sito "ufficiale" (link) e modificarli, con l'unica restrizione di non utilizzarli per creare un sw commerciale (cosa che sinceramente nessuno può escludere a priori, vista la semplicità con cui è possibile inglobare codice all'interno di una applicazione).

Vista la complessità del sw che contemporaneamente interpreta i file ifo e vob, decodifica l'mpeg 1 e 2, decodifica l'audio ac3, utilizza routine di elaborazione dell'immagine per ridimensionare il video, tagliarne pezzi (crop), eventualmente deinterallacciarlo e infine si collega ai plug-in di Premiere, è impensabile che tutta questa mole di lavoro possa essere fatta da una sola persona. In realtà, se oggi esistono dei software freeware complessi come flaskmpeg, il merito sta anche nel meccanismo del "Open Source", ovvero nella libera e gratuita circolazione dei sorgenti di programma messi a disposizione da programmatori generosi.

Riguardo flaskmpeg i sorgenti che sono stati utilizzati, inglobati e ovviamente personalizzati derivano da altri progetti, come correttamente indicato nei sorgenti: per la decodifica Mpeg sono stati utilizzati sorgenti della MPEG Software Simulation Group e ottimizzazioni della Intel, per la decodifica ac3 quelli del sw ac3dec di Aaron Holtzman mentre per il collegamento ai plug-in di Premiere, chiaramente i sorgenti sono stati modificati partendo dal Premiereª 5 Plug-In Developer's Toolkit: Vigatà, l'autore di flaskmpeg ha ovviamente correlato il tutto, creato la struttura e la grafica del programma e soprattutto ha personalmente modificato routine fondamentali quali quella della conversione dei colori (YUVtoRGB), della interpretazione della struttura dei file ifo, e quella della decodifica della trasformata coseno inversa utilizzando le istruzioni MMX ( MMX32 iDCT algorithm) , il cuore della decodifica mpeg. Per quello che ho potuto osservare, dando una occhiata ai sorgenti di flask mpeg, praticamente ogni routine è stata controllata e ritoccata da Vigatà: un lavoro veramente incredibile a cui va la mia gratitudine e ammirazione!!!

Dal 6 marzo 2001 è resa disponibile la versione "ufficiale" 0.6 Preview, che a seguito alle grosse modifiche apportate al codice e alle numerose modifice introdotte, è a tutti gli effetti una versione Beta; Vigatà ha ovviamente deciso di rendere pubblica la versione per poter disporre di una serie di test "a base planetaria"; è il bello del freeware !!!

La possibilità di migliorare il programma, grazie ai sorgenti in C++ e ASM liberamente utilizzabili, hanno fatto fiorire un numero incredibile di versioni alternative al flaskmpeg originale, ciascuna con dei pregi e difetti che cercherò di analizzare: spesso ciascun miglioramento è presente in una singola versione!!!

Da osservare come la nuova versione 0.6 è ancora più modulare rispetto a tutte le versioni precedenti: grazie a ciò il lavoro di ottimizzazione fattibile con delle modifiche a parti di codice diventa molto più semplice; al di là delle novità inedite, e della maggiore velocità, ritengo che la rinnovata modularità sia la vera novità che renderà Flask mpeg ancora più veloce e affidabile.

La prima importante modifica all'originale è stata l'inserimento delle capacità di DeCss: la versione originale di flaskmpeg, che per scelta dell'autore è ASSOLUTAMENTE LEGALE E RISPETTOSA DI TUTTE LE LICENZE CHE SONO LEGATE ALL'UNIVERSO DVD, non è in grado di decodificare e convertire i DVD protetti dalla criptatura css, ovvero della stragrande maggioranza dei DVD in commercio: per questo motivo con la versione originale di Flaskmpeg è possibile convertire singoli vob o interi film, solo se questi non sono criptati. Tra i DVD privi di protezione Css cito ad esempio la quasi totalità dei DVD in vendita in edicola ed eccezioni quali "Die Hard 3" e "Al di la dei sogni" o "Casper: il film". Grazie alla capacità di Flaskmpeg in questi casi è possibile fare la conversione senza copiare nessun file dal DVD su HD.

Per convertire un film criptato ( la quasi totalità dei film prodotti dalle Major) ci sono due alternative: la prima è l'uso di una versione DeCSS di flaskmpeg , così da fare la conversione direttamente da DVD senza copiare nulla su HD ; la seconda alternativa sta nel copiare su HD l'intero film, decriptandolo con sw quali DVD Decripter o Smart Ripper , ed in seguito utilizzando una qualsiasi versione di Flaskmpeg, versione ufficiale compresa, che permetterà la conversione poichè il film sarà visto come non criptato. (per chiarimenti sul CSS e DeCess e guida all'uso di Smart Ripper e DVD Decripter, vi rimando al'articolo Il Css e il ripping dei DVD su Hard Disk: possibili applicazioni )

In entrambi i casi prima di utilizzare flaskmpeg occorre autenticare il drive DVD o utilizzando per qualche attimo un player sw (winDVD, Cinemaster, Power DVD .....) o avviando un programma di ripper ( Smart Ripper o DVD Decripter vanno benissimo)

OSSERVAZIONE IMPORTANTE: esistono alcuni Film che non vengono correttamente convertiti dalle versioni Decss di flaskmpeg (crash di sistema, immagini a scatto, .... ) a causa della incapacità di tali versioni nel realizzare un corretto decriptaggio. Il classico esempio sono quei film in cui la chiave di criptatura cambia, all'interno del film stesso (vedi al passaggio tra un capitolo e il successivo): in tal caso flaskmpeg nel punto in cui cambia la chiave, va in crash.

In tutti i questi casi occorre procedere al metodo di decriptazione su HD. Stesso discorso tutte quelle volte in cui la conversione si blocca magari dopo un paio di ore, a causa di configurazioni non particolarmente stabili o a causa della presenza di programmi residenti che vanno in conflitto con l'operazione di conversione (che può durare anche parecchie ore).

Due parole sulla questione che interessa un po' tutti: la conversione fatta, grazie alle capacità di Decss, direttamente da DVD-Rom danneggia il lettore?. Su molti siti ho trovato affermazioni esagerate sulla questione; la conversione eseguita in tale maniera ridurrebbe drasticamente la vita dei lettori DVD-Rom, "condannati" a rapida rottura dopo poche conversioni.

In realtà durante la conversione diretta, il DVD-Rom non viene sollecitato diversamente da quanto non accada durante la riproduzione dei film: il lettore in entrambi i casi legge pacchetti di dati dal DVD alla massima velocità possibile di dimensione pari alla propria cache interna: appena questa è svuotata a seguito delle richieste del sw, procede alla lettura di altri dati nella stessa modalità. A causa del bitrate variabile dell'mpeg 2 la lettura fatta dal DVD-Rom non è mai continua neanche durante la visualizzazione del film eventualmente a velocità 1X: per questo motivo la continua accensione e spegnimento del laser non è assolutamente una prerogativa della conversione diretta e quindi non è assolutamente dannosa. L'unica sollecitazione particolare è dovuta dal funzionamento continuo del DVD-Rom, a causa di conversioni di durata spesso "biblica". Chiaramente come qualsiasi componente meccanico, la "vita media" prima della rottura è un dato normalmente fisso e pertanto un maggior uso non può che diminuirne la durata: i lettori DVD, visto il loro uso, sono progettati per avere un numero di ore di funzionamento prima della rottura elevato e pertanto ritengo abbastanza esagerate le affermazioni allarmistiche viste. L'alternativa è acquistare un lettore DVD-ROM e non utilizzarlo mai.... vantandosi dopo 15 anni della sua resistenza infinita !!

Il mio consiglio è di fare il ripping ogni qual volta che lo spazio su HD lo consente e nel caso di lunghe conversioni: per fare dei test o nel caso non si dispone dello spazio necessario su HD, la conversione diretta è una ottima alternativa ; chiaramente se si decide di fare conversioni in continuazione è ovvio che la "vita" del lettore non può che abbreviarsi, ma ciò NON significa che dopo 200-300 ore di conversione si dovrà sostituire il lettore!!!! Forse dopo 3-4 anni di "sforzi continui" potrebbe avvicinarsi il momento di mandarlo in pensione, ma niente di certo o matematico!!! Il mio consiglio è quello di preoccuparsi maggiormente della qualità del modello da acquistare, spendendo 30-40000 lire in più e procurandosi un lettore di marca in grado di durare nel tempo: un lettore mal progettato e costruito "al risparmio" è sempre una vera e propria bomba ad orologeria.

Ovviamente nel caso in cui la versione che contiene la decriptazione automatica non funziona correttamente, prima di ricorrere al ripping su HD, è opportuno tentare con una delle versioni che richiedono l'inserimento manuale del Key.

Il secondo punto fondamentale su cui le diverse versioni differiscono, è la velocità di decodifica.

Ad essere sincero c'è una certa disinformazione su questa questione e spero di fare chiarezza.
Ciò che dicono i detrattori di flaskmpeg è semplice: se prendo un file vob 720*576 e lo faccio decodificare da flaskmpeg v.0594, versione ufficiale e lo stesso file lo decodifico con il sw DVDtoAvi (considerato da molti il rivale o dai meno "cattivi" il futuro sostituto di flaskmpeg), ottengo con flaskmpeg una velocità pari circa ad un terzo.

Questo dato è assolutamente vero: con il mio P2 400 Mhz nella semplice decompressione ottengo con un vob di test, 21.3 fotogrammi al secondo (fps) con DVDtoAvi e solo 7.4 fotogrammi con flaskmpeg v.0594 originale (solo il 48% della velocità di DVDtoAvi).

In realtà le doti velocistiche di DVD2AVi sono relative alla decompressione dell'mpeg nello spazio colori 4:2:2 che normalmente deve essere convertito in RGB per essere utilizzato nelle conversioni in altri formati; al contrario Flaskmpeg lavora già sul formato RGB e pertanto impiega sempre parte della potenza di calcolo della CPU per la conversione 4:2:2---> RGB.

Per paragonare le prestazioni tra flaskmpeg e DVD2Avi occorre paragonare le doti velocistiche di DVD2avi in modalità RGB, con quelle di Flaskmpeg, relativamente alle versioni più veloci (vedi la Flaskmpeg v.0594 PX3 s2v3 Miha). Il vantaggio di DVD2Avi rimane, ma è ridotto a pochi punti percentuali.

Ecco una tabella riassuntiva dei test sulla semplice decodifica dei vob :ho eliminato la previsualizzazione sul monitor che rallenta la velocità, visto che durante la compressione è una buona abitudine escluderla: per fare un confronto alla pari ho eliminato i filtraggi presenti in flaskmpeg relativi al ridimensionamento (filtraggio bilineare, bicubico filter,...) ma ho lasciato "ridimensionamento prossimo" : facendo un breve test si vede che in modalita 720*576, tali filtri rallentano la decodifica senza produrre alcuna variazione delle immagini (si ottengono avi bit a bit identici al caso "ridim.prossimo") ovviamente poichè non viene effettuato nessun ridimensionamento... Il test è realizzato sfruttando la modalità benchmark del plug-in avisynth 1.0 Beta36 e ho usato le modalità IDCT più veloci: MMX idct per flask e per DVD2AVI.
Per quanto detto l'opzione DVD2AVI 4:2:2 è in realtà "fuori gara" !!!

La seconda cosa da chiarire è che nel momento in cui faccio la conversione da DVD in altro formato, il tempo che la CPU impiega per la decodifica del video è solo una percentuale del tempo utilizzata in tutta la conversione poiché pesano fortemente i tempi relativi al sw che poi deve comprimere in Mpeg 1 o 2 , DivX;-) ,......

Tanto più il codec di compressione Mpeg, DivX;-) impiega tempo , tanto meno i vantaggi sulle velocità di decodifica di Flaskmpeg, DVDtoAvi o altri sw analoghi, contribuiranno a diminuire il tempo totale del processo di compressione (quello che alla fine interessa all'utilizzatore).

Detto in breve, considerando la tabella, se DVD2AVI impiega 1 minuto a decodificare un certo spezzone di video e Flaskmpeg originale 1.90 minuti, NON E' VERO che se ad esempio faccio un video DivX,-) in 10 minuti con DVDtoAVI, devo impiegare addirittura 19.3 minuti (10*1.9) con Flaskmpeg, ma grazie al cielo molto di meno ; infatti la CPU impiegherà lo stesso tempo nell'utilizzo dei codec DivX,-) in entrambe le conversioni e pertanto il vantaggio di velocità complessivo sarà inferiore rispetto al vantaggio dovuto alla maggior rapidità della conversione di DVD2AVI rispetto a Flaskmpeg .

La cosa è evidente dal seguente schema in cui si comparano due conversioni Vob ---> Divx;-) la prima realizzata utilizzando DVD2Avi e la seconda utilizzando una versione di Flask che impiega ad esempio il doppio del tempo nella decodifica.

E' chiaro come il tempo complessivo di codifica del caso più lento NON è doppio !!!

E' noto come all'aumentare della risoluzione video i codec di compressione vanno sempre più lenti ed è altrettanto noto come la compressione DivX;-) a parità di risoluzione è più rapida dei codec mpeg della Ligos, ancora di più rispetto ai codec mpeg di tmpeg e incomparabilmente più veloce di bbmpeg; per questo motivo i vantaggi di velocità che ho con versioni ottimizzate di flaskmpeg, considerando i tempi globali di conversione, sono più evidenti per conversioni di filmati aventi risoluzioni ridotte (es 352*288) ma meno evidenti con risoluzioni maggiori (es. 640*360); più evidenti per conversioni in DivX;-) e meno evidenti per conversioni fatte con i codec ligos o peggio ancora con tmpeg. E' ovvio che sta facendo un discorso quantitativo sui tempi e non sulla qualità del video; è noto che i codec ligos rispetto a tmpeg producono video di qualità inferiore, ed è per questo motivo che sono molto più rapidi.

Nello schema che segue è evidente come la maggiore velocità di DVD2AVI è influente sul tempo complessivo in maniera più evidente nella compressione DivX;-) che mpeg poichè i tempi fissi dovuti alla compressione mpeg sono superiori a quelli del DivX,-)

Semplificando al massimo il discorso, ed estremizzandolo, è chiaro che risparmiare un minuto su una compressione di 3 minuti diventa importante poichè per ogni ora di compressione si risparmiano 20 minuti; al contrario risparmiare 1 minuto su di un'ora di compressione diventa praticamente insignificante.

Ovviamente gli schemi visti, sono concettuali poichè il processore in multitasking alterna decompressione e compressione a gruppi di 10-15 frame. Globalmente il calcolo sui tempi impiegati è lo stesso.

Altra cosa da osservare è che, allo stato attuale, DVD2AVI permette la compressione diretta in formato avi e in particolare DivX;-) solo alla risoluzione originale del vob (720*576 per il PAL): per creare filmati aventi risoluzioni inferiori (le tipiche risoluzioni del DivX,-) ) occorre agganciarsi ad altri sw, quali Virtual dub che ridimensionano il video prima di farlo comprimere al codec DivX;-). Il risultato è che il collegamento tra DVD2AVI e VirtualDub azzera tutti i vantaggi che DVDtoAVI ha nella pura decompressione rendendo il metodo con Flaskmpeg più rapido.

Senza addentrarmi nella questione è evidente come collegare due sw non è banale poichè occorre operare sullo stesso tipo di dati, cosa che comporta delle conversioni di formato (ad esempio lo spazio colore YUV o RGB) che se non ottimizzate rallentano tantissimo i tempi totali di conversione: DVD2AVI per quello che è possibile valutare dai test, non è certamente una scheggia nel momento in cui esporta i propri dati ad altre applicazioni come ad esempio Virtualdub (lo fa attraverso il metodo analizzato nell'articolo su DVD2AVI): convertire un Vob in DivX;-), tramite DVD2avi-->Virtualdub-->DivX;-) significa dover aggiungere ai tempi di decompressione di DVD2avi, il tempo per le conversioni di formato e il tempo impiegato da Virtualdub per le elaborazioni (ridimensionamento del video).

Lo stesso discorso vale nel momento in cui si crea la catena Flaskmpeg---> avisynth--->Tmpeg: in tal caso Flaskmpeg converte il formato colore nativo del DVD, lo YUV in RGB; è con tale formato che avisynth passa ai dati a Tmpeg, che per ricomprimere in mpeg sarà costretto a fare una nuova conversione da RGB--> a YUV . Tale doppio , inutile passaggio, potrebbe essere eliminato, tramite nuove versioni di FlaskMpeg, avisynth e Tmpeg. E' stato calcolato che in tal caso si otterrebbero guadagni nei tempi di conversione dell'ordine del 20%.

Nell'ultima parte di questo articolo, nella tabella in cui analizzo risultati sui metodi alternativi a Flaskmpeg, appare evidente quanto appena detto: DVD2AVI brucia tutte le sue doti velocistiche nel momento in cui passa i suoi dati alle applicazioni di compressione; nella pratica non ci sono grossi vantaggi nell'utilizzarlo (in attesa di un eventuale miglioramento nelle prossime versioni).

Lasciando da parte DVD2AVI e ritornando a Flaskmpeg, tutti i discorsi che seguono sulle velocità delle varie versioni Flaskmpeg devono necessariamente tener conto di quanto appena detto: i miglioramenti possono essere molto evidenti nelle compressioni DivX;-) a risoluzioni più o meno ridotte (ad esempio la 352*288 per i film 4:3 o la 480*288 per i 16:9), mentre se si è interessati a conversioni DVD---> SVCD, a causa dei lenti tempi di compressione dell'mpeg alla risoluzione 480*576 i vantaggi diventano quasi inavvertibili.

Ecco una tabella in cui ho comparato la nuova versione 0.6 preview con il plug-in iDCT Miha , la versione 0594 "ufficiale" di Flaskmpeg (dalla quale derivano tutte le nuove versioni ), con la versione ad oggi in assoluto più veloce, la v.0594 PX3 s2v3 Miha che allo stato attuale però, a seguito di un bug, può fare solo delle conversioni che iniziano dal principio del video e nei cambi di capitolo di un DVD inserisce lievi artefatti al video e una brevissima interruzione dell'audio ; ho pertanto inserito i tempi della versione Flaskmpeg v.0594 PX3 004e che è leggermente più lenta ma priva di tali bug : ho valutato i guadagni di tempo nella sola decompressione di un vob (usando come sw di banckmark avisynth 1.0 Beta 31), e con diverse compressioni in mpeg o DivX;-).

Osservo come il dato sulla velocità della sola decodifica vob è ai fini pratici assolutamente inutile perché corrisponde alla velocità di visualizzazione quando si utilizza il lettore di flaskmpeg (a nessuno verrà in mente di visualizzare i flilm in DVD con flaskmpeg !!!): è comunque importante perché rappresenta la velocità teorica che otterrei se usassi un ipotetico compressore che non impiega alcun tempo per la compressione., ovvero è il parametro che mostra i miglioramenti del solo sw flaskmpeg al variare delle versioni. Tali tempi sono quelli che nei grafici di prima ho indicato in verde

Nella tabella che segue ho indicato i fotogrammi al secondo e i guadagni sui tempi di compressione rispetto alla versione originale v.0594; pertanto ad esempio il +30% indica che a parità di parametri con la versione di flask corrispondente si ottiene un risparmio di tempo del 30% rispetto alla versione originale v.0594: cioè ad esempio su ogni ora di compressione rispetto al flask più lento si risparmiano 60*0.3= 18 minuti ovvero 42 minuti di codifica rispetto ai 60 minuti.

I test sono stati fatti con un Pentium 2 400 Mhz 128 MB Ram utilizzando un VOB PAL 720*576 25fps in formato 16:9 anamorfico (privo cioè di bande nere) decriptato e copiato su HD: si è utilizzata la modalità di flaskmpeg Idct MMX , audio 44100 e ridimensionamento con filtraggio bilineare , eliminando la visualizzazione che rallenta leggermente le conversioni. Per escludere la presenza di bande nere orizzontali che velocizzano i test a seguito della relativa semplicità con cui vengono decodificati, in flask NON ho selezionato, "mantieni rapporto altezza, larghezza"

Nel caso della px3 004e ho utilizzato la Idct non-MMX che è risultata leggermente più veloce della versione MMX; è possibile che con altre CPU diverse dal P2, sempre con la px3 004e, la opzione MMX risulti più rapida della non MMX, ( come appare ad esempio su di test fatto con un AMD Duron 800). Riguardo le compressioni XVCD e SVCD ho utilizzato il sw tmpeg con l'opzione Motion search accuracy = normal, mentre per il DivX;-) ho utilizzato il codec low motion versione 3.11alpha e audio Wav PCM non compresso .

E' evidente come all'aumentare della complessità nella compressione, cioè all'aumentare dei tempi di codifica globali , i vantaggi delle versioni più rapide di FlaskMpeg tendono a diventare trascurabili: i due estremi sono il DivX;-) 352*288, molto rapido da comprimere in cui i vantaggi delle versioni più veloci sono evidenti, e il SVCD 480*576 a cui ad una lentezza nella compressione seguono guadagni marginali.

Ricordo come noti i fps (vedi tabella) i tempi di compressione si ricavano tramite il parametro "Realtime" che rappresenta il fattore da moltiplicare per ricavare il tempo che occorre per comprimere un dato spezzone video. Il Realtime lo si ricava tramite la seguente formula:

Realtime = 25/fps (25 sono i fps del video PAL che suppongo di convertire)
es. fps=7.1 Realtime=25/7.1= 3.52 1 minuto di video è compresso in 3.52 minuti, 3 minuti e 31 secondi (60*52=31), 1 ora di video in 3 ore e 31 minuti,......

Facendo dei brevi test , come già detto, ho notato come anche decodificando alla risoluzione originale del DVD (720*576), i filtri di ridimensionamento di flaskmpeg (bilineare, bicubico) pur non apportando nessuna modifica rispetto al caso di filtraggio assente (ridimensionamento prossimo) rallentano la decodifica ; basta creare due avi non compressi con o senza filtraggio e si ottengono due file identici.

Chiarito, spero, in quale percentuale gli incrementi di velocità del solo flaskmpeg influenzano i tempi totali di conversione, occorre chiarire uno dei punti chiave su cui le diverse versioni di flaskMpeg vantano presunti miglioramenti: l'algoritmo IDCT utilizzato per la decompressione degli mpeg e quindi dei vob.

A prova dell'importanza di tale algoritmo, a partire dalla nuova versione 06 preview, la IDCT viene implementata in un plug-in esterno: la cosa diventa molto comoda per i chi desidera fare delle ottimizzazioni o delle modifiche alla IDCT nel momento in cui non occorre compilare l'intero flaskmpeg ma solamente il plug-in relativo.

A seconda della versione di flaskmpeg e della CPU posseduta, si hanno a disposizione più scelte possibili:

A chi vuole approfondire il discorso della compressione MPEG, consiglio di leggere l'articolo "I formati Mpeg1 e 2: come funzionano e come utilizzare al meglio tutti i parametri di Tmpeg encoder. Dalla teoria matematica . . . all'uso di tutti i giorni" che trovate nella pagina Digital Video.

Riguardo la parte che concerne il parametro "Opzioni IDCT", l'importante è sapere come, diversamente dalla compressione mpeg in cui i metodi per velocizzare i tempi di compressione sono tantissimi (è lasciata molta libertà alla "fantasia" del programmatore), nel caso della decompressione mpeg l'operazione che impiega la gran parte della potenza della CPU e quindi pesa fortemente sulla velocità di decompressione, è la "IDCT, Trasformata Discreta Coseno Inversa, ". Tale operazione viene fatta per ciascun blocco di 8*8 pixel in cui è diviso ciascun fotogramma del video compresso in mpeg.

Nella pratica la IDCT altro non è che un pezzo di programma che esegue la seguenti operazione:

dove F (u,v) è una matrice di 8*8 numeri interi compresi tra 0 e 255 (sono i 64 coefficienti della DCT nel campo delle frequenze) da cui si devono ricavare analoghi 64 valori sempre compresi tra 0 e 255 che rappresentano la luminanza o crominanza di un blocchetto di 8*8 pixel dell'immagine da decomprimere.

Tutte le altre operazioni che contribuiscono alla decompressione del video mpeg, sono state ormai da tempo ottimizzate e presentano solo piccoli margini di miglioramento in termini di velocità . Al contrario la IDCT si presta a numerosissime ottimizzazioni grazie a due fondamentali motivi: il primo è che è possibile approssimare il calcoli facendo degli errori spesso assolutamente invisibili all' occhio umano; il secondo è che è possibile implementare tali calcoli sfruttando diversi tipi di numeri e il parallelismo di tipo SIMD (singola operazione su dati multipli) presente nei set di istruzioni delle CPU recenti. Le differenze di prestazioni sono enormi: ad esempio con un Pentium 2 400 è possibile passare nella sola decodifica da 1-2 fotogrammi al secondo sino a quasi 20.

Le possibili diverse "aritmetiche " implementabili per la IDCT, con una tabella sulle compatibilità con le principali CPU in circolazione sono:

Le implementazioni possibili le possiamo dividere in 4 categorie che analizzerò tra breve:

Come valutare le diverse implementazioni ? I criteri sono due: velocità e errori prodotti.

Riguardo la velocità è ovvio che a parità di video prodotto conviene scegliere il metodo più veloce..... e complimentarsi con il programmatore che è riuscito ad implementare il metodo , magari con una e-mail di complimenti che non può che risultare gradita. (per la cronaca ho mandato un e-mail di complimenti a Miha Peternel, l'autore di quello che è ad oggi l'algoritmo IDCT più veloce.... e dopo un giorno mi è pervenuta la sua risposta, con in più il consiglio su dove scaricare la versione più stabile!!!! ).

Riguardo la questione degli errori prodotti dalla particolare implementazione, occorre chiedersi quanti errori sono prodotti, quale tipo di errore e che vantaggi di velocità si ottengono con quella particolare implementazione.

Gli errori nella decodifica si traducono in pixel sbagliati, ovvero in pixel che hanno un colore , rappresentato dalla tripletta RGB errato. Ciascun pixel lo si descrive con i corrispondenti valori a 8 bit dei fattori R (red, rosso), G (green, verde), B (blu), ciascuno dei quali assume un valore compreso tra 0 e 255. In totale si ha la ultra nota rappresentazione a 24 bit (8 bit * 3) per ogni pixel: si hanno 2^24 = 16 777 200 possibili colori che corrispondono al massimo numero di sfumature che l'occhio umano è teoricamente capace di distinguere.

Come si fa a vedere se la implementazione utilizzata produce un pixel sbagliato? Il metodo più semplice è quello di calcolarsi una immagine con un metodo di decompressione privo di errori (il metodo "qualità di riferimento" in flaskmpeg) e confrontare l'immagine con il metodo di cui si vuole valutare se ci sono errori. Se i pixel sono tutti uguali, il metodo è anche lui corretto; in caso contrario si possono valutare il numero di pixel sbagliati e di quanto sono sbagliati.
E' evidente che se ho un pixel corretto avente ad esempio il colore (128 ,100 ,100), un pixel errato (128,100,101) sarà praticamente uguale all'originale (l'occhio ha enormi difficoltà ad accorgersi di una differenza di colore così piccola), mentre un pixel (128,100, 112) sarà diverso in maniera evidente anche ad occhio nudo.

Per descrivere l'entità (ampiezza) dell'errore prodotto il metodo più semplice è fare la differenza tra pixel corretto e quello esatto ; si parla di errore di tipo x/256 a seguito del fatto che sono possibili 256 valori (0-255) per le 3 componenti R,G,B

Il numero di errori prodotti lo si può descrivere tramite "ogni quanti pixel corretti appare un pixel sbagliato": ricordo come in un DVD PAL avente risoluzione 720*576 a 25 fps ci sono

Quindi ad esempio una implementazione che sbaglia 1 pixel ogni 10 000 presenterà 41 pixel errati per ogni immagine (414720/10000), 1035 per ogni secondo,....

Chi ha formalizzato l'mpeg, ben conoscendo le problematiche relative agli errori nella decompressione che come ho detto sono legate all'implementazione della IDCT, in base a dei test fatti su decodifiche reali visionate da un gruppo di persone, ha creato le specifiche IEEE-1180.

Tali specifiche sono espresse tramite un test a cui viene sottoposta la particolare implementazione IDCT: l'implementazione che passa il test, garantisce una decodifica del flusso mpeg caratterizzata da errori trascurabili e praticamente invisibili all'osservatore. Una implementazione che soddisfa le specifiche IEEE-1180 non significa che è priva di errori, ma semplicemente che contiene errori che non superano quelli concessi da tali specifiche, e pertanto nella pratica invisibili.

Ovviamente una implementazione IDCT priva di errori (quella che in flask è detta Reference , di riferimento) supera nel migliore dei modi le specifiche IEEE-1180: errori matematicamente nulli.

Da osservare che tutte le implementazione IDCT che superano le specifiche IEEE-1180 non producono lo stesso risultato e anche tra loro è migliore quella che produce il minor numero ed entità (ampiezza) di errori: in tutti i casi tali errori sono praticamente invisibili all'occhio.

Attualmente TUTTE LE IMPLEMENTAZIONI di iDCT presenti nelle varie versioni di flaskmpeg soddisfano le specifiche IEEE-1180, nonostante l'infelice idea dei programmatori di segnare tale compatibilità solo in "qualità di riferimento": non a caso nella versione 06 tale imprecisione nella indicazione è stata eliminata.

A chi non è convinto della cosa, in relazione alla versione 0594, riporto ciò che è scritto nel manuale di Flaskmpeg:

"Anche se il formato MPEG è quasi deterministico (dato un flusso dati MPEG, il risultato in uscita dovrebbe essere identico in tutti i decodificatori) lo standard definito ha un certo grado di libertà quando si sceglie il metodo iDCT da utilizzare. In questo modo il decodificatore può essere implementato più facilmente in base all'hardware utilizzato. Ciò che lo standard richiede ai decodificatori è che il metodo iDCT utilizzato risponda alle specifiche IEEE-1180 o, in parole povere, che l'errore che si ottiene dal metodo iDCT non vada oltre quello permesso dalla specifica IEEE-1180.
Per il momento FlasK MPEG ha tre algoritmi per applicare il metodo iDCT e tutti rispondono alle specifiche IEEE-1180. Un metodo sfrutta le istruzioni MMX, un altro è basato su numeri interi ed il terzo utilizza cifre in virgola mobile. Anche se tutti sono compatibili con le richieste IEEE, il metodo che utilizza la virgola mobile è il più accurato ma richiede molto più tempo dalla CPU. Il metodo basato sugli interi è sufficiente per tutti coloro che non hanno un computer con CPU MMX e la versione che utilizza l'iDCT MMX dovrebbe essere l'opzione di default per la maggior parte degli utenti."

Nella nuova versione 06 preview è presente un test IEEE-1180 applicabile alle IDCT disponibili: sono create delle particolari matrici 8*8 delle quali è calcolata la IDCT e in seguito sono indicate le entità degli errori prodotti, come ad esempio il valore quadratico medio (Mean square errors MSE).

Come risultato del test viene prima di tutto indicato se la IDCT selezionata supera o meno il test IEEE-1180:
in caso affermativo appare la scritta: "nome della IDCT" Meets IEEE1180 spec; se il test non è superato appare "nome della IDCT" Does NOT meet IEEE1180 spec.

Ad esempio per la implementazione MMX è indicato "IEEE-1180 32 bits integer precision using MMX Meets IEEE1180 spec"

Poi sono elencati i vari test e per ognuno è indicato l'errore prodotto e a fianco il massimo errore consentito (Meets spec limit): il test è superato quando si ottiene un errore minore rispetto a quello consentito; ovviamente tanto più piccolo è l'errore tanto migliore è l'implementazione della IDCT.
Ad esempio:

Worst pmse = 0.015800 (Meets spec limit 0.06): il test è superato poichè 0.015800 è minore di 0.06
Overall mse = 0.012963 (Meets spec limit 0.02): il test è superato poichè 0.012963 è minore di 0.02

Il problema è cercare di capire se gli errori prodotti dalle implementazioni "meno accurate" sono realmente visibili ad occhio nudo o meno: per cercare di dare una risposta spero definitiva, ho escogitato un metodo di test che mi ha dato la risposta che cercavo.

Ho preso un paio di vob, uno tratto da Jurassic Park 2 (immagini relativamente piene di grana) e l'altre tratto da Toy Story 2 (immagini in computer grafica dotati di una gamma completa di colori), ed ho scelto 2 fotogrammi "significativi" che vedete in figura

Poi con i 3 diversi metodi disponibili ("MMX", "non MMX" e "riferimento") per ciascuna versione di flask esaminata ho creato degli avi 720*576 non compressi formati da un solo fotogramma che lo ho estratto con Virtual Dub tramite "save image sequence".

Con queste immagini (6 per ciascuna versione , 3 di Toy Story e 3 di Jurassic Park 2 ) ho fatto due tipi di analisi: una analisi a vista, per rilevare "ad occhio" eventuali differenze, ed una analisi diciamo più scientifica per valutare il numero di pixel errati e l'entità (ampiezza) degli errori tramite i raffinati strumenti matematici di Photoshop , aiutato anche da alcune macro programmate per l'occorrenza.

Riguardo l'analisi a vista, ho utilizzato il comodissimo ACDSee 32 che permette di scorrere e alternare le singole immagini anche molto rapidamente tramite la rotellina del mouse, visualizzandole in successione a schermo intero con sfondo nero; il tutto ovviamente sul mio ViewSonic PS 790, 19 pollici, con risoluzione 24 bit. I risultati hanno sinceramente sorpreso anche me !!
Considerando come ho osservato le immagini sia da lontano che da pochi centimetri dallo schermo per valutare differenze sul singolo pixel, e per valutare più facilmente eventuali differenze ho alternato le immagini anche molto velocemente, mi aspettavo di notare delle piccolissime variazioni, fasce di colori, pixel errati o i tipici difetti visibili con i DVD player sw meno precisi.

In realtà tutte le immagini decodificate e analizzate con tale metodo, di qualunque versione di flask e con qualsiasi decodifica IDCT utilizzata, SONO VISIVAMENTE IDENTICHE !!!! Non sono mai riuscito ad osservare alcuna differenza neanche impercettibile.

Le uniche differenze visibili le si hanno confrontando le immagini prodotte dalla nuova 06 Preview con tutte le altre; la causa non è certamente attribuibile alla IDCT poichè tali differenze sono presenti anche confrontando le immagini prodotte dalle modalità reference, ovvero le modalità che non introducono errori nella IDCT, della 0594 e la 06. Le differenze presenti nella 06 preview sono causate invece da una diversa implementazione della decodifica mpeg.

A conferma di ciò le immagini prodotte dalle diverse IDCT della 06 (.fast integer, MMX, AMD x87...) risultano visivamente identiche: la questione delle differenze presenti tra le modalità reference è trattata dopo

Da notare come grazie a Photoshop (tramite la sua possibilità di calcolare le differenze matematiche dei fattori RGB con image/calculations/difference) sapevo a priori la posizione degli errori e pertanto puntavo lo sguardo sui pixel che sapevo errati per cercare le differenze. Anche sapendo dove cercare gli errori, questi sono rimasti nascosti.

Da osservare come tali presunti errori anche se fossero visibili con il metodo visto, sarebbero poi magistralmente nascosti nelle immagini in movimento: quando si vede un filmato, certamente non si fa l'analisi pixel per pixel della sua correttezza confrontandolo con una versione matematicamente perfetta !!!
Tra l'altro stiamo parlando di un sw da utilizzare per fare poi delle conversioni in altri formati: alla decompressione segue il ridimensionamento ed una serie di artefatti inevitabili dovuti alla successiva compressione in Divx;-) , mpeg1 o 2, o altro. Lì gli artefatti fanno da padrone: una manciata di pixel errati prodotti da flask, nulla sarebbero a confronto degli enormi artefatti che poi seguono nella successiva compressione. In tutti i casi questi errori di flaskmpeg, non sono mai visibili.

Rimane un'ultima questione da appurare: l'accumulo di errori.
Nel video mpeg circa 14/15 delle immagini (i frame B e P) sono calcolate come differenze tra frame successivi, e pertanto l'errore presente in un frame si ripercuote in altri: questa cosa spaventa tanto i "sostenitori della modalità reference" che ritengono, a torto, che tali accumuli di errori causano differenze visibili tra la modalità reference e le altre.

Il test fatto, che ho appena descritto, era relativo a 2 fotogrammi di tipo I che sono quelli meno pieni di errori poiché decodificati indipendentemente dai frame precedenti o successivi.

La questione deve essere affrontata con i dati alla mano che sono: le leggi degli accumuli degli errori (lo si studia in statistica) e la sintassi dell'mpeg 2: senza scomodare distribuzioni di probabilità gaussiane o altro voglio ricordare come a seguito della struttura dei GOP , tipicamente IBBPBBPBBPBBPBBI, il caso peggiore di accumuli di errore è pari a 5: cioè il caso più sfortunato in assoluto è quello in cui un pixel è calcolato dalla differenza con un pixel in precedenza sbagliato, a sua volta pure lui vittima di una differenza con un pixel sbagliato che a sua volta è stato calcolato come differenza di un pixel errato.....questo in totale per 5 volte.

Per chi conosce la sintassi dell'mpeg, ecco una serie di esempi in cui indico in giallo il frame decodificato in cui valuto gli errori su un pixel, e in rosso i possibili frame da cui possono provenire errori: a destra il numero di accumuli di errore.

Accumulare gli errori significa incrementare le differenze rispetto ad una decodifica matematicamente corretta.

Se ad esempio senza accumulo di errore, posso sbagliare di una unità il colore di un pixel es. (5,42,13)---> (5,42,14) , se faccio un accumulo di errore (cioè due errori consecutivi dello stesso segno) posso raddoppiare l'entità dell'errore sino ad arrivare ad es. (5,42,13)---> (5,42,15) .

Nel caso peggiore in assoluto (la nuvoletta di Fantozzi!!) se ho accumuli di errori come quello visto pari a 5 ho un errore finale per esempio pari a (5,42,13)---> (5,42,19). Il bello è che la probabilità che ciò si verifichi è enormemente bassa, in prima approssimazione trascurabile. Il motivo che rende meno probabili gli accumuli di errore, sono 2 fattori (gli amanti della statistica, mi perdoneranno la semplificazione che sto per fare, ma non posso certamente parlare in termini di distribuzione di probabilità condizionate!!!):

Tutto questo discorso serve a dare una giustificazione teorica a quella che è la conclusione a cui sono giunto: anche l'aggravante dell'accumulo degli errori (che come visto è meno preoccupante di quanto molti in realtà affermano), non è in grado di provocare differenze visibili tra le decodifiche IDCT MMX e non MMX , rispetto a quella reference.

Per convincermene ho dovuto ripetere il test sulla visione di fotogrammi analoghi decodificati con le 3 modalità IDCT, ma questa volta ho esaminato 15 fotogrammi successivi, presi da Toy Story 2: per ciascuno dei 15 fotogrammi ho confrontato le 3 immagini decodificate con le versioni MMX, non-MMX e reference della versione Flaskmpeg 0594 originale. Cercando per ciascun fotogramma le differenze nelle 3 immagini prodotte, ancora una volta NON ho riscontrato mai alcuna differenza visibile.

Osservo come in base ad altri brevi test, la serie delle 15 immagini in esame sono da considerare una specie di "caso peggiore" a seguito dei colori molto vari e pieni di alte frequenze video dovuti alla natura artificiale del video (computer grafica): in altri casi ho trovato errori numericamente anche 3 volte inferiori.

La scelta dei 15 fotogrammi successivi mi ha garantito il fatto di aver esaminato i 15 tipi di frame di un GOP IBBPBBPBBPBBPBB (la lunghezza massima standard per i DVD) e quindi anche i frame in cui ho la massima possibilità di accumulo di errori (con DVD Repair ho verificato il tipo di frame in esame (I, P o B))

Seguono i risultati ottenuti paragonando le versioni IDCT MMX e non MMX, rispetto alla versione reference relativamente alla versione Flaskmpeg 0594 originale.

Per "errori 1/256" , come visto intendo gli errori in cui è errato di 1 il valore R, G o B. es (12,24,43)---> (12,25,43) ; analogamente per "errori 2/256" intendo gli errori in cui è errato di 2 il valore R, G o B. es (12,24,43)---> (12,26,43),..... Il 256 deriva dal numero dei possibili valori dei fattori RGB (intervallo 0-255).
Per ciascun frame ho valutato le differenze per i fattori R, G, B e ho fatto la somma. Osservando i risultati è apparso come in realtà gli errori si concentrano su i fattori RGB di singoli pixel; se errori (12,24,43)---> (12,25,43) sono rarissimi, al contrario sono frequenti 2 o 3 errori di tipo 1/256 concentrati sullo stesso pixel (12,24,43)---> (13,25,44) o (12,24,43)---> (13,25,43). In pratica se si compie un errore unitario per il rosso di un certo pixel, molto probabilmente ci sarà un analogo errore unitario per il verde o e il blu e in altri 3 pixel adiacenti.

Il motivo va ricercato nel formato colore YUV e nel sottocampionamento 4:2:0 dell'mpeg: per ogni frame 720*576 il decoder lavora indipendentemente su una immagine 720*576 in B/N (l'informazione di luminanza) e su 2 immagini 360*288 relative alla crominanza: Un singolo errore di tipo 1/256 sulla IDCT di un blocco 8*8 di crominanza può arrivare a creare sino a 12 errori di tipo 1/256 sui valori RGB di 4 pixel: infatti a seguito del campionamento colore 4:2:0 ciascun pixel di crominanza colora ben 4 pixel !!!.
Per valutare, con buona approssimazione i pixel errati, considerando tali accorpamenti ho utilizzato la formula "Stima pixel errati" = Totale errori/2,4; se il discorso degli accorpamenti degli errori sullo stesso pixel valesse sempre, cosa non vera, avrei dovuto utilizzare la formula =Totale errori/3.

Ecco i risultati ottenuti che commento in seguito. Osservo che la questione accumulo degli errori la ho analizzata tramite la versione 0594, ma la propagazione percentualmente cambia pochissimo in altre versioni.

Ecco tabellati i risultati degli errori della modalità MMX, quella che crea in assoluto il maggior numero ed entità di errori.

Ecco il "commento" ai risultati.
Ci sono due modi di valutare gli errori: numero di errori ed entità (ampiezza) degli errori.

Iniziamo subito col discorso quantità degli errori: prima di tutto il metodo non MMX, che è leggermente più lento produce all'incirca la metà degli errori rispetto al metodo MMX; la presenza di errori di tipo 4 e 5 è assolutamente trascurabile ( al massimo raggiunge lo 0,003 % dei pixel totali). Ricordo,come già detto, che in altri brevi test ho riscontrato errori anche 3 volte inferiori in numero: la artificiosità della computer grafica crea ovviamente sfumature e variazioni di colori più complesse delle immagini dei film.

La seconda cosa fondamentale da osservare è che le previsioni catastrofiche di chi ritiene che l'accumulo degli errori ne provoca un aumento preoccupante, si mostrano infondate (bastano comunque delle nozioni di statistica per intuirlo). Per i più attenti voglio osservare come i frame P contengono sempre meno errori rispetto ai vicini frame B, poichè non c'è l'incremento degli errori causato dagli Interpolated Block che nella decodifica immettono un potenziale accumulo di errore in più. Osservo inoltre come gli ultimi due B frame contengono meno errori rispetto ai precedenti, poichè calcolano la compensazione in parte dal frame I successivo che NON CONTIENE NESSUN ACCUMULO DI ERRORI. Pertanto il fatto che il massimo errore lo si trova nel frame B undicesimo è la prova di come i risultati dei test che ho eseguito sono logici e coerente con una trattazione puramente teorica.

Affrontiamo il discorso "entità (ampiezza) degli errori": è evidente come un errore di tipo 4/256 o 5/256 è teoricamente più facile da osservare rispetto ad uno di tipo 1. Dai risultati appare chiaro come il numero di tali errori è limitatissimo (siamo nell'ordine di pochissimi pixel per immagine), e non si supera mai la soglia degli errori di tipo 6 (al massimo un pixel per immagine!!).
Per quanto sperimentato con la comparazione delle immagini prodotte dalla decodifica IDCT reference, MMX o non MMX, tali errori sono al di sotto della soglia di visibilità: secondo alcuni miei test è possibile osservare ad occhio variazioni di colore solo per errori almeno di tipo 3,4, ma nelle condizioni di sotto: comparazione diretta di un gruppo di pixel sbagliati accanto al colore "corretto", come nell'esempio (da visualizzare con profondità colore a 24 o 32 bit ).

Nel momento in cui si ha un solo pixel errato, all'interno di una immagine che contiene altri pixel corretti o caratterizzati da un errore di tipo 1 o 2, accorgersi della differenza è impossibile.

A prova di ciò ecco un semplice esempio in cui ho riprodotto (all'interno dei 256 colori del gif) una immagine in cui ci sono errori in una percentuale analoga a quella vista negli esempi.

Nella tabella che segue trovate le due immagini, quella corretta ed errata, e gli errori in scala di grigio dei fattori R, G, B che indicano posizioni e entità degli errori (i puntini più o meno chiari). Le immagini degli errori sono state create sottraendo pixel per pixel i valori di RGB delle 2 immagini e modificando il contrasto per rendere visibili i puntini degli errori. Due immagini identiche provocherebbero 3 immagini di errori fattore R, G e B perfettamente uniformi senza alcun puntino.
Nonostante siano note le posizioni degli errori (i puntini), sfido chiunque ad accorgersi delle differenze, che non sono visibili ma esistono !!!!! (fondamentale la visualizzazione a 24 o 32 bit)

Non è un caso la scelta del gradiente azzurro , immagine semplice in cui un errore è più facilmente individuabile: in tutte le immagini ricche di diversi colori e dettagli minuti (le alte frequenze video), a causa dei limiti dell'occhio umano individuare gli errori è ancora più difficile. Se non si vedono errori su sfondi uniformi, sicuramente non si vedranno all'interno di immagini complesse.

Termino questa parentesi sugli errori causati dalle approssimazioni delle iDCT, con un banale test: la tabella di sotto contiene 40 immagini, alcune delle quali contengono i 143 errori appena visti; se avete la capacità visiva di individuare le immagini errate, potete avere la conferma posizionando il mouse sul riquadro corrispondente. Sono pronto a scommettere che non ci riuscirete!!!

Ovviamente non lasciatevi ingannare dalle scritte "low-Q", "bassa qualità" o altro: in flaskmpeg vanno intese in termini di accuratezza matematica, e non inficiano sulla qualità visibile della decodifica.

Tutte le analisi sulle differenze matematiche che seguono sono pertanto poco importanti ai fini pratici, ma interessanti per chi, anche solo per curiosità, vuole approfondire il discorso della implementazione IDCT; ancora una volta la superficialità nell'analisi dei risultati fa da padrone su Internet. Un esempio tra tutti la gigantesca polemica nata sull'efficacia della sezione Floating-point del neonato Pentium 4 che in breve cercherò di chiarire, che ha costretto la Intel a sfornare in pochissime ore una nuova versione di Flaskmpeg ottimizzata per Pentium 4 ; pochi hanno capito cosa è successo veramente, ma sui newsgroup di tutto il mondo si è sparsa la voce di usare la versione di Flaskmpeg della Intel, in assoluto la migliore e la più veloce . NIENTE DI PIU' FALSO !!!!!!!

Andando con ordine, vediamo quali sono le principali modifiche fatte alle implementazioni iDCT della versione originale 0594 di flaskmpeg.

1) Miha Peternels: http://www.angelfire.com/art/mpeg/flask.html il suo contributo è incorporato in tutte le versioni dette "miha": le sue incredibili ottimizzazioni sono state da poco incorporate in altri sw simili a FlaskMPEG ed in particolare nelle ultime versioni di Mpeg2avipx3 e DVD2AVI. L'ultima implementazione in ordine di tempo è il plug-in alla versione 06 di flaskmpeg Miha.idct.flask.

- Optimized MMX: analoga per qualità alla versione MMX standard presente in flaskmpeg originale; produce esattamente le stesse immagini. L'incremento di velocità nei suoi confronti è circa pari all'8%
- Miha x87 Fast iDCT: è una versione praticamente identica alla reference : introduce nella Idct in media un errore di tipo 1/256, cioè praticamente nullo, ogni 6 milioni di pixel; nell'immagine finale, considerando l'accumulo degli errori, secondo i miei test produce un solo errore ogni circa 400000 pixel. A prova delle sue caratteristiche nel test IEEE-1180 non introduce alcun errore esattamente come la modalità reference. Riguardo la velocità è solo il 5% più lenta e addirittura più veloce della versione MMX originale che al contrario ha un tasso di errore di circa il 4.8% (un pixel ogni 20 circa) INCREDIBILE!!!! Questa implementazione è presente nel SW DVD2AVI con il nome "64-bit Floating Point" e non a caso è la implementazione più veloce.

Purtroppo a causa dell'interfacciamento di tale Idct con il resto del SW, SOLO NELLA 0594 Miha si ottengono errori così rari; nella 06 preview con il plug-in Miha e nella PX3 s2v3 Miha al contrario sono inseriti altri errori anche se numericamente inferiori a qualsiasi altra implementazione. Stesso tasso di errori nel SW DVD2AVI con la IDCT di Miha 64 bit Floating-point.

La cosa è veramente strana nel momento in cui il test IEEE-1180 mostra errori nulli, pari al caso "reference".
- Miha x87 Reference iDCT: modalità matematicamente priva di errori ma lo stesso velocissima: in DVD2AVI è presente con il nome IEEE-1180 Reference.

2) Rolf : http://go.to/px3 il suo contributo è incorporato in tutte le versioni dette "PX3": tali ottimizzazioni comprendono anche altre sezioni relative alla decodifica degli mpeg. Ha collaborato direttamente con Alberto Vigatà per la realizzazione della versione 06. E' autore delle modifiche al velocissimo sw Mpeg2avi (fermo alla v0.16B35 del 11/10/99 ) che è diventato Mpeg2avipx3.

3) Intel : ha incorporato del codice ottimizzato per fare una versione compatibile con le SSE2.

Altro autore di modifiche è colui che si firma HRM che pur non modificando le opzioni Idct , si è concentrato nel migliorare l'audio di flaskmpeg: sono sue le versioni denominate h1 e h2.

Il creatore delle versioni Decss è invece colui (o coloro) che si firmano "The Daltons Group": il sito di riferimento è daltons_team .

Da segnalare inoltre la versione Flaskmpeg v.0594 DVB o che è una particolare versione compatibile con il formato DVB, utilizzato per le trasmissioni digitali via satellite.

Come già detto nella 06 preview le routine IDCT sono implementate come dei plug-in : considerando le velocità e il tipo di artefatti introdotti (vedi dopo) è probabile che parte delle modifiche PX3 sono presenti nella 06 ; presenti pure le IDCT della Intel compatibili con le SSE2 del P4 che grazie al riconoscimento automatico della CPU sono disponibili solo se presente tale CPU. Attualmente l'unico plug-in aggiuntivo disponibile è quello di Miha (il file Miha.idct.flask): grazie alle sue caratteristiche quelle fornite di serie sono diventate a tutti gli effetti inutili !!!!

In breve le caratteristiche salienti delle diverse versioni, analizzate più in dettaglio nel paragrafo conclusioni.
Flaskmpeg v.06 preview: (6 marzo 2001) Molte piccole novità, buona velocità (leggermente al di sotto comunque delle migliori modifiche alla 0594), modularità nelle IDCT implementate come plug-in (la versione migliore quella di Miha), nuova sezione audio e qualche naturale instabilità tipica di tutte le versioni Beta. Un ottimo punto di partenza per le prossime 061,062,063..... che non tarderanno ad essere rilasciate. Una analisi delle novità è presente nel capitolo La versione 06 preview.

Flaskmpeg v.0594 originale: penultima versione ufficiale di flaskmpeg di Alberto Vigatá; la più lenta ma probabilmente la più stabile.

Flaskmpeg v.0593 e v.0594 Decss: praticamente uguale alla originale ma con in più le capacità di Decss che funzionano automaticamente senza l'inserimento manuale della chiave di decriptazione.

Flaskmpeg v.0594 PX3: è la "famiglia" delle versioni di flask primatiste in velocità modificate con il codice di ROLF. La prima serie di modifiche, dopo le versioni provvisorie dette 001, 002, 003, 004a, 004b, 004c, 004d, ha "dato alla luce" la Flaskmpeg v.0594 PX3 004e (12 agosto 2000) molto veloce e stabile anche se non dotata di Decss.

Dopo questa versione ROLF ha indirizzato i suoi sforzi al miglioramento del sw mpeg2avi, sino ai primi giorni di dicembre in cui ha rilasciato una nuova serie di versioni di flaskmpeg. Simpaticamente Rolf ha "giustificato" la sua nuova versione dicendo "it appears that FlaskMpeg programming has become a popular sport and even Intel is participating: there's now a new release of the FlaskMpeg PX3 version" (sembra che la programmazione di FlaskMpeg sia diventata uno sport popolare a cui anche la Intel sta partecipando: ecco una nuova versione di FlaskMpeg PX3 version ).

Il risultato del nuovo lavoro di Rolf sono le così dette versioni PX3 second strike (PX3s2) che dopo le versioni non definitive denominate PX3 s2v1 e PX3 s2v2 hanno portato alla Flaskmpeg v.0594 PX3 s2v3 (10 dicembre 2000) disponibile in 3 versioni: con o senza il Decss e con le routine di Miha (Flaskmpeg v.0594 PX3 s2v3 Miha); quest'ultima è attualmente la versione più veloce.

Presente sulla rete una versione detta Vulture, che di fatto è una Flaskmpeg v.0594 PX3 s2v3 con un miglioramento nella modalità reference e ottimizzata per le CPU AMD.

Il problema di tutte le versioni PX3 s2v3 è che a causa di un Bug, non è possibile fare delle conversioni se non dall'inizio di un vob: se si prova a convertire partendo da un altro punto, diverso dall'inizio del filmato, il sw va in crash; un secondo bug fa si che ad ogni cambio di capitolo vengono introdotti alcuni frames con leggeri artefatti e una brevissima interruzione dell'audio. Se si converte un vob estratto da un sw di ripping su Hd corrispondente ad uno spezzone preso da un punto intermedio del video (ad esempio un capitolo diverso dal primo) si va spesso incontro a problemi di sincronismo audio video.

Pertanto se si desidera fare una conversione partendo da un punto intermedio diverso dall'inizio del video, e non si tollerano i problemi relativi ai cambio di capitolo, occorre ricorrere ad una versione diversa, come la PX3 004e che è leggermente più lenta ma non ha il problema appena visto presente nelle PX3 s2v3 o la 06 preview.

Flaskmpeg v.0594 versioni h: è la "famiglia" delle versioni di flask modificate da hrm: le principali modifiche riguardano l'audio ac3, per il quale è possibile incrementare il volume generale e il volume dei singoli canali. Come velocità non ci sono miglioramenti di rilievo rispetto alla versione originale. L'ultima versione disponibile è la Flaskmpeg v.0594 h2 PRE3 del 2 dicembre 2000 che è seguita alle versioni h1, h2 Pre1 e h2 Pre2.

Voglio citare due altre implementazioni Idct, leggermente più rapide che NON soddisfano le specifiche IEEE-1180: tali implementazioni non sono usate in flaskmpeg ma sono incorporate nel sw Mpeg2avipx3; sono la Chen-Wang Idct e la AAN Idct entrambe implementate sfruttando le istruzioni MMX ma a 16 bit invece che a 32.

E' probabile che tali IDCT possano essere disponibili tra breve come plug-in per la 06.

Da osservare come l'algoritmo MMX idct utilizzato nella versione 0594 originale di flaskmpeg è in realtà quello presente nella ultima versione di Mpeg2avi, la v0.16B35, che risale all'ormai "lontano" 11/10/99 .

Ecco delle tabelle riassuntive dei risultati dei test che commenterò nel proseguo dell'articolo. Nella prima tabella sono indicati risultati della sola decodifica Vob e caratteristiche (in breve) delle versioni esaminate. Segue una tabella con i risultati di tutti i test svolti. Conclude una tabella con la comparazione delle 3 versioni più significative (già vista in precedenza). I test DivX;-), XVCD, SVCD sono stati eseguiti solamente sulle versioni "più significative", per ovvi motivi di opportunità; per le altre versioni, gli esiti sono facilmente intuibili e ricavabili dagli altri dati forniti

I test sono stati fatti con un Pentium 2 400 Mhz (128 MB Ram HD IBM DTTA 14 Gb, Matrox Marvel g200) utilizzando un Vob PAL 720*576 25fps in formato 16:9 anamorfico ( 1.75:1 , privo cioè di bande nere) decriptato e copiato su HD: si è utilizzata la modalità di flaskmpeg Idct MMX , audio 44100 e ridimensionamento con filtraggio bilineare, eliminando la visualizzazione che rallenta leggermente le conversioni. Per escludere la presenza di bande nere orizzontali che velocizzano i test a seguito della relativa semplicità con cui vengono decodificati, in flask NON ho selezionato, "mantieni rapporto altezza, larghezza".

Riguardo le compressioni XVCD e SVCD ho utilizzato il sw tmpeg b12a collegato a flaskmpeg con Avisynth v0.3 di Ben Rudiak-Gouldcon, più rapido rispetto alla recente 1.0 Beta 36. In Tmpeg ho utilizzato l'opzione Motion Search Accuracy = normal, mentre con flaskmpeg il metodo Idct più veloce (MMX tranne nelle versioni Px3 in cui ho usato il metodo non MMX, leggermente più rapido).
Per il DivX;-) ho utilizzato il codec low motion versione 3.11alpha e audio non compresso. Per la sola decodifica dei Vob ho utilizzato il plugin avisynth 1.0 Beta 36 in modalità benchmark.Tutti i test sono stati eseguiti su 20 secondi di video (500 frame). I risultati indicano la media di 2 test successivi.

Nel grafico che segue ho sottolineato in rosa le versioni dotate di Decss; ho indicato in giallo le versioni per le quali è possibile fare delle conversioni unicamente dall'inizio del film e che presentano i problemi visti ( ad ogni cambio di capitolo vengono introdotti alcuni frames con leggeri artefatti e una brevissima interruzione dell'audio )

Ecco riproposta la tabella riassuntiva per le versioni più significative: per la px3 004e si è utilizzata la Idct non-MMX leggermente più veloce della versione MMX;

Voglio osservare come i risultati debbano essere interpretati nel contesto della metodologia con cui sono stati realizzati i test (spezzoni video di 20 secondi, con test ripetuti 2 o 3 volte): si devono considerare normali errori sui tempi rilevati dell'ordine del 2-3 %: in pratica ad esempio 2 versioni che producono delle velocità pari a 7 o a 7,1 fps devono essere considerate di fatto identiche.

Per avere dati molto più precisi con errori magari limitati allo 0,2- 0,3 % occorrerebbe fare test su 5-10 minuti di video, cosa assolutamente improponibile nella pratica per ovvi motivi di tempo.

Partiamo brevemente dall'analisi della iDCT reference (qualità di riferimento), da cui è nato quello che scherzosamente ho battezzato "il caso Pentium 4"

Tale versione, come già detto, produce una decodifica del video mpeg matematicamente corretta, assolutamente priva di errori, implementata come riferimento e capace di far vedere la bravura del programmatore nel realizzare le altre implementazioni molto più veloci.
Perchè tale opzione non va utilizzata? Semplicemente poichè, come detto, è la più lenta e le altre implementazioni Idct producono errori invisibili all'occhio umano e rarissimi (la migliore implementazione, la non MMX miha, secondo le mie statistiche e come confermato dall'autore, sbaglia in media UN PIXEL OGNI CENTOMILA sempre producendo un errore del tutto invisibile all'occhio umano (del tipo 1/256) !!!!! La sua velocità è al contrario elevata, superiore a molte implementazioni idct MMX che al contrario sbagliano in media un pixel ogni 20-25 )

La qualità di riferimento nella versione originale v.0594 è lentissima come appare dalla seguente tabella che visualizza i fotogrammi al secondo nella sola decodifica di un VOB 720*576 nelle 3 modalità di IDCT: la decodifica è 5 volte più lenta (1.4/7.0 = 0.2 = 20%= 1/5 ) rispetto alla implementazione MMX. Il test come gli altri è fatto su un Pentium 2 400 Mhz.

La qualità di riferimento presente nella versione originale v.0594, è la base dalla quale sono nate poi tutte le altre implementazioni iDCT: a prova della sua enorme semplicità, ecco il listato in C.

* Perform IEEE 1180 reference (64-bit floating point, separable 8x1 direct matrix multiply) Inverse Discrete Cosine Transform*/
void Initialize_Fast_IDCTref _ANSI_ARGS_((void));
void Reference_IDCT _ANSI_ARGS_((short *block));
static double c[8][8];

void Initialize_Reference_IDCT()
{ int freq, time;
   double scale;
   for (freq=0; freq < 8; freq++)
   {scale = (freq == 0) ? sqrt(0.125) : 0.5;
      for (time=0; time<8; time++)
      c[freq][time] = scale*cos((PI/8.0)*freq*(time + 0.5));}
}
void Reference_IDCT(block)
short *block;
{int i, j, k, v;
double partial_product;
double tmp[64];
for (i=0; i<8; i++)
     for (j=0; j<8; j++)
      { partial_product = 0.0;
         for (k=0; k<8; k++)
        partial_product+= c[k][j]*block[8*i+k];
        tmp[8*i+j] = partial_product;   }
for (j=0; j<8; j++)
for (i=0; i<8; i++)
{partial_product = 0.0;
    for (k=0; k<8; k++)
      partial_product+= c[k][i]*tmp[8*k+j];
      v = (int) floor(partial_product+0.5);
      block[8*i+j] = (v<-256) ? -256 : ((v>255) ? 255 : v);
   }}

Da queste circa 30 righe di codice, sono state create tutte le altre implementazioni, reference ottimizzate, MMX, non MMX,SSE2, 3DNow!. Per dare una idea del lavoro svolto, ad esempio la versione MMX passa dalle 30 a circa 1000 righe di codice molte delle quali in assembler. Basta dare una occhiata ai sorgenti dei Sw per rendersi conto della complessità delle operazioni di ottimizzazione.

Chi ha compiuto una specie di miracolo, grazie alla ottimizzazione in assembler del codice reference visto, è stato Miha Peternels, che ha realizzato una versione reference che arriva a superare, e anche di molto, la versione più rapida presente nella versione originale di flasK, la MMX. Ecco i risultati del test di sola decodifica di un Vob 720*576 nelle versioni in cui è stato inglobato il codice di Miha;

I risultati si commentano da sè: le qualità di riferimento Miha, che produce immagini matematicamente corrette e quindi identiche alla versione originale è sino a 5-6 volte più rapida. Non a caso tale implementazione della IDCT reference è stata immediatamente incorporata in DVD2avi e Mpeg2aviPX3.

Come già detto con buona approssimazione è possibile considerare le versioni non MMX di miha (in rosso) a tutti gli effetti delle reference essendo il tasso di errori praticamente nullo (1 errore di tipo 1/256 ogni 400000 pixel).

Stesso discorso per Idct AMD x87 (3.5 fps) presente nella 06 reference (2 fps) che pur non avvicinandosi alle prestazioni di miha sbaglia pochissimo, circa 1 pixel diverso su mille.

Riguardo una analisi più dettagliata degli errori vi rimando al capitolo relativo.

L'implementazione Idct reference è stata la centro di una polemica che verteva sulla scarsa efficacia della sezione Floating-point del neonato Pentium 4 .

Il noto sito http://www.tomshardware.com , Tom's Hardware guide, famoso per l'obbiettività dei suoi test e la serietà degli argomenti trattati, ha realizzato un test che sfruttava la versione ufficiale di Flaskmpeg (v.0594) per la decodifica di un vob e successiva compressione in DivX;-) su computer ciascuno dotato di una CPU diversa. Come ovvio è stata utilizzata l'opzione IDCT MMX, la più veloce , e tra le altre cose quella consigliata dallo stesso autore di flaskmpeg .

I risultati sono stati chiarissimi: il Pentium 4 è più veloce rispetto a tutti gli altri concorrenti grazie sopratutto alla elevata velocità di clock e ovviamente al solido lavoro fatto dagli ingegneri della Intel.
Ecco la tabella riassuntiva: le velocità sono espresse in fotogrammi al secondo. Mi permetto di osservare che con un P4 a 2 Ghz (che penso nel 2002 dovrebbe essere alla portata di tutte le tasche), la conversione in DivX;-) sarà possibile in tempo reale !!! (sul sito non si fa accenno alla risoluzione utilizzata, ma facendo dei brevi calcoli sulle velocità, dovrebbe essere un qualcosa tipo 480*288 o leggermente superiore)

I chiari segni di potenza di calcolo del Pentium 4 che si evincono da tali test, sono stati messi in dubbio da un sapientone di turno, un certo Toby Hudon, che scrivendo una affermazione assolutamente discutibile ha in pratica detto che l'uso dell'opzione IDCT MMX di FlaskMpeg produce nella successiva compressione in DivX;-) un incremento degli artefatti a causa delle approssimazioni fatte. Che sia una affermazione discutibile (per me una grossa fesseria) lo si deduce dai test visivi di cui ho appena parlato: sinceramente prima di dire "Using the IEEE decode eliminates most of these artifacts " (l'uso della decodifica IEEE elimina gran parte degli artefatti, riferendosi a quelli presenti del DivX;-)), Toby Hudon avrebbe dovuto fare almeno qualche test. Ecco comunque uno stralcio della e-mail inviata da Toby Hudon:

The default is MMX. However, this tends to produce a lot of artifacts in the final MPEG-4 video because all the pixel values of the decoded frames are approximations. Thus when a second DCT transform is applied to convert it to MPEG-4 it tends to approximate again and produce really horrible artifacts in some cases.Using the IEEE decode eliminates most of these artifacts and produces an output that rivals most DVDs when set to about 20% of the original bit rate.

Il risultato di tale e-mail è stato immediato: nel sito Tom's Hardware guide è stato rifatto il test con l'utilizzo dell'opzione IEEE reference, che utilizza la unità floating point della CPU, e che ha messo in luce dei risultati disastrosi per il neonato Pentium 4 che addirittura è risultato più lento di un Pentium 3 a frequenza 1Ghz (rispetto ai 1.5 Ghz overcloccati a 1.73 Ghz, del fratellino maggiore P4)

Un risultato del genere ha fatto tremare la Intel, che in poche ore, sicuramente facendo lavorare senza alcuna pausa i propri dipendenti, ha sfornato una nuova versione di flaskmpeg targata Intel, che ha rimesso le cose a posto (vediamo tra un pò, come).

Sembrava ripetersi la maledizione dell' Intel Pentium che pochi giorni dopo la sua uscita ( parliamo di dicembre 1994 e di CPU a 60 e 90 Mhz) si è scoperto sbagliava i conti in virgola mobile; il più clamoroso difetto nella storia delle CPU!!!!

Se la velocità delle operazioni in virgola mobile del P4 fosse stata sempre insufficiente come nel caso dai nuovi test, la Intel avrebbe clamorosamente fallito nel progetto della sua nuova CPU: ricordo che stiamo parlando di colossi dell'economia mondiale e fatturati da brivido, su scala mondiale; una bocciatura così clamorosa su di un sito così importante avrebbe potuto rapidamente affossare l'immagine della nuova CPU con danni economici disastrosi per l'Intel.

Questa volta la questione si è rivelata diversa rispetto al caso del 1994: il problema risiedeva nel compilatore utilizzato da Vigatà, l'autore di Flaskmpeg, che produceva un codice assolutamente non ottimizzato nel caso di calcoli in virgola mobile. Le nuove CPU, tra cui il P4, sono sensibilissime alla qualità del codice prodotto: un eseguibile non ottimizzato è capace di mandare in stallo la CPU, rallentando la velocità anche di 4-5 volte. Ciò è successo con l'opzione "qualità di riferimento" di Flaskmpeg, ma si verifica in tutte le operazione in virgola mobile fatte con sw datati.

Non a caso il P4 nel test ,sempre sul sito Tom's Hardware guide, aveva evidenziato prestazioni insufficienti del P4 con 3D Studio MAX2 (sw vecchiotto!!!): anche in questo caso il P4 a 1.5Ghz era risultato più lento di un P3 a 1 Ghz.

Riguardo tali problemi, sinceramente, non credo si possa fare una colpa alla Intel, che tra l'altro ha sempre affermato dell'importanza della ottimizzazione del codice per le nuove CPU; chi acquista un P4, non lo fa per utilizzare una versione di un Sw ormai superata . Tra l'altro le ottimizzazioni da fare per i programmatori sono assolutamente automatiche: basta ricompilare il sw con un compilatore più recente, e senza modificare una riga di codice le prestazioni torneranno ad essere ottimizzate per qualsiasi CPU.

Ritornando al "caso Flaskmpeg e P4 ", la Intel si è vista costretta in poche ore a correre ai ripari, fornendo una versione, denominata appunto Flaskmpeg Intel , che incrementava le prestazioni riportando il P4 al primo posto in termini di velocità.

Prima di continuare l'analisi del "caso Pentium 4", ai più curiosi consiglio la lettura di una E-mail molto equilibrata , inviata da Jim Quinlan, della Multimedia & Intel(r) Xscale(tm), Intel Corporation, che nonostante la gravità della situazione chiarisce in maniera molto pacata la sua opinione. Ecco il link.

In breve Jim Quinlan, in coerenza con quanto da me detto, si mostra scettico sulla presunta migliore qualità della IDCT reference, rispetto alla veloce MMX; l'unica maniera per dimostrare una cosa del genere sarebbe quella di fare una serie di "test scientifici" con un gruppo di persone messe in condizione di valutare più DivX;-) visualizzati in parallelo su due monitor affiancati, ciascuno compresso con entrambi i modi. Inoltre Quinlan ricorda giustamente come gli errori della decodifica di flaskmpeg sono assolutamente trascurabili rispetto a tutta la catena di operazioni che si hanno nella conversione Vob---> DivX;-): il vero responsabile della qualità finale è il codec Mpeg4 (DivX;-) nel caso in esame) con la sua forte compressione video, codec che a causa delle sue routine potrebbe addirittura non essere in grado di apprezzare la miglior precisione della decodifica reference di Flaskmpeg..

La cosa curiosa è che riguardo l'opzione incriminata per la sua lentezza (IDCT qualità di riferimento, che ricordo utilizza i numeri in floating point), LA INTEL NON HA MODIFICATO UNA SOLA RIGA DI CODICE: ha semplicemente ricompilato i sorgenti con un compilatore recente ed ottimizzato, l'Intel compiler 5.1 B18; idem per le altre opzioni standard (MMX e non MMX iDCT).

Tale banale ricompilazione nel caso di "qualità di riferimento" produce per tutte le altre CPU diverse dal P4 un incremento di un fattore 2 ( raddoppio di prestazioni) , mentre produce un incremento di prestazioni sul P4 pari ad un fattore 3.6 (da 3.83 a 14.03 fps). Riporto a destra i risultati della versione non ottimizzata.

Con il mio Pentium2 400 sempre utilizzando la versione Intel, ho ottenuto gli stessi miglioramenti rispetto alla 0594 originale di un fattore 2 per la "Qualità di riferimento " e piccoli incrementi nelle altre, in coerenza con il fatto che l'unica differenza della versione Intel rispetto alla originale sta nell'utilizzo di un compilatore ottimizzato. Al contrario sono prestazioni NETTAMENTE INFERIORI rispetto ad altre implementazioni reference molto più ottimizzate come visibile nella tabella (i test che seguono sono sempre riferiti alla sola decodifica di un vob 720*576).

Penso di aver chiarito in maniera inequivocabile come non è minimamente conveniente utilizzare la versione Intel poichè non è più veloce delle altre, al contrario di quanto erroneamente detto su numerosi newsgroup e siti dedicati al digital video. Ricordo ancora una volta che stiamo parlando della qualità di riferimento che per quanto detto non va utilizzata; nella pratica utilizzando la MMX iDCT le versioni Miha e Px3 sono notevolmente più veloci della versione Intel.

I programmatori della Intel, come detto, hanno inserito delle ulteriori implementazioni IDCT ottimizzate e funzionanti solo per i P4; eccole presentate dalla Intel stessa

IEEE1180 SSE2/Single Precision -- this is the straight IEEE1180 reference algorithm using single precision FP SSE + some SSE2 icing. Again, the point is that "SSE2 port is easy".

IEEE1180 SSE2/DP -- the same straight IEEE1180 algorithm, now with double precision FP SSE2. Same point "SSE2 port is easy".

============================
1: FastIDCT MMX 1:28
2: FastIDCT Int 1:39
3: AP-945 FastIDCT SSE2 1:24
4: IEEE1180 SSE2/SP 1:35
5: IEEE1180 SSE2/DP 1:45
6: IEEE1180 x87i 2:34
============================

The new version was compiled with different compiler options. So only by different options No.6 improved significantly. We measured 10:36 with the unchanged Flask v0.594.

Tom, please keep in mind that this program was edited in only half a day. So the engineer didn't incorporate a CPU identification. If you select one of the SSE2 optimized paths running Flask on a non-SSE2-enabled machine, you might run into issues.

Ecco la tabella che riassume le velocità in fotogrammi al secondo (fps) ottenibili utilizzando la versione ottimizzata della Intel nel caso di compressione da DVD a DivX;-) (poichè non è specificato sul sito di Tom's Hardware viste le velocità presumo ci si riferisca ad una conversione con una risoluzione circa pari a 480*288): è evidente come per chi possiede un P4 se si utilizza la versione Intel è consigliabile usare la IDCT SSE2, la più veloce. Come ovvio le modalità SSE2 funzionano solo sul P4.

Da notare come se utilizzassi la modalità MMX iDCT con la velocissima versione v.0594 PX3 s2v3 Miha , in base ad alcune mie stime, otterrei un incremento di velocità pari circa a 1.42 (ovviamente è un dato estrapolato dai risultati del mio P2, visto che non possiedo nessuna delle CPU in esame). Ecco le velocità "presunte" sempre espresse in fotogrammi al secondo.

Un DivX;-) 480*288 convertito a 31 fotogrammi al secondo, significa fare una conversione più rapida del tempo reale (25/31 = 0,8 ) : 60 minuti di film convertiti in 48 minuti.... in attesa di simili meraviglie a prezzi un pò più accessibili non ci resta che aspettare...e sognare alle nuove CPU che tra un pò supereranno anche la soglia dei 2 Ghz !!!!.

Osservo che tali velocità anche per chi possiede un P4, rendono inutile la versione della Intel che per tali CPU riesce a raggiungere solamente 22,85 fps (la modalità Idct SSE più veloce) rispetto ai 31 fps appena visti.

La mia conclusione riguardo la versione Flaskmpeg Intel è abbastanza ovvia: NON USATELA PERCHE' IN NESSUN CASO E' PIU' VELOCE o MIGLIORE DI ALTRE VERSIONI.

Un breve accenno alle modalità ottimizzate per le CPU AMD dotate di set 3D Now! (Athlon, Duron,..): non avendo possibilità di fare dei test mi riferisco ai dati attenuti da Edwin van Eggelen http://www.videotools.net/ autore delle nuove versioni di Avisynth, in cui è evidente come la velocità della Idct MMX rimane imbattuta. Il test realizzato con un AMD Duron 800 su sistema operativo Windows 98SE, è riferito alla SOLA DECODIFICA del vob, più ridimensionamento. Il test che riporto è relativo alla versione più veloce ottimizzata per CPU AMD. Osservo come sono mostrati anche i ridimensionamenti "Bicubic" che portano ad un ulteriore incremento dei tempi di decompressione. La tabella indica i FPS (fotogrammi al secondo) .

In base ai miei test, la versione 0594 PX3 s2v3 Miha rimane comunque la più veloce, sempre nella modalità MMX anche per le CPU AMD.

Per quanto visto le versioni che migliorano la v.0594 originale sono nettamente più veloci: ma tale incremento di velocità aumenta il numero e la entità (ampiezza) degli errori, ovvero dei pixel errati rispetto alla decodifica prodotta della modalità reference?

In base alle osservazioni e ai test compiuti comparando immagini prodotte con le modalità MMX e non MMX, con quelle ottenute dalle rispettive modalità reference , ho osservato come:

- Gli errori introdotti dalle IDCT non reference della versione 0594 originale (e 0593 decss, h2 PRE3, 0594 miha...) hanno per posizione e intensità una distribuzione più o meno casuale....una specie di cielo stellato di una notte senza luna!!!!!
- Le IDCT non reference delle versioni PX3 (004e, s2v3, s2v3 Decss, Vulture, s2v3 Miha ) agli errori tipici introdotti delle IDCT della 0594 aggiungono altri errori. Numericamente l'incremento rispetto agli errori della 0594 è pari a circa al 30% ; come tipologia, tali errori si manifestano come blocchetti 8*8 o 16*16 pixel spesso completamente pieni di errori di tipo 1/256 o 2/256, probabilmente a seguito di approssimazioni sui primi valori dei coefficienti della IDCT (quelli relativi al valor medio e alle "basse frequenze video"). L'incremento di errori non porta comunque variazioni visibili ad occhio nudo dell'immagine , come più volte affermato: tra l'altro essendo tutti errori di tipo 1 o 2/256 sono assolutamente invisibili.
- la 06 preview (beta) si comporta sia come quantità (incremento del 30%), sia come tipologia (blocchetti 8*8 e 16*16) in maniera analoga alle versioni Px3; in più ho riscontrato alcuni errori di tipo 6 o 7/256 (al massimo una decina per immagine) che vista l'ampiezza non trascurabile mi hanno indotto a pensare nella possibilità di effetti indesiderati visibili. In realtà analizzando (sempre con Photoshop) dove tali errori sono collocati, ho verificato che sono relativi a pixel aventi colore molto vicino al nero (vedi le fasce nere che spesso si trovano ai bordi dell'immagine): riconoscere per pixel praticamente neri delle differenze di tipo 6 o 7/256 è ASSOLUTAMENTE impossibile essendo il nero una zona in cui il nostro occhio è poco sensibile. E' comunque da vedere se tale problema è in realtà un bug della versione 06 beta o una caratteristica dell'algoritmo utilizzato.
- La IDCT non MMX Miha mostra le sue caratteristiche (un errore circa ogni 400000 pixel) solo nella 0594 Miha; nelle altre in cui è diponibile (06 preview-Miha, 0594 px3 s2v3 Miha ) introduce degli errori simili alle altre Idct presenti nelle versioni px3, numericamente inferiori di un fattore 2-3

Vediamo degli esempi di errori tramite rappresentazione grafica; seguiranno poi i riscontri numerici. -

Ricordo come le immagini degli errori nei piani R,G,B (vedi gli esempi qui sotto) sono calcolate come differenza dei rispettivi fattori R, G B tra l'immagine decodificata con l'algoritmo IDCT scelto (MMX o non MMX) e quella prodotta dalla modalità IDCT reference. I puntini bianchi indicano le posizioni e l'entità degli errori. Le zone con colore scuro uniforme sono quelle in cui non ci sono errori.

La 06 preview produce degli errori molto simili alle versioni PX3: mostro solo un ingrandimento che evidenzia gli errori concentrati in blocchi 16*16

Nell'eseguire i test ho constatato come , diversamente da quanto è lecito aspettarsi, decodificando la stessa immagine, con le modalità IDCT reference di versioni di flaskmpeg diverse, si ottengono risultati diversi.

Dal punto di vista strettamente matematico ogni versione di flaskmpeg appartenente ad una diversa "famiglia" (vedremo poi quali), produce delle immagini in modalità reference diverse ; le differenze ovviamente aumentano nel momento in cui utilizziamo IDCT approssimate (MMX , non MMX,...) che introducono ulteriori errori di fatto invisibili.

In pratica ho identificato 3 gruppi ("famiglie") di versioni, ciascuno dei quali produce immagini , in modalità reference, diverse. La presenza dell'intruso (DVD2AVI è spiegata dopo)

Di quanto è la differenza tra immagini prodotte dalle modalità reference di "famiglie" diverse?. Nel caso di un I frame (quello che ha il minor numero di errori a seguito della mancanza degli accumuli di errore) ho rilevato le seguenti differenze.

Il confronto visivo delle 2 diverse immagini prodotte dalla modalità reference delle versioni Flaskmpeg PX3 rispetto alle altre 0594, ancora una volta non mostra differenze visibili, ma la differenza matematica delle immagini ( si arriva ad errori di tipo 9/256) è abbastanza marcata; siamo al limite delle differenze visibili, che pur presenti sono semplicemente nascoste.
Voglio osservare come la presenza di un errore come questo

mostra ancora una volta la struttura a macroblocchi 16*16 dell'mpeg decodificata per il blocco rappresentato in maniera leggermente diversa dalle due famiglie..

Comparando questi risultati con quelli degli errori causati dalla approssimazione delle IDCT rispetto al metodo reference, è evidente come la entità di errori dovuta alla diversa decodifica delle versioni PX3 è parecchio maggiore sia come numero di errori sia come entità (ampiezza) rispetto agli errori creati dalle Idct approssimate; ci sono un numero non trascurabile di errori di tipo 6 sino ad arrivare ad errori di tipo 9!!!.

- Prima "sorpresa" : paragonando l'immagine prodotta dalla modalità reference della 06 preview con le altre 2 famiglie di versioni , ho trovato al contrario delle differenze ENORMI; ci sono situazioni in cui si arriva tranquillamente a 70% dei pixel diversi con la presenza di errori comunque normalmente inferiori a 10/256; seguono errori numericamente ridotti ma estesi sino a 20-25 /256 ; sono in certi casi riuscito a trovare alcuni pixel con un errore di tipo 53/256 !!!!

Visualizzando gli errori si nota come la "costellazione più o meno casuale" degli altri casi e la presenza di blocchetti 16*16 è sostituita da una serie di errori che ricalca l'immagine originaria: ecco un esempio in cui appare inequivocabile il volto di Woody, simpatico protagonista di Toy Story 2. Altre volte sono visibili delle linee orizzontali come in figura.

Comparando " a vista " le immagini (alternando cioè le 2 immagini "reference"con ACDSee32) le differenze sono quasi sempre visibili anche se poco evidenti; si può notare una leggera tendenza della 06 a produrre immagini più chiare (non succede sempre) e qualche strana leggera variazione cromatica. Siamo comunque sempre lontani dagli artefatti introdotti da sw quali Power DVD le cui approssimazioni sui colori sono visibili in maniera inequivocabile.

A questo punto il problema si sposta: chi sbaglia , la 06 preview o tutte le altre ??

Per cercare di chiarirmi le idee ho analizzato le decodifiche delle versioni reference di altri sw quali DVD2AVI, ed ecco la seconda sorpresa: la nuova 06 produce una decodifica referece molto simile a DVD2AVI in modalità YUV--->RGB, PC scale: di fatto le uniche differenze sono sui pixel praticamente neri (assolutamente invisibili ad occhio) e sono presenti alcuni blocchetti 16*16 ( alla PX3!!) diversi di entità assolutamente trascurabile (1 o 2/256).
E' evidente quindi come parte del codice del velocissimo DVD2AVI è stato incorporato nella nuova 06.

Concludendo posso dire senza ombra di dubbio come ciascuna famiglia di sw (le versioni PX3 di flaskmpeg, le altre versioni di flaskmpeg 0594 e la 06 con DVD2AVI) decodifica i file Mpeg e VOB in maniera leggermente diversa: mi riferisco alle decodifiche con la modalità IDCT reference e di conseguenza anche alle altre versioni più rapide.

L'entità di queste differenze, pur rimanendo molto limitata, è maggiore rispetto alle differenze, non rilevabili a vista, presenti tra le versioni MMX, non MMX e reference di flaskmpeg.

Quali delle 3 famiglie produce in realtà l'immagine corretta, non mi è dato saperlo, anche se probabilmente la famiglia 3 (06 preview e DVD2avi ) essendo più recente se è stato fatto un buon lavoro finalizzato alla qualità oltre che alla velocità , potrebbe essere quella corretta.

Voglio osservare , nell'ottica di quanto visto sulle diverse implementazioni della decodifica mpeg reference nelle 3 famiglie, quanto sia stata sterile la polemica relativa alla "indiscutibile superiorità" della Idct reference rispetto alla iDCT MMX, che ha sollevato il polverone sul P4; molto probabilmente, se la 06 decodifica correttamente e la 0594 no, si è fatta "battaglia" su decompressioni tutte sempre molto "approssimate" !!!

Concludo analizzando numericamente le differenze matematiche tra le immagini prodotte nelle modalità IDCT MMX, non MMX e reference delle diverse versioni: per comodità chiamo ref1 le immagini prodotte dalla modalita reference delle versioni 0594 originale, 0593 decss, h2 PRE3, miha, ref2 quelle prodotte dalle versioni PX3: 004e, s2v3, s2v3 Decss, Vulture, s2v3 Miha, ref3 quelle prodotte dalla 06 preview

Per ogni versione indico le differenze, e quindi gli errori, tra la IDCT in esame e la corrispondente modalità reference: i valori che trovate sono relativi ad una singola immagine 720* 576 (frame I) e ovviamente sono dei risultati assolutamente indicativi, ma abbastanza chiari nel momento in cui in questo test è stato pensato per valutare le differenze tra le diverse IDCT nei confronti della stessa immagine per evidenziare la propensione a generare errori.

Una analisi più accurata ovviamente richiederebbe lo studio degli errori di più frame, ma non si deve dimenticare come per ogni immagine sono calcolate 9720 IDCT che sono già un discreto campione.(1620*6=9720 dove 1620 è il numero di macroblocchi di un frame 720*576 e 6 il numero di IDCT per macroblocco, 4 per la luminanza e 2 per la crominanza) Molte versioni producono immagini identiche nelle modalità in cui il programmatore non ha modificato nulla (vedi le versioni Intel che hanno semplicemente utilizzato un compilatore più aggiornato): ho indicato nella colonna "note" i casi in cui ciò avviene e ho semplicemente ricopiato i risultati che sono in un colore più scuro.

Ecco gli istogrammi dei risultati: ho incluso dei grafici senza gli errori di tipo 1 o 2 , errori che sono assolutamente invisibili anche nelle condizioni viste del " confronto diretto".

Appare evidente come le versioni PX3, in parallelo alla maggiore velocità, inseriscono un numero maggiore di errori nei confronti della versione originale, nonostante tale incremento è numericamente contenuto e presente solo sugli errori di tipo 1,2,3/256 che sono quelli che meno preoccupano poichè al di sotto della capacità visiva: per quanto visto tale incremento è causato dai famosi blocchetti 16*16 di errori

che si aggiungono in tutte le versioni PX3.
Ancora una volta ricordo come in tutti i casi gli errori misurati, su immagini reali, sono invisibili all'occhio anche nel caso di un confronto diretto con l'immagine corretta ,e pertanto non inficiano la qualità delle conversioni.

Anche qui i miei complimenti alla qualità elevatissima della implementazione non MMX di Miha nella 0594 Miha che produce errori numericamente ben al di sotto di tutti gli altri casi, tanto da non essere visibili in nessuno dei grafici.

Osservo inoltre come le versioni PX3 nella modalità non MMX non solo sono leggermente più veloci delle corrispondenti modalità MMX, ma in più producono meno errori: da preferire senza riserve.
Concludo la lunga "disquisizione" sugli errori , ricordando come nella decodifica mpeg, flaskmpeg, come tutti gli altri sw analoghi, lavora in modalità YUV e che il sottocampionamento dei colori (il 4:2:0 del PAL) fa si che il decoder lavori indipendentemente su una immagine 720*576 in B/N (l'informazione di luminanza) e su 2 immagini 360*288 relative alla crominanza. Dopo la ricostruzione di queste 3 immagini viene calcolato il bitmap 720*576 a colori. Un singolo errore di tipo 1/256 sulla IDCT di un blocco 8*8 di crominanza può arrivare a creare sino a 12 errori di tipo 1/256 sui valori RGB di 4 pixel: infatti a seguito del campionamento colore 4:2:0 ciascun pixel di crominanza colora ben 4 pixel.

Per questo motivo gli errori che ho trovato nei miei test sono numericamente superiori a quelli descritti nella pagina web di Miha, che tra l'altro parla di un numero di errori maggiori nelle modalità non MMX rispetto a quella MMX, in coerenza con il test IEEE 1180 presente nella 06 preview, e in opposizione a quanto ho sperimentato.
Il motivo sta nel fatto che i miei test indicano gli errori del risultato finale della decodifica mpeg, mentre Miha riporta quelli presenti nella sola IDCT: dopo la IDCT il sw deve eseguire la compensazione del moto e fare la conversione YUV-->RGB , operazioni che creano altri errori.

Ecco in breve i risultati dei test di Miha Peternels, che ovviamente parla di MY iDCT riferendosi alla versione PX3 s2v3 Miha.

FlaskMPEG 0.594 / PX3
- compiled with Intel C++ 4.5, Pentium II optimizations
- video: Divx low-motion codec, default settings
- audio: direct stream copy
- source mpeg: MPEG1, full resolution PAL, 25 fps, 57 seconds (created from DV source)
- target mpeg: MPEG4, 354*288, high-quality downsampling
- Platform: Celeron 450A, 128M, Win98

In alcune delle versioni viste, ci sono al di là di un incremento nella velocità della decodifica e alla presenza di funzioni di tipo Decss, altre caratteristiche non presenti nella versione 0594 originale.

Una di queste è la capacità di memorizzare i parametri presenti in "opzioni globale progetto, settaggio film " ovvero di tutti i parametri relativi a dimensione del video, tipo di decodifica, cropping, tipo di ridimensionamento,.......): è strano ma la versione 0594 originale di flaskMpeg non prevede tale comoda possibilità. Osservo come non sono memorizzati i parametri relativi ai plugin di compressione utilizzati, che di volta in volta dovranno essere settati secondo le proprie esigenze. Per la memorizzare basta selezionare file/Load/Save profile.

Nella 06 Preview è stata implementata la possibilità di memorizzare i profili in opzioni/opzioni globali progetto/ profile meneger: per memorizzare i parametri basta cliccare su save current e indicare il nome del profilo. Tutti i profili sono memorizzati automaticamente nella sottodirectory "profiles" e sono richiamabili anche tramite il relativo menù.

Nella tabella riassuntiva trovate indicate le versioni dotate di tale caratteristica sotto la dicitura "load/save profile"

Una seconda modifica apportata al flaskMpeg originale , è quella relativa alla decodifica dell'audio ac3: uno dei problemi del decoder ac3 di flaskmpeg 0594 è il livello relativamente basso dell'audio prodotto, ed in particolare del canale centrale adibito in massima parte ai dialoghi.

Il problema si aggravia nel momento in cui , nelle conversioni di formato, si utilizzano i codec audio mpeg layer 2 (per le conversioni in XVCD, SVCD), mp3 o WMA (per le conversioni in DiVX;-)); tali formati sono pensati sopratutto per le conversioni di musica di qualità CD, notorialmente caratterizzata da livelli audio mediamente alti.

Nella decodifica audio multicanale dei film, la dinamica è elevatissima a causa della presenza di 6 canali audio distinti (Ac3 5.1) che a secondo del tipo di scene possono intervenire tutti insieme o singolarmente come nel caso di soli dialoghi presenti sul canale centrale. Tali canali , mixati in stereo da flaskmpeg, producono a secondo dei momenti livelli bassissimi ed altri al limite della dinamica massima disponibile. Inoltre sono numerosi i casi dei film in cui per evitare il problema delle distorsioni, l'audio AC3 è prudentemente lasciato su livelli medio bassi.

Flaskmpeg 0594, quando decodifica l'audio ac3, lo fa senza nella maniera più prudente, eliminando il rischio di distorsioni (clipping): il risultato è spesso un livello globale basso che dopo la conversione in mpeg layer2, mp3 o WMA, provoca audio rumoroso e "scricchiolante" (è il termine che caratterizza quel fastidioso rumore dovuto alla compressione di audio di basso livello). Spesso i dialoghi presenti sul centrale coperti dagli altri canali e pertanto diventa difficoltoso l'ascolto.

La prima è quella di utilizzare la nuova 06 preview, che (vedi dopo) permette numerose regolazioni riguardo l'audio: spero a breve una versione un pò più stabile, priva di bug e magari leggermente più veloce.

Altra possibilità è quella di eliminare la decompressione e relativa ricompressione in stereo dell'audio e mantenere l'audio ac3: ciò è possibile facendo dei DivX;-) con audio ac3 o MiniDVD: il limite di tale soluzione sta nell'incremento della dimensione dei file a causa della minore compressione dell'ac3.
La seconda possibilità è quella di convertire audio Dolby Surround 2.0 (se disponibile) invece che audio ac3: in pratica se nel DVD sono contemporaneamente presenti audio ac3 5.1 e audio stereo codificato in Dolby Sourround, è preferibile utilizzare quest'ultimo, normalmente ottimizzato nei livelli globali; peccato che i DVD che contengono contemporaneamente audio stereo e 5.1 sono pochissimi.

Uscendo dai settaggi occorre poi verificare che tale elaborazione sia selezionata (X).
Riguardo il fattore di moltiplicazione per i test che ho fatto con 180-200% non si corre il rischio di distorsioni: lo si può appurare facendo il preview (play all'nterno di audio preprocessing ) o ad esempio esportando il file Wav in Tmpeg (non si perde il tempo della decodifica video ) tramite File- Save as- wavfile e visualizzando la forma d'onda in un editor audio.

Ricordo che se si ascolta l'audio all'interno di Tmpeg, per evitare la perdita di sincronismo audio-video nella conversione occorre inizializzare nuovamente la catena Flaskmpeg--->avisynth--->Tmpeg cliccando su Stop serving e in seguito per iniziare la conversione "inizia la conversione" in Flask , e "Start" in Tmpeg.

L'ultimo metodo possibile, utile per le conversioni in DivX;-) fatte direttamente all'interno di flaskmpeg , è quello di utilizzare la versione 0594 h2 PRE3 che pur avendo la stessa (relativamente lenta) velocità di decodifica video della 0594 originale, permette delle modifiche sui parameti dell'audio tramite l'opzione Audio player.

E possibile modificare i volumi dei canali posteriori (Rear) , o centrale (Center), tramite i relativi potenziometri verticali , dove 0 rappresenta il volume originale (quello non amplificato): è possibile disabilitare tali canali deselezionando il corrispondente

(utile ad esempio per eliminare i dialoghi a lasciare solo la musica).
I potenziometri global 1 e 2 incrementano il volume generale tramite una modifica "intelligente" dei volumi: il mio consiglio è di lasciare a 0 tali potenziometri e in tutti i casi non utilizzare mai valori maggiori di 50 pena possibili distorsioni.

Il volume generale è quello settato dal potenziometro orizzontale.

il cui valore è indicato da "Current factor"

Per ottenere una decodifica avente volumi identici alla versione originale di flaskmpeg e quindi certamente senza distorsioni si deve settare il volume generale a 32000 e a zero tutti gli altri (potenziometri verticali). Osservo come il volume generale con cui avverrà la decodifica è SEMPRE quello indicato da Current factor e NON occorre cliccare su APPLY per renderlo aittivo ( Apply serve a impostare il volume generale al valore "Suggest", come vedremo dopo)

Il problema dell'aumento dei volumi è quello delle possibili distorsioni dovute ad amplificazioni eccessive: per raddoppiare il volume basta posizionare il volume generale al valore 64000 (32000*2), per triplicarlo al valore 96000; andare oltre non conviene: sono quasi certe le distorsioni.

Il mio suggerimento è di utilizzare valore compresi tra 40000 e 60000 (al massimo 80000), mentre per incrementare leggermente il volume dei dialoghi consiglio un valore di center = 100. Ovviamente non posso garantire sui rischi di distorsioni che comunque con questi valori penso siano improbabili.

E' possibile ascoltare la decodifica audio ottenuta tramite play, e spostandosi con il potenziometro orizzontale in alto per scegliere la posizione: i valori Min e Max indicheranno il massimo volume ottenuto che per non dare distorsioni deve mantenersi all'interno dell'intervallo -32767 and +32767. Suggest indica il valore massimo suggerito che è possibile dare all'amplificazione prima di creare distorsioni relativamente all'audio che è stato analizzato tramite Play (per impostare il volume al valore suggerito da suggest basta cliccare su Apply o settarlo manualmente tramite il potenziometro) . Il problema è che per avere un valore "suggest" valido per tutto il filmato (e assenza certa di distorsioni) occorrebbe analizzare (play) il video nella sua interezza cosa che comporta parecchio tempo ( con Fast search i tempi diminuiscono leggermente anche se non si ascolta più l'audio).
Per video lunghi, il mio consiglio è quello di posizionarsi nei punti in cui l'audio è ai massimi livelli e dopo aver analizzato alcuni secondi o minuti del video, utilizzare il valore che appare in suggest in maniera intelligente, cioè settando manualmente un valore leggermente inferiore rispetto a quello indicato (in tutti i casi come già detto non conviene mai superare valori di 60000-80000.)

Ultima cosa: la posizione corrente dell'audio (il potenziometro in alto) è quella da cui poi FlaskMpeg inizierà la conversione audio-video: per questo motivo nel caso di conversioni dall'inizio del film occorre selezionare "Seek first" e nel caso di conversioni da punti particolari del video occorre ritornare in lettore e da li selezionare visivamente il punto da cui inizierà la decompressione.

La versione 0594 h2 PRE3 al di là della diversa sezione audio, contiene la comoda possibilità di posizionarsi sul punto desiderato, anche all'interno del pannello di uscita, la finestra dalla quale settare visivamente il ridimensionamento e il ritaglio del video. Da notare come il ritaglio diversamente dalle altre versioni di flaskMpeg, viene rappresentato da un rettangolo bianco il cui interno è poi inviato in uscita.

La versione 06 preview, è come dice il nome, una versione Beta della prossimo Flaskmpeg 06: grazie ad una maggiore modularità tra breve, speriamo presto, dovrebbe supportare tutti i vantaggi velocistici delle numerose modifiche alla 0594: attualmente è solo leggermente più lenta delle versioni 0594 più veloci ma priva del bug che caratterizzava le versioni PX3 più veloci.

Per quello che ho constatato sul mio sistema la versione appare già abbastanza stabile, nonostante alcuni problemi tipici delle versioni Beta. La lista dei bug è presente sul sito "ufficiale" known bugs page: tra questi il più importante è, molto spesso, la segnalazione di un errore di sistema alla chiusura del programma e uno strano comportamento nel ridimensionamento dei formati utilizzati dai SVCD (facilmente risolvibili se si utilizza l'encoder Tmpeg, come descritto nella guida alla creazione dei SVCD).

Il mio consiglio è prima di tutto quello di fare dei brevi test per tastare il comportamento sul proprio sistema: per fare delle conversioni "definitive" che non siano test (ad esempio , un intero film in DivX;-)), è consigliabile avviare la conversione a "sistema pulito", ovvero riavviando i computer, settando i parametri , e iniziando subito la conversione; al contrario se si avviano e poi si bloccano più codifiche , se si modificano più volte i parametri, se si "pasticcia " con le opzioni audio, e poi si avvia una lunga conversione, la possibilità del manifestarsi di bug aumenta. Non auguro a nessuno una conversione di 12 ore e in seguito l'amara sorpresa di un audio magari senza il canale centrale!!

In particolare ho notato la difficoltà a fare 2 compressioni con audio mp3 successive: spesso la seconda conversione è muta ! Obbligatorio in tal caso riavviare il sistema !!!.

1) Modularità delle parti del sw più importanti, che vengono implementate come plug-in. In pratica per il programmatore è possibile modificare sezioni fondamentali del Sw senza dover compilare tutta l'applicazione; per l'utente basterà avere un solo eseguibile (Flaskmpeg.exe) e vari plug-in ciascuno ottimizzato per una operazione. Le sezioni implementate come plug-in sono:

2) Possibilità di memorizzare i parametri presenti in "opzioni globale progetto, settaggio film " ovvero di tutti i parametri relativi a dimensione del video, tipo di decodifica, cropping, tipo di ridimensionamento,nome file,.......). Sono esclusi tutti i parametri relativi ai plug-in di uscita che di volta in volta vanno settati.

Per memorizzare i parametri (opzioni/opzioni globali progetto/ profile manager) basta cliccare su save current e indicare il nome del profilo. Tutti i profili sono memorizzati automaticamente nella sottodirectory "profiles" e sono richiamabili anche tramite il relativo menù.

3) Control panel completamente rinnovato: è possibile spostarsi facilmente all'interno del video sia tramite il cursore orizzontale

Per fissare il segmento video da convertire, occorre prima di tutto cancellare la selezione corrente con

; poi dopo essersi posizionati sui punti di interesse, si seleziona il punto di inizio e fine conversione tramite (tali posizioni possono essere raggiunte cliccando su

Il video selezionato è evidenziato dal colore diverso

e sarà convertito per intero solo se il parametro opzioni\opzioni globali progetto\ generali\tempo di compilazione è pari a "compila l'intero file" o contiene un valore MAGGIORE della durata della parte selezionata. In caso contrario il video sarà convertito a partire dall'inizio sezione, ma solo per la durata indicata.
L'ultima operazione da fare è confermare l'intervallo scelto cliccando su

Vediamo nel caso più generale i 3 diversi modi di procedere nella scelta della sezione di video da convertire:

La conversione si avvia o tramite esegui/inizia la conversione o cliccando su

presente nel Control Panel.

E' importante osservare come i secondi o fotogrammi da convertire presenti in opzioni/opzioni globali progetto/generali

indicano il video da convertire a partite dal punto d'inizio selezionato; SE SI INDICA COMPILA L'INTERO FILE, verrà convertito il video selezionato

e quindi non necessariamente tutto il video.

4) Uscita in formato OpenDML AVI: per file di lunghezza maggiore a 2GB, vengono creati avi separati, ciascuno di dimensione Max di 2 GB. A causa di una diversa gestione del multiplexing audio- video, a parità di parametri, in molti casi quali le conversioni DVD--> DivX;-) si ottengono dei tempi di decodifica leggermente maggiori ( 5-10%).

Nel caso di creazione diretta DVD--> DivX;-) con audio mp3 in modalità d'uscita OpenDML AVI, si ottiene un multiplexing audio video ottimizzato, diversamente da quello che succede con la modalità Avi output.

Infatti nel caso di modalità Avi output, il multiplexing tra l'audio mp3 e il video DivX;-) è realizzato in maniera tale che viene caricato il flusso audio-video ogni 5-10 secondi, con dei caricamenti da HD (o CD rom) che tendono a saturare la potenza di calcolo della CPU per alcune frazioni di secondo: il risultato è che in tali istanti sono possibili degli scatti del video. Per ovviare a questo problema occorre rimultiplexare l'avi tramite Virtual dub, con una ulteriore perdita di tempo (vedi l'articolo sul DivX). Al contrario se si utilizza la modalità d'uscita OpenDML AVI, il caricamento del video è continuo e pertanto non ci sono particolari istanti di maggiore occupazione di CPU. Ecco graficamente l'occupazione di CPU e il bitrate nei due casi, con il medesimo filmato.

5) Nella nuova finestra audio player è possibile tramite play e stop ascoltare l'audio e in tempo reale modificare i seguenti parametri.

- regolazione del " Dinamic Range Compression". Metodo di amplificazione "intelligente", una specie di compressore di dinamica che aumenta il volume nei punti in cui è basso e lo attenua quando è forte. Non conviene mai eccedere nei livelli ( il cursore deve essere posto verso il basso) poiché è facile introdurre delle distorsioni.

- regolazione dei volumi del canale centrale , dei frontali e dei posteriori. L'ampiezza è espressa in dB:

- amplificazione globale:

è possibile inserire manualmente un valore (100%= lascia il volume originario, 200% raddoppia il volume totale,.....) o far calcolare il volume massimo che non introduce distorsioni (Search).

Ovviamente una amplificazione eccessiva crea distorsioni e in generale non conviene superare il 200%. Le eventuali regolazioni dei singoli canali e il dinamic range compression influenzano il volume generale e pertanto il valore ricercato. Nel caso si seleziona un dinamic range compression eccessivo, la ricerca si blocca con l'indicazione 100% che indica l'insorgere di distorsioni. Per un Bug del SW se si applica la ricerca dopo aver selezionato e poi deselezionato "dinamic range compression" e/o "multichannel volumes" si ottengono risultati errati: basta comunque uscire dalla sezione audio player e poi ritornarci per riattivare correttamente il "search" automatico.

- compatibilità

: se selezionata l'audio ac3 5.1 sarà compatibile con il formato Dolby Sourround, (4 canali in codifica matriciale da estrarre dal flusso stereo prodotto con un amplificatore o player compatibile)
- scelta del flusso audio da convertire

6) E' possibile tramite "Esegui/ extract audio to Wav" convertire l'intero flusso audio ac3 5.1 in Wav 16 bit 44100/4800 PCM non compresso; sono valide tutte le impostazioni (regolazioni dei volumi, scelta del flusso audio....) e viene sempre convertito l'intero file caricato. E' possibile scegliere la freq. di campionamento 44100 o 48000 in opzioni/opzioni globali progetto/ audio; se in tale finestra si indica i "copia direttamente il flusso..." ,andando in opzioni/opzioni globali progetto/ files è possibile inserire il nome del file wav da creare.

I Wav prodotti sono incompatibili con il windows media player, mentre sono letti correttamente da sw quali Winamp, Virtualdub, WaveLab,.....: tipici problemi di una versione beta.

7) Più intuitivo il preview nel "pannello di uscita" per il ridimensionamento e il ritaglio del video: è possibile spostarsi all'interno del filmato e l'immagine finale è mostrata all'interno di un riquadro bianco.

8) Presenza del test IEEE-1180 sulle IDCT utilizzate: ho analizzato le caratteristiche nella sezione relativa

Il bug più evidente della versione 06 sta nella impossibilità di trasformare correttamente video anamorfico in non anamorfico (l'opzione "Mantieni rapporto altezza/larghezza") nel caso di risoluzioni particolari quale la 480*576 (o 352*576) utilizzata per i SVCD. Se la conversione è fatta con Tmpeg , tale limite è facilmente superabile, tramite il metodo che trovate nella guida sui SVCD.

Arrivare a delle conclusioni non è facile visti i tanti parametri in gioco e considerando come nei prossimi mesi probabilmente vedranno la luce nuove versioni di flaskmpeg. La premessa da fare è che per ovvi motivi non ho potuto sperimentare intensamente tutte le versioni e pertanto mi è impossibile dare dei giudizi sulla loro stabilità; la versione in assoluto più simile alla 0594 originale e contemporaneamente abbastanza più veloce è la 0594Miha che almeno in teoria dovrebbe essere la versione più stabile: se siete stanchi di codifiche che si bloccano dopo numerose ore di compressione, non vi rimane che provare tale versione, che comunque non è Decss e che pertanto converte solo video decriptato e copiato su HD. Riporto per comodità l'istogramma dei risultati.

Riguardo la 06 preview, insieme al plug-in Miha.idct.flask, si può tranquillamente dire che è ad un passo dallo sbaragliare la "concorrenza": speriamo tra breve nella disponibilità della versione definitiva. Non sono in grado di dare delle valutazioni definitive sulla stabilità e compatibilità, vista la giovinezza della versione, anche se per i test fatti non mi sembra ci siano problemi di stabilità superiori alle altre versioni; rimane comunque prudente riavviare il computer prima di una compressione impegnativa (vedi un intero film!!). I parametri in gioco (sistema operativo, lettore DVD-Rom, film,...) rimangono comunque tantissimi e possono esistere delle incompatibilità specifiche. Il difetto maggiore lo si ha all'uscita del programma in cui quasi sempre un messaggio di errore obbliga il riavvio del sistema: nulla di veramente grave.

Ecco la tabella (già vista) delle velocità di codifica in fotogrammi al (per) secondo (fps); le versioni più veloci sono quelle che producono il fps maggiore: le versioni evidenziate in rosa sono quelle dotate di funzionalità Decss (non richiedono la copia del DVD su HD) mentre le versioni in giallino consentono la conversione solo a partire dall'inizio del video e ad ogni cambio di capitolo introducono alcuni frames con leggeri artefatti e una brevissima interruzione dell'audio.

Nel caso in cui si desidera convertire un DVD direttamente dal DVD-Rom, senza il ripping (decriptazione e copia) su HD, ci sono 6 possibilità: 06 preview, 06 preview miha ,0593 Decss, 0594 Decss , 0594 PX3 s2v3 Decss ,0594 h2 PRE3 (evidenziate in rosa). Delle 6, le 0593/ 0594 decss e la 06 preview con il relativo plug-in, determinano automaticamente la chiave, mentre per le altre 3 occorre inserirla manualmente dopo averla ricavata tramite un sw di ripping quale Smart Ripper o DVD Decripter.

Tra le 5 versioni il mio consiglio è di utilizzare la 06 preview: se si desidera la massima velocità a tutti i costi, è consigliabile la 0594 PX3 s2v3 Decss decisamente più veloce ma con i problemi noti : impossibilità di fare una conversione partendo da un punto diverso da quello iniziale , piccola interruzione audio e artefatti nei fotogrammi a cavallo tra il cambio di capitolo. Le ultime 3 possibilità ( h2 pre3, 0593 Decss, 0594 Decss ) sono delle vere e proprie "riserve" identiche tra loro per la velocità , da usare se la 06 preview fallisce nella conversione. La h2 pre3 ha in più la possibilità di settare i parametri relativi all'audio, utile come visto nel caso di conversioni in DivX;-) fatte all'interno di flaskmpeg: le medesime caratteristiche le possiede la 06 preview.

Tra le modalità IDCT in base alle analisi sia visive che numeriche, come ampiamente dimostrato , conviene scegliere la modalità più rapida che è la MMX: agli amanti della ottimizzazione se usate la 0594 PX3 s2v3 Decss consiglio un breve test sulla velocità della modalità non MMX che sul mio P2 400 è risultata leggermente più rapida della MMX ( basta convertire ad esempio 20 secondi di uno stesso filmato e cronometro alla mano scegliere la modalità più rapida): in tutti i casi è possibile guadagnare solo piccolissime frazioni di tempo (tipo 1 secondo ogni 2 minuti di conversione!!!).

La seconda possibilità è quella di fare la conversione partendo da DVD decriptati e copiati su HD tramite un sw di ripping quali Smart Ripper o DVD Decripter. Lo svantaggio di questo metodo è il tempo che occorre attendere per il ripping (da 30 minuti a più di un ora per un intero film a secondo della velocità del proprio sistema e dalla dimensione del film da convertire): al contrario il ripping può risultare necessario in tutti quei casi in cui i metodi Decss presenti in Flaskmpeg falliscono.

Dopo aver fatto il ripping rimangono le seguenti possibilità (riporto in ordine di velocità)

Per la scelta della modalità iDCT vale quanto detto prima: usate sempre la iDCT MMX e nel caso della px3 004e eventualmente valutate con un test se la modalità non MMX sul vostro sistema risulta più veloce. Nella 06 preview-Miha la Idct da utilizzare è la Optimized MMX iDCT

In conclusione ecco una carrellata delle versioni più importanti, ciascuna con i propri vantaggi e svantaggi:

Esistono metodi alternativi all'utilizzo Flaskmpeg per la conversione di video proveniente da DVD in formati quali DivX;-), mpeg1 o 2 (XVCD, SVCD, MiniDVD).

Con DVD2AVI è possibile convertire i VOB dei DVD in avi solamente alla risoluzione nativa (720*576 nel caso di DVD PAL) ; per le conversioni in formati diversi (mpeg 1 e 2 ) e a risoluzioni diverse occorre collegare DVD2AVI ad encoders esterni quali VirtualDUB o TMpeg che si preoccuperanno anche di ridimensionare il video: le prestazioni ottenute allo stato attuale sono inferiori rispetto all'utilizzo delle versioni più rapide di Flaskmpeg. Per comprimere in mpeg conviene creare la catena DVD2AVI-->Virtual Dub (frame server)--> Tmpeg piuttosto che collegare direttamente DVD2AVI a Tmpeg; il collegamento diretto produce conversioni notevolmente più lente (anche del 30%) mentre il collegamento che utilizza VirtualDub supera di pochissimo (di fatto pareggia ) la velocità che si ottiene con Flaskmpeg 06 .

DVD2AVI comunque non invia direttamente l'audio agli encoders ma lo copia in formato wave non compresso su HD: ai tempi indicati nella tabella di sotto occorre sommare i tempi relativi alla decompressione dell'audio (sul mio P2 400 circa 20 secondi per ogni minuto di video da decodificare): sommando questi tempi aggiuntivi le velocità complessive risultano inferiori. Vi rimando all'articolo relativo.

Nel caso di DVD2avi per sola decodifica (prima colonna) intendo l'opzione preview (F5) con o senza previsualizzazione (F7): nel caso di DVD2avi-->Virtual dub intendo la modalità preview di VirtualDub (file/preview (F5)).

Mpeg2avi, privo di capacità di Decss, è utilizzabile solamente per le decodifiche in avi e non in mpeg (è pertanto usato per fare dei DivX;-)). Ha il "difetto" di decomprimere solo il video, mentre la parte audio è semplicemente copiata su HD nel formato originale ( tipicamente ac3): se da un lato la cosa è ottima nel momento in cui si desidera fare un DivX;-) con audio ac3, al contrario per fare un DivX;-) diciamo "classico" con audio mp3 o WMA, occorre usare un sw esterno per la decompressione ac3---> in WAV e Virtualdub per il multiplexing e compressione audio in mp3 o WMA.

Anche per Mpeg2avi valgono i discorsi appena visti sul tempo da sommare a causa dei passaggi aggiuntivi (ripping e conversioni), se si vuole dare una valutazione oggettiva del metodo. Secondo la mia opinione l'uso di Mpeg2avi è consigliabile alla pari di flaskmpeg nel caso di DivX;-) con audio ac3.
Nella tabella indico i tempi misurati con mpeg2avi (in modalità a linea di comando e senza neanche la copia del relativo flusso ac3) e con MpegtoAVIPX3 v_010 insieme con l'interfaccia grafica MPEG2AVI/AC3DEC/vStrip GUI v0.20. MpegtoAVIPX3 è in grado di copiare in parallelo alla decodifica, il flusso audio ac3.

Le compressioni in Mpeg SVCD e XVCD sono fatte con la catena Flaskmpeg-->Tmpeg beta12a.

Nel caso di DivX;-) i valori indicati per le versioni di flaskmpeg comprendono la decodifica dell'audio in Wav PCM non compresso, mentre per mpegtoavi l'audio o è ignorato (Mpegtoavi) o semplicemente copiato in ac3 (Mpegtoavipx3).

Per poter disporre e utilizzare le diverse versioni di flaskmpeg 0594, dopo aver fatto una installazione completa (ad esempio copiando l'insieme dei file presenti nella 0593 Decss scaricabile dal mio sito come più volte descritto nei miei articoli), occorre copiare SOLAMENTE il nuovo eseguibile nella stessa directory in cui è presente la prima versione di flaskmpeg installata..

Ovviamente prima di copiare il nuovo eseguibile è fondamentale rinominarlo con un nome appropriato, sia perché è impossibile avere 2 file con lo stesso nome e sia perchè dopo aver copiato diverse versioni è importante saperle riconoscerle rapidamente: quindi non rinominate le versioni in Flaskmpeg1.exe, Flaskmpeg2.exe,Flaskmpeg3.exe ma in nomi più indicativi, magari analogamente a come ho "battezzato" le versioni in questo articolo.

Riguardo la 06 preview, il metodo più semplice è quello di scaricare la versione presente nel mio sito Flaskmpeg 06 preview decss e in seguito di copiare il tutto in una directory diversa da quella in cui sono presenti le varie versioni 0594.

Per l'installazione del plug-in css.mism.flask, come già detto esistono 2 versioni, aventi lo stesso nome: la versione dell'11-3-2001 (135168 byte) in cui occorre inserire manualmente la chiave Decss e la più recente versione del 21-04-2001 (143360 byte) in cui la chiave è cercata automaticamente. Il plug-in deve essere presente nella stessa directory in cui c'è flaskmpeg.exe. Scaricando la versione Flaskmpeg 06 preview decss dal mio sito trovate inserita nella stessa directory di flaskmpeg la versione in cui la chiave deve essere inserita manualmente. Per utilizzare alternativamente una delle due versioni di css.mism.flask, basta copiare quella desiderata nella directory in cui c'è flaskmpeg.exe, sovrascrivendo l'altra. Le due versioni le trovate nelle cartelle "css automatico" e "css manuale".

Quale delle due conviene usare? La versione "automatica" è ovviamente più comoda da usare ma ha lo svantaggio che in una versione precedente a causa di un problema sulla cache utilizzata rallentava vistosamente la decodifica in maniera ciclica (almeno sul mio sistema): la nuova versione, che trovate nella distribuzione presente sul mio sito Flaskmpeg 06 preview decss , con il mio sistema ( Creative PC-DVD 5X) ha risolto il problema, ma non posso garantire per le altre configurazioni. L'autore parla di una futura versione che dovrebbe ottimizzare l'uso della cache tramite un test interno.
Per quanto visto basta fare due brevi test con entrambe le versioni e scegliere eventualmente la versione "manuale" se la "automatica" crea rallentamenti: ovviamente prima di sostituire la versione occorre chiudere flaskmpeg se è in esecuzione.

Nell'ipotesi in cui volete procedere con l'installazione di una versione scaricata altrove (ad esempio la versione presente sul sito Doom 9 FlaskMpeg 0.60 preview ) , cosa che magari è già stata fatta, in fase di installazione quando richiesto, conviene scegliere una directory diversa da quella in cui sono installate le varie 0594 ad evitare conflitti tra le varie versioni: ovviamente si dovranno ricopiare, se disponibili sul proprio PC, gli altri plug-in di uscita non forniti con Flask (LSX , panasonic, CCE,..)

Dopo aver installato il sw occorre copiare nella directory in cui è presente flaskmpeg.exe, uno dei due plug-in css.mism.flask che trovate zippati sul mio sito mism1.zip : vale ovviamente quello appena detto per la scelta della versione automatica o manuale.

Come seconda operazione occorre verificare se nella directory in cui c'è flaskmpeg.exe sono presenti uno o più dei seguenti plug-in (dipende dalla versione scaricata)

In caso affermativo questi andranno cancellati poichè sono delle versioni meno recenti della css.mism.flask

Verificate che nella directory in cui c'è flaskmpeg.exe, tra i diversi plug-in installati del tipo nome.mism.flask siano presenti contemporaneamente solo i due plug-in css.mism.flask e null.mism.flask

NOTA: su certe configurazioni, dopo aver installato la 06 preview, nell'uso di alcune delle precedenti versioni di flaskmpeg v.0594, apparentemente sembra impossibile selezionare opzioni/opzioni globali Progetto/generali/ tempo di compilazione. In realtà NON FUNZIONA L'INSERIMENTO DEL TEMPO IN SECONDI: occorre pertanto o esprimere il tempo in immagini o selezionare "compila l'intero file"

Altri Sw citati nell'articolo
DVD2AVI	Sito Ufficiale http://hiroko.ee.ntu.edu.tw/ Digital Video dvd2avi.zip
MPEG2AVI/AC3DEC/vStrip GUI	Sito Ufficiale http://members.nbci.com/DanniDin/GUI4mpeg2avi.htm Digital Video gui.zip
Mpeg2AviPX3	Sito Ufficiale http://go.to/px3 Digital Video gui.zip

Come al solito per qualsiasi commento e parere potete contattarmi al mio indirizzo di posta elettronica.

Flaskmpeg v.0593 Decss	Decriptazione automatica
Flaskmpeg v.0594 Decss	Decriptazione automatica
Flaskmpeg v.0594 PX3 s2v3 css	Decriptazione con inserimento key
Flaskmpeg v.0594 h2 PRE3	Decriptazione con inserimento key
Flaskmpeg v.06 preview + plug-in css.mism.flask	Decriptazione con inserimento key o automatica a secondo del plug-in utilizzato

software	velocità di decodifica di un vob	velocità: % riferita al più veloce	tempo impiegato riferito al più veloce
DVDtoAVI v 1.65 R:G:B	15.4 fps	100 %	1
Flaskmpeg v.0594 PX3 s2v3 Miha	12.8 fps	83 %	1.20
Flaskmpeg v.06 Preview Miha	11.1 fps	72 %	1.38
Flaskmpeg v.0594 originale	7.4 fps	48 %	2.08
DVDtoAVI v 1.65 4:2:2 (fuori gara)	21.3 fps	138 %	0.72

software	sola decodifica vob 720*576	sola decodifica vob ridimensionato a 352*288	DivX;-) 352*288 1000Kbit/s	DivX;-) 480*288 1200Kbit/s	XVCD mpeg1 352*288 2100Kbit/s	DivX;-) 704*432 1600Kbit/s	SVCD mpeg2 480*576 2500Kbit/s max
Flaskmpeg v.0594 PX3 s2v3 Miha (Idct MMX)	11.7 fps (+65%)	14.1fps (+78%)	8.2 fps (+49%)	7.0 fps (+43%)	4.31 fps (+26%)	4.5 fps (+25%)	2.10 fps (+13 %)
Flaskmpeg v.0594 PX3 004e (Idct non MMX)	10.5 fps (+48%)	12.4 fps (+57%)	7.4 fps (+35%)	6.6 fps (+34%)	3.96 fps (+15.8%)	4.4 fps (+22%)	1.98 fps (+6.5 %)
Flaskmpeg v.06 preview-Miha	10.0 fps (+41%)	12.0 fps (+52%)	6.9 fps (+26%)	6.3 fps (+29%)	3.96 fps (+15.8%)	4.3 fps (+20%)	1.98 fps (+6.5 %)
Flaskmpeg v.0594 originale (Idct MMX)	7.1 fps	7.9 fps	5.5 fps	4.9 fps	3.42 fps	3.6 fps	1.86 fps

software	decodifica vob 720*576 rid. prossimo (nessun filtro)	decodifica vob 720*576 rid. bilineare	decodifica vob 720*576 rid. bicubico
Flaskmpeg v.0594 PX3 s2v3 Miha (Idct MMX)	12.8 fps	11.7 fps	9.2 fps
Flaskmpeg v.06 preview-Miha	11.1 fps	10.0 fps	7.8 fps
Flaskmpeg v.0594 originale (Idct MMX)	7.4 fps	7.1 fps	5.6 fps

	Pentium	Pentium MMX	Pentium2 Celeron, AMD K6	Pentium3 Celeron 2	Pentium 4	AMD Athlon AMD Duron
Interi 32 bit	X	X	X	X	X	X
MMX 32 bit		X	X	X	X	X
Floating point 64 bit (X87)	X	X	X	X	X	X
SSE				X	X
SSE 2					X
3DNow!						X


Flaskmpeg v.0594 originale	Flaskmpeg v.0594 Intel	Flaskmpeg v.0594 PX3 all IDCT


Flaskmpeg v.06 preview	Flaskmpeg v.06 preview+Miha iDCT (in rosso)

Pixel corretto (R,G,B)	Pixel errato (R,G,B)	differenza (in valore assoluto)	errore componente R	errore componente G	errore componente B
(128,100,100)	(128,100,100)	(0 ,0 ,0)	0	0	0
(128,100,100)	(128,100,101)	(0 ,0 ,1)	0	0	1/256
(128,100,100)	(128,99,102)	(0 ,1 ,2)	0	1/256	2/256
(128,100,100)	(127,99,102)	(1 ,1 ,2)	1/256	1/256	2/256
(128,100,100)	(128,96,113)	(0 ,4 ,13)	0	4/256	13/256

n. di pixel in una immagine	n. di pixel in 1 secondo di video	n. di pixel in 10 secondi di video
414 720	10 368 000 (=25*414720)	103 680 000(= 1025414720)

caso N.	GOP	massimo accumulo di errori	Considero ad esempio il caso 4:ho un possibile accumulo di errore se il pixel in esame del frame P appartiene ad un macroblocco codificato come Forward Predicted Block , ovvero è stato calcolato come differenza rispetto ad un pixel del frame I precedente, pixel che nella decodifica di tale frame suppongo errato poichè vittima di un errore della IDCT. Considero il caso 3: ho un possibile doppio errore (accumulo di tipo2) se il pixel in esame del frame B appartiene ad un Interpolated Block, ovvero è stato calcolato come media matematica tra un macroblocco precedente (I) e uno seguente (P) entrambi sbagliati nei pixel da cui poi si calcolerà la media. Considero il caso 7: ho un possibile doppio errore (accumulo di tipo 2) se il pixel in esame del frame P appartiene ad un macroblocco codificato come Forward Predicted Block , ovvero è stato calcolato come differenza rispetto ad un pixel del frame P precedente, che suppongo errato. Per avere l'accumulo di errori, si deve avere la medesima cosa per il pixel corrispondente del frame P precedente, calcolato come differenza rispetto al frame I anche lui errato in quel pixel.
1	IBBPBBPBBPBBI	0
2	IBBPBBPBBPBBI	2
3	IBBPBBPBBPBBI	2
4	IBBPBBPBBPBBI	1
5	IBBPBBPBBPBBI	3
6	IBBPBBPBBPBBI	3
7	IBBPBBPBBPBBI	2
8	IBBPBBPBBPBBI	4
9	IBBPBBPBBPBBI	4
10	IBBPBBPBBPBBI	3
11	IBBPBBPBBPBBI	5
12	IBBPBBPBBPBBI	5

.	Errori presenti nei 3 spazi colore RGB di un frame 720576 su di un massimo di 1244160 (720576*3 = 1244160) nel caso di decodifica iDCT MMX, rispetto alla iDCT di riferimento (reference): versione flaskmpeg 0594 originale											5	Errori presenti nei 3 spazi colore RGB di un frame 720*576 nel caso di decodifica iDCT non MMX, rispetto alla iDCT di riferimento (reference): versione flaskmpeg 0594 originale
.	N.	tipo frame	errori 1/256	errori 2/256	errori 3/256	err. 4/256	err. 5/256	err. 6/256	err. totali	stima pixel errati (err/2.4)	stima % pixel errati		errori 1/256	errori 2/256	errori 3/256	err. 4/256	err. 5/256	err. totali (% rispetto alla modalità MMX)
a	0	I	11256	5138	49	2	0	0	16445	6852	1,65		5830	2580	37	1	0	8448 (51%)
	1	B	17031	8283	167	19	1	0	25501	10625	2,56		8707	3871	66	5	0	12649 (49.6%)
	2	B	20047	9888	244	47	1	0	30226	12594	3,03		9873	4521	65	5	0	14464 (47,8%)
	3	P	17143	7659	133	21	0	0	24956	10398	2,50
	4	B	23428	11306	242	103	0	0	35079	14616	3,52
	5	B	25871	12065	278	69	5	1	38289	15953	3,84
	6	P	23927	11006	218	75	5	0	35231	14679	3,53
	7	B	27906	11063	265	52	8	0	39294	16372	3,79
	8	B	30696	12143	297	69	0	0	43205	18002	4,17
	9	P	28785	12045	307	12	8	0	41157	17148	3,97		14683	7068	121	11	0	21883 (53,1%)
	10	B	33318	13623	366	85	12	0	47404	19751	4,58		.	.	.	.	.	.
	11	B	36065	14116	384	74	12	1	50652	21105	4,89		18749	9006	179	30	4	27968 (55,2%)
	12	P	34221	14003	402	92	7	1	48726	20302	4,70		.	.	.	.	.	.
	13	B	29886	11878	275	53	4	1	42097	17540	4,07		15775	6777	143	14	0	22709 (53,9%)
	14	B	28786	10874	243	49	3	0	39955	17647	4,09

immagine corretta	immagine con errori	errori componente R	errori componente G	errori componente B

immagine corretta ingrandita del 300%	immagine con errori ingrandita del 300%

Qualità di riferimento Idct (floating point) Confronto versione originale non ottimizzata e la versione Intel	Qualità di riferimento Idct (floating point) con la versione originale non ottimizzata

FlasK Vulture VCD (352x288) & SVCD(480x576) Keep aspect ratio No crop, No letterboxing
Resizing\iDCT	MMX	non-MMX	Reference	Athlon x87 optimisized	Athlon 3DNOW!	Hybrid
Bilinear (VCD)	26,8	24,0	10,1	14,2	17,4	24,6
Bicubic (VCD)	22,5	20,4	9,4	12,8	15,4	21.0
HQ Bicubic (VCD)	17,2	16	8,3	10,9	12,7	16,2
..
Bilinear (SVCD)	23,6	21,4	9,7	13,2	15,9	21,9
Bicubic (SVCD)	20,0	18,3	9,0	12,0	14,2	18,6
HQ Bicubic (SVCD)	15,9	14,8	8,0	10,4	12,0	15,1

Versione 0594 originale		note
Errori (fattore colore R) Idct MMX	Errori (fattore colore R) Idct non MMX	note
		- Le immagini sono rimpicciolite del 50% - E' evidente nel caso della IDCT MMX un numero di errori quasi doppio - intensità e distribuzione degli errori sembra casuale


versione PX3 s2V3		note
Errori (fattore colore R) Idct MMX	Errori (fattore colore R) Idct non MMX	- Ai medesimi errori visti nella versione 0594, si sommano quelli concentrati in blocchetti 16*16 pixel: ecco un forte ingrandimento

Versione Px3 s2v3 Miha. Errori (fattore colore R) Idct non MMX	note
	La IDCT non MMX Miha produce un numero di errori limitato (i pochi pixel diagonali isolati in figura) : i blocchetti, non presenti nella versione 0594 miha, sono presenti nella 0594 PX3 s2v3 miha a causa delle ottimizzazioni px3. L'immagine a sinistra che presenta i blocchetto 16*16 è relativa a quest'ultima.

Famiglia 1	0594 originale, 0593 decss, h2 PRE3, 0594 miha
Famiglia 2	le versioni PX3: 004e, s2v3, s2v3 Decss, Vulture, s2v3 Miha
Famiglia 3	06 preview, DVD2AVI

Differenze tra le modalità reference della "famiglia 2" e modalità reference della "famiglia 1"
errori 1/256	errori 2/256	errori 3/256	err. 4/256	err. 5/256	err. 6/256	err. 7/256	err. 8/256	err. 9/256	err. totali	stima pixel errati (err/2.4)	stima % pixel errati	errori in scala di grigio ( da una porzione di immagine)
63887	33822	2910	800	130	55	5	5	2	101616	42340	10,2%

Differenza (fattore colore Red ) tra una immagine decodificata con la 0594 e la stessa decodificata con la 06 preview sempre in modalità reference.
Altro esempio (ingrandimento 200%)

versione	modalità IDCT	confronto con	errori 1/256	err. 2/256	err. 3/256	err. 4/256	err. 5/256	err. 6/256	err. totali	stima pixel errati (err/2.4)	stima % pixel errati	velocità decodifica vob 720*576	note
0594 originale	MMX	ref1	26579	12719	315	147	10	3	39773	17572	3,99%	7,1 fps
0594 originale	non MMX	ref1	14459	6663	114	25	4	0	21265	8860	2,13%	6,4 fps
0594 Intel	MMX	ref1	26579	12719	315	147	10	3	39773	17572	3,99%	7,6 fps	produce le stesse immagini della 0594 originale
0594 Intel	non MMX	ref1	14459	6663	114	25	4	0	21265	8860	2,13%	6,4 fps	produce le stesse immagini della 0594 originale
0594 miha	MMX	ref1	26579	12719	315	147	10	3	39773	17572	3,99%	9,1 fps	produce le stesse immagini della 0594 originale (in realtà c'è in più un pixel diverso in media ogni 2-3 fotogrammi )
0594 miha	non MMX	ref1	2	1	0	0	0	0	3	1	0,0002%	8,5 fps	è in pratica una decodifica senza errori.
0594 PX3 004e	MMX	ref2	32174	14818	555	139	5	0	47691	19871	4,79%	10,3 fps
0594 PX3 004e	non MMX	ref2	22035	9809	313	54	1	0	32212	13421	3,23%	10,5 fps
0594 PX3 s2v3	MMX	ref2	32174	14818	555	139	5	0	47691	19871	4,79%	11,2 fps	produce le stesse immagini della px3 004e
0594 PX3 s2v3	non MMX	ref2	22035	9809	313	54	1	0	32212	13421	3,23%	11,3 fps	produce le stesse immagini della px3 004e
0594 PX3 s2v3 Miha	MMX	ref2	32174	14818	555	139	5	0	47691	19871	4,79%	11,7 fps	produce le stesse immagini della px3 004e
0594 PX3 s2v3 Miha	non MMX	ref2	11719	5092	173	22	1	0	17007	7086	1,71%	10,9 fps
06 preview	AMD x87	ref3	201	186	1	0	0	0	388	161	0,038%	3,5 fps
06 preview	MMX	ref3	31875	15025	612	99	6	1-9-1	47628	19845	4,78%	9,3 fps	nel test ho rilevato 9 errori di tipo 7 e uno di tipo 8
06 preview	fast integer (non MMX)	ref3	21761	10005	358	36	1	1-10-1	32173	13405	3,23%	8,8 fps	nel test ho rilevato 10 errori di tipo 7 e uno di tipo 8
06 preview Miha	MMX	ref3	31875	15025	612	99	6	1-9-1	47628	19845	4,78%	10,0 fps	produce le stesse immagini della iDCTMMX fornita di serie con la o6
06 preview Miha	x87fast IDCT (non MMX)	ref3	11520	5229	184	11	0	0	16944	7060	1,70%	9,5 fps

IDCT	velocità di decodifica e compressione in fotogrammi al secondo e incrementi rispetto alla velocità di flaskoriginale	numero di pixel differenti su 888 274 944	massimo errore in floatin point nella decodifica IDCT	freqenza di errori M=1 milione	massima ampiezza dell'errore
flask reference 64-bit float.point	1.55 fps	0 (reference)	0 (reference)	0 (reference)	0 (reference)
my reference x87 - 64 bit float.po.	6.03 fps (3.9 X )	0	N/A	0	0
flask fast non-MMX 32-bit integer	5.22 fps	2164212	0.54916	1/410	1
my fast non MMX floating point 64-bit	7.03 fps (1.35 X )	148	1.98952e-013	1/6.00M	1
flask MMX fastest 32-bit MMX	5.40 fps	310427	0.589824	1/2861	1
my MMX fastest 32-bit MMX	7.38 fps (1.36 X )	538	3.58548e-005	1/1.65M	1

Visualizzazione di un DivX;-) ottenuto tramite l'uscita AVI Out: sono evidenti i picchi nell'utilizzo del processore	Visualizzazione del medesimo DivX;-) ottenuto tramite l'uscita OpenDML AVI o dopo il multiplexing rifatto con Virtual-Dub

ampiezza in dB	amplificazione
+1 dB	1.12 (+12%)
+2 dB	1.26 (+26%)
+3 dB	1.41 (+41%)
+4 dB	1.58 (+58%)
+6 dB	2 (+100%)
+10 dB	3.1 (+210%)
+12 dB	4 (+300%)

Le diverse versioni di FlaskMPEG: velocità reali, opzioni iDCT, errori, caratteristiche e confronto con i metodi alternativi.

0594 PX3 s2v3 Miha	La più veloce in assoluto; consente però la decodifica solo a partire dall'inizio del video e ad ogni cambio di capitolo vengono introdotti alcuni frames con leggeri artefatti e una brevissima interruzione dell'audio.
0594 PX3 004e	Leggermente più lenta della PX3 s2v3 Miha ma in grado di decodificare senza problemi a partire da qualsiasi punto del video. Come riconosciuto dall'autore è consigliabile chiudere e riavviare il programma dopo aver fatto ogni conversione.
06 preview-Miha	Essendo una beta può dare dei problemi di stabilità: leggermente più lenta della PX3 004e. E' dotata di funzionalità di decodifica audio più evolute. E' la versione che consiglio
0594 Miha	La più stabile (è di fatto identica all'originale e ottimizzata nelle IDCT ) ma leggermente più lenta rispetto alla 06 preview
0594 h2 PRE3	Lenta quanto la versione 0594 originale ma dotata di funzionalità di decodifica audio più evolute.

Flaskmpeg v.06 preview + css plug-in + iDCT Miha Plug-in (Miha.idct.flask)
vantaggi	-non occorre la copia e decriptazione del DVD su HD essendo dotata di capacità Decss - grazie all'inserimento manuale della chiave di decodifica è possibile utilizzare direttamente DVD- Rom DVD non decriptati correttamente da Flaskmpeg v.0593 Decss e Flaskmpeg v.0594 Decss - possibilità di modificare il volume dei singoli canali del flusso ac3 o il volume generale dell'audio decodificato - migliore interfaccia grafica nella sezione player - buona velocità di decodifica: nelle conversioni DVD-->DivX;-) dal 20% al 30% più veloce rispetto alla versione originale 0594; 16% circa più veloce per XVCD 352*288 creati con Tmpeg. - IDCT implementate come plug-in: presto disponibili ( si spera) versioni più rapide; ci sono ancora leggeri margini di miglioramento.
svantaggi	- è una Beta e pertanto potenzialmente instabile . - è impossibile mantenere le esatte proporzioni nel caso di ridimensionamento da anamorfico a non anamorfico alle risoluzioni quali 352(480)X 576. Per i SVCD creati con Tmpeg , tale limite è facilmente superabile, tramite il metodo che trovate nella guida sul SVCD
Note	Le 3 versioni di Idct inserite dal plug-in Miha.idct.flask sono quelle in rosso: tra tutte le IDCT la più veloce e super consigliata è la OPTIMIZED MMX IDCT

Flaskmpeg v.0593 Decss e Flaskmpeg v.0594 Decss
vantaggi	- non occorre la copia e decriptazione del DVD su HD essendo dotata di capacità Decss - le capacità Decss sono automatiche (non occorre inserire la chiave di decriptazione) - versioni parecchio stabili essendo identiche alle versioni originali
svantaggi	- la velocità di decodifica è (relativamente) lenta quanto le versioni 0594-0595 originali - basano le capacità Decss (ricerca della chiave e decriptazione) su di un algoritmo che non funziona con alcuni film

0594 PX3 s2v3 Miha
vantaggi	- è la versione più veloce in assoluto: nelle conversioni DVD-->DivX;-) dal 25% al 50% più veloce rispetto alla versione originale 0594; 26% circa più veloce per XVCD 352*288 creati con Tmpeg.
svantaggi	- non è dotata di capacità Decss e pertanto per essere utilizzata occorre la copia e decriptazione del DVD su HD - consente la decodifica e quindi le conversioni solo a partire dall'inizio del video e ad ogni cambio di capitolo vengono introdotti alcuni frames con leggeri artefatti e una brevissima interruzione dell'audio.
note	Con certe CPU la modalità IDCT non MMX è leggermente più rapida della IDCT MMX: è consigliabile un test

0594 PX3 004e
vantaggi	- abbastanza veloce; nelle conversioni DVD-->DivX;-) dal 20% al 35% più veloce rispetto alla versione originale 0594; 16% circa più veloce per XVCD 352*288
svantaggi	- non è dotata di capacità Decss e pertanto per essere utilizzata occorre la copia e decriptazione del DVD su HD - consente la decodifica e quindi le conversioni solo a partire dall'inizio del video e ad ogni cambio di capitolo vengono introdotti alcuni frames con leggeri artefatti e una brevissima interruzione dell'audio.
note	Con certe CPU la modalità IDCT non MMX è leggermente più rapida della IDCT MMX: è consigliabile un test

0594 Miha
vantaggi	- abbastanza veloce, nelle conversioni DVD-->DivX;-) dal 15% al 30% più veloce rispetto alla versione originale 0594. - è la versione in assoluto più stabile poichè di fatto identica alla 0594 originale, tranne nella implementazione della IDCT che permette un incremento evidente della velocità.
svantaggi	- non è dotata di capacità Decss e pertanto per essere utilizzata occorre la copia e decriptazione del DVD su HD.

Forum dedicati a flaskmpeg
Doom 9 forum	Sezione forum di http://go.to/doom9 http://doom9.org/ http://doom9.net/
Flaskmpeg_forum	Sezione forum del sito ufficiale http://go.to/flaskmpeg http://flaskmpeg.sourceforge.net

Smart Ripper e DVD decripter
Per i links e le guide all'uso, riferirsi all'articolo "Il Css e il ripping dei DVD su Hard Disk: possibili applicazioni"
Digital Video	DVD_Decripter.zip SRipper.zip
Geocities	DVD_Decripter.zip SRipper.zip