Pat Hawks via Flickr

Sembrerà male, sarà poco elegante, ma lasciatemelo dire: “l’avevo detto”. Qualche tempo fa’, all’epoca dell’acquisizione di On2 da parte di Google ed in piena battaglia sulla questione dei codec (con Mozilla che all’ora si schierava apertamente a favore di Theora e contro H.264), si discuteva dei possibili sviluppi allo scenario dell’informatica (e di Internet in particolare) che questo passo avrebbe portato. Il maggior valore di On2 infatti (quello che Google voleva verosimilmente acquistare), sta decisamente nel codec VP7 (del quale viene oggi annunciato il successore, VP8 per l’appunto) ed era facilmente prevedibile che Google preparasse una mossa “ad effetto” rilasciando questo codec sotto una licenza libera (nella fattispecie si tratta della licenza BSD) e senza “royalties”, andando così a dichiarare guerra aperta ad Apple (su tutti) ed al codec H.264 all’interno delle specifiche video di HTML5.

Cos’è un codec?

Ok, mi rendo conto, troppe sigle. Urge una spiegazione per chi non mastica pane e bit da mattina a sera. La rappresentazione di immagini su uno schermo (sia questo quello della televisione o quello di un pc, o di un telefonino poco importa), necessita senza eccezione alcuna della definizione di una “rappresentazione informatica” dei dati che si vogliono far apparire. Questa rappresentazione (che può assumere molte, moltissime forme), viene definita “codec“. Per chiarire il concetto di “codec”, facciamo un esempio pratico: ci troviamo nella condizione di voler visualizzare sullo schermo di un pc un’immagine completamente bianca (il caso più semplice); il meccanismo più semplice per rappresentare digitalmente questa immagine è quello di descrivere pixel per pixel i colori che la compongono; assegneremo quindi una scala di colori (dal bianco al nero, passando per tutti i vari colori), partendo da 0 (bianco) ed arrivando, ad esempio, a 255 (nero); dopodiché inseriremo in un file le codifiche di ogni singolo pixel che compone la nostra immagine, uno di fianco all’altro; nel momento in cui (dotandoci di un apposito programma che sia capace di “decodificare” il nostro codec), andremo a visualizzare l’immagine, sarà sufficiente leggere i codici colori e “colorare” i pixel dello schermo sulla base dei colori indicati.
Naturalmente un codec così semplice ha delle limitazioni notevoli

• prima di tutto non è in grado di mostrare immagini in movimento (potremmo però comporre più rappresentazioni in successione, creando il movimento)
• secondariamente è molto poco efficace: un’immagine 1920×1080 pixel (il formato del “Full HD” ci costringerà a definire 2.073.600 pixel, anche se fossero tutti bianchi. Un’idea potrebbe essere quella di indicare le sequenze di pixel colorati allo stesso modo in versioni “ridotte”, o assegnare “codici” a sequenze definite e ripetitive di pixel…
• c’è poi la questione del codice colore: 256 colori sono decisamente pochi per rappresentare con un’immagine di buona qualità. L’aumento del numero dei colori possibili però (e quindi della dimensione della rappresentazione del singolo pixel), fa crescere proporzionalmente la dimensione dell’immagine finale: se posso rappresentare 256 colori con 32bit (e quindi la nostra immagine di cui sopra da 2.073.600 pixel “peserà” 8.2 megabytes), rappresentarne solo 512 (il doppio) necessiterà di 64bit (e quindi arriveremo a 16.4Mb). Una “profondità di colore” che consenta immagini realistiche si aggira intorno ai 16.7 milioni di colori, portando la nostra immagine a dimensioni spropositate (svariate migliaia di gigabytes).

Ecco quindi il perché del fiorire di codec differenti: ottimizzazione delle prestazioni a parità di dimensione della rappresentazione digitale (con algoritmi di codifica più o meno complessi), velocità di codifica e decodifica e via dicendo. Anche la semplicità dell’algoritmo del codec stesso è un fattore molto importante: un algoritmo molto  complesso è difficilmente implementabile “in hardware” (dedicandogli quindi un chip che faccia il lavoro di decodifica), con ripercussioni notevoli sul consumo di batteria (un chip dedicato consuma meno del processore che esegue il software di decodifica) e sulla velocità di decodifica.

Di fronte a tutti questi codec, ci sono come al solito due vie per “standardizzare” l’uso di un codec piuttosto che l’altro: la via “de jure”, che prevede l’inserimento di un ben specifico codec all’interno di un formato, oppure la via “de facto” in cui è l’adozione massiccia (solitamente per via di caratteristiche tecnica inconfutabili) a dettare la standardizzazione del formato. Nel mondo reale, una “specifica” consente spesso di adottare codec diversi all’interno del “contenitore”: la sezione video delle specifiche HTML5 (la nuova versione delle specifiche HTML che consentono di creare pagine web “arricchite” senza bisogno di ricorrere ad “aiuti esterni” come Flash o player dedicati) è definito che si possano usare codec differenti sia per quanto riguarda il canale audio che quello video, il che ha portato fino ad oggi all’adozione di H.264 (codec video) e AAC (codec audio). Purtroppo il formato H.264 è proprietario e (soprattutto) gravato dalla necessità di pagare una “tassa” (royalty) al proprietario del codec stesso, cosa non possibile nel caso di software libero (sviluppato cioè, semplificando, sotto la spinta di una comunità di sviluppatori e non di un’azienda che possa farsi carico del pagamento della royalty stessa).

Dicevamo…

Tornando alla discussione iniziale, la scelta di Google di rendere il successore del codec VP7 (acquisito attraverso l’acquisto On2), detto VP8, libero ed esente da royalty, oltre che prevedibile, apre un nuovo scenario, consentendo l’implementazione delle specifiche HTML5 attraverso codec liberi e royalty-free (affidando la parte audio all’ottimo codec Theora). Purtroppo VP8 è al momento ancora un codec incompleto (e le specifiche sembrano essere ancora poco precise) ed apparentemente coperto da una serie di “software patents” (i brevetti software che in Europa si cerca di scongiurare da svariati anni ma che sono da anni legge negli Stati Uniti) che renderebbero Google un soggetto facilmente attaccabile sul fronte giudiziario. Visto che però a Mountain View non sono degli sprovveduto, ritengo che abbiano in mente tempi e modi per risolvere queste problematiche.

Il motivo per cui questa scelta da parte di Google porta tanto scalpore, è da ricercarsi nella particolare congiuntura in cui il mondo del web si trova oggi:

• il ruolo sempre più importante del video nel web (ed il particolar modo il fenomeno YouTube, acquisito da Google qualche anno fa) e la scarsa adattabilità di Flash nel ruolo di player più usato (per via sia della parte software, proprietaria e ormai vecchiotta, sia del codec scelto), portano particolare attenzione sulle nuove specifiche HTML5 ed in particolare proprio sul frangente di audio e video.
• il sempre maggior affermarsi di Firefox come vero antagonista di Internet Explorer sul panorama dei browser, con una percentuale di “market-share” non più trascurabile (oltre il 25%), rende necessaria un’attenzione particolare alle tematiche del software libero, che Google ha sempre ascoltato in modo favorevole.
• il sempre maggior diffondersi di “device mobili” (iPhone, smartphone, palmari, netbook, tablet e chi più ne ha più ne metta) con caratteristiche computazionali spesso inadatte a fare computazione pesante ma orientati sopratutto alla fruizione di contenuti web, tra cui per l’appunto i video, impone un occhio di riguardo alla tematica dell’implementabilità in hardware.
• è in corso da parecchio tempo un braccio di ferro tra Adobe (proprietaria di Flash) ed Apple in quanto sugli iPhone non c’è il supporto a Flash. Apple si è giustificata dicendo che il player Flash è un software di scarsa qualità (cosa sulla quale potrebbero trovarmi parzialmente d’accordo, per altro) e che le specifiche del codec sono tali da rendere difficoltosa e costosa l’implementazione in hardware, fondamentale per una maggior durata delle batterie delle device mobili. Apple ha poi presentato, qualche tempo fa, una propria proposta per risolvere il problema, Gianduia (che sarebbe un’alternativa non solo a Flash ma anche a Silverlight, di Microsoft), che non ha però visto alcuna reazione da parte di Google, che evidentemente preparava il lancio di VP8.

Andiamo allora ad analizzare le reazioni dei “player” più importanti di fronte all’annuncio di Google:

• I proprietari di Flash (Adobe per l’appunto) sono stati i primi a replicare all’annuncio di Google, affermando che il formato VP8 sarà immediatamente supportato dal player Flash. Per Adobe l’orizzonte sembra piuttosto scuro: l’arrivo di HTML5 comporterebbe il progressivo abbandono di Flash come colonna portante dell’animazione sul web, della quale oggi è l’unico indiscusso interprete. L’implementazione di VP8 potrebbe consentire di mantenere un certo respiro per via della “backward compatibiliy” (i siti consentiranno l’accesso ai propri contenuti sia tramite Flash, per i browser più vecchi, sia attraverso HTML5). Andare a braccetto con Google significa inoltre garantirsi l’enorme visibilità legata a YouTube (che costituisce una parte preponderante del video online) e mette Adobe in una posizione dominante, sebbene riflessa.
• Dopo il sostanziale “flop” di SilverLight e Bing, Microsoft cerca una via d’uscita per tornare ad essere un player importante del mondo del web a prescindere dalle (sempre minori) quote di mercato di Internet Explorer. L’orientamento alla “compatibilità” è già stato dimostrato con la maggior attenzione alle specifiche HTML e CSS delle ultime release del browser “made in Redmond” ed in Microsoft non devono essersi lasciati sfuggire il fatto che se Google va verso VP8, il web va verso VP8. Prendere la palla al balzo era fondamentale e l’annuncio del supporto a VP8 da parte di Internet Explorer 9 non ha tardato (così come non aveva tardato l’annuncio del supporto a H.264 non troppo tempo fa).
• La posizione di Apple sulla questione VP8 era attesa da giorni e solo questa mattina si è appreso del parere “contrario” di Cupertino. Apple afferma che le royalty su H.264 non sono tali da renderle fastidiose (purtroppo nel mondo del software libero, costose o meno, non si possono pagare perché non c’è un ente preposto al pagamento stesso ed espone critiche tecniche sul formato VP8 stesso, considerato espressamente concepito per il web ed incapace di offrire contenuti di alta qualità, soprattutto se comparato al più prestante e complesso codec MPEG-4.

Si instaura (o meglio, si ravviva) così un braccio di ferro tra il crescente mercato delle device mobili targate “Apple” (numericamente non trascurabile) e quello del software libero, che certo non farà bene ad una crescita “sana” del web. Purtroppo per Apple, in questo caso, la posizione di Google non sarà verosimilmente una posizione “d’attesa”, e “tagliare fuori gli iPhone dai contenuti video di Youtube” potrebbe essere una minaccia in grado di smuovere non poche poltrone, a Cupertino…