Comparativa sui CODEC - 2004

Sommario:

1: Introduzione
2: Configurazione del Test
3: Test 1: Matrix Revolutions (veloce) -- versione per banda larga
4: Test 2: Salvate il Soldato Ryan (veloce) -- versione per banda larga
5: Test 3: Futurama (veloce) -- versione per banda larga
6: Conclusioni
7: Oltre ai codec
8: Uno sguardo al futuro
9: FAQ

Benvenuti signore e signori ad un'altra delle mie (famigerate?) comparative sui CODEC.

E' trascorso un anno intero da quando, per l'ultima volta, ho rivolto la mia attenzione ad un pugno di codec e alle loro performance in un classico ambito da "backup" di DVD. Siamo stati testimoni di una forte attività nel settore codec per tutto il 2004: per citarne una componente abbiamo già a disposizione diversi compressori H.264 / MPEG-4 AVC (d'ora innanzi semplicemente AVC). Con l'utilizzo del formato AVC negli standard DVD ad alta definizione di prossima introduzione (qual che sia tra Blu-ray e HD DVD), così come con l'utilizzo che se ne vorrà fare fra gli standard della TV digitale, mi aspetto di vedere parecchio movimento in questa fascia del mercato negli anni a venire. Il formato WMV9 di Microsoft è stato, a sua volta, accettato fra quelli utilizzabili nei prossimi formati DVD ad alta definizione, mentre la stessa Microsoft si sta aprendo alcune strade importanti nel lucrativo mercato televisivo, anche se finora si tratta solo di sistemi proprietari limitati a ristrette aree geografiche.

Per quanto rigurda il formato MPEG-4 Advanced Simple Profile (d'ora in avanti semplicemente ASP), abbiamo visto che i principali produttori di elettronica di consumo hanno immesso sul mercato lettori DVD in grado di riprodurre contenuti ASP (a parte quelli codificati con GMC a "3 punti" che impediscono di fatto l'uso del GMC di XviD e di NeroDigital assieme ai riproduttori DVD da tavolo...). Mentre le migliorie ai codec già esistenti si sono susseguite vorticosamente per tutto l'anno.

Ora una veloce panoramica su quello che è cambiato dall'ultima comparativa, riferendoci ai "partecipanti" di quest'anno:

• 3ivX: Lo sviluppo è stato lento per tutto l'anno. Ma appena in tempo pe la comparativa ho ricevuto una versione preliminare del prossimo 3ivX 5.0. Ora dispone di un'impostazione "qualità / velocità" che vi permette di trovare un compromesso fra la qualità e la velocità di codifica, ed è stato aggiunto anche il supporto ai B-frames. In aggiunta, alla 3ivX sono stati impegnati con lo sviluppo di un codec AVC, che pero' non era pronto in tempo utile per la comparativa.
• DivXNetworks: ha addottato una polica di sviluppo in base alla quale le versioni alpha e beta del codec vengono rilasciate anche al pubblico perchè partecipi al test. Abbiamo visto tutta una serie di questi test che sono sfociati nell'ultima versione ufficiale DivX 5.2.1. Ci sono state anche due alpha pubbliche del DivX 5.2.2 (credo sarà questo il numero di versione che useranno). L'obiettivo dello sviluppo alla DivX è stato quello di ottenere una maggior qualità attraverso il miglioramento sui B-frames (fra le latre cose è ora possibile avere B-frames multipli) e grazie ad una miglior selezione sulla matrice di quantizzazione. Il codec "Fusion" che usero' nella comparativa dispone di nuove modalità "performanti" che migliorano la qualità a discapito della velocità di codifca, che integra quantizzazioni sulla "rate distortion" ottimizzate in standard H.263, una nuova funzione di ridimensionamento basata sull'aspetto di proporzionalità, supporto per la funzione di "deblocking" da 4MB e migliore.
• Nero Digital: il vincitore della scorsa comparativa per quanto riguarda la velocità di codifica, è stato impegnato nello sviluppo della componente qualitativa. In aggiunta ateme, l'azienda che collabora per i codec di Nero, ha sviluppato un encoder AVC che è stato da poco rilasciato al pubblico come parte integrante della soluzione al backup DVD Nero Recode 2.2. Oltre al "classico" transcoding dei DVD, Recode ora può convertire i DVD nei formati ASP, oppure AVC, ambedue - volendo - con audio (HE) AAC, capitoli e sottotitoli integrati in un contenitore multimediale .MP4.
• RealVideo: la versione 10 del codec video è stata lanciata nel 2004, assieme a diversi aggiornamenti successivi del codec. La modalità ad alta qualità EHQ è ora una funzione disponibile di base, e lo sviluppo è stato incentrato soprattutto sulla qualità.
• On2: hanno rilasciato al pubblico il proprio codec VP6 già nell'ottobre 2003. Da allora il codec è stato sottoposto a numerose revisioni fino a marzo 2004, ma da allora non ci sono state novità di rilievo. Solo da poco la On2 ha dato il via ad una fase di "beta testing" su un'applicazione integrata di conversione che ha comportato una ripresa dello sviluppo sul codec steso, anche se sono pronto a scommettere che lo sviluppo si è concentrato più che altro sul prossimo VP7. Purtroppo VP7 non era pronto per il termine ultimo di inserimento nella comparativa (19 dicembre 04) e non sarà più gratuitamente utilizzabile una volta che sarà pronto.
• XviD: la versione 1.0 è stata lanciata all'inizio del 2004, e da allora si è intensificato lo sviluppo della versione 1.1 che si sta ora avvicinando al rilascio definitivo. La nuova versione 1.1 introduce il VHQ sui B-frames, supporto nativo all'aspetto di proporzionalità e al "deringing" direttamente nel decoder, controllo sui valori del bitrate per la codifica a doppia passata compatibile con VBV (è importante per la compatibilità con i riproduttori da tavolo), e supporto ai profili hardware introdotti dalla DivXNetworks per una perfetta riproduzione su lettori da tavolo (nonstante questi profili non sfruttino davvero appieno tutte le caratteristiche che un codec ASP è in grado di offrire...).
• Microsoft's WMV9: è stato reintrodotto nella comparativa soprattutto perchè è stato inserito nelle specifiche HD DVD e Blu-ray. Ci sono stati dei miglioramenti anche per quanto riguarda WMV9, nonostante si tratti più che altro di codifica interlacciata e l'inclusione delle codifiche WMV9 nei TS (flussi di trasporto) della TV digitale. Si sono visto anche alcuni DVD Video commerciali che offrono anche una speciale versione ad alta definizione del film codificata in formato WMV9.
• Videosoft Inc: è il nuvo nome della divisione codec della Vanguard Software, che ora agisce in maniera indipendente dalla casa madre.Offrono 3 diversi codec - uno AVC Simple Profile, uno AVC Main Profile, e uno AVC Main Profile per uso professionale, assieme ad un kit di sviluppo SDK.
• Moonlight software: creatori di filtri di decodifica MPEG-2 molto consociuti ed ampiamente utilizzati (anche per il comparto audio) sono entrati nel mercato AVC ed ora offrono il proprio encoder sotto forma di applicazione "automatizzata" per la trasformazione AVI -> DVD / AVC.
• HDX4: per concludere ecco un codec ASP che ho ricevuto da una casa di software finora sconosciuta, la Jomigo. Il rilascio ufficiale è previsto a breve, sotto forma di programma integrato di conversione AVI/DVD -> ASP.

Come vi avevo già preannunciato l'ultima volta, non tratterò più il codec DivX3 SBC nelle comparative. Sono convinto che adesso abbiamo a disposizioni molte soluzioni definitivamente superiori al SBC, e in più c'è da ricordare che DivX3 è sostanzialmente un "hack" mai autorizzato di un primo codec MPEG-4 della Microsoft (e quindi non molto in linea con le specifiche dello standard...) ed è quindi oggetto di possibili problemi legali.

Sfortunatamente sono stato costretto ad escludere anche il codec AVC della Moonlight, nonostante avessi avuto modo di realizzare alcuni test prima del termine ultimo di ingresso nella comparativa. Uno dei motivi è stato che i loro filtri di decodifica andavano ad interferire con la riproduzione di altro materiale (e persino con gli script di AviSynth), mentre l'altro motivo è legato al fatto che al momento scrivono i propri flussi AVC solo all'interno di TS (flussi di trasporto), che invece sono pensati per lo streaming. Ma il TS non è un contenitore adatto al DVD dei DVD anche perchè aggiunge un notevole "overhead" (spazio per la gestione del "contenitore multimediale") che avrebbe svantaggiato questo codec in modo non corretto poichè a causa di questo maggior "overhead" il bitrate video sarebbe stato considerevolmente più basso di quello di qualsiasi altro competitor. Alla Moonlight stanno lavorando su un miscelatore .MP4 per i propri flussi AVC, e quindi potremo inserirli in una prossima comparativa (e se siamo fortunati per quella volta anche con un controllo sul bitrate per la doppia passata in grado di garantire una riproduzione da tavolo ottimale...).

Come nelle occasioni precedenti ho contattato i produttori dei codec 2 settimane prima dell'inizio delle fasi di codifca, e ho chiesto loro di fornirmi una versione dei loro codec da poter testare, assieme ai settaggi che loro stessi suggerivano per le 3 fonti video originali usate nella comparativa. Settaggi che mi sono stati forniti da tutti i produttori coinvolti e parimenti applicati: percui se pensate che altri settaggi avrebbero permesso di raggiungere risultati migliori siete più che invitati a farne parte direttamente con i produttori dei codec in questione (e non con me: io mi sono limitato ad usare i valori che mi sono stati forniti). Vorrei approfittare dell'occasione per ringraziare tutte le persone coinvolte in questo progetto... sono state 2 settimane piuttosto intense (e sono ancora in contatto con diversi produttori mentre procedono le fasi del test...).

I partecipanti

• 3ivX D4 4.5.2fc8 (non ancora disponibile, sarà pubblicato col nome di 3ivX 5.0)
• DivX Fusion 5.9 (non ancora disponibile)
• HDX4 1.4 (non ancora disponibile)
• Microsoft WMV9 VCM
• NeroDigital AVC Main Profile (core encoder versione 1.0.3.4, sarà integrato nella prossima versione di NeroVision). Da ora ci riferiremo a questo codec con l'acronimo ND MP.
• NeroDigital AVC High Profile (core encoder versione 1.1.0.1, ben lungi al momento da qualsiasi pubblicazione). Da ora ci riferiremo a questo codec con l'acronimo ND HP.
• On2 VP6 versione 6.2.7.0 (non ancora disponibile, integra alcune migliorie derivate dalla prossima applicazione di codifica della On2).
• RealNetworks RealVideo 10 (basato sul Helix DNA Producer versione 10.1.0.390 e su DLL ottimizzate). Da ora ci riferiremo a questo codec con l'acronimo RV10.
• Videosoft Codec Pro 2.2. Da ora ci riferiremo a questo codec con l'acronimo VSS.
  
• XviD 1.1 (compilata da CSV in data 19 dicembre 04)

Tutti i codec sono stati testati in una configurazione a doppia passata usando i settaggi suggeriti dagli stessi produttori.

Configurazione del Test:

Tutte le prove sono state condotte su questo hardware:

AMD Athlon 64 3500+
scheda madre Shuttle FN95 (parte del sistema "barebone" Shuttle SN95F5)
2x512MB PC3200 Kingston HyperX DDR RAM CL2
HIS Excalibur Radeon 9600 XT
Monitor Philips 230W5B2 su collegamento DVI

Per le codifiche ho usato il seguente software:

DGIndex 1.0.12 e DGDecode.dll
AviSynth 2.55 per il frameserving
VirtualDub 1.5.10 per la codifica (vedi in basso le eccezioni)
Nandub 1.0 RC2 "lumafix" per unire l'audio MP3 VBR
Helix DNA Producer 10.1 (versione numero 10.1.0.390)

Per codificare in RV10 ho usato AutoRV10. Per codificare in NeroDigital mi è stato fornito da ateme uno speciale encoder da linea di comando, che gestisce l'ingreasso da AviSynth (i beta tester del codec Main Profile conoscono di sicuro questo programmino).

I film che ho codificato:

Matrix Revolutions - Regione 1, NTSC, durata: 2h 09m, 185917 frames (@23.976 fps). Da ora in avanti mi riferirò a questo film come Matrix3
Salvate il Soldato Ryan - Regione 1, NTSC, durata: 2h 49m, 243770 frames (@23.976fps). Da ora in avanti mi riferirò a questo film come SPR.
Futurama "Seconda Stagione Primo Episodio" - Regione 2, PAL, durata: 0h 21m, 41271 frames (@25.00 fps)

Parametri di codifica:

Ho usato una traccia audio MP3 a 128kbit/s ABR creata con LAME 3.93 (usando il settaggio --alt-preset 128) per tutti i film, e ho quindi cercato di far stare Matrix3 su 1 solo CD da 700MB, SPR su 2 CD da 700MB e 4 episodi di Futurama su 1 solo CD da 700MB (il che costringeva il singolo episodio in 175MB). La dimensione finale della traccia audio è stata rispettivamente di 117'263 KB, 157'455 KB e 20'582 KB. Questo ha permesso di utilizzare un bitrate video effettivo di 621kbit/s per Matrix3, 1.016kbit/s per SPR e 987kbit/s per Futurama (dove kbit sta per 1000 bit). Ho usato GordianKnot per calcolare i bitrate (poichè è in grado di calcolare in modo preciso l'effettivo overhead che si ha usando tracce audio VBR MP3).

