Ormai se ne parla un po’ ovunque: l’HTML 5 apporterà davvero tante novità, la maggior parte di queste, sicuramente diventeranno gioie e dolori per chi del web ne sviluppa le interfacce, chi realizza il markup…altri aspetti, altrettanto innovativi, danno origine a speculazioni di vario genere.
Ma prima di arrivare al punto, una piccola parentesi: dovete sapere che quando nel lontano 1996 Google non era ancora l’indice della Rete, una delle mie attività preferite sul web (oltre a scrivere un blog in inglese sulla realtà virtuale immersiva 🙂 ) consisteva nel praticare ore (notturne) di netsurfing selvaggio: semplicemente partendo da un sito che mi interessava, proseguivo senza alcun freno verso i link in uscita da quella pagina…questa attività, molto spesso, conduceva su pagine sperdute nella rete, dove mi ritrovavo a leggere di chissà quali argomenti.
Ebbene, nel corso degli anni (per motivi di facile comprensione), ho un po’ abbandonato questa pratica, ma capita che avendo sempre con me un “cellulare connesso alla rete” (se mi sentisse Steve Jobs… 🙂 ), di tanto in tanto riesco a riprovare questa esperienza.
Di recente, infatti, sono incappato in un sito dove il tema principale è l’approccio all’imminente html5 ( Dive Into HTML5 ) e, in particolare, mi ha colpito la completezza con cui vengono descritti i protocolli di codifica, le questioni di licenze annesse e connesse e le alternative open per realizzare e riprodurre contenuti video su pagine conformi al nuovo standard.
Di cosa si tratta: in poche parole, con l’avvento dell’HTML 5, sarà possibile inserire video all’interno delle pagine html utilizzando un tag (<video>, per l’appunto), esattamente come avviene ora per le immagini (mediante il tag <img>).
Attualmente, invece, l’inserimento di un contenuto video in una pagina html prevede l’inclusione di un oggetto (il player) preposto alla riproduzione dei video: negli ultimi anni, infatti, la diffusione di player video in Flash hanno fatto la fortuna di progetti com YouTube e Vimeo e, in virtù della loro notorietà, aumentato enormemente la diffusione di contenuti video in rete.
Di pari passo con la diffusione di player Flash per i video, è altrettanto diffuso proprio il formato di codifica dei video compatibile con Flash: l’FLV (FLash Video).
Attualmente, per inserire un player flash e riprodurre video flv in una pagina html, infatti:
- I video da riprodurre vanno convertiti (o transcodificati, come direbbe il mio prof di Elaborazione Numerica dei Segnali 🙂 ) nel formato FLV
- Il player (che di fatto è un programma flash, compilato, con estensione .swf) va reso disponibile sul server
- All’interno della pagina html dove inserire il video (ed il relativo player), vanno aggiunte le istruzioni di embed necessarie ad informare il browser che dovrà eseguire un programma, in flash, con determinati parametri (il percorso del file al punto 2 e, generalmente, anche il percorso del video .flv al punto 1)
- L’utente deve avere installato un plug-in per eseguire nel browser applicazioni flash (come le animazioni, i banner animati…i player flv)
…ed è proprio su quest’ultimo punto che vorrei soffermarmi: fermo restando che qualunque contenuto video, affinché sia “riproducibile”, in un modo o nell’altro, prima o poi, andrà transcodificato e che, anche sull’inserimento di tag nella pagina non ne possiamo fare a meno, ciò che attualmente è legato alla specifica tecnologia (di riproduzione) utilizzata, richiede:
- L’esistenza di un player sul server
- L’esistenza di un plug-in sul client
Questo è quanto accade ora, con Flash.
…e qui arriva la mia speculazione: se HTML5, con l’avvento del tag <video> ed il relativo demand al browser della scelta del miglior player (disponibile dal sistema operativo), per riprodurre filmati non solo in flv ma anche (e, credo, soprattutto) in H.264, in un certo senso tenderà a “liberare” la questione dell’embed di video dai punti 2 e 4 dell’elenco di sopra,
è plausibile che il predominio di Flash, per la riproduzione di video, ne sarà influenzato ?
La mia risposta è: FORSE, soprattutto perché se è vero che convertire e riprodurre video in FLV non è esente da costi/condizioni di licenza a favore di Adobe, la situazione non è molto differente se, anziché usare Flash Video, si usa Windows Media, QuickTime e persino H.264 (come riporta quell’articolo su DiveIntoHtml5)…ovviamente esistono soluzioni open e questo scenario, magari, farà da cassa di risonanza proprio ai formati di codifica open source.
Ma la considerazione immediatamente successiva è quella relativa all’accesso dei dispositivi dotati di browser web, sinora sprovvisti di plug-in per Flash, a contenuti video su pagine conformi allo standard HTML5:
In questo momento, ad esempio, la versione di Safari per iPhone non supporta Flash in quanto Adobe non ha rilasciato un plug-in che consenta al gioiellino di casa Apple di riprodurre filmati Flash e, di conseguenza, player .flv qualora questi siano presenti nelle pagine…
Ma il motivo per cui sto spostando l’attenzione di questo post sul discorso mobile non è casuale 🙂
…vediamo se riesco a rendere l’idea:
- Attualmente un Nokia N97, ad esempio, a differenza di altri palmari, può riprodurre contenuti Flash ed ha un supporto di terze parti (Adobe) a contenuti quali Flash e Pdf
- Google, anni fa ormai, acquista YouTube: decisamente il più diffuso portale di video sul web…che sinora usava esclusivamente Flash
- Ma Google sta sviluppando Android quindi, al pari di YouTube, potrebbe ritrovarsi a “dipendere” da una tecnologia proprietaria (non sua 🙂 ) per riprodurre filmati sul browser dei dispositivi dotati di Android
…e ora un po’ di domande:
- Che succede se YouTube inizia a sposare la causa dell’HTML 5 e, magari in poco tempo, iniziare a testare i video in HTML5 a scapito di Flash Video ?
- E’ un caso che Chrome (il browser di Big G, alla base anche del futuro Google OS) sia basato su WebKit, attualmente il framework per lo sviluppo di client web che meglio supporta HTML5…e che questo framework sia lo stesso su cui è basato Safari (sia su Mac che su iPhone) ?
- E’ un caso che su YouTube sia costantemente suggerito l’uso di Chrome ? (ovviamente, il primo motivo per farlo è quello di risicare quote di utenti a IE, Firefox ed altri…ma, secondo me, il motivo è più profondo…)
- Se Google (e tutti i progetti in suo possesso) ed Apple non avranno più necessità della tecnologia di Adobe, in virtù dell’alternativa derivante dall’utilizzo di HTML5 per il supporto del video sul web, chi ne trarrà i maggiori benefici ?
Personalmente piuttosto che addentrarmi nelle speculazioni su risvolti commerciali, mi piace concentrarmi sull’effetto che un simile ipotetico scenario avrà sui dispositivi che tutt’ora utilizziamo e che, ancora di più, avremo magari in tasca, in borsa, in ufficio e con cui accederemo alla rete nei prossimi mesi:
il mio MacBook Air non potrà che ringraziare se anziché stressare i due core del processore per far andare un player flash, demanderà l’esecuzione dei contenuti video, anche in HD, a Quartz e fratelli 🙂
Insomma, dal punto di vista dell’utente, io credo che i cambiamenti (soprattutto se nella direzione degli standard) non possano che produrre miglioramenti e, cosa piuttosto usuale sul web, favorire l’open source a scapito di tecnologie proprietarie…ma dov’è che l’utente davvero ci guadagna ?! sicuramente quando le aziende, man mano che prendono coscienza di tale processo, si staccano dal concetto di royalty a favore dei servizi da poter offrire: IMHO su questo Big G è davvero lungimirante,
staremo a vedere.
