Link alla notizia: http://www.hwfiles.it/news/microsoft-promette-un-plug-in-per-h264-in-chrome_35385.html

A redmond verrà sviluppato un plug in dedicato a Google Chrome e in grado di garantire il supporto a H.264

Click sul link per visualizzare la notizia.

"Microsoft con questa mossa conferma di non credere in WebM"

Microsoft, ricorda ai suoi utenti di essere la comproprietaria di MPEG-LA. All your base are belong to us.

....
A redmond verrà sviluppato un plug in dedicato a Google Chrome e in grado di garantire il supporto a H.264 ....


ma anche no ...c'è già :
http://www.interoperabilitybridges.com/wmp-extension-for-chrome

Se i servizi google non supporteranno H264 allora semplicemente tutti si adegueranno.
Youtube è leader e decide i giochi.

Se Google non vuole supportare alcune cose, arriva Microsoft che li aggira e sviluppa per la concorrenza! :D

E poi dicono che Microsoft è malvagia.

"Microsoft con questa mossa conferma di non credere in WebM"

Microsoft, ricorda ai suoi utenti di essere la comproprietaria di MPEG-LA. All your base are belong to us.

L'hai detto fratello. Tira l'acqua al suo mulino.
Questa invadenza di microsoft nei browser altrui ormai è arcinota, basta guardare la miriade di plugin microsoft installati su firefox.

Se Google non vuole supportare alcune cose, arriva Microsoft che li aggira e sviluppa per la concorrenza! :D

E poi dicono che Microsoft è malvagia.

Hemm ti è forse sfuggito il primo commento:

"Microsoft con questa mossa conferma di non credere in WebM"

Microsoft, ricorda ai suoi utenti di essere la comproprietaria di MPEG-LA. All your base are belong to us.

non è che google ci guadagna a spingere Ogg theora,webM & vp8, sono tutte tecnologie opensource di cui anche M$ potrebbe godere in modo gratuito, come tutti gli altri d'altronde. invece no, dobbiamo prostrarci a 90 e pagare royalty su royalty (che non pagherai per averlo nel browser, ma per avere la decodifica in hardware su una handycam...si, sull'ipad pure, sul cellulare pure

quindi M$ continua ad infinocchiare facendoci credere che la roba sua è gratis, come le licenze oem sui pc....

Non so se hai notato l'elevata qualità dei formati promossi da Google, che bada solo allo spazio occupato nei suoi hard disk e non alla qualità dell'immagine.

Questo formato presenta ad oggi validi decoder hardware, supporto praticamente totale e una qualità notevolmente superiore.

a

Link alla notizia: http://www.hwfiles.it/news/microsoft-promette-un-plug-in-per-h264-in-chrome_35385.html

A redmond verrà sviluppato un plug in dedicato a Google Chrome e in grado di garantire il supporto a H.264

Click sul link per visualizzare la notizia.

L'articolo scritto sopra giustamente lancia una notizia e non specifica nel dettaglio la situazione, a mio giudizio esclusivamente personale, la riassume semplificandola molto, per cui a chi vuole chiarirsi le idee sulla situazione e anche sulla posizione di Microsoft consiglio di leggere il post specifico ufficiale sull'argomento:
http://blogs.msdn.com/b/ie/archive/2011/02/02/html5-and-web-video-questions-for-the-industry-from-the-community.aspx

anche l'articolo in inglese in link da quello in Italiano sopra http://arstechnica.com/microsoft/news/2011/02/microsoft-offers-h264-plugin-for-chrome-queries-google-on-webm.ars chiarisce meglio la situazione ed i diversi punti di vista.

Il plugin H264 per chrome è già disponibile come fanno notare in altri commenti e limiti e particolarità sono descritte nella pagina di download:
http://www.interoperabilitybridges.com/wmp-extension-for-chrome

Aggiungo alcuni punti secondo me importanti per chiarire la situazione, provando a riassumere i nodi principali:

- Microsoft non fa una scelta di campo sul codec per il Tag Video e si assicura che in IE9 si possa supportare codec differenti

-Con IE9 viene preinstallato H264 ma il browser consente anche l'utilizzo di webM se l'utente decide di installare il codec.

-Microsoft collabora ampiamente con Google per far funzionare correttamente il codec webM su Windows

-in molti hanno sollevato legittimi interrogativi circa la responsabilità, e i rischi su eventuali possibili brevetti pendenti su webM, e il supporto per WebM e i sostenitori di WebM non hanno risposto su questo punto in modo chiaro

-Chi è responsabile per il rischio presente per i consumatori, aziende e sviluppatori fino a quando eventualmente l'ordinamento giuridico non risolve i problemi di proprietà intellettuale ?

- Quando e soprattutto come si darà spazio per la comunità e gli enti dei Web Standards di accedere a webM e di proporre modifiche evoluzioni ? come si potranno proporre modifiche ed evoluzioni e chi le guiderà realmente ? Ad oggi non si ha nessuna notizia su questo, il codice non è realmente pubblico e non si ha nessun piano su come verrà fatto evolvere e da chi e sarebbe opportuno che fosse guidato da un ente di standardizzazione l'evoluzione del formato. Non si hanno notizie su questo al momento ... dire che una cosa è open non significa molto in termini poi reali

- open non significa standard

- Qual è il piano per il ripristino della coerenza tra i dispositivi, i servizi Web, e il PC.

-ad oggi H264 è uno standard abbracciato dall'intera industra dell'intrattenimento e presenta ad oggi validi decoder hardware nelle GPU e nei principali box e televisori sul mercato, ha praticamente un supporto totale e una qualità notevolmente superiore, per cui togliere il supporto dai browser sembra proprio strumentale, al limite la cosa più sensata dal mio punto di vista è quella di supportare entrambi i formati, e chiarire i problemi di brevetti e il percorso di evoluzione futura di webM. Ed infatti MS in IE9 permette di usare anche webM ma senza preinstallarlo, lasciando eventualmente all'utente la possibilità di farlo.


Per contribuire a farsi un idea è anche interessante dal mio punto di vista anche questo post sull'argomento :
http://antimatter15.com/wp/2011/01/the-ambiguity-of-open-and-vp8-vs-h-264/

La mia opinione personale è che la cosa migliore è quella eventualmente di supportarli entrambi, per poterli preinstallare entrambi vanno però chiariti gli eventuali problemi di brevetti citati negli articoli e anche come webM evolverà nel futuro .

-in molti hanno sollevato legittimi interrogativi circa la responsabilità, e i rischi su eventuali brevetti, e il supporto per WebM e i sostenitori di WebM non hanno risposto su questo punto in modo chiaro

Google ha studiato la questione e dice che non ci sono punti sostenibili per MPEG-LA su cui appellarsi su webm.
MPEG-LA non si è ancora appellata su nulla.
Diversi produttori hardware hanno mostrato le loro implementazioni su SoC.


-Chi è responsabile per il rischio presente per i consumatori, aziende e sviluppatori fino a quando eventualmente l'ordinamento giuridico non risolve i problemi di proprietà intellettuale ?

FUD. Presupponi già che problemi di ordinamento giuridico esistano.


- Quando e soprattutto come Google darà spazio per la comunità Web Standards di accedere a webM e di proporre modifiche evoluzioni ? come si potranno proporre modifiche ed evoluzioni e chi le guiderà realmente ? Ad oggi non si ha nessuna notizia su questo, il codice non è realmente pubblico e non si ha nessun piano su come verrà fatto evolvere e da chi.

FUD massimo. Non mi pare che h264 faccia parte di alcun "web standard", visto che il w3c non specifica alcun web standard da questo punto di vista. Piuttosto si indica che il web standard debba essere royalty free, e h264 non lo è.
Il codice "non veramente pubblico" di cui parli è tutto disponibile su http://www.webmproject.org/ ed è già stato introdotto nel progetto ffmpeg, sia in forma di encoder che di decoder, con ottimizzazioni ad-hoc, oltre alle implementazioni hardware dei SoC citati in precedenza.

Google ha studiato la questione e dice che non ci sono punti sostenibili per MPEG-LA su cui appellarsi su webm.
MPEG-LA non si è ancora appellata su nulla.
Diversi produttori hardware hanno mostrato le loro implementazioni su SoC.



FUD. Presupponi già che problemi di ordinamento giuridico esistano.



FUD massimo. Non mi pare che h264 faccia parte di alcun "web standard", visto che il w3c non specifica alcun web standard da questo punto di vista. Piuttosto si indica che il web standard debba essere royalty free, e h264 non lo è.
Il codice "non veramente pubblico" di cui parli è tutto disponibile su http://www.webmproject.org/ ed è già stato introdotto nel progetto ffmpeg, sia in forma di encoder che di decoder, con ottimizzazioni ad-hoc, oltre alle implementazioni hardware dei SoC citati in precedenza.


Non voglio fare polemiche, ribadisco che dal mio punto di vista implementare entrambi ed anche altri formati e rimanere agnostici su questo è la posizione migliore ed è anche la posizione di Microsoft .

Le questioni di brevetti non sono chiarite :

Looking at the notes from a recent “WebM Summit” (https://docs.google.com/viewer?a=v&pid=explorer&chrome=true&srcid=0B6g5FABKcB8DODQ2NjYxYzgtYjJjMi00OGE5LWI0NTUtMDgzNzFhODhhNzY1&hl=en&authkey=CM7w28sE, slide 12), Google says that there are "No known royalty requirements." That’s quite different from no royalty requirements, and the former might be a more accurate description of the IP situation.

Mostrare delle implementazioni non vuol dire che ci saranno mentre oggi H264 ha miliardi di file già creati anche da Google stessa e ci sono decine se non centinaia di device con codec h264.
Ripeto qui la guerra non è tra i due codec e per me non c'è nessuna guerra, ribadisco che la cosa migliore è supportarli entrambi che è la cosa migliore anche per gli utenti finali e in generale per il mercato.
La critica eventualmente sta nell'aver eliminato il supporto per H264 ..non a webM che infatti si supporterà . Va però secondo me , sottomesso ad un ente di standardizzazione e chiarito come evolverà, io non mi riferifo al codece sorgente in se ma a come verrà guidata l'evolozione . H264 è uno standard MPEG http://en.wikipedia.org/wiki/Moving_Picture_Experts_Group. Standard e open e royalty sono cose diverse come secondo me è descritto bene nel post che citavo prima http://antimatter15.com/wp/2011/01/the-ambiguity-of-open-and-vp8-vs-h-264/

Sono in tanti ad aver sollevato queste questioni .

Si giustifica la rimozione del supporto di H264 perchè si vuole promuovere l'open ma in realtà ad oggi webM ha i problemi di sopra ed è completamente guidato da una sola azienda http://who.is/whois/webmproject.org/ e si continua ad utilizzare H264 anche su siti di Google e al momento il supporto di H264 in Android continua ed anche nalla Google Tv ....... credo che al limite mantenere entrambi sarebbe stata la scelta migliore, così come proporre webM in un ente di standarizzazione.

Bella questa vignetta http://www.geekculture.com/joyoftech/joyarchives/1491.html .

Il fatto che si rimuova in questo modo il supporto di quello che è uno standard non è un bel segnale e inoltre cosa garantisce dal fatto che la stessa cosa non possa essre fatta in qualunque momento per altro ? Anche dare stabilità e garanzia del supporto di una feature nel browser per un tempo predicibile e certo credo sia importante in particolare per chi ha investito su quella specifica feature ed importante anche per le applicazioni critiche che vengono in molti casi basate su HTML e sul Web e penso che ci vorrebbero dei commitment più chiari su cosa si intende supportare e per quanto tempo.

Questo vale per tutte le specifiche HTML, CSS, etc pensate a quello che è successo con i Websocket per firefox http://hacks.mozilla.org/2010/12/websockets-disabled-in-firefox-4/ e per gli altri browser che lo implementano o che sta succedendo con il database per il browser con la specifica Web Sql Database http://dev.w3.org/html5/webdatabase/, implementata in diversi browser in passato ed ora ufficialmente nella specifica potete leggere nello status "Beware. This specification is no longer in active maintenance and the WebApplications Working Group does not intend to maintain it further" e si va verso IndexedDB che deve comunque ancora essere completata come specifica http://news.cnet.com/8301-30685_3-20023351-264.html http://hacks.mozilla.org/2010/06/beyond-html5-database-apis-and-the-road-to-indexeddb/ Come scrivevo anche in un precedente commento, credo che sul discorso degli standard non ci sia solo la necessità del fallback o dei supporti differenti, ma anche di distinguere cosa è maturo per una implementazione reale e cosa no e commitment chiari su cosa un implementatore di browser ha intenzione di supportare e per quanto tempo garantisce il supporto a garanzia di utilizzatori e sviluppatori. L'approccio di inserire nei browser le specifiche non stabilio non mature , di togliere supporto a feature utilizzate e standard stabili o meno, con breve preavviso, di non dichiarare chiaramente cosa si vuole realmente supportare e per quanto tempo al minimo, non credo faccia il bene del Web e a chi lo utilizza in particolare per applicazioni aziendali critiche. Microsoft con IE9 ad esempio, ha deciso di mantenere ben separate le specifiche stabili ed implementate nel browser e che impattano le applicazioni e gli utenti, da quelle che invece sono ancora immature o che subiranno modifiche significative e che quindi possono essere provate sperimentalmente per contribuire alle specifiche usando gli HTML5 Labs http://blogs.msdn.com/b/italy/archive/2010/12/21/htlm5-labs-sviluppare-i-siti-di-oggi-e-sperimentare-da-subito-le-specifiche-html-di-domani.aspx ad esempio qui trovate maggiori info per provare IndexedDB con IE9 in HTML5 Labs http://blogs.msdn.com/b/giuseppeguerrasio/archive/2011/01/21/html5-labs-un-database-per-il-browser-con-indexed-db.aspx. Inoltre il ciclo di supporto di ogni prodotto è chiaramente indicato anche in termini di tempi minimi di supporto..

Ribadisco comunque che dal mio punto di vista implementare entrambi ed anche altri formati e rimanere agnostici su questo è la posizione migliore ed è anche la posizione di Microsoft .

Quello che vedo di positivo e che microsoft si adatta ad altri browser. Ha sempre cercato di imporre i propri formati ed adesso si deve preoccupare di creare un plugin per far fruire il proprio formato.

Mi sembra quasi una svolta.

Magari verrà anche il giorno che implementeranno un plugin per vedere silverlight su firefox, magari...

Quello che vedo di positivo e che microsoft si adatta ad altri browser. Ha sempre cercato di imporre i propri formati ed adesso si deve preoccupare di creare un plugin per far fruire il proprio formato.

Mi sembra quasi una svolta.

Magari verrà anche il giorno che implementeranno un plugin per vedere silverlight su firefox, magari...

Carlo, Silverlight funziona su Firefox fin dalla prima versione. Silverlight supporta differenti tipi di codec video tra cui VC-1 e H264. I Browser e i SO supportati da Silverlight li trovi qui http://www.microsoft.com/getsilverlight/Get-Started/Install/Default.aspx facendo click sul link system requirements le domande\risposte più frequenti su Silverlight le trovi qui http://www.microsoft.com/silverlight/faq/

Son in pratica supportati su windows e mac:
Internet Explorer dalla 6 alla 9 attuale
Firefox dalla 3+ alla ultima attuale
Safari dalla 3+ alla ultima attuale
Chrome dalla 4+ alla ultima attuale

per Linux http://www.mono-project.com/Moonlight

Signor Giuseppe Guerrasio, lei è dotato di grande pazienza :)

Nonostante io sia completamente all'oscuro dell'argomento cui trattate, in sostanza sono ignorante, l'esperienza mi insegna a riconoscere quando ci si addentra nella tana del lupo.

Grazie per la sua disponibilità.

Signor Giuseppe Guerrasio, lei è dotato di grande pazienza :)

Nonostante io sia completamente all'oscuro dell'argomento cui trattate, in sostanza sono ignorante, l'esperienza mi insegna a riconoscere quando ci si addentra nella tana del lupo.

Grazie per la sua disponibilità.

Grazie per il complimento sulla pazienza !

Già che ci siamo:
Una volta era Flash che presentava un ostacolo per utilizzare i browser a 64 bit. Volete che il prossimo ostacolo sia Silverlight? :D

Già che ci siamo:
Una volta era Flash che presentava un ostacolo per utilizzare i browser a 64 bit. Volete che il prossimo ostacolo sia Silverlight? :D

hai proprio ragione arrows!

Già che ci siamo:
Una volta era Flash che presentava un ostacolo per utilizzare i browser a 64 bit. Volete che il prossimo ostacolo sia Silverlight?

hai proprio ragione arrows!

Credo che i plugin e il Web Standard sono due cose diverse entrambe utili. I plugin permettono di fare quello che è possibile con il browser perchè possono essere evoluti più rapidamente avendo un runtime indipendende e credo che sarà sempre così. Silverlight è Flash credo che abbiano anche molti meriti e continuaranno ad averli. Non capisco sinceramente quale sia la fondamentale differenza che vedete ad oggi tra un browser a 32bit ed uno a 64bit..... per chi lo utilizza sinceramente non capisco che differenza si produce, ma magari mi sbaglio ..
Comunque Silverlight 5 supporta anche i 64 bit

Egr sig. Guerrasio bisognerebbe anche aggiungere che lei è un po' di parte

MSDN Blogs > Giuseppe Guerrasio > About Giuseppe Guerrasio
About

Lavoro nella divisione Developers & Platform di Microsoft come Architect Evangelist e mi occupo di aiutare clienti e partner nell’adozione delle tecnologie Microsoft nell’area dello sviluppo applicativo con particolare riferimento ai Solution Architect delle grandi aziende Italiane ed i principali Web Site Italiani.

Egr sig. Guerrasio bisognerebbe anche aggiungere che lei è un po' di parte

ahahahaahahahahha :D

Egr sig. Guerrasio bisognerebbe anche aggiungere che lei è un po' di parteMa va? Noooo... Mi crolla un mito...

E pensare che credevo che HWUpgrade avesse aperto l'opportunità di chiedere a uno del team di sviluppo di IE9, senza che questo lavorasse per Microsoft... :asd:

Egr sig. Guerrasio bisognerebbe anche aggiungere che lei è un po' di parte

Salve,
che lavoro per Microsoft non è un mistero direi ..... in molti post l'ho anche scritto e anche su alcuni articoli di HWUPGRADE è scritto chiaramente.