Google geeft licentievrije WebM-videoformaat vrij
Google heeft zijn VP8-codec vrijgegeven onder de naam WebM. De videocodec zal onder andere ondersteund worden in de browsers van Mozilla en Opera, evenals IE9 van Microsoft. Adobe doet ook mee met zijn Flash-plugin.
Het vrijgeven van de VP8-codec werd woensdag aangekondigd tijdens de eerste keynote op Google I/O, een jaarlijkse bijeenkomst voor ontwikkelaars. Er gingen al langer geruchten over de mogelijkheid dat Google de VP8-codec, oorspronkelijk een creatie van On2, zou vrijgeven. De Free Software Foundation vroeg in februari al aan Google om de VP8 opensource te maken, zodat het naast het reeds open Ogg Theora-formaat gebruikt zou kunnen worden.
De VP8-codec moet volgens Google een licentievrij en breed toegepast alternatief gaan vormen voor de h.264-codec, die op grote schaal wordt gebruikt om hd-video's via internet te streamen. Ook kondigde Google aan dat vanaf woensdag op YouTube alle geüploade video's met een resolutie van 720p en hoger in het nieuwe WebM-formaat gecomprimeerd zullen worden.
De VP8-codec, voorzien van een licentie die op die van BSD lijkt, zal opgaan in de WebM-standaard. Als bestandscontainer is voor het opensource Matroska-formaat gekozen, terwijl audiostreams volgens de eveneens licentievrije Vorbis-codec gecomprimeerd dienen te worden. Volgens Google vereist de codec relatief weinig rekenkracht en levert het hierdoor ook goede prestaties op mobiele apparatuur.
Google stelde op de I/O-bijeenkomst dat ook hardwarefabrikanten, waaronder AMD en Nvidia, WebM zullen ondersteunen. Daarnaast maakte zowel Opera als Mozilla bekend dat ze op korte termijn WebM-afspeelmogelijkheden aan hun browsers zullen toevoegen, terwijl Adobe heeft toegezegd dat het WebM-ondersteuning in zijn Flash-plugin zal opnemen. Ook Microsoft heeft laten weten dat Internet Explorer 9 met het nieuwe videoformaat, dat binnen html5 via de video-tag zal worden aangesproken, uit de voeten zal kunnen.
Met het vrijgeven van de VP8-codec moet er een door iedereen vrij te gebruiken alternatief komen voor h.264, een codec die met name voor hd-video breed gebruikt wordt maar in bepaalde gevallen wel licentiekosten met zich meebrengt. Onder andere Mozilla weigerde daarom het h.264-formaat in Firefox te ondersteunen.
Reacties (173)
Persoonlijk zie ik dit als een goede ontwikkeling. Open Source heeft zeker op dit gebied nog goede kansen om door te breken.
open source gaat hand in hand met open standaarden
Het heeft (mits de licentie vrij genoeg is) een groot voordeel, namelijk de prijs.
Vooral cameramakers zullen een vrij formaat graag omarmen.
Mits natuurlijk het niet te kostbaar is qua CPU-power tijdens het opnemen en het redelijk makkelijk te verwerken is in montageprogramma's en af te spelen is en het qua bitrate ook beter presteert dan de concurrentie.
Kortom, er zijn best wel veel mitsen en maren, maar ik verwacht dat een adoptie door Google/Youtube best wel kan meewerken aan een succes.
Vooral cameramakers zullen een vrij formaat graag omarmen.
Mits natuurlijk het niet te kostbaar is qua CPU-power tijdens het opnemen en het redelijk makkelijk te verwerken is in montageprogramma's en af te spelen is en het qua bitrate ook beter presteert dan de concurrentie.
Kortom, er zijn best wel veel mitsen en maren, maar ik verwacht dat een adoptie door Google/Youtube best wel kan meewerken aan een succes.
Ik was hardware (zoals camera's) helemaal vergeten! Als ook zij VP8 (of WebM) gaan ondersteunen... Dat zou prachtig zijn.
Om op het web door te breken, mag VP8 wel iets grotere bestands groottes produceren als H.264, het web is vooral gebaat met het open karater. Zolang de kwaliteit maar gelijk(aardig) (of hoger) als h.264 is.
Om op het web door te breken, mag VP8 wel iets grotere bestands groottes produceren als H.264, het web is vooral gebaat met het open karater. Zolang de kwaliteit maar gelijk(aardig) (of hoger) als h.264 is.
[Reactie gewijzigd door MrSnowflake op woensdag 19 mei 2010 21:39]
Het lijkt mij sterk dat opnameapparatuur direct naar h.264 óf VP8 coderen. Meestal wordt hier een 'snel te schrijven' formaat gebruikt, zoals AVCHD (als ik 't goed spel). Daarna bewerk je de video (raw) en dan pas comprimeer je'm naar h.264 of VP8. Die laatste codecs zijn intensief om te maken, maar erg geschikt om te streamen (en op low-end devices af te spelen).
Een quote uit Wikipedia:
) maakt gebruik van h.264. Dus VP8 kan makkelijk (uitgaande van gelijke of mindere hardware belasting) in dergelijke apparatuur gebruikt worden.
Dus AVCHD (ja, het is juist gespeldAVCHD utilizes MPEG-4 AVC/H.264 (AVC) video compression codec and either Dolby AC-3 (Dolby Digital) or linear PCM audio compression codec. Uncompressed linear PCM audio is not supported in existing consumer devices, but is offered in the Sony NXCAM professional lineup.
) maakt gebruik van h.264. Dus VP8 kan makkelijk (uitgaande van gelijke of mindere hardware belasting) in dergelijke apparatuur gebruikt worden.[Reactie gewijzigd door MrSnowflake op woensdag 19 mei 2010 21:52]
Ik snap je 'dus' niet. De apperatuur maakt gebruik van h.264 met AVCHD, en dus juist niet VP8. Het is niet effe een firmware update die dat kan veranderen, omdat het encoden van de videobeelden in de hardware gebeurt via een chip.Dus AVCHD (ja, het is juist gespeld
Ik denk dat MrSnowflake eerder bedoelt dat er ook apparatuur zal verschijnen die rechtstreeks naar VP8 (WebM) zal schrijven. Omdat het geen hogere vereisten legt op hardware. En dus niet dat de huidige hardware, gebruikt voor AVCHD, ingezet kan worden.
De eerste reviews duiden anders op dat de vrijgegeven VP8 decoder nog langzamer was als de x.264 en CoreAVC decoders.Omdat het geen hogere vereisten legt op hardware
Dat is geen goed teken.
Het aanwezig zijn van TI, BroadCom, ARM, MIPS en Qualcomm lijkt er anders toch op te wijzen dat dit door 'toegewijde' eenheden op SoC's gaat gebeuren:
"...it is obvious that only a HW solution is feasible for the encoder. An encoder supporting the 720p resolution can be implemented in a mobile chip even... ...(90 nm CMOS), while 1080p is feasible in 65 nm and 45 nm CMOS technologies."
On2 in DSP designline, 2008. Merk op dat ARM en GlobalFoundries in 2011 met 32/28nm gaan beginnen, in eerste instantie voor CPU kernen, maar lijkt me ook voor heel de SoC bruikbaar.
Een IVA 2+ core met encoder van Ittiam (o.a. gebruikt in de OMAP 3 serie van TI, die zijn weg o.a. in de Nokia 900 heeft gevonden) doet "H.264 Base Profile (BP) encoding at 720p, upto 30fps", terwijl de IVA3 eraan zit te komen (voor OMAP 4). Die doet 30fps, onder andere voor On2 VP7 (!) Dus het kan wel.
Aangezien TI bij het rijtje van WebM 'steuners' staat, lijkt het me logisch dat de overgang van VP7 naar VP8 voor hen niet te groot zal zijn, en deze codec zijn weg snel naar sillicium zal vinden.
"...it is obvious that only a HW solution is feasible for the encoder. An encoder supporting the 720p resolution can be implemented in a mobile chip even... ...(90 nm CMOS), while 1080p is feasible in 65 nm and 45 nm CMOS technologies."
On2 in DSP designline, 2008. Merk op dat ARM en GlobalFoundries in 2011 met 32/28nm gaan beginnen, in eerste instantie voor CPU kernen, maar lijkt me ook voor heel de SoC bruikbaar.
Een IVA 2+ core met encoder van Ittiam (o.a. gebruikt in de OMAP 3 serie van TI, die zijn weg o.a. in de Nokia 900 heeft gevonden) doet "H.264 Base Profile (BP) encoding at 720p, upto 30fps", terwijl de IVA3 eraan zit te komen (voor OMAP 4). Die doet 30fps, onder andere voor On2 VP7 (!) Dus het kan wel.
Aangezien TI bij het rijtje van WebM 'steuners' staat, lijkt het me logisch dat de overgang van VP7 naar VP8 voor hen niet te groot zal zijn, en deze codec zijn weg snel naar sillicium zal vinden.
[Reactie gewijzigd door kidde op donderdag 20 mei 2010 02:40]
Het wordt sowieso een succes, dit is nu het enige formaat dat door alle browsers ondersteund gaat worden (een ook nog eens Flash), ondersteuning voor mobiele apparaten èn HD… Meer hebben we niet nodig.
Dit is echt het geweldige nieuws waar ik al maanden op wacht. Nu maar hopen dat zo veel mogelijk sites overstappen.
Dit is echt het geweldige nieuws waar ik al maanden op wacht. Nu maar hopen dat zo veel mogelijk sites overstappen.
Van de grote browsers mis ik alleen Safari... Ik denk niet dat Apple dit nieuwe formaat niet met open armen zal ontvangen aangezien zij liever hun Quicktime formaat blijven gebruiken/opdringen.
Gelukkig heeft safari een (relatief) klein markt aandeel, hierdoor wordt apple vanzelf gedwongen dit formaat te gaan ondersteunen (mochten ze dat niet gaan doen, lijkt me eerlijk gezegd sterk) wanneer alle andere (grotere) browsers en content over gaat.
Ook gebruikt safari webkit (door apple zelf gemaakt en opensource), google chrome gebruikt ook webkit en gaat daar webM inbouwen, dus kan apple dit makkelijk overnemen.
Ik zie eerlijk gezegd geen reden voor apple om het niet te ondersteunen op inderdaad hun quicktime en H.264 na (ze zitten in de MPEG LA). Maar de nadelen wegen denk ik niet op tegen de voordelen/druk.
Ook gebruikt safari webkit (door apple zelf gemaakt en opensource), google chrome gebruikt ook webkit en gaat daar webM inbouwen, dus kan apple dit makkelijk overnemen.
Ik zie eerlijk gezegd geen reden voor apple om het niet te ondersteunen op inderdaad hun quicktime en H.264 na (ze zitten in de MPEG LA). Maar de nadelen wegen denk ik niet op tegen de voordelen/druk.
[Reactie gewijzigd door !GN!T!ON op woensdag 19 mei 2010 22:32]
kanttekening:
Webkit is volledig gemaakt op basis van de Open Source KHTML software. Het Open Sourcen was bittere noodzaak vanwege de licentie.
Je doet het voorkomen alsof Apple dit als gift doet of de ontwikkeling zelf heeft gedaan. Beide niet waar.
Wat mij betreft hoeven ze dat ook niet, maar de geschiedenis van Webkit is iig niet te vergelijken met die van WebM.
Ik ben het met je eens dat ondersteuning in Safari waarschijnlijk is. Exclusiviteit van quicktime lijkt me niet reëel.
Webkit is volledig gemaakt op basis van de Open Source KHTML software. Het Open Sourcen was bittere noodzaak vanwege de licentie.
Je doet het voorkomen alsof Apple dit als gift doet of de ontwikkeling zelf heeft gedaan. Beide niet waar.
Wat mij betreft hoeven ze dat ook niet, maar de geschiedenis van Webkit is iig niet te vergelijken met die van WebM.
Ik ben het met je eens dat ondersteuning in Safari waarschijnlijk is. Exclusiviteit van quicktime lijkt me niet reëel.
Nee Apple doet voorkomen alsof dit een gift van hun is, zoals ze nu ook webkit2 hadden gepresenteerd.. dat is typisch Apple... doen alsof zij zo innovatief zijn terwijl ze niets anders doen dan jatten..
Op de WebKit wiki staat het volgende:Nee Apple doet voorkomen alsof dit een gift van hun is, zoals ze nu ook webkit2 hadden gepresenteerd.
Door Apple betaalde medewerkers leveren dus bulk van het werk, dus ja het is een gift van Apple!Apple employees have contributed the majority of work on WebKit since it became an independent project. Apple uses WebKit for Safari on Mac OS X, iPhone and Windows; on the former two it is also a system framework and used by many other applications. Apple's contribution has included extensive work on standards compliance, Web compatibility, performance, security, robustness, testing infrastructure and development of major new features.
[Reactie gewijzigd door Carbon op donderdag 20 mei 2010 10:27]
Zoals hier al eerder aangegeven, het is geen gift: ze waren verplicht de code vrij te geven in verband met de licentie van de Open Source KHTML software. 
Dus het feit dat het meeste werk verzet wordt door Apple betaalde krachten kun je niet zien als gift aan de opensource community?ze waren verplicht de code vrij te geven in verband met de licentie van de Open Source KHTML software.
Ze hadden ook een eigen engine kunnen nemen, of die van Firefox / Mozilla kunnen pakken. KHTML was lange tijd een niet veel voorstellend project, tot het webkit werd.Zoals hier al eerder aangegeven, het is geen gift: ze waren verplicht de code vrij te geven in verband met de licentie van de Open Source KHTML software.
Ieder bedrijf dat betaalde werknemers inzet om een bestaand opensource project uit te breiden levert een gift aan de opensource wereld.
KHTML is de basis geweest voor WebKit in het begin, maar als je KHTML van toen vergelijkt met WebKit nu, is daar niet veel meer van terug te vinden hoor. (Ik weet niet hoeveel KHTML vervolgens over heeft genomen van WebKit).
jatten zou zijn als Apple Webkit had gepakt, en geen enkele vorm van bijdrage had gedaan aan het project.Nee Apple doet voorkomen alsof dit een gift van hun is, zoals ze nu ook webkit2 hadden gepresenteerd.. dat is typisch Apple... doen alsof zij zo innovatief zijn terwijl ze niets anders doen dan jatten..
Nu echter, heeft apple het merendeel van het werk aan webkit geleverd, en het project is een groot en bloeiend ding geworden, wat door meedere browsermakers wordt gebruikt.
Apple had ook z'n eigen engine kunnen maken, closed source en alles. Dit lijkt me uit opensource optiek gezien juist een veel betere situatie.
vergeet niet dat Steve Jobs namens Apple een persoonlijke kruistocht is begonnen tegen flash. Html5+VP8Web M is daar een ideale combi voor.
Ik vraag me af wat ze nu gaan doen. Aan de ene kant hebben ze zelf Quicktime en spelen iPod/iPhone/iPad allemaal H.264 HTML5 video. In dat opzicht hebben ze natuurlijk liever H.264 dan VP8, omdat ze dat dan weer in moeten gaan bouwen. (Zou technisch gezien niet heel moeilijk zijn, maar met Apple weet je het nooit … Als je dan ook nog hardwareacceleratie wilt moeten ze ook nog eerst een extra/andere chip inbouwen en dat gaan ze waarschijnlijk niet snel doen.)
Van de andere kant wil Apple natuurlijk ook weer zoveel mogelijk Safarigebruikers en zijn ze voorstanders van HTML5.
Ik verwacht dat Apple vroeg of laat toch wel mee gaat, zij het vrijwillig om HTML5 te ondersteunen, zij het verplicht om bij te blijven. (Denk ook aan Youtube die overgaat op VP8 + Youtube op de iPod/iPhone/iPad.)
Van de andere kant wil Apple natuurlijk ook weer zoveel mogelijk Safarigebruikers en zijn ze voorstanders van HTML5.
Ik verwacht dat Apple vroeg of laat toch wel mee gaat, zij het vrijwillig om HTML5 te ondersteunen, zij het verplicht om bij te blijven. (Denk ook aan Youtube die overgaat op VP8 + Youtube op de iPod/iPhone/iPad.)
Ik zie niet hoe Apple een keuze heeft. De push voor meet Quicktime gebruik is definitief mislukt. Zelfs MS heeft in feite met hun support voor WebM de push voor hun eigen standaard (WMV) opgegeven. Het is duidelijk hoe laat het is.
De push voor WMV is helemaal nog niet voorbij, aangezien veel tools van Microsoft gewoon vrolijk video in WMV-formaat encoden. En eerder kondigde Microsoft al aan om in ieder geval H.264 te gaan ondersteunen in IE9. Het is eerder dat Microsoft mee gaat met de menigte maar zelf niet echt een besluit neemt.
Uiteindelijk bied MS op deze manier een goede user experience aangezien gebruikers gewoon alles kunnen bekijken op deze manier. Als Safari blijft vasthouden aan h.264 en Mozilla/Opera aan WebM dan zullen deze browsers nooit alles kunnen weergeven. IE (en wss ook Chrome) kunnen dat dan weer wel.
WMV/VC-1 is nog steeds een goede optie voor streaming video omdat de decoder belasting zeer laag is wat vooral bij live streaming video veel nut biedt.
Vergeet dan gelijk niet dat Apple in de patentpool zit voor h.264. 1 van de 1134 patenten is van hun, dus voor iedere verkochte h.264 licentie krijgt Apple geld. Microsoft iets van 40x zoveel echter, dus die zullen vast ook liever h.264 hebben, dus daarom extra fijn dat ze toch meedoen.
WebM zal ook wel in Quicktime gaan draaien. Quicktime is een framework dat gebruik maakt van componenten voor de verschillende formaten. Je kunt simpelweg allerlei formaten toevoegen door codecs te plaatsen in de juiste directory (/library/quicktime als ik het uit m'n hoofd goed heb.) Daarna heb je ondersteuning voor die codec in alle apps die gebruik maken van quicktime. Dus bijvoorbeeld in Safari, in Final Cut, in iMovie etc.
Apple heeft daar zelf een pagina over:
http://www.apple.com/quicktime/resources/components.html
en een bekende set codecs wordt geleverd door Perian:
www.perian.org
Apple heeft daar zelf een pagina over:
http://www.apple.com/quicktime/resources/components.html
en een bekende set codecs wordt geleverd door Perian:
www.perian.org
Mits het aan hun vereisten voldoet, mits de software van de klant ermee om kan gaan, mits ze vrij zijn om hun eigen videocodec te gebruiken en bijvoorbeeld niet vastzitten aan een lopend contract met MPEG, etc.Vooral cameramakers zullen een vrij formaat graag omarmen.
Camerafabrikanten dragen op dit moment royalties af aan MPEG-LA voor een licentie om te mogen encoden. Het afspelen van H264 media is tot 2015 iig nog royalty-free, maar als tegen die tijd H264 flink ingeburgerd is komen de claims wel, de MPEG-LA is niet gek.
Misschien een leuk artikel om een door te nemen:
http://www.osnews.com/sto...Threatened_by_the_MPEG-LA
Misschien een leuk artikel om een door te nemen:
http://www.osnews.com/sto...Threatened_by_the_MPEG-LA
Jammerlijk weer want MPEG-LA kan niet zomaar licenties heffen vanaf 2015 omdat ze al toezeggingen gedaan hebben naar de toekomst.
Zo kunnen zij hun licenties niet meer dan 10% per 5 jaar verhogen.
Zo kunnen zij hun licenties niet meer dan 10% per 5 jaar verhogen.
Die toezegging gaat enkel over 'broadcast' voor 'non-comercial use'. Aan de andere kant is 10% over 0 natuurlijk ook weer 0, dus we kunnen aannemen dat dit geval altijd gratis zal blijven?
Dat hangt maar net van hun commerciele belangen af.Vooral cameramakers zullen een vrij formaat graag omarmen.
Als je al een H264 licentie hebt gekocht of geruild (dat laatste komt heeeel vaak voor), dan heb je mooi een streepje voor op de concurrentie. Sterker nog, door selectief te werk te gaan bij het verstrekken van licenties, kun je als clubje bedrijven de ongewenste spelers (zoals sharewareauteurs in het geval van software codecs) lekker buiten de deur houden.
Ik denk dat niet alle fabrikanten staan te springen om deze open codec te omarmen.
Zeker niet de fabrikanten die een "eigen" codec gebruiken, die alleen binnen hun eigen omgeving makkelijk gebruikt kan worden *hoest*sony*kuch*avchd*blaf*...
Dit heeft vrij weinig met Open Source te maken. Het gaat erom dat VP8 royalty en, nog belangrijker, patent vrij is! DAT is belangrijk voor het web. Het feit dat het Open Source is, is natuurlijk ook zeer interressant maar heb web heeft geen nood aan standaarden gebaseerd op proprietaire formaten.
met h.264/avc moet je voor elke video ongeveer 10 cent neertellen in 2012 
Ja, met h.264 krijgen we GIF toestanden over een aantal jaar.
Maar gelukkig zijn we er toch aan tegen 2012
Maar gelukkig zijn we er toch aan tegen 2012
2015!met h.264/avc moet je voor elke video ongeveer 10 cent neertellen in 2012
Je moet alleen betalen als je die video's verkoopt!
Commerciële aanbieders hoeven niet te betalen als ze gratis h264 films aanbieden en b.v de inkomsten halen uit reclame.,
Ook na 2015 geldt dat niet omdat de tariefstelling voor internet video's dan ofwel gratis blijft (dat is het meest waarschijnlijk) ofwel maximaal het tarief van free TV broadcasters krijgt wat ook niet veel is.
[Reactie gewijzigd door hAl op donderdag 20 mei 2010 13:05]
De eigenaren van h264 zullen waarschijnlijk gaan claimen dat VP8 weldegelijk gebruik maakt van hun patenten. Denk dat dat de grootste bedreiging van de codec gaat worden.
Dit zal inderdaad zo zijn, maar ik verwacht dat Google dit voldoende gecontroleerd heeft. Verder heeft Google ook patenten op VP8 en kan h.264 misschien terug claimen.
Met uw zorg wordt hier al rekening gehouden
.
(bron: http://www.webmproject.org/about/faq/)Is the WebM project owned by Google or is it independent? What if Google changes its mind?
WebM is an open-source project sponsored by Google. Google licenses its intellectual property that is covered by VP to VP8 users for free, under a BSD-style license. These licenses are revocable only if the licensee files a patent infringement lawsuit against the VP8 code that Google released.
Met uw zorg wordt hier al rekening gehouden
.[Reactie gewijzigd door MrSnowflake op woensdag 19 mei 2010 21:45]
H.264 is een oudere technologie. Elke claim van Google met patenten van VP8 op h.264 is dan ook lachwekkend want gaat ten onder wegens prior art. Welke prior art? h.264 zelf...
VP8 mag dan wel nieuwer zijn, maar is niet de eerste standaard van On2. Het is dus perfect mogelijk dat Google patenten in handen heeft gekregen die wel degelijk geschonden worden door h.264
On2 had maar weinig relevante patenten op codecs toen h.264 uitkwam.
Ik vraag het me af.
De H.264 specificatie stamt uit 2003.
On2 bestaat als sinds 1992. On2 gaf in 2001 de (gepatenteerde) VP3 codec vrij onder een OS licentie waaruit in 2002 de Theora codec is ontstaan.
De H.264 specificatie stamt uit 2003.
On2 bestaat als sinds 1992. On2 gaf in 2001 de (gepatenteerde) VP3 codec vrij onder een OS licentie waaruit in 2002 de Theora codec is ontstaan.
Je hebt helemaal gelijk, zie http://x264dev.multimedia.cx/?p=377#more-377
"Finally, the problem of patents appears to be rearing its ugly head again. VP8 is simply way too similar to H.264: a pithy, if slightly inaccurate, description of VP8 would be “H.264 Baseline Profile with a better entropy coder”. Though I am not a lawyer, I simply cannot believe that they will be able to get away with this, especially in today’s overly litigious day and age. 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. Until we get some hard evidence that VP8 is safe, I would be extremely cautious. Since Google is not indemnifying users of VP8 from patent lawsuits, this is even more of a potential problem."
"Finally, the problem of patents appears to be rearing its ugly head again. VP8 is simply way too similar to H.264: a pithy, if slightly inaccurate, description of VP8 would be “H.264 Baseline Profile with a better entropy coder”. Though I am not a lawyer, I simply cannot believe that they will be able to get away with this, especially in today’s overly litigious day and age. 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. Until we get some hard evidence that VP8 is safe, I would be extremely cautious. Since Google is not indemnifying users of VP8 from patent lawsuits, this is even more of a potential problem."
Fijne onafhankelijke bron. De firma ON2 ontwikkelt hun codecs al langer dan H.264 bestaat. Ach, zoals hij aangeeft, hij is geen advocaat.
Overigens zullen we hier niet direct veel last krijgen met software patenten.
Overigens zullen we hier niet direct veel last krijgen met software patenten.
Hoezo niet? FAT-software patent is afgelopen maand immers nog geldig verklaard door de hoogste Duitse rechter (die daar z'n plasje over kan doen)!
Dat FAT patent was van Microsoft, en Microsoft heeft iets van 40 patenten (~30 als je dubbele nationaliteiten niet meetelt) op h.264.
Dat FAT patent was van Microsoft, en Microsoft heeft iets van 40 patenten (~30 als je dubbele nationaliteiten niet meetelt) op h.264.
Als ik me niet vergis is MS één van die eigenaren. Het feit dat ook zij dit nieuwe formaat omarmen is denk ik wel een teken dat het met de aanklachten wel los zal lopen.De eigenaren van h264 zullen waarschijnlijk gaan claimen dat VP8 weldegelijk gebruik maakt van hun patenten. Denk dat dat de grootste bedreiging van de codec gaat worden.
MS betaalt meer voor H264 aan de rest van de bedrijven die de MPEG-LA vertegenwoordigt dan dat het voor zijn 75 patenten op H264 terugkrijgt. MS is qua patenten nogal vrijgevig bij dit soort dingen (VC1 hebben ze ook geprobeerd vrij te geven), maar als er ook maar 1 ding is in VP8 die lijkt op iets wat gepatenteerd is door een ander bedrijf vertegenwoordigd in de MPEG-LA, duurt het niet lang voor er een leger advocaten losgelaten wordt.
MS omarmt het formaat niet echt. Ze gaan het zelf niet implementeren dan wel verspreiden. Een risicoloze strategie die ook hun patentrechten niet aan zal tasten.Het feit dat ook zij dit nieuwe formaat omarmen is denk ik wel een teken dat het met de aanklachten wel los zal lopen
gelukkig zit google er achter met een paar miljard, en kunnen ze zo mpegla kopen als dat moet
Microsoft is alleen eigenaar van VC1, verder niets met AVC te maken.
Microsoft is alleen eigenaar van VC1, verder niets met AVC te maken.
[Reactie gewijzigd door stewie op donderdag 20 mei 2010 00:11]
Jawel, zie pagina 17 voor de lijst Microsoft patenten die AVC voor ze aan derden verkoopt (licenseert).
MPEG-LA kopen is non-relevant.
Die beheren patentpools maar zijn geen eigenaar van de patenten.
Die beheren patentpools maar zijn geen eigenaar van de patenten.
Ik denk niet dat Google alle bedrijven kan kopen die achter de MPEG-LA zitten.
De MPEG-LA is alleen maar een aanspreekpunt, wil je de patenten hebben zal je dus alle bedrijven moeten kopen. Als je ziet dat daar bijvoorbeeld Apple en Microsoft in zitten, die op dit moment een marketcap hebben van 226,0 en 247,5 miljard dollar, dan kan Google, wat nu een marketcap van 'slechts' 157,5 miljard dollar heeft, dat rustig vergeten. En dat zijn pas 2 van de bedrijven van de hele groep...
De MPEG-LA is alleen maar een aanspreekpunt, wil je de patenten hebben zal je dus alle bedrijven moeten kopen. Als je ziet dat daar bijvoorbeeld Apple en Microsoft in zitten, die op dit moment een marketcap hebben van 226,0 en 247,5 miljard dollar, dan kan Google, wat nu een marketcap van 'slechts' 157,5 miljard dollar heeft, dat rustig vergeten. En dat zijn pas 2 van de bedrijven van de hele groep...
Patent vrij is maar de vraag.. we gaan er even vanuit dat het patentvrij is, het is namelijk niet de eerste keer dat van een 'opensource'formaat gedacht werd dat het volledig patentvrij was... overigens is vp8 ook gewoon een 'gesloten'formaat, denk nou niet dat je daar zomaar een variant van mag afleiden en daarmee verder gaan..
Misschien worden de HTML5 video's nu eens goede kwaliteit en lost het de zware rekenproblemen op met Flash, maar in ieder geval mooie ontwikkeling
H264 geeft al zeer goede kwaliteit.
Er was nooit een probleem met de kwaliteit van HTML 5 video. Met h.264 kan je prima kwaliteit videos maken (Dit is de codec die de defacto standaard voor HTML 5 video ging worden, wellicht dat dat nu dus allemaal anders word). Alleen in een paar landen in de wereld (voornamelijk de VS) kennen ze zoiets als software patenten. Dit zorgt ervoor dat software fabrikanten voor h.264 royalties moeten afdragen in die landen.Misschien worden de HTML5 video's nu eens goede kwaliteit
Ik ben geen fan van Adobe Flash, maar dat is niet primair een Flash probleem. HD video kost nou eenmaal flink wat CPU cycles om te decoderen zonder hardware ondersteuning. Als je h.264 of VP8 zonder hardware ondersteuning decodeert zal je ook een hoge CPU load krijgen.en lost het de zware rekenproblemen op met Flash
Flash Player 10.1 (nu in beta) heeft (ok, eindelijk..) hardwarematige H.264 decoding op Windows met moderne videokaarten. Er is zelfs een versie van OSX die het mogelijk gaat maken.
[Reactie gewijzigd door Genoil op woensdag 19 mei 2010 22:17]
h.264 zou nooit de standaard worden in de HTML5 specs simpelweg omdat deze niet aan de voorwaarden van het W3C voldoet, zijnde een vrij te gebruiken codec.
Dat was niet omdat h.264 niet aan de voorwaarde voldeed. Dat was omdat de alle partijen in de W3C (Apple, Mozilla, Microsoft, etc.) er niet uit konden komen welke codec de standaard zou worden. Omdat ze allemaal teveel belangen hadden konden ze er niet uitkomen. Daarom hebben ze gegezegd de codec word geen onderdeel van de standaard, de browser moet zelf maar kijken welke codecs hij ondersteund.h.264 zou nooit de standaard worden in de HTML5 specs simpelweg omdat deze niet aan de voorwaarden van het W3C voldoen
Omdat partijen zoals Google met YouTube en Microsoft aangaven h.264 te gaan gebruiken zou h.264 dus tot defacto standaard worden verheven.
Als je een betere kwaliteit wilt moet je niet voor VP8 gaan, high profile h264 blijft sowieso veel beter.
Erg goede ontwikkeling. Mooi dat een codec zo vrij beschikbaar wordt gesteld én dat er meteen brede ondersteuning is vanuit diverse takken: hardware én software.
Google, Adobe, Microsoft, Free Software Foundation, Mozilla, Opera, AMD, nVidia...
Ik mis eigenlijk alleen Apple en Intel, die hebben ook redelijk veel invloed op het wereldwijde web en de drijvende veren daar achter.
En waar staat het W3C?
Hopelijk kunnen ze het daadwerkelijk bewerkstelligen tot dé standaard.
Ik mis eigenlijk alleen Apple en Intel, die hebben ook redelijk veel invloed op het wereldwijde web en de drijvende veren daar achter.
En waar staat het W3C?
Hopelijk kunnen ze het daadwerkelijk bewerkstelligen tot dé standaard.
Het W3C kan niet zomaar volgen, de leden zullen eerst hun akkoord moeten geven (veronderstel ik).
[Reactie gewijzigd door MrSnowflake op woensdag 19 mei 2010 21:36]
Apple maakt Safari, Safari gebruikt de Webkit browser die ze zelf open source gemaakt hebben, Google zal waarschijnlijk al VP8 / WebM ondersteuning toegevoegd hebben aan Chrome en dus Webkit, dus Apple volgt wel. Apple heeft er op zich weinig mee te maken.Ik mis eigenlijk alleen Apple en Intel, die hebben ook redelijk veel invloed op het wereldwijde web en de drijvende veren daar achter.
Overigens, kom ik net achter, Apple zit ook in de MPEG LA, dus die verdienen mogelijk aan h.264 licenties. Microsoft ook overigens. Intel weer niet.
Intel? Mja, die zullen, als AMD en nVidia WebM versnelling inbakken in hun GPU's - als dat nu al niet mogelijk is met slechts een driverupdate - alleen maar kunnen volgen. En anders maar niet - veel PC's en laptops gebruiken al AMD en / of nVidia GPU's.
Die heeft een specifieke codec die te gebruiken is voor de video tag juist uit de HTML5 draft gehaald, dus die maakt het niet zoveel uit. En ik vindt het niet erg als de w3c zich daar niet mee bemoeit - teveel kans dat ze beïnvloed worden door lobbyisten van een partij die vervolgens licentiegelden kan vragen.En waar staat het W3C?
Alhoewel ze hiermee mogelijk overstag kunnen gaan. Goed mogelijk dat Google al gesprekken met ze gehad heeft (of zat Google zelf niet in het w3c?) maar dat daar nog geen concrete zaken uitgekomen zijn.
[Reactie gewijzigd door YopY op woensdag 19 mei 2010 22:00]
webkit is een fork van het opensource khtml gedeelte van kde, apple heeft het dus niet opensource gemaakt, ze moesten zich gewoon aan de licensie houden
So? Alle verbeteringen zijn wel naar buitengebracht, alsook veel projecten die ze uit zichzelf open-source hebben gemaakt. Alsof Apple altijd het 'evil gesloten bedrijf' is.. en Google enkel vrijheid blijheid openheid... blegh.
Apple weigerde samen met de KHTML ontwikkelaars te werken in hetzelfde traject. Hierdoor kwamen de verbeteringen KHTML niet ten goede.
Hun vrije keuze overigens, maar om dit nu als tegenargument voor "evil" aan te dragen...
Hun vrije keuze overigens, maar om dit nu als tegenargument voor "evil" aan te dragen...
Ik zou zeggen, ga eens wat bijlezen over de verhouding tussen Apple en het KDE team. Dat was bijna oorlog tussen die twee.
Dat soort oorlogen komen ook binnen projecten nog wel eens voor.Ik zou zeggen, ga eens wat bijlezen over de verhouding tussen Apple en het KDE team. Dat was bijna oorlog tussen die twee.
Dat zegt ongeloofelijk weinig over wie van de twee goed/fout/evil/whatever is.
(als ik alleen al naar de halve en complete oorlogen kijk binnen de linux kernel, dan kun je stellen dat het haast de aard van het opensource beestje is)
Even een opmerking. Apple heeft WebKit niet open-source gemaakt. WebKit is een fork van KHTML. De engine van Konqueror, de browser van KDE.
Google Chrome gebruikt wel WebKit maar ze kunnen natuurlijk makkelijk support voor WebM inbakken terwijl Safari die aanpassing in WebKit niet gebruikt.
Google Chrome gebruikt wel WebKit maar ze kunnen natuurlijk makkelijk support voor WebM inbakken terwijl Safari die aanpassing in WebKit niet gebruikt.
Van Apple verbaast het me niet zo heel erg dat dat niet in dit rijtje staat. De standaard uitspraak van Apple over toekomst plannen is bijna altijd: "Apple never talks about future products". Dus wellicht dat Apple zelf t.z.t. komt met de aankondiging dat ze WebM ondersteunen in WebKit/Safari (bv. tijdens de WWDC in juni ergens).
Eerder in hun A4 SoC vermoedt ik. Ze zullen wel moeten gezien TI nu al VP7 op sillicium levert, en TI en BroadCom (vermoedelijk) allebei VP8 op sillicium zullen gaan leveren. Dan moet 'de rest' haast wel volgen.
Apple wilde Theora niet gebruiken, omdat ze de patenten voor deze codec niet vertrouwden. In principe zijn alle patenten ooit door de ontwikkelaar vrijgegeven, maar omdat het eigenlijk nooit echt commercieel gebruikt is, is er nooit echt diepgaand onderzoek gedaan naar eventuele onderliggende patenten van derde partijen die het zou kunnen schenden. Apple wil voorkomen dat Theora straks de webstandaard is en er dan ineens een partij met een serie patenten op de proppen komt zetten, die gebruikt worden door Theora en ook nog eens ouder zijn (er is al erg veel op het gebied van compressie gepatenteerd, waardoor dit scenario vrij reëel is).
Omdat h264 al lange tijd commercieel gebruikt wordt en daar erg veel grote bedrijven achter staan met veel patenten in deze business, is een soort van bewezen dat de kans erg klein is dat er nu nog eens patent-lijken uit de kast komen vallen.
Nu weet ik niet hoe uitvoerig Google de patenten rond VP8 onderzocht heeft, maar gezien de grote namen die nu al ondersteuning hebben toegezegd, denk ik dat ze best een goed verhaal hebben.
Het is iig zeker dat Apple veel rechten rond mp4 bezit (de container waar h264 vaak ingehesen wordt), aangezien dat voor een groot deel op mov gebaseerd is. Dus misschien hoopten ze nog wat bij te verdienen. Ook schijnt de opzet van Theora veel complexer te zijn om hardwarematig te versnellen vergeleken bij h264. Iets dat voor Apple met hun i-producten ook niet onbelangrijk is. Weet niet hoe dat met de VP8-codec zit?
Omdat h264 al lange tijd commercieel gebruikt wordt en daar erg veel grote bedrijven achter staan met veel patenten in deze business, is een soort van bewezen dat de kans erg klein is dat er nu nog eens patent-lijken uit de kast komen vallen.
Nu weet ik niet hoe uitvoerig Google de patenten rond VP8 onderzocht heeft, maar gezien de grote namen die nu al ondersteuning hebben toegezegd, denk ik dat ze best een goed verhaal hebben.
Het is iig zeker dat Apple veel rechten rond mp4 bezit (de container waar h264 vaak ingehesen wordt), aangezien dat voor een groot deel op mov gebaseerd is. Dus misschien hoopten ze nog wat bij te verdienen
. Ook schijnt de opzet van Theora veel complexer te zijn om hardwarematig te versnellen vergeleken bij h264. Iets dat voor Apple met hun i-producten ook niet onbelangrijk is. Weet niet hoe dat met de VP8-codec zit?[Reactie gewijzigd door Kheldar op woensdag 19 mei 2010 22:36]
Dat Apple als rechthebbend van h.264 er geld mee wil verdienen lijkt me duidelijk, maar dat Theora-patentenverhaal heet in normaal Nederlands "een enorm slappe smoes".
Als het zo'n slappe smoes is, waarom wil het bedrijf achter Theora er niet achter gaan staan en garanderen dat het geen patentproblemen zou opleveren? Sun deed dat wel met zaken die zij open source hebben gemaakt: Sun gaf de garantie dat er geen patentproblemen waren en mocht er toch een probleem zijn, dan zou Sun dit aanvechten.
en belangrijker nog dan aanvechten: Sun zou de klanten vrijwaren.
edit:
belangerijker uit klant perspectief, die zal het namelijk een worst wezen, als ie zelf maar niet aangeklaagd kan worden wegens patentinbreuk op z'n SUN hardware en software.
edit:
belangerijker uit klant perspectief, die zal het namelijk een worst wezen, als ie zelf maar niet aangeklaagd kan worden wegens patentinbreuk op z'n SUN hardware en software.
[Reactie gewijzigd door arjankoole op donderdag 20 mei 2010 11:13]
Tja, maar h.264 is niet patent en royalty vrij. Men kan en mag dus niet zomaar de codec meeleveren. Dat is ook de reden waarom Mozilla bijvoorbeeld deze codec niet ondersteund. Zij zouden enkele miljoenen per jaar moeten afdragen.Omdat h264 al lange tijd commercieel gebruikt wordt en daar erg veel grote bedrijven achter staan met veel patenten in deze business, is een soort van bewezen dat de kans erg klein is dat er nu nog eens patent-lijken uit de kast komen vallen.
Het bedrag is peanuts voor Mozilla. Het is iets van $5M/jaar, vorig jaar had Mozilla dacht ik $411M inkomsten...
Het probleem is dat er helemaal geen enkele garantie is dat WebM wel patentvrij is. Misschien maakt Google er wel geen aanspraak op, maar dat wil niet zeggen dat er geen andere partijen zijn die patenten hebben waar VP8 inbreuk op maakt.Tja, maar h.264 is niet patent en royalty vrij. Men kan en mag dus niet zomaar de codec meeleveren.
Het is een voordeel dat Google WebM wil gaan gebruiken, zodat zij een eventuele patentclaim zouden kunnen aanvechten. Google op zichzelf is echter veel minder invloedrijk dan de gehele groep bedrijven vertegenwoordigd in de MPEG-LA. Die hebben er een groot gezamenlijk belang bij dat 'outsiders' geen tot op heden onbekende patenten gaan claimen. Ik zou dus zelf meer vertrouwen hebben in de MPEG-LA dan in alleen Google als het om eventuele patentproblemen gaat, temeer daar de MPEG-LA veel meer belangen heeft bij het bestrijden van submarine patents dan Google.
Het zou me daaro verbazen als veel bedrijven dat risico wel willen nemen als er al een vrij zeker alternatief bestaat in de vorm van H.264, dat bovendien betere kwaliteit biedt en waar al veel ervaring mee is. Die paar euro's (relatief) licentiekosten voor H.264 zou ik als bedrijf voor lief nemen.
Wat wel mooi is, is dat de MPEG-LA zich nu zeker meerdere malen zal bedenken voordat ze besluiten de royalties eventueel te verhogen. H.264 concurreert nu immers wel met een gratis (zij het wat minder 'veilige') codec, en dat alternatief kan op zichzelf misschien al genoeg zijn om de beschikbaarheid van H.264 voor een redelijk bedrag te waarborgen.
Ondersteuning is maar een relatief begrip. IE9 zal straks wel VP8 ondersteunen als de codec al beschikbaar is in directshow maar Microsoft zal de codec zelf niet meeleveren zodat ze geen enkel risico lopen.Nu weet ik niet hoe uitvoerig Google de patenten rond VP8 onderzocht heeft, maar gezien de grote namen die nu al ondersteuning hebben toegezegd, denk ik dat ze best een goed verhaal hebben
Dat betekent dat Google zelf de codec zal moeten verspreiden en al het risico moet lopen. Een aparte actie want dan had Google ook wel h.264 codec zelf kunnen verspreiden. Dat kost ze een paar miljoen maar is verder dan bijna risicoloos.
En Opera heeft al een build met de nieuwe codec vrijgegeven, nu nog het beeldmateriaal, maar daar is Youtube al druk mee bezig. Dit word de toekomst 
http://labs.opera.com/news/2010/05/19/
EDITS:
De builds van Chrome konden natuurlijk niet uitblijven Toch wel, die builds komen 24 mei uit:
http://build.chromium.org/buildbot/snapshots/
Doe dan ook maar Firefox;
http://nightly.mozilla.org/webm/
Hier een korte uitleg om de codec te proberen:
WebM codec op youtube afspelen:
http://labs.opera.com/news/2010/05/19/
EDITS:
De builds van Chrome konden natuurlijk niet uitblijven Toch wel, die builds komen 24 mei uit:
http://build.chromium.org/buildbot/snapshots/
Doe dan ook maar Firefox;
http://nightly.mozilla.org/webm/
Hier een korte uitleg om de codec te proberen:
WebM codec op youtube afspelen:
- Search using the YouTube search
- On the URL for the search and “&webm=1&html5=1” and visit that URL.
- Click on a video.
- Add to the end of that video URL: &html5=1
- Enjoy WebM goodness.
- Right click in Firefox on the video to get fullscreen.
[Reactie gewijzigd door tweeny op woensdag 19 mei 2010 21:57]
Adobe doet ook mee met zijn Flash-plugin.
Heb je een open video-formaat en wat doe je er dan mee, afspelen dmv Flash...?
Heb je een open video-formaat en wat doe je er dan mee, afspelen dmv Flash...?
Dit is vooral handig als fallback-optie voor oudere browsers. Zou Adobe dit niet doen dan zou je serverside voorlopig minimaal twee codecs moeten ondersteunen, nu kan alles WebM
Afspelen met Flash in een browser die de video tag / webm niet ondersteunt of direct in de browser die het wel doet, wat is het verschil? Je zult de komende tien jaar toch met legacy issues zitten, en dan kan Adobe zich beter indekken door Flash deze codec te laten ondersteunen.
Voor Adobe is het een mooie besparende maatregel.
Tot nu toe gebruiken de meeste Flash video's de On2 VP6 codec waarvoor Adobe dik heeft moeten betalen...
Tot nu toe gebruiken de meeste Flash video's de On2 VP6 codec waarvoor Adobe dik heeft moeten betalen...
Mkv, Ogg Vorbis.
Ik kan dit alleen maar toejuichen. Ik ben een groot voorstander van Ogg Vorbis. Fantastische geluidskwaliteit vergeken met mp3 en royalty vrij.
Ik kan dit alleen maar toejuichen. Ik ben een groot voorstander van Ogg Vorbis. Fantastische geluidskwaliteit vergeken met mp3 en royalty vrij.
Vorbis is de duidelijk verbetering in dit nieuwsbericht. Dat is inderdaad een bdetere codec dan mp3 waar VP8 eigenlijk niet een betere codec is dan de h.264 codec die al gebruikt wordt.
Er zijn twee belangrijke problemen die dienen overwonnen te worden:
- hardwareacceleratie: zolang de meeste low-end pc's/telefoons/netbooks geen chip hebben die ontwikkeld is om WebM te decoderen, zal een algemene toepassing ervan uitblijven.
- bescherming van andersmanspatenten. Iedereen die H264 gebruikt zit in hetzelfde bootje. Als er ergens iemand een bedrijf wilt aanklagen, moet het opboksen tegen alle bedrijven tegelijk. Bij opensource kan elk individy die de codec gebruikt aangeklaagd worden. Bovendien bezitten de H264 aandeelhouders zelf een hele batterij aan patenten om eventueel mee terug te vechten. Dit is allemaal niet zo nobel maar het geeft wel zekerheid van rechtswege aan bedrijven die besluiten om in zee te gaan met H264.
- hardwareacceleratie: zolang de meeste low-end pc's/telefoons/netbooks geen chip hebben die ontwikkeld is om WebM te decoderen, zal een algemene toepassing ervan uitblijven.
- bescherming van andersmanspatenten. Iedereen die H264 gebruikt zit in hetzelfde bootje. Als er ergens iemand een bedrijf wilt aanklagen, moet het opboksen tegen alle bedrijven tegelijk. Bij opensource kan elk individy die de codec gebruikt aangeklaagd worden. Bovendien bezitten de H264 aandeelhouders zelf een hele batterij aan patenten om eventueel mee terug te vechten. Dit is allemaal niet zo nobel maar het geeft wel zekerheid van rechtswege aan bedrijven die besluiten om in zee te gaan met H264.
1. Daar zijn de hardwarepartners voor, denk aan Texas Instruments, Broadcom, AMD, nVidia, Qualcomm, ARM, MIPS.
2. Als het goed is beschermt de BSD licentie daar tegen.
2. Als het goed is beschermt de BSD licentie daar tegen.
Volgens http://www.webmproject.org/about/faq/ heeft Google daarom voor de BSD-achtige licentie gekozen ipv de Apache licentie (waaronder Android verschenen is).
Dus deze licentie geeft het recht om alle patenten waarop VP8 berust (en eigendom zijn van Google) te mogen gebruiken, in verband met deze codec.The main difference between the standard BSD license and the VP8 license is that this license grants patent rights, and terminates if patent litigation is filed alleging infringement of the code.
[Reactie gewijzigd door MrSnowflake op woensdag 19 mei 2010 21:50]
Dat klopt, maar in de VS kun je dan nog steeds worden aangeklaagd voor het gebruik ervan, ook al heb je een licentie van Google.
Als een derde partij vindt dat jij onterecht gebruik maakt van hun intellectuele eigendom, dan heb je een probleem.
Ik denk dat je dan echter wel een flink grote partij moet zijn, wil je je hier zorgen om maken, en het feit dat Microsoft er nu ook achter staat, zegt toch wel wat. Het kan echter ook zo zijn dat Google en Microsoft onderling een verklaring hebben waarin Google hen vrijwaart. In dat geval heeft Google straks eventueel een probleem, vooral als ze een rechtszaak hierover verliezen...
Als een derde partij vindt dat jij onterecht gebruik maakt van hun intellectuele eigendom, dan heb je een probleem.
Ik denk dat je dan echter wel een flink grote partij moet zijn, wil je je hier zorgen om maken, en het feit dat Microsoft er nu ook achter staat, zegt toch wel wat. Het kan echter ook zo zijn dat Google en Microsoft onderling een verklaring hebben waarin Google hen vrijwaart. In dat geval heeft Google straks eventueel een probleem, vooral als ze een rechtszaak hierover verliezen...
Als ik het goed lees staat hier:
je mag met de code doen wat je wil (bsd style)
maar als je besluit om een patent claim van infringement tegen de code uit te brengen (dus tegen WebM) mag je ze niet meer gebruiken.
dit vind ik wel een leuke uitbreiding tov de bsd license
beschermd wel niet zo heel veel meer tegen patent claims, aangezien er altijd een appart bedrijfje opgericht kan worden met als enige doel om een claim uit te brengen, en die de software niet gebruikt.
Maar ik vind het wel een leuk principe:
patent claimer:
Ik denk dat een stukje van die code van mij is, ik wil ook centjes.
google;
ah, we zullen zien, maar gij moet al nie meer meedoen gij.
je mag met de code doen wat je wil (bsd style)
maar als je besluit om een patent claim van infringement tegen de code uit te brengen (dus tegen WebM) mag je ze niet meer gebruiken.
dit vind ik wel een leuke uitbreiding tov de bsd license
beschermd wel niet zo heel veel meer tegen patent claims, aangezien er altijd een appart bedrijfje opgericht kan worden met als enige doel om een claim uit te brengen, en die de software niet gebruikt.
Maar ik vind het wel een leuk principe:
patent claimer:
Ik denk dat een stukje van die code van mij is, ik wil ook centjes.
google;
ah, we zullen zien, maar gij moet al nie meer meedoen gij.
Ik las precies hetzelfde eruit...
Maar dat zal niet helpen tegen patentclaims...
Het levert hoogstens op dat een bedrijf wat WebM zou willen leveren en een patent heeft, hierover zijn mond houdt, als echter het bedrijf het idee heeft dat ze meer zullen verdienen door geen WebM te hebben, maar wel aan te klagen, zullen ze dat dus gaan doen...
Maar dat zal niet helpen tegen patentclaims...
Het levert hoogstens op dat een bedrijf wat WebM zou willen leveren en een patent heeft, hierover zijn mond houdt, als echter het bedrijf het idee heeft dat ze meer zullen verdienen door geen WebM te hebben, maar wel aan te klagen, zullen ze dat dus gaan doen...
On2 had niet veel sterke patenten op hun codecs en die vrijheid van Google geeft eingelijk weinig bescherming. Maar zolang Google zelf de codec verspreid is dat geen probleem. Grote video sitesdie niet van Google zijn zullen echter wel iets meer zekerheid willen om VP8 toe te gaan passen.Dus deze licentie geeft het recht om alle patenten waarop VP8 berust (en eigendom zijn van Google) te mogen gebruiken, in verband met deze codec.
Als zoveel partijen in de markt h.264 liever kwijt dan rijk zijn snap ik niet waarom het door iedereen zo breed ingezet wordt? Waren er tot nu toe dan echt geen goede alternatieven?
Niet echt, Ogg Theora biedt geen goede kwaliteit en alle andere codecs die wel goede kwaliteit bieden zijn niet open.
Nee, eigenlijk niet. Er was alleen het Theora formaat, alleen dit schijnt technisch niet heel goed te zijn en nogal zwaar te decoderen, wat toepassing in embedded devices moeilijk zou maken.
Qua decoderen is theora niet zwaar. Minder zwaar dan h.264
Echter je hebt dubbel zo grote bestanden nodig om dezelfde video te hebben en dat is heel bezwaarlijk.
Echter je hebt dubbel zo grote bestanden nodig om dezelfde video te hebben en dat is heel bezwaarlijk.
h.264 is gewoon een hele goeie codec, het enige probleem is de licentie. Die weerhoud 'm ervan om de grote overkoepelende open standaard te worden.
Het alternatief was tot nu toe OGG Theora. Die heeft wel een open licentie, maar zit kwalitatief minder goed in elkaar. (de technische details weet ik verder ook niet).
Nu is er dus een alternatief dat qua kwaliteit kan concurreren met h.264, maar dat wel een open licentie heeft, en dus zonder bezwaar door iedere softwaremaker geïmplementeerd kan worden.
Het alternatief was tot nu toe OGG Theora. Die heeft wel een open licentie, maar zit kwalitatief minder goed in elkaar. (de technische details weet ik verder ook niet).
Nu is er dus een alternatief dat qua kwaliteit kan concurreren met h.264, maar dat wel een open licentie heeft, en dus zonder bezwaar door iedere softwaremaker geïmplementeerd kan worden.
Blijkbaar niet - heb je van een algemeen beschikbare codec gehoord dat goeie compressie en kwaliteit haalt bij HD video anders dan h.264? Ik heb zelf eigenlijk weinig daarover gehoord.
Maar een overzicht van de alternatieven zou wel handig zijn.
Faux edit: nVidia heeft het geprobeerd, Microsoft heeft er een gemaakt die tegenwoordig in Blu-rays gebruikt wordt, naast die van MPEG, en euh... dat was het wel voor zover ik kon vinden.
Er zijn een aantal HD codecs / videoformaten, maar blijkbaar maar twee die ook nog geschikt zijn voor het web - h.264, en deze dus.
Maar een overzicht van de alternatieven zou wel handig zijn.
Faux edit: nVidia heeft het geprobeerd, Microsoft heeft er een gemaakt die tegenwoordig in Blu-rays gebruikt wordt, naast die van MPEG, en euh... dat was het wel voor zover ik kon vinden.
Er zijn een aantal HD codecs / videoformaten, maar blijkbaar maar twee die ook nog geschikt zijn voor het web - h.264, en deze dus.
Wellicht interessant is de eerste, maar toch al zeer uitgebreide beoordeling van de specs op http://x264dev.multimedia.cx/?p=377#more-377
De codec lijkt qua implementatie enorm veel op h.264 en dat zou uiteindelijk het licentievrije karakter sterk kunnen aantasten.
Daarnaast lijkt de performance tussen xvid en vc1 in te zitten...
De codec lijkt qua implementatie enorm veel op h.264 en dat zou uiteindelijk het licentievrije karakter sterk kunnen aantasten.
Daarnaast lijkt de performance tussen xvid en vc1 in te zitten...
[Reactie gewijzigd door Maurice v/d Zwaan op woensdag 19 mei 2010 21:53]
Vergeet niet dat deze beoordeling niet 100% objectief is hè...
Ik denk dat we de komende dagen meer te weten komen. Mocht er nog een patentendreiging op de loer liggen, dan is het mogelijk dat dit pas na een tijdje duidelijk wordt, als de codec al volop in gebruik is...
Maargoed, de toezegging van grote partijen om gebruik te gaan maken van WebM is toch wel uitzonderlijk.
Ik denk dat we de komende dagen meer te weten komen. Mocht er nog een patentendreiging op de loer liggen, dan is het mogelijk dat dit pas na een tijdje duidelijk wordt, als de codec al volop in gebruik is...
Maargoed, de toezegging van grote partijen om gebruik te gaan maken van WebM is toch wel uitzonderlijk.
Misschien, maar het is in ieder geval een gedetailleerde technische analyse die eenvoudig te verifiëren is.Vergeet niet dat deze beoordeling niet 100% objectief is hè...
En als de conclusies kloppen dan belooft dat niet veel goeds voor WebM.
Goede link.
De performance in snelheid klinkt schokkend slecht namelijk nog langzamer dan h.264.
Dat is de compressie/kwalitetis performanceDaarnaast lijkt de performance tussen xvid en vc1 in te zitten...
De performance in snelheid klinkt schokkend slecht namelijk nog langzamer dan h.264.
In terms of decoding speed I’m not quite sure; the current implementation appears to be about 16% slower than ffmpeg’s H.264 decoder (and thus probably about 25-35% slower than state-of-the-art decoders like CoreAVC).
Op dit item kan niet meer gereageerd worden.
Populair: Asus Samsung Websites en communities Mobiele telefoons Laptops Sony Games Microsoft Consoles Microsoft Xbox One
© 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
