Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 75 reacties

Chris DiBona, opensource-manager bij Google, stelt dat de VP8-codec zeker niet onderdoet voor h.264. Ook zou de zoekgigant aan de codec, onderdeel van het vrij te gebruiken WebM-platform, blijven sleutelen om zo betere resultaten te behalen.

DiBona laat aan de Duitse website Golem.de weten dat hij zich niet kan vinden in de kritiek van x264-ontwikkelaar Jason Garrett-Glaser, die onder andere stelde dat de VP8-codec een minder goede videokwaliteit levert en dat Google bovendien niet aan patentclaims zou kunnen ontkomen.

Volgens DiBona hebben beide codecs zowel goede als slechte eigenschappen. Zo zou uit metingen van Google blijken dat VP8 in bepaalde gevallen vergelijkbaar of zelfs beter presteert dan h.264, maar hij geeft toe dat h.264 bij actiebeelden en animaties beter uit de bus kan komen. Toch zouden de kwaliteits- en efficiëntieverschillen beperkt blijven en voor het grote publiek vrijwel niet waarneembaar zijn. Google zou bovendien aan de VP8-codec blijven sleutelen.

DiBona vreest ook niet dat mogelijke licentiekwesties het gebruik van WebM in de weg zullen staan. Volgens de opensource-manager van Google zijn er enkele aanpassingen aan de licentie van WebM gedaan, waardoor de VP8-codec geheel opensource is. Eerder viel WebM nog onder een aangepaste BSD-licentie, die zou komen te vervallen zodra een patentzaak tegen Google zou worden aangespannen. Dit voorbehoud is uit de licentie verwijderd. Inmiddels zou WebM van een normale BSD-licentie zijn voorzien.

Moderatie-faq Wijzig weergave

Reacties (75)

Ook zou de zoekgigant aan de codec, onderdeel van het vrij te gebruiken WebM-platform, blijven sleutelen om zo betere resultaten te behalen.
Ik hoop niet dat dat gaat leiden tot een stroom va incompatibele versies waardoor het afspelen van zo'n VP8 filmpje net zo'n "belevenis" wordt als het proberen af te spelen van een avi met een ongebruikelijke xvid variant enkele jaren geleden.
De kwaliteit is voornamelijk afhankelijk van de encoder niet van decoder. Er zijn veel verschillen encoders voor MPEG-4 met verschillende kwaliteit (DivX, XviD, WMV, QuickTime, AVC, VC-1, H.264) , maar ze maken allemaal gewoon een standaard MPEG4 stream.

Een belangrijke stap in de encoder is het zoeken van blokjes van pixels uit een frame in het volgende frame. Als je deze blokjes kan terug vinden, kan je deze verplaatsen en hoef je weinig nieuwe blokjes toe te voegen, en krijg je dus hoge kwaliteit met een kleine bandbreedte. (http://en.wikipedia.org/wiki/Motion_compensation BMC)
Maar het voorspellen van de beweging van de objecten in de film dus de verplaatsing van de blokjes, is erg complex en cpu-expensive. Het zoekalgoritme bepaald dus voor een groot deel de kwaliteit van de encoder.

Angezien h.264 niet alleen een blokjes uit het vorige frame, maar ook uit een volgende frame gebruikt, kan deze gewoon vaker blokjes hergebruiken, en dus een hogere kwaliteit stream krijgen bij snelle beweging.

[Reactie gewijzigd door djexplo op 14 juni 2010 16:49]

Het wordt misschien wat technisch, maar H.264 gebruikt bijv. arithmetic coding (een techniek om via kansberekening een bepaalde eenheid aan gegevens zo effectief mogelijk op te slaan, eigenlijk een implementatie van de theorie van Shannon dat entropy (de onvoorspelbaarheid van informatie) uitgedrukt kan worden in een getal), terwijl de oudere MPEG4 varianten een andere encoding geimplementeerd hebben die voor een PC beter performd, maar waarbij de compressie slechter is.
Daarnaast heeft H.264 een eenvoudige implementatie van een type neuraal netwerk van Paq overgenomen. Dat neurale netwerk was een van de grootste redenen waardoor de Paq-serie van Matt Mahoney al jaren aan de top staat als sterkste compressie-algoritme.
Deze technieken waren al jaren bekend, maar pas de laatste jaren was het praktisch mogelijk om die op te nemen in een video-codec. Dit omdat de cpu's nu sterk genoeg zijn om zo'n codec realtime te tonen.

Overigens zijn er nog een aantal optimalisaties mogelijk waardoor er nog wat rek zit in de mogelijkheden om tot nog betere ratio's te komen. Je kunt dieper in de historie gan kijken dan voorheen mogelijk was, doordat het werkgeheugen is toegenomen. Daardoor kun je een betere voorspelling doen voor het toekomstige video-frame.
(Het is overigens een misverstand dat je de toekomstige frames zou kunnen gebruiken om het huidige video-frame beter te comprimeren. Die frames zijn voor de encoder wel bekend, maar voor de decoder niet! Die moet stapje voor stapje zo'n stream decoden.)
Je zou ook het neurale netwerk kunnen uitbreiden en meer algoritmes kunnen toevoegen die in speciale situaties intelligent kunnen reageren. Bij het uitzoemen of verschuiven van het beeld zou je bijvoorbeeld kunnen herkennen dat bepaalde delen hetzelfde blijven, al zit de oude pixel niet meer op dezelfde plek. Je kunt dat idee virtueel oneindig uitbreiden met algoritmes en het mooie van dat neurale netwerk is dat die wel dynamisch kan bepalen wie op welk moment nuttig is.
Het wordt misschien wat technisch, maar H.264 gebruikt bijv. arithmetic coding (een techniek om via kansberekening een bepaalde eenheid aan gegevens zo effectief mogelijk op te slaan
Om het nog maar wat technischer te maken: wat je zegt klopt ook niet helemaal. De vorm van arithmetic coding die door H264 gebruikt kan worden (variable length coding is overigens ook nog steeds mogelijk met H264), is niet gebaseerd op kansberekening, maar op frequentie en re-normalisatie. Met andere woorden: door te tellen welke symbolen hoe vaak worden gecodeerd, en deze statistieken on-the-go bij te werken. Er wordt dus nooit iets voorspeld, en er komt geen kansberekening bij kijken.
eigenlijk een implementatie van de theorie van Shannon dat entropy (de onvoorspelbaarheid van informatie) uitgedrukt kan worden in een getal)
Het tweede gedeelte van je opmerking klopt, het eerste deel is nogal nietszeggend omdat simpele variable-length coding (zoals bijvoorbeeld run-length coding, waarbij je niet 10,10,10,10 opslaat maar bijvoorbeeld -1,10,4) op precies dezelfde manier is gerelateerd aan de theorie van Shannon. In principe elke vorm van compressie is dat eigenlijk.
terwijl de oudere MPEG4 varianten een andere encoding geimplementeerd hebben die voor een PC beter performd, maar waarbij de compressie slechter is
Vergelijkbare encoding manieren zijn nog steeds ook onderdeel van de H264 specs, en in sommige profielen zelfs de enige optie (bijvoorbeeld de profielen die specifiek voor low-bitrate streaming video zijn), inderdaad vooral omdat arithmetic coding behoorlijk zwaar is en bepaalde profielen specifiek voor low-power devices bedoeld zijn.

Maargoed los van dit hele technische verhaal gaat dit alleen maar over het comprimeren van de bitstream, en dit is maar een relatief klein gedeelte van de efficientie van een encoder. Veruit de meeste winst valt te halen in het in de eerste plaats zoveel mogelijk beperken van die (ongecodeerde) bitstream, vooral door zoveel mogelijk redundatie uit het signaal te halen, en de data van je video-signaal op een andere manier te representeren, zodat je meer redundantie kunt creeeren zonder al te veel signaalverlies te introduceren.

Het verschil in de compressie van de bitstream tussen een complexe, zware encoding zoals CABAC (context-adaptive binary arithmetic coding) zoals gebruikt kan worden met H264, vergeleken met een veel envoudigere run-length encoding, is hooguit 10%. En dat is dan niet 10% op de ongecodeerde video, maar 10% op de bitstream na het encoden van de video. Dat is zeker niet waar H264 zijn grote winst haalt, de motion prediction (forward en backward tot ik geloof 4 frames), subpixel motion vectors, meer motion vectors per macroblock, en het veel uitgebreidere gebruik van slices (aaneengeschakelde macroblocks) maken echt veruit het grootste verschil.

Edit: @dj_tjerk:
Dat klopt inderdaad, een typische videocodec met zowel forward als backward-prediction kan doorgaans 3 verschillende 'frames' bevatten: I-frames, P-frames en B-frames, en deze frames worden samen gebundeld in een group-of-pictures (GOP), die typisch 1 I-frame plus een aantal P en/of B-frames bevat. De I-frame is grofweg gecodeerd als een JPEG-plaatje en heeft dus minimaal kwaliteitsverlies, het enige verlies aan kwaliteit komt uit de compressie van het plaatje, en er is geen kwaliteitsverlies door motion compensation. Een P (predicted) frame bevat een veld van motion vectors, die naar macroblokken in een vorig frame verwijzen, en slechts het verschil tussen het gewenste blok in het het P-frame met het frame waar naar wordt verwezen, wordt gecodeerd. Omdat dit verschil veel kleine waarden en veel 0-en bevat, is het heel efficient te coderen. Een B (bi-predicted) frame werkt hetzelfde maar kan zowel naar vorige als naar volgende frames verwijzen. De frames waarnaar verwezen wordt zijn trouwens altijd I- of P- frames, een predicted frame kan nooit naar een B-frame verwijzen.

Een typische GOP bevat zo rond de 15 frames en begint altijd met een I-frame, gevolgd door een aantal P-frames, gevolgd door een aantal B-frames De codeer volgorde hoeft niet hetzelfde te zijn als de display volgorde, en bij B-frames is dit per definitie niet zo. Een GOP die gecodeerd is als IPPPBBB, zou bijvoorbeeld heel goed als IBPBPBP kunnen worden weergegeven, waarmee de mogelijkheid van frames die naar toekomstige frames verwijzen is verklaard ;-)

[Reactie gewijzigd door johnbetonschaar op 15 juni 2010 16:06]

(Het is overigens een misverstand dat je de toekomstige frames zou kunnen gebruiken om het huidige video-frame beter te comprimeren. Die frames zijn voor de encoder wel bekend, maar voor de decoder niet! Die moet stapje voor stapje zo'n stream decoden.)
Niet helemaal correct denk ik, aangezien frames herordend worden en niet meer perse in afspeelvolgorde staan.
Er zijn veel verschillen encoders voor MPEG-4 met verschillende kwaliteit (DivX, XviD, WMV, QuickTime, AVC, VC-1, H.264) , maar ze maken allemaal gewoon een standaard MPEG4 stream.
Klok en klepel?

- DivX en XviD zijn en-/decoders voor MPEG4 boek 2.
- WMV definieert geen codec, er zijn vele generaties, meest populair is VC-1, confortmeert aan geen MPEG-standaard. Is wel een geldige codec voor het geflopte HDDVD.
- QuickTime definiteert geen codec, het is een framework vergelijkbaar met DirectShow.
- VC-1 hebben we het al even over gehad, veel WMV-bestanden bevatten VC-1.
- H.264 is een synoniem voor MPEG4 boek 10. Het is niet de naam van een en/-decoder.
- Een standaard MPEG4-stream bestaat niet. Veelgebruikt zijn MPEG-transportstreams, AVI-bestanden, .MP4-bestanden, Matroska-bestanden.

[Reactie gewijzigd door dmantione op 14 juni 2010 16:56]

AVC/H.264 is MPEG 4 part 10, DivX en XviD zijn implementaties van MPEG 4 part 2, specifiek ASP. Twee verschillende specificaties dus, niet allemaal een implementatie van hetzelfde. WMV/VC-1 staat los van MPEG 4, en QuickTime is tegenwoordig ook al geen eigen specificatie meer, maar een container en afspeelapplicatie wat tegenwoordig vooral H.264/AVC/MPEG 4 part 10 content draagt.

Een MPEG 4 stream is dan weer wat anders, maar de meeste content zoals uitgezonden zit in transport streams die we nog kennen uit MPEG 2 (ook al dragen ze een H.264/AVC/MPEG 4 part 10 videostream).

Conclusie: niet alles zomaar over een kam scheren :P.
Angezien h.264 niet alleen een blokjes uit het vorige frame, maar ook uit een volgende frame gebruikt, kan deze gewoon vaker blokjes hergebruiken, en dus een hogere kwaliteit stream krijgen bij snelle beweging.
Er zit 1 gat in je verhaal die ik niet kan volgen. Het hergebruiken van 'blokjes' kan alleen als het blokje in 2 frames voorkomt. Bij snelbewegende beelden zal dit veel minder snel het geval zijn. Op wat voor manier heeft het hergebruiken dan een positieve invloed op de kwaliteit bij snelbewegende beelden?
Dat lijkt me niet aangezien Google wil dat de VP8 codec decoder onderdeel van de browsers wordt. Mocht dat gebeuren, zal er bij een update van je browser hooguit een nieuwere versie van de codec worden meegeleverd.

Dat de codec open source is, was Google te doen om geen licentiekosten af te moeten staan voor het gebruik van andere codecs zoals de h.264 in hun browser.
Nee. Wat Google wil is 1 standaard op het web, en ik denk dat ze wel inzagen dat dat met proprietary codecs als h264 niet gaat lukken vanwege licentiekosten en andere beperkingen van zaken waar patenten op zitten. Buiten Mozilla lijken er niet veel browser makers mee te willen werken met Theora, dus dan heb je de 2 meest voor de hand liggende codecs al afgeschoten.
WebM is de makkelijkste oplossing voor iedereen: een codec die goed genoeg is om de anti-theora meute tevreden te houden en ook nog eens open source en licentievrij is.
H.264 is gewoon een open standaard hoor, niks proprietary aan.
Je kunt dat wel blijven zeggen maar dat helpt niet zo goed. In plaats daar van moet je die mening onderbouwen.

Er lijkt concensus te zijn dat iets dat niet patentvrij is niet echt open is. Zowel de definitie van Open Source als de meest gebruikte definities van Open Standaard stellen dit.
h.264 is niet patentvrij en daarmee volgens de meest gebruikte definities dus niet Open.
Voor h.264 dienen licentiegelden betaald te worden en dozals burne hierboven meld: Iedereen, de maker, de gebruiker, de bewerker, de fabrikant van camcorders moet betalen, zelfs al wordt bij het uiteindelijk formaat geen H.264 gebruikt.
Stel, jij neemt een filmje op met een camcorder die opneemt in H.264, je zet het op Youtube in VO8 formaat, moet je toch betalen, en Youtube ook, en degene die naar jouw flmje kijkt nogmaals. Dat is dus het schoolvoorbeeld van NIET-Open.

In Europa zijn die patenten niet geldig en kun je dus in principe prima x.264 oid gebruiken, maar voor de USA en Z.Korea geldt dat dus niet. Kortom, gewoon niet aan beginnen.

Als de patenten verlopen zijn, dus over zo'n 20 jaar kan het dan well (al zou ik dan zowiezo niet voor H.264 gaan maar voor ťťn van de vrije varianten (zoals x.264) maar tegen die tijd zijn er mischien wel al andere codecs die beter zijn, 3D ondersteunen of veel hogere resoluties (bv 90.000 bij 160.0000 picels voor schermen vanaf 90 bij 160 inch), is niemand meer geÔnteresseert in H.264 of VP8 en komt er opnieuw zo'n discussie over de nieuwe .
Dat de codec open source is, was Google te doen om geen licentiekosten af te moeten staan voor het gebruik van andere codecs zoals de h.264 in hun browser.
Erg ongeloofwaardig als je bedenkt dat Google 106 miljoen dollar voor On2 heeft betaald.
Alleen de rentevergoeding over dat bedrag is al bijna voldoende om de jaarlijkse h.264 licentiekosten te betalen.
Dan hebben ze de licentiekosten wellicht van de codec, maar is hij dan ook OpenSource?
Nee, en erger, de h.264-licentie is niet af te kopen, dus iedereen die iets doet met VP8, en daaronder valt ook h.264-video encoden of op je website plaatsen, moet apart een nieuwe licentieovereenkomst sluiten.

Dat is juist het probleem met h.264. Iedereen, de maker, de gebruiker, de bewerker, de fabrikant van camcorders, iedereen moet lappen voor h.264.
Met h.264 weet je nooit wat de toekomst brengt. Mensen die zeggen dat het wel mee zal vallen, zuigen dat gewoon uit hun dikke duim want dat weet je gewoon niet. Zodra die codec ingeburgerd is, begint het oogsten. Logisch dat ze eerst even wachten dat iedereen zich er aan opgehangen heeft. Dat kan voor opensource bedrijven zoals Mozilla de nekslag betekenen. Die hebben gewoon dat geld niet.

Daarom is het een verademing dat er nu een gelijkwaardig open source alternatief is. Verschillen in de marge zijn niet relevant. De hele wereld gebruikt ook MP3, heeft er iemand nog iets van MP3+ gehoord? Nee zelfs al compres je twee maal zo goed, dat is geen issue meer, standaardisatie is veel belangrijker. Daarom is het ook zo belangrijk dat H.264 niet de web standaard wordt, dan krijg je die niet zo maar weg.

Met de macht die Google er achter gooit, wordt VP8 niet alleen de webstandaard maar komt er ook snel hardware ondersteuning voor de codec. En Google heeft genoeg geld om de codec nog verder te ontwikkelen en oneffenheden glad te strijken.

Google heeft de wereld hiermee een grote dienst geleverd. Want video is een serieuze concurrent voor tekst aan het worden. Voor informatie over producten kijk je liever een kort fimpje dan een lap tekst door te lezen en het geeft je ook een directere ervaring.

Wat niet opgemerkt is maar toch belangrijk is, is dat Google het nu onder een normale BSD-licentie uitbrengt. Niet dat de eerdere Licentie Google speciale voordelen gaf, het was meer bedoeld als bescherming, maar er werd serieus gevreesd dat andere bedrijven ook zouden kunnen gebruik gaan maken van aangepaste BSD-licentie. Dan zou men binnen de korste keren door de bomen het bos niet meer kunnen zien, en nog niet weten waar men aan toe was. Juist het feit dat dit zo een belangrijke deal was voor de open source gemeenschap zou hen dwingen om een oogje dicht te knijpen waar ze dat juist beter niet zouden moeten doen. En daarmee is het hek van de dam. Het werd daarom erg belangrijk geacht dat de BSD-Licentie in haar oorspronkelijke vorm werd gehandhaafd.

En weer zien we dat Google oprecht de open source is toegedaan want zij heeft de BSD-licentie aangepast. Dat is een van dingen die ik erg aan Google als bedrijf kan waarderen, op kritiek wordt serieus gereageerd en zij probeert daar aan tegemoet te komen. Het maakt ook duidelijk dat Google streeft naar een warme lange termijn relatie met de open source gemeenschap en daar zal de mensheid als geheel van profiteren.
"De hele wereld gebruikt ook MP3, heeft er iemand nog iets van MP3+ gehoord?"
Wat ik niet zo goed begrijp is waarom niemand dan klaagt over de licenties die je moet betalen over het MP3 formaat.

Nu klaagt iedereen over h.264, maar MP3 is ook niet vrij kwa licenties.

Ik denk, in de toekomst zullen we het gewoon op meer standaarden houden, de video tag wordt dan net zo ondersteund als de img tag nu is. Maakt niet uit wat voor formaat je gebruikt, je browser speelt het wel af, precies zo als het nu met img gaat. Zonder plugin, want het wordt gewoon in je browser gecompileerd, of volgens een plugin zoals quicktime in safari op een mac, of media op een PC.

Voor Mozilla komt er dan uiteindelijk ook wel wat, alicht dat er een plugin komt die dan h.264 ondersteund.

Apple blijft het wel bij h.264, maar zal ook V8 gaan ondersteunen als het gemeen goed wordt, of zo besloten wordt tussen een paar heren in een bar in Silicon Valley. Windows krijgt wel een plugin, of MS zal het wel meeleveren.
Mozilla gat wel gebruiken maken van de beaschikbare formaten die beschijkbaar zijn in het OS. Iedereen tevreden! Maar het zal niet uitdraaien op een formaat!

Google is gebaat bij zo'n min-mogelijk bandbreedte, als V8 minder bandbreedte inneemt dan h.264, dan gebruiken ze dat. Als h.264 minder is in gebruik neemt, dan gaan ze dat wel gebruiken. Kost hun veel minder dan die licenties!

Ries
Mozilla komt niet met Mp3 support. Direct gevolg van de licentie gelden die de Fraunhofer-Gesellschaft daarvoor wil vangen.

OggVorbis aan de andere kant is geen probleem.
Er zijn plenty opensource h264 implementaties.
carbon, het is niet omdat een implementatie open source is dat deze vrij van licentiegelden is.
Nee, opensource betekend niet dat het product vrij van licentie gelden is.
Open source is dat je het kan aanpassen en dat dus de source er bij zit.
H.264 is ook opensource, maar je moet er wel een licentie voor hebben om er in bv. een webbrowser filmpjes mee af te spelen.
Die licentiekosten worden niet meer goedkoper, die zullen alleen maar duurder worden. Door eenmalig een eigen codec te kopen zijn ze daar voor de toekomst helemaal van af. Zelfs als Google toch nog een h264 licentie wil kopen hebben ze nu een stuk betere onderhandelingspositie.

Overigens gaat het niet alleen om Google zelf maar ook om alle klanten en gebruikers. Het is voor Google veel makkelijker als ze er op kunnen rekenen dat alle browsers VP8 ondersteunen dan dat ze verschillende codecs moeten ondersteunen voor verschillende browsers.

Voor fabrikanten van hardware kan dit ook heel interessant zijn. Nu betaal je een paar dollar per apparaat voor een H264 licentie. Als jij goedkope mediaspelers of telefoons levert dan zijn die paar dollar een belangrijk deel van de kostprijs. Als je die kosten kan vermijden zonder ondersteuning voor youtube op te geven kan dat best interessant zijn.
Dat de codec open source is, was Google te doen om geen licentiekosten af te moeten staan voor het gebruik van andere codecs zoals de h.264 in hun browser.

tot blijkt dat hun codec wel 1 of 2 patenten gebruikt die niet in handen van google zijn.
Bronnen? Dit is het eerste dat ik daar over hoor. Tot nu toe hoor ik dat er geen bevestigde patenten op rusten.
[...]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”. 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. It’s quite possible that VP8 has no patent issues, but until we get some hard evidence that VP8 is safe, I would be cautious. Since Google is not indemnifying users of VP8 from patent lawsuits, this is even more of a potential problem. Most importantly, Google has not released any justifications for why the various parts of VP8 do not violate patents, as Sun did with their OMS standard: such information would certainly cut down on speculation and make it more clear what their position actually is.
http://x264dev.multimedia.cx/?p=377

Inderdaad nog niet bevestigd, maar zeer aannemelijk.
jongens, zullen we al dit gezeik over codecs skippen en een manier vinden om de juiste codec van het web te downloaden zodra hij nodig is? dit kan bijvoorbeeld door middel van een universeel plugin formaat voor codecs + een tag waar je een download url in kwijt kan... dan is de browser maker niet meer verantwoordelijk voor licentie issues maar de aanbieder van de video. kunnen ze zelf kiezen welke ze beter vinden voor hun content, en of ze licenties hebben / het riskeren ze "illegaal" te distribueren.
Onveiligheid troef.

Een codec is een erg low-level component die vrij rechtstreeks met hardware zoals de videokaart en het geheugen praat. Die wil je dus echt niet automatisch laten downloaden op basis van een suffe URL in een tag! Hebben we niks geleerd van DirectX met zijn beveiligingsproblemen? Zo'n automatische codec download zou zo mogelijk nog veel linker zijn!
Men probeert het nu al: filmpje, meestal in het genre laatste bioscoopfilm of "bekende actrice" naakt, als je het afspeelt zie je een melding dat je op www.nogwat een codec moet downloaden om het af te spelen. Uiteraard haal je als je zo dom bent dat te doen alleen een virus en/of trojan binnen.
s/DirectX/ActiveX/
True, het had ActiveX moeten zijn...
Op zich een goed idee, maar dan zal je zien dat de aanbieder van dat video materiaal alleen een decoder voor Windows levert en dan zit alsnog een derde van de gebruikers zonder video...
En hoe moet dat dan op mobiele telefoons, OSsen die op non-X86-machines draaien, gameconsoles, settopboxen, tablets, fotolijstjes, ...? Ga jij alle mogelijke codecs naar al die platformen porten? Ik dacht het niet :) Het hele voordeel van een vastgestelde codec is juist dat je die kan implementeren en je unit HTML5-compatible kan noemen. In jouw idee zou je met een HTML5-compatible ding nog steeds niet alles kunnen afspelen; da's feitelijk een teruggang van het avi'tje-in-een-iframe wat je voor flash enzo had.
~_~ daar heb je een heel goed punt. maar wat als die plugin-based codec nou eens platform independent zou zijn, zoals java?
Goed plan, helaas werkt het vooral voor 'gratis' plugins. Het plan voorziet immers niet in een betaalmechanisme voor 'micro-betalingen' (zoals 50 eurocent o.i.d. aan de rechthebbenden, als die er geld voor willen zien zoals voor h.264).

Als men 'gratis herdistribueerbare codecs' maakt, kunnen gewoon al die codecs standaard in de browser opgenomen worden.
Goh, Google noemt zijn eigen codec beter.
Krijg toch een beetje een WC eend gevoel.

Toch zal ik 10x liever VP8 gebruiken dan H.264.
Het idee dat de makers van H.264 vanaf 2015 zomaar geld kunnen gaan vragen voor het gebruik staat mij echt niet aan.

Wat betreft het sleutelen...
Ik verwacht dat dat op dezelfde manier gaat als nu veel codecs.
De films met de nieuwe codec zullen compatible zijn met de oude decoder.
Maar mits een nieuwe decoders gebruikt wordt die de nieuwe functies ondersteund is de kwaliteit wel beter.

[Reactie gewijzigd door itarix op 14 juni 2010 16:21]

Het is nu juist Google niet een keer die haar eigen product de hemel in prijst.
Het is juist een van de makers van H.264 die op een zeer kinderachtige manier zonder veel onderbouwing met modder probeert te gooien.
Op ander site hebben ze tenminste de moeite genomen om beide codes uitvoerig naast elkaar te zetten.

Persoonlijk denk ik dat ik niet het verschil zal zien bij bewegende beelden....
Heb je de blog van die x264 ontwikkelaar gelezen?
Ik zie echt niet in wat er zeer kinderachtig, zonder veel ervaring en moddergooiend aan zou zijn.

Hij analyseert tenminste de theoretische kant van het verhaal en niet enkel een paar framepjes, als het theoretisch niet beter is dan x264 dan zal het dat in praktijk ook niet zijn.

Er wordt hier niet eens gezegd met welk profile van h264 er vergeleken werd. Als er vergeleken werd met baseline h264 kan het best kloppen dat ze vergelijkbare kwaliteit halen, maar dan moet je niet gaan beweren dat VP8 ook maar enigszins vergelijkbaar is met h264.
even een kleine correctie, het was niet de maker van H.264 maar de maker van x264
Het idee dat de makers van H.264 vanaf 2015 zomaar geld kunnen gaan vragen voor het gebruik staat mij echt niet aan.
Inderdaad, geld vragen voor het gebruik van je product, het moet niet gekker worden :P
Het moet toch niet gekker worden dat als je een camera koopt van €2000 euro koopt dat je geeneens plaatjes mag schieten voor commerciele doeleinden, maar ze dit wel 'vergeten' te zeggen bij je aankoop. Dus eerst lekker een userbase opbouwen en dan uitzuigen.
Hier hebben ze het gelukkig wel gezegd bij aankoop ;)
Inderdaad en daarom roepen veel mensen ook: "Nee bedankt, liever geen h.264!"

Ergste is nog dat het niet duidelijk is of/hoeveel het gaat kosten in de toekomst. Bedenk dat we nu al 10 jaar doen met HTML4 en nog veel langer met standaarden als JPG.

En denk bijvoorbeeld eens terug aan het drama met .GIF, waar patenten op bleken te rusten die men ineens ging exploiteren. Ineens mochten alle grote bedrijven die iets met .gif deden lekker gaan betalen. Dat terwijl .gif al helemaal was ingeburgerd op het web. Lekker verhaal. Hetzelfde wil men dus niet nog eens en zeker niet in een nieuwe standaard die waarschijnlijk pas in 2011 of 2012 final word terwijl de toekomst van h.264 vanaf 2015 onzeker is.
de filosofie die schuil gaat achter dit protocol is compleet anders dan de insteek van VP8. Het commerciele aspect botst natuurlijk met het open standaard voor html5
Het commerciele aspect botst natuurlijk met het open standaard voor html5
h.264 is een open standaard! Open impliceert niet automatisch dat het ook gratis is.

[Reactie gewijzigd door Carbon op 14 juni 2010 16:37]

h.264 is idd open, maar himlims heeft wel gelijk. Het feit dat er patenten achter zitten gaat in tegen de open, vrije filosofie van het w3c en de html standaarden. In de eerste drafts van html5 was gekozen voor theora. Nadat de kwaliteit ondermaats werd bevonden werd de bepaling aangepast in het volgende:
It would be helpful for interoperability if all browsers could support the same codecs. However, there are no known codecs that satisfy all the current players: we need a codec that is known to not require per-unit or per-distributor licensing, that is compatible with the open source development model, that is of sufficient quality as to be usable, and that is not an additional submarine patent risk for large companies. This is an ongoing issue and this section will be updated once more information is available.
h.264 voldoet niet aan de vereisten aangezien er een licentie aan vast hangt en zal dus waarschijnlijk niet opgenomen worden in de html5 standaard. VP8 kan hier wel aan voldoen eenmaal duidelijk is geworden dat er geen patentclaims boven het hoofd van Google of de gebruikers hangen.
Ja, maar toch voornamelijk nee.

Het is een beetje afhankelijk welke definitie van Open Standaard je gebruikt. Als je de definitie van Open Standaard gebruikt die het meest analoog is aan Open Source dan is h.264 geen Open Standaard, want je moet betalen voor het implementeren en gebruik van de standaard (maar het inkijken van de standaard is wel toegankelijk voor iedereen).

Maar volgens bijna geen enkele definitie van Open Standaard is h.264 er een, want de meeste definities gaan uit van een royalty free standaard, en h.264 is alles behalve royalty free.

Zie wikipedia voor verschillende definities va Open Standaard: http://en.wikipedia.org/wiki/Open_standard

Over het algemeen heeft men het bij Open Standaard over de definitie volgens Bruce Perens of de definitie van OSI.

[Reactie gewijzigd door elmuerte op 14 juni 2010 16:58]

Zoals al gezegd,
Voor h.264 worden geen gratis patentlicenties verstrekt,
verstrekte patentlicenties zijn vziw niet eeuwigdurend,
gebruik van de standaard is niet gratis,
h.264 is niet her-licenseerbaar door derden,
het is niet mogelijk delen ervan te gebruiken voor een nieuwe standaard.

Het is dus een publieke standaard die voor een groot deel open is.
h.264 is een open standaard! Open impliceert niet automatisch dat het ook gratis is.
De term 'Open' misschien niet per se, maar 'Open Source' impliceert wel degelijk dat het gratis is. Zie ook mijn blog over dit onderwerp:
http://opensourcefacts.wo...-source-is-free-software/

En verder over de patent dreiging: Hoewel het een beetje een theoretisch verhaal is is het mogelijk dat men in 2015 ineens een miljoen dollar per minuut encoding gaat vragen...Onbetaalbaar dus. Dus hoe open is iets nu werkelijk als de deur vanaf 2015 elk moment keihard in je gezicht dicht gegooid kan gaan worden? Vind je het gek dat veel mensen liever niet zien dat video-op-het-web volledig gebaseerd word op een standaard waarbij zo'n enorme adder onder het gras zit?

Als de mensen achter h.264 duidelijkheid willen scheppen moeten ze gewoon een officiŽle vrijwaring van betalingsplicht geven voor vanaf 2015... of op zijn minst alvast de prijslijst online zetten. Maar om nu alle techniek te gaan baseren op iets waarvan je niet weet of/hoeveel het gaat kosten? Daartegen zeggen veel mensen (terecht imho) "bedankt, maar nee dank u".
Er zou wat mij betreft wel iets meer zekerheid mogen komen over de lange termijn kosten. Het is niet echt triviaal om over te stappen naar een andere codec.
Ach het is een reactie op een WC eend reactie van een H.264 ontwikkelaar :P
(nieuws: X264-ontwikkelaar vindt VP8 onder meer buggy en langzaam)

Ik vind hem zelfs nog een beetje aan de late kant om eerlijk te zijn

[Reactie gewijzigd door Mellow Jack op 14 juni 2010 16:24]

Ik lees steeds vaker over "wij van WC eend".. waar komt dit vandaan en wat betekent dit precies?
haha das gewoon van een oude wc-eend reclame waar ze dat letterlijk zeiden.
Ja das nogal wiedes he dat de makers van wc-eend, wc-eend aanraden als je vraagt, welk product moet ik gebruiken, ze willen hun product toch verkopen?
Maar verder zonder enige onderbouwende motivatie erbij...
Kortom, elk merk raad zijn eigen producten aan
Ooit toen jij schijnbaar even een paar jaar geen TV keek of misschien nog te jong was om het verhaal te snappen was er een schoonmaak middelen fabrikant genaamd WC eend. Die een nog al ludieke reclame maakte: linkje

Met als resultaat dat veel mensen een onderzoek uitgevoerd door het bedrijf dat als beste uit de test komt nog al vaak een WC eend onderzoek nomen. Met andere worden een niet geheel onafhankelijk onderzoek.
Ik lees steeds vaker over "wij van WC eend".. waar komt dit vandaan en wat betekent dit precies?
Ik begin me nu toch echt wel oud te voelen op mijn 29e 8)7
zoek het even op op youtube, zo gevonden:
http://www.youtube.com/watch?v=YsvHeLUOoxs
Vroeger hadje reclames van WC-eend (een toiletreiniger) waarin letterlijk werd verteld dat zij aan iedereen WC-eend aanraadden. Nogal logisch maar door de manier waarop dit letterlijk werd gezegd is dit bij veel mensen blijven hangen.
op tweakers iig, op andere fora heb ik dit niet gezien...
De h264 codec heeft zich bewezen. Dat VP8 niet onder doet kan wel kloppen maar het blijft een nieuwe codec. Waarom ineens daar vanaf wijken? Wat doet VP8 zoveel beter dan h264?
Wat doet VP8 zoveel beter dan h264?
Vrij zijn van licentiegelden en toepasbaar zijn in open source software (wat met h.264 niet bij alle licenties het geval is).

[Reactie gewijzigd door Ook al Bezet op 14 juni 2010 17:09]

En daar gaat het ook om. Zie ook de grote "videotape oorlog" (http://en.wikipedia.org/wiki/Videotape_format_war). Een beter formaat hoeft nog nieuwe standaard te worden als er een ander formaat al masaal gebruikt wordt.
Blijkbaar heeft VP8 minder bandbreedte nodig dan h.264, anders was Google het niet gaan gebruiken voor Youtube. Bepaalde netwerkboeren dringen er immers op aan dat Google moet gaan betalen voor de bandbreedte die haar consumenten verstoken.

Tevens zijn de h.264 licentie-voorwaarden ook veel complexer dan die van VP8, en is er geen 'legale' onduidelijkheid over de open-bron versie van de VP8 codec, die onduidelijkheid is er wel over de 'open h.264 codec' (ffmpeg).
@allen: bedankt. De licentiegelden zijn wel vervelend ja. Maar goed. Dan gaat dalijk de format war hierover en gaat men elkaars codecs verbieden op de respectievelijke systemen. Dat zou niet goed zijn.
VP8 is geen nieuwe codec, deze is zelfs ouder dan h.264. VP8 doet niets beter dan h.264 maar heeft als voordeel dat er geen licentierechten voor afgedragen moeten worden. Als bijvoorbeeld Mozilla de h.264 codec wenst te verdelen met Firefox dan moet het ik dacht 4 tot 5 miljoen dollar per jaar aan de mpeg betalen.
Ik heb sowieso het idee dat het niet veel mooier kan dan h.264. Elke keer sla ik ervan achterover hoe mooi het is vergeleken met andere codecs.
Ik heb sowieso het idee dat het niet veel mooier kan dan h.264.
Het kan zeker wel aesthetisch mooier, veel mooier zelfs. Al die block artifacts die je ook bij h.264 overhoudt zijn vrij irritant.

Maar ja.. lossless comprimeren kost een hoop meer bandbreedte / opslag.. dus technisch is h.264 (en VP8) natuurlijk wel mooier.
Tuurlijk, maar met een mooie bitrate zoals Blu-Ray ziet het er voor mij perfect uit hoor.
"Google gaat blijven sleutelen"

Dit is de doodsteek van VP8. De "standaard" van VP8 is hetgeen google zegt dat het is. Ze hebben aangegeven om de standaard aan te passen. Bij h264 zijn er het tenminste alle grote spelers die samen beslissen of er aanpassingen komen. Bij VP8 is dat alleen Google en als Google de standaard aanpast, dan mag dat nog zo open zijn als je wilt, je zult en moet volgen.

Niemand wilt geconfronteerd worden met dat van de ťne op de andere dag youtube niet meer werkt omdat Google er wat aan gesleuteld heeft.
Als er bovendien fouten blijken te zitten in VP8 (volgens die kerel van x264 is dit zo) dan is het ook alleen maar Google die beslist of en wanneer die fouten worden hersteld ondanks het open karakter ervan.
Heb de blog van google niet gelezen maar hebben ze gezegd dat ze de standaard gaan aanpassen of hebben ze alleen gezegd dat ze de encoder die de bitstream moet maken blijven verbeteren?
Goh dus bij actiebeelden en animaties is het minder? Zeg maar hetgeen waar het om gaat, want bij stilstaande of langzaam bewegende beelden doen alle codecs het wel prima.

Daarnaast kunnen ze er best een leuke licentie op gooien, maar als blijkt dat VP8 patenten van h264 schendt (en dat beweerde iemand van die h264 club laatst) dan zit je alsnog met de gebakken peren.

Ik zie dat hele VP8 niet zo zitten...

[Reactie gewijzigd door Vizzie op 15 juni 2010 06:05]

Goh dus bij actiebeelden en animaties is het minder? Zeg maar hetgeen waar het om gaat, want stilstaande of langzaam bewegende beelden doen alle codecs het wel prima.
Vergeet ook de daaropvolgende zin niet.
Toch zouden de kwaliteits- en efficiŽntieverschillen beperkt blijven en voor het grote publiek vrijwel niet waarneembaar zijn. Google zou bovendien aan de VP8-codec blijven sleutelen.
De meeste mensen bekijken hun youtube fimpje niet beeldje voor beeldje onder een loep.
Maar goed, je kunt het natuurlijk ook gewoon zelf beoordelen http://www.youtube.com/watch?v=rLxQiI8c1Bs (aangenomen dat je een browser gebruikt die webm ondersteunt)
Daarnaast kunnen ze er best een leuke licentie op gooien, maar als blijkt dat VP8 patenten van h264 schendt (en dat beweerde iemand van die h264 club laatst) dan zit je alsnog met de gebakken peren.
Er wordt wel meer beweerd in de wereld van patenten. MS beweert al jaren dat Linux inbreuk maakt op patenten van MS maar heeft dat nog nooit hard weten te maken, ze hebben zelfs nooit willen zeggen om welke patenten het gaat. SCO... wel, moet ik nog meer zeggen?
Trouwens, ook met h.264 kun je over een paar jaar met de gebakken peren zitten als ze opeens besluiten dat iedereen die filmpjes in hun formaat op het web heeft staan moet gaan dokken.

[Reactie gewijzigd door Ook al Bezet op 14 juni 2010 21:16]

tja allkeen jammer dat h.264 nu een ''standaard'''is en zelfs alo in hardware gebruikt word geloof niet dat het een goed idee is om nog meer codecs uit te gaan vinden
"tja alleen jammer dat MPEG-2 nu een standaard is en zelfs al in hardware gebruikt word geloof niet dat het een goed idee is om nog meer codecs uit te gaan vinden" - zou ook maar zo een citaat kunnen zijn ~2 jaar nadat DVD duidelijk ingeburgerd was.

Er is altijd ruimte voor 'weer een codec', zolang deze maar meerwaarde heeft.
VP8 zou als meerwaarde bijvoorbeeld het gebrek aan patentclaims / licentiegelden kunnen hebben. Zoals hierboven al aangegeven... als jouw videocamera in h.264 opslaat, jij er een filmpje mee schiet, en deze commercieel aanbiedt.. dan kŠn het zo zijn dat de MPEG-LA bij jou aan komt kloppen om licentiegelden aan hen af te dragen. Het zal (vrijwel) niet gebeuren - maar dat het ueberhaupt al zo vastgelegd is zou je toch tot denken moeten zetten. Sowieso zitten hardware en software vendors vast aan het licentiegelden verhaal bij gebruik van h.264.
De grootste hardware fabrikanten (Intel, AMD, NVidia) hebben al aangegeven dat ze VP8 steunen; met die hardware support komt het wel goed.

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True