Linux multimedia/Video/Acquisizione

Acquisizione

Multimedia non significa solo fare copie di backup dei propri DVD. Ci sono molte altre cose che si possono fare. In particolare, riversare i propri vecchi nastri VHS o Video8 su DVD o altro formato della famiglia MPEG; oppure usare il computer come videoregistratore e registrare da satellite o digitale terrestre (pensate la soddisfazione nel tagliare la pubblicità da un film con pochi click!)

In questa sezione si illustreranno alcune di queste attività, praticamente limitate a sorgenti analogiche, dal momento che, per le sorgenti digitali, come ad esempio le videocamere DV, miniDV o Digital8, non è corretto parlare di acquizione, perché in pratica c'è solo da riversare i filmati direttamente su hard-disk già in forma digitale, pronti per la codifica più opportuna.

Introduzione

Tipicamente, l'acquisizione da sorgenti video analogiche, come avviene anche per l'audio, richiede il campionamento del segnale: in parole povere, a intervalli regolari il segnale analogico continuo in ingresso viene catturato, ottenendo così una serie di istantanee digitali del filmato (stessa operazione viene effettuata sulla componente audio del filmato stesso, ma con tecniche diverse). Queste istantanee sono di solito immagini in formato JPEG, completamente indipendenti le une dalle altre e contenute, insieme con i dati audio, in un contenitore multimediale come AVI o Quicktime. Solo in seguito all'acquisizione esse potranno essere usate per costruire un file in un qualche formato compresso, come quelli della famiglia MPEG.

È facile intuire che, quanto più istantanee si catturano in un secondo, tanto più alta sarà la qualità del risultato (ma anche lo spazio richiesto). Allo stesso modo, la qualità della compressione JPEG incide positivamente sulla qualità del risultato finale, ma negativamente sullo spazio richiesto.

Il codec più usato per memorizzare i filmati acquisiti in questo modo è MJPEG (acronimo di Motion JPEG), particolarmente adatto all'editing proprio perché i frame sono indipendenti l'uno dall'altro, come se fossero soltanto componenti di un array ad accesso random. Di conseguenza, lo scorrimento da una scena all'altra può essere estremamente rapido, molto più che nei formati compressi, cosa che semplifica alquanto l'editing. Il rovescio della medaglia è la notevole quantità di spazio necessaria per memorizzare un tipico film: dopo l'editing, la compressione secondo qualche codec compresso è inevitabile.

L'acquisizione viene normalmente effettuata tramite apposite schede, di cui si parla più in dettaglio nel seguito. Nel loro uso molte cose possono andare storte, e molti sono i fattori che vanno controllati per evitare problemi o per ottenere risultati soddisfacenti.

Sorgenti meccaniche e relativi problemi

C'è una notevole differenza nell'acquisire da sorgenti meccaniche e sorgenti non meccaniche. È importante capire il perché per farsi una prima idea di quanto si possa pretendere dall'acquisizione.

Una prima categoria di sorgenti analogiche sono i vari tipi di videocassetta, ancora molto diffusi nei primi anni 2000: VHS, Video8 e i loro derivati. Per acquisire e convertire i filmati registrati su queste videocassette sono ovviamente necessari videoregistratori o videocamere compatibili. Tutte queste fonti sono di tipo meccanico.

Un'altra categoria di sorgenti analogiche sono la televisione, il decoder satellitare (analogico o digitale) e il decoder per digitale terrestre. Per quanto molte utilizzino tecnologie digitali, queste sorgenti producono di solito un output comunque analogico. A parte questo, fonti di questo tipo non hanno parti meccaniche coinvolte nel processo di acquisizione.

Da un certo punto di vista, tutte queste sorgenti sono fra loro equivalenti, perché gran parte delle attività richieste nelle varie fasi dell'elaborazione vengono effettuate allo stesso modo per ognuna di esse. Purtroppo, però, la meccanica ha forte impatto sui risultati che si possono ottenere, e di norma le sorgenti meccaniche portano a risultati peggiori.

La questione è discussa alquanto in dettaglio nell'articolo TBC della Wikipedia inglese. Vale la pena di leggerlo, ma per quanti non ne avessero voglia o non sapessero l'inglese, si cerca qui di riassumere brevemente il problema.

Non c'è modo di evitare un processo meccanico nella lettura di una video cassetta, qualunque apparecchio si usi. La meccanica interviene nello scorrimento del nastro e nella rotazione (per altro molto rapida) delle testine della video camera o del videoregistratore. Entrambi i movimenti sono inevitabilmente affetti da errori, e poiché entrambi concorrono alla qualità del filmato riprodotto, se essi sono gestiti da meccanica scadente i risultati saranno a loro volta scadenti.

