Processo di produzione audiovisiva casalinga

Condizioni al contorno

Ho appena incominciato la sperimentazione di una squadra di software per il montaggio audiovisivo. In passato ebbi un po' di esperienza con Adobe Premiere, After Effects e Encore DVD, ma questa volta ho voluto affrontare l'impresa usando esclusivamente software libero.

Guardandomi in giro, mi imbatto in Lightworks, un programma professionale rilasciato recentemente, in versione beta, come libero e open source: perfetto per farsi tanto male... mi piace! Naturalmente ho scoperto poi di aver bisogno di diversi altri strumenti.

Il punto di partenza del processo è l'acquisizione con i seguenti dispositivi a mia disposizione:

• smatphone HTC Tattoo: aquisisce in formato 320x240 usando il contenitore 3gp con framerate variabile;
• macchina fotografica Canon Digital IXUS 85IS: acquisisce in formato 640x480 usando la codifica MJPEG a 30 fps;
• videocamera Sony Handycam DCR-HC19E PAL: acquisisce in formato PAL 4:3 o 16:9 su cassetta miniDV.

L'ambiente di lavoro è MS Windows 7 a 64 bit.

Il punto di arrivo è la visualizzazione da:

• smartphone HTC Tattoo;
• riproduttore Philips Home Theater System HTS3164 (con televisore 16:9): riproduce DVD e DivX e supporta audio AC3 e DTS.

Sperimentazione

Il primo problema da considerare è che Lightworks è un programma professionale che si è appena affacciato al grande pubblico amatoriale, quindi utilizza come formati di acquisizione i formati standard per il broadcasting e il cinema: PAL, NTSC, HD 720, HD 1080; i contenitori gestiti sono AVI e Quicktime con le compressioni DV, MPEG 2 e una caterva di formati professionali a me sconosciuti. Fine. Niente MPEG4, DivX, Theora ... ahi!

Nessun problema con la Handycam, che è riconosciuta e correttamente controllata nel processo di acquisizione: l'unica difficoltà è che Windows 7 non permette l'uso dell'interfaccia USB per l'acquisizione video (e neanche Lightworks, figurarsi!), quindi è necessario usare la IEEE 1394 (anche nota come Firewire o iLink): meglio, dato che quest'ultima è anche superiore in termini di qualità del segnale.

La IXUS ha una qualità del video un po' inferiore a quella della Handycam (e vorrei vedere, è una macchina fotografica!), ma il formato MJPEG è direttamente importabile in Lightworks. Però, siccome registra a 30 fps, Lightworks permette di importare i metraggi solo in formato NTSC o HD, perchè tale velocità non è prevista per PAL (che, per combinazione, è il formato che devo usare io): importo in HD 720, pur sapendo che il passaggio da 640x480 a 1024x720 necessiterà di un ricampionamento.

Il Tattoo ha una risoluzione molto più bassa del PAL e un framerate variabile fra circa 5 e 16 fps, oltre ad un'ottica molto "economica" e nessuna possibilità di regolazione in fase di ripresa: non mi aspetto risultati esaltanti; inoltre il contenitore 3gp appartiene ad un pianeta sconosciuto a Lightworks. Mi necessita un convertitore: dopo averne provati diversi la mia scelta cade su ffcoder, che usa K-Lite Codec Pack e Avisynth; forse non è la scelta ottimale, perché scopro in seguito che sul mio sistema operativo il programma non riesce a configurare i codec VFW per il contenitore AVI (che, guarda caso, sono proprio quelli utilizzati da Lightworks). Per risolvere questo problema, installo anche Virtualdub, che può usare i codec VfW ma non legge i 3gp. Nessuno dei due programmi da solo può convertire da 3gp ai codec Matrox usati da Lightworks, ma posso usarli insieme usando un formato comune di trasferimento. Comunque Virtualdub è utile anche per l'applicazione di filtri, quali Deshaker (stabilizzatore video), che per le riprese con il Tattoo si rivelerà salvifico.

