Sono cambiate un po' di cose nel mondo Linux, e tanto per non essere da meno ho installato e sto usando Fedora, con molta soddisfazione. Inoltre ho avuto in regalo un masterizzatore DVD usato da un amico che ha fatto un upgrade, come pure ho un po' potenziato il PC: adesso ho un Pentium 4 a 1.5 GHz, e ho una scheda firewire IEEE1394. Chissà che non ci esca qualche novità?
Ah, tra l'altro mi sono sposato... quindi per un po' sono stato offline.
Questo è un documento in continua scrittura. Quindi contiene sicuramente errori, imprecisioni, ecc. ecc., ma contiene molto altro. Leggetelo e fatemi sapere cosa ne pensate.
Ovviamente un PC con su installato Linux, una qualsiasi distribuzione va bene, anche se gli esempi saranno presi dalla RedHat 9 e da Fedora Core 1. La configurazione non ha importanza, basta che sia installato il necessario per lo sviluppo, ossia gcc e g++ con le relative librerie.
Se volete produrre DVD, videoCD (VCD), SupervideoCD (SVCD), DivX, convertire le vostre videocassette in VCD o SVCD, qui troverete il punto di partenza. Non troverete ovviamente dettagli sulle applicazioni o sui formati dei supporti. Né troverete help o tutorial su come si fa un VCD da un DVD o sulle singole applicazioni. Lo scopo è di fornire una panoramica di quello che esiste su Linux come software libero, e di come configurare la vostra macchina per lavorare con il video.
N.B.: se non sapete cosa sia un tarball, se non avete mai usato Linux da console testo, se non sapete cosa sia una named pipe, se non conoscete la sequenza configure/make/make install, questo documento non fa per voi. Tornate a leggerlo dopo che saprete cosa sono le strane parole che ho usato. Credetemi, vi risparmierete mal di testa e delusioni.
L'unica cosa che non potete fare con questo documento è venderlo o usarne parte, in qualsiasi forma o codifica, per includerla in un prodotto in vendita. Praticamente questo documento è rilasciato sotto la licenza FDL, che potete trovare o allegata alla distribuzione insieme ai file di questo documento oppure potete prelevare dal sito http://www.fsf.org/licenses/fdl.html.
Spesso mi capita di pensare con un senso di meraviglia al meccanismo che fa funzionare il software libero. Utenti che producono e condividono software con chiunque voglia utilizzarlo. E' a tutte queste persone, che permettono a tutti di utilizzare il computer, anche a chi non ha mezzi economici, che dedico questo documento.
Quanto scritto qui non vuole essere né una bibbia né verità totale ed assoluta. L'errore è sempre in agguato. Se volete contribuire, mandare commenti, segnalazioni, critiche e suggerimenti scrivetemi pure all'indirizzo che trovate in cima al documento. Qualsiasi vostro contributo è gradito, e se si rivela determinante il vostro nome verrà citato nella lista degli ospiti di riguardo.
Potete usarlo come un manuale, essendo diviso in sezioni per argomenti. Oppure potete leggerlo tutto di seguito, ma in questo caso potrebbe non esservi molto utile in quanto non vi è un vero filo logico che lega le sezioni, almeno non volutamente. Fate come credete meglio. L'importante è che lo usiate e che vi sia utile. Pronti? Si parte!
Ovviamente la nostra attenzione deve essere in primo luogo per gli strumenti software che ci permetteranno di fare tutto quello che ci interessa con il video, ed ovviamente l'audio.
Esistono diverse categorie di software, in funzione della destinazione:
Spesso un singolo pacchetto software contiene programmi per fare tutti e 4 i passi, ma molto più spesso ne fanno veramente bene uno solo, o una parte. Ma non per questo è da scartare, anzi. Per questo motivo non dividerò il software in categorie, ma per ogni software cercherò di elencare quello che può fare e cosa, secondo me, fa meglio.
Molti dei pacchetti che vedremo usano parti comuni, come librerie specifiche o programmi di altri. Spesso alcune librerie sono opzionali per un pacchetto, ma nel caso il risultato sia migliore vi indicherò quali sono le dipendenze e le librerie che conviene aggiungere all'installazione. Se poi non avete la possibilità di reperire questi pacchetti opzionali, o le funzionalità aggiunte non vi interessano, potete ignorarli.
Per poter correttamente installare gran parte dei pacchetti è necessario utilizzare la versione in sorgenti da compilare. Questo perché spesso non esiste il pacchetto binario già pronto, oppure perché è creato con opzioni che non ci soddisfano o non corrispondono a quanto installato sul nostro computer, o infine per attivare o disattivare parti opzionali che non ci interessano. E' quindi fondamentale che abbiate dimestichezza con il metodo di installazione da sorgenti, ossia la classica trafila del configure/make/make install. Inoltre occorre che siano installati tutti i pacchetti necessari per la compilazione:
Usando RedHat, se al momento dell'installazione avete selezionato l'opzione "Sviluppo", dovreste avere tutto pronto, anche se in qualche caso potrebbe mancare il nasm, che nella RedHat 7.3 è contenuto nel pacchetto nasm-0.98.22-2.i386.rpm (terzo CD).
Se durante la fase di configure ottenete degli errori, o ne ottenete in fase di make è probabile che vi manchi qualcosa, o che sia una versione non compatibile.
In generale, se non specificate diversamente al momento del configure, eseguibili, librerie e include file C saranno installati a partire da /usr/local, e vi consiglio di lasciarlo così. Se volete potete cambiarlo in /usr usando l'opzione --prefix=/usr quando impartite il comando configure. Se avete installati dei pacchetti tra quelli elencati sotto, perché compresi nella vostra distribuzione Linux, ricordate che di solito viene installato tutto in /usr, quindi se volete fare un upgrade dai sorgenti avete due possibilità: disinstallate i pacchetti ed installate dai sorgenti oppure soprascrivete i file installati usando l'opzione --prefix. Nel primo caso non potrete disinstallare automaticamente i file nuovi, ma dato che si trovano tutti dentro /usr/local potrebbe essere sufficiente cancellare il contenuto di /usr/local/bin, /usr/local/lib, /usr/local/include, /usr/local/share, /usr/local/man, ecc. Nel secondo caso potrebbero non funzionare più i tool di installazione della vostra distribuzione per rimuovere o fare l'upgrade del pacchetto che soprascrivete dai sorgenti.
Una considerazione finale: in RedHat versione 7.x il compilatore fornito di default è il gcc versione 2.96, e questo può creare qualche problema. Se potete, e sapete come fare, fate un upgrade alla versione 3.2 o successiva. Ovviamente questo è semplice da dire ma non da fare, quindi considerate attentamente la cosa e leggete tutta la documentazione necessaria. Ad esempio un vantaggio con gcc versione 3 è l'ottimizzazione con l'uso di istruzioni SSE su Pentium III/IV per alcuni pacchetti. Se avete RedHat 9, il compilatore è già aggiornato alla versione 3.2, quindi il problema non si pone.
Nel mio caso, per RedHat 7.3 ho preso il compilatore gcc 3.2.1 di Mandrake 9, che funziona abbastanza bene e non crea problemi di installazione con rpm.
In seguito ho fatto un upgrade alla RedHat 9, e la cosa più evidente è stato un raddoppio netto di velocità per le applicazioni che manipolano immagini e file multimediali.
Di seguito vengono elencati i pacchetti utilizzati per tutte le mie prove e produzioni. Sono presentati in ordine di installazione, perché se li installate in ordine diverso potrebbero non essere attivati e utilizzati dai programmi principali di transcodifica. Ad esempio se installate il codec DivX dopo aver installato Transcode o Avifile, questi ultimi non lo rilevano e non lo usano. Per farlo utilizzare dovete ricompilare sia Transcode che Avifile.
Per ogni pacchetto usato metterò anche il numero di versione usata.
Se possibile, aggiornate i software che sono elencati sotto alla ultima versione disponibile, e teneteli aggiornati.
Alcuni dei pacchetti elencati sono già installati da molte distribuzioni, e se intendete installare le versioni scaricate come sorgenti, occorre prima disinstallare le versioni precedenti.
Se invece scaricate come pacchetti pronti (RPM, DEB, o il formato della vostra distribuzione) potete fare un upgrade.
Controllate comunque SEMPRE la versione che viene usata, perché spesso i pacchetti pronti installano le applicazioni in /usr/bin mentre se installate da sorgenti le applicazioni finiscono in /usr/local/bin e le applicazioni vengono cercate prima in /usr/bin e dopo in /usr/local/bin, quindi se in /usr/bin c'è una vecchia versione userà quella.
Se avete installato librerie condivise da sorgenti, ed uno dei programmi che andate ad installare/compilare vi dice che non trova la libreria ce avete installato poco prima, provate a dare un comando ldconfig da root, e ritentate la compilazione/installazione.
E' l'encoder/decoder MPEG layer 3 più usato su Linux. Fornisce librerie ed eseguibili per tutte le operazioni di manipolazione di file audio MPEG.
Potete prelevarlo dal sito: http://www.mp3dev.org.
Versione usata: 3.95.1
Ne avete bisogno se intendete acquisire da AVI/DivX (in cui mp3 è il formato utilizzato per la traccia audio), e se avete intenzione di creare AVI con DivX o XviD.
Non servono opzioni particolari nella compilazione, quindi la solita sequenza configure/make/install è senza particolari parametri. Usa nasm e attiva alcune ottimizzazioni legate a istruzioni specifiche del processore (MMX, SSE, 3Dnow!, ecc.), producendo codice più veloce.
E' il corrispondente codec MPEG layer 2.
E' il decoder per l'audio ATSC A/52 (conosciuto meglio come AC-3, detto familiarmente 5+1) usato nei DVD video e nella TV digitale. Fornisce librerie per la manipolazione dell'audio AC-3 dei DVD.
Potete prelevarlo dal sito: http://liba52.sourceforge.net/.
Versione usata: 0.7.4
Ne avete bisogno se intendete acquisire da DVD.
Non servono opzioni particolari nella compilazione, quindi la solita sequenza configure/make/install è senza particolari parametri.
Sono le librerie di base per il DivX. Non sono distribuite come sorgenti, ma solo come librerie condivise.
Potete prelevarle dal sito: http://www.divx.com/.
Versione usata: 5.01 alfa (divx4linux501-20020418.tgz)
E' opzionale, ne avete bisogno per acquisire e creare AVI/DivX.
Non necessitano di compilazione, basta installarle seguendo le istruzioni nel pacchetto.
E' un codec MPEG-4 open source.
Potete prelevarlo da: http://www.xvid.org.
Versione usata: 1.0.0-rc1
Opzionale, ne avete bisogno per acquisire e creare AVI/Xvid.
Gli script di configurazione sono nella nella directory build/generic, per cui anche con xvid si può usare la sequenza di installazione solita.
E' stato anche risolto il problema dell'installazione degli header. E' rimasto un problema con il pacchetto avifile che continua a non rilevare il codec Xvid, anche se installato. Fra l'altro nell'installazione non viene creato il link simbolico libxvidcore.so nella directory delle librerie per cui createlo voi a mano con:
ln -s /usr/local/lib/libxvidcore.so.4.0 /usr/local/lib/libxvidcore.so
seguito dal comando:
ldconfig
entrambi dati da user root.
E' la libreria di base per l'uso del formato DV, quello delle videocamere di ultima generazione. Permette codifica, decodifica e riproduzione.
Potete prelevarlo da: http://libdv.sourceforge.net/.
Versione usata: 0.101
Opzionale, se avete videocamere DV ne avete bisogno.
Non avendo né videocamera DV, né porte FireWire (IEEE1394) non la uso, quindi non posso aiutarvi con questa. Non so se esiste software di acquisizione video da FireWire.
La compilazione non richiede opzioni speciali nel configure.
Librerie e utility per l'uso dei formati OGG Vorbis.
Potete prelevare il tutto da: http://www.vorbis.com/download.psp.
Versioni usate: libogg 1.0, libvorbis 1.0, vorbis-tools 1.0.
Vanno installati in questo ordine, per rispettare le dipendenze reciproche. La compilazione non richiede opzioni speciali.
E' una delle due librerie di base per leggere a basso livello i DVD video, insieme a libdvdread. Senza queste due librerie non potete navigare e decodificare i DVD, cifrati o in chiaro che siano. Permettono ad esempio di acquisire un singolo capitolo, oppure un gruppo di capitoli, un intero titolo, ecc.
Questa libreria consente la lettura dei DVD codificati con l'algoritmo CSS.
Potete prelevarla da: http://www.videolan.org, dalla sezione Developers.
Versione usata: 1.2.8
Opzionale, ne avete bisogno se dovete acquisire da DVD.
Non ha opzioni particolari per il configure, quindi la solita sequenza configure/make/make install funziona normalmente.
Questa libreria invece permette di navigare i DVD. Permette ad esempio di acquisire un singolo capitolo, oppure un gruppo di capitoli, un intero titolo, ecc.
Potete prelevarla da: http://www.dtek.chalmers.se/groups/dvd/downloads.shtml, oppure cercatela su FreshMeat.
Versione usata: 0.9.4
Opzionale, ne avete bisogno se dovete acquisire da DVD, e richiede libdvdcss.
Non ha opzioni particolari per il configure, quindi la solita sequenza configure/make/make install non richiede particolari operazioni.
E' una serie di librerie per la decodifica/manipolazione di file AVI. Se nel sistema sono installate le librerie SDL crea un player AVI. Se avete KDE crea anche un player per Qt.
Potete prelevarlo da: http://avifile.sourceforge.net.
Versione usata: 0.7.38
Non è fondamentale, ma non fa male averlo, in quanto offre alcuni tools interessanti, tra cui avirec per registrare da schede di acquisizione video che siano Video4Linux compatibili (per esempio le Pinnacle PCTV e DC10+).
Per qualche motivo che non ho compreso, non rileva automaticamente la presenza dei codec Xvid versione 0.9.0 e 0.9.1, per cui al momento del configure occorre passare come parametri --with-xvid-prefix=/usr/local --enable-xvid, dove /usr/local è la directory di base dell'installazione usata per Xvid, mentre la versione 1.0.0 di xvid non è proprio supportata, come riportato nella mailing list di Avifile.
Se avete un computer non molto potente, ma volete comunque catturare video in qualità accettabile, potete usare questo recorder che usa un codec video MJPEG molto veloce. Non è il massimo della qualità, ma vi permette di catturare video a 25 frame per secondo in 384x288 con un Pentium 233 MMX. Avete letto bene. E' molto efficiente con un video di buona qualità e con pochi dettagli, tipicamente i cartoni animati.
Potete prelevarlo da: http://freshmeat.net, cercando "nuppelvideo". Opzionale.
Il formato file è conosciuto da Transcode.
Solita installazione.
Altro pacchetto fondamentale. Il codec viene utilizzato in Transcode, anche se l'integrazione fra i due pacchetti non è ancora completa, e le sue funzioni in parte sono duplicate da Transcode, ma ha molti tools interessanti e ben fatti, ed ha la possibilità di regolare molte opzioni di generazione. Il codec MPEG1 è di ottima qualità.
Potete prelevarlo da: http://sourceforge.net/projects/mjpeg/ o cercarlo su FreshMeat. Nella pagina trovate i pacchetti da cui dipende e quelli opzionali.
Versione usata: 1.6.1.93
L'installazione è la solita, se volete opzioni aggiuntive come Quicktime4Linux o il formato movtar, seguite passo-passo le istruzioni contenute nel pacchetto. Se avete intenzione di lavorare con telecamere digitali e con il formato DV PAL usate configure --with-dv-yv12.
Arriviamo al dunque. Questo è uno dei pacchetti principali. Come suggerisce il nome, si usa per convertire il video da un formato all'altro. Non solo, permette operazioni come l'applicazione di filtri, cambio di dimensione delle frames, ricodifica dell'audio, ecc.
Potete prelevarlo da: http://freshmeat.net, cercando "transcode". Nella pagina trovate anche i link per i pacchetti da cui dipende e quelli opzionali, praticamente tutti quelli citati finora.
Versione usata: dalla 0.6.3 alla 0.6.12
Questo pacchetto è fondamentale, quindi occorre installarlo.
Per il configure usate questa opzione: --enable-liba52, che abilita l'uso della liba52 di default. Questo perché nel mio caso succedeva che la decodifica AC-3 inclusa in Transcode introduceva un disturbo sul canale destro del segnale audio stereo. Ho anche tentato una compilazione con due diverse versioni di gcc, ma il problema persiste. Con questa opzione invece Transcode usa di default la liba52 citata poco sopra, che non ha questo problema.
Se non trova la libreria ImageMagick (usata per alcune operazioni sulle singole frame), vuol dire che non ne trova gli header, ossia non è installato il pacchetto RPM ImageMagick-devel.
La versione 0.6.12 ha un problema nel plugin resample, va in segmentation fault appena avviata la conversione. E' un conflitto con il tool di manipolazione audio sox, usato per la conversione di frequenza di campionamento dell'audio. Se avete un audio a 48000 (la traccia audio di un DVD per esempio) e volete convertirlo a 44100 (per usarlo con un VCD) non sarà possibile usare il plugin di ricampionamento. Una possibile soluzione, se usate MPEG layer 2, è di selezionare l'output tramite toolame
E' un editor molto semplice per i file AVI, ma è veloce e efficiente. Permette di navigare all'interno del file e di tagliarlo a piacere. Lo uso per determinare i cambi di scena e scegliere il punto dove tagliare i filmati.
Potete prelevarlo da: http://fixounet.free.fr/avidemux/ o al solito da http://freshmeat.net, cercando "avidemux".
Versioni usate: 0.9 (stable) e 2.0.20 (unstable).
Solita installazione.
Quando avete i vostri filmati MPEG rimane il problema di scriverli su VCD/SVCD. VCDimager permette la creazione di VCD e SVCD a partire dai file MPEG.
Potete prelevarlo da: http://www.vcdimager.org/.
Versione usata: 0.7.14 (unstable) o 0.6.2 (stable).
Nel sito trovate molte informazioni sui formati dei video CD, oltre a link verso i tool di creazione, molti dei quali sono elencati sopra. Trovate anche link per interfacce grafiche a vcdimager, come pure parecchie informazioni su (S)VCD e derivati. Personalmente ho usato qualche volta "qvcd" per librerie grafiche Qt, come al solito è questione di preferenze personali.
Finita l'opera di cattura, editing e rendering del vostro video in (S)VCD (o magari DVD) non resta che scriverlo su CD-R. Uno dei pacchetti necessari è appunto questo, che permette di scrivere immagini di tipo BIN/CUE su CD registrabile usando il metodo Disk-at-Once.
Potete prelevarlo da: http://sf.net/projects/cdrdao.
Versione usata: 1.1.7
Nel pacchetto trovate anche altre utility, tipo cdparanoia per il ripping dei CD audio.
Solita installazione.
Per vedere il vostro video prima durante e dopo le manipolazioni, usate l'ottimo player Xine. Di solito è disponibile nei CD della vostra ditribuzione, ma se non vi fosse potere prelevarlo dal solito http://freshmeat.net, cercando "xine". L'unico formato file che non riproduce è il NuppelVideo, ma dato che nel pacchetto di quest'ultimo vi è un semplice player, non dovrebbe essere un grosso problema.
La versione che ho io (quella inclusa in RedHat 7.3) ha qualche problema con gli AVI in DivX/Xvid in quanto spesso va fuori sincrono audio/video durante la riproduzione, specialmente se l'audio è in PCM lineare, ossia non compresso. Non ho provato altre versioni, anche perché non ne ho avuto il tempo, e comunque il fatto che audio e video siano fuori sincrono in riproduzione non vuol dire che il file sia rovinato o inutilizzabile.
Esiste una quantità impressionante di formati video, ma in generale possiamo suddividerli per categorie in funzione delle caratteristiche che ci interessano. Ad esempio una prima classificazione possiamo farla distinguendo tra formati che possiamo riprodurre solo con il computer e formati che possiamo riprodurre anche con il lettore DVD collegato al nostro TV. La principale differenza tra i due tipi è che per i formati da riprodurre con il PC abbiamo la libertà totale di usare a piacimento codec video e audio, con dimensione della frame e bitrate assolutamente a nostra discrezione, mentre per i formati da lettore DVD le specifiche sono molto restrittive, anche se sul mercato iniziano a presentarsi lettori DVD che leggono AVI/DivX (i prezzi sono esagerati per ora).
Una seconda classificazione distingue tra formati utili per registrare ed editare il video e formati per la riproduzione e distribuzione. In questo caso la distinzione è molto più sottile e spesso il confine evanescente. Ad esempio MPEG2 video è utile sia per la distribuzione che per l'editing, mentre video codificati MJPEG non sono molto pratici da distribuire a causa della dimensione.
Esistono molti editor per file MPEG1/2 e AVI, e l'MPEG1/2 è un formato molto utilizzato in ambito professionale, anche per la presenza sul mercato di schede di compressione/decompressione hardware (di costo abbastanza elevato per usi casalinghi). Il problema è che le operazioni di editing sono abbastanza rapide, ma al momento di creare il file definitivo occorre rigenerare l'intero file con una operazione detta "rendering", che spesso significa decodificare tutte le singole frames del filmato e ricodificarle di nuovo, con tempi di esecuzione non trascurabili. Esiste la possibilità di effettuare semplici operazioni di taglia e incolla (per esempio per togliere la pubblicità da un programma registrato dalla TV) senza dover per forza rigenerare l'intero file.
Vediamo in dettaglio alcuni formati.
Utilizzando un normale CD-R da 80 minuti (700Mbytes) si possono archiviare 80 minuti circa di video con qualità paragonabile ad un buon VHS. Il formato del video però è molto restrittivo, ed al momento lo standard VCD2.0 permette queste varianti:
Il video può essere in uno di questi tre formati:
Se volete quindi fare un VCD che sia riprodotto dai lettori DVD in commercio dovete rispettare queste specifiche. Esiste una ragione per cui il bitrate è proprio quello: se fate la somma di tutti i flussi (1150+224) ottenete 1374 kbit/sec, ossia un valore molto vicino ai 1400 kbit/sec del CD audio standard, per cui un normale lettore di CD legge i VCD a velocità 1x costante.
Potete creare VCD con bitrate audio e video differenti, ma non è detto che vengano riprodotti dai lettori di DVD, per cui vi conviene fare al limite delle prove con videoclip brevi, usando un CD-RW se il vostro lettore di DVD li accetta. Ad esempio, alcuni lettori accettano bitrate più elevati, fino a 4000 kbit/sec per il video, come pure accettano bitrate diversi per l'audio, ed in qualche caso accettano anche audio MPEG Layer 3 invece di Layer 2. Tutti e tre i lettori che ho potuto provare sono invece molto intolleranti alla dimensione della frame, ed in tre casi su tre hanno rifiutato VCD con frame size "strane" (640x480, 512x384, 640x288 e simili).
E' possibile creare dei VCD con menù iniziale animato, simile a quello dei DVD, ma non è navigabile e serve solo ad indicare l'associazione traccia/tasto del telecomando.
Esiste un formato non ancora standardizzato che prevede anche l'uso di sottotitoli ed altre features simili a quelle del DVD, ma è poco conosciuto e supportato.
Se volete maggiori informazioni potete vedere su:
Con la diffusione dei lettori CD 2x fu approvato uno standard migliore per i CD video, che prevede doppio audio stereo o AC-3 e sottotitoli. La qualità è migliore, teoricamente paragonabile ad un buon Super-VHS, ma in questo caso un CD-R da 80 minuti (700Mbytes) contiene circa 40 minuti di video.
Anche in questo caso però il formato è piuttosto restrittivo:
Il video può essere in uno di questi formati:
Anche per i SVCD potete provare bitrate differenti, ma come per i VCD non è detto che tutti i lettori in commercio li accettino.
Anche per i SVCD è possibile inserire un menu.
Se volete maggiori informazioni potete vedere su:
E' un modo generico per indicare tutti i formati video sotto forma di file. Ne esistono di due tipi base, uno detto ES (Elementary Stream) che contiene semplicemente la sequenza di dati video senza informazioni aggiuntive, ed uno detto PS (Program Stream o System) che è un flusso composito contenente audio, video, informazioni di sincronizzazione e altro, in multiplexing. Il video può avere qualsiasi bitrate, e l'audio è di solito in MPEG1 Layer 2. Il frame rate, la dimensione, l'aspetto e tutti gli altri dati di caratterizzazione del flusso video sono a piacere, ovviamente entro limiti abbastanza ampi. Può essere a bitrate fisso o variabile.
Ovviamente, se volete riportare il vostro video su (S)VCD, occorre rispettare strettamente i limiti imposti dallo standard (S)VCD.
E' un formato file, più che un formato video. AVI sta per Audio-Video Interleaved, ossia il modo in cui è strutturato il file. Per ognuno dei due componenti è definito il codec corrispondente, per cui i file AVI possono avere combinazioni dei seguenti:
La combinazione più usata è ovviamente DivX/MP3.
Ha una limitazione intrinseca nel formato che impone massimo 2 Gbytes totali per file, ma in Linux è possibile superare questo limite, a patto di sapere che i file corrispondenti non saranno leggibili da tutte le applicazioni.
Ad esempio nelle mie applicazioni casalinghe catturo il video in formato DivX5 a 1750 kbit/sec con audio PCM, usando circa 1,4Gbytes per ogni ora di video catturato. Ottengo spesso file da 1-2G, che poi suddivido e lavoro separatamente per creare dei VCD, senza problemi.
Vediamo come sia possibile con un PC abbastanza spartano prendere un programma dalla TV e farne un VCD.
Partiamo da una configurazione che conosco: il mio PC. Non avendo molti soldi da spendere, il mio PC non è proprio l'ultimo grido. E' un Pentium III 500MHz, con 448M di RAM (64+128+256), due dischi IDE uno per il sistema operativo ed uno per i dati video (acquistato ultimamente, da 80G). Ho acquistato una scheda TV basata sul chipset Philips SAA7134, verificando prima che il chipset fosse supportato dal layer multimediale Video4Linux, spendendo meno di 80Euro.
Con altri 15Euro ho acquistato un buon cavo videocomposito con due RCA per l'audio, ossia il classico cavo con i tre connettori RCA giallo-bianco-rosso, e un adattatore da doppio RCA a jack stereo.
Uso come sorgente il videoregistratore, dato che preferisco non usare il sintonizzatore della scheda TV. Ho collegato il videoregistratore all'ingresso videocomposito della scheda e tramite l'adattatore RCA-jack stereo ho mandato l'audio stereo all'ingresso della scheda audio.
La scheda ha ingresso videocomposito e S-Video, ma il mio videoregistratore esce solo in videocomposito, quindi la scelta è stata obbligata.
La scheda da me acquistata non è direttamente supportata dai kernel serie 2.4 (lo sarà nella serie 2.6). Dal sito http://bytesex.org ho prelevato sia la patch per Video4Linux versione 2 e il modulo kernel per le schede di cattura video basate su SAA7134. Ho dovuto prelevare i nuovi sorgenti del kernel versione 2.4.20 e applicarvi la patch, configurarlo, compilarlo e installarlo. Dopodiché ho compilato e installato il modulo per la scheda. Al caricamento del modulo kernel viene correttamente riconosciuta e attivata.
Ovviamente tutte le operazioni elencate finora non coinvolgono mai visualizzazioni o interfacce grafiche, tutto avviene via console e riga di comando. Per poter vedere cosa entra nella scheda ho scaricato e installato dallo stesso sito del driver della scheda il programma xawtv, perché la versione distribuita insieme ai dischi della RedHat 7.x è inadeguata.
Lo stesso programma permette di catturare singoli fotogrammi o filmati, ma i formati disponibili non sono molti. Nella mia scheda, per default, la dimensione dello schermo televisivo è di 384x288 pixel. Si può aumentare fino a 720x576, ma in questo caso ci sono problemi di interlacciamento, e comunque la vera risoluzione video disponibile è la prima, e per le prove che ho fatto il deinterlacciamento è una operazione delicata e estremamente problematica, oltre che piuttosto pesante per il processamento.
Arriviamo al momento di registrare il primo video. La prima cosa da fare è scegliere il codec video e audio giusti. Codec che creano file meno grandi di solito sono più pesanti come elaborazione. Codec che comprimono poco il video sono molto pesanti per la scrittura dei dati su disco. Quindi occorre trovare un compromesso che ci garantisca un buon risultato senza occupare spazio eccessivo e senza caricare troppo il processore, nel qual caso perderemmo frame ed il filmato risultante sarebbe inguardabile. Ne ho provati parecchi, ed alla fine il migliore è il codec DivX5 per il video, mentre per l'audio uso il PCM, ossia nessun codec. La cattura avviene in 384x288 pixel, 25 frame per secondo, audio PCM a 44100 Hz, 16 bit per campione, stereo.
Incredibile, ma vero. Ho provato vari tipi di codec MPEG1/2 ma tutti erano estremamente pesanti, arrivando al massimo a 12-15 frame al secondo con il processore al 100%. Atri codec tipo YUV4MPEG sono molto meno pesanti, ma richiedono dischi molto veloci ed estremamente capienti. Per fare un esempio, la cattura di 67 secondi di un talk show ha creato un file di 450M perdendo il 5% delle frames per il sovraccarico dell'I/O disco. Ovviamente lo spazio occupato dipende dalla complessità delle scene e da quanto cambiano nel tempo. Eventi sportivi e film d'azione sono i peggiori.
Esiste poi il problema della perdita di frame dovuta al carico del processore. Il problema è causato non tanto dal meccanismo di cattura, che in Linux è a prova di bomba, ma dalla dimensione del buffer delle frames. Mi spiego. La cattura dei filmati avviene in tre processi distinti:
Il primo processo è gestito dai meccanismi di IRQ e DMA del kernel di Linux, per cui se le frames ci sono vengono prelevate. Il buffer delle frame è una FIFO di solito di 20-30 frames, che il codec preleva e codifica. Se il codec video non preleva abbastanza rapidamente le frame da codificare, il buffer si riempie e il processo che legge le frames non trova spazio per memorizzare nuove frames, che vengono "buttate". Il processo che fornisce frames al codec, non trovando alcune frames di solito le sostituisce duplicando l'ultima frame disponibile. Il filmato risultante ha un effetto "moviola a scatti" caratteristico.
La situazione viene peggiorata dall'uso di codec che sono sensibili alla complessità delle scene, come i codec MPEG1/2/4 e derivati (DivX, Xvid e simili). In scene complesse e con molta azione questi codec consumano più tempo processore a parità di qualità dell'immagine finale. Usano delle tecniche basate su come la vista percepisce il movimento, diminuendo dinamicamente la qualità dei dettagli quando la sequenza video contiene molto movimento, ma questo comportamento implica un aumento del carico del processore. Aumentando il movimento, aumenta il carico del processore, ed aumenta la possibilità di perdita delle frame. Vediamo come evitare o limitare il rischio.
Il programma di cattura che permette un controllo estremamente accurato di tutte le fasi della cattura è proprio Transcode.
La cattiva notizia (se così si può dire) è che funziona con interfaccia a riga di comando, quindi occorre usare switch, parametri e argomenti. Partiamo direttamente con la riga di comando per registrare un filmato in AVI con le seguenti caratteristiche:
La riga di comando è:
transcode -i /dev/video0 --import_v4l 1 -p /dev/dsp \ -x v4l -g 384x288 -e 44100,16,2 -M 0 -n 0x01 \ -y divx5 -Q 4 -w 1700 -N 0x01 -o videoclip.avi \ -V -u 500 -q 2
Calma. Non fatevi intimidire, è meno complicato di quello che sembra. Per meglio inquadrare le cose ho diviso il comando in quattro sezioni:
L'opzione -i permette di scegliere da cosa leggere il flusso dati audio/video. Può essere un singolo file, una directory, un device lettore di DVD o un device Video4Linux compatibile. Nel nostro caso è /dev/video0, ossia l'input viene dalla scheda di cattura video. L'opzione --import_v4l serve a indicare l'input video da utilizzare, per esempio nella mia scheda l'input 0 è l'ingresso antenna e bisogna specificare anche il canale da cui si vuole registrare, mentre l'ingresso 1 è il videocomposito ed il 2 è S-Video. In questo caso prendiamo l'input dall'ingresso videocomposito.
Alcune schede di cattura video hanno la possibilità di catturare audio dai canali televisivi (anche in stereo), ma spesso la qualità non è eccelsa, e per di più molte schede campionano soltanto a 32kHz, un po' poco. In questo caso transcode ci viene in soccorso con l'opzione -p che permette di specificare una sorgente audio differente, escludendo i dispositivi Video4Linux che hanno un loro audio. In questo caso viene prelevato l'audio dalla scheda audio standard del PC, indicando appunto come parametro /dev/dsp.
Passando alla seconda riga, l'opzione -x specifica il tipo di sorgente, ossia, nel nostro caso, un dispositivo Video4Linux. Il resto lo fa transcode, impostando i parametri del device e preparando le proprie strutture interne di lavoro. Per evitare problemi, specifichiamo il formato sia del video che dell'audio in input: con l'opzione -g diamo la dimensione della frame in pixel nel formato LxH, con l'opzione -e diamo il formato dell'audio, ossia frequenza di campionamento, bit per campione e modo (1 per mono e 2 per stereo). Spendiamo due parole per questo. Per quanto riguarda la frequenza di campionamento, vi conviene scegliere quella che sarà la frequenza del supporto finale, ossia se volete farne un VCD o SVCD scegliete 44100Hz, se invece volete farne un DVD vi conviene scegliere 48000Hz, in modo da evitare conversioni di frequenza di campionamento, sempre rognose. Se invece intendete farne un DivX da distribuire su CD-ROM o Internet scegliete a piacere, ovviamente tenendo conto della qualità della sorgente. Se ad esempio riversate da VHS è inutile salire sopra 44100Hz, e spesso anche 32000Hz sono più che accettabili.
L'opzione -M 0 disabilita qualsiasi operazione di risincronizzazione fatta da transcode, che deve accettare per buoni sia il frame rate del video che quello dell'audio così come escono dai device di acquisizione.
L'opzione -n serve a indicare il tipo di codifica audio in ingresso e, ovviamente, usando l'ingresso della scheda audio, non può essere che PCM.
La sezione successiva è il formato scelto per l'output. L'opzione -y è quella che ci consente di scegliere il formato file ed i codec in output. Nell'esempio uso il formato AVI, implicito quando si sceglie il codec DivX. Le opzioni -Q e -w servono rispettivamente a scegliere la qualità ed il bitrate del file DivX. Transcode mette a disposizione 6 diversi preset per il codec DivX, selezionati appunto tramite l'opzione -Q, e indicati con un numero da 0 (qualità minima) a 5 (massima). Ovviamente scegliendo una qualità minima, il codec è molto veloce, ma la qualità è orrenda. L'opzione -w permette di scegliere il bitrate del solo video in kbit/sec. Anche qui, un bitrate basso rende il codec più veloce, a prezzo di una qualità inferiore.
La scelta di questi due parametri è fondamentale per equilibrare carico del processore, spazio occupato e qualità del video finale. Molto dipende anche dalla qualità della sorgente video. Ad esempio se si riversa da un VHS di qualità non eccelsa una buona parte del bitrate finale è impegnato dal rumore di fondo del nastro, mentre registrando direttamente dal videocomposito una trasmissione in diretta, spesso il risultato è indistinguibile dall'originale. Un altro fattore che pesa sia sul bitrate che sul carico del processore, è la quantità di movimento contenuto nel video. Una trasmissione televisiva tipo un talk-show ha pochi cambi di scena e poco movimento, mentre un film d'azione o un evento sportivo sono dei veri tour-de-force.
I valori indicati nell'esempio sono un buon compromesso, e sono riuscito a registrare sia film d'azione in diretta che a riversare VHS con una qualità accettabile.
Se il vostro PC lo permette, potete aumentare la qualità alzando prima il bitrate (fatelo a passi di 100kbit/sec), oppure riducete il bitrate e portate la qualità al massimo. Per dare una valutazione grossolana, un 1700kbit in qualità 4 è simile ad un 1100 kbit in qualità 5, ma il carico del processore nel secondo caso è notevole (il mio PC non è in grado di reggerlo).
L'opzione -N indica che tipo di codec audio deve essere usato nell'AVI finale. Nel mio caso, per risparmiare prezioso tempo processore, uso il codec PCM, ossia nessuna compressione.
Come avrete intuito, l'opzione -o dice a transcode come si chiamerà il file AVI risultante. Dovete specificare anche l'estensione.
Siamo quasi all'arrivo. Rimangono le opzioni che regolano il funzionamento di transcode. L'opzione -V istruisce transcode per l'uso di un formato interno nella rappresentazione delle immagini detto YV12, che rende le operazioni intermedie più veloci, a volte anche di un 40%. Se ad esempio effettuate dei ridimensionamenti della frame, o applicate un filtro, con questo tipo di rappresentazione si risparmia parecchio tempo. Solo in qualche caso occorre usare la rappresentazione RGB, in quanto alcuni dei filtri disponibili in transcode non accettano la rappresentazione YV12.
L'opzione -q imposta il livello di prolissità di transcode, ossia quante informazioni stampa a video durante l'esecuzione. Il default è 1, ossia un livello informativo normale, mentre 2 indica una maggiore quantità di informazioni.
Arriviamo all'ultima opzione, una delle più importanti. Come detto predentemente, se il filmato che stiamo catturando contiene sequenze di azione seguite da momenti di calma, potrebbe capitare che nelle sequenze "tranquille" il PC regge bene il carico e non perde frames, mentre se c'è una sequenza d'azione di tre minuti (tipica degli action movie) il processore si carica al 100% ed iniziano a perdersi frames in pochi secondi. Transcode di default usa un buffer per dieci frames, ed è decisamente poco. L'opzione -u permette di definire quanto deve essere profondo il buffer. Sperimentando qua e là, ho trovato che in sequenze di azione particolarmente lunghe si arriva ad accumulare oltre 300 frames. Ma se il buffer è grande abbastanza da contenerle tutte, passata la sequenza "movimentata", durante le sequenze "tranquille" il buffer viene svuotato lentamente utilizzando il tempo processore che avanza.
Se disponete di una buona quantità di RAM alzate pure il numero di frames nel buffer (io l'ho impostato a 500), considerando che ogni frames occupa uno spazio proporzionale alla dimensione della frame in pixel. Ad esempio con 500 frames da 384x288 si occupano circa 105M di RAM solo per transcode. Ma se serve a non perdere frames non abbiamo alternative.
Già. Decidete cosa farne, le opzioni non sono poi molte:
Partendo però da una situazione reale, il video che abbiamo potrebbe essere non proprio pulito, per esempio con le pubblicità. Oppure, come preferisco fare di solito, interrompo la registrazione ad ogni spazio pubblicitario, e la riprendo quasi subito, in modo da avere spezzoni più "maneggevoli". La situazione è la seguente: ho registrato un film dalla TV, in quattro spezzoni rispettivamente da 20, 33, 38 e 25 minuti, con la pubblicità in testa ed in coda. Ne voglio fare dei VCD standard. La procedura è spiegata di seguito, divisa per fasi, supponendo di aver catturato il video in 4 file dal nome clip1.avi, clip2.avi, clip3.avi, clip4.avi.
Con avidemux aprite i file AVI e con i tasti di navigazione cercate le frame esatte in cui inizia e finisce lo spezzone di film, escludendo così la pubblicità. Non fate nessuna modifica, annotatevi soltanto la frame iniziale e finale di ogni spezzone. Se avete usato le impostazioni di default per generare il Divx vi troverete che quasi sempre l'inizio del film coincide con una delle keyframes, per cui usando i tasti di navigazione di avidemux troverete abbastanza rapidamente i punti che vi interessano.
Annotatevi per ogni spezzone la frame d'inizio e quella finale. Se ci sono delle pubblicità all'interno dello spezzone, annotatevi la frame iniziale e finale esatte per ogni pubblicità.
A titolo di esempio, supponiamo che nello spezzone clip1.avi il film inizi alla frame 273 e finisca alla frame 28176.
Adesso si dovrebbe avviare la sequenza di transcodifica dall'AVI a MPEG con transcode. Al momento transcode, pur avendo il codec di mjpegtools incluso, non permette un controllo accurato delle opzioni di codifica (per ora, ma ho letto nella mailing list di transcode che stanno provvedendo anche a questo). Per cui occorre operare in modo più complesso, ossia mettendo l'uscita di transcode direttamente in ingresso al codec di mjpegtools. Dopo varie prove e peripezie, ho trovato che la migliore configurazione per far questo è la seguente:
transcode -i clip1.avi -V -y yuv4mpeg,mpeg -b 224 -Z 352x288 \ -c 273-28176 -o videofifo -k -C 2
cat videofifo.mpa > clip1.mpa
cat videofifo | mpeg2enc -f 1 -n p -o clip1.m1v
A questo punto, dopo aver lanciato il terzo comando, vedrete che sulla console dove avete lanciato transcode inizia a contare le frames in ingresso, mentre nella console dove avete lanciato mpeg2enc vedrete scorrere una serie di informazioni sul procedere della codifica.
Vediamo di capire meglio. Il primo comando, che usa transcode, separa i due flussi audio e video, codificando l'audio in MPEG Layer 2 a 224 kbps e lo scrive nella FIFO videofifo.mpa, per il video invece prende singole frame dal file AVI in sequenza, e le esporta nella FIFO in formato YUV4MPEG, dopo aver fatto un resize alla dimensione standard della frame del VCD.
L'encoder riceve attraverso la FIFO le frame video e le trasforma in un file MPEG1 video, di tipo Elementary Stream (ES).
Il tempo di elaborazione è estremamente dipendente dalla velocità del vostro processore. Nel mio caso, un PIII 500, la velocità va da 6 a 3 frames al secondo, ossia da 4 a 8 ore per ogni ora di video. La velocità dipende anche dalle operazioni aggiuntive e dalla qualità finale richiesta. Ovviamente maggiore è la qualità, minore è la velocità.
Più avanti vedremo meglio la funzione dei vari parametri e come massimizzare la qualità, anche a basso bitrate.
Finita l'operazione di codifica, otteniamo due file: uno contenente il flusso video MPEG1/ES (clip1.m1v), ed uno contenente il flusso audio (clip1.mpa). Per poterli utilizzare, occorre trasformali in un unico file, in un particolare formato interno detto Program Stream, un flusso audio/video in multiplexing, ossia il classico file MPEG. Il programma che fa questo si chiama mplex (incluso nel pacchetto mjpegtools), Nel nostro esempio il comando sarà:
mplex -f 1 -o clip1.mpeg clip1.m1v clip1.mpa
ed alla fine avremo il nostro file MPEG in formato VCD standard.
Così facendo, avremo il primo segmento dei quattro detti sopra. Ripetiamo l'operazione di individuazione di inizio e fine degli spezzoni e successiva codifica in MPEG1, alla fine del quale avremo quattro file con estensione m1v e quattro con estensione mpa.
Una volta che abbiamo i segmenti video e audio, occorre riunirli in modo da avere un solo file MPEG. Il metodo migliore che ho trovato è il seguente, facendo sempre riferimento ai quattro segmenti citati sopra:
cat clip1.m1v clip2.m1v clip3.m1v clip4.m1v > filmato.m1v
cat clip1.mpa clip2.mpa clip3.mpa clip4.mpa > filmato.mpa
mplex -f 1 -M -o filmato.mpeg filmato.m1v filmato.mpa
Durante il multiplexing il programma vi darà dei warning lamentandosi del fatto che trova gli END SEQUENCE marker ma non può dividere il file perché gli abbiamo detto di non farlo. Ignorateli.
Alla fine avrete il vostro file totale con tutto il film, con nome filmato.mpeg.
Ottenuto il file video in formato VCD standard, occorre poi creare un VCD in modo da poterlo riprodurre da un normale DVD player collegato al TV.
Non è infatti sufficiente masterizzare un normale CD-ROM con dentro il file MPEG, in quanto la struttura di un VCD è abbastanza differente: ha almeno due tracce registrate (tracce nel senso inteso dallo standard ISO), la prima è in effetti una traccia dati in formato ISO9660 (il normale CD-ROM), mentre la seconda traccia è in formato MODE2/XA con settori di 2324 bytes. Quindi la prima traccia esiste sempre ed è una traccia dati, mentre le successive rappresentano ognuna una clip video. Se ad esempio abbiamo 6 clip video in un VCD, avremo 7 tracce registrate, la prima con dati, le altre 6 con gli spezzoni, e premendo il tasto 3 nel telecomando del lettore DVD manderemo in riproduzione il terzo video sul VCD. Inserendo questo ipotetico VCD nel lettore CD del nostro PC, noteremo che viene letto come un normale CD-ROM, in apparenza. Dentro troveremo una directory chiamata mpegav, con dentro 6 files: avseq01.dat, avseq02.dat, avseq03.dat, avseq04.dat, avseq05.dat, avseq06.dat. Questi file in realtà sono virtuali, e servono solo come puntatori al settore di inizio di ogni clip.
Comunque, tutti questi dettagli non sono necessari per creare un VCD, in quanto il programma vcdimager si occupa di tutti i dettagli. Tornando al nostro file, il comando per creare un VCD è:
vcdimager -l "Il mio primo VCD" -p filmato.mpeg
dove l'opzione -l permette di specificare l'etichetta della traccia CD-ROM (può essere omesso), l'opzione -p mostra un conteggio che ci informa del progredire dell'operazione. Alla fine dell'operazione avremo due nuovi file, videocd.bin e videocd.cue, che sono l'immagine binaria del VCD ed il file indice delle tracce. Questi due file sono pronti per l'uso con il programma di masterizzazione cdrdao che trasferisce l'immagine videocd.bin su un CD-R in una unica operazione. Il comando è:
cdrdao write --speed 12 --device 0,1,0 videocd.cue
dove l'opzione --speed indica al programma di scrivere alla velocità 12x e l'opzione --device indica qual è l'indirizzo SCSI del masterizzatore. Se avete un masterizzatore IDE invece di SCSI, dovrete usare l'emulazione SCSI per IDE, implementata nel modulo kernel ide-scsi.
Quanto video entra in un VCD standard? La risposta è semplice: su un CD-R da 74 minuti entrano esattamente 74 minuti di video. Ovviamente in un CD-R da 80 ne entrano 80. Il calcolo è semplice:
settori totali * 2324 * 8 / bitrate VCD = secondi di video
dove settori totali è il numero dei settori utili nel CD-R (333.000 nel 74' e 358000 in un 80'), che moltiplicato per i byte per settore (2324) e per i bit per byte (8) dà il numero di bit utili totale nel CD-R, mentre il bitrate VCD è dato dalla somma del bitrate video (1.152.000 bit per secondo) del bitrate audio (224.000 bit per secondo) e un flusso di dati supplementari (timecode, sincronismi, ecc.) che possiamo stimare fra 10.000 e 15.000 bit per secondo. Risultato: 4450 secondi (poco più di 74 minuti) per un CD-R74 e 4780 secondi (circa 80 minuti) per un CD-R80.
Il VCD standard non ha effettivamente una grande qualità, dovuta anche al fatto che rispettare un bitrate così basso (parlando di video, ovviamente) pur con una dimensione del frame ridotta come appunto quella del VCD, non è proprio facile. Tanto per dare una misura, il DVD standard prevede 9.800.000 bit per secondo solo per il video, un videoregistratore digitale professionale 20Mbps, il formato interno per gli editor video digitali professionali è 50Mbps ed il video digitale non compresso è standardizzato a 270Mbps con frame di 768x576 pixel. Come vedete i numeri sono ben altri. Si può però fare di meglio anche con il VCD, operando su alcuni parametri ed "allargare" un po' le misure imposte dallo standard. Quindi, munitevi di CD-RW e controllate che il vostro lettore DVD-home legga i VCD masterizzati su CD-RW (per non sprecare inutilmente supporti), e prendete dei file video corti per fare le prove, 3 o 4 minuti al massimo. Magari passate ore a codificare un filmato per poi accorgervi di aver sbagliato un parametro, o aver usato un formato che provoca l'orticaria al vostro lettore DVD. Quindi, ripeto, CD-RW e file video di 3-4 minuti per le prove. Magari prendete sequenze di azione o scene con molti dettagli, per mettere in crisi l'encoder e vedere i difetti di codifica.
No. Certo, il bitrate conta, ma non quanto potrebbe sembrare affidandoci al solo buonsenso. Paradossalmente, un video codificato MPEG1 a 4Mbps può risultare molto peggiore di uno a 1,7Mbps. Per capire perché occorre conoscere tutti i dettagli del funzionamento dell'encoder MPEG, ma saremmo decisamente oltre il fine di questo manualetto, per cui limitiamoci a descrivere i principali parametri e come intervengono sulla qualità.
Nello standard VCD si usa il modello di codifica a bitrate costante, detto CBR, per cui a grandi linee il codec codifica un gruppo di frame, ed arrivato al bitrate indicato, scarta tutti i dettagli che sono al di sotto di una certa soglia. Questa soglia è regolata da un valore detto "valore di quantizzazione" (quantisation value) e nel VCD standard varia per mantenere costante il bitrate. Molti encoder MPEG1 permettono di impostare un valore minimo e massimo per la quantizzazione, e minore è il valore assegnato, maggiore è la qualità finale, ma ovviamente maggiore è il bitrate necessario. Potremmo produrre file MPEG1 impostando il solo valore di quantizzazione, e lasciare libero il bitrate, ma ovviamente non avremmo nessun controllo sulla dimensione finale del file generato. E, peggio, potremmo avere incompatibilità totali con i lettori di DVD home.
Fissando un valore di quantizzazione si ottiene un file MPEG1 video a bitrate variabile (VBR) che non è certo compatibile con lo standard VCD.
Beh, la notizia è che quasi tutti i lettori DVD home (prodotti negli ultimi due anni e che leggono VCD standard) riproducono correttamente anche VCD con MPEG1 VBR. Uniche "stranezze" le potreste riscontrare nell'indicazione del tempo trascorso nel display del lettore. Ma non è certo un problema.
Supponendo di utilizzare la stessa procedura vista prima, il comando da dare usando mpeg2enc è:
cat videofifo | mpeg2enc -f 1 -q 2 -Q 3 -n p -o clip1.m1v
dove ci sono due nuovi parametri:
mentre il parametro -f 1 indica all'encoder che tutti gli altri parametri saranno quelli del VCD standard (bitrate, ecc.), ed il parametro -n indica lo standard televisivo da usare per la codifica e riproduzione (p per PAL, n per NTSC e s per SECAM).
Ovviamente, se impostate i due valori al massimo possibile (-q 1 -Q 0) avrete la massima qualità. Nelle mie sessioni di codifica uso normalmente valori come:
-q 1 -Q 1
per sorgenti di buona qualità, mentre uso:
-q 2 -Q 0.5
per sorgenti a qualità inferiore.
Durante la successiva fase di multiplexing, può succedere che compaiano dei warning di questo tipo:
++ WARN: [mplex] Stream e0: data will arrive too late sent(SCR)=513871 required(DTS)=512913 ++ WARN: [mplex] Video e0: buf= 229428 frame=000084 sector=00000190 ++ WARN: [mplex] Audio c0: buf= 1902 frame=000129 sector=00000042
che indicano che il bitrate impostato nel multiplexing per il VCD standard non è sufficiente, ed il video occupa troppo bitrate rispetto a quanto dovrebbe. Se questo si verifica poche volte (meno di dieci mi pare) il multiplexer arriva al termine e vi segnala un errore di questo tipo:
**ERROR: [mplex] **ERROR: [mplex] MUX STATUS: Frame data under-runs detected!
ed il file risultante dovrebbe essere comunque un VCD senza problemi. Se invece il processo di multiplex si interrompe e viene visualizzato questo messaggio:
**ERROR: [mplex] Too many frame drops -exiting
le cose si fanno più complicate, ed avete due possibilità: o ricodificate il file con un valore di quantizzazione inferiore, oppure create un XVCD.
Esiste la possibilità di creare dei VCD con bitrate video diverso da quello standard, maggiore o minore. In questo caso la compatibilità con i lettori DVD-home è ancora meno assicurata, per cui l'uso di CD-RW e prove con vari bitrate sono d'obbligo. Questo tipo di VCD vengono chiamati XVCD, ma non esiste uno standard, quindi non è detto che se il vostro lettore riproduce i VCD riproduca anche questi.
In pratica, è possibile alzare il bitrate al momento della codifica utilizzando un calcolo abbastanza semplice:
2324 x num_settori x 8
dove num_settori vale 333000 per i CD-R74 è 358000 per i CD-R80 (in realtà è di più, ma tenetevi un margine e usate questi valori). I totali sono 6.191.136.000 bit per CD-R74 e 6.655.936.000 bit per i CD-R80
Otterrete il bitrate massimo totale audio/video che può avere il vostro filmato. Per sapere quanto è il bitrate video da usare, sottraete 230.000 dal valore ottenuto e arrotondate ai 50.000 bit inferiori. Un esempio pratico: un filmato da 45 minuti su un CD-R74. La durata in secondi è 2.700, e dividendo 6.191.136.000 per 2700 otteniamo 2.293.000 (circa). Sottraendo il bitrate audio si ottiene 2.063.000, ed arrotondando 2.050.000, che è il bitrate cercato. Adesso però occorre informare l'encoder MPEG1 che dovrà generare un MPEG1 con impostazioni alquanto differenti dal VCD. Il comando da dare, sempre supponendo di utilizzare lo schema visto sopra:
cat videofifo | mpeg2enc -f 2 -q 1 -Q 1 -V 230 -b 2050 -n p -o clip1.m1v
come vedete alcuni parametri sono cambiati ed altri sono nuovi, ma andiamo con ordine:
I valori di -q e -Q sono quelli che uso di solito.
Al termine della codifica avremo la solita coppia di file, m1v e mpa, che dovremo sottoporre al multiplexing. Anche qui il comando varia alquanto:
mplex -f 2 -b 230 -r 2270 -V -M -o filmato.mpeg clip1.m1v clip1.mpa
e questo è il significato dei parametri:
Al termine dell'operazione avremo il nostro file filmato.mpeg pronto per la masterizzazione. Se seguite alla lettera questi passi, noterete che i file saranno sempre di dimensione notevolmente superiore allo spazio disponibile su un CD-R come CD-ROM. Questo perché il CD-ROM usa solo 2048 bytes per settore del supporto, mentre il (X)VCD usa 2324 bytes per settore. Questo significa che su un disco da 74' entrano file fino a 738M (773.892.000 bytes) e fino a 793M (831.992.000 bytes) in un CD-R80. Se rispettate i calcoli che ho mostrato, difficilmente vi troverete problemi di capienza.
Pur se la procedura per creare il file MPEG1 in formato XVCD è molto differente da quella per il VCD, per masterizzare non esiste nessuna differenza. I comandi sono esattamente gli stessi, come pure la procedura, prima si crea l'immagine:
vcdimager -l "Il mio primo VCD" -p filmato.mpeg
e poi si masterizza:
cdrdao write --speed 12 --device 0,1,0 videocd.cue
tutto qui. Il vostro XVCD è pronto, non resta che infilarlo nel vostro DVD player, e vedere che succede.
Se durante la registrazione Transcode non evidenzia errori e il file AVI che crea ha la traccia audio, cosa che potete verificare con tcprobe, il problema risiede nel livello di input. La prima cosa da fare è aprire la vostra applicazione mixer audio preferita e controllare se arriva audio dall'input LineIn. Se si sente l'audio, allora controllare che come input di registrazione sia selezionato appunto LineIn. Inoltre controllare il livello di registrazione generale che sui mixer in genere è un cursore chiamato "IGain" (Input Gain). Di solito è a 0, per default.
E' un problema parente del problema precedente. Controllate il cursore "IGain", il livello deve essere tra il 45% e il 60%, altrimenti nei momenti in cui il livello è alto la registrazione va in saturazione, conferendo all'audio registrato il classico effetto "metallico".
Il livello regolato dal cursore LineIn è solo per l'ascolto diretto, come monitor, non il livello di registrazione. Per capirci, una volta che la registrazione è avviata e avete controllato che l'audio arriva, potete anche mettere a zero il livello di LineIn.
Può dipendere da due diversi fattori. Il più comune è un problema di tracking del VCR, ossia durante la riproduzione il VCR non riesce a seguire perfettamente la traccia audio/video e pertanto il segnale video in ingresso alla scheda non è perfetto, soprattutto per difetti nel sincronismo di quadro. Se il vostro VCR ha i controlli di tracking, regolateli manualmente in modo da centrare meglio l'allineamento della traccia audio/video. Se il vostro VCR è anche stereo, potete aiutarvi con il segnale audio: quando il tracking sarà a posto, il segnale dai due canali destro e sinistro sarà allo stello livello e pulito all'ascolto.
Quanto detto non vale se state tentando di riversare un VHS protetto con il famigerato sistema MacroVision. In questo caso c'è poco da fare, dato che questo sistema manda in tilt sia la regolazione automatica di guadagno dello stadio di ingresso dellla vostra scheda, sia il rivelatore di sincronismi video. Infatti la protezione consiste in una serie di impulsi di livello "illegale" proprio sul sincronismo di quadro, e se comunque la vostra scheda TV riesce ad agganciare il segnale, diventa molto più sensibile ai problemi di tracking.
E' un problema causato dal sistema di protezione da copia MacroVision. Oltre a generare problemi come nel punto precedente, questo sistema di protezione influisce sul controllo automatico di guadagno nello stadio di ingresso della scheda video, causando le caratteristiche fluttuazioni di luminosità del video, spesso anche improvvise e comunque fastidiose.
Probabilmente si è raggiunto il limite massimo per il vostro lettore DVD. Ci sono due possibilità: la prima è di abbassare il bitrate del video, portandolo a 2500 o 2400 kbps, e comunque abbassandolo fino a che il vostro lettore DVD non mostra più il difetto, neanche su scene molto movimentate e dettagliate. La seconda possibilità è di sperimentare dimensioni del buffer di decodifica maggiori di 230kbytes, nel parametro -V di mpeg2enc e -b di mplex. Provate valori tipo 300, 350, 400, 450, ecc. per vedere quali sono accettati dal vostro lettore e quali valori diminuiscono o eliminano il problema. Nel mio lettore ad esempio il massimo è 2400kbps, e nessun valore di -V e -b cambia le cose, per cui sono costretto a tenermi sotto quel valore. Su un lettore del 1999, già a 1700kbps si manifesta pesantamente il difetto, e solo con un bitrate VCD si riesce a riprodurre correttamente un filmato.