Concludiamo con questo articolo la serie di introduzione a HTML5 nei suoi vari aspetti. Non finisce qui, però, l’attenzione che riserviamo a queste tematiche: presto torneremo a parlare di aspetti operativi con altri articoli fuori dalla serie e, inoltre, terremo sempre aggiornati i nostri lettori sugli sviluppi delle specifiche e del mondo HTML5 che subiranno un’ulteriore accelerazione nei mesi a venire.
Un web “audiovisivo”
L’abbiamo già scritto in passato: sembra impossibile immaginare un mondo senza YouTube. Tutti noi occupiamo un po’ di tempo a guardare video su Internet: dai video più insulsi, ai vecchi classici videoclip musicali, ai più seri esempi di videoreportage. Il video sul web ci sembra un dato di fatto, un servizio assodato: del resto, Youtube è ad oggi il terzo sito più visitato del web, dopo Google e Facebook. Prescidendo per un attimo dai legittimi discorsi su copyright e diritto d’autore, ci sembra “ovvio” che YouTube o Vimeo ci mettano a disposizione così tanto materiale.
In tutto questo, ci scordiamo spesso di due fattori: il primo, “di costume”, è che YouTube è relativamente “giovane” non avendo ancora compiuto 7 anni, ed avendo raggiunto i numeri di cui sopra solo da meno di 5 anni. In un World Wide Web che ha recentemente festeggiato i 20 anni dalla nascita, un lustro non è poco, ma neanche poi così tanto. La seconda considerazione, “tecnologica”, è che, almeno fino all’anno scorso, non era possibile guardare video su YouTube senza avere installato sul proprio browser il plugin Flash (e vedremo come questo aspetto, da un punto di vista di “guerra commerciale” risulterà importante negli sviluppi prossimi venturi). Le notizie ufficiali, poi, che danno una Adobe “in ritirata” [1] almeno sul fronte del Flash per dispositivi mobile, con una mossa da molti inaspettata, ci fanno comprendere come quello dei codec e dei plugin sia uno dei fronti più caldi delle battaglie tecnologiche e commerciali tra i grandi colossi dell’IT.
In pratica, il web “audiovisivo” è importante per i contenuti che veicola, è importante perche’ è uno degli aspetti più “appariscenti” di ciò che è possibile fare con Internet, ma è importante anche perche’ è qui che si vanno a concentrare enormi interessi economici. Ne riparleremo più avanti nell’articolo.
Contenitori e codec
Quando si ha a che fare con audio e video, uno primi concetti da dirimere è quello di formato. Le convenzioni “di tradizione DOS” hanno abituato, almeno i più anziani tra di noi, a identificare il formato con la classica estensione a tre lettere. Nel campo audio e video, quindi, tendiamo a vedere .MP3, .AVI, .WMV, .FLV etc., magari associandoli a un particolare programma o gruppo di applicazioni capace di creare e/o leggere tali file.
In realtà, quando parliamo di formati nell’ambito audio e video, spesso ci riferiamo più precisamente a contenitori multimediali (multimedia container format); semplificando molto, siamo in presenza di un “wrapper” che ingloba al suo interno altri elementi, li mette nella giusta relazione tra loro tramite multiplexing, ed è capace di descrivere all’esterno il modo in cui questi vari elementi contenuti al suo interno (dati e metadati) devono coesistere nel file e devono essere letti dall’applicazione. Ma questo potrebbe non bastare: infatti l’applicazione che legge il formato e i metadati da esso forniti, deve essere anche in grado di decodificare positivamente gli elementi contenuti dentro il contenitore.
Infatti, continuando nella nostra semplificazione, gli elementi contenuti all’interno del multimedia container sono i flussi audio, video e di sottotitoli, opportunamente digitalizzati attraverso i famosi codec, ossia gli algoritmi di codifica e decodifica (spesso con compressione a perdita di informazione, ma anche senza perdita di informazione) che consentono la memorizzazione, la trasmissione e la riproduzione di tali dati: per il video, alcuni esempi sono WMV, Theora, H.263, H.264 etc.
Stesso container, codec diversi
In tal senso, se lo consideriamo come wrapper, un contenitore multimediale di un dato formato può contenere al suo interno flussi codificati anche in maniera diversa. Vediamo un banale esempio: un formato video proprietario come AVI (contenitore multimediale), che per anni ha rappresentato “il video”, almeno sui sistemi Windows, ha la possibilità di contenere al suo interno fino a due flussi audio e a un flusso video; non è in grado però, di contenere alcun flusso di sottotitoli. Per non complicare l’esempio, limitiamoci ai soli codec video, lasciando da parte per ora audio e sottotitoli: in un AVI, il flusso video può essere codificato/decodificato come MPEG-1, MPEG-2, MPEG-4, WMV, RealVideo, Theora, ma non può ad esempio essere codificato come Flash. Analogamente, in un formato aperto e libero come il contenitore multimediale OGG, potrei mettere dentro flussi video codificati con Theora, Dirac, OggUVS, ma non potrei inserire MPEG o WMV.
Se a questo aggiungiamo, nei numerosi codec disponibili, anche i flussi audio e i flussi testuali di sottotitoli… be’, la situazione può decisamente complicarsi. Chiaramente, al di là delle mille ipotesi possibili e dei numerosi codec disponibili (open o proprietari, migliori o peggiori come qualità di riproduzione, più o meno performanti in termini di risorse richieste ai processori), il sottobosco di soluzioni è stato in buona parte sfrondato dall’uso diffuso di certi abbinamenti standard “de iure” o da soluzioni imposte “de facto” dal mercato. E in questo senso, la grande diffusione dei dispositivi mobile ha fatto, nell’ultimo anno, la sua parte. Vedremo più avanti con quali implicazioni tecnologiche e commerciali, ma adesso concentriamoci un po’ sulla programmazione HTML.
Si è sempre fatto così
Prima di vedere le gioie e i dolori che HTML5 ci riserva per audio e video, prendiamo un attimo in esame il modo in cui era possibile gestire l’inserimento di audio e video nel codice HTML.
Tipo MIME / Internet Media Type
Tutti i lettori con un minimo di esperienza nella programmazione sapranno che cosa è lo standard Internet MIME (Multipurpose Internet Mail Extension): nato per gestire al meglio la spedizione della posta elettronica, consentendo l’invio di elementi diversi dal semplice testo ASCII, questo sistema di tipizzazione è largamente utilizzato con il protocollo HTTP e con la programmazione HTML per poter scambiare diversi tipi di contenuto. Si parla infatti di Internet Media Type o Internet Content Type. Tra i vari Internet Media Type, si identificano anche audio, image, video e application. Ogni tipo “principale” può essere ulteriormente specificato con un sottotipo “specifico”: per esempio video/quicktime o audio/x-flac.
Tag di inserimento
Nell’XHTML, per inserire un audio o un video, non esiste un tag di inserimento “diretto”. Ciò che occorre fare è impiegare il tag object che ci consente di inserire diversi tipi di “oggetto” all’interno del nostro codice. In tal senso, una clip audio o video sono “oggetti” (ma anche un PDF o un’animazione Flash). Il tag object ha un attibuto data il cui valore è semplicemente l’indirizzo del nostro oggetto (audio, video o altro). Occorre però specificare anche l’attributo type, che rappresenta il tipo di formato di questo contenuto multimediale. Restano comunque dei problemi a seconda del browser utilizzato ma il concetto è quello appena illustrato.
L’inserimento del tag embed (che non appartiene allo standard XHTML) all’interno di object, ha lo scopo di incrementare la retrocompatibilità del codice. Dobbiamo porre attenzione alla corretta definizione delle dimensioni del player, se si inseriscono valori non proporzionali al formato del video, lo stesso verrà deformato.
I parametri per il setting del video possono essere configurati attraverso una serie di tag param, generalmente replicati anche all’interno di embed.
Plugin
“Tradizionalmente” il sistema per gestire al meglio la visualizzazione corretta dei vari formati/codec nei browser è stato quello del plugin. Un apposito plugin dedicato consente al nostro browser di interpretare e mostrarci correttamente il contenuto audio e video indicato nel codice HTML: tenendo presenti tutte le versioni di uno stesso browser “abbastanza recenti” la situazione si complica. Questo è dovuto al fatto che i browser, di per se’, non avevano il supporto nativo per certi elementi. Anche nei casi “ottimali” in cui non sono apparentemente necessari i plugin, occore far notare che comunque il browser si “appoggia” su qualche API sottostante, come accade nel caso di Safari su Mac OS X che non necessita di un plugin Quicktime perche’ utilizza direttamente le librerie Quicktime del sistema operativo (in Windows invece Safari funziona bene se il plugin Quicktime è stato installato).
In certi casi, però, specie qualche anno fa, la procedura di scaricamento e installazione di plugin risultava tutt’altro che agevole. Inoltre, a ogni cambiamento sostanziale di versione di un browser doveva corrispondere l’adeguamento del “parco plugin” in grado di leggere tutti i formati più diffusi.
La promessa di HTML5
Una delle novità più attese di HTML5 era proprio quella relativa al trattamento dei “media” audiovisivi. Visto che audio e video hanno adesso un’importanza enorme nel web, HTML5 ne prende atto, semplificando notevolmente la loro gestione all’interno del codice.
Supporto nativo
Il primo e sostanziale passo verso la semplificazione è l’introduzione del supporto nativo per i diversi elementi audio e video all’interno dei browser: non sono più necessari i plugin, a patto di scrivere il codice nel modo giusto e di avere, ovviamente, un browser di ultima generazione che supporti nativamente i tag di incorporamento e i diversi formati/codec. Questo in teoria è semplice e lineare, ma vedremo poi che i problemi, anche con HTML5 continuano ad esistere, nonostante la innegabile semplificazione.
In questo nuovo panorama, con i nuovi browser che supportano HTML5, l’incorporazione nativa del video, ad esempio, avviene grazie all’elemento video che al suo interno delimita tutte le informazioni necessarie al browser per caricare e visualizzare il video. Notate che si fa riferimento a uno stesso video in tre diversi formati, per le ragioni che vedremo meglio più avanti nell’articolo.
Qui, tramite l’attributo src del tag source diciamo al browser dove andare a pescare il video (nella cartella media) e ne specifichiamo larghezza (width) e altezza (height); poi tramite controls diciamo di mostrare i classici controlli di un video (play, pause etc.) e tramite poster indichiamo che c’è una immagine “di copertina” che sarà mostrata all’utente mentre il video è in caricamento, prima che venga premuto play. Questo attributo non è necessario: se non è specificato, il browser semplicemente ci farà vedere come “fermo immagine” il primo fotogramma del video.
Ci sono anche altri attributi che è possibile usare: type, che specifica i formati video; autoplay, che fa partire il video automaticamente; loop, che lo ripete di continuo; muted, che lo fa partire con il volume azzerato. Vi è poi preload (valorizzabile come none o metadata o auto) che indica se e come il video vada precaricato. Preload sostituisce il buffer ma presenta, al momento, alcuni problemi: non tutti i browser implementano allo stesso modo il suo supporto e quindi realizzare una “barra di avanzamento” precisa che funzioni ugualmente bene con tutti i browser può rivelarsi più arduo del previsto.
Un dettaglio importante
Al di là del codec che verrà usato, diventa molto importante in questi casi anche la cura e l’attenzione nel modo in cui i formati audiovisivi vengono codificati: ripetute conversioni di “ratio” o di “framerate”, così come codifiche audio poco attente, possono creare dei problemi nella riproduzione dei file video e audio. Per esempio, si è notato [10] che una codifica audio “constant bitrate” a 44.1 kHz è preferibile per una corretta riproduzione dei contenuti audiovisivi sulla maggior parte dei browser.
La “dura” realtà dei fatti
Dicevamo prima del tag type e della sua importanza. Come abbiamo visto nella parte introduttiva, da un lato ci sono i “contenitori” dentro cui possiamo mettere flussi (audio/video/sottotitoli) codificati con diversi codec, dall’altro ci sono molti diversi browser che dovranno leggere questi file. Attraverso type è possibile specificare chiaramente il contenitore e i codec del file audio o video che il nostro browser dovrà leggere.
Qui, grazie all’attributo type, specifichiamo che il video chiamato “TitoloDelVideo” è di formato WEBM, codificato grazie ai codecs vp8 (per il video) e vorbis (per l’audio).
Identico discorso si può fare per l’audio: nel codice seguente, attraverso l’elemento audio, specifichiamo al browser di riprodurre il file audio “TitoloDellAudio” di formato OGG codificato grazie al codec vorbis.
La figura 1 mostra un quadro riassuntivo del supporto [7] dei diversi browser all’elemento
Figura 1 – Come emerge da questa tabella comparativa, nelle versioni più recenti dei browser, sia desktop che mobile, il supporto ai tag <audio> e <video> di HTML5 è pressoch� totale. Pesando la diffusione delle varie piattaforme, si stima che più dei due terzi dei dispositivi supporti questi elementi. Ma, come vedremo, non sono tutte rose e fiori.
Quindi? Tutto bene? Sì, se non fosse che:
- non esiste un solo formato audio e un solo formato video, ma ci sono svariati “contenitori” diversi;
- dentro un identico container possono essere usati codec diversi;
- soprattutto, non esiste (e non esisterà) un browser che supporti nativamente tutti i formati e tutti i codec…
Occorre quindi da un lato capire cosa è supportato e da chi, e dall’altro trovare delle soluzioni per far sì che, in un modo o nell’altro, il nostro brano audio o il nostro filmato possano essere ascoltati e visti da quanti più utenti possibili.
Districarsi tra i formati
Sebbene i MIME types siano parecchi, e sebbene, come già detto, sia possibile combinare dentro un identico contenitore dei flussi audiovisivi codificati con codec diversi, al momento attuale il quadro si orienta verso una relativa “standardizzazione”. Chiaramente sopravvivono anche formati tecnologicamente “vecchi”, seppur non obsoleti (audio MP3, video FLV, video AVI, etc.) con i quali occorre fare i conti.
In ambito video, che è quello maggiormente problematico, il rapporto che in genere esiste tra container multimediale e codecs usati è il seguente.
- il container MP4 usa il codec video H.264/MPEG-4 AVC e il codec audio AAC
- il container OGV usa il codec video Theora e il codec audio Vorbis
- il container WebM usa il codec video VP8 e il codec audio Vorbis
H.264: in futuro solo su Internet Explorer e Apple Safari
Se a questo punto analizziamo le tabelle che ci illustrano il supporto ai singoli codec video, vediamo che la faccenda si complica. In figura 2 è riportato il supporto al codec H.264, che è un codec proprietario, per il cui uso (almeno a livello commerciale) è necessario pagare royalties al detentore dei diritti, la società di Denver “MPEG LA, LLC”. H.264 è uno standard di compressione video a perdita di informazione (“lossy”) capace di ottenere ottimi risultati e che è usato estensivamente in tutta l’industria del video digitale (si pensi che è sfruttato nello standard dei dischi BluRay e nella trasmissione digitale a televisori ad alta definizione). Al momento è supportato totalmente da Apple Safari (su desktop e mobile) da Internet Explorer e anche da Google Chrome, ma, ed è notizia recente[8], le cose sono destinate a cambiare presto, poiche’ Chrome non supporterà più H.264 a partire dalle prossime versioni.
Figura 2 – Il codec H.264 è al momento supportato totalmente da Apple Safari (su desktop e mobile) da Internet Explorer e da Google Chrome… Ma nell’immediato futuro le cose cambieranno: saranno solo Explorer e Safari a mantenere il supporto totale (il browser di Android garantirà un supporto solo parziale).
Theora: il codec che non piace ad Apple
Il codec Theora è concesso in uso senza pagamento di royalties, e ha subìto negli ultimi anni notevoli migliorie, che, con la versione 1.1.1, lo hanno portato, per quanto riguarda la qualità, quasi al livello di H.264 (le differenze sono piccole). Questo codec è supportato dai browser Mozilla Firefox e Google Chrome, e da Opera, anche nella versione mobile, ma non viene supportato dai browser di Apple sia su desktop che su iOS.
Figura 3 – Theora è un codec che non viene supportato da Apple. Anche il browser di Android non lo supporta, nemmeno nella versione 4.0. Tutti gli altri browser forniscono invece attualmente un supporto estensivo a questo codec.
VP8: l’open source… di Google
VP8 è stato sviluppato da On2 (peraltro anche alla base del progetto da cui poi è nato Theora) società acquisita da Google nel 2010. Su “invito” della Free Software Foundation, Google ha deciso di rilasciare anche il codice sorgente di VP8, facendone di fatto un prodotto open source. VP8 è supportato sostanzialmente dagli stessi browser che supportano Theora (Chrome, Firefox, Opera), ma anche, e non c’è da stupirsi, dalle versioni più recenti di Android. Non ne è previsto il supporto, però, in casa Apple.
Figura 4 – Il supporto a VP8 è diffuso tra i browser più avanzati. Fa eccezione Safari, sia su desktop che su mobile.
Il “detective” dei codec
È chiaro a questo punto che per avere la garanzia di visualizzazione dei nostri video su tutti i browser di ultima generazione sui diversi sistemi, in HTML5, saranno necessari due passi fondamentali:
- effettuare la codifica del video usando codec e container diversi, ossia “duplicare” o anche “triplicare” il proprio contenuto audiovisivo nei diversi formati. In pratica, sarà necessario avere i propri video perlomeno in formato MP4 (con codec H.264) e WebM (con codec VP8), e meglio ancora anche in formato OGV (con codec Theora). Si tratta di un lavoro di encoding e/o conversione da condurre con grande precisione, che è certamente fattibile quando i nostri contenuti audiovisivi sono pochi; ma può diventare un lavoro faticoso in presenza di grandi moli di dati da gestire direttamente: i grandi siti che aggregano contenuti multimediali (come YouTube o Vimeo) hanno strumenti automatizzati di conversione (che, comunque, rappresentano un costo in termini di tempi e di potenza di calcolo).
- far sì che il particolare browser possa andare a pescare il contenuto multimediale nel formato ad esso più congeniale. Nel creare in HTML5 il nostro sito e nel metterci i contenuti audio e video da fruire, non possiamo sapere a priori con quali sistemi operativi (desktop o mobile) e con quali browser il nostro sito sarà utilizzato (o vogliamo tornare all’inquietante dicitura “ottimizzato per la visione sul tale browser”?). Occorre pertanto una soluzione che ci consenta di fornire al browser il giusto contenuto da esso supportato. E questo è il meccanismo della detection.
Detection
Con un po’ di codice JavaScript è possibile effettuare una “indagine” e capire che cosa il browser supporti o non supporti. Occorre però subito specificare che la detection va effettuata a livello approfondito. Non basta sapere se un browser supporta un determinato container, perche’ non sappiamo a priori cosa c’è dentro in termini di codec: possiamo ragionevolmente supporlo, ma non saremo certi.
Pertanto occorre che la detection sia effettuata “a basso livello” ossia andando a verificare anche quali codec effettivamente siano supportati dal browser in questione: un po’ di lavoro in più, ma la quasi certezza di non avere problemi.
var testEl = document.createElement("video"),
mpeg4, h264, ogg, webm;
if (testEl.canPlayType) {
// Si controlla il supporto per il MPEG-4
var typeStr = testEl.canPlayType("video/mp4; codecs="mp4v.20.8"" );
mpeg4 = typeStr !== "";
// Si verifica il supporto per il codec H.264
typeStr = testEl.canPlayType("video/mp4; codecs="avc1.42E01E"" )
|| testEl.canPlayType("video/mp4; codecs="avc1.42E01E, mp4a.40.2"" );
h264 = typeStr !== "";
// Si controlla il supporto per OGG con codec Theora
typeStr = testEl.canPlayType("video/ogg; codecs="theora"" );
ogg = typeStr !== "";
// Si controlla il supporto per WebM con codec VP8
typeStr = testEl.canPlayType("video/webm; codecs="vp8, vorbis"" );
webm = typeStr !== "";
}
Il metodo canPlayType è quello che svolge il ruolo centrale, perche’ ci consente di verificare il tipo di codec effettivamente supportato.
Modernizr
In aiuto dello sviluppatore viene una pratica libreria JavaScript, Modernizr [11] di cui abbiamo già parlato nel quinto articolo di questa serie [12]. In pratica, Modernizr è una libreria di “feature detection” cui è possibile delegare la verifica del supporto di determinate funzioni HTML5 all’interno del browser. Giunto alla versione 2, lo scorso anno questa utility ha vinto, giustamente, il premio “.net Awards 2011” come migliore applicazione open source assegnato dalla rivista “.net”: una risorsa davvero utile per lo sviluppatore.
Ci sarebbero molti altri aspetti tecnici da trattare, tra cui il funzionamento dello streaming, le differenze strutturali tra browser desktop e browser dei sistemi operativi mobile (mondo dominato da iOS e Android, ma in cui una piccola fetta resta comunque in carico a Symbian, Blackberry e Windows Phone, che non vanno dimenticati), la compatibilità dei diversi video player con i browser e con i formati supportati [9] o l’aspetto dei metadati legati ai contenuti multimediali (Media Annotations) [13]. Ma vogliamo concludere con qualche breve riflessione non strettamente tecnica, ma più legata alle strategie dei grandi gruppi del mondo IT. Molte scelte tecnologiche, infatti, trovano la loro giustificazione più in aspetti commerciali e di gestione/dominio del mercato che non in aspetti squisitamente tecnici, anche se spesso questi ultimi sono usati per “giustificare” certi orientamenti.
Battaglia dei formati: tecnologica o di mercato?
Abbiamo dunque visto che, tra i formati nuovi e il loro supporto da parte dei browser, l’immediato futuro sembra chiaramente configurare una divisione. In particolare, per il video, da un parte si pone il blocco (inusuale) Apple + Microsoft orientato al supporto di MP4 (codec video H.264 + codec audio AAC), dall’altra il gruppo dei sostenitori di WebM (codec video VP8 + codec audio Vorbis), ossia Google, Mozilla, Opera che poi sono grosso modo anche i sostenitori di OGV (codec video Theora + codec audio Vorbis). Spesso l’affermazione che MP4 è meglio di OGV in termini di qualità è servita a giustificare certe scelte (e in effetti, la qualità di H.264 rispetto a Theora è leggermente superiore, ma non in modo così netto, specie con le ultime versioni del codec Theora). Del resto non sempre la qualità è il fattore chiave di adozione di un formato. L’MP3, ad esempio, a parità di dimensioni del file compresso, ha una qualità di resa sonora inferiore all’OGG audio, ma questo non gli ha impedito di diventare, nel decennio scorso, lo standard de facto dell’audio digitale compresso (anche se poi certi grandi gruppi di produttori di contenuti audio, come la BBC Radio, ad esempio, hanno scelto il formato OGG per i suoi contenuti). Se per questo, poi, il codec VP8 è ancora migliore di Theora, ed è sostanzialmente paragonabile in termini di qualità al più diffuso H.264. E, tanto per spiegare che il discorso non è nuovo, per i più giovani tra i lettori sarà bene andarsi a (ri)leggere la storia della lotta fra formato Betamax e VHS a fine anni Settanta, nell’oramai defunto mercato delle videocassette.
La discussione sui formati video in HTML5
In realtà, la specifica HTML5 su questo tema si è “arresa” abbastanza presto. Inizialmente era esplicitamente previsto il supporto per codec audio e video che fossero open source, di buona qualità, e gratuiti, specificando che i realizzatori di browser dovessero “supportare il codec video Theora e il codec audio Vorbis audio insieme al formato contenitore OGG”. Ma alla fine del 2007 questa frase è stata sostituita da una più generica “dichiarazione di intenti” in cui si dice che i contenitori e i codec supportati dovranno essere di buona qualità e senza brevetti “sommersi” (cioè senza il rischio che qualcuno possa rivendicare all’improvviso la paternità di un formato, ma non necessariamente senza che ci sia un licenziatario palese e onestamente presente sul mercato, come accade per MPEG LA LLC, licenziataria di H.264).
Si tratta in pratica, di quello di cui abbiamo già parlato nei primissimi articoli della serie: sono i grandi attori del mercato IT a dettare le specifiche al W3C, con netto risparmio di tempo sull’effettiva implementazione delle specifiche, ma con tutto il peso dei loro interessi commerciali che va a sovrapporsi al lungo e burocratico sistema fin qui usato per definire le specifiche HTML, il quale però aveva dalla sua una maggiore democraticità.
E in tal senso, Apple critica la qualità di Theora e dichiara di non supportare questo codec per timore che non si tratti poi di un formato sicuramente libero, e dà il suo appoggio a H.264 (per il cui uso a livello commerciale da parte delle aziende occorre comunque pagare delle royalties) che è in effetti il codec più diffuso, anche in ambito di TV digitale. Dall’altra parte, Google mette a punto (o meglio, si compra l’azienda che mette a punto) il codec VP8 qualitativamente comparabile al più diffuso e standardizzato H.264, lo rilascia senza richiesta di royalties e con il beneplacito della Free Software Foundation, e da un lato dichiara che non supporterà più nel suo browser Chrome il “rivale” H.264, dall’altro ha cominciato a convertire tutto il “patrimonio” di video presenti su YouTube proprio in formato WebM utilizzando il codec VP8. E in tutto questo, Opera e Mozilla reclamano a gran voce che il formato WebM (VP8 + Vorbis) sia incluso ufficialmente in HTML5.
La situazione verso cui si va incontro potrebbe essere una nuova edizione della “guerra dei browser” evolutasi in una “guerra dei codec”: da un lato WebM/VP8 (Google+Mozilla+Opera, e Android come principale OS mobile), dall’altra H.264 (Apple+Microsoft, e iOS come principale OS mobile). Non si tratta tanto di schierarsi con l’uno o con l’altro contendente, quanto di capire le motivazioni che spingono a questa “guerra” nell’immediato futuro
Il nuovo campo di battaglia: la televisione
La cara vecchia televisione analogica è andata in pensione. Va da se’ che il concetto di TV non è però morto. Sì, tutto il discorso del “palinsesto fisso e imposto” vs “palinsesto liquido e personalizzato” è vero: ma non è che con questo concetto (“posso guardare quello che voglio quando voglio/posso”) muoia il concetto di TV; esso, semplicemente, cambia pelle. Del resto, sebbene in maniera più macchinosa, qualcosa del genere già avveniva tanti anni fa, con l’uso del videoregistratore per potersi vedere successivamente qualche trasmissione o qualche film trasmessi in un orario in cui non si poteva/voleva stare davanti al televisore; e tale modalità di fruizione viene oggi tecnologicamente aggiornata da quei sistemi digitali di registrazione tipo MySky.
Oggigiorno la diffusione di apparecchi TV digitali consente lo sviluppo di nuovi modelli di business legati alla TV, oltre al classico modello derivato dalla televisione analogica. A tal proposito, sebbene entrambe sfruttino l’infrastruttura Internet, è bene fare una distinzione chiara tra IPTV e WebTV. L’IPTV è un sistema di abbonamento per cui un distributore di servizi apre i diversi canali, su pagamento, a un preciso indirizzo IP che fruisce di tali flussi di dati opportunamente decodificati da un decoder (“set-top box” interno o esterno al televisore) che ne permette la visione. In genere, quando si parla di IPTV, si fa riferimento anche a precisi standard tecologici di trasmissione (almeno per quanto riguarda mercati omogenei). In Europa, ad esempio, sempre più diffuso è il codec H.264 che sta sostituendo progressivamente il vecchio MPEG-2. WebTV o Internet TV sono invece termini che stanno a indicare qualcosa di diverso: i grandi “broadcaster” nelle diverse nazioni mettono a disposizione del loro pubblico un archivio digitale che contiene parte del loro palinsesto e che può essere fruito attraverso un adeguato player, in genere personalizzato, sia sul computer, sia su televisori che abbiano supporto al collegamento internet. Per esempio, nel Regno Unito, l’iPlayer della BBC è un vero e proprio “canale” principale di fruizione dei contenuti che, in alcuni casi fa registrare, per una stessa trasmissione, più contatti di quelli che si verificano con la visione su TV: chiaramente è una forma di TV “on demand” che si adatta bene al desiderio di guardare certi programmi dove e quando si può.
A guardar bene, il confine tra IPTV (in pratica “televisione via cavo” basata su infrastruttura Internet, ma con palinsesto fisso) e Web/Internet TV (in pratica “televisione on demand” fruibile su computer, tablet, TV, in cui si guarda quel che si vuole quando si vuole), è sempre più labile. Il futuro vede sempre maggior convergenza tra questi due aspetti, e di conseguenza, anche un nuovo mercato che va sfruttato al meglio.
I progetti TV dei colossi
In pratica, è proprio il mercato televisivo dei prossimi anni che fa gola a Google e Apple, ed è questa la ragione per cui diventa fondamentale “controllare” il formato con cui i contenuti audiovisivi da fruire vengono distribuiti. Se l’audiovisivo viene trasmesso in un solo formato, ogni dispositivo hardware/software di qualsiasi produttore mi consentirà di vederli. Ma se i formati sono diversi, dovrò fare una scelta e acquistare il prodotto (hardware e/o software) che mi consente di vedere uno o l’altro formato, favorendo di fatto qualche produttore. E questo è un modello di business, magari discutibile sul piano della libertà di fruizione dei contenuti, ma che funziona. Diventa quindi il codec a influenzare il successo e la vendita di un determinato lettore di quei contenuti (non dimentichiamo che questi codec possono essere anche inglobati direttamente in apparecchi hardware). Pertanto la scelta di supportare uno o l’altro codec ha senso anche e soprattutto in termini di rapporti con i produttori di contenuti audiovisivi (abbiamo già detto che il BluRay adotta il codec H.264).
Sia Apple, con il prodotto Apple TV [14], sia Google, con il prodotto Google TV [15] (grande fantasia nei nomi, eh…), forniscono un sistema per la fruizione di film, notiziari, trasmissioni, contenuti multimediali in genere, sia presenti sulla rete, sia residenti sui nostri hard disk (o, sempre di più, “nella nuvola”). Senza entrare nel dettaglio dei prodotti, per cui rimandiamo ai siti ufficiali, l’hardware di Apple TV consiste in un piccolo set-top box (grazioso come di consueto con i prodotti della casa di Cupertino) da collegare a un televisore HD, mentre Google TV si concretizza in un set-top box, o anche in un televisore HD che ha il decoder incorporato.
Una cosa è certa: nonostante la partenza appaia ancora stentata per entrambi, su questo fronte si concentreranno molti degli sforzi e degli interessi dei due grandi attori del mondo IT. Integrazione fra contenuti audiovisivi diversi, integrazione con altri dispositivi (in primis tablet e smartphone) ma anche tipologia, qualità e tecnologia di codifica dei contenuti stessi svolgeranno un ruolo fondamentale nella spartizione del mercato, o nella prevalenza di uno dei due sistemi.
Con buona pace della promessa di HTML5 di semplificare la fruizione di audio e video digitale…
Conclusioni
In questo articolo abbiamo affrontato il complesso tema dell’audio e video per il web sotto due punti di vista.
Da un lato ci siamo focalizzati sugli aspetti meramente tecnici, mettendo in luce sia gli elementi fondamentali relativi a formati “contenitori” multimediali e codec, che quelli inerenti il corretto incorporamento degli elementi multimediali all’interno del codice HTML5. Abbiamo osservato come HTML5 abbia notevolmente semplificato tali operazioni: restano comunque una serie di considerazioni sulla compatibilità e sul supporto ai diversi codec, e gli sviluppatori devono sempre avere molta cautela nel tener presenti le diverse configurazioni (browser/dispositivo/supporto a certi codec) che si possono trovare a incontrare. Strumenti come Modernizr possono facilitare il compito.
Dall’altro lato abbiamo visto come dietro questa battaglia di formati, apparentemente solo “tecnologica”, si profili invece l’interesse delle grandi aziende dell’IT e del web per i possibili sviluppi tecnologici della piattaforma “televisiva”: essere in una posizione dominante per quanto riguarda il modo in cui i contenuti audiovisivi vengono codificati, può rappresentare un punto di forza nel “possedere” certi contenuti e quindi garantirsi anche un pubblico più ampio.
Riferimenti
[1] Danny Winokur, “Flash to Focus on PC Browsing and Mobile Apps; Adobe to More Aggressively Contribute to HTML5”
http://blogs.adobe.com/conversations/2011/11/flash-focus.html
[2] Il sito del WHATWG
[3] La nuova Editor’s Draft di Ian Hickson sul sito del W3C
http://dev.w3.org/html5/spec/Overview.html
[4] HTML5 Readiness
http://www.html5readiness.com/
[5] HTML5test misura la compatibilità dei browser
[6] Il sito di HTML5Rocks che fornisce una nutrita serie di esempi
[7] Il sito “When can I use…” fornisce delle tabelle comparative sul supporto alle diverse funzionalità di HTML5 da parte dei diversi browser sia desktop che mobile. Le ricerche sono personalizzabili.
[8] Google toglie da Chrome il supporto al codec di Apple.
http://blog.chromium.org/2011/01/html-video-codec-support-in-chrome.html
[9] La tabella comparativa dei player disponibili e del loro supporto
http://praegnanz.de/html5video/
[10] Il video dell’ottimo intervento (in lingua inglese) di Mark Boas alla conferenza Better Software 2011
[11] Modernizr, lo strumento JavaScript che consente di individuare se un browser abbia o meno il supporto per determinate funzioni di HTML5.
[12] Hoang Chau Huynh, “HTML5, CSS3, JavaScript e il mobile – V parte: Salvare informazioni in locale”, MokaByte 162, maggio 2011
https://www.mokabyte.it/cms/article.run?articleId=5DD-FIH-2N3-4H8_7f000001_31945162_ad609fa7
[13] Media annotations
http://www.w3.org/2008/WebVideo/Annotations/
[14] Apple TV
http://www.apple.com/it/appletv/
[15] Google TV