Xmpeg 4.2a
Xmpeg 4.2a è attualmente la versione più evoluta di flaskmpeg, derivata dalla versione "Flaskmpeg 06 Preview". La versione Xmpeg 4.2a risolve alcuni dei bug presenti nelle precedenti Xmpeg 4.1b, Xmpeg 4.2 e FlasKMPEG Xis ; rispetto alla "vecchia" 06 preview sono inserite nuove opzioni, prima tra tutte la modalità YUY.
A meno di conversioni particolari o incompatibilità con specifiche configurazioni HW, il mio consiglio è quello di utilizzare la Xmpeg 4.2a e di abbandonare del tutto le altre versioni, da utilizzare solo in caso di "soccorso".
Ecco alcune note sulla nuova versione Xmpeg4.2a che spero chiariscano alcuni legittimi dubbi che nascono dal suo uso: colgo " l'occasione " per parlare di alcune questioni quali quelle relative alle reali velocizzazioni ottenibili con i Pentium 4.
Riguardo le prossime versioni di Xmpeg, si parla già di una versione 4.3 o 4.5: ad oggi non ci sono notizie sulla data del rilascio.
La versione xmpeg 4.2a, con i plug-in che descrivo nell'articolo che segue la potete scaricare dal mio sito nella sezione download.
1) Utilizzo della modalità di decompressione YUV.
Xmpeg è in grado di utilizzare la modalità YUV.
Vi rimando all'articolo sul formato YUV, in cui descrivo i vantaggi e le velocizzazioni ottenibili con tale formato, con un particolare riferimento ad Xmpeg.
Riassumendo, ricordo come il formato colore la si setta in opzioni/opzioni globali progetto/post trattamento (tale possibilità è presente anche nella versione Mpeg Xis 3.0e Expert Edition V2).
RGB | |
YUV 4:2:2 (YUY2) | |
YUV 4:2:0 (YV12) |
I due casi più importanti sono la creazione di DivX;-) e DivX in cui occorre settare la modalità YUV 4:2:0 (YV12) e la catena XMPEG-->Video Server Plugin--> Cinema Craft Encoder stand alone in cui si deve utilizzare la modalità YUV 4:2:2 (YUY2) .
2) Xmpeg 4.2 è attualmente la versione più veloce, grazie alla ottimizzazione del codice e all'utilizzo della modalità di decompressione YUV.
I test che mi appresto a descrivere relativi alla velocità di xmpeg 4.2a, paragonata ad altre versioni di flaskmpeg e ad altri software di decompressione e conversione di DVD ( DVD2avi e Vidomi), sono tratti dall'aggiornamento sull'articolo che ho scritto sulle varie versioni di flaskmpeg, articolo che non ho ancora terminato ( non è on line) e da cui estrapolo i risultati dei test.
Ho utilizzato come video da
convertire , i primi 30 secondi (750 frame), del capitolo n 12 del DVD
Jurassic Park 2 caratterizzato da un mix di scene mediamente dinamiche. I risultati indicano la velocità media di 2 test successivi e sono stati ottenuti con il buon metodo del "cronometro manuale" , nel momento in cui spesso le statistiche indicate dai Sw sono poco attendibili e non tengono conto ad esempio dall'esatto istante in cui inizia la conversione. Il sistema di Test è un PC Pentium 2 400 Mhz, chipset 440BX, 256 MB di Ram Pc100, Hd IBM serie DTTA 14 GB, Matrox Marvel G200: ho da poco aggiornato la mia configurazione HW (ora utilizzo il velocissimo P4 1700 Mhz) e alcuni dei test che ho rifatto confermano in maniera proporzionale i risultati del test fatto con il Pentium II |
I test eseguiti sono i seguenti:
Visualizzazione 720*576
: la
sola visualizzazione ( i primi 30 sec del filmato) è finalizzata a valutare
1)
la velocità del SW per sola decodifica del Vob
2)
l'entità dell'accelerazione della decodifica in formato YUV piuttosto che RGB
(circa 30-40% nelle versioni di Flaskmpeg capaci di decodificare in modalità YUV).
3)
la differenza di velocità tra le 2 modalità possibili della decodifica YUV: la
YUY2 (16 bit per pixel) e la YV12 (12 bit per pixel)
4)
la velocizzazione dovuta al caso della sola decodifica senza visualizzazione
rispetto alla decodifica con visualizzazione. Tale velocizzazione, di circa il
25%, è dovuta alla mancanza del trasferimento del video decodificato verso la
scheda video, tramite AGP, con relativo disimpegno della CPU.
Nelle versioni di flaskmpeg della famiglia 0594 per la visualizzazione 720*576 ( senza ridimensionamento) è stata settata la modalità "Nearest Neighbour" a causa di un bug che in alcuni casi fa si che il filtraggio bilineare o bicubico è effettuato anche quando non viene ridimensionato il video, come nel caso del test.
Volendo fare un confronto tra DVD2avi e Xmpeg, occorre farlo riferendosi alla stessa modalità, ovvero la YUY2 in cui DVD2avi è più veloce di pochissimi punti percentuali (6-7%) del tutto trascurabili. Naturalmente se si elimina la visualizzazione ( in cui la responsabilità è delegata alla scheda video e al bus AGP) la massima velocità la si ha in modalità YV12 (21.2 fps in Xmpeg), segue la YUY2 (18.8 fps) e per ultimo la RGB (10.9). In presenza di visualizzazione, in cui la scheda video ha un ruolo importante la situazione tra le 2 modalita YUV si ribalta: con il mio sistema (Marvel g200, 8 MB, AGP 2X) la modalità nativa dell'mpeg , la YV12 (15.9 fps), è al contrario più lenta della YUY2 (17.1 fps).
Concludo ricordando come potendo scegliere, per le compressioni in Divx;-), Divx e mpeg 1 e 2, è sempre consigliabile utilizzare, se disponibile, la modalità YV12 . Attualmente ciò è possibile nella creazione di DivX e DivX;-) con Xmpeg e Flaskmpeg Xis : se si utilizza DVD2avi occorre utilizzare la YUY2 solo leggermente più lenta. Utilizzando la catena flaskmpeg-->avisynth-->Tmpeg, l'unica modalità possibile è la RGB.
Visualizzazione e ridimensionamento a 512*288 : questo test, fatto sempre sui primi 30 sec del filmato, è finalizzato a valutare la velocità dell'algoritmo di filtraggio-ridimensionamento: è stata utilizzata la modalità Bilinear Filtering ovunque tranne che per la versione Xmpeg 4.2a in cui si è scelto l'ottimo algoritmo "Bressenham" che produce una qualità leggermente superiore.
DivX;-) 3.11 512*288: é una delle possibili risoluzioni utilizzabili per il formato DivX;-) nel caso di film anamorfici 1.78:1 : si è scelto il codec low motion, bitrate 1000Kbits/s, key frame every 3 secondi, crispness=100, e audio 48 KHz Stereo PCM non compresso. Sono stati compressi 30 sec di video e il ridimensionamento con Flaskmpeg è stato fatto utilizzando la modalità bilinear e Bressenham per Xmpeg 4.2a.
DivX 4.11 512*288 medium : formato analogo al caso di prima, ma con il codec Divx 4.11. Per il video variable bitrate mode 1 pass, performance/quality = medium, Key frame = 300 e 1 pass encoding parameters di default (12,2,2000, 10,20); per l'audio 48 KHz Stereo PCM non compresso. Sono stati compressi 30 sec di video. Dove possibile si è scelta la modalità nativa YV12, la più veloce.
DivX 4.11 512*288 slowest : tutto analogo al caso di prima ma performance/quality = slowest, da utilizzare per conversioni di qualità .
XVCD 352*288 : l'mpeg 1 è stato creato tramite la catena Flaskmpeg--> avisynth-->Tmpeg v2.0. Come plug-in per avisynth si è utilizzata la versione 1.0 Beta 31 e come avisynth la versione 0.28 Beta 37. Con flaskmpeg il video è stato ridimensionato a 352*288 lasciandolo in anamorfico e si è scelto l'audio a 44.1 Hz; con tmpeg si è utilizzato il template "XVCD 352_288 2100 16_9.mcf" con bitrate video 2100 Kbits/s, motion search precision = normal e ovviamente video arrange method full screen.Sono stati compressi 30 sec di video
SVCD 480*288 : l'mpeg 2 è stato creato tramite la catena Flaskmpeg--> avisynth-->Tmpeg v2.0. Come plug-in per avisynth si è utilizzata la versione 1.0 Beta 31 e come avisynth la versione 0.28 Beta 37. Con flaskmpeg il video è stato ridimensionato a 480*432 convertendolo pertanto in non anamorfico (432 righe al posto di 576) e si è scelto l'audio a 44.1 Hz; con tmpeg si è utilizzato il template "SVCD Benny 4 3 CBR 2450-224.mcf" con bitrate video 2450 Kbits/s costante, motion search precision = normal e ovviamente video arrange method = center (custom size) 480*432. Sono stati compressi 20 sec di video.
In tutti i test è stata
deselezionata l'opzione
"mantieni rapporto altezza, larghezza" in coerenza con il tipo di codifiche
realizzate: tutte non anamorfiche tranne che per l'xvcd.
Riguardo la scelta della IDCT è stata utilizzata la versione MMX idct con
l'ottimizzazione di Miha dove presente detta nelle versioni 06, Xis e Xmpeg
optimized MMX IDCT
: per tutte le 2 versioni PX3 è stata utilizzata la non-MMX idct risultata sul
mio sistema leggermente più veloce. Tutte le versioni utilizzate per la IDCT,
soddisfano le specifiche IEEE-1180.
Come termine di paragone con metodi alternativi, ho inserito i risultati ottenuti facendo i medesimi test ma con DVD2avi 1.82 e vidomi 0403 entrambi capaci di decodificare vob e creare video divx e divX;-). Naturalmente i parametri utilizzati sono gli stessi. Per la creazione di SVCD e XVCD con DVD2avi ho utilizzato il metodo più veloce in termini di prestazioni: creazione con DVD2avi del file progetto.d2v e relativo wav; creazione dell'avi virtuale tramite VFAPIConv-EN.exe; creazione del frame server con virtualdub, responsabile del ridimensionamento con filtraggio bilineare; conversione con tmpeg collegato icon il frame server di Virtual Dub. (Osservo che l'utilizzo diretto del file d2v all'interno di Tmpeg produce conversioni parecchio più lente, 3.02 fps invece di 3.83 fps per XVCD e 1.80 fps al posto di 2.18 per i SVCD). Per il calcolo dei fotogrammi al secondo con DVD2avi ho sommato il tempo impiegato per la conversione e estrazione dell'audio ( operazione da fare nel primo passaggio) con quello impiegato per la compressione in DivX o mpeg.
Velocità espresse in fps, fotogrammi al secondo: in rosso il più veloce, in verde il più lento. |
|||||||
Decodifica senza ridimensionamento 720*576 |
Decodifica e ridimensionamento a 512*288 |
Divx;-) 3.11 512*288 |
Divx 4.11 512*288 Medium |
Divx 4.11 512*288 Slowest |
Xvcd 352*288 |
Svcd 480*576 |
|
Xmpeg 4.2a Modalita YUV Idct optimized-MMX |
17.1 YUY2 con
visualizz. |
13.1 | 7.53 | 7.37 | 6.38 | - | - |
Xmpeg 4.2a Modalita RGB Idct optimized-MMX |
11.1 | 11.7 | 6.35 | 6.36 | 5.57 | 3.98 | 2.13 |
FlaskMPEG Xis 3.0e
Expert Edition V2 Modalita YUV Idct optimized-MMX |
16.5
YUY2 con
visualizz. |
12.3 | 7.34 | 7.23 | 6.19 | - | - |
FlaskMPEG Xis 3.0e
Expert Edition V2 Modalita RGB Idct optimized-MMX |
10.9 | 11.2 | 6.22 | 6.09 | 5.38 | 3.95 | 1.99 |
FlaskMPEG v.0.6 Preview | 9.55 | 10.9 | 6.38 | 6.30 | 5.54 | 3.85 | 2.02 |
Flaskmpeg v.0594 PX3 s2v3 Miha Idct non-MMX | 10.3 | 12.4 | 6.79 | 6.75 | 5.91 | 4.04 | 2.09 |
Flaskmpeg v.0594 PX3 004e Idct non-MMX | 8.82 | 10.7 | 6.20 | 6.12 | 5.40 | 3.80 | 2.02 |
Flaskmpeg v.0594 Miha Idct MMX | 8.15 | 9.55 | 5.84 | 5.70 | 5.12 | 3.57 | 1.96 |
Flaskmpeg v.0594 decss Idct MMX | 6.88 | 7.57 | 5.51 | 5.44 | 5.05 | 3.32 | 1.87 |
DVD2avi v.1.82 Modalita YUV2 |
18.4
YUY2 con
visualizz. |
11
con visualizz. |
6.60 | 6.42 | 5.62 | - | - |
DVD2avi v.1.82 Modalita RGB |
11.9
con visualizz. |
7.4
con visualizz. |
- | - | - | 3.83 | 2.18 |
Vidomi 0403 Modalita RGB | - | - | 7.04 | 6.88 | 5.96 | - | - |
Vidomi 0403 Modalita YUV | - | - | 7.14 | 6.95 | 6.03 | - | - |
Nel grafico per non appesantire la visibilità, ho inserito solo i valori relativi alla opzione YUV (YUY2) dove disponibile, trascurando i valori inferiori, ottenuti in modalità RGB (non ha alcun senso usare la modalità RGB nella creazione di DivX;-) e Divx, che in tutti i casi operano in modalità YUV): naturalmente per la 06 preview e per le versioni 0594 ho necessariamente utilizzato la modalità RGB, unica disponibile.
E' evidente come all'aumentare
della complessità nella compressione rispetto a quella della decompressione (e
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;-) 512*288, molto rapido da comprimere in cui i
vantaggi delle versioni più veloci sono evidenti poichè la CPU impiega una buona
percentuale del suo tempo nella decodifica e le velocizzazioni di Xmpeg 4.2a
diventano importanti; all'opposto si ha il SVCD 480*576 a cui ad una lentezza
nella compressione seguono guadagni marginali: le velocità sono tra loro molto
simili.
Dalla analisi globale delle velocità ottenute è vincitore praticamente ovunque Xmpeg 4.2a: l'incremento di prestazioni è ancora più evidente quando è utilizzata la modalità YUV.
Vediamo i risultati ottenuti utilizzando un sistema Pentium 4 1700 Mhz, 384 MB Sdram PC133, Chipset Intel i845, HD IBM 60 GXP, Matrox G450 : come versione di Flaskmpeg è stata utilizzata la Xmpeg 4.2a con la optimized MMX IDCT che è risultata la più veloce anche su P4 ; Xmpeg è stato settato con il ridimensionamento tramite filtraggio Bressenham; per la compressione in Mpeg ho utilizzato la versione tmpeg 2.01 ottimizzata per il processore Pentium 4.
Come riferimento in termini di frequenza di clock , il fattore di paragone è X 4.25 (1700/400=4,25). Se il P4 andasse più veloce del P2 in maniera proporzionale alla frequenza, e se trascurassimo tutti i tempi dovuti alle altre attivita (HD, scheda video,..) la medesima operazione sarebbe eseguita nel P2 400Mhz con un tempo 4.25 volte maggiore rispetto al P4 1700Mhz. Vediamo dove e se tale accelerazione si è verificata.
Velocità espresse in fps, fotogrammi al secondo |
||||||||
Decodifica senza ridimensionamento 720*576 YV12 |
Decodifica senza ridimensionamento 720*576 RGB |
DVD-->Divx 4.02 512*288 Slowest |
DVD-->Divx 4.12 |
DVD-->Xvcd 352*288 |
DVD-->Svcd 480*576 |
DV-->DVD 720*576 |
||
Pentium 4 1700 Mhz |
45,5 | 26.3 | 17.8 | 21.8 | 16.1 | 9.50 | 7.57 | |
Pentium 2 400 Mhz |
15,9 | 10.9 | 6.18 | 6.10 | 3.88 | 1.97 | 1.35 | |
Velocità |
X 2.86 | X 2.41 | X 2.88 | X 3.57 | X 4.15 | X 4.80 | X 5.61 |
La prima osservazione da
fare è che ho effettuato il confronto utilizzando sia la versione DivX 4.02 non
ottimizzata per le istruzioni SSE2 del P4, e sia la DivX 4.11 qualitativamente
identica alla 4.02 ma ottimizzata per P4 grazie all'uso delle istruzioni SSE2:
l'incremento di prestazioni è stato del 22.5%: sul sito del DivX si parla di una
velocizzazione massima del 75% che si ottiene nella pura compressione di un avi
in formato YUV; nel caso della conversione DVD--->DivX naturalmente occorre
considerare l'impiego della CPU nella decodifica del vob e nelle operazioni di
ridimensionamento, entrambe eseguite da Xmpeg per giustificare "solo" la
velocizzazione del 22.5%.
Nell'ultima colonna ho inserito una conversione in cui come materiale d'origine
ho utilizzato lo stesso video di jurassic Park2 ma in formato DV, e ho creato un
file mpeg 2 nello standard DVD (720*576 bitrate video 6000 Kbits/s costanti,
compressione interallacciata). Lo
scopo è quello di valutare il tipo di accelerazione che si ha nel passaggio
dalla piattaforma Pentium 2 a Pentium4 nell'uso intensivo di tmpeg 2.01: è
evidente come tale sw è fortemente ottimizzato per p3 e p4 grazie all'uso
intensivo delle istruzioni SSE e SSE2.
Tmpeg 2.01 è fortemente ottimizzato per Pentium 4: non utilizzando le istruzioni SSE2, non disponibili ad esempio con i Pentium 3 e i nuovi Athlon XP si ha una diminuzione di velocità di circa il 20%; nella conversione DV-->DVD (risoluzione 720*576) si passa da 7,57 a 6,35fps. Per fare dei test basta andare in option/envir.setting/CPU e deselezionare SSE-2: naturalmente il test lo può fare solo chi possiede un P4: per le altre CPU l'opzione SSE-2 non è selezionabile.
|
|
La conclusione è
abbastanza ovvia: utilizzando il Pentium 4 in tutti i sw non ottimizzati per
tale piattaforma e in particolare che non sfruttano le istruzioni SSE e SSE2, si
ottengono discreti aumenti di velocità, INFERIORI RISPETTO ALL'INCREMENTO DI
FREQUENZA PARI A 4,25 .
Flaskmpeg e il codec DivX 4.02 , non contengono infatti routine scritte
appositamente per tale processore.
Nella conversione "ibrida" in DivX 4.11 in cui si ha il contributo non
ottimizzato di Xmpeg e quello ottimizzato del codec DivX, si ottiene una
velocizzazionwe quasi pari all'aumento di Clock. Al top della velocizzazione
c'è l'utilizzo intenso di Tmpeg, ottimizzato per P3 e P4, che riesce nelle sue
conversioni A PAREGGIARE E SUPERARE L'INCREMENTO DELLA FREQUENZA DI CLOCK, sino
all'incremento di un fattore 5,6 nella conversione DV-->DVD, in cui la quasi
totalità dell'impegno della CPU è la compressione ( la sola decompressione del
formato DV è molto più "leggera" rispetto alla decodifica e ridimensionamento di
un Vob eseguita da Flaskmpeg).
Nelle conversioni video spesso ci si riferisce al fattore REAL TIME (RT), ovvero al multiplo del tempo che occorre per la conversione ; ad esempio
1 RT --->
1 minuto di video convertito in 1 minuto, 1 ora in un'ora,......
2.3 RT ---> 1 minuto di video convertito in 2.3 minuti (2:18) , 1 ora in 2.3 ore
(2:18:00)......
10 RT ---> 1 minuto di video convertito in 10 minuti , 1 ora in 10 ore,...
Il fattore real time lo si calcola nel caso di video Pal, RT=25/fps dove 25 deriva dal numero dei fotogrammi al secondo del sistema Pal e fps è la velocità in fotogrammi al secondo.
Ottengo
Divx 4.12 512*288 Slowest |
Xvcd 352*288 |
Svcd 480*576 |
DVD 720*576 |
|
P4 1700 Mhz |
1.14 RT | 1.55 RT | 2.6 RT | 3.3 RT |
P2 400 Mhz |
4.10 RT | 6.44 RT | 12.7 RT | 18.5 RT |
3) I plug-in avi output e i problemi con Windows 98/98SE
Una dei bug non ancora risolti nella nuova versione Xmpeg, è la incompatibilità
del plug-in fornito di serie nella distribuzione di Xmpeg 4.2a con Windows
98/98SE: al contrario nessun problema con Windows XP ( e suppongo NT).
La premessa è che ho testato il plug-in in esame su 3 computer, tutti in ambiente Windows 98: tutti hanno manifestato lo stesso problema. Vediamo con esattezza i termini della questione.
Per creare con Xmpeg degli AVI e in particolare per creare DivX o DivX;-), sin dalla prima versione di Flaskmpeg vengono utilizzati dei semplici plug-in che si collegano al software e permettono la creazione del file avi oltre che l'immissione dei parametri.
Con Xmpeg 4.2a viene fornito
l'avi plug-in 2.5 che come novità introduce la possibilità di comprimere
l'audio direttamente tramite il codec mp3 Fraunhofer senza la presenza di
asincronismi audio-video: basta selezionare il plug-in ( seleziona il
formato d'uscita/ aviplug-in ) e selezionare l'opzione "compensate F...mp3
codec bug. Sconsiglio la High quality compression che rallenta la
compressione in mp3 senza particolari vantaggi qualitativi. |
|
L'altra novità del nuovo plug-in è la presenza di un "compression tracer" che durante la compressione diagramma l'andamento del bitrate |
|
e mostra delle statistiche sul bitrate medio ottenuto, velocità di conversione,...... Durante la compressione conviene comunque lasciare la finestra delle statistiche (a destra) e non l'andamento grafico del bitrate che rallenta la conversione. |
|
Il problema dell'avi
plug-in 2.5 è che è un divoratore di risorse grafiche: se si effettua una
conversione che utilizza tale plug-in (tipicamente la creazione di un DivX)
con il sistema operativo
Windows 98/98SE e quasi
certamente ME, le risorse GDI (parte della memoria del sistema utilizzata dal
sistema operativo per l'interfaccia grafica) inesorabilmente diminuiscono sino
all'esaurimento. A quel punto
l'intera la conversione si blocca, interfaccia grafica collassa, si è costretti
a chiudere il programma e molte volte a riavviare il sistema operativo. Il plug-in 2.5 al contrario funziona senza problemi con windows XP e quasi certamente on Windows NT entrambi privi di limitazioni sulle risorse GDI. |
La soluzione al problema è semplice: se si lavora con Windows 98/98SE, occorre utilizzare la vecchia versione 2.3 del plug-in.
La versione di Xmpeg 4.2a che trovate nel mio sito contiene infatti 2 diversi avi plug-in:
Versione plug-in | Nome File | Dimensione File | plug-in da selezionare in opzioni / seleziona il formato d'uscita | Note | |
Avi plug-in 2.5 | AVIPlugin.cm.Xmpeg | 249 856 | Avi plug-in |
Inutilizzabile con W98/98Se. Perfettamente funzionante con Windows XP Compatibile con la modalità YUV |
|
Avi plug-in 2.3 | odmlavioutput.cm.Xmpeg | 196 608 | Open DML Avi Output (RGB, YUV) |
Perfettamente funzionante con Windows XP, 98 e 98SE Compatibile con la modalità YUV |
Per utilizzare il plug-in desiderato basta selezionarlo in opzioni / seleziona il formato d'uscita : in rosso i 2 plug-in visti ( i numeri delle versioni, in rosso, ovviamente sono stati aggiunti )
A chi chi utilizza Xmpeg all'interno di Windows XP, il mio consiglio è quello di usare l'Avi plug-in 2.5 ed eventualmente cancellare il file odmlavioutput.cm.Xmpeg . A chi chi utilizza Xmpeg all'interno di Windows 98/98SE (e credo anche Windows ME) , il mio consiglio è quello di usare l'Avi plug-in 2.3 ed eventualmente cancellare il file AVIPlugin.cm.Xmpeg . |
Osservo come la vecchia versione Avi plug-in 0.58 (incompatibile tra l'altro,
con la modalità YUV e con la compressione diretta in mp3)
fornito come standard nelle versioni flaskmpeg 0,594, non può essere usato a
causa di una incompatibilità: chiudendo Xmpeg4.2a, dopo aver usato tale plug-in,
va in crash l'intero sistema operativo: naturalmente tale versione del plug-in
non la fornisco nella mia distribuzione di Xmpeg.
4) Come selezionare il punto d'inizio e fine conversione e garantirsi che l'intero intervallo sia convertito.
Chi non ha mai utilizzato una versione della "famiglia" Flaskmpeg 06 o Xmpeg, può avere difficoltà a fare una conversione partendo da un punto diverso dall'inizio e di garantirsi che l'intervallo selezionato sia interamente convertito. Al contrario può succedere che la conversione prosegue indefinitivamente creando da un certo punto in poi solo video nero. Vediamo i termini del problema.
Vediamo prima di tutto come selezionare l'intervallo del filmato che si vuole convertire: caricato il filmato ( DVD video, mpeg 1 o 2,....) , click destro su un qualsiasi punto blu del player e click su . Poi si sceglie il punto d'inizio conversione spostandosi con o con la rotellina del mouse, nuovamente click destro su un qualsiasi punto blu del player e click sinistro su ; stesso discorso per selezionare il punto in cui terminerà la conversione (occorre cliccare su)
La selezione sarà evidenziata con un colore diverso: come ultima cosa click destro su un qualsiasi punto blu del player e click sinistro su .
Se l'operazione descritta non viene effettuata, è di default selezionato l'intero filmato.
Importante Dopo aver eventualmente selezionato graficamente l una parte da convertire, o aver selezionato l'intero video: - se si utilizza un AVI plug-in ( vedi il caso della conversione in DivX) , il Ligos Plug-in o il BBmpeg plug-in, per garantirsi che tutto l'intervallo selezionato sia convertito occorre settare in opzioni globali progetto( settaggio film)/generali/compila l'intero file (più correttamente l'opzione si sarebbe dovuta chiamare, "compila l'intero intervallo".) Se si seleziona una
durata ( in secondi o immagini) inferiore all'intervallo scelto , verrà
convertita la durata indicata a partire dall'inizio selezione; il punto di fine
selezione non sarà mai raggiunto. In pratica se ad esempio seleziono 5 minuti di filmato e indico di convertirne 2, saranno convertiti solo 2 minuti; se seleziono 5 minuti di filmato e indico di convertirne 10, saranno convertiti solo i 5 selezionati; - se si utilizza un plug-in del tipo avisynth o videoserver, il punto di fine selezione sarà sempre ignorato ( non conviene pertanto neanche settarlo) ma l'intervallo da convertire deve essere indicato settando graficamente (come visto) il punto di inizio della conversione mentre l'intervallo da convertire lo si inserisce in opzioni globali progetto(settaggio film)/generali esprimendolo in secondi o immagini (per il video PAL Immagini=secondi*25). Con i plug-in tipo "avisynth" o "videoserver" non bisogna mai settare compila l'intero file . Se sbagliando si inserisce "compila l'intero file", terminato il filmato Xmpeg fornirà una serie di fotogrammi neri al software collegato tramite avisynth che se non è bloccato dall'utente creerà alla coda del filmato un filmato nero e muto !!! La seconda conseguenza sta nelle stime de tempo di compressione tutto sbagliate: 600-700 ore (roba da XT a 4.77 Mhz !!!) Il motivo di
questo diverso comportamento sta nel fatto che quando si setta graficamente
l'inizio e la fine della conversione, Xmpeg non conosce la durata in fotogrammi
dell'intervallo scelto, ma solo il punto del file da cui iniziare la conversione
e il punto dove finirla (sono degli offset).
- se si utilizza un plug-in tipo avisynth o video server si deve settare graficamente solamente il punto di inizio conversione ( di defoult è l'inizio del video) e settare in opzioni globali progetto( settaggio film)/generali/ il numero di fotogrammi o la durata in secondi di quanto si vuole convertire. - se si utilizza un AVI plug-in ( vedi il caso della conversione in DivX) , il Ligos Plug-in o il BBmpeg plug-in si può procedere come appena visto: come alternativa è possibile settare graficamente l'intervallo da comprimere ( inizio e fine) e settare in opzioni globali progetto( settaggio film)/generali l'opzione compila l'intero file. |
5) Xmpeg 4.2a e il plug-in CCE Encoder 2.62/2.64
A prima vista può sembrare che tali plug-in, capaci di creare video mpeg1/2, siano incompatibili con Xmpeg: ciò deriva dal fatto che la compressione viene effettuata correttamente, ma al suo termine si ottiene un video di dimensione 0.
Il tutto nasce da una leggera incompatibilità che si risolve facilmente: al termine della compressione l'encoder CCE crede di dover ancora modificare l'mpeg creato che rimane ancora "aperto" e non è accessibile da altri software: ad esempio non è osservabile con il media player , cosa opinabile visto che è sempre buona cosa visualizzare l'mpeg appena creato !!!.
Il bug si risolve
semplicemente chiudendo Xmpeg al termine della conversione: da quel momento in
poi il file è accessibile e può essere tranquillamente visionato, elaborato,
copiato....
Osservo come CCE non aggiunge l'estensione al file e
pertanto conviene farlo all'interno di Xmpeg, chiamando il video da convertire
ad esempio test. mpg e non semplicemente test.
Riguardo alla qualità di CCE vi rimando all'articolo che ho scritto sugli encoder mpeg1-2.
Per chi vuol fare dei
test, il mio consiglio è di utilizzare la catena Xmpeg---> videoserver--> CCE
stand alone: i vantaggi sono notevoli: maggiore velocità grazie alla modalità
YUV impossibile con il plug-in ( sul mio sistema la velocizzazione è del 5% per
gli XVCD e 8% per i SVCD); possibilità di creare video con bitrate
variabile e audio ( anche ciò impossibile con il plug-in).
Altra stranezza ( almeno sul mio sistema): per potere utilizzare CCE encoder
stand alone e Xmpeg, da collegare con la catena Xmpeg---> videoserver--> CCE
stand alone, occorre aprire prima CCE e poi XMPEG ; al contrario se si esegue
xmpeg, diventa impossibile avviare CCE encoder (dopo aver doppio cliccato sul
programma, questo semplicemente non si apre). Non escludo che sia un problema
relativo al mio PC, a causa di strani conflitti tra i sw installati.
6) I
parametri di ridimensionamento per creare correttamente i SVCD.
Per creare i SVCD-XVCD tramite la catena xmpeg-->avisynth-->tmpeg o xmpeg-->videoserver-->tmpeg
basta seguire le indicazioni che trovate
nell'articolo che ho dedicato al SVCD.
Vediamo come settare i paramentri quando si utilizza tmpeg ( è una ricapitolazione di quello che trovate nell'articolo); seguono poi le tabelle relative al caso in cui non si utilizza tmpeg, ma un plug-in di compressione mpeg1/2, quali BBmpeg, CCE encoder plug-in, LSX plug-in o tramite le catene Xmpeg-->videoserver-->ENCODER o Xmpeg-->avisynth--->Encoder, dove per Encoder intendo un qualsiasi encoder mpeg compatibile con il video-server (in pratica tutti) o avisynth: LSX encoder stand alone, CCE encoder stand alone.
Attenzione a non confondere il formato anamorfico o meno dei DVD che dipende ovviamente da chi ha realizzato il DVD, con il formato anamorfico o meno del SVCD/XVCD che si vuole creare che è una scelta di chi crea la conversione. Sull' articolo dedicato al SVCD sono indicati i casi in cui può essere opportuno fare SVCD/xvcd anamorfici.
Creazione di XVCD/SVCD/XSVCD NON ANAMORFICI con Tmpeg Ricordo come gran parte (85-90%) dei DVD di film 1,85:1 e 2.35:1, sono anamorfici; tutti i DVD in formato 4:3 e solo alcuni film 1,85:1 e 2.35:1 sono non anamorfici |
|||||||
|
|
Parametri Xmpeg |
Parametri Tmpeg |
||||
N. |
Conversione |
Opzioni/opzioni globali
progetto/post trattamento
(osservo come poichè negli esempi che seguono si deseleziona Mantieni rapporto alt/largh i parametri pixel aspect e aspect ratio sono ininfluenti) |
Opzioni/opzioni globali
progetto/video. Le dimensioni possono essere settate graficamente anche in "mostra pannello d'uscita/ dimensioni di uscita" |
Setting/video (risoluzione dell'mpeg da creare) |
Setting/advanced/Video arrange Method | ||
1 |
DVD anamorfico-->Svcd 480*576 non anamorfico |
|
|
||||
2 |
DVD anamorfico-->Svcd 352*576 non anamorfico |
stessi parametri del caso N.1 |
Dimensione
della cornice |
Size 352X576 Aspect ratio 4:3 display |
Video
arrange Method=Center(custom size) |
||
3 |
DVD anamorfico-->Svcd 704*576 non anamorfico |
stessi parametri del caso N.1 |
Dimensione
della cornice |
Size 704X576 Aspect ratio 4:3 display |
Video arrange Method=Center(custom
size) 704X432 |
||
4 |
DVD anamorfico-->Svcd 720*576 non anamorfico |
stessi parametri del caso N.1 |
Dimensione
della cornice |
Size 720X576 Aspect ratio 4:3 display |
Video arrange Method=Center(custom
size) 720X432 |
||
5 |
DVD anamorfico-->Svcd 352*288 non anamorfico |
stessi parametri del caso N.1 |
Dimensione
della cornice |
Size 352X288 Aspect ratio 4:3 display |
Video arrange Method=Center(custom
size) 352X216 |
||
6 |
DVD non anamorfico-->Svcd 480*576 non anamorfico |
stessi parametri del caso N.1 |
Dimensione
della cornice Larghezza=480 Altezza = 576 |
Size 480X576 Aspect ratio 4:3 display |
|
||
7 |
DVD non anamorfico-->Svcd 352*576 non anamorfico |
stessi parametri del caso N.1 |
Dimensione
della cornice |
Size 352X576 Aspect ratio 4:3 display |
stessi parametri del caso N.6 |
||
8 |
DVD non anamorfico-->Svcd 704*576 non anamorfico |
stessi parametri del caso N.1 |
Dimensione
della cornice |
Size 704X576 Aspect ratio 4:3 display |
stessi parametri del caso N.6 |
||
9 |
DVD non anamorfico-->Svcd 720*576 non anamorfico |
stessi parametri del caso N.1 |
Dimensione
della cornice |
Size 720X576 Aspect ratio 4:3 display |
stessi parametri del caso N.6 |
||
10 |
DVD non anamorfico-->Svcd 352*288 non anamorfico |
stessi parametri del caso N.1 |
Dimensione
della cornice |
Size 352X288 Aspect ratio 4:3 display |
stessi parametri del caso N.6 |
Creazione di XVCD/SVCD/XSVCD ANAMORFICI con Tmpeg Ricordo come gran parte (85-90%) dei DVD di film 1,85:1 e 2.35:1, sono anamorfici. Non considero il caso di XVCD/SVCD anamorfici, partendo da DVD non anamorfici, poichè la cosa non avrebbe molto senso.
Ricordo inoltre che
creando XVCD/SVCD anamorfici, l'opzione di Tmpeg "Aspect ratio 16:9 display"
semplicemente inserisce nel flusso mpeg un byte che comunica al player
di ridimensionare il video nelle giuste proporzioni: ciò funziona in alcuni
DVD player software per Pc (vedi powerdvd) ma quasi sempre non produce
effetto sui DVD player stand alone, che al contrario pasticciano il video
(in realtà i DVD player dovrebbero lasciare il video in anamorfico se in
uscita hanno una TV 16:9 e ridimensionare il video se in uscita hanno un TV
4:3) . In tal caso può essere opportuno lasciare Aspect ratio 4:3 display e
utilizzare manualmente l'opzione 16:9 sui TV 4:3 ( se disponibile) e
impostare la modalità 16:9 (nessuno zoom) sui TV 16:9 che a causa della loro
forma sono predisposti nativamente a visualizzare video anamorfico |
|||||||
|
|
Parametri Xmpeg |
Parametri Tmpeg |
||||
N. |
Conversione |
Opzioni/opzioni globali
progetto/post trattamento
(poichè negli esempi che seguono si deseleziona Mantieni rapporto alt/largh i parametri pixel aspect e aspect ratio sono ininfluenti) |
Opzioni/opzioni globali
progetto/video. Le dimensioni possono essere settate graficamente anche in "mostra pannello d'uscita/ dimensioni di uscita" |
Setting/video (risoluzione dell'mpeg da creare) |
Setting/advanced/Video arrange Method | ||
11 |
DVD anamorfico-->Svcd 480*576 anamorfico |
|
|
||||
12 |
DVD anamorfico-->Svcd 352*576 anamorfico |
stessi parametri del caso N.11 |
Dimensione
della cornice |
Size 352X576 Aspect ratio 16:9 display |
stessi parametri del caso N.11 | ||
13 |
DVD anamorfico-->Svcd 704*576 anamorfico |
stessi parametri del caso N.11 |
Dimensione
della cornice |
Size 704X576 Aspect ratio 16:9 display |
stessi parametri del caso N.11 | ||
14 |
DVD anamorfico-->Svcd 720*576 anamorfico |
stessi parametri del caso N.11 |
Dimensione
della cornice |
Size 720X576 Aspect ratio 16:9 display |
stessi parametri del caso N.11 | ||
15 |
DVD anamorfico-->Svcd 352*288 anamorfico |
stessi parametri del caso N.11 |
Dimensione
della cornice |
Size 352X288 Aspect ratio 16:9 display |
stessi parametri del caso N.11 |
Vediamo come settare i parametri se si desidera creare un XVCD/SVCD/XSVCD tramite Xmpeg con un plug-in di compressione mpeg1/2, quali BBmpeg, CCE encoder plug-in, LSX plug-in o tramite le catene Xmpeg-->videoserver-->ENCODER o Xmpeg-->avisynth--->Encoder, dove per Encoder intendo un qualsiasi encoder mpeg compatibile con il video-server (in pratica tutti) o avisynth: LSX encoder stand alone, CCE encoder stand alone .
Osservo che per utilizzare un plug-in encoder con Xmpeg, occorre installare normalmente l'encoder che inserirà il plug-in nella directory plug-in di premiere; occorre poi copiare tale plug-in
Creazione di XVCD/SVCD/XSVCD NON ANAMORFICI con un encoder plug-in (BBmpeg, Lsx encoder,...) o con la catena Xmpeg-->videoserver (o avisynth)-->ENCODER Ricordo come gran parte (85-90%) dei DVD di film 1,85:1 e 2.35:1, sono anamorfici; tutti i DVD in formato 4:3 e solo alcuni film 1,85:1 e 2.35:1 sono non anamorfici |
|||||
|
|
Parametri Xmpeg |
Parametri Encoder |
||
N. |
Conversione |
Opzioni/opzioni globali
progetto/post trattamento
(attenzione a settare correttamente pixel aspect 1:1) |
Opzioni/opzioni globali
progetto/video. Le dimensioni possono essere settate graficamente anche in "mostra pannello d'uscita/ dimensioni di uscita" |
Risoluzione video mpeg da creare (non si può impostare nei plug-in , che utilizzano il valore impostato in Xmpeg) |
Aspect ratio |
16 |
DVD anamorfico-->Svcd 480*576 non anamorfico |
480 X 576 |
CCIR601 625 (per gli mpeg 1 con il LSX e BBmpeg) |
||
17 |
DVD anamorfico-->Svcd 352*576 non anamorfico |
Dimensione
della cornice |
352X576 | stessi parametri del caso N.16 | |
18 |
DVD anamorfico-->Svcd 704*576 non anamorfico |
stessi parametri del caso N.16 ma con il valore 0,61 al posto di 0,90 |
Dimensione
della cornice |
704X576 | stessi parametri del caso N.16 |
19 |
DVD anamorfico-->Svcd 720*576 non anamorfico |
stessi parametri del caso N.16
ma con il valore
0,60
al posto di 0,90. Come alternativa è possibile inserire |
Dimensione
della cornice |
720X576 | stessi parametri del caso N.16 |
20 |
DVD anamorfico-->Svcd 352*288 non anamorfico |
stessi parametri del
caso N.16 ma con il valore
0,61
al posto di 0,90. Come alternativa è possibile inserire |
Dimensione
della cornice |
352X288 | stessi parametri del caso N.16 |
21 |
DVD non anamorfico-->Svcd 480*576 non anamorfico |
Attenti a DESELEZIONARE mantieni rapporto alt/largh. Pixel aspect è ininfluente |
Dimensione
della cornice Larghezza=480 Altezza = 576 |
480X576 |
stessi parametri del caso N.16 |
22 |
DVD non anamorfico-->Svcd 352*576 non anamorfico |
stessi parametri del caso N. 21 |
Dimensione
della cornice |
352X576 | stessi parametri del caso N.16 |
23 |
DVD non anamorfico-->Svcd 704*576 non anamorfico |
stessi parametri del caso N. 21 |
Dimensione
della cornice |
704X576 | stessi parametri del caso N.16 |
24 |
DVD non anamorfico-->Svcd 720*576 non anamorfico |
stessi parametri del caso N. 21 |
Dimensione
della cornice |
720X576 | stessi parametri del caso N.16 |
25 |
DVD non anamorfico-->Svcd 352*288 non anamorfico |
stessi parametri del caso N. 21 |
Dimensione
della cornice |
352X288 | stessi parametri del caso N.16 |
Riguardo i valori "Aspect ratio- custom" ad esempio nel caso 16, il valore (0,9 deriva dal rapporto 432/480 dove 432=576 righe*0.75 in cui 0.75 è il fattore di conversione video anamorfico-video non anamorfico. Nel caso di SVCD 352*576 1,23 deriva da 432/352= 1.227.
Termino con l'ultimo caso,
Creazione di XVCD/SVCD/XSVCD ANAMORFICI con un encoder plug-in (BBmpeg, Lsx encoder,...) o con la catena Xmpeg-->videoserver (o avisynth)-->ENCODER Ricordo come gran parte (85-90%) dei DVD di film 1,85:1 e 2.35:1, sono anamorfici. Non considero il caso di XVCD/SVCD anamorfici, partendo da DVD non anamorfici, poichè la cosa non avrebbe molto senso . Ricordo inoltre che creando XVCD/SVCD anamorfici, l'opzione di Tmpeg "Aspect ratio 16:9 display" semplicemente inserisce nel flusso mpeg un byte che comunica al player di ridimensionare il video nelle giuste proporzioni: ciò funziona in alcuni DVD player software per Pc (vedi powerdvd) ma quasi sempre non produce effetto sui DVD player stand alone, che al contrario pasticciano il video (in realtà i DVD player dovrebbero lasciare il video in anamorfico se in uscita hanno una TV 16:9 e ridimensionare il video se in uscita hanno un TV 4:3) . In tal caso può essere opportuno lasciare Aspect ratio 4:3 display e utilizzare manualmente l'opzione 16:9 sui TV 4:3 ( se disponibile) e impostare la modalità 16:9 (nessuno zoom) sui TV 16:9 che a causa della loro forma sono predisposti nativamente a visualizzare video anamorfico |
|||||
|
|
Parametri Xmpeg |
Parametri Encoder |
||
N. |
Conversione |
Opzioni/opzioni globali
progetto/post trattamento
(poichè negli esempi che seguono si deseleziona Mantieni rapporto alt/largh i parametri pixel aspect e aspect ratio sono ininfluenti) |
Opzioni/opzioni globali
progetto/video. Le dimensioni possono essere settate graficamente anche in "mostra pannello d'uscita/dimensioni di uscita" |
Risoluzione video mpeg da creare (non si può impostare nei plug-in, che utilizzano il valore impostato in Xmpeg) |
Aspect ratio |
26 |
DVD anamorfico-->Svcd 480*576 anamorfico |
480 X 576 |
16:9
625 (per gli mpeg 1 con il LSX e BBmpeg) |
||
27 |
DVD anamorfico-->Svcd 352*576 anamorfico |
stessi parametri del caso N. 26 |
Dimensione
della cornice |
352X576 | stessi parametri del caso N.26 |
28 |
DVD anamorfico-->Svcd 704*576 anamorfico |
stessi parametri del caso N. 26 |
Dimensione
della cornice |
704X576 | stessi parametri del caso N.26 |
29 |
DVD anamorfico-->Svcd 720*576 anamorfico |
stessi parametri del caso N. 26 |
Dimensione
della cornice |
720X576 | stessi parametri del caso N.26 |
30 |
DVD anamorfico-->Svcd 352*288 anamorfico |
stessi parametri del caso N. 26 |
Dimensione
della cornice |
352X288 | stessi parametri del caso N.26 |
7) Opzioni IDCT: quale modalità scegliere
Con Xmpeg, è possibile selezionare il tipo di algoritmo IDCT da utilizzare per decodificare l'mpeg: ho analizzato la questione in maniera approfondita sull'articolo che tratta le varie versioni di Flaskmpeg.
In breve, la IDCT
(trasformata coseno inversa) è un algoritmo matematico alla base della
decompressione mpeg. Da tale algoritmo si richiedono 2 caratteristiche:
- velocità (una rapida implementazione velocizza globalmente la decompressione
e quindi la conversione degli mpeg)
- qualità: per velocizzare la IDCT si devono utilizzare delle approssimazioni
che non devono però inficiare la qualità degli mpeg: lo standard mpeg ha fissato
dei margini di errori consentiti e un test, l' IEEE 1180 che se superato
garantisce una qualità al top.
Osservo che in realtà l'unica implementazione corretta matematicamente è quella così detta reference, che ha il difetto di essere parecchio lenta: le IDCT non reference ma che soddisfano il test IEEE 1180 producono degli errori (alcuni pixel colorati diversamente) assolutamente invisibili all'occhio umano e pertanto tollerabili. Nell'articolo ho realizzato analisi molto accurate e ora posso affermare quanto detto con assoluta certezza: per tranquillizzare gli amanti della qualità, nessun DVD player "da tavolo" utilizza una IDCT reference, ma tutte IDCT IEEE 1180 compatibili.
Con Xmpeg è possibile selezionare la IDCT, tra le tante disponibili: poiché ciascuna IDCT utilizza diverse istruzioni, MMX, SSE, SSE, 3d Now!, le IDCT disponibili dipendono ovviamente dalla CPU del proprio computer.
L'ideale sarebbe
quello di selezionare la IDCT in maniera automatica :selezione su
opzioni/opzioni globali progetto/video/Auto selection. Io sconsiglio tale
opzione, e consiglio di deselezionarla,
per un motivo
semplice: su quasi tutti i sistemi che ho provato viene automaticamente
utilizzata la DVD2aviMMX
o DVD2aviSSEMMX che sono le uniche IDCT che non soddisfano il test IEEE 1180.
In realtà in base alle analisi che ho effettuato (comparazione con photoshop
delle decodifiche), sia la DVD2aviMMX e la DVD2aviSSEMMX producono
immagini identiche alle altre modalità garantite dal test IEEE 1180. Quasi
certamente c'è un bug nel test IEEE 1180 con tali modalità: ciò lo si deduce che
il test si blocca all'inizio e viene indicata una incompatibilità con le
specifiche IEEE 1180 nonostante i risultati indicati sono assolutamente
corretti. Pertanto è mia opinione che le IDCT DVD2aviMMX o DVD2aviSSEMMX
soddisfano le specifiche IEEE 1180 e vanno benissimo: pertanto si potrebbero
tranquillamente selezionare e lasciare Auto selection.
In pratica vista la parità di velocità delle DVD2aviMMX o DVD2aviSSEMMX con altre IDCT, il mio consiglio è di DESELEZIONARE opzioni IDCT/auto selection e di settare la più veloce delle IDCT che non sia DVD2aviMMX o DVD2aviSSEMMX: sul mio sistema setto indifferentemente Optimize MMX o Fast SSE2 che hanno la medesima velocità, sono IEEE1180 compatibili e sono le più veloci. Ho provato Optimize MMX e fast SSE2 su di un P2, P3 e P4 e in tutti i 3 i casi la optimize mmx è risultata più veloce alla pari della fast SSE2, incompatibile con il P2 che non dispone le istruzioni SSE. E' molto probabile che si ottengono gli stessi risultati su piattaforme AMD.
Per determinare la IDCT più veloce, ( magari per confermare quello che ottengo sul mio sistema), conviene fare un breve test: decodifica di video di origine DVD, 720*576 senza ridimensionamento, modalità YV12 preview disattivato. Io ho usato uno spezzone di 80s che dopo la prima visualizzazione è stato immagazzinato nella RAM del sistema grazie al file system di W98SE: dalla seconda visualizzazione il file è stato decodificato da RAM senza l'influenza spesso imprevedibile, della velocità dell'HD.
Ecco i risultati
ottenuti sul mio sistema P4 1700 Mhz con le iDCT disponibili
: ho valutato
per ciascuna Idct il superamento del test IEEE1180 tramite opzioni iDCT/test.
Una iDCT è risultata reference nel momento in cui non ci sono errori: nel test
si ottengono tutti valori di errore pari a 0.
Come più volte detto, le caratteristiche "reference" sono solo una
interessante meta teorica per i programmatori: nella pratica non servono a molto
poichè il superamento della IEEE1180 basta a garantire la massima qualità.
Velocità espresse in fps, fotogrammi al secondo nella decodifica di video
720*576 senza ridimensionamento, modalità YV12 |
|||
iDCT | Fotogrammi al secondo | Superamento test IEEE1180 | iDCT reference |
Optimize MMX iDCT | 61,5 | SI |
NO |
Fast SSE2 iDCT | 61,5 | SI |
NO |
DVD2AVI SSEMMX | 61,5 | ???? |
NO |
DVD2AVI MMX | 60,1 | ???? |
NO |
Miha's 87 Fast iDCT | 54,7 | SI |
NO |
MMX iDCT | 53,3 | SI |
NO |
Fast integer iDCT |
49,1 | SI |
NO |
Reference Low iDCT SSE2 | 43,4 | SI |
NO, in pratica SI |
Miha's 87 Reference iDCT | 40,2 | SI |
SI |
Reference iDCT SSE2 | 34,8 | SI |
SI |
AMD x87 iDCT | 15,2 | SI |
SI |
Reference iDCT | 10,5 | SI |
SI |
Come detto con DVD2aviMMX o DVD2aviSSEMMX il test IEEE1180 si blocca a metà, e viene indicato il non superamento: stranamente i risultati parziali dimostrano il contrario. Visto come l'algoritmo è utilizzato dall'ottimo sw DVD2AVI, che per quanto verificato e garantito dall'autore è compatibile con le specifiche IEEE1180, la compatibilità dovrebbe valere anche per Xmpeg.
Osservo come Reference Low iDCT
SSE2 non è reference anche se produce degli errori assolutamente trascurabili in
un paio di test, tanto da poterlo ritenere reference a tutti gli effetti : non a
caso è stato battezzato Reference Low. La Reference iDCT, l'ultima per velocità,
è ottenuta tramite semplice codice C, utilizzo di istruzioni in virgola mobile
senza alcuna ottimizzazione: risulta ben 4 volte più lenta della Miha's 87
Reference iDCT che produce bit a bit gli stessi risultati, ma è
incomparabilmente più veloce grazie alla ottimizzazione del codice sorgente,
classico esempio di ottima programmazione.
Nel diagramma le IDCT reference hanno un colore diverso.
8) Modalità di ridimensionamento: quale modalità scegliere
Per ridimensionare il video ad una risoluzione diversa da quella originale, è possibile utilizzare una serie di algoritmi, noti "agli addetti ai lavori", nel campo della elaborazione numerica dell'immagine: il tipo di filtraggio modifica fortemente la qualità dell'immagine ridimensionata ottenuta.
Le "vecchie" versioni di Flaskmpeg sino alla 06 preview, utilizzavano 4 metodi: esclusa la Nearest Neighbour ( pixel più vicino, nessun filtraggio) di fatto inutilizzabile per la qualità insufficiente, le alternative erano il filtro bilineare (media dei 2*2 punti più vicini) e il bicubico (media su 4*4 punti) discretamente più lento; il bicubico d'alta qualità al contrario produceva di fatto la stessa qualità del bicubico ma in più un inutile rallentamento della decodifica.
Il filtraggio bicubico, a torto è stato considerato qualitativamente superiore al bilineare a causa di una strana ed errata equazione: maggiore lentezza dell'algoritmo è sinonimo di maggiore qualità e in seguito al fatto che ciascun pixel è calcolato come media di 16 e non 4 punti tra loro confinanti. In realtà se si legge un buon libro di elaborazione numerica del segnale e si fa qualche test in proprio si ci si accorge che il filtraggio di tipo bicubico è da preferire al bilineare quando si deve ingrandire una immagine e quindi un video; tanto maggiore è l'ingrandimento, tanto più è opportuno usare il filtro bicubico rispetto al bilineare; al contrario tutte le volte in cui si desidera ridimensionare una immagine o video, riducendo le dimensioni si ottengono i migliori risultati con il bilineare per discreti e medi ridimensionamenti (diciamo risoluzioni sino a XXX*350 pixel con originali DVD 720*576), mentre si ottiene una parità tra i due metodi sino ai ridimensionamenti al 50% delle righe (XXX*288 sempre da originali 720*576); solo nei casi di forti rimpicciolimenti e risoluzioni inferiori al 50% (risoluzioni inferiori a XXX*240) può essere conveniente utilizzare il filtraggio bicubico per inserire il maggior numero di dettagli in un numero così ridotto di pixel.
(N.B. per XXX*288 intendo qualsiasi risoluzione in cui ho 288 righe, 352*288, 388*288, 512*288,..., analogamente per XXX*350 intendo qualsiasi risoluzione in cui ho 350 righe,...)
Il motivo
dell'inutilità del bicubico per discreti e medi rimpicciolimenti del video
deriva dal fatto che ciascun pixel del video ridimensionato verrebbe "inquinato"
dai contributi di troppi altri pixel, creando della informazione video non
presente nell'originale.
Non è assolutamente vero che il bilineare non è in grado di ridimensionare
correttamente linee diagonali, che sempre nell'ipotesi di riduzione della
dimensione del video non elevatissime sono rese con la massima naturalezza: al contrario quando
si ingrandisce un video il bicubico produce una qualità decisamente superiore:
ciò appare evidente proprio in corrispondenza di contorni ben delineati
che sono resi con maggiore realismo.
Osservo come recentemente il filtraggio bicubico viene implemento e utilizzato in HW dalle schede video ATI Radeon : le Matrox ad esempio continuano ad utilizzare il bilineare. Non è un caso che l'operazione che la scheda video è maggiormente chiamata a compiere è l'INGRANDIMENTO, di video da finestra a full screen o in tutti i casi a finestre con dimensioni maggiori.
Xmpeg va in soccorso ai limiti del filtraggio bilineare , che come visto tendere a perdere in qualità per riduzioni attorno alle 350 righe o inferiori, grazie ala disponibilità del filtraggio Bressenham che oltre ad essere velocissimo, ha una resa superiore anche per riduzioni sino a 240-288 righe (sono sempre nell'ipotesi di originali 720*576). Il bicubico rimane qualitativamente superiore per riduzioni maggiori.
Ridimensionamento di un DVD 720*576 |
||
Risoluzione video ridimensionato |
Filtraggio qualitativamente superiore |
Filtraggio consigliato |
XXX*576 - XXX*350 |
Bressenham |
Bressenham |
XXX*350 - XXX*240 |
Bressenham o Bicubico |
Bressenham |
inferiore a XXX*240 |
Bicubico |
Bicubico |
Riassumendo,
tutte le volte che si deve usare Xmpeg per ridimensionare un video
riducendo le dimensioni sino ad un massimo 240 righe (vedi le conversioni DVD--> Divx, XVCD, SVCD,... )
conviene utilizzare il filtraggio Bressenham.
Il filtraggio bicubico va invece usato le volte in cui si ingrandisce il video,
ad esempio la conversione di video "formato francobollo" in risoluzioni
maggiori.
Rimarrebbe conveniente il bicubico nel caso della creazione di
video con dimensioni molto ridotte, che in pratica ha senso solo per
contenuti web-oriented : in tal caso
ad una risoluzione ridotta a 240 righe o meno si somma una fortissima
compressione, e i vantaggi del bicubico vengono immediatamente vanificati
dagli artefatti creati dal codec di compressione.
Noto come che esistono numerose implementazioni del filtraggio bicubico, ciascuna
della quali produce risultati leggermente diversi: basta ad esempio
ridimensionare un frame contenente linee nere verticali di 1 pixel per
accorgersi ad esempio dei diversi risultati del filtraggio bicubico di Flaskmpeg , di VirtualDub
(5 diverse versioni di filtraggio bicubico) o di Photoshop.
Xmpeg 4.2a contiene 7 implementazioni del ridimensionamento, con la utilissima
possibilità di vedere il preview del ridimensionamento mentre si cambia
filtraggio (opzioni/opzioni globale progetto/post trattamento/mostra il pannello
di uscita/options), maniera molto semplice per fare dei confronti sulla qualità
dei diversi filtraggi. Fatti alcuni test ho avuto conferma del fatto che, sempre
nelle ipotesi viste di rimpicciolimenti del video, la modalità di
filtraggio Bressenham, scritta dall'autore del sw DVD2AVI, è in assoluto la
migliore a livello di qualità e inoltre ottimizzata in velocità.
Ho trovato conferma di quanto detto rispetto al filtraggio bicubico: sino a
240-288 righe, non ho mai trovato un caso in
cui il filtraggio Bressenham produce qualità inferiore, nonostante
sia ben 60-70% volte circa più veloce. Il test lo ho fatto anche zoomando l'immagine
ridimensionata del 200 % grazie al Matrox Desk Nav: i risultati hanno
mostrato inoltre come il filtraggio Bressenham risulta superiore in qualità
al filtraggio bilineare, leggermente nelle medie e piccole riduzioni e in
maniera più evidente in quelle maggiori.
Osservo come la modalità Bicubica presente in Xmpeg4.2a è molto
più precisa di quella della vecchia Flaskmpeg06 ( il test sulle linee verticali di un
pixel lo dimostrano senza dubbio) ma al contrario è lentissima , più della bicubica HQ presente nella 06: non usatela ma andate tranquilli con il
filtraggio Bressenham. Da scartare come la peste il filtraggio chiamato "pseudobicubico"
che produce sempre delle evidentissime seghettature verticali.
Ecco una tabella che riassume le velocità ottenibili con il mio P4 1700 Mhz (solo decodifica) in
2 casi diciamo "classici":
- ridimensionamento di un Vob 720*576 alla risoluzione 480*432, modalità RGB per
la creazione di un SVCD standard tramite la catena Xmpeg-->video server-->
tmpeg;
- ridimensionamento a 512*288, modalità YV12, classica risoluzione per i DivX
con video 1.78 :1 e bitrate medio -bassi.
Naturalmente tali
velocizzazioni
influenzano solo in parte la velocità della conversione finale dove la
maggior parte del lavoro computazionale della CPU è delegato al codec di
compressione. Da osservare
l'incredibile velocità nel caso di Nearest
Neighbour, che a causa della scarsa qualità è utilizzabile solo in fase di test
(ad esempio la compressione "rapida" di interi film con "dimensioni
francobollo", fatte a scopo di test per verificare la stabilità di un software,
catena o codec.)
Sola visualizzazione : fotogrammi al secondo | ||
RGB 480*432 |
YUV 512*288 |
|
Nearest Neighbour | 35,9 | 54,5 |
Bressenham | 27,6 | 37,7 |
Bilineare | 16,7 | 24,4 |
Bilineare MMX | 19 | 28,0 |
Bicubico | 6,8 | 6,0 |
Bicubico SSE | 17,7 | 11,.1 |
PseudoBicubico | 19,2 | 27,9 |
Osservando i risultati sono stato colpito dal rallentamento evidente che si ha in corrispondenza della risoluzione 512*288 con filtraggio bicubico: il ridimensionamento è notevolmente più lento rispetto al caso di ridimensionamento a 480*432, nonostante il minor numero di punti da calcolare. Incuriosito della cosa ho provato a ridimensionanere sempre con il filtraggio bicubico SSE, ma con altre risoluzioni: 528*288, 544*288,.... : ho notato che nonostante il maggior numero di punti da calcolare la velocità si raddoppia arrivando sino a 24, 25 fotogrammi al secondo. E' evidente che c'è un qualche problema nell'algoritmo di ridimensionamento bicubico SSE che con il mio p4 1700 Mhz, perde la sua ottimizzazione in presenza di particolari risoluzioni, probabilmente a causa di blocchi o latenze nella pipeline della CPU che fanno calare drasticamente le prestazioni. Fortuna che ciò non succede per il filtraggio Bressenham !!!!
9) Xmpeg e la creazione diretta di video (ad esempio DivX) con audio mp3 e codec Fraunhofer-II
Il metodo "classico" per creare video (ad esempio in formato DivX;-) o DivX ) con audio compresso in formato mp3, è quello di creare prima con Xmpeg un avi con audio PCM non compresso, e poi di effettuare la compressione in mp3 sfruttando Virtual Dub e codec audio mp3 Fraunhofer-II installato tramite la nota distribuzione DivX;-) versione 3.11. Con virtual dub si crea il nuovo avi in cui la traccia video è copiata bit a bit (non si rieffettua nessuna ricompressione grazie all'opzione video/direct stream copy) , mentre la traccia audio viene convertita da PCM non lineare a mp3 (o DivX audio)
Il motivo del doppio passaggio sta in un "bug" del codec mp3 Fraunhofer-II, che a causa di una dimensione errata dei pacchetti audio, crea un asincronismo audio-video già dopo pochi secondi di conversione: Virtual dub compensa tale bug creando un flusso audiovideo perfettamente sincronizzato.
Xmpeg 4.2a contiene all'interno dei suoi 2 plug in
Xmpeg 4.2a contiene all'interno dei suoi 2 plug in (la versione 2.3 da usare con win98/98SE/ME e la 2,5 da usare con NT/XP/2000) la possibilità di effettuare automaticamente la correzione del "bug" del codec mp3 Fraunhofer-II esattamente come succede per Virtual Dub: per far ciò basta SELEZIONARE l'opzione Compensate Fraunhofer-II's MP3 codec bug. Il vantaggio sta ovviamente nel fatto che si evita il doppio passaggio (conversione in Xmpeg con audio pcm e seconda passata con VirtualDub) ed è possibile ottenere direttamente il filmato avi (normalmente DivX o DivX;-)) con audio mp3. Consiglio l'utilizzo della opzione High quality compression, che in pratica non rallenta la compressione (ci sono differenze a volte neanche cronometrabili) ma crea una qualità leggermente superiore: non ci si deve attendere un miglioramento dell'audio evidente, ma in tutti i casi c'è un miglioramento lieve della qualità. |
|
Vediamo come risolvere alcuni dei possibili problemi che si possono presentare quando si effettua la compressione mp3 direttamente all'interno di xmpeg.
1) E' impossibile settare un bitrate superiore a 56 Kbits/s e freq. di campionamento superiore 22050 o 24000
Ricordo come nativamente Windows 95/98/98SE/ME/NT/2000/XP (.... spero di non aver dimenticato nessun fratellino Microsoft..) possiede al suo interno un codec mp3 limitato al bitrate di 56 Kbits/s e freq. di campionamento 22050 o 24000 di proprietà Fraunhofer a causa delle royality richieste da questa dedentrice dei diritti sul formato. Per ottenere la versione completa in grado di raggiungere i 320 Kbits/s occorre acquistarla o utilizzare quella distribuita con il DivX;-) versione 3.11 (DivX 3.11 alpha link1 , DivX 3.11 alpha link2 )
Se si installano nuove versioni del Windows Media Player o in generale pacchetti di sviluppo della Microsoft, i codec mp3 forniti dalla distribuzione DivX sono sovrascritti da quelli Microsoft, rimanedo così il limite dei 56 Kbits/s. Per ripristinare i codec mp3 in grado di raggiungere i 320 Kbits/s occorre o eseguire il programma Register_DivX.exe (che trovate nella directory in cui si è installato il DivX) o reinstallare del tutto il codec DivX;-) . Apparirà il seguente messaggio a cui occorre rispondere SI. Ricordo che se si vuole utilizzare ancora il codec video DivX;-) 3.11, conviene installare i codec aggiornati capaci di inserire key frame nei cambi di scena: basta scaricare il file Divx.zip e ricopiare i codec aggiornati DivXc32.dll e DivXc32f.dll nella directory Windows\System per la famiglia Windows98/98SE,ME o Windows\System32 se si usa Windows NT, 2000 o XP. Vista la netta superiorità del DivX rispetto al "vecchio" DivX;-), tale operazione è inutile se, come consiglio, si utilizza il nuovo DivX.
2) Appena si avvia la compressione dell'avi appare il seguente messaggio:
o
E' uno dei problemi più frequenti. La causa è legata al fatto che il codec mp3 Fraunhofer è un codec ACM, ovvero un codec che dopo essere stato installato nel sistema può essere richiamato da qualsiasi applicazione capace di creare file avi e settare il formato audio.
C'è da sperare che nelle prossime versioni Xmpeg, esattamente come fanno altri encoder (vedi Vidomi), si agganci all'ottimo codec mp3 LAME (un freeware che ha la medesima qualità e velocità del Fraunhofer) tramite un accesso diretto al codec (la libreria Dll disponibile con la distribuzione LAME) evitando così i conflitti che derivano dall'utilizzo di un encoder ACM.
Per risolvere il problema occorre disattivare momentaneamente ( o se non servono anche in maniera definitiva) tutti gli eventuali altri codec ACM mp3 installati nel sistema, come ad esempio il codec mp3 marchiato Creative, installato con i driver delle schede audio Creative Audigy e altri codec "fastidiosi", uno tra tutti il WRPR video server client codec, utilizzato dal plug-in video server (plug-in che crea avi virtuali e permette la creazione di catene quali la nota Xmpeg--> video server--->tmpeg. Per codec "fastidiosi" intendo quelli aggiunti ai codec installati di serie in Windows.
Osservo come la disattivazione è immediata (vedo tra un pò come fare) e non occorre riavviare il sistema per renderla attiva. Vediamo come disattivare i "codec incriminati".
Vediamo prima di tutto come procedere in Windows 98/98SE/ME e poi vedremo come fare in Windows XP
Per far ciò occorre andare in Risorse del Computer/Pannello di controllo/multimedia/periferiche/codec di compressione audio e cliccando su + individuare i codec che vanno in conflitto. |
|
|
Sul mio sistema i codec che vanno in conflitto sono i due cerchiati in rosso: il Creative mp3, installato con la audigy e il WRPR video server. Tutti gli altri sono installati con Windows, mentre il codec mp3 installato con il divX;-) 3.11 è il Fraunhofer IIs mpeg layer 3 codec (professional), codec ovviamente da lasciare !! Per disattivare ciascuno dei codec che vanno in conflitto (i due cerchiati)........
|
|
|
...... occorre selezionarli, cliccare su proprietà e settare "NON utilizzare il codec audio selezionato" e click su OK Nell'esempio tale operazione va fatta 2 volte, per il Creative MP3 e per il WRPR . |
Dopo aver disattivato i codec è possibile rieseguire Xmpeg dove sarà possibile settare il codec audio mp3 e avviare la conversione.
Naturalmente per riattivare i codec momentaneamente disattivati basta procedere nella stessa maniera vista e selezionare questa volta "utilizza il codec audio selezionato".
ATTENZIONE a riattivare il WRPR video server al termine dell'utilizzo di Xmpeg : se questo è lasciato disattivato le volte che si utilizza il video server (vedi Xmpeg--> video server--->tmpeg) tutto sembra funzionare bene.... con la sorpresa che l'audio non viene passato all'encoder e che si ottengono video muti !!!!!!!
Vediamo come procedere nella disattivazione con Windows XP.
Con XP occorre andare in Risorse del Computer e cliccare su visualizza informazioni sul sistema.... |
|
...click su Hardware e gestione periferiche.... |
|
...doppio click su codec audio... |
|
...selezionando proprietà appare la lista dei codec installati ... I codec da disabilitare sono, sempre nell'esempio del mio sistema , ctmp3.acm (cambia il nome ma il codec è lo stesso, Ct sta per creative e pertanto Ctmp3 sta per codec mp3 della creative) e Video server wrapper codec. gli altri sono installati di default da Windows XP |
|
Per disattivare (e alla fine riattivare) i codec occorre procedere come per windows 98, settando "non utilizzare il codec audio selezionato" |
|
Osservo che utilizzando Windows XP sembra che il codec Creative possa rimanere e consentire ugualmente con Xmpeg, la compressione diretta di avi con audio mp3 Fraunhofer. In realtà ANCHE SE SI SELEZIONA il codec Fraunhofer, viene attivato il codec Creative notevolmente più lento !!!. Si ottengono in certi casi velocità di conversione dimezzate. Conviene pertanto DISATTIVARE il codec Creative senza scrupoli !!!.
Termino osservando come ho considerato il caso particolare del mio sistema in cui ci sono 2 codec che vanno in conflitto, ma nulla cambia se sono stati installati altri codec audio ACM in conflitto con l'mp3 Fraunhofer . La regola è la stessa: provare con Xmpeg la creazione diretta di avi audio mp3 Fraunhofer: se appare il messaggio visto o ci sono strani problemi di rallentamenti evidenti di velocità, occorre cercare il o i codec acm causa del conflitto, disabilitarli, ricaricare xmpeg e effettuare la conversione.
Nei casi più "disperati" rimane il buon metodo della creazione di Avi con audio PCM non compresso, e compressione successiva dell'audio in mp3, con Virtual Dub.
10) Reinizzializzare Xmpeg (o Flaskmpeg)
Può essere necessario reinstallare ex novo Xmpeg, magari perchè il software inizia a creare problemi nella compressione o crash di sistema: Xmpeg infatti memorizza i parametri di codifica e decodifica all'interno del registro di sistema e all'interno delle cartelle "profile" e "setting".
La prima cosa da fare è cancellare i parametri che xmpeg ha inserito nel registro: dopo aver scaricato e decompresso il file registri.zip per chi utilizza Windows 98/98SE/ME basta doppiocliccare sul file Unregister Xmpeg.reg ; per chi utilizza windows 2000, NT o XP, bisogna doppiocliccare su Unregister Xmpeg winxp.reg. All'interno di registri.zip trovate anche i file analoghi relativi a Flskmpeg valida per azzerare il valori immessi nel registro da Flaskmpeg 0594, 06 e xis_30e_expert: può servire eseguirili nel caso sono presenti nel sistema nell'ipotesi che creano dei conflitti (ipotesi comunque rara). A prova dell'avvenuta cancellazione dei dati memorizzati nel registro, alla nuova esecuzione di xmpeg viene richiesta la lingua ( italiano nel nostro caso) con cui utilizzare il programma.
La seconda cosa che è possibile fare ( se i problemi permangono) è intanto operare come visto sul registro, poi cancellare le cartelle "profile" e "setting" e ricopiare quelle che trovate nella mia distribuzione di xmpeg. Attenzione a non cancellare semplicemente il contenuto di tali cartelle, poiché molto probabilmente xmpeg andrà poi in crash. Come alternativa più drastica è possibile cancellare completamente la cartella dove si è installato Xmpeg, (cancellando ovviamente anche le sottocartelle settings, profiles,..), e ricopiare del tutto il contenuto della mia distribuzione: è consigliabile prima di cancellare la cartella, fare il backup degli eventuali altri plug-in installati, non presenti nella mia distribuzione: ad esempio videoserver.cm.Xmpeg (video server plug-in), lsx.cm.Xmpeg (Lsx plug-in), bbmpeg.cm.Xmpeg (bbmpeg plug-in),Avisynth.cm.xmpeg.....
11) Compressione DivX a doppia passata
Prima di tutto vi rimando all'aggiornamento/articolo sul DivX 4.12 per una analisi dei diversi parametri da utilizzare e per la descrizione della compressione a doppia passata.
Utilizzando Xmpeg 4.2a è possibile effettuare senza alcun problema la compressione a doppia passata nella maniera più semplice, in cui la seconda passata non è avviata in maniera automatica ma manualmente. Vediamo prima questo caso e poi vedremo il caso in cui la seconda passata è avviata automaticamente ( possibile solo con windows NT/XP/2000).
In breve, nel metodo manuale, si immettono i parametri della prima passata, la si avvia, terminata questa si immettono i parametri della seconda passata e si avvia la conversione finale: è ciò che si può fare con qualsiasi sw capace di creare avi e quindi divX. Nel metodo automatico (disponibile solo su alcuni software, Xmpeg compreso), si inseriscono i parametri di prima e seconda passata ( vediamo poi come) e si avvia la conversione: Xmpeg automaticamente avvierà la prima e poi la seconda conversone.
Doppia passata - metodo manuale
Vediamo il metodo in
cui si avvia manualmente la seconda passata: è possibile farlo con qualsiasi
sistema operativo da win98...... ad XP.
Per la prima passata occorre intanto settare in Xmpeg i parametri
relativi al video da decodificare cliccando su opzioni/opzioni globali progetto
e immettendo i parametri desiderati in
. Si
scelgono pertanto la dimensione video, Idct, filtraggio di ridimensionamento,
nome del file, ...... e naturalmente formato YV12 !
PER L'AUDIO poichè si deve effettuare la prima passata in cui si ha solo una
analisi del video, conviene settare "non
processare l'audio"
: in questa
maniera si ha una velocizzazione dovuta al fatto che l'audio non viene ne
convertito e ne compresso (sarebbe assurdo fare la prima passata con audio
mp3!!!)
Riguardo i parametri del sottomenù "Generali" poiché non è utilizzato avisynth o il frameserver, è possibile inserire i secondi o fotogrammi da convertire (2500 sec nell'esempio) oppure se si vuole convertire l'intero video o l'intero intervallo precedentemente selezionato in maniera grafica (clear all job, set job start, set job end, add job) occorre selezionare "compila l'intero file". Riguardo gli altri parametri presenti in "Generali" occorre deselezionare 2nd Pass Enable for multipass plug-in e deselezionare 2nd Pass Enable for DivX4 come in figura.
Riguardo le opzioni formato d'uscita si sceglie come visto l'avi plug-in 2.5 se si usa NT/2000/XP o l'avi plug-in 2.3 se si usa 98/98SE/ME
In opzioni/opzioni formato d'uscita per l'audio i parametri sono ininfluenti poichè l'audio nella prima passata non viene convertito avendo prima settato l'opzione "non processare l'audio": per il video occorre ovviamente settare il DivX e immettere i parametri ad esempio come in figura: fondamentale mettere il variable bitrate mode= 2 pass first pass e naturalmente il bitrate medio desiderato (900 nell'esempio)
A questo punto si avvia la conversione: esegui/inizia la conversione.
Terminato il primo
passaggio, occorre ritornare in opzioni/opzioni globali progetto/audio e settare
con la
frequenza di campionamento preferita (normalmente 44100). Riguardo il nome del
file (opzioni globali progetto/files) è possibile utilizzare lo nome stesso
settato nel primo passaggio, poichè il pseudo avi del primo passaggio può
tranquillamente essere sovrascritto.
Poi occorre andare in opzioni/opzioni
formato d'uscita per settare il formato audio (ad esempio mp3) e i parametri del
DivX, questa volta relativi alla seconda passata: ad esempio
Fondamentale mettere il variable bitrate mode= 2 pass second pass. e naturalmente il bitrate medio desiderato: attenti a lasciare lo stesso log file del primo passaggio. Non rimane che riavviare la conversione: esegui/inizia la conversione.
Doppia passata - metodo automatico (solo per Windows XP/NT/2000)
Questo metodo funziona solo utilizzando l'avi plug-in 2.5 che per quanto detto può essere usato solo con Windows NT/2000/XP: con Windows 98/98SE/ME tale plug-in dopo alcuni minuti di conversione manda in crash il sistema per mancanza di risorse grafiche.
E' IMPORTANTE NON PROVARE IL METODO CHE STO PER DESCRIVERE CON IL PLUG-IN v. 2.3 (quello che appare in opzioni/seleziona il formato d'uscita come OpenDML AVI Output (RGB, YUV) Non solo la seconda passata non funziona, ma quasi certamente viene pasticciato il registro di sistema così che vengono inseriti come valori di Defoult del DivX valori assolutamente inutilizzabili, tanto che occorre eventualmente reinstallare i codec DivX.
Il metodo automatico di doppia passata ripeto ancora funziona solo su Windows NT/2000/XP e utilizza l'avi plug-in 2.5 (quello che appare in "opzioni/seleziona il formato d'uscita" come "AVI plug-in"): occorre pertanto settare come primissima cosa in opzioni/seleziona il formato d'uscita, tale plug-in.
Con il metodo automatico occorre immettere una sola volta i parametri della prima e seconda passata e poi avviare la conversione: sarà Xmpeg in maniera automatica ad avviare la seconda passata al termine della prima.
Occorre intanto
settare in Xmpeg i parametri relativi al video da decodificare cliccando su opzioni/opzioni globali progetto
e immettendo i parametri desiderati in
. Si
scelgono pertanto la dimensione video, Idct, filtraggio di ridimensionamento,
nome del file, ...... e naturalmente formato YV12 !
PER L'AUDIO si deve settare ovviamente "Decodifica l'audio"
(XMPEG
automaticamente nella prima passata non decodificherà l'audio velocizzando così
l'operazione di analisi del video)
Riguardo i parametri del sottomenù "Generali" poiché non è utilizzato avisynth o il frameserver, è possibile inserire i secondi o fotogrammi da convertire (2500 sec nell'esempio) oppure se si vuole convertire l'intero video o l'intero intervallo precedentemente selezionato in maniera grafica (clear all job, set job start, set job end, add job) occorre selezionare "compila l'intero file".
Riguardo gli altri parametri presenti in "Generali" occorre selezionare sia 2nd Pass Enable for multipass plug-in e sia 2nd Pass Enable for DivX4 come in figura
Per settare i parametri della seconda passata occorre cliccare sempre nel sottomenù generali su "2nd Pass plug-in": apparirà la finestra in cui occorre settare per l'audio il codec scelto (mp3 nell'esempio) e per video DivX Codec 4.12 e i parametri della seconda passata, ad esempio
(per il bitrate il valore medio che si vuole ottenere).
Per settare i parametri della prima passata occorre andare in opzioni/opzioni formato d'uscita dove apparirà nuovamente : per l'audio non ha alcuna importanza il codec che si sceglie, poichè Xmpeg automaticamente nella prima passata disattiva l'audio; per il video occorre settare DivX Codec 4.12 e immettere i parametri della prima passata, ad esempio .
Non rimane che avviare la conversione e per velocizzarla evitare di lasciare fisso nella finestra "compression tracer" il diagramma del bitrate, ma magari selezionare "video stats", utile per monitorare nella seconda passata, il bitrate medio ottenuto.
12 Come reinizzializzare Xmpeg e il codec DivX dopo aver erroneamente utilizzata la doppa passata con Xmpeg e avi plug-in v2.3
Se si effettua per errore la compressione in DivX a doppia passata utilizzando l'avi plug-in 2.3 a causa di una incompatibilità di tale plug-in con la doppia passata di Xmpeg4.2a si verifica in numerosi casi (non sempre comunque) l'impossibilità di utilizzare Xmpeg e soprattutto la spiacevole conseguenza che i parametri di default del DivX, qualsiasi sia il software che lo utilizzi, sono valori senza senso.
Il problema si risolve del tutto reinizzializzando Xmpeg e il codec DivX.
Per Xmpeg, occorre procedere come descritto nel punto 10. In breve, fare il backup dei plug-in installati non presenti nella mia distribuzione, cancellare del tutto la cartella in cui c'è Xmpeg (cancellando ovviamente anche le sottocartelle settings, profiles,..), reinstallare Xmpeg (ricopiando del tutto il contenuto della mia distribuzione). Come ultima cosa occorre resettare il registro di sistema: caricato e decompresso il file registri.zip per chi utilizza Windows 98/98SE/ME basta doppiocliccare sul file Unregister Xmpeg.reg ; per chi utilizza windows 2000, NT o XP, bisogna doppiocliccare su Unregister Xmpeg winxp.reg.
Per rimettere a posto il codec DivX basta semplicemente reinstallarlo.
26 febbraio 2002
Ritorna alla pagina digital video