di  -  giovedì 20 maggio 2010

Solamente due settimane fa vi parlai dell’annuncio da parte di Microsoft di supportare nel suo futuro Internet Explorer 9 il solo formato H.264 per la riproduzione di video sul web nel tag video del facente parte dello standard HTML5.

Proprio in quella sede, analizzai la situazione che vede, in questo specifico ambito, due schieramenti opposti. Da un lato Microsoft e Apple che puntano su H.264, tecnologia proprietaria concessa in uso gratuito per 5 anni per quanto concerne la riproduzione di contenuti video sul web, dall’altro Google e Mozilla che, invece, spingevano per l’adozione del più datato, ma open source, codec Ogg Theora.

L’uso dell’imperfetto non è un caso in quanto Google ha annunciato la nascita del progetto WebM, un nuovo formato di file multimediale che racchiude al suo interno il codec VP8 per la codifica video, il noto codec audio Vorbis ed un container che si basa su un sottoinsieme del Matroska.

L’aspetto più interessante di questo annuncio è che per l’occasione Google ha reso open source con licenza BSD il codec VP8, facente parte delle proprietà intellettuali di On2 Technologies acquistata da Big-G il 19 Febbraio di quest’anno e già nota per aver partorito e reso open source il codec VP3 alias Ogg Theora.

La notizia potrebbe assumere una rilevanza storica perché se il formato Ogg Theora poteva far storcere il naso a molti a causa della sua arretratezza tecnologica rispetto al più recente H.264, VP8 può contare su specifiche più moderne. A tal proposito, tuttavia, un confronto tecnologico tra VP8 e H.264 per capire tecnicamente quale sia il migliore è molto difficile da effettuare anche perché le specifiche di un formato sono cosa ben diversa dalla sua implementazione: un codec scadente H.264 può dare risultati ben peggiori di un ottimo codec MPEG2.

Superato, quindi, lo scoglio tecnico, Google può vantare già un’ampia schiera di partner tra i quali ci sono non solo Mozilla, Opera e Adobe, ma anche produttori hardware del calibro di ARM, Broadcom, NVIDIA, Qualcomm e Texas Instruments.

Il supporto da parte dei produttori hardware giocherà un ruolo fondamentale nella crescita della diffusione di questo formato in quanto, benché VP8 possa contare su un’implementazione software già molto efficiente (secondo quanto afferma Google), la riproduzione accelerata in hardware è vitale per competere con H.264 che, in questo campo, ha un tangibile vantaggio.

In attesa di veder annunciare ufficialmente a Google l’adozione di WebM quale formato prescelto per la diffusione dei video su YouTube, non ci resta che attendere la contromossa di Apple, visto che la stessa Microsoft ha appena rivisto la sua posizione in merito al supporto su Internet Explorer 9 annunciando che quest’ultimo sarà in grado di supportare il formato video VP8 se sul computer sarà installato il relativo codec.

25 Commenti »