Lightworks ha una curva di apprendimento piuttosto ripida, perché pur avendo un'interfaccia utente molto pulita e flessibile, usa un linguaggio professionale e un paradigma di montaggio che è sicuramente intuitivo per i professionisti del settore (quelli che lavoravano con le forbici e le pellicole), ma è diverso dagli altri NLE più diffusi. Il manuale utente è anch'esso rivolto ai professionisti, quindi poco masticabile per un novizio, ma, in compenso il forum del sito è molto vivo, ricco e popolato da personaggi piuttosto esperti; inoltre ci sono nella rete diversi filmati di apprendimento che mostrano le caratteristiche principali del programma e sono sufficienti per incominciare a lavorare.

Stimolato dal forum, integro Wax come plugin di Lightworks per provare un po' di effetti speciali, ma rimango un po' deluso: l'interfaccia utente, pur abbastanza semplice e classica, non permette operazioni banali come lo zoom sulle timeline o l'inserimento da tastiera dei valori dei vari effetti, rendendosi di difficile ed impreciso utilizzo. In pratica, non riesco a creare correttamente né una transizione, né un effetto speciale: spero in una prossima evoluzione. Diversamente da Lightworks, le risorse per imparare ad usarlo sono piuttosto povere.

Per tentativi e con forum sul comodino riesco a produrre un paio di filmati. Al momento dell'esportazione sono un po' imbarazzato nello scegliere il codificatore di uscita. Naturalmente, neanche a dirlo, Lightworks esporta solo nei formati e nelle codifiche già elencate per la fase di importazione. Ma ormai la strada è in discesa: basta ripercorrere al contrario la strada in salita dell'andata. Quindi, con Virtualdub esporto in DivX 720x404 (pur arrivando il PAL a 768x576, più di 720 sembra che il mio home theater non supporti) e in AVI non compresso: quest'ultimo è trasformato in e MPEG 2 (PAL Widescreen) e 3gp 320x240 con bande orizzontali mediante ffcoder.

Conclusioni

La prima evidenza scaturita da questa esperienza è (non ci vuole Kubrick per scoprirlo) che il Tattoo è assolutamente inadeguato. Penso che la prossima volta che mi appresterò ad usarlo per riprendere le evoluzioni di mia figlia sarò preso da brividi di paura. Una buona ripresa con la Handycam o al limite la IXUS è un buon punto di partenza per sentirsi a proprio agio nelle successive fasi di produzione.

Virtualdub era un mio vecchio amico e continua ad esserlo, perché non fa molto, ma il poco che fa lo fa molto bene: applicazione di filtri e conversione di formato e codifica sono semplici ed efficaci.

Sono stato deluso dall'incapacità di ffcoder di esportare in AVI VfW; per il 3gp e MPEG 2 invece nulla da eccepire.