Dal momento che non è disponibile alcun codec VFW (Video for Windows) per i formati RV10 e ND, ho dovuto utilizzare flussi audio diversi con questi codec. Nel caso di NeroDigital ho usato l'encoder AAC dello stesso Nero per creare tracce audio CBR a 128kbit/s (nell'ordine: 122'481 KB, 160'441 KB e 20'489KB). E dal momento che NeroDigital utilizza il contenitore multimediale .MP4 ho dovuto anche fare dei calcoli sul bitrate particolari per questo codec. Ateme mi ha detto di attendermi un overhead di circa 10.4 byte per singolo frame, il che - dando per scontato che l'audio è a 128kbit/s (anche se poi ho scoperto che l'audio era leggermente più grosso e questo ha comportanto un leggero aumento anche del video - l'audio bitrate in Matrix3 era di 129.40 kbit/s mentre quello di SPR era di 129.27 kbit/s) - mi porta ad utilizzare 627kbit/s per Matrix3, 1025kbit/s per SPR e 1000kbit/s per Futurama. Nel caso di RV10, AutoRV10 si è fatto carico di calcolare in modo automatico i bitrate, e ho riutilizzato una traccia audio AAC a 128kbit/s, e quindi mi attendo che il bitrate di RV10 sia del tutto in linea con i valori di NeroDigital.

