'Google geeft VP8-codec volgende maand opensource-licentie'
Google maakt volgende maand tijdens de I/O-bijeenkomst bekend dat het de VP8-codec van het voormalige On2 met een opensource-licentie vrij beschikbaar zal stellen, zo meldt de site NewTeeVee op basis van anonieme bronnen.
De zoekgigant zou verder op de I/O-bijeenkomst op 19 mei in San Francisco bekendmaken dat zijn eigen Chrome-browser de VP8-codec zal ondersteunen, zo schrijft NewTeeVee. Bovendien zou ondersteuning voor VP8 in de html 5-implementatie van Mozilla's Firefox snel volgen.
Google verkreeg de VP8-codec na de overname van On2 in 2009. Met de stijgende populariteit van html 5 als mogelijk alternatief voor het propriëtaire Flash, werd de roep om een licentievrije en hoogwaardige videocodec steeds luider. Zo riep de Free Software Foundation Google in een open brief onlangs nog op om VP8 opensource te maken.
Als Google VP8 inderdaad een opensource-licentie meegeeft, dan kan deze videocodec gaan dienen als een alternatief voor de kwalitatief minder goede, maar licentievrije Theora-codec en tevens een concurrent worden voor h.264. Voor h.264, een codec die vooral voor hd-materiaal populair is, moeten in bepaalde gevallen licentiekosten aan de MPEG-LA worden betaald.
Ondanks de geruchten over het vrijgeven van de VP8-codec is het nog de vraag of deze zal aanslaan, mede omdat niet duidelijk is of bedrijven als Microsoft en Apple ondersteuning voor de nieuwe videocodec in toekomstige versies van Internet Explorer en Safari zullen opnemen. Sommige analisten wijzen er echter op dat Google met YouTube een troef achter de hand heeft.
Reacties (76)
Geweldig, eindelijk een vrije codec die met h264 kan concurreren. Deze codec kan op de lange termijn ook voor hd-materiaal en andere toepassingen erg populair worden, als het idd een vrije codec is en kleinere bestanden oplevert dan h264. Ik ben benieuwd naar de eerste onafhankelijke vergelijkingen tussen Theora, VP8 en h264.
Google kan idd h264 op Youtube vervangen door VP8. Dan volgen de andere browsermakers snel genoeg, als ze geen gebruikers aan Chrome of Firefox willen verliezen. Opera zal ook wel meegaan. MS wil met IE9 laten zien dat ze html5 nu echt serieus nemen; hopelijk zetten ze daarom alles op alles om Youtube (en dus deze codec) werkend te hebben.
Google kan idd h264 op Youtube vervangen door VP8. Dan volgen de andere browsermakers snel genoeg, als ze geen gebruikers aan Chrome of Firefox willen verliezen. Opera zal ook wel meegaan. MS wil met IE9 laten zien dat ze html5 nu echt serieus nemen; hopelijk zetten ze daarom alles op alles om Youtube (en dus deze codec) werkend te hebben.
[Reactie gewijzigd door JanDM op dinsdag 13 april 2010 10:38]
Zeer goed nieuws!
Ik ben benieuwd of de kwaliteit en mogelijkheden net zo goed zijn als x.264.
Als het werkelijk opensource wordt zal er nog verbetering plaatsvinden uiteraard.
Ik hoop alleen dat er niet te veel wildgroei ontstaat.
Misschien is het handig om het filter voortaan gewoon in het media bestand op te nemen.
Ik ben benieuwd of de kwaliteit en mogelijkheden net zo goed zijn als x.264.
Als het werkelijk opensource wordt zal er nog verbetering plaatsvinden uiteraard.
Ik hoop alleen dat er niet te veel wildgroei ontstaat.
Misschien is het handig om het filter voortaan gewoon in het media bestand op te nemen.
niet alleen om yutube te hebben maar gewoon om het <video> element eindelijk op alle browsers werkend te krijgen. als dit een vrije codec wordt zijn we strax eindelijk af van al die ranzige flash / silverligt etc hacks op 'video-sites' etc. en heb je dergelijke troep dus alleen nog nodig als er drm in het spel is (maar dan haak ik zowiso al af - dus doe mij dit maar).
Mag je mij vertellen hoe je DRM in een open-source codec wil implementeren, en voorkomen dat iemand gewoon een vlaggetje in de broncode omzeilt waardoor de inhoud ontsleuteld wordt.niet alleen om yutube te hebben maar gewoon om het <video> element eindelijk op alle browsers werkend te krijgen. als dit een vrije codec wordt zijn we strax eindelijk af van al die ranzige flash / silverligt etc hacks op 'video-sites' etc. en heb je dergelijke troep dus alleen nog nodig als er drm in het spel is (maar dan haak ik zowiso al af - dus doe mij dit maar).
Lezen is ook een kunst, hij zegt net dat we dan enkel nog met Flash etc. alleen nog nodig hebt als er DRM bij komt kijken.
hij zegt niets over DRM bij VP8.
hij zegt niets over DRM bij VP8.
[Reactie gewijzigd door t-town op dinsdag 13 april 2010 11:44]
DRM / Encryptie kun je niet omzeilen door een vlaggetje om te zetten. Je zult eerst drm sleutels moeten hebben.
Overigens kun je zowel opensource als binary executables aanpassen om ze voor rippen te gebruiken.
Als je de timer van een mediaspeler kunt manipuleren en een pointer naar de rasterbuffer / audiobuffer kunt verkrijgen (d.m.v. dll injection bijv. ) dan kun je DRM altijd omzeilen.
De pointer naar de rasterbuffer is gemakkelijk te verkrijgen door bepaalde systeem aanroepen op te vangen.
Overigens kun je zowel opensource als binary executables aanpassen om ze voor rippen te gebruiken.
Als je de timer van een mediaspeler kunt manipuleren en een pointer naar de rasterbuffer / audiobuffer kunt verkrijgen (d.m.v. dll injection bijv. ) dan kun je DRM altijd omzeilen.
De pointer naar de rasterbuffer is gemakkelijk te verkrijgen door bepaalde systeem aanroepen op te vangen.
[Reactie gewijzigd door E_E_F op dinsdag 13 april 2010 11:52]
Nouja, hoe vaak wordt beveiliging in een open-source library omzeild? (Denk SSH, Linux / Unix die bankmainframes draaien). Denk dat dat ook gewoon te doen is met DRM, mits goed geimplementeerd. Mits je DRM wilt, tenminste, als contentaanbieder.[...]
Mag je mij vertellen hoe je DRM in een open-source codec wil implementeren, en voorkomen dat iemand gewoon een vlaggetje in de broncode omzeilt waardoor de inhoud ontsleuteld wordt.
Als de content door de ontvanger te lezen is, heeft hij ook de sleutel. Bij SSH kun je de verbinding dus niet omzeilen, omdat de ontvanger en zender je de sleutel niet geven. Bij DRM krijgt de ontvanger ook de sleutel (bv. ingebouwd in de dvd of blue ray speler), maar mag hij deze alleen gebruiken om de content zelf te zien.
Als je DRM in open source gaat stoppen, moet je de sleutel ook erbij leveren. Door de code aan te passen kun je dan andere dingen gaan doen dan alleen naar de content te kijken.
DRM en (volledig) open source gaat dus nooit tegelijkertijd.
Als je DRM in open source gaat stoppen, moet je de sleutel ook erbij leveren. Door de code aan te passen kun je dan andere dingen gaan doen dan alleen naar de content te kijken.
DRM en (volledig) open source gaat dus nooit tegelijkertijd.
DRM is in principe "broken by design", dit volgt al uit jou uitleg. De ontvanger heeft altijd de sleutel om te decrypten. Het is de decrypter die dan een feature wel of niet toe laat, een simple bit. Als jij die decrypter aanpasten zodat die feature altijd op "aan" staat is veel de DRM geen enkel nut meer.
Een goede debugger maakt van elke beveiliging ook gehakt overigens. En dan zijn er nog resultaten uit de literatuur die zeggen dat obfuscation altijd ongedaan gemaakt kan worden. Ik heb geen zin om de referentie op te zoeken, maar het komt er op neer dat alleen mensen die er niets van begrijpen geloven in deze vorm van DRM.
Wat het misschien wel doet is de drempel enigszins verhogen, maar aangezien je maar 1 iemand nodig hebt met een meer dan gemiddelde interesse....
Wat het misschien wel doet is de drempel enigszins verhogen, maar aangezien je maar 1 iemand nodig hebt met een meer dan gemiddelde interesse....
http://blogs.gnome.org/uraeus/2005/12/03/drm-and-gstreamer/DRM en (volledig) open source gaat dus nooit tegelijkertijd.
GStreamer heeft een interface gemaakt, waarmee DRM modules (binary, niet source) gebruikt kunnen worden.
http://lwn.net/Articles/163701/
Still, anybody who can hack on the source can obtain an unencrypted stream from a GStreamer DRM module.
zolang je dus bij de source kan komen, kun je die aanpassen om de content naar disk weg te schrijven (zonder encryptie) in plaats van op het scherm te laten zien. En zelfs als ze GStreamer zodanig gaan dichttimmeren (closed source?), kun je er altijd nog voor kiezen om je linux kernel te hacken, en een nieuwe video driver voor je seagate/maxtor/western digital/... "display" te schrijven.
DRM werkt dus alleen op een volledig closed systeem. Zodra er ook maar iets open is nadat decryptie heeft plaatsgevonden, kun je de content opslaan. (Open kan open source zijn, maar natuurlijk ook reverse engineered software/hardware).
http://lwn.net/Articles/163701/
Still, anybody who can hack on the source can obtain an unencrypted stream from a GStreamer DRM module.
zolang je dus bij de source kan komen, kun je die aanpassen om de content naar disk weg te schrijven (zonder encryptie) in plaats van op het scherm te laten zien. En zelfs als ze GStreamer zodanig gaan dichttimmeren (closed source?), kun je er altijd nog voor kiezen om je linux kernel te hacken, en een nieuwe video driver voor je seagate/maxtor/western digital/... "display" te schrijven.
DRM werkt dus alleen op een volledig closed systeem. Zodra er ook maar iets open is nadat decryptie heeft plaatsgevonden, kun je de content opslaan. (Open kan open source zijn, maar natuurlijk ook reverse engineered software/hardware).
Dit ligt er maar net aan welke license er wordt gekozen. Als VP8 onder GPL wordt vrij gegeven, moeten onder andere Microsoft en Opera een commerciele licentie aanschaffen omdat de broncode van hun browser niet opensource is. Bij LGPL is dit probleem niet aanwezig omdat zij dan gewoon kunnen linken aan de library.
Als VP8 echter onder een BSD license zoals andere geaccepteerde standaarden LZW (compressie) en de BSD TCP/IP protocol stack dan is er geen enkele reden om nog andere codecs te gebruiken.
Nog idealer zou zijn dan de video tag maar als de image tag wordt opgezet. <video codec="vp8" src="movie.fp8" ><novideo><img src="novid.png" /></novideo></video> Op die manier kunnen later vrij gemakkelijk andere codecs worden geïntroduceerd zonder dat het nodig is de HTML specificatie aan te passen.
Voor Silverlight en Flash zal weinig veranderen indien VP8 onder een vrij linkbare licentie wordt vrij gegeven. Zij zullen dan naast mpg, avi, x264 ook VP8 gaan ondersteunen. Beide bieden natuurlijk meer dan alleen maar video..
Zeker als ik zie met hoeveel gemak WPF user interfaces kunnen worden omgezet zal Silverlight niet snel verdwijnen. Daarnaast zal ook DRM nodig blijven. Denk hierbij aan omroepen die alleen een licentie hebben om een programma/serie/sport evenement in Nederland uit te zenden. En dat vind ik persoonlijk een ander soort DRM van degene welke bepalen dat je een video drie keer mag bekijken..
Als VP8 echter onder een BSD license zoals andere geaccepteerde standaarden LZW (compressie) en de BSD TCP/IP protocol stack dan is er geen enkele reden om nog andere codecs te gebruiken.
Nog idealer zou zijn dan de video tag maar als de image tag wordt opgezet. <video codec="vp8" src="movie.fp8" ><novideo><img src="novid.png" /></novideo></video> Op die manier kunnen later vrij gemakkelijk andere codecs worden geïntroduceerd zonder dat het nodig is de HTML specificatie aan te passen.
Voor Silverlight en Flash zal weinig veranderen indien VP8 onder een vrij linkbare licentie wordt vrij gegeven. Zij zullen dan naast mpg, avi, x264 ook VP8 gaan ondersteunen. Beide bieden natuurlijk meer dan alleen maar video..
Zeker als ik zie met hoeveel gemak WPF user interfaces kunnen worden omgezet zal Silverlight niet snel verdwijnen. Daarnaast zal ook DRM nodig blijven. Denk hierbij aan omroepen die alleen een licentie hebben om een programma/serie/sport evenement in Nederland uit te zenden. En dat vind ik persoonlijk een ander soort DRM van degene welke bepalen dat je een video drie keer mag bekijken..
Je kunt gewoon een juiste mimetype meesturen en dan heb je die codec optie helemaal niet nodig.Nog idealer zou zijn dan de video tag maar als de image tag wordt opgezet. <video codec="vp8" src="movie.fp8" ><novideo><img src="novid.png" /></novideo></video> Op die manier kunnen later vrij gemakkelijk andere codecs worden geïntroduceerd zonder dat het nodig is de HTML specificatie aan te passen.
Dat zal er toch iets meer moeten gebeuren dan dat Google een opensource licentie over een codec legt.Opera zal ook wel meegaan. MS wil met IE9 laten zien dat ze html5 nu echt serieus nemen;
Opensource licenties zijn vaak niet compatibel met closed source en zijn dus voor Opera en Microsoft niet acceptabel.
Een vrije technologie licentie op de VP8 codec door Google en het beschikbaar stellen van specificaties door liefst een standaardisatieorgnisatie lijken me eerder noodzakelijk voor brede acceptatie van een dergelijk formaat.
Google zal zeer waarschijnlijk de BSD-licentie gebruiken, net zoals ze voor o.a. Chrome en V8 doen. Dan is de codec prima te gebruiken in IE of Opera.Opensource licenties zijn vaak niet compatibel met closed source en zijn dus voor Opera en Microsoft niet acceptabel.
Het gaat hier op patenten en royalties he, niet zozeer om broncode.
Google hoeft alleen maar officieel de royalties voor altijd op op 0 te zetten (en de voorbeeld implementatie kan onder een BSD-licentie zoals JanDM zegt , of dual-licence).
Over dual-licence gesproken; Dat zou nu de beste move van MPEG-LA zijn voor h.264.
De gebruikelijke prijs voor closed source en hardware implementaties. 0 voor open source implementaties.
Hiermee houden ze VP8 af en zullen ze alleen maar MEER licentie geld binnenslepen omdat h.264 dan de onbetwiste web standaard wordt.
Google hoeft alleen maar officieel de royalties voor altijd op op 0 te zetten (en de voorbeeld implementatie kan onder een BSD-licentie zoals JanDM zegt , of dual-licence).
Over dual-licence gesproken; Dat zou nu de beste move van MPEG-LA zijn voor h.264.
De gebruikelijke prijs voor closed source en hardware implementaties. 0 voor open source implementaties.
Hiermee houden ze VP8 af en zullen ze alleen maar MEER licentie geld binnenslepen omdat h.264 dan de onbetwiste web standaard wordt.
@ hAl:
ik denk dat je de invloed van Google en Youtube op internetgebruikers onderschat. Als youtube overstapt op een andere codec, onstaat er al een redelijke vraag naar de VP8 codec. Wat zullen andere sites doen? De verwachting is dat veel sites toch wel liever met een open source codec werken dan met de propriëtaire codecs van adobe. Temeer daar adobe een eigen agenda heeft, of op bepaalde devices geweerd wordt (iPad). Een open source standaard is veel minder gevoelig voor dergelijke nukken.
De flash plugin moet veelal zelf geïnstalleerd worden. Stel dat bij Chrome en Firefox de pluging al meegeleverd wordt, wat zal microsoft doen met internet explorer en apple met Safari? Alles hangt af van het gebruiksgemak en hoe de gebruiker dit ervaart. Apple volgt meestal een eigen koers, daar is de integratie van de standaard moeilijk te voorspellen. Microsoft daarentegen heeft veel minder keuzevrijheid. Waar apple op een klein segment mikt, mikt microsoft op de grote massa. Dat wil zeggen dat aantallen heel belangrijk zijn voor Microsoft. Het marktaandeel van Internet Explorer staat al een aantal jaren onder druk (hoofdzakelijk van firefox). Een brede acceptatie aan aanbieders' zijde van een opensource codec en ondersteuning door firefox zou betekenen dat microsoft niet veel keuze heeft om dezelfde gebruikerservaring als de concurrentie te bieden.
ik denk dat je de invloed van Google en Youtube op internetgebruikers onderschat. Als youtube overstapt op een andere codec, onstaat er al een redelijke vraag naar de VP8 codec. Wat zullen andere sites doen? De verwachting is dat veel sites toch wel liever met een open source codec werken dan met de propriëtaire codecs van adobe. Temeer daar adobe een eigen agenda heeft, of op bepaalde devices geweerd wordt (iPad). Een open source standaard is veel minder gevoelig voor dergelijke nukken.
De flash plugin moet veelal zelf geïnstalleerd worden. Stel dat bij Chrome en Firefox de pluging al meegeleverd wordt, wat zal microsoft doen met internet explorer en apple met Safari? Alles hangt af van het gebruiksgemak en hoe de gebruiker dit ervaart. Apple volgt meestal een eigen koers, daar is de integratie van de standaard moeilijk te voorspellen. Microsoft daarentegen heeft veel minder keuzevrijheid. Waar apple op een klein segment mikt, mikt microsoft op de grote massa. Dat wil zeggen dat aantallen heel belangrijk zijn voor Microsoft. Het marktaandeel van Internet Explorer staat al een aantal jaren onder druk (hoofdzakelijk van firefox). Een brede acceptatie aan aanbieders' zijde van een opensource codec en ondersteuning door firefox zou betekenen dat microsoft niet veel keuze heeft om dezelfde gebruikerservaring als de concurrentie te bieden.
Daar volg ik je niet helemaal, zijn proprietary licenties dan wel compatibel met closed source browsers? Neen. In se is die boodschap dus irrelevant. Meer nog, open source licenties kunnen een bepaling hebben voor bv gebruik in closed source browsers, onder andere voorwaarden. De kans is groot dat deze voorwaarden (afhankelijk van de gebruikte licentie) nog veel democratischer zijn dan de voorwaarden van closed source codecs... Eigenlijk eerder een pluspunt van het uitbrengen van een open source plugin.Opensource licenties zijn vaak niet compatibel met closed source en zijn dus voor Opera en Microsoft niet acceptabel.
Apple kan echter hetzelfde doen met deze codec als ze met flash hebben gedaan, simpelweg weren van hun platform. Jammer genoeg betekent het appstore idee ook dat alle software goed gekeurd moet worden door Apple.
Dat ie opensource is betekend niet automatisch dat ie ook patent en dus licentie vrij is. Hier in .eu niet zo'n groot probleem, maar voor de wereldwijde adaptatie is meer nodig.eindelijk een vrije codec die met h264 kan concurreren
Volgens On2 hoeft de 'gebruiker' niet aan een patentpool deel te nemen, in tegenstelling tot .h264.
Tevens stelt On2 RTL (transistor ontwerp) beschikbaar aan Intel, MIPS, ARM en TI, dus vermoedelijk zal het binnenkort in de hardware zitten en dan is het patentprobleem hardwarematig opgelost.
Tevens stelt On2 RTL (transistor ontwerp) beschikbaar aan Intel, MIPS, ARM en TI, dus vermoedelijk zal het binnenkort in de hardware zitten en dan is het patentprobleem hardwarematig opgelost.
Als VP8 vrij is gegeven (en dan niet alleen open source maar ook herbruikbaar) dan kunnen Mozilla (Firefox), Opera en anderen deze implementeren. Alles hangt uiteraard af van de voorwaarden waaronder de het herbruikbaar is.
Op h.264 zitten licentiekosten
Theora is minder goede kwaliteit (/meer bandbreedte voor dezelfde kwaliteit)
Maar nu komt Google dus met een 3e alternatief die het beste van beide biedt? Klink te mooi om waar te zijn. Hopen dat de browsers het allemaal gaan ondersteunen dan.
Edit: Hoe zit het met de hardwarebakkers? Voordeel van h.264 is dat veel videokaarten ondersteuning voor hardwarematig decoden hebben. Is dat er ook voor VP8?
Theora is minder goede kwaliteit (/meer bandbreedte voor dezelfde kwaliteit)
Maar nu komt Google dus met een 3e alternatief die het beste van beide biedt? Klink te mooi om waar te zijn. Hopen dat de browsers het allemaal gaan ondersteunen dan.
Edit: Hoe zit het met de hardwarebakkers? Voordeel van h.264 is dat veel videokaarten ondersteuning voor hardwarematig decoden hebben. Is dat er ook voor VP8?
[Reactie gewijzigd door Shadow op dinsdag 13 april 2010 10:17]
Als het open en vrij van rechten wordt denk ik dat Opera en Firefox wel mee zullen gaan. Aangezien MS nog geen duidelijke voorkeur heeft gegeven denk ik dat ook zij het niet zullen betreuren om VP8 te gaan gebruiken, aangezien dat ook voor hun weer licentie kosten scheelt.
Nee, google komt nu met TWEE alternatieven.
Ze hebben eerder algemeld dat ze er aan gaan werken om Theora de lowest common denominator te laten worden. Theora moet dus de basis worden, die altijd werkt, en dan kunnen andere codecs daarboven zitten als de browser ze ondersteunt.
Dit is ZEER goed nieuws en toont maar weer eens aan dat Google een van de coolste bedrijven is.
Deze vrijheid om een codec te hebben zonder patent kuilvallen (gif, mp3 iemand) is een mooi iets voor de toekomst. Houd het web net een beetje opener dan wanneer de MS/Apples van de wereld het voor het zeggen houden.
Ze hebben eerder algemeld dat ze er aan gaan werken om Theora de lowest common denominator te laten worden. Theora moet dus de basis worden, die altijd werkt, en dan kunnen andere codecs daarboven zitten als de browser ze ondersteunt.
Dit is ZEER goed nieuws en toont maar weer eens aan dat Google een van de coolste bedrijven is.
Deze vrijheid om een codec te hebben zonder patent kuilvallen (gif, mp3 iemand) is een mooi iets voor de toekomst. Houd het web net een beetje opener dan wanneer de MS/Apples van de wereld het voor het zeggen houden.
Echter, voor een 'lowest common denominator' heb je iets nodig wat overal ondersteund wordt, met wellicht wat mindere kwaliteit, grotere file size of meer energieverbruik bij afspelen.
Daar Theora niet heel erg wijdverbreid ondersteund is, kan het die rol niet spelen...
Tevens, welke garantie geeft de maker van Theora dat er niet toch een patent geschonden wordt? Bijvoorbeeld van H.264? Of van deze VP8 codec?
Daar Theora niet heel erg wijdverbreid ondersteund is, kan het die rol niet spelen...
Tevens, welke garantie geeft de maker van Theora dat er niet toch een patent geschonden wordt? Bijvoorbeeld van H.264? Of van deze VP8 codec?
MPEG LA geeft ook geen enkele garantie dat h.264 geen patenten van 3den schendt, dus daar is geen verschil / probleem.
Dat is geen goed nieuws want het houdt in dat meerdere versies van je content nodig hebt; Theora dat overal werkt maar een slechtere kwaliteit biedt, en vervolgens VP8 dat niet overal zal werken maar een betere kwaliteit biedt? Dan moet je alles twee keer coderen, twee keer aanbieden, heb je dus ook twee keer de schijfruimte en bandbreedte nodig. Als je al die nadelen overweegt, is die extra kwaliteit die toch niet overal ondersteunt wordt dan de moeite waard?
Het zou beter zijn om één standaard uit te kiezen en die geschikt te maken voor alle apparaten en het liefst in hoge kwaliteit. (VP8 geschikt maken voor mobiele apparaten dus; dit moet niet zo'n heel groot probleem zijn met hulp van de open-source community.)
Het zou beter zijn om één standaard uit te kiezen en die geschikt te maken voor alle apparaten en het liefst in hoge kwaliteit. (VP8 geschikt maken voor mobiele apparaten dus; dit moet niet zo'n heel groot probleem zijn met hulp van de open-source community.)
Google staat nou niet bekend als een bedrijf dat vrekkig met bandbreedte en storage omgaat 
Jouw "probleem" is dus dat voor Google, voor de consument is het alleen maar handig.
(hmm.. kan m'n dreambox dan nog steeds een H264 krijgen?)
Jouw "probleem" is dus dat voor Google, voor de consument is het alleen maar handig.
(hmm.. kan m'n dreambox dan nog steeds een H264 krijgen?)
Dat is maar zeer de vraag, Theora video is gebaseerd op VP3 en nu is er VP8, een opvolger van VP3. Ze zullen grote overeenkomsten hebben vermoedelijk, alleen VP8 is geavanceerder.Dan moet je alles twee keer coderen
Als het niet in de browser komt, dan kan Google het toch ook aanbieden als plugin? Voor veel gebruikers maakt dat toch niks uit, zolang de filmpjes maar zonder problemen afspelen...
Dan zit je als website bouwer weer met het feit dat je rekening moet houden met verschillende formaten. En vooral met video lijkt me dat niet the way to go.
ook nu loop je daar tegen op ik zie dat niet als iets dat je tegenhoud,, Kijk naar YouTube... Je moet toch flash installeren.
Met HTML5 is dat dus verleden tijd (hopen we).
Nee met HTML 6 is het verleden tijd, ja HTML 5 komt er aan waar het mogelijk is flash te vervangen, maar heeft iedereen in 1 klap HTML 5? NEE, dus is flash nog wel een paar jaar nodig, net zoals ik nu me sites ook nog in IE6 en 7 wil laten werken, IE5.5 doe ik niet meer aan, maar 2 jaar terug nog wel 
Je ziet nu er elektrische auto's bestaan toch ook niet van de ene op de andere dag iedereen met z'n ding rijden, dat heeft TIJD nodig En tot die tijd doe ik lekker alles met flash en waar mogelijk met HTML5 maar altijd met terugval mogelijkheden naar flash!
Je ziet nu er elektrische auto's bestaan toch ook niet van de ene op de andere dag iedereen met z'n ding rijden, dat heeft TIJD nodig
En tot die tijd doe ik lekker alles met flash en waar mogelijk met HTML5 maar altijd met terugval mogelijkheden naar flash!
Flash wordt vziw niet veel gebruikt voor intranetten en zelfs als dat wel zo is, kunnen die mensen bij de oude browser blijven. De rest stapt gewoon over naar de nieuwste versie van zijn of haar browser met HTML5 en we kunnen flash achter ons laten
Je moet het zo zien. Zodra de grote sites zoals Youtube omswitchen en de sites die hier gebruik van maken (hyves, facebook) ook een melding (+ link) geven voor een nieuwe browser zal de overgang veel sneller zijn dan "vroeger" het geval was
Maar alsnog duurt het wel 1 tot 2 jaar hoor daar ben ik het wel met je eens maar het zal sneller verlopen door dat veel mensen gebruik maken van dezelfde sites
Maar alsnog duurt het wel 1 tot 2 jaar hoor daar ben ik het wel met je eens maar het zal sneller verlopen door dat veel mensen gebruik maken van dezelfde sites
Het gaat harder dan je denkt.
Youtube en vimeo hebben al html 5.
CNN heeft het of is bezig.
Brightcove (videoplatform leverancier van 1000 sites o.a. Time en de NY Times) hebben ook al HTML 5 video support (Zie linkje)
Youtube en vimeo hebben al html 5.
CNN heeft het of is bezig.
Brightcove (videoplatform leverancier van 1000 sites o.a. Time en de NY Times) hebben ook al HTML 5 video support (Zie linkje)
dat mag dan waar zijn, maar door een open / vrije codec kun je wel zelf je browser-plugin bouwen, iets dat met flash wat minder goed lijkt te lukken, dus zelfs als <insert je browser> dit niet standaard ondersteund dan nog zal het makkelijker (dan nu) zijn om het toch werkend te krijgen. denk maar eens aan alle problemen die browsers nu hebben met flash (bijv onder linux of op je gsm). en waar één bedrijf (bij flash is dat adobe), steken kan laten valllen zal dat bij een vrije codec snel door 'de gemeenschap' worden opgelost.
Het probleem met plugins is dat je het moet installeren. het is niet bevoordelijk om veel plugins te installeren. je zult het niet snel merken, Echter als je van PC veranderd of je OS opnieuw moet installeren ben je langbezig met uitzoeken welke plugins je allemaal nodig hebt. Het is dus beter om dit te intergreren. Daarnaast als het geintergreerd is, voelt dat ook meer als een goedkeuring cq bevestiging.
Was "een lichte browser die je zelf naar smaak aan kan passen" niet juist een voordeel van een aantal browsers (o.a. FireFox) ?
Wanneer alles vast geintegreerd wordt zitten we straks wéér met van die logge dinosaurussen.
Ik vind keuze via plug-ins zo gek nog niet.
(Al is VP8 wel een plug-in die ik zou installeren
)
Wanneer alles vast geintegreerd wordt zitten we straks wéér met van die logge dinosaurussen.
Ik vind keuze via plug-ins zo gek nog niet.
(Al is VP8 wel een plug-in die ik zou installeren
)
Dat was toch het hele punt van HTML5. Videos zonder plugins aan het werk krijgen. 
true, en daar wordt ook op gemikt maar als je dan toch vast zit aan een plugin dan liever eentje die vrij is, en ook nog eens opensource (zodat elke gek, hem naar z'n <insert > kan porten). - in de meeste browsers waarsch zonder en in een enkele mischien met plugin maar dan werkt het na verloop van tijd ten minste op iedere browser / ieder device.
Dat is ook het hele idee, maar je krijgt dan het kip en het ei verhaal.
Als je de VP8 codec als plugin gaat aanbieden, dan kunnen dus alle browser met dat video formaat overweg. Veel sites zouden dan gebruik gaan maken van die codec, aangezien het een groot marktaandeel heeft/ kan krijgen. (Tussen de Theora-codec en de h.264. zit nu al een markt verschil van 20%, aangezien Firefox de H.264 niet ondersteunt, dus moet je als website bouwer altijd met de 2 formaten rekening gaan houden.) Als veel sites er gebruik van gaan maken, dan is het later voor de browser makers mogelijk om de codec standaard in de browser op te nemen en de Theora en H.264 te laten vallen.
De plugin kan je dan dus zien als een tijdelijk oplossing om de komende 1-3 jaar te overbruggen. Voor 90% van de gebruikers maakt het niet uit, die installeren toch wel een plugin, zeker als grote sites zoals youtube die nodig hebben. Voor website bouwers is het makkelijker omdat je dan maar met 1 codec rekening moet houden. Voor de browers bakkers is het dan weer eenvoudiger om 1 codec te gaan ondersteunen zonder licencie gelden te betalen.
Als je de VP8 codec als plugin gaat aanbieden, dan kunnen dus alle browser met dat video formaat overweg. Veel sites zouden dan gebruik gaan maken van die codec, aangezien het een groot marktaandeel heeft/ kan krijgen. (Tussen de Theora-codec en de h.264. zit nu al een markt verschil van 20%, aangezien Firefox de H.264 niet ondersteunt, dus moet je als website bouwer altijd met de 2 formaten rekening gaan houden.) Als veel sites er gebruik van gaan maken, dan is het later voor de browser makers mogelijk om de codec standaard in de browser op te nemen en de Theora en H.264 te laten vallen.
De plugin kan je dan dus zien als een tijdelijk oplossing om de komende 1-3 jaar te overbruggen. Voor 90% van de gebruikers maakt het niet uit, die installeren toch wel een plugin, zeker als grote sites zoals youtube die nodig hebben. Voor website bouwers is het makkelijker omdat je dan maar met 1 codec rekening moet houden. Voor de browers bakkers is het dan weer eenvoudiger om 1 codec te gaan ondersteunen zonder licencie gelden te betalen.
Wat hebben mensen toch met die plugins.. de enige plugin die ik echt gebruik is de gene die Flash uitschakelt. Moeten we er niet eens van af stappen overal maar plugins voor te maken? 
OT: Ik hoop dat er goede hardwarematige ondersteuning op mobiele apparaten komt anders is dit denk ik ook gedoemd te mislukken.. Wel een prachtig initiatief van Google! Geen ander bedrijf kan het ook beter aan de man brengen dan Google.. Met Youtube hebben ze meteen een groot marktaandeel.
OT: Ik hoop dat er goede hardwarematige ondersteuning op mobiele apparaten komt anders is dit denk ik ook gedoemd te mislukken.. Wel een prachtig initiatief van Google! Geen ander bedrijf kan het ook beter aan de man brengen dan Google.. Met Youtube hebben ze meteen een groot marktaandeel.
je bedoeld: je deinstalleerd flash?de enige plugin die ik echt gebruik is de gene die Flash uitschakelt.
nee, hij bedoelt de plugin die zorgt dat flash uitgeschakeld word tenzij hij aangeeft dat hij 't wil hebben.
spaart veel acculading op mijn macbook pro kan ik je zeggen...
flash aan, 2-3 uur internetten
flash uit, of alleen aan als ik even een filmpje kijk haal ik toch wel de door apple aangegeven 5+ uur
spaart veel acculading op mijn macbook pro kan ik je zeggen...
flash aan, 2-3 uur internetten
flash uit, of alleen aan als ik even een filmpje kijk haal ik toch wel de door apple aangegeven 5+ uur
Ondanks dat het hier nog steeds geruchten zijn, is het natuurlijk wel mooi nieuws. Op het moment ligt video ondersteuning in HTML 5 nog redelijk gevoelig, mede omdat Apple en Microsoft Theora niet implementeren, en ook YouTube nog gebruikt maakt van de H264 codec. Logisch: H264 heeft betere compressie dan Theora, en daarmee (veel) betere geluid- en videokwaliteit bij dezelfde bitrates. Voor Apple is het tevens belangrijk dat er hardwarematige versnelling is voor hun mobiele producten, iets wat bij Theora nog niet het geval was. Daarnaast is Apple van mening dat er met Theora nog de nodige lijken uit de kast kunnen komen door "submarine patents".
Vorige week heeft Google aangekondigd te gaan investeren in Theora ARM waarmee een groot deel van de mobiele apparaten hardwarematige versnelling kan gebruiken. Toch is het niet heel gek om te denken dat de investering niet zo zeer nadruk legt op de huidige richting, Theora, maar de makers de mogelijkheid biedt om aandacht te besteden aan VP8. In hetzelfde bericht heeft Google de patenten-claim van Apple ontkracht met het volgende citaat: "Not just “free to use in decoders," or “free to use if you agree to this complicated license agreement," but really, honestly, genuinely, 100% free". Ondanks dat competitiviteit tussen Apple en Google op het gebied van browser ontwikkeling gezond is, is dat toch wel een scherpe snaar richting Apple: met één blogpost ontkrachten ze beide argumenten van Apple tegen Theora.
Het "lekken" van deze informatie kan tevens heel goed opzet zijn. Als Google dit inderdaad al een tijd van plan is (misschien zelfs al lang voor de overname van On2) dan kan het best zijn dat er al een tijd gelobbyd wordt tussen de browser vendors. Het meest logische scenario voor de aankondiging is in mijn ogen dat Google, samen met Mozilla de VP8 codec publiekelijk beschikbaar maakt, samen met een ARM versie en plannen om YouTube over te laten schakelen van H264 naar VP8. Dit zou Apple, mochten ze zelf niet kiezen om VP8 te implementeren, in een moeilijke positie plaatsen: het bedrijf dat zoveel nadruk legt op HTML 5 en Flash in principe al doodverklaart heeft, kan geen gebruik maken van YouTube. (Ver) onder de riem, natuurlijk, maar m.i. voor het internet wel het beste.
En Microsoft? Ik denk dat het gemakkelijk nog tot juli kan duren voordat daar uitsluitsel over is. Volgens hun bi-maandelijkse update plannen is de volgende preview van Internet Explorer 9 in mei, en die daarna pas in juli. Mei lijkt me te vroeg, tenzij Google ook actief met Microsoft in gesprek is, en ondanks de verbeterde instelling van het Internet Explorer team doen ze bar weinig uitspraken over het ondersteunen van bepaalde features (denk aan canvas) of codecs. Mocht ook Apple overstag gaan en VP8 implementeren in Safari, dan zou dit nog wel eens het einde van het Theora/H264 geneuzel kunnen betekenen, en wellicht zelfs opgenomen worden in de HTML 5 standaard. Dat zou mooi zijn
Vorige week heeft Google aangekondigd te gaan investeren in Theora ARM waarmee een groot deel van de mobiele apparaten hardwarematige versnelling kan gebruiken. Toch is het niet heel gek om te denken dat de investering niet zo zeer nadruk legt op de huidige richting, Theora, maar de makers de mogelijkheid biedt om aandacht te besteden aan VP8. In hetzelfde bericht heeft Google de patenten-claim van Apple ontkracht met het volgende citaat: "Not just “free to use in decoders," or “free to use if you agree to this complicated license agreement," but really, honestly, genuinely, 100% free". Ondanks dat competitiviteit tussen Apple en Google op het gebied van browser ontwikkeling gezond is, is dat toch wel een scherpe snaar richting Apple: met één blogpost ontkrachten ze beide argumenten van Apple tegen Theora.
Het "lekken" van deze informatie kan tevens heel goed opzet zijn. Als Google dit inderdaad al een tijd van plan is (misschien zelfs al lang voor de overname van On2) dan kan het best zijn dat er al een tijd gelobbyd wordt tussen de browser vendors. Het meest logische scenario voor de aankondiging is in mijn ogen dat Google, samen met Mozilla de VP8 codec publiekelijk beschikbaar maakt, samen met een ARM versie en plannen om YouTube over te laten schakelen van H264 naar VP8. Dit zou Apple, mochten ze zelf niet kiezen om VP8 te implementeren, in een moeilijke positie plaatsen: het bedrijf dat zoveel nadruk legt op HTML 5 en Flash in principe al doodverklaart heeft, kan geen gebruik maken van YouTube. (Ver) onder de riem, natuurlijk, maar m.i. voor het internet wel het beste.
En Microsoft? Ik denk dat het gemakkelijk nog tot juli kan duren voordat daar uitsluitsel over is. Volgens hun bi-maandelijkse update plannen is de volgende preview van Internet Explorer 9 in mei, en die daarna pas in juli. Mei lijkt me te vroeg, tenzij Google ook actief met Microsoft in gesprek is, en ondanks de verbeterde instelling van het Internet Explorer team doen ze bar weinig uitspraken over het ondersteunen van bepaalde features (denk aan canvas) of codecs. Mocht ook Apple overstag gaan en VP8 implementeren in Safari, dan zou dit nog wel eens het einde van het Theora/H264 geneuzel kunnen betekenen, en wellicht zelfs opgenomen worden in de HTML 5 standaard. Dat zou mooi zijn
[Reactie gewijzigd door Peter op dinsdag 13 april 2010 10:27]
Maar is het ondersteunen van één enkele standaard gewoon niet erg korte termijn denken? Ik bedoel, VP8 gaat het wel één of twee jaar trekken, maar tegen die tijd zijn er toch alweer betere codecs die content aanbieders geld gaan schelen (betere encoding, lagere bandbreedte voor dezelfde of hogere kwaliteit) en dan zijn we weer terug bij af, want uiteindelijk willen mensen ook gewoon content kunnen afspelen, ongeacht wat voor codec daarvoor wordt gebruikt.
Ik vind de manier waarop Mozilla (en waarschijnlijk anderen ook, maar ik heb voornamelijk ervaring met Firefox) je per pagina attendeert dat je een bepaalde plug-in mist en je dan verder leidt naar de download pagina of je een pop-up voorschotelt om hem te installeren, een flexibelere manier om functionaliteit en dus ook codecs te kunnen toevoegen.
Je nu vastbijten in één bepaalde codec is een beetje kortzichtig naar mijn mening.
Ik vind de manier waarop Mozilla (en waarschijnlijk anderen ook, maar ik heb voornamelijk ervaring met Firefox) je per pagina attendeert dat je een bepaalde plug-in mist en je dan verder leidt naar de download pagina of je een pop-up voorschotelt om hem te installeren, een flexibelere manier om functionaliteit en dus ook codecs te kunnen toevoegen.
Je nu vastbijten in één bepaalde codec is een beetje kortzichtig naar mijn mening.
Bitmap heeft het ook een lange tijd volgehouden en is toen vervangen door JPEG.
Er zijn ook andere formaten maar JPEG is toch een beetje de standaard. Hetzelfde kan ook gebeurden met video maar laten we hopen dat het voor de eind gebruiker niet zichtbaar is.
Er zijn ook andere formaten maar JPEG is toch een beetje de standaard. Hetzelfde kan ook gebeurden met video maar laten we hopen dat het voor de eind gebruiker niet zichtbaar is.
Met betrekking tot standaardisatie vind ik dat helemaal niet zo'n slecht idee. Je wilt gewoon dat alle browsers die nu HTML5 ondersteunen, dat over 3 jaar nog steeds doen. En dus alle websites die in HTML5 gemaakt zijn, perfect weergeven.
Bovendien, op internet hoeft het toch niet allemaal zo ontzettend briljante kwaliteit te zijn? Als je dat wilt download je de video toch gewoon in een hogere resolutie / andere codec? Er moet gewoon afgesproken worden welke formaten door HTML5 ondersteund gaan worden en daar moet dan verder niet meer aan getornd worden. Pas dan heb je een echte standaard.
In een latere revisie van HTML5 zou je dan eventueel ondersteuning kunnen toevoegen voor andere formaten, mocht die noodzaak blijken.
Bovendien, op internet hoeft het toch niet allemaal zo ontzettend briljante kwaliteit te zijn? Als je dat wilt download je de video toch gewoon in een hogere resolutie / andere codec? Er moet gewoon afgesproken worden welke formaten door HTML5 ondersteund gaan worden en daar moet dan verder niet meer aan getornd worden. Pas dan heb je een echte standaard.
In een latere revisie van HTML5 zou je dan eventueel ondersteuning kunnen toevoegen voor andere formaten, mocht die noodzaak blijken.
Niets let browser bouwers om in de toekomst nieuwe codecs toe te voegen. Het is niet zo dat ze maar één codec in kunnen bouwen. Voor iedere codec een aparte plugin toevoegen is vragen om problemen met prestatie en stabiliteit.
Gezien de ontwikkelingen op het moment best snel gaan, en het update patroon van gebruikers aan het veranderen is (kijk bijvoorbeeld naar Google Chrome versies) denk ik dat het best meevalt. Met name als YouTube over zou gaan op VP8 zouden andere browser vendors zich best snel kunnen aanpassen. Het is best mogelijk dat bij de aankondiging zelf Mozilla Firefox en Google Chrome al aangepast zullen zijn, bij Opera zal het in de wekelijkse development build meegenomen kunnen worden en Safari / Internet Explorer duren iets langer, maar ook deze browsers zitten niet meer in een "laten we een jaar stil zijn" denkwijze.
Voor goede penetratie op een manier dat het bruikbaar wordt voor websites, zoals <video> vandaag al gebruikt wordt, kan het inderdaad nog gemakkelijk een jaar (of twee) duren. Wel anticipeert de specificatie hierop: door meerdere <source> elementen binnen de video tag te plaatsen kun je, in ieder geval voor zolang dat nodig is, meerdere video formaten ondersteunen zodat de cliënt zelf een keuze kan maken.
Kortzichtig.. ik zou het eerder hoopvol noemen. VP8 zit qua compressie en kwaliteit op (of hoger dan) dan het niveau van H264, met ARM ondersteuning zou de performance ook op dat niveau kunnen komen voor hardware. Door het totaal open te gooien, zoals On2 destijds met VP3 naar Theora gedaan heeft en een formeel statement te publiceren dat er geen patenten op rusten legt Google de weg in ieder geval open.
Voor goede penetratie op een manier dat het bruikbaar wordt voor websites, zoals <video> vandaag al gebruikt wordt, kan het inderdaad nog gemakkelijk een jaar (of twee) duren. Wel anticipeert de specificatie hierop: door meerdere <source> elementen binnen de video tag te plaatsen kun je, in ieder geval voor zolang dat nodig is, meerdere video formaten ondersteunen zodat de cliënt zelf een keuze kan maken.
Kortzichtig.. ik zou het eerder hoopvol noemen. VP8 zit qua compressie en kwaliteit op (of hoger dan) dan het niveau van H264, met ARM ondersteuning zou de performance ook op dat niveau kunnen komen voor hardware. Door het totaal open te gooien, zoals On2 destijds met VP3 naar Theora gedaan heeft en een formeel statement te publiceren dat er geen patenten op rusten legt Google de weg in ieder geval open.
ARM ondersteuning is niet genoeg, zeker niet voor HD content. Het moet ondersteund gaan worden in de media chips zoals ik hieronder schreef. Als een ARM chip op vol vermogen draait is je batterij zo leeg, ook al kan de ARM het vloeiend afspelen. Daarnaast wordt teruggegrepen naar integer berekeningen, en dat gaat waarschijnlijk iets ten kosten van de kwaliteit omdat kleine details moeilijker met integers gerepresenteerd kunnen worden. Ik moet het nog zien 
Zucht,
Straks krijg je een storm van Media ARM chips speciaal voor al die CODEC's...
Straks krijg je een storm van Media ARM chips speciaal voor al die CODEC's...
Gezien het feit dat google met youtube zo ongeveer de grootste content aanbieder is, zit het denk ik wel in orde. Ze zullen VP8 waarschijnlijk inderdaad wel verder door ontwikkelen en optimaliseren en over een aantal jaren met VP9 komen. Dat kunnen ze dan gebruiken om het serverpark voor youtube weer verder te verkleinen, zodra VP9 na een tijdje gemeengoed is geworden.
Het is zeker mooi en aardig, maar van hardware ondersteuning voor VP8 of Theora is nog absoluut geen sprake. Ja, leuk dat het nu beter draait op een ARM chip, maar het is nog steeds software matig en dat vreet batterijen. H.264 wordt door een aparte chip van (bijv.) Broadcom gedecodeerd met een fractie van de energie. Wil Google VP8 echt succesvol maken, dan zullen de fabrikanten van die chips (niet alleen voor mobieltjes, maar ook de mediacenters en netbooks) ook mee moeten gaan doen.
Natuurlijk, maar optimalisaties zijn een eerste stap. Als de VP8 codec na beter onderzoek echt superieur is dan de H264 codec, cross-platform beschikbaar is en gebruikt wordt op websites/YouTube, dan zal de vraag naar chips logischerwijs ook gaan toenemen. Zelfs voor Theora waren er al plannen (en testjes) om lib-theora en lib-ogg ondersteuning op een Leon3 chip te creeëren. Met de nodige commerciële interesses zie ik dit met VP8 ook nog wel gaan gebeuren.
http://people.xiph.org/~j...ga/doc/leon3_integration/Het is zeker mooi en aardig, maar van hardware ondersteuning voor VP8 of Theora is nog absoluut geen sprake.
http://www.schleef.org/bl...on-ti-c64x-dsp-and-omap3/
H.264 hardware acceleratie is bijna altijd niks anders dan een geprogrammeerde DSP, en met dezelfde hardware kan je ook Theora decoden.
En behalve dat werkt Theora vloeiend op een PC uit 2000 zonder enige vorm van hardware acceleratie. En Theora schaalt makkelijker naar beneden, want veel qualiteits verbeterende features kunnen genegeerd worden op low end systemen (die heb je toch niet nodig op een klein scherm).
Er zijn misschien wel 500 miljoen apparaten met h.264 hardware ondersteuning in de wereld al in omloop.
Met een dergelijk basis in hardware ondersteuning liggen bijvoorbeeld Dirac,Theora en VP8 nog vele jaren achter.
Met een dergelijk basis in hardware ondersteuning liggen bijvoorbeeld Dirac,Theora en VP8 nog vele jaren achter.
Professionele hardware draait met VC-2... is een subset van Dirac. Theora was al jaren geleden te vinden in professionele camera's en met respectievelijke FPGA's.
Zeker niet zoveel als met h264, maar laten we zeggen dat de meeste hardware ondersteuning van bijvoorbeeld videocodecs toch een copy/paste blijkt te zijn van vele opensource projecten. Google maar eens op GPL violations met Sigma Designs, je kunt dus beter spreken over een 'defacto standaard' waar de motivatie onduidelijk van is. H264 is vrij complex in vergelijking tot bijvoorbeeld Dirac.
Zeker niet zoveel als met h264, maar laten we zeggen dat de meeste hardware ondersteuning van bijvoorbeeld videocodecs toch een copy/paste blijkt te zijn van vele opensource projecten. Google maar eens op GPL violations met Sigma Designs, je kunt dus beter spreken over een 'defacto standaard' waar de motivatie onduidelijk van is. H264 is vrij complex in vergelijking tot bijvoorbeeld Dirac.
Ik denk ook uberhaupt het einde van theora..Mocht ook Apple overstag gaan en VP8 implementeren in Safari, dan zou dit nog wel eens het einde van het Theora/H264 geneuzel kunnen betekenen, en wellicht zelfs opgenomen worden in de HTML 5 standaard. Dat zou mooi zijn
Ik denk dat VP8 het niet verder schopt dan een aanbeveling in de HTML5 standaard.. Misschien is dat jammer, aan de andere kant kunnen we nu niet HTML5 zo dicht timmeren dat we straks een probleem hebben als VP8 straks niet meer bij tijds is, waar gaan we het dan door vervangen.. Moeten alle browser makers dan weer gaan bakkeleien of licenties en voorwaarden? Wat mij betreft mag de videotag zo werken als de img tag. De enige die dat niet voldoende ondersteunt is Microsoft.Aangezien Microsoft er toch zijn eigen standaarden op na houdt en niet de richtlijnen kan/wil volgen, neem ik deze browser toch niet serieus. Het zou dus mooi zijn als alle browsers VP8 standaard ondersteunen maar dat H.264 ook tot de mogelijkheden behoort. Het Quicktime components systeem is hier denk ik erg geschikt voor. Dit zijn enkel decoder componenten in plaats van full fledged plugins. Zie ook hier voor o.a. de reden waarom QuickTime nooit aangeslagen is op Windows. Op deze manier kunnen we het installeren van een 'plugin' (decoder) zo eenvoudig maken als het installeren van een search engine in IE8 en FF.
Er was toch al een implementatie geweest van VP8 in ffmpeg die door dreigementen offline is gehaald? Ik denk dus dat de implementatie, als het toch open source wordt, al native aanwezig kan zijn in bestaande oplossingen.
Vrijwel zeker zal Microsoft in IE9 geen theora ondersteuning opnemen en heel zeker geen VP8 ondersteuning.En Microsoft? Ik denk dat het gemakkelijk nog tot juli kan duren voordat daar uitsluitsel over is.
Ze zullen in hun html video implementatie in iedergeval h.264 ondersteuning opnemen en mogelijk ook VC-1 ondersteuning
[Reactie gewijzigd door hAl op dinsdag 13 april 2010 12:08]
Je noemt geen bronnen. Microsoft heeft duidelijk gemaakt geen Theora te gaan implementeren, mede omdat ze lid zijn van MPEG-LA. Ze hebben nog geen uitspraken gedaan over VP8 of eventuele andere formaten.
Microsoft zal zeker geen broncode met een open source licentie in hun applicaties opnemen en ook als Google ooit nog eens de volledige specificaties publiceert en een vrije patentlicentie/vrijwaring verstrekt dan zal het zelf bouwen van een eigen codec vanaf scratch nog voor de release van IE9 zeker niet meer gebeuren.
VP8 is een relatief nieuwe propriety codec waarover nog maar heel weinig bekend is en al helemaal niet precies welke technologieen erin zijn verwerkt die mogelijk gepatenteerd zijn door andere 3rd party partijen.
Microsoft zal daar heel zeker niet zo maar instappen zonder garanties.
VP8 is een relatief nieuwe propriety codec waarover nog maar heel weinig bekend is en al helemaal niet precies welke technologieen erin zijn verwerkt die mogelijk gepatenteerd zijn door andere 3rd party partijen.
Microsoft zal daar heel zeker niet zo maar instappen zonder garanties.
[Reactie gewijzigd door hAl op dinsdag 13 april 2010 13:51]
Dat hebben ze al eens gedaan hoor. Je hebt namelijk ook opensource licenties die anders in elkaar zitten dan de GPL, en die je gewoon mag gebruiken. (zolang je maar niet claimed dat je 't zelf gemaakt hebt).Microsoft zal zeker geen broncode met een open source licentie in hun applicaties opnemen
Zo is microsoft aan z'n tcp/ip stack gekomen in windows 2000, die hebben ze van FreeBSD overgenomen. (en dat is volledig in orde qua licentie)
Dat zou betekenen dat IE9 wellicht out-of-the-box niet eens de HTML5 versie van YouTube kan gebruiken. Dat gaat ze niet helpen om developers (en gebruikers) te overtuigen dat ze nu toch echt op het rechte pad zitten en voorlopen op de rest. Integendeel, hiermee zetten ze zichzelf (alweer) op achterstand.Vrijwel zeker zal Microsoft in IE9 geen theora ondersteuning opnemen en heel zeker geen VP8 ondersteuning.
[Reactie gewijzigd door JanDM op dinsdag 13 april 2010 13:07]
Aangezien Google in eerdere uitlatingen heeft aangeven in hun html 5 implementatie h.264 op Youtube te zullen gaan ondersteunen en dat ook in hun eerste implementaties heeft gedaan is het onwaarschijinlijk dat ze nu die ondersteuning zouden laten vallen. Dat zou ze vrijwel zeker op een rechtszaak komen te staan.Dat zou betekenen dat IE9 wellicht out-of-the-box niet eens de HTML5 versie van YouTube kan gebruiken
[Reactie gewijzigd door hAl op dinsdag 13 april 2010 13:27]
Verkeerd geplaatst
[Reactie gewijzigd door Incr.Badeend op dinsdag 13 april 2010 11:18]
Open Source != Open Standaard
Dat de codec open source wordt is niet interessant. Voor H.264 is er ook een open source implementatie: x264. Maar zo lang het geen "open standaard" (de definitie waarin er _geen_ licentie gekocht moet worden, of iig niet voor content providers en decoders) is heb je er weinig aan.
De FSF vroeg aan Google niet op VP8 open source te maken, maar om het een open standaard te maken. Uit de brief:
Dat de codec open source wordt is niet interessant. Voor H.264 is er ook een open source implementatie: x264. Maar zo lang het geen "open standaard" (de definitie waarin er _geen_ licentie gekocht moet worden, of iig niet voor content providers en decoders) is heb je er weinig aan.
De FSF vroeg aan Google niet op VP8 open source te maken, maar om het een open standaard te maken. Uit de brief:
Just think what you can achieve by releasing the VP8 codec under an irrevocable royalty-free license and pushing it out to users on YouTube?
Er staat ook dat ze het "vrij beschikbaar" stellen.
.De FSF vroeg aan Google niet op VP8 open source te maken, maar om het een open standaard te maken.
Hele terechte opmerking, De FSF wil niet alleen een open source implementatie, en het openen van de standaard, maar óók nog eens dat de licentie op de codec onherroepelijk in het publieke domein terecht komt. Dat laatste is het enige wat VP8 anders zou maken dan H.264.
Dat betekent echter nog altijd niet dat Google kan garanderen dat VP8 altijd 'gratis' zal zijn. Net zoals H264 en Theora is het mogelijk dat derden patenten hebben op technieken die in deze codecs worden toegepast.
Verder vraag ik me ook af wat er met H.264 zou gebeuren als Google inderdaad deze stap neemt. H.264 is al een open standaard met open source implementaties. Het belangrijkste wat er tegenin wordt gebracht door sommige 'enthousiastelingen' is dat het royalty-beleid voor de toekomst (na 2013-2014 iirc) nog niet vaststaat.
Ik zou verwachten dat de MPEG-LA op het vrijgeven van VP8 zou reageren door dit voor H.264 zo spoedig mogelijk te publiceren. Ik denk ook dat de voorwaarden enorm aantrekkelijk zullen zijn; niemand in de industrie muv een aantal open-source groepjes zit m.i. te wachten op het vervangen van H.264. Het is al te ingeburgerd daarvoor.
Mij lijkt het dus waarschijnlijk dat het openen van VP8 niet zal leiden tot een overgang op deze codec, maar tot het aantrekkelijker maken van de voorwaarden van H.264.
[Reactie gewijzigd door Arthur op dinsdag 13 april 2010 19:18]
MPEG-LA is geen eigenaar van h.264.Ik zou verwachten dat de MPEG-LA op het vrijgeven van VP8 zou reageren door dit voor H.264 zo spoedig mogelijk te publiceren.
h.264 is een codec die is gestandaardiseerd en de specificaties zijn eigendom van de standandaardisatie organisatie (bijvoorbeeld ISO/IEC). De specificaties daarvan zijn dus al voro een ieder die dat wil beschikbaar.
MPEG-LA bezit de het exploitatierecht op op bepaalde gepatenteerde technologieeen gebruikt in h.264 en moet deze tegen 'reasonable' licentiekosten verstrekken (omdat de verschillende standaardisatie deelnemers zich daartoe verplicht hebben)
[Reactie gewijzigd door hAl op dinsdag 13 april 2010 13:18]
Dit is wat we gehoopt én om gevraagd hadden. Ik kan me niet anders voorstellen dat iedere browsermaker die HTML5 een goede start/toekomst wil geven VP8 op basis van de Open Source licentie gaat ondersteunen.
Of het zo ver zal komen dat deze codec alsnog opgenomen wordt in de HTML5 standaard heb ik m'n twijfels over, maar dat zou uiteindelijk nog mooier zijn.
Of het zo ver zal komen dat deze codec alsnog opgenomen wordt in de HTML5 standaard heb ik m'n twijfels over, maar dat zou uiteindelijk nog mooier zijn.
Dat hangt er geheel vanaf wat voor opensource licentie. de GPL is voor een hoop bedrijven nog altijd heel erg eng. Een BSD / Mozilla/ / Apache license daarentegen is voor de meeste bedrijven geen probleem.Ik kan me niet anders voorstellen dat iedere browsermaker die HTML5 een goede start/toekomst wil geven VP8 op basis van de Open Source licentie gaat ondersteunen.
Op dit item kan niet meer gereageerd worden.
Populair: Tablets Samsung Websites en communities Mobiele telefoons Google Sony Microsoft Games Politiek en recht Consoles
© 1998 - 2013 Tweakers.net B.V. Contact Over Tweakers Jouw privacy Algemene voorwaarden Cookies
Tweakers wordt uitgegeven door De Persgroep en wordt gehost door True