La prima caratteristica di Lightworks che mi ha colpito è la conservazione di tutto il lavoro fatto anche in caso di crash (d'altra parte è una beta): è una balla sorpresa scoprire di non aver perso niente dopo uno spaventoso "errore critico". Se all'inizio mette un po' di soggezione il suo approccio personale al montaggio, basta entrare un po' in intimità per restarne affascinati: dà l'impressione di saper fare cose che noi umani (neanche quelli che hanno scritto il manuale) non possiamo neanche immaginare.

WAX... mah, c'è chi ne parla entusiasticamente, chi meno. Io non sono riuscito ad usarlo efficacemente come plugin di Lightworks. L'impossibilità di ingrandire l'area di lavoro nella timeline, quando si deve lavorare con precisione, è una grave pecca; ancora peggio l'impossibilità di scrivere (con la tastiera) dati numerici nelle caselle di testo delle regolazioni degli effetti, ma l'obbligo di ottenere "172,34" facendo scorrere il mouse intorno alla casella: impossibile. Inoltre, anche dopo essere riuscito a creare un effetto approssimativamente come volevo io, la sua applicazione nell'edit di Lightworks era scorretta.

Insomma, posso dire che il risultato di questa esperienza è soddisfacente, ma migliorabile.

Separazione delle carriere in php

php è considerato un linguaggio "semplice" per lo sviluppo web, spesso contrapposto alle piattaforme "serie" come .NET e Java: questo è dovuto soprattutto all'uso semplice che la maggior parte degli sviluppatori ne fanno.

Ma anche in php si possono usare paradigmi di progettazione più evoluti del semplice incapsulamento nel codice html; ad esempio, si possono usare i template, per separare lo strato di visualizzazione da quello di elaborazione.

Il template è un file prototipo che non contiene (quasi) codice php e che può essere quindi gestito anche da chi non conosce il php: può essere un file html, xml, javascript o di qualunque altro tipo si voglia. La sua particolarità è quella di poter contenere eventuali segnaposto utilizzabili da php.

Il codice php può compilare il template con diverse tecniche (io ne mostrerò solo una, basata sulla funzione eval) e restituire il documento opportunamente modificato.

Ad esempio, si possono avere i tre file:

• mondorux.php: la pagina che sarà richiesta dal browser e che controlla il processo;
• component.php: contiene la classe Component, che incapsula il meccanismo di rendering dei contenuti;
• template.html: il prototipo che "vestirà" mondorux.php.

Ecco il codice, che mi appresto a commentare.

template.html

<html>
    <head>
        <title>$titolo</title>
    </head>
    <body>
        <h1>$titolo</h1>
        <p>$saluto</p>
    </body>
</html>

Come si può vedere, in questa pagina html non c'è codice php, a parte quelle strane stringhe precedute da '$': esse sono solo dei segnaposto (nota: questo non è l'unico modo per scrivere il template).

component.php

<?php
class Component{
    var $_template;
    var $_parameters_array;

    /* costruttore, imposta il template */
    function Component($template){
        $this->_template = str_replace("\"","\\\"",implode("",file($template)));
    }

    /* legge un array associativo di nomi di variabili e loro valori */
    function setParameters($parameters_array){
        $this->_parameters_array = $parameters_array;
    }

    /* esegue la resa del template */
    function render(){
        if(is_array($this->_parameters_array)){
            foreach($this->_parameters_array as $v_name => $v_value){
                eval("$v_name = \$v_value;");
            }
        }
        eval("\$compiled = \"".$this->_template."\";");
        return $compiled;
    }
}
?>