Dalla Microsoft invece mi han detto di usare valori differenti: 595 kbit/s per Matrix3, 1000 kbit/s per SPR e 900 kbit/s per Futurama. Per quanto ovvio ho chiesto perchè non potevo semplicemente usare i bitrate che mi ero calcolati, e mi è stato risposto che per raggiungere le dimensioni volute avrei dovuto usare i valori che mi stavano fornendo. Il che potrebbe anche dire che alla Microsoft non si fidano del proprio controllo sul flusso del bitrate...

Come già saprete, non tutti i meccanismi di controllo sul bitrate sono perfetti e quindi eccovi riepilogate le dimensioni finali delle mie codifiche:

Da notare che 700MB corrispondono a 716'800KB, 1400MB a 1'433'600KB e 175 MB sono 179'200 KB. Vi prego di notare che ho dato per scontato che VP6 utilizzasse la convenzione kbit = 1000 bit, e quindi i bitrate che mi ero calcolato per Matrix3 e SPR erano troppo alti (ho dovuto ricodificare Futurama ed ho quindi potuto correggere quell'errore). Le dimensioni finali effettive per il codec VP6 dovrebbero essere: 728'289 KB per Matrix3 e 1'452'626 KB per SPR (ma come vedete sono comunque ambedue notevolmente al di sopra dei valori limite). Ho messo il colore rosso quando si è andati oltre la dimensione voluta di più di 2.5 MB (2.5 MB è il valore medio di quanto si possa scrvere in più su un CD senza bisogno di ricorrere all'overburning). Il giallo intenso invece evidenzia i valori più bassi di oltre 2.5 MB dal limite cercato (e questo ci lascia supporre un problema col meccanismo di controllo del bitrate, ma è meno problematico dei file sovradimensionati).

Guardando la tabella vedete che 3ivX, DivX, HDX4, i due codec ND ed XviD raggiungo le dimensioni volute. RV10 esce un pelino sottodimensionato, ma ci sta comuque bene sui CD. VP6 invece restituisce valori eccessivamente sovradimensionati (a parte Futurama che - cosa interessante - era nei limiti la seconda volta che l'ho codificato - la prima volta era fuori di ben oltre 5 MB) e a questo livello di sviluppo non è molto adeguato come soluzione di backup dei DVD, almeno fintantochè On2 non sistema il proprio meccanismo di controllo sul bitrate. WMV9 è uscito per due volte sottodimensionato, in linea col bitrate più basso che ci era stato suggerito, ma è andato oltre i limiti voluti nel caso di SPR. Quindi, per impieghi specificatamente di backup, mi vedo costretto a segnare un mettere anche qui un bel punto interrogativo. VSS a sua volta ha un meccanismo di controllo del bitrate assai problematico e ha prodotto due risultati sovradimensionati e uno sottodimensionato.

Impostazioni dei Codec (indico i valori *diversi* da quelli standard del codec)

• 3ivX: B-frames ON, best quality for bitrate, MPEG quantizer con SPR (H.263 per gli altri due).
• DivX: profilo Home theater, modalità Balanced con 1-bframe per la prima passata, modalità Insane Quality per la seconda passata, quantizzazione H.263 ottimizzata e psychovisual: Shaping.
• HDX4: profilo Unrestricted, quantizzazione MPEG, QPel, 2 B-frame consecutivi, Quality: highest, Optimize for film source con Matrix3 e SPR, 1 B-frame e Quality:highest per Futurama.
• ND MP: codifica Cabac entropy, B-frames e weighted prediction ON, forza del filtro di deblocking: -2, numero massimo dei frame ri riferimento: 2, livello di psychovisual: 2, modalità cartoon (miglioramento sui colori) ON e numero massimo di B-frames consecutivi a 2 per Matrix3/SPR. Per Futurama, la forza del filtro di deblocking è stata aumentata a : +2 ed è stata disattivata la weighted prediction (le rimanenti impostazioni sono le stesse).
• ND HP: la trasformata 8x8 è attiva, off, 2 frame di riferimento, phsychovisual livello 2, massimo 2 B-frames consecutivi in Matrix3/SPR, e lo stesso per Futurama, ad eccezione della weighted prediction che è stata disattivata e la deblock strength che è stata portata a 2.
• RV10: impostazioni di default in AutoRV10 ad eccezione della modalità di scaling del rate control (impostata su linear) e Auto Select Best Quantizer per il filtro InLoop ceh è stata disattivata.
• VP6: VP62 Heightened Sharpness Profile con tutte le impostazioni standard. Per la seconda passata: Variability al 70%, Min Section a 60, Max Section a 800 e Two Pass Mode: Best quality.
• VSS: mi hanno mandato un file di configurazione lunghissimo e quindi non sono sicuro di quali siano le impostazioni standard e quali quelle modificate, ma eccovi quello che ho ritenuto degno di nota: QPel era attivo, è stato utilizzato il filtro di deblocking, la motion estimation lavora sul frame precedente e si è fatto uso della funzione Cabac.
• WMV9: impostazioni standard dall'inizio alla fine, ad eccezione per la maximum keyframe distance che è stata impostata a 20 secondi
• XviD: con Matrix3/SPR: quantizzazione MPEG, quantizzazione Trellis, attivi QPel, VHQ per i B-frames e Turbo. Per Futurama: B-frames disattivati, modalità Cartoon attiva e Trellis attivo.

Velocità di codifica:

Ho preso come come esempio la codifica di Matrix3. La risoluzione di SPR era superiore e per questo anche le performance sono state inferiori. Vi prego di notare che è il caso di prendere questi valori con un pizzico di grabo salis. Per le misurazioni sulla veloctà di codifca sono stati presi in esame solo i primi 10'000 frame e quindi la media globale dei frame per secondo potrebbe essere un filo differente. Inoltre NON ho riavviato / resettato il PC ad ogni rilevazione e NON ho fatto più rilevazioni per ogni singolo codec. Per dei valori assoluti ed attendibili, si sarebbe reso necessario un test più accurato ed approfondito, ma allo stesso tempo i valori riscontrati dovrebbero permettere di farvi un'idea piuttosto chiara delle velocità relative dei varii codec. Si noti anche che questi sono valori di media sulla doppia passata, dove possibile fare questa misurazione.

Mi sono concesso la libertà di creare 3 diverse categorie di velocità: più di 2 volte la velocità reale (verde), fra 1 e 2 volte la velocità reale (bianco) e sotto la velocità reale (rosso). Anche se la qualità è di certo ben più importante della velocità di codifica, alcuni codec hanno davero messo a dura prova la mia pazienza. Alla fine ho anche speso due parole in merito al rapporto che ci si può attendere fra la qualità e la velocità di codifica, e come i fatti sembrano confermare un'alta velocità non è necessariamente sinonimo di bassa qualità, e allo stesso modo una bassa velocità non significa automaticamente una maggior qualità.

Alcune tematiche meritevoli di essere approfondite: la modalità Insane di DivX, usata durante la seconda passata, ha determinato in modo particolare la bassa velocità raggiunta. Mi è stato detto di usare questa modalità, ma forse una modalità più rapida avrebbe permesso un giudizio complessivamente più attendibile senza per questo compromettere eccessivamente la qualità. Allo stesso modo anche con VP6 la modalità best quality avrebbe potuto essere rimpiazzata con quella standard senza andare incontro ad un significativo degrado della qualità. Inoltre fate attenzione ai due valori fra parentesi per i codec di NeroDigital: infatti questi valori sono l'effettivo framerate medio della codifica dell'intero film (che è stata perfezionata di notte senza alcun intervento manuale esterno). Scopriamo che ND aumenta progressivamente la velocità durante la prima passata e la piena velocità di codifica della prima passata si può avere solo codificando completamente il film (e come potete vedere l'impatto sulla media è notevole). Non sono in grado di spiegare il perchè di questa cosa (ma in effetti è una figata dato che riescono a superare i 100 fps di media della prima passata sul film completo) dato che si tratta, evidentemente, di un segreto ben custodito.

Altre cose importanti

Ecco lo script AviSynth che ho usato per codificare i film, in modo che possiate riprodurre in modo perfetto i miei stessi risultati. Ho usato force film con DGIndex sia per Matrix3 sia per SPR. Futurama era interlacciato e quindi ho usato la funzionalità FieldDeinterlace di Decomb, senza blending per ottenere un'immagine progressiva.

lo script di Matrix3:

LoadPlugin("C:\PROGRA~1\GORDIA~1\AviSynthPlugins\dgdecode.dll")
mpeg2source("D:\THE_MATRIX_REVOLUTIONS_D1\VIDEO_TS\matrix3.d2v")
crop(8,60,704,356)
LanczosResize(640,272)

lo script di SPR:

LoadPlugin("C:\PROGRA~1\GORDIA~1\AviSynthPlugins\dgdecode.dll")
mpeg2source("D:\SAVING_PRIVATE_RYAN\VIDEO_TS\spr.d2v")
crop(2,8,714,464)
LanczosResize(640,352)

lo script di Futurama:

LoadPlugin("C:\PROGRA~1\GORDIA~1\AviSynthPlugins\dgdecode.dll")
LoadPlugin("C:\PROGRA~1\GORDIA~1\AviSynthPlugins\decomb.dll")
mpeg2source("D:\FUTURAMA_SEASON_2_DISC_1\VIDEO_TS\futurama.d2v")
crop(10,4,702,568)
FieldDeinterlace(blend=false)
LanczosResize(640,480)

Riproduzione

Ho usato il filtro di decodifica standard per ogni singolo codec, attivando la funzionalità di "postprocessing" automatica ogniqualvolta fosse possibile. Con XviD ho attivato sia il deblocking sia il deringing, in HDX4 ho attivato il deblocking sui colori (chroma) e sulla luminosità (luma). Ho usato uno speciale filtro DirectShow fornitomi dalla ateme per la riproduzione di NeroDigital (visto che il filtro di Nero decodifica solamente i contenuti Main Profile - ancora una volta i beta tester potrebbero già aver utilizzato una versione precedente di questo fitro). Dove possibile, ho disabilitato l'effetto "film". Un appunto su questa cosa: la modalità di HDX4 "optimize for film" in realtà elimina la "grana da pellicola" durante la codifica, ne salva una rappresentazione matematica e la "riapplica" in fase di decodifica. Quindi questa volta ci troviamo con della "grana" evidente nei contenuti HDX4. Nelle prossime comparative mi attendo di vedere ulteriori implementazioni di questa tecnica dal momento che questo prcedimento è stato integrato nelle specifiche AVC High Profile.

Tutti i file sono stati recensiti utilizzando Media Player Classic visto che è in grado riprodurre sostanzialmente qualsiasi cosa gli facciate aprire. E in più questo player è in grado di collocarsi in modo preciso su un qualsiasi specifico frame del flusso video, una funzionalità questa che mi ha permesso di risparmiare SECOLI quando tiravo giù gli screenshot. Grazie Gabest per aver creato un player così potente!

Una nota in merito agli screenshot: diversamente da quello che potreste pensare dopo aver letto di questa magnifica funzione "go-to" di MPC, non è un compito facile prendere gli screenshot in modo appropriato. I seguenti codec di sono comportati in modo affidabile e prevedibile (nel senso che o non mostravano alcun "ritardo" e cioè prendendo il frame X dallo script di avisynth anche il frame X in MPC era lo stesso identico frame, oppure mostravano uno "spostamento" costante rispetto alla sorgente AviSynth): DivX, VP6, XviD. Ambedue le codifiche NeroDigital godevano di uno spostamento costante, ma ancora con dei problemi a livello di filtro di decodifica (non è possibile andare indietro di un frame alla volta). ateme mi ha promesso che sistemerà prima possibile questo problema. E ora giù di cazziatura: 3ivX e RV10 di solito si scostavano di ±1 frame, ma visto che questo valore continuava a cambiare sono stato costretto a prendere uno screenshot, compararlo col frame di riferimento (switchando molto velocemente da un frame all'altro nel visualizzatore di immagini), e tornare indietro a farne un altro se non era quello corrispondente. Ma le cose sono andate addirittura peggio con HDX4, VSS e WMV9. Prima parliamo di HDX4: stando a quanto dicono i produttori del codec, il problema è originato da una funzionalità che hanno introdotto per gestire i flussi MPEG-4 corrotti e che dovrebbe essere possibile disattivare in una prossima versione (e ci sarà una prossima comparativa in cui potranno provare queste loro affermazioni ;). Tutti e 3 questi codec hanno evidenziato problemi nel saltare al frame giusto. Se state visualizzando un film codificato con uno di questi codec, e agite sulla barra di avanzamento per spostarvi rapidamente in un altra parte del video, o vi beccate uno schermo nero fino al prossimo I-frame (HDX4), oppure vi dovete sorbire un'avanzamento rapido delle immagini fino al successivo I-frame (WMV9, VSS). Quando si è trattato di catturare degli screenshot questo ha voluto dire trovare l'I-frame immediatamente precedente al frame di cui volevo fare uno screenshot, avanzare quindi un frame alla volta fino a quando trovavo il frame voluto (e se non c'è un segno di distinzione davvero evidente fra il frame precedente e quello successivo è un'impresa TITANICA e sfiancante). Quindi alla fine diciamo che 3ivX, RV10, HDX4, WMV9 e VSS necessitano di essere migliorati per quanto riguarda il filtro di decodifica visto che mi sono costati letterlamente ore ed ore buttate alle ortiche solo perchè i loro filtri di decodifica non implementano tutte le funzionalità di ricerca che il formato DirectShow prevede (ti aspetti di poter sbrigare la faccenda screenshot in un tre quarti d'ora forse... ma allo stato delle cose gli screenshots mi han portato via ben più di 4 ore).

E come nota aggiuntiva: ho dovuto rifare parecchi screenshot a causa di un problema di conversione sui colori. Si scopre che il renderer video VMR9, che ho usato la volta scorsa per prendere gli screenshot, ha come effetto secondario una fastidiosa decolorazione. Per poter prendere screenshot da NeroDigital, ho dovuto installare nel sistema l'SDK DirectX per poter diporre di un nuovo renderer di default che integra un pulsante di "cattura video" direttamente all'interno delle proprietà del filtro. Ma, nonostate questo nuovo renderer non soffrisse più di problemi di decolorazione, alla fine ha comportato che la mia attività di cattura degli screenshot divenisse ancor più complessa e macchinosa: con tutti quei codec che non supportano una ricerca precisa al frame è stato necessario che utilizzassi la funzione di cattura video del renderer invece di quella nativa di MPC (utilizzando quella di MPC mi ritrovavo col keyframe immediatamente precedente!). Lo stesso è successo con RV10.

E ora andiamo avanti con primo test (versione JPEG a bassa occupazione di banda. Questa pagina carica 533KB di immagini all'inizio, mentre il peso complessivo delle immagini per l'intero test di Matrix3 è di 3.85 MB). Se avete parecchia banda oppure non vi secca aspettare, c'è anche una versione PNG a banda larga (che carica inizialmente 1.98 MB di immagini e se volete vedere tutte le immagini vi dovete scaricare qualcosa come 16.6 MB di dati...). Vi prego di notare che la versione a banda larga richiede che abbiate sufficiente memoria cache libera nel vostro browser oppure le immagini verranno ricaricate ogniqualvolta zoomate dentro e fuori.

Questa pagina è stata aggiornata il 28 dicembre 2004
Traduzione di babaz il 16 gennaio 2005