La conseguenza decisiva per il processo di acquisizione è la temporizzazione scadente del segnale. Come visto sopra, l'acquisizione avviene campionando il segnale analogico a intervalli regolari (ad esempio, per le sorgenti PAL commercializzate in Italia, vengono catturate 25 immagini al secondo). Ma se il segnale analogico in ingresso arriva a intervalli non altrettanto regolari, alcune immagini vengono perse.

Per scoprire se la propria videocamera o il proprio videoregistratore presentano questo problema, c'è solo un modo: fare molte prove di acquisizione, in varie condizioni, e tenere sotto controllo il numero di frame persi. Se questi sono comunque tanti (centinaia o migliaia su un'ora di filmato originale), l'apparato è scadente. L'unica soluzione è acquistare uno stabilizzatore di segnale. In Italia sono praticamente introvabili, per cui vanno acquistati su web cercando video enhancer su qualche sito commerciale specializzato nel settore audio/video.

Almeno per il Video8 ci sarebbe un'ottima alternativa, sia pure costosa: acquistare una videocamere Digital8. Le videocamere di questo tipo garantiscono la stessa qualità di quelle miniDV o DV, ma possono riprodurre, e soprattutto riversare su computer, in MJPEG, le normali cassette Video8 analogiche.

Si trovano anche a meno di 200 euro, ma è importante scegliere modelli con presa IEEE 1394 (FireWire), che elimina i frequenti problemi di compatibilità con Linux riscontrabili nei modelli con la sola connessione USB.

Hardware e software necessari

Sono stati prodotti numerosi tipi di schede di acquisizione video da sorgenti analogiche, per tutte le fasce di utenza. Purtroppo, l'utenza Linux non è stata considerata quasi da nessun produttore, per cui l'acquisto dev'essere ben ponderato. Punto di partenza obbligato è il wiki del progetto Video4Linux: esso contiene, fra l'altro, un elenco delle schede riconosciute da Linux.

Molte schede di acquisizione digitalizzano il segnale analogico secondo il codec MJPEG. Alcune sfruttano in parte la CPU, altre dispongono di un apposito chipset. Le prime richiedono CPU potenti, mentre le seconde, in teoria, hanno un impatto trascurabile sul sistema: al massimo, il disco e il relativo controller potrebbero essere troppo lenti per ricevere la mole di dati che arriva dalla scheda.

Un chipset molto noto e diffuso che effettua questo tipo di digitalizzazione è lo Z36065 (che ha avuto anche molti derivati), prodotto da Zoran: una scheda di acquisizione video equipaggiata con questo chipset funziona quasi certamente con Linux, purché il kernel non sia troppo datato. Per poter utilizzare queste schede, però, è anche necessaria la suite mjpeg-tools.

La home page degli mjpeg-tools è http://mjpeg.sourceforge.net/, ma pure importante è la pagina del progetto su SourceForge, http://sourceforge.net/projects/mjpeg/. Da quest'ultima è possibile scaricare i sorgenti e diversi pacchetti precompilati, ma la maggior parte delle distribuzioni include un apposito pacchetto nei repository standard.

Un problema da non sottovalutare è la scheda audio. Sebbene tutte le schede di acquisizione video siano in grado di acquisire anche l'audio, questo viene quasi sempre acquisito tramite l'usuale scheda audio, presente praticamente su tutti i sistemi. Addirittura, alcune schede di acquisizione, come ad esempio la MiroVideo DC30+, non è gestita completamente dal kernel per quanto riguarda l'audio, e quindi va abbinata necessariamente ad una scheda audio.

Il problema cui si accennava è che la scheda audio può non essere in grado di campionare il segnale alla frequenza richiesta in certe situazioni. Si veda più avanti la sezione relativa alle impostazioni audio.

Anche il sistema di I/O dev'essere adeguatamente veloce e capiente: serve moltissimo spazio, e serve molto in fretta, come si vedrà.

Nozioni preliminari

Alcuni concetti e nozioni meritano un'introduzione teorica. Questa in genere si rivela utile al momento di affrontare applicazioni pratiche.

Frame e framerate

Il frame è la singola immagine campionata e memorizzata di solito in formato JPEG. Le dimensioni e la qualità, com'è ovvio, sono fattori critici. Ma anche la frequenza con cui i frame vengono catturati, detta framerate, è molto importante, perché quando i frame sono parecchi in un secondo l'hardware può trovarsi in difficoltà. In pratica, il framerate è sempre 25 frame al secondo (o fps, dall'inglese frame per second), caratteristico delle sorgenti PAL utilizzate in Italia.

Campi (field)

Il sistema PAL, o Phase Alternating Lines, trasmette, come già ricordato più volte, 25 frame al secondo. Ma il singolo frame non viene trasmesso riga per riga, bensì diviso in due campi (in inglese field), corrispondenti all'insieme delle righe pari (top field) e all'insieme delle righe dispari ('bottom field). In questo modo lo spettatore, a causa della lenta risposta della vista umana, ha l'impressione di vedere una trasmissione in cui le immagini arrivano con frequenza di 50 Hz invece che 25.

L'aspetto negativo, nell'acquisizione, è che in certe situazioni, e per giunta in modo praticamente imprevedibile, i due campi si scambiano, oppure slittano in avanti o indietro, per cui vengono creati frame costituiti di due campi che, in realtà, appartengono a due istantanee consecutive, non ad una sola. Gli effetti sui risultati dell'acquisizione e le possibili soluzioni sono discusse più avanti, nel paragrafo su problemi e soluzioni.

Qualità JPEG

Come già più volte ricordato, il codec MJPEG organizza la parte video in una sequenza di immagini in formato JPEG. Questo formato prevede la possibilità di scegliere la qualità del risultato finale in termini percentuali, ma quanto maggiore è la qualità, tanto minore sarà la compressione, e quindi la qualità è un parametro che incide in modo importante sullo spazio richiesto e sul rischio di perdita di frame, come si vedrà più avanti. Qui basti dire che molti frame grandi possono mettere in difficoltà un sistema di I/O troppo lento, da cui appunto la perdita di frame. Nelle schede che acquisiscono sfruttando la CPU, diventa determinante anche lo sforzo richiesto dalla compressione, che può richiedere troppo tempo ad un CPU lenta, al punto da costringere la scheda a scartare dei frame in eccessivo ritardo.

Decimazione (decimation)

Concetto della teoria dei segnali, da non confondere con l'agghiacciante punizione in uso nell'esercito romano, la decimazione (in inglese decimation) è un fattore, tipicamente 1, 2 o 4, che divide le dimensioni massime potenziali dell'immagine acquisita, caratteristiche della scheda di acquisizione.

Ad esempio, le schede della famiglia DC10/30/+ di MiroVideo possono acquisire a 768x576. Queste dimensioni corrispondono alla decimazione 1. A decimazione 2, invece, si ottengono frame di dimensioni pari a 384x288, mentre a decimazione 4 le dimensioni sono pari a 192x144. In sostanza, non vengono usate tutte le linee disponibili, sia verticali che orizzontali, ma solo la metà o un quarto di esse.

Può avere senso anche usare valori diversi in orizzontale e in verticale. Ad esempio, una decimazione 21 significa decimazione 2 in larghezza, 1 in altezza. Per le schede citate, i frame risultanti avranno dimensioni 360x576.

Ci si può chiedere che senso abbia usare un valore superiore a 1: perché rinunciare alla piena risoluzione? Ci sono diversi fattori che possono portare a questa scelta: le dimensioni dei frame, legate a loro volta allo spazio disponibile su disco e alla velocità dell'hardware (disco e controller), e la qualità della sorgente.

Le dimensioni dei frame, e le relazioni di queste con l'hardware, sono discusse più avanti. Qui osserviamo solo che una sorgente PAL ha normalmente una risoluzione molto inferiore a quelle con cui possono lavorare molte schede. Se poi l'uso del filmato prodotto è solo la visione al televisore, che a sua volta lavora secondo lo standard PAL, può davvero avere poco senso acquisire a decimazione 1.

Per contro, va ricordato che un teorema di Shannon afferma che, perché un campionamento sia efficace, occorre campionare a frequenza doppia rispetto a quella massima del segnale. Nel caso dei frame, in teoria si dovrebbero ottenere risultati migliori catturando a piena decimazione per poi ridurre le dimensioni in fase di codifica, piuttosto che catturare direttamente a decimazione 2, senza ridurre in codifica. La pratica in effetti conferma la teoria, ma vale la pena di fare dei confronti fra risultati ottenuti con i due diversi approcci: se la differenza è modesta, può valer la pena acquisire a decimazione 2.

Qualunque sia il motivo per cui si acquisisce a decimazione 2, i vantaggi che si hanno sono molto interessanti: spazio richiesto ridotto ad un quarto che a decimazione 1; tempi di codifica ridotti di conseguenza; velocità maggiore anche nell'editing; minore impatto sul sistema di I/O, e quindi minori rischi di perdita di frame in caso che esso sia lento.

Si tratta comunque di una valutazione in parte soggettiva, che necessita di varie prove e confronti in condizioni ben controllabili.

Spazio disco richiesto

Abbiamo visto quali sono i due fattori che incidono sulle dimensioni dei file risultanti: dimensioni dei frame e qualità JPEG (consideriamo il framerate un dato, sempre pari a 25). Una stima quantitativa, anche se approssimativa, di questa incidenza è data dalla formula seguente, che esprime il numero di KB prodotti in un secondo di acquisizione in funzione dei vari parametri:

(width * height * framerate * quality ) / (200 * 1024)

La qualità è compresa fra 0 e 100, ed è ricondotta alla effettiva qualità JPEG grazie al fattore 200 al denominatore. Il fattore 1024 serve semplicemente ad esprimere il risultato in KB.

Se ad esempio la scheda può lavorare a 720x576, ecco quello che ci si deve aspettare, in un secondo, a decimazione 1 e a decimazione 2 rispettivamente:

(360 * 288 * 25 * 80) / (200 * 1024) = 990 kB/s
(720 * 576 * 25 * 80) / (200 * 1024) = 4050 kB/s

Se invece la scheda arriva fino 768x576, il risultato sarà:

(384 * 288 * 25 * 80) / (200 * 1024) = 1080 kB/s
(768 * 576 * 25 * 80) / (200 * 1024) = 4320 kB/s

L'impatto sull'hardware è duplice: da una parte occorre spazio su disco, dall'altra l'accoppiata controller - disco dev'essere abbastanza rapida da salvare i frame in arrivo.

Stimare lo spazio necessario è banale, grazie alle formule sopra riportate: basta moltiplicare il valore ottenuto per il numero di secondi previsto per l'acquisizione.

Più complicato è il discorso per quanto riguarda le prestazioni di I/O. Se si perdono molti frame durante l'acquisizione, una delle tante possibile cause è la lentezza delle operazioni di I/O.

Naturalmente anche l'acquisizione dell'audio richiede spazio su disco, anche se in percentuale molto inferiore allo spazio richiesto per il video. L'acquisizione audio, in genere attraverso la scheda sonora piuttosto che la parte audio della scheda di acquisizione, avviene secondo il codec PCM, senza quindi alcuna compressione. La stima dello spazio richiesto è dunque molto precisa, essendo linearmente proporzionale alla durata del filmato:

(samplerate * channels * bitsize ) / (8 * 1024)

Il denominatore converte semplicemente il valore in kB. La frequenza di campionamento (samplerate) è spesso quella del CD (44.100 Hz), ma per produrre DVD può essere necessario acquisire a 48.000 Hz, oppure ricampionare successivamente (la specifica DVD video richiede una frequenza di 48KHz). I canali sono 1 (mono) o 2 (stereo). Bitsize è di solito 16, ma può anche valere 8 e 4.

Ad esempio, volendo audio a qualità CD, bisogna mettere in conto

(44100 * 2 * 16) / (8 * 1024) = 172,2 kB/s

da aggiungere ai kB prodotti dall'acquisizione del solo video.

Contenitore multimediale (AVI o QuickTime)

Poiché l'acquisizione, almeno di solito, riguarda sia la parte video che quella audio, i file risultanti devono essere di tipo multimediale, cioè devono avere un formato in grado di contenere audio e video sincronizzati. Si parla di contenitore multimediale.

Due sono i formati contenitore più usati a questo scopo: [w:AVI|AVI] e QuickTime. Ma il formato AVI, per quanto non privo di difetti, è sicuramente il più diffuso e anche il più supportato dai tool per Linux e dai lettori DVD in commercio. Nel seguito faremo riferimento esclusivamente a questo contenitore.

Un file AVI è normalmente composto di alcuni chunk (pezzi o blocchi) in formato [w:RIFF|RIFF]:

• un header di 2048 byte
• il filmato vero e proprio, audio compreso
• un indice

L'indice non è strettamente necessario alla riproduzione, ma diventa necessario nell'editing, perché consente il salto da un punto ad un altro del filmato.

Per la cronaca, altri contenitori sono OGG e MPEG. OGG non è riconosciuto, almeno per ora, dai lettori commerciali, anche se su PC sono disponibili, per tutti i sistemi operativi, diversi lettori software. MPEG è un contenitore per file MPEG, ma anche questo è poco usato.

Buffer

I tool di acquisizione tendono a bufferizzare i frame che ricevono dalla scheda di acquisizione. In questo modo, infatti, le operazioni di I/O sono meno frequenti, e questo può essere positivo in molti casi. In particolare, può contribuire a limitare il problema di eventuali frame persi.

D'altra parte, buffer troppo grandi richiedono singole operazioni di I/O troppo lente, e questo può portare a perdere frame. Vanno quindi valutate le dimensioni e il numero più opportuni per i buffer, dal momento che la soluzione è sicuramente lontana dagli estremi. Prove pratiche sono inevitabili per la valutazione.

Inoltre, come si accennava a proposito della qualità, se i buffer sono troppo piccoli per contenere un frame alla qualità scelta, essa viene ridotta al valore necessario per consentire ad un buffer di contenere un frame intero, e senza informare l'utente. Il fenomeno può essere scoperto solo controllando l'effettiva qualità del risultato.

Acquisizione da sorgenti analogiche: lavrec

Introduzione

lavrec è il comando della suite mjpeg-tools che acquisisce dalla sorgente analogica una sequenza di immagini JPEG organizzate in un unico file. Come già accennato, questo file non è un filmato compresso, ma solo un modo per tenere insieme un certo numero (di solito cospicuo) di immagini compresse in JPEG, con audio sincronizzato. Il formato del file di output può essere AVI o QuickTime, e questo può indurre appunto a confonderlo con un filmato compresso: in realtà, questi due formati sono solo dei contenitori di oggetti multimediali, compressi o no.

lavrec è normalmente in grado di impostare automaticamente molti parametri che altrimenti devono essere impostati tramite opportune opzioni. Ad esempio, è in grado di capire se il segnale analogico arriva da una sorgente video composita piuttosto che da una sorgente S-Video. Può capire se si tratta di un filmato in NTSC o PAL, e riconoscere le dimensioni del singolo frame (cioè della singola immagine).

Pertanto, la prima cosa da fare è senz'altro provare a eseguirlo con il minimo possibile di opzioni e vedere se funziona. Ad esempio:

# lavrec -d 1 -t 300 filmato.avi

In questo caso, sarà creato un file in formato AVI, in cui ogni singola immagine JPEG avrà qualità del 50%, l'audio sarà prelevato dalla presa line-in della scheda audio, e la registrazione avrà termine al verificarsi di una delle seguenti condizioni:

• non c'è più spazio su disco
• l'utente dà il segnale CTRL-C sulla console
• il file supera le dimensioni ammesse dal formato (ad esempio, circa

1.6G per AVI)

• sono passati 300 secondi (opzione -t)

L'opzione -d 1 indica la cosiddetta decimazione del filmato, un divisore che determina quale porzione di ciascuna immagine catturata sarà effettivamente utilizzata. Un divisore 1, ovviamente, significa che sarà utilizzata l'intera immagine. All'inizio, può essere prudente usare questo valore, anche se molto dispendioso in termini di memoria di massa.

Qualità JPEG

lavrec consente di impostare la qualità JPEG tramite l'opzione -q (--quality). È importante ricordare che un valore -q 100 corrisponde a una qualità JPEG effettiva del 50%: la qualità effettiva è dunque la metà di quella impostata con l'opzione -q.

Un'altra cosa da tenere presente è che il driver si comporta in modo piuttosto subdolo quando vengono usate anche le opzioni relative ai buffer: se queste sono impostate a valori incompatibili con la qualità richiesta, essa viene ridotta al valore più alto compatibile con le impostazioni relative ai buffer, senza informare l'utente. In altre parole, le impostazioni relative ai buffer hanno la precedenza sulla qualità, cosa alquanto discutibile, soprattutto se non viene comunicata.

Buffer

lavrec riceve i dati dalla scheda a velocità teoricamente costante. Nel caso delle sorgenti PAL usate in Italia, deve gestire 25 immagini JPEG al secondo. Normalmente, salvare i frame su disco con la stessa velocità con cui arrivano è proibitivo, e quindi lavrec utilizza dei buffer in cui salvare i frame in RAM per poi salvarli su disco in una sola operazione di I/O.

Le opzioni --mjpeg-buffers (-n) e --mjpeg-buffer-size (-b) consentono di impostare quanti buffer usare e quanto grandi devono essere. Queste opzioni possono incidere in vario modo sui frame persi.

Inoltre, come si accennava a proposito della qualità, se i buffer sono troppo piccoli per contenere un frame alla qualità scelta, essa viene ridotta al valore necessario per consentire ad un buffer di contenere un frame intero, e senza informare l'utente. Il fenomeno può essere scoperto solo controllando l'effettiva qualità del risultato.

File di output

Il nome del file di output di lavrec, che è l'unico parametro richiesto, opzioni a parte, ammette una sintassi alla printf (mitica funzione C per l'output formattato). Se sul sistema è installato il compilatore GCC, è molto probabile che siano disponibili le man page di tale funzione, molto utili per capire come scegliere il nome del file.

Un esempio probabilmente più che sufficiente nella maggior parte dei casi è film-%02d.avi, che indica a lavrec di produrre file numerati come file-01.avi, file-02.avi e così via.

Il formato AVI, per quanto diffuso, è molto limitato sotto diversi aspetti. In particolare, un file AVI normalmente non può essere più grande di 1.7Gb circa. Poiché di solito a decimazione 2 bastano 10 minuti circa per raggiungere questo limite, è necessario produrre più file in sequenza.

Si può impostare una diversa dimensione del singolo file prodotto tramite l'opzione --max-file-size. Ma poiché molte cose possono andare storte durante l'acquisizione, usare pochi file grandi può essere rischioso: ci si può trovare con un file inservibile corrispondente a parecchi minuti di registrazione. In genere è più prudente, semmai, ridurre le dimensioni dei file, in modo che corrispondano a qualche minuto al massimo di registrazione: una volta chiuso correttamente, il file è valido e nessun incidente successivo nel corso dell'acquisizione può alterarlo.

Un'impostazione simile è possibile con l'opzione --max-file-frames: come si può intuire, indica a lavrec di produrre un nuovo file non appena quello corrente contiene un certo numero di frame. Il risultato è comunque un controllo sulle dimensioni dei singoli file prodotti ma, in questo modo, ognuno di essi conterrà lo stesso numero di frame, e ricordando che 25 frame corrispondono a un secondo, è facile usare questa opzione per avere file corrispondenti a un certo numero di secondi o di minuti. Anche con questa opzione, comunque, è bene evitare che risultino file troppo grandi.

Un'opzione pure interessante legata ai file di output è --file-flush, che indica ogni quanti frame il file va aggiornato su disco. Il comportamento di lavrec in mancanza di questa opzione è indeterminato, ma presumibilmente lascia decidere al sistema operativo. Può essere utile tarare questa opzione quando si sospetta che l'hardware sia in difficoltà nel salvare troppi dati in una volta sola, oppure pochi, ma troppo frequentemente.

Impostazioni per l'acquisizione audio

Ovviamente, la fase di acquisizione non si limita alla parte video della sorgente, ma acquisisce anche l'audio e sincronizza le due componenti nei modi previsti dal formato multimediale (AVI o QuickTime) scelto per l'operazione. Vale però la pena di considerare separatamente la componente audio perché spesso si tende a sottovalutare la cospicua quantità di problemi che da essa possono derivare e che possono rendere inutilizzabile il risultato.

Va detto subito che, normalmente, la scheda di acquisizione video dispone di ingressi audio, ma è pratica molto diffusa utilizzare quelli della scheda audio quasi certamente installata sul computer, se non sulla mother board stessa. Supponiamo senz'altro che sia questa la situazione.

Un primo errore che si può fare è dimenticare di impostare correttamente il mixer: il fatto che nei diffusori si senta distintamente l'audio proveniente dalla fonte, magari con un gradevole effetto stereo e buona qualità complessiva, tende spesso ad ingannare l'utente, che dimentica semplicemente di impostare la sorgente audio per la cattura e il relativo volume di registrazione. Di solito il cavo audio viene connesso all'ingresso line-in della scheda audio, ma se questa non è configurata per acquisire, oltre che riprodurre, la registrazione sarà muta.

Il volume di registrazione può essere fonte di problemi se è troppo alto: in questo caso il risultato è clamorosamente distorto e pressoché inutilizzabile. Questa impostazione dipende molto dalla scheda audio usata: in certi casi il volume di riproduzione e quello di registrazione si sommano, in altri casi sono del tutto indipendenti. L'unica soluzione è provare la propria scheda audio, variando le impostazioni finché non sono soddisfacenti (e poi trascriverle da qualche parte, per non rischiare di dover fare tutto daccapo se le impostazioni si perdono per qualche motivo).

Ultimo serio problema può essere la frequenza di campionamento. Ad esempio, volendo produrre un DVD, sembra naturale impostare l'opzione --audio-bitrate al valore 48000, previsto dallo standard, ma non tutte le schede audio, soprattutto quelle molto vecchie oppure di scarsa qualità, sono in grado di lavorare a questa frequenza. Il risultato sono seri problemi di sincronismo audio/video, con conseguente perdita o eliminazione di numerosi frame (riconoscibili nell'output di lavrec come lst: XX e del: XX).

Se la scheda audio non può lavorare a 48KHz, si deve provare innanzitutto ad omettere l'opzione --audio--bitrate, accettando così l'impostazione standard di 44.1KHz (qualità CD). Se neanche questo è sufficiente, andranno impostati valori ancora più bassi, ma a questo punto andrebbe considerato l'acquisto di una scheda audio nuova.

Ad ogni modo, trovata un'impostazione che eviti la perdita o la cancellazione di frame, si può sempre portare successivamente la frequenza a 48 KHz nella fase di transcodifica audio. Ovviamente non si riguadagna la qualità perduta in acquisizione, ma almeno si potrà produrre comunque un DVD, se necessario.

Infine, trovate le impostazioni adatte, è opportuno tradurle in uno o più comandi amixer da includere all'inizio di uno script di acquisizione, in modo da essere sempre sicuri che l'acquisizione partirà con il mixer impostato correttamente. Ad esempio, se la sorgente audio è collegata all'ingresso Line-in della scheda audio, un comando come:

amixer set Line unmute cap

consentirà di sentire l'audio nei diffusori e di catturare il segnale audio correttamente.

Altre opzioni

lavrec ha diverse altre opzioni meno importanti, ma che in alcuni casi possono tornare utili.

--format (-f)

Indica il formato contenitore (AVI o QuickTime), ma di

solito è inutile, perché lavrec interpreta anche l'estensione del file, scegliendo il contenitore giusto. Tuttavia, come vedremo più avanti, c'è una importante differenza fra il valore a e il valore A.

--input (-i)

Indica il tipo di sorgente: p sta per PAL...

--time (-t)

Il numero di secondi previsti per l'acquisizione. Molto

utile se si pensa di lasciare la postazione a lavorare per conto suo.

Problemi e soluzioni

Lost frames

La cosa forse più seccante che possa capitare durante l'acquisizione è perdere dei frame. Il risultato, quando i frame persi sono troppi, può essere un filmato che procede a scatti in maniera intollerabile. Le cause, però, possono essere davvero tante.

audio bitrate troppo alto per la scheda audio

Se la scheda audio non

è in grado campionare il suono alla velocità impostata con l'opzione --audio-bitrate (-r), è probabile che vengano persi dei frame perché non è possibile sincronizzare il video con l'audio (che arriva troppo in ritardo). Se si ha questo sospetto, usare un bitrate più basso, anche 22050 o meno, e vedere se il problema si riduce drasticamente, ferme restando tutte le altre condizioni. Se è proprio così, non è detto che acquisire a più bassa frequenza sia un problema, specialmente se la sorgente è comunque scadente. In seguito, nella transcodifica, si può operare un ricampionamento se necessario.

qualità JPEG troppo alta

Ovviamente dipende dall'hardware di cui si

dispone, ma pretendere una elevata qualità JPEG significa certamente produrre frame grandi, troppo grandi in rapporto alle prestazioni del sistema di I/O. Ridurre la qualità in qualche esperimento può fugare sospetti del genere: se con una qualità davvero bassa si perdono ancora troppi frame, il problema sarà altrove.

dimensioni dei frame eccessive

Altezza e larghezza dei frame si

legano alla qualità richiesta per contribuire allo spazio richiesto da ogni singolo frame. Se a decimazione 2 una qualità JPEG dell'80% è compatibile col proprio hardware, a decimazione 1 difficilmente si potrà pretendere la stessa qualità senza perdere spesso dei frame. Se si possono escludere altre cause, i frame persi per una combinazione di qualità e decimazione inadeguate all'hardware possono essere ridotti solo riducendo le pretese.

dimensioni e numero di buffer

Si è già detto di questi due parametri

e delle opzioni che li governano. Fare tentativi con questi due parametri è faticoso, ma in certi casi occorre almeno provare. Una politica sensata consiste nell'evitare di avere troppi buffer grandi, perché questo pesa molto sul sistema di I/O. Alcuni hanno anche notato che, su sistemi datati, un numero eccessivo anche di piccoli buffer provoca la perdita di numerosi frame. Volendo ridurre comunque le dimensioni dei buffer, occorre ricordare che se questi sono troppo piccoli per contenere un frame alla qualità e alla decimazione richieste, il driver riduce la qualità in modo tale da ottenere frame piccoli abbastanza da essere contenuti nei buffer, senza dare avvisi in proposito. Si può capire cosa è successo notando la scarsa qualità del risultato.

Inserted frames

Di solito qualche frame inserito sporadicamente indica piccoli problemi di sincronismo audio/video. Una scheda di buona qualità non dovrebbe darne, ma in alcuni casi si presentano comunque, e in modo troppo sistematico e con frequenza e regolarità eccessive per non destare sospetti. In questi casi, è probabile che qualche altro applicativo abbia lasciato impegnato il sistema audio. Ad esempio, può capire che la chiusura non corretta di un applicativo audio lasci vivo un demone esd di troppo. In questo caso, basta uccidere quello sospetto e riprovare ad acquisire. Se i frame inseriti si azzerano o diventano del tutto sporadici, è stato ucciso il demone giusto.

File AVI corrotto

Normalmente con lavrec si sceglie il formato AVI per l'output. Purtroppo, però, lavrec crea l'header RIFF soltanto al momento di chiudere il file di output. Se lavrec o il sistema si bloccano prima che un file AVI sia chiuso, esso rimarrà con un header RIFF pieno di zeri e quindi inservibile: in pratica nessun tool di riproduzione o elaborazione lo riconoscerà come AVI. In realtà il file contiene tutti i frame catturati fino all'ultima scrittura su disco, e in certi casi può valere la pena cercare di recuperarli.

In effetti di solito ci si può riuscire perché gli header dei file prodotti da lavrec nel corso di una acquisizione sono tutti uguali: basta quindi copiarne uno da un file sano a quello difettoso. Se si lavora sempre nelle stesse condizioni (decimazione, qualità JPEG e altro), si possono riutilizzare anche file prodotti da altre acquisizioni, o addiritturare acquisire pochi secondi nelle stesse condizioni per ottenere un file AVI corretto.

Ad ogni modo, se good.avi è un file integro con header presumibilmente adatto alla bisogna, è facile ricavare l'header:

$ dd bs=2048 count=1 if=good.avi of=good-header

Il file good-header contiene ora solo un header RIFF. Se chiamiamo bad.avi il file rimasto con header vuoto o comunque non corretto, dobbiamo farne una copia del tutto priva di header, in modo da concatenarla poi con l'header sano per ricavare un file integro:

$ dd bs=2048 skip=1 if=bad.avi of=bad-noheader.avi
$ cat good-header bad-noheader.avi > bad-fixed.avi

A questo punto il file bad-fixed.avi dovrebbe almeno essere riproducibile, ma non può essere elaborato con strumenti di editing perché manca l'indice. Per crearlo, usiamo aviindex, un tool distribuito di solito con transcode (uno dei principali strumenti di codifica, discusso nel relativo capitolo):

$ aviindex -i bad-fixed.avi -o index

Il file index contiene l'indice del file bad-fixed.avi, nel formato richiesto da avimerge, un altro tool legato a transcode, e che è in grado di unire un indice ad un file AVI che ne sia privo:

$ avimerge -i bad-fixed.avi -o bad-nomore.avi -x index

Questo comando crea un file bad-no-more.avi identico a bad-fixed.avi, ma dotato di indice: tale file è in teoria utilizzabile anche da strumenti di editing, e soprattutto dovrebbe essere possibile scorrere velocemente le scene .

Campi slittati (Interlacing problem)

Come si è detto, i frame nel sistema PAL vengono trasmessi sotto forma di coppie di campi, top e bottom. Il problema, per lavrec, è che quando esso comincia ad acquisire non può sapere se sta acquisendo righe pari o righe dispari, cioè se il primo campo che trova è davvero un top field o se invece è un bottom field. In ogni caso prende come top field il primo che trova.

Se lavrec comincia l'acquisizione da un bottom field invece che da un top field, costruirà i frame prendendo sempre il bottom field da un'immagine, e il top field da quella successiva. Facile immaginare: il filmato è rigato in maniera vistosissima e comunque inaccettabile.

Fortunatamente, il tool yuvcorrect che fa parte degli mjpegtools consente, fra le altre cose, di far slittare in avanti i campi in modo che, con la sola perdita del primo campo acquisito in assoluto, tutti gli altri saranno catturati nel modo giusto, cioè a coppie del tipo (top, bottom) costituenti un frame corretto. yuvcorrect è un filtro, e quindi si usa di solito insieme a lav2yuv, che converte file AVI prodotti da lavrec in YUV:

$ lav2yuv film.avi | yuvcorrect -T LINE_SWITCH | yuv2lav > film-fixed.avi

Di solito, però, una simile operazione viene effettuata in codifica, anche se i tool di codifica, di solito, non fanno altro che invocare yuvcorrect in modo simile a quello visto sopra.

Avanzi e scarti

Sorgenti digitali

Escludendo sorgenti come DVD e VCD, per le quali non è propriamente corretto parlare di acquisizione, in pratica il discorso si restringe alle video camere di nuova generazione diffuse a partire dal 2000 circa.

Attorno alla metà degli anni 1990, è stato introdotto lo standard DV, poi diffusosi nel mercato amatoriale e semi-professionale nella versione miniDV. Entrambi sono discussi diffusamente nell'articolo Digital Video, per cui qui ci limitiamo a qualche breve cenno.

Il supporto fisico è un nastro magnetico, ma la registrazione è digitale, per cui in pratica la fase di acquisizione avviene durante le riprese, e quindi resta solo il trasferimento del video in qualche formato sull'hard disk, di solito attraverso interfaccia IEEE 1394, meglio nota come Firewire. Va detto subito che le videocamere con la sola interfaccia USB sono un grosso rischio, perché poco supportate da GNU/Linux.

Anche la fase di editing è semplificata, perché diversi applicativi, fra cui kino, sono in grado di controllare la videocamera, mandando avanti o indietro il nastro, consentendo il taglio delle scene prima ancora di scaricare il video: saranno scaricate solo le scene selezionate, possibilità che può essere vantaggiosa quando non si ha molto spazio su disco o quando molte delle scene sono da scartare per qualche motivo.

Gli applicativi dedicati all'editing del miniDV hanno anche un'altra grande attrattiva: molti integrano anche le funzioni di conversione in vari formati compressi, per cui costituiscono praticamente un punto d'accesso unico a tutte le operazioni che l'utente presumibilmente può volere effettuare con i suoi filmati.