Questa classe (perdonate lo stile PHP4, un po' obsoleto) incapsula il template e il meccanismo di rendering, che ruota tutto intorno alla funzione eval (nel metodo render), che valuta come codice php la stringa passata come parametro.

Il metodo getParameters raccoglie un array associativo di coppie (nome, valore) in modo che il codice cliente possa impostare i contenuti della pagina.

mondorux.php

<?php
require("component.php");
$pagina = new Component("template.html");
$pagina->setParameters(
    array(
        '$titolo' -> "Template php",
        '$saluto' -> "Ciao mondo, ma che belli i template!"
    )
);
$pagina->render();
?>

Come si può vedere, in questo codice non c'è traccia di come sarà reso il documento (in questo caso: html).

mondorux.php usa la classe Component, chiedendole di eseguire, tramite il template "template.html", la resa dei contenuti, ossia i parametri $titolo e $saluto i cui valori sono assegnati nell'array.

Con questa tecnica abbiamo ottenuto una quasi completa separazione del codice di elaborazione (mondorux.php) dal codice di visualizzazione (template.html), implementando così il famoso (e utile) pattern Model-View-Controller.

LaTeX senza preamboli

Niente di pornografico, non è questo il luogo.

Come tutti sappiamo, L^_AT_EX è un linguaggio a marcatori per la preparazione di testi basato sul programma di composizione tipografica T_EX.

Io trovo molto comodo il suo approccio WYSIWYM (What You See Is What You Mean, "ciò che vedi è ciò che intendi") per pubblicazioni complesse e strutturate, e comodissimo il fatto che dalla compilazione di un unico documento .tex si possano ottenere prodotti dvi, ps, pdf, (x)html, docbook o persino odt, con piccoli accorgimenti nella composizione del preambolo.
Quello che trovo scomodo è invece la scrittura stessa del preambolo, che mi obbliga a ricordare una serie di comandi che non sono "What I Mean". Per questo mi viene in aiuto L^_AT_EX stesso, perchè permette l'inclusione di file esterni nel file sorgente principale. Allora ho scritto una piccola libreria di comandi che permette di costruire di volta in volta il preambolo adatto al tipo di output che desidero.

La libreria (che ho chiamato preamble) è costituita da pochi file:

• default.tex: un preambolo semplice, che definisce solo il tipo di documento, il titolo, l'autore e la data;
• dvi.tex: permette la creazione di un dvi (e quindi un ps) con immagini; pensato per la compilazione mediante il comando:

  latex miodocumento.tex

• pdf.tex: permette la creazione di un pdf ipertestuale; pensato per la compilazione mediante il comando:

  pdflatex miodocumento.tex

• xml.tex: permette la creazione di documenti basati su xml, quali ad esempio:
  • html: htlatex miodocumento.tex
  • docbook: dblatex miodocumento.tex
  • odt: ooflatex miodocumento.tex

Il preambolo dei miei nuovi documenti diventerà semplicemente:

\input{preamble/pdf}
\makepreamble{article}{a4paper,12pt}{titolo}{autore}{oggi}
\setabstract{Una libreria per facilitare la scrittura del preambolo}
\setkeywords{LaTeX preambolo pdf html dvi odt}

La prima riga del preambolo imposta l'uso di ./preamble/pdf.tex.
Questo preambolo serve per produrre un pdf. Per cambiare il tipo di output, è sufficiente modificare la prima riga in \input{preamble/dvi} oppure \input{preamble/xml}.
Il comando \makepreamble costruisce il preambolo per un articolo su foglio A4 con caratteri da 12 punti (i primi due parametri sono identici a quelli del comando \documentclass di L^_AT_EX), e imposta il titolo, l'autore e la data.
I comandi \setabstract e \setkeywords impostano rispettivamente le proprietà del pdf oggetto e parole chiave; anche se servono solo per il pdf, si possono lasciare nel sorgente senza danni perchè i file della libreria preamble rispettano tutti la stessa interfaccia, che definisce anche questi comandi.

Ecco come sono i sorgenti:
pdf.tex

\newcommand{\makepreamble}[5]{
 \RequirePackage{ifpdf}
 \ifpdf
   \documentclass[#2]{#1}
   \RequirePackage[hyperindex]{hyperref}
   \hypersetup{
     pdftitle={#3},
     pdfauthor={#4},
     pdfcreator={wordml2latex (Ruggero Dambra, http://www.mondorux.com)},
     colorlinks=true,
     linkcolor=red,
     anchorcolor=black,
     citecolor=green,
     filecolor=magenta,
     menucolor=black,
     urlcolor=blue,
     breaklinks=true,
     pdfstartview=FitH,
     pdfpagemode=UseOutlines
   }
   \usepackage[pdftex]{graphicx}
   \DeclareGraphicsExtensions{.pdf,.png,.jpg}
 \else
   \documentclass[#2]{#1}
   \usepackage{hyperref}
   \usepackage{graphicx}
   \DeclareGraphicsExtensions{.eps,.ps}
 \fi

 \usepackage[]{fontenc}
 \usepackage[latin1]{inputenc}
 \usepackage[italian]{babel}
 \frenchspacing
 \title{#3}
 \author{#4}
 \date{#5}
}

\newcommand{\setabstract}[1]{
 \RequirePackage{hyperref}
 \hypersetup{pdfsubject={#1}}
}

\newcommand{\setkeywords}[1]{
 \RequirePackage{hyperref}
 \hypersetup{pdfkeywords={#1}}
}

ht.tex

\newcommand{\makepreamble}[5]{
 \documentclass{#1}
 \usepackage[T1]{fontenc}
 \usepackage{hyperref}
 \usepackage{graphicx}
 \DeclareGraphicsExtensions{.gif,.png,.jpg}
 \usepackage[latin1]{inputenc}
 \usepackage[italian]{babel}
 \frenchspacing
 \title{#3}
 \author{#4}
 \date{#5}
}

\newcommand{\setabstract}[1]{}
\newcommand{\setkeywords}[1]{}

\newcommand{\href}[2]{\Link[#1]{}{} #2 \EndLink}
\newcommand{\hypertarget}[2]{\Link[]{}{#1} #2 \EndLink}
\newcommand{\hyperlink}[2]{\Link[]{#1}{} #2 \EndLink}

dvi.tex

\newcommand{\makepreamble}[5]{
 \documentclass[#2]{#1}
 \usepackage[T1]{fontenc}
 \usepackage{hyperref}
 \usepackage{graphicx}
 \DeclareGraphicsExtensions{.eps,.ps}
 \usepackage[latin1]{inputenc}
 \usepackage[italian]{babel}
 \frenchspacing
 \title{#3}
 \author{#4}
 \date{#5}
}

\newcommand{\setabstract}[1]{}
\newcommand{\setkeywords}[1]{}

default.tex

\newcommand{\makepreamble}[5]{
 \documentclass[#2]{#1}
 \title{#3}
 \author{#4}
 \date{#5}
}

\newcommand{\setabstract}[1]{}
\newcommand{\setkeywords}[1]{}

In realtà, la finalità di questa libreria non è di evitare la scrittura del preambolo, perchè prima di \begin{document} si potranno scrivere tutte le ulteriori direttive che servono al nostro documento; il vero pregio è la possibilità di modificare "al volo" quelle parti del preambolo che ottimizzano la produzione di un particolare tipo di output.

RFC: tutti i suggerimenti per migliorare sono benvenuti.

Ottimizzazione di Windows

L'ottimizzazione del sistema operativo di casa Microsoft è spesso considerata un'operazione misteriosa da cervelloni informatici.

In alcuni casi lo è, ad esempio se si vuole far girare Windows XP in 64 MB di memoria o ridurre lo spazio sul disco fisso occupato dal sistema operativo a 200 MB; ma in questi casi è necessario modificare la struttura stessa dell'installazione di Windows e bisogna conoscere le componenti che si vogliono toccare (o essere pronti a reinstallare tutto).

Normalmente però mi viene richiesto qualcosa di molto più semplice: ridurre il degrado di prestazioni che inevitabilmente si crea con un uso non oculato del sistema. In questi casi, con poche conoscenze di base e l'aiuto di alcuni programmi che non necessitano di installazione (cosiddetti "portable"), opero così:

1. Analizzo l'uso della memoria di massa (i dischi fissi), con il comodo Scanner e cancello eventuali file o cartelle ingombranti e inutili;
2. Eseguo una pulizia dei file e del registro di configurazione con CCleaner;
3. Eseguo la scansione antivirus e antispyware completa: come antivirus uso ClamWinPortable e una selezione di antivirus on-line; come antispyware Spybot- S&D;
4. Richiedo l'esecuzione di ScanDisk (uno degli strumenti forniti con Windows stesso) al successivo avvio del sistema operativo;
5. Disattivo la memoria virtuale per eliminare il file di paging (serve solo per eseguire una deframmentazione più completa dopo il successivo riavvio);
6. Riavvio; ScanDisk sarà eseguito automaticamente;
7. Deframmento tutti i dischi con JKDefrag e Defraggler; quest'ultimo ha la particolarità di poter deframmentare i file singolarmente;
8. Deframmento il registro di configurazione con RegDefrg
9. Imposto in PageDefrag la deframmentazione dei file di sistema al successivo riavvio;
10. Dopo il riavvio, riattivo la memoria virtuale.

Questa è la procedura classica che uso quando il tempo non mi manca...