I commenti inseriti dai lettori di AppuntiDigitali non sono oggetto di moderazione preventiva, ma solo di eventuale filtro antispam. Qualora si ravvisi un contenuto non consono (offensivo o diffamatorio) si prega di contattare l'amministrazione di Appunti Digitali all'indirizzo info@appuntidigitali.it, specificando quale sia il commento in oggetto.

  • # 1
    Emanuele Rampichini
     scrive: 

    La notizia buona è la convergenza di player importanti del mercato. Vedremo come evolverà la situazione.

    Per chi volesse approfondire il lato tecnico c’è una prima analisi da parte di uno sviluppatore del codec x264:

    http://x264dev.multimedia.cx/?p=377

  • # 2
    goldorak
     scrive: 

    Molto bene, e’ irrilevante che VP8 sia un pochino meno prestante di x264 (che ricordo sempre e’ una specifica implementazione di H264. Ci sono molti altri encoders commerciali di H264 la cui qualita’ e’ molto inferiore a quella di x264 e tuttavia vengono usati eccome), perche’ quello che il mondo free/open source ha da guadagnare dal uso di tale codec annulla qualsiasi tipo di critica sopratutto se le critiche sono puramente FUD.
    Mi fa enormemente piacere che sia Mozilla che Opera siano onboard.
    Non vedo l’ora di provare la prossima build di Opera con il supporto a VP8. E visto che google sta gia’ trascodando i video di youtube su VP8 (ne hanno gia’ trascodati 1300000 a quanto pare) cosa che molti dicevano che era impossibile direi che siamo sulla strada giusta.
    Ironia della sorte, anche Adobe supportera’ VP8 in Flash.

    Per quelli che sotengono ancora il FUD sui brevetti, l’analisi fatta qui http://x264dev.multimedia.cx/?p=377 e’ molto “allegra”. Per violare un brevetto e’ necessario che la tecnica sia esattamente la stessa, se gli sviluppatori di VP8 hanno usato una tecnica “simile” ma diversa quel che basta per non violare i brevetti di H264 siamo a cavallo. Ed e’ questa la cosa piu’ importante.

  • # 3
    Filippo Bistaffa
     scrive: 

    Quindi non è attendibile questa affermazione? “Even VC-1 differed more from H.264 than VP8 does, and even VC-1 didn’t manage to escape the clutches of software patents”

  • # 4
    goldorak
     scrive: 

    Cosa centra VC-1 con VP8 ?
    Gia’ il fatto che Mozilla (che e’ totalmente contraria ai brevetti software) e Opera abbiano dato l’assenso all’uso di VP8 nei loro browser e’ indice che il pericolo di qualche infrazione di brevetti sia insignificante (diciamo allo stesso livello di Theora).
    Inoltre siccome le specifiche sia di Theora che di VP8 sono open source, tutti compresi i membri della MPEG LA possono vedere se ce’ qualche infrazione di brevetti su H264. E se esistono lo faranno sapere. Per quel che riguarda invece i “submarine patents” beh li’ il problema e’ di tutti, Theora, VP8. H264 e qualsiasi altro codec esistente.

  • # 5
    degac
     scrive: 

    Quindi – da un punto di vista puramente ‘commerciale’ – il fatto che Google appoggi VP8 comporterà una ‘migrazione’ dei servizi di YouTube (ora mi sembra in H264 per l’HD).
    Apple – non volendo rimanere da sola e/o troppo isolata – sicuramente cambierà strategia sui ‘5 anni gratuiti’… una mossa indiretta di Google (che ha solo vantaggi data l’acquisizione di ON2, avere un codec e non poterlo sfruttare non serve a nulla…)
    Avremo quindi una coesistenza tra H264 (Apple) e VP8 (Google-Android).
    L’unico vincolo è quello hardware: sono molte le schede video che integrano in hardware le specifiche (o parte di esse) per la decodifica H264 – probabilmente con qualche aggiornamento dei driver anche questo ostacolo dovrebbe venir superato.

  • # 6
    Filippo Bistaffa
     scrive: 

    Centra perché (a quanto dice il dev di x264) era meno “somigliante” di VP8 a H264, e nonostante questo è andato incontro a problemi riguardanti brevetti. Quindi a maggior ragione anche VP8.
    Tu invece affermi il contrario, ovvero che se non sono esattamente identici non ci sono problemi…

    Quindi volevo capire come è esattamente la faccenda, tutto qua

  • # 7
    goldorak
     scrive: 

    @ Filiuppo Bistaffa :

    Ti rispondo quotando quello che ha scritto uno dei sviluppatori di Theora a proposito della critica del dev di x264.

    Monty/Xiphmont (Xiph.org – Ogg Theora lead developer) have commented a bit on the x.264 developers analysis in a comment to his own blog post here: http://xiphmont.livejournal.com/50239.html

    === QUOTE ===
    “Do you believe that VP8 is more or less a rip off h264″

    No. That’s pretty serious hyperbole. Some design chunks look very similar even to the trained eye, but details matter in both code and patents. DS ignored the details.
    === QUOTE ===

    I dettagli sono importanti, il fatto che il codice sia piu’ o meno simile non indica niente sulla presunta infrazione di brevetti di H264. Occorre andare a vedere il come e’ stato implementato e su questo punto il dev di x264 non ha detto niente. Si e’ soltanto limitato a dire “sono simili”. Ma questo non basta per inferire che VP8 infrage su qualche brevetto di H264.
    poorly documented though.

  • # 8
    Cesare Di Mauro
     scrive: 

    Dall’analisi dei link emerge la seguente situazione: VP8 è qualitativamente inferiore a H264, e richiede più risorse hardware per essere implementato. Tra l’altro il supporto hardware è ancora tutto da vedere.

    A parte questo, è simile a H264 (profilo base). Dal confronto fra le singole caratteristiche dei due codec è chiaro che VP8 abbia “preso in prestito” interi pezzi di H264, e non si tratta di poca roba.

    Bisognerà vedere se questa roba sia coperta o meno da brevetti; a mio avviso sono troppe le cose in comune, per cui ci sono serie possibilità che vi siano delle violazioni.

    Preciso che non conta l’implementazione, cioè il codice. Non è che se implemento il codec aritmetico del JPEG in maniera diversa da come l’ha fatto IBM, non infrango i brevetti di quest’ultimo…

  • # 9
    elevul
     scrive: 

    Yahooo!!!!
    Dopo la notizia dei problemi legali legati al rilascio con licenza BSD temevo che Google avrebbe rinunciato a rilasciarlo.
    Invece non ci ha delusi.
    Tanto di cappello e grazie mille a Google! :D

  • # 10
    goldorak
     scrive: 

    @ Cesare di Mauro : da quel link emerge soltanto che in determinate circostanze VP8 e’ leggermente inferiore a x264. Non metterti anche tu a confondere x264 con H264. Come ho gia’ detto ci sono una miriade di encoders commerciali di H264 la cui qualita’ e’ inferiore a quella di x264. E nonstante questo vengono regolarmente usati quindi come vedi e’ inutile pigiare sul tasto “qualita'” come se questo fosse il motivo principale dell’adozione di H264 sul web.
    Vuoi fare un confronto serio tra VP8 e H264 ? Benissimo e allora confrontalo con tutte le implementazioni di H264 che ci sono oggi sul mercato. ^_^

    E se hai letto il blog di quello sviluppatore, ti sarai anche reso conto perche’ la qualita’ di VP8 e’ inferiore a quella di x264. Semplicemente perche’ gli sviluppatori di VP8 hanno fatto a meno di usare tecniche brevettate !!! che in questop frangente danno un vantaggio a H264.

  • # 11
    Cesare Di Mauro
     scrive: 

    Il confronto era dal punto di vista delle mere caratteristiche tecniche utilizzate dai due codec, ed è evidentissimo come VP8 sia decisamente inferiore ad H264, a maggior ragione (ed è anche ovvio) visto che fa a meno di diverse funzionalità atte proprio a migliorare il fattore di compressione a parità di qualità ottenuta (già il solo mancato supporto ai B frame si fa sentire; e se sei appassionato di compressione video sai benissimo quanto sia “pesante” questa caratteristica).

    Poi è chiaro che l’implementazione conta, ma qui, permettimi: se si può realizzare un ottimo codec VP8, si può fare lo stesso con H264. E quest’ultimo è sicuramente molto più conosciuto, supportato e con parecchia gente che c’ha sbattuto la testa per migliorarlo.

    Quindi, c’è poco da fare: VP8 rimane nettamente inferiore ad H264 (e superiore quanto a risorse hardware necessarie per implementarlo).

  • # 12
    elevul
     scrive: 

    Ora che ci penso, se usano il matroska vuol dire che nei video si potranno embeddare anche i sottotitoli!!! O__O

  • # 13
    HostFat
     scrive: 

    Spero che il VP8 prenda piede il più velocemente possibile.
    Prima questo succederà, più difficile sarà in futuro attaccarlo per problema di brevetti e quant’altro.
    Una volta superato questo problema, si potranno anche passare a nuove specifiche ( un webm 2 :D ), e magari sforare dove prima i brevetti non permettevano di proseguire.

  • # 14
    goldorak
     scrive: 

    @ Cesare di Mauro : perdonami ma le tue critche sono infarcite di iperbole. Se Youtube che da ieri ormai trascoda tutti i file uploadati da 720p in su’ in VP8 non si fa problemi sulla qualita’, perche’ tu e tutti i denigratori invece si ? Io non dico che VP8 e’ superiore a H264, perche’ evidentemanete non lo e’. Nessuno lo nega. Ma tra il dire che e’ leggermente inferiore a H264 al dire che e’ totalmente inutile per un uso sul web ce’ ne passa di acqua sotto i ponti. Poi che non venga usato come codec sui blu-ray ma chi se ne frega sinceramente. Stiamo parlando del web, di youtube, di dailymotion della miriade di siti che usano user generated ocntent. E per questi, l’uso di codec royalty e patent free e’ piu’ importante che una leggerissima perdita di qualita’.

    Poi ci saranno alcuni siti tipo Hulu etc… che useranno H264 se lo ritengono necessario. Ma la scelta di avere un codec royalty a patent free per tutti gli altri e’ di fondamentale importanza per l’ecosistema del web.

    Finisco col dire che il concetti di compressione avra’ sempre minor importanza andando avanti nel tempo. Vuoi perche’ l’infrastruttra di rete verra’ aggiornata, vuoi perche’ la banda a disposizione aumentera’ per tutti. Quindi quanto vuoi scommettere che tra 5-10 anni a nessun freghera’ un fico secco che VP8 non usi B-Frames perche’ tanto di banda per lo streaming ce ne sara’ a sufficienza per garantire un ottima qualita’ ?

  • # 15
    Cesare Di Mauro
     scrive: 

    @goldorak:

    perdonami ma le tue critche sono infarcite di iperbole.

    Non vedo dove. E poi sono di carattere puramente tecnico.

    Se Youtube che da ieri ormai trascoda tutti i file uploadati da 720p in su’ in VP8 non si fa problemi sulla qualita’, perche’ tu e tutti i denigratori invece si ?

    Io non denigro nessuno: da tecnico ne faccio una questione tecnica, e la tua domanda sai bene essere del tutto fuori luogo, visto che non ho mai detto nulla del genere.

    Io non dico che VP8 e’ superiore a H264, perche’ evidentemanete non lo e’. Nessuno lo nega.

    Ottimo.

    Ma tra il dire che e’ leggermente inferiore a H264 al dire che e’ totalmente inutile per un uso sul web ce’ ne passa di acqua sotto i ponti.

    Infatti questo l’hai detto TU, non io.

    Poi che non venga usato come codec sui blu-ray ma chi se ne frega sinceramente. Stiamo parlando del web, di youtube, di dailymotion della miriade di siti che usano user generated ocntent. E per questi, l’uso di codec royalty e patent free e’ piu’ importante che una leggerissima perdita di qualita’.

    Leggerissima no, ma per il resto concordo, a parte la questione sui brevetti che, a mio avviso, rimane aperta.

    Poi ci saranno alcuni siti tipo Hulu etc… che useranno H264 se lo ritengono necessario. Ma la scelta di avere un codec royalty a patent free per tutti gli altri e’ di fondamentale importanza per l’ecosistema del web.

    Lo è se, a queste precise condizioni, il codec sia “decente”.

    Finisco col dire che il concetti di compressione avra’ sempre minor importanza andando avanti nel tempo. Vuoi perche’ l’infrastruttra di rete verra’ aggiornata, vuoi perche’ la banda a disposizione aumentera’ per tutti. Quindi quanto vuoi scommettere che tra 5-10 anni a nessun freghera’ un fico secco che VP8 non usi B-Frames perche’ tanto di banda per lo streaming ce ne sara’ a sufficienza per garantire un ottima qualita’ ?

    Vuoi scommettere che col continuo aumento di risoluzione video (in Giappone DA ANNI stanno sperimentando con l’UltraHD), di refresh rate, l’introduzione del 3D (già solo questo raddoppia i requisiti), e chissà cos’altro aggiungeranno (più di 16 milioni di colore?), ci sarà sempre la ricerca di codec video qualitativamente superiori?

  • # 17
    goldorak
     scrive: 

    @ Cesare di Mauro :

    Rispondo su gli ultimi due punti. Cos’e’ un codec decente secondo te ? Un codec che dev’essere migliore di x264 ? Se si, allora tutti gli encoders commerciali di H264 andrebbero buttati nella pattumiera essendo palesemente inferiori a x264. E le aziende non dovrebbero usarli. Ovviamente questo non succede quindi come la metti ? Hai dato un occhiata al encoder H264 della Apple ? E un obbrobbio ad essere sinceri. Produce video che sono largammente inferiori a quelli encodati con x264.
    Che dici, l’encoder H264 di Apple non e’ decente ?

    VP8 e’ un codec decente, ma non a livello di eccellenza di x264.
    Questo non lo rende inutile ai fini del web.

    Sull’ultimo punto che hai citato. Dovresti sapere benissimo che il ritmo di progresso tecnologico nel campo video e’ dettato largamente dai broadcasters. E le scelte che si fanno hanno impatti generazionali, si stimano in decenni. Ancora siamo agli albori dei broaddcast in 1080p, anzi molti trasmettono in 720p. Lo standard 1080p restera’ fissato per decenni, non pensare che in 10 anni si cambi tutto. Questo non esclude che nei laboratori di ricerca della RAI, della BBC, della NHK etc… si sperimentino trasmissioni con risoluzioni elvatissime. Ma sono laboratori di ricerca eh, i risultati semmai venissero aabbracciati dall’industria verrebbe fatto almeno tra qualche decennio. Checche’ ne pensino i fanboys, il ritmo di sviluppo nel campo video non e’ dettato dal home video.

  • # 18
    Medicina
     scrive: 

    Quelli di Google hanno pubblicato una patch per aggiungere il supporto al formato in FFmpeg (vedi: http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2010-May/088858.html).

  • # 19
    Daniele
     scrive: 

    Evvai subito ad infervorarsi per un paio di appunti critici! Vero Goldrake? :D
    In verità ci sarebbe da chiedersi perché Google abbia rifiutato le patch che i programmatori di X264 avevano sottoposto. Io sono propenso alla teoria che ci sia una certa urgenza di effettuare lo switch su youtube, forse la corsa all’h264 non garbava Google per via di certi rumors che ho sentito riguardo alle royalties. Da questo il rifiuto di mettere mani al codec perché ne avrebbe tardato la diffusione.
    Per l’utente linux che deve sbattersi perché i codec proprietari come l’MP3 non sono inclusi nella distribuzione è una grande vittoria. Libertà.

  • # 20
    goldorak
     scrive: 

    @ Daniele ha scritto : “Evvai subito ad infervorarsi per un paio di appunti critici! Vero Goldrake? :D”

    Ce modo e modo di criticare. Criticare sputando FUD non serve alcuna critica costruttiva. E forse non l’hai notato ma io non ho alcun problema ad ammettere che VP8 non sia all’altezza di x264.
    E i motivi sono molto chiari, non ci vuole l’intervento dello spirito santo per capirlo eh. ^_^ Questo pero’ non toglie che sia un codec perfettamente adatto al web.

  • # 21
    Smocco
     scrive: 

    A me sembra che stiate un po’ perdendo il nocciolo della notizia. Ovvero la convergenza di grandi nomi sul V8. E’ chiaro l’intento di google e compagnia di promuovere uno standard royalties-free. E a me consumatore questo fa piacere. V8 infrange brevetti? Non so, vedremo come evolve la situazione. Non penso che google avrebbe percorso questa strada se non avesse previsto di passare indenne da questo genere di accuse.

  • # 22
    Rampage
     scrive: 

    Umh…Mah, non sò voi, ma io ho consumi BEN superiori a flash con WebM…vedo decentemente i 360p con consumo del 100% di processore, contro il 50-60 sempre a 360p di flash…oh ragazzi, con FF 3.7 WebM Nighly Build, praticamente, se parte un video, ti puoi scordare di lavorare, con Chromium versione 6 (ultima nightly…) invece, già la questione inizia a farsi meno pesante, ma i consumi si attestano comunque tra il 90 ed il 100%…Ok, ho uno stupido Celeron M440, ma santo cielo…se flash funge meglio, non vedo proprio a cosa serve a questo punto un implementazione del genere…premetto che con H264 e chrome, mi và tutto da dio, fluido e con consumi leggermente più bassi di quelli di flash, mentre con Ogg Theora, principalmente, non noto differenze…Sinceramente, ora come ora, vedo più logica la posizione di MS ad esempio, che non supporterà nativamente WebM ma permetterà di usarlo se il codec è installato nel sistema, continuando a supportare H264…All’utente finale, poco importa se usa WebM o H264 e le licenze che ci stanno dietro…ed alla fin fine, se il codec si distribuisce uniformemente sul web, dubito che MPEG LA, possa fare qualcosa nel 2016 per farsi pagare dal resto del mondo…sbaglio? ò_ò

  • # 23
    Cesare Di Mauro
     scrive: 

    @goldorak:

    Rispondo su gli ultimi due punti. Cos’e’ un codec decente secondo te ? Un codec che dev’essere migliore di x264 ?

    Uno che risulti un buon compromesso dato un certo obiettivo.

    Se si, allora tutti gli encoders commerciali di H264 andrebbero buttati nella pattumiera essendo palesemente inferiori a x264. E le aziende non dovrebbero usarli. Ovviamente questo non succede quindi come la metti ? Hai dato un occhiata al encoder H264 della Apple ? E un obbrobbio ad essere sinceri. Produce video che sono largammente inferiori a quelli encodati con x264.
    Che dici, l’encoder H264 di Apple non e’ decente ?

    http://compression.ru/video/codec_comparison/pdf/msu_mpeg_4_avc_h264_codec_comparison_2009.pdf

    Questo è l’ultimo confronto fra i codec H264 disponibili, e non mi sembra che x264 sia il migliore; lo è, al contrario di quel che dici, uno commerciale…

    In ogni caso io parlo di standard, e tu ricadi nelle implementazioni, facendo cherry picking e pretendendo di estenderlo alla globalità. Non mi sembra un comportamento corretto.

    La realtà è questa:

    “x264, slowest mode, High Profile: 29.76103db (~28% better than VP8)
    VP8, slowest mode: 28.37708db (~8.5% better than x264 baseline)
    x264, slowest mode, Baseline Profile: 27.95594db”

    prendendo i dati dal link che hai fornito prima. E si commenta da sé…

    VP8 e’ un codec decente, ma non a livello di eccellenza di x264.
    Questo non lo rende inutile ai fini del web.

    Ma nemmeno la miglior soluzione.

    Inoltre l’implementazione attuale è scarsa, ma dovresti saperlo avendo letto il link che hai passato prima, e da cui emerge roba come questa:

    gmaxwell: It survives it with a patch that causes artifacts because their encoder doesn’t clamp MVs properly.
    ::cries::
    So they reverted my decoder patch, instead of fixing the encoder.
    “but we have many files encoded with this!”
    so great.. single implementation and it depends on its own bugs.

    This is just like Internet Explorer 6 all over again — bugs in the software become part of the “spec”!”

    C’era un bug grossolano, è stata fornita una patch per risolverlo, ma è stata rigettata perché ormai hanno usato il codec con quel bug.

    Non è così che si definiscono gli standard. Uno standard viene definito da un draft, a cui le implementazioni devono sottostare (e come dovresti ben sapere), e non il viceversa.

    Tra l’altro VP8 non solo non è uno standard ufficiale, ma nemmeno uno standard di fatto.

    Singolare che lo si voglia imporre per il web, che è ratificato da un ente, il W3C, che… rilascia standard ufficiali.

    Sull’ultimo punto che hai citato. Dovresti sapere benissimo che il ritmo di progresso tecnologico nel campo video e’ dettato largamente dai broadcasters. E le scelte che si fanno hanno impatti generazionali, si stimano in decenni. Ancora siamo agli albori dei broaddcast in 1080p, anzi molti trasmettono in 720p. Lo standard 1080p restera’ fissato per decenni, non pensare che in 10 anni si cambi tutto. Questo non esclude che nei laboratori di ricerca della RAI, della BBC, della NHK etc… si sperimentino trasmissioni con risoluzioni elvatissime. Ma sono laboratori di ricerca eh, i risultati semmai venissero aabbracciati dall’industria verrebbe fatto almeno tra qualche decennio. Checche’ ne pensino i fanboys, il ritmo di sviluppo nel campo video non e’ dettato dal home video.

    Dovresti sapere che per l’alta definizione le TV hanno adottato l’H264… e non il VP8.

    E non credo che lo utilizzeranno né l’UltraHD né per il suo successore, per i motivi che ho esposto prima (qualità nettamente inferiore, e maggior uso di risorse sia nella codifica che nella decodifica).

    @Daniele: la patch è stata rifiutata semplicemente perché avevano già codificato una montagna di video, e non volevano ripetere l’operazione.

    Il che non mi sembra assolutamente corretto: i bug si correggono, e NON devono assolutamente diventare parte dello standard.

    Altrimenti, come giustamente faceva notare lo sviluppatore di x264, finisce come IE6 che è rimasto legato mani e piedi ai bug del suo renderer HTML (in quanto componente OCX utilizzato non solo da IE6, ma da altri software).

    Solo che in questo caso immagino che non troverò nessuno che sarebbe disposto ad appoggiare la scelta di Microsoft.

    La coerenza è un concetto relativo, e i fanatici sono come le banderuole: a seconda di come gira il vento si muovono anche loro…

    @goldorak:

    Criticare sputando FUD non serve alcuna critica costruttiva.

    In questo caso potresti essere più chiaro? Chi ha spalato FUD? E come?

    Questo pero’ non toglie che sia un codec perfettamente adatto al web.

    Qui hai usato una parola di troppo: “perfettamente”.

    Proprio perfetto non è, anche perché si trascina un grossolano bug che Google non ha voluto risolvere.

    E poi, come dicevo, è qualitativamente più scarso, richiede molte più risorse (specialmente in fase di codifica; a quanto pare il codice è stato scritto coi piedi), e non c’è alcuna garanzia che non sia coperto da brevetti.

    Questo non è FUD, ma FATTI CONCRETI.

    @Rampage:

    All’utente finale, poco importa se usa WebM o H264 e le licenze che ci stanno dietro…ed alla fin fine, se il codec si distribuisce uniformemente sul web, dubito che MPEG LA, possa fare qualcosa nel 2016 per farsi pagare dal resto del mondo…sbaglio? ò_ò

    Sembra che per 5 anni non farà pagare licenze, ma dopo potrà benissimo farlo.

  • # 24
    Rampage
     scrive: 

    Beh, mi rendo conto che possa benissimo decidere di farle pagare successivamente, ma come dicevo, se fino al 2016 potranno usarlo tutti, senza problemi di sorta, come poi, pretenderà farsi pagare licenze dal resto del mondo? Una volta che un codec del genere diventa standard e viene utilizzato in tutto il web, credo proprio che non possa riuscire nel suo intento…ora, mi rendo conto del fatto che Google abbia opportunamente preferito per VP8, ma a questo punto, se VP8 non mi garantisce prestazioni sufficienti, su dispositivi dual core (eh si, ho provato anche su un dual core…non recentissimo, un Athlon 64 x2 Dual Core 4200+ a 360p sta a 60% circa, invece a 720p sta a 95% circa ed il video ogni tanto, scatta…ora non so se sia colpa dell’implementazione acerba che si ha nei 3 browser che dispongono di questo tipo di decodifica…ma comunque, i consumi sono alti oltre ogni termine di usabilità…specie su pc poco recenti…e la qualità, sinceramente, non mi fa urlare al miracolo se non per il 360p…ottima la sua qualità rispetto alla controparte in flash, ma i consumi sono assurdi…

  • # 25
    Flare
     scrive: 

    Concordo con chi dice che la notizia è come abbia creato un generalizzato consenso.

    Ho provato WebM su Youtube con la build di Opera (per Ubuntu), guardando dei video a caso e in effetti Flash utilizza meno CPU con gli stessi video (30% vs 40% circa su una vecchia baracca), però ho notato un abisso di differenza in qualità: lasciando le impostazioni predefinite, WebM ha la qualità da 720p anche se indica 360p. Forse è a 720p lo stesso? Allora provando a 720p Flash + H.264, con una qualità che ad occhio pare effettivamente molto simile, pressoché identica, l’utilizzo della mia CPU oscilla (è un po’ meno stabile) fra 55% e 60% vs 40% di WebM. Andrebbe chiarita meglio questa faccenda, per fare dei confronti giusti; non vorrei che si confrontasse l’utilizzo della CPU con Flash+h264 a 360p vs WebM a 720.

Scrivi un commento!

Aggiungi il commento, oppure trackback dal tuo sito.

I commenti inseriti dai lettori di AppuntiDigitali non sono oggetto di moderazione preventiva, ma solo di eventuale filtro antispam. Qualora si ravvisi un contenuto non consono (offensivo o diffamatorio) si prega di contattare l'amministrazione di Appunti Digitali all'indirizzo info@appuntidigitali.it, specificando quale sia il commento in oggetto.