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. Je kunt ook een cookievrije versie van de website bezoeken met minder functionaliteit. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , reacties: 45, views: 19.967 •

Google is bezig de ontwikkeling van de VP9-videocodec af te ronden en op 17 juni zal er een specificatie-freeze plaatsvinden. Vanaf die datum kan Chrome de codec ondersteunen en ook YouTube zal met VP9 gaan werken, zo maakt Google bekend.

Google hield vorige week een bijeenkomst over VP9, het WebM-project voor een nieuwe generatie van de open videocodec. "We waren vooral blij onze vrienden van YouTube te verwelkomen, die het over hun plannen om VP9 te gaan ondersteunen hadden, zodra Chrome ondersteuning krijgt", zegt Matt Frost, productmanager bij het WebM-project. Vanaf 17 juni worden er geen wijzigingen in de code meer doorgevoerd en op die datum zal een check plaatsvinden voor ondersteuning van Chrome en YouTube, blijkt uit de planning van het WebM-project.

De WebM-container zal uitgebreid worden met ondersteuning voor VP9-streams, maar ook zal ondersteuning voor audiostreams op basis van het lossy compressieformaat Opus, ontwikkeld door de Internet Engineering Task Force, toegevoegd worden. VP9 zorgt voor efficiëntere compressie dan VP8, de videocodec die Google twee jaar geleden introduceerde. Doel is om de bitrate met 50 procent te verlagen ten opzichte van VP8 met behoud van dezelfde videokwaliteit.

VP8 is nog geen gemeengoed, in tegenstelling tot het concurrerende h.264. Het voordeel van VP8 en VP9 ten opzichte van h.264 en opvolger h.265 zou zijn dat geen royalties afgedragen hoeven te worden. Nokia claimt echter dat VP8 inbreuk maakt op patenten van het bedrijf.

Reacties (45)

Dat krijg je als een grote website en een browser met een groot marktaandeel dezelfde eigenaar hebben. Ze pushen door wat ze willen. Het maakt hen daarbij weinig uit wat de anderen er over denken.
Zolang ze alleen ondersteuning toevoegen in plaats van vervangen, lijkt me dat toch niet erg en alleen maar een goede zaak?
Daarnaast is VP9 een doortontwikkeling van VP8 met (alleen maar) voordelen, dus deze ontwikkeling is sowieso in "ieders" voordeel.
Naja, het gevaar zou zijn als ze het een gesloten en betaald formaat zouden maken en daarna de ondersteuning voor de gangbare formaten zouden laten vallen. Gelukkig is dat nu niet het geval met VP9.

En nog @biglia: weet je wat de hele browser revolutie op gang zette? Dat was namelijk niet mozilla (al waren die ook zeer goed bezig met spidermonkey op dat moment), maar google die betere browsers voor z'n producten nodig had en dus maar besloot dat ze zelf een speler moesten worden. En dat heeft er voor gezorgd dat alle browser een stuk beter zijn geworden. Maja, krijgt chrome een te groot marktaandeel dan kan het een ander verhaal worden, maar tot dat moment zit het allemaal nog super goed :D .
Zolang ze alleen ondersteuning toevoegen in plaats van vervangen,
Idd, je bedoeld toch zoals Microsoft destijds ook deed met IE6? Iedereen is nog steeds blij met de eigen 'toevoegingen' van IE6. Google doet precies hetzelfde als Microsoft destijds deed, zaken toevoegen die buiten de standaard vallen.
met dat verschil dat iedereen deze codecs rechtenvrij mag implementeren...
Dat is dus nog lang niet zeker. Nokia denkt daar in ieder geval anders over, dus reken maar op een rechtzaak.
Dat is dus nog lang niet zeker. Nokia denkt daar in ieder geval anders over, dus reken maar op een rechtzaak.
De mafia organisatie achter H264 geeft Google gelijk.
Ik denk dat ontwikkeling in een nieuwe videcodec als positief kan aanzien worden. Een verandering die ik maar al te graag gepushed zie worden.

Ik zou wel eens een vergelijking tussen VP9 en H.264 willen zien. Zijn deze 2 codecs nu aan elkaar gewaagd of is ťťn van de twee superieur ?
Volgens mij was VP9 toch een soort-van-kloon van H264 puur om van de licenties af te komen?
op dit moment is h.264 kwalitatief een stuk beter (bij dezelfde bitrate) dan vp8, en je moet vp9 vergelijken met h.265 aangezien dat de opvolger is... uiteindelijk is het maar wat jij goed genoeg vindt, zelf heb ik liever goede kwaliteit video, en dat dan een hogere bitraye nodig is, so be it.
H.264 High Profile werd dan ook vergeleken (dit is wat er op blurays gebruikt wordt). Als je het vergelijkt met Baseline/Main Profile dan is VP8 wel gewaagd aan H.264. Mobiele devices ondersteunen High Profile vaak niet.

http://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Profiles

Als webformaat vind ik VP8 wel redelijk geslaagd. VP9 en H265 moet ik nog zien...
op dit moment is h.264 kwalitatief een stuk beter (bij dezelfde bitrate) dan vp8, en je moet vp9 vergelijken met h.265 aangezien dat de opvolger is... uiteindelijk is het maar wat jij goed genoeg vindt, zelf heb ik liever goede kwaliteit video, en dat dan een hogere bitraye nodig is, so be it.
Elke codec kan met een hogere bitrate meer kwaliteit bieden. En heb je een referentie voor je claim dat h264 _veel_ beter is dan vp8? In het begin was er namelijk nog een zichtbaar verschil maar dat is al een aardige tijd geleden opgelost.
Zoals SuperDre inderdaad al aangeeft, VP9 is beter te vergelijken met h.265. En ja, dezen zijn beiden superieur aan h.264.
Het is maar zeer de vraag of VP9 beter is als h.264.
In de vergelijklingen die ik heb gezien waar VP9 wel beter deed dan h.264 maar minder dan h.265 was er toch flink gesjoemeld door de video met h.264 een veel groter aantal A/B-frames te geven die relatief veel opslag vragen. VP9 vergelijkingen van Xiph en/of Google bevatten hoogstens 1 A-frame per seconde (kent geen b-frames) terwijl ze vaak vergelijken met video's met veel met meer A/B-frames.

Nou is het niet erg om maar 1 A-frame per seconde te hebben maar doe dat dan wel in allebei de te vergelijken video's.

Zeker is dat VP9 nog aanzienlijk achterligt bij h.265.

[Reactie gewijzigd door hAl op 11 mei 2013 19:10]

a-frames
Ik werk echt al jaren in deze sector, en ik heb werkelijk nog nooit van een A-frame gehoord. Ik ben echt bijzonder benieuwd wat volgens jou een A-frame is. FYI, B staat voor bidirectional (of bi-predicted), in tegenstelling tot P (predicted) of I (independent of intra-coded). Zie bv. wikipedia.
flink gesjoemeld
De vergelijkingen tussen vp9 en h264 zijn gedaan via de bijzonder standaard settings (voor x264): --tune psnr (als psnr als metric wordt gebruikt) --profile high --pass 1/2 --preset veryslow, dat zijn de aanbevolen settings en de x264 developers zijn het daarmee eens (zie #x264-devel logs voor discussies tussen vp9 en x264 devs daarover). Het feit dat vp9 (via standaard best quality 2-pass settings, zie WebM wiki) 50% kleinere bestanden voor dezelfde kwaliteit (of enorm veel hogere kwaliteit voor dezelfde bitrate) genereert, is volledig verwacht en is niet verrassend, niet voor de x264 developers en niet voor de vp9 developers. Op bepaald materiaal (bv. parkjoy) doet x264 het bijna net zo goed als vp9 en hevc, en dat is wederom niet bepaald verrassend (als je wilt, kan ik ook uitleggen waarom).
door de video met h.264 een veel groter aantal A/B-frames te geven die relatief veel opslag vragen
Ik geloof dat je in de war bent met de VP8/H264 MTI (mandatory-to-implement) codec discussie in webRTC (real-time communication, i.e. videochat in de browser). Daar werden in de tests door het ene team wel en door het andere team niet B-frames voor H264 ingeschakeld. De reden dat het VP8 team ze niet inschakelden is omdat B-frames delay betekenen (omdat je eerst een future P-frame moet encoden), wat dus latency (vertraging) betekent, wat over het algemeen als onacceptabel wordt beschouwd voor RTC doeleinden. Het gebruiken van B-frames in een RTC codec test was daarom ook nogal vreemd. Er waren nog wel meer vreemde dingen aan de gang in die codec-vergelijking.

Maar al dat heeft niks met VP9 te maken.
(kent geen b-frames)
VP9 kent geen B-frames, maar kent wel degelijk bi-directional prediction of non-linear (alt-ref) frame encoding (in vp9 kan een alt-ref patroon ook recursive zijn), wat samen voor vergelijkbare doeleinden kan worden gebruikt als B-frames (maar ook voor volledig andere dingen).
Zeker is dat VP9 nog aanzienlijk achterligt bij h.265.
Dit vind ik een grappige opmerking, wat er bestaan nog geen commerciele (of free software) hevc encoders waarvan de licentie je toestaat ze in vergelijkende tests te gebruiken. De enige encoder die momenteel op die manier ""bruikbaar"" is (expres tussen aanhalingstekens), is de reference model ("HM"), welke in de richting van de 10 frames (1080p) per uur kan encoden (zie bv. rant hierover dan een van de x264 developers), m.a.w. enorm praktisch bruikbare software voor HD video encoding. Vergeleken met die reference model implementatie (zie dat als een exhaustive search implementatie van de hevc specificatie), staat libvpx (een echte encoder die al in Youtube is geintegreerd) vrijwel gelijk. ik ben - net als vele anderen - benieuwd naar echte vergelijkingen tussen vp9 en non-exhaustive implementaties van hevc (die dus sneller zullen zijn, maar niet noodzakelijkerwijs even goede resultaten zullen geven), maar om nu al te claimen dat vp9 ver achterligt t.o.v. h265 is ... bijzonder twijfelachtig. Niet in de laatste plaats omdat encoders voor beide formaten de komende jaren nog enorm onder ontwikkeling zullen zijn (inclusief kwaliteits-verbeteringen), iets wat voor H264 al jaren niet meer het geval is (voorbeeld: x264 --profile high --preset veryslow --pass 1/2 --tune psnr (met psnr als kwaliteits-metric) van januari 2013 is sneller dan van januari 2012, maar kwaliteit is hetzelfde).
Ach:

1.je hebt er geen last van.
2. er is nog redelijk wat concurrentie in die markt, je wordt dus niet gedwongen een browser te gebruiken met brede ondersteuning voor allerlei formaten
Ondernemingen met een economische machtspositie (EMP) mogen die positie niet misbruiken, en om goede redenen. Dat leidt namelijk tot vermindering van de concurrentie. Ik geloof niet dat dit hier het geval is.

Er is pas sprake van EMP als een onderneming zich onafhankelijk van concurrenten, eindgebruikers en leveranciers kan gedragen. Een eerste indicatie voor een dergelijke positie is het marktaandeel. Voor zover ik mij kan herinneren is het marktaandeel van Chrome in de browsermarkt niet zodanig dat er aanleiding is om aan te nemen dat het hier een gevaar is. Ook uit het marktaandeel van YouTube kan waarschijnlijk niet direct de conclusie getrokken worden dat er sprake is van EMP. Hoewel ongetwijfeld de populairste videosharing website zijn er heel veel concurrenten die hun dienstverlening kunnen volhouden op een vergelijkbaar niveau.

Ik denk dus dat op de twee bovenliggende markten voor browsers en videosharing een machtspositie is die Google kan misbruiken. Stel dat het wel zo zou zijn (bijvoorbeeld omdat Google een marktaandeel van 80% heeft op beide markten), dan nog kun je je afvragen of het ondersteunen van een eigen codec wel misbruik oplevert. Het is waar dat die codec onderdeel is van een onderliggende markt, maar het is niet zo dat Google de ondersteuning van andere codecs beŽindigd ten faveure van haar eigen codec. Er is interoperabiliteit met een hele hoop andere standaarden.

Het ondersteunen van meer codecs voert de concurrentie druk op andere codecs juist op, wat leidt tot een prikkel voor alle makers van codecs om te blijven innoveren. Ik denk dat je hier juist kan spreken van een situatie die de concurrentie bevordert.

Dat een bedrijf als Google doet wat ze wil, is haar goed recht. Zolang ze geen misbruik maakt van haar positie kan zij haar eigendomsrechten uitoefenen zoals haar dat zint. Gaat ze te ver (zoals bijvoorbeeld de zaak die in behandeling is bij de Europese Commissie, waar waarscijnlijk remedies worden opgelegd voor zoekresultaten) dan is ingrijpen gerechtvaardigd.

N.B. Even opgezocht: YouTube had een marktaandeel fluctueert tussen de 32,5% en 55% (bron). Dat is lang niet voldoende om EMP aan te nemen. In dat geval moeten er andere factoren in de markt spelen die aanleiding voor die conclusie geven. Bij dergelijke diensten wordt juist aangenomen dat er sprake is van economische dynamica waardoor groot aandeel juist niet leidt tot EMP, zoals bijvoorbeeld lage instap- en uittredingsdrempels

Chrome's marktaandeel blijkt nog veel lager, namelijk iets meer dan 16%(bron).
Google biedt vrije en gratis encoders, decoders en chip-ontwerpen aan voor de WebM familie, en stelt daarnaast de patenten in het publieke domein.

Een monopolie impliceerd een industrie met een hoge barier to entry, en Google/Xiph neemt dat dus allemaal weg met hoe ze VP8/9,WebM en Vorbis beschikbaar stellen. Dit is dus zo anti-monopolistisch als het maar kan, ongeacht marktaandeel van eventuele diensten gebaseerd op deze tech (Youtube).
Bij H.264/H.265 wordt de codec publiek ontwikkeld en iedereen kan inbreng doen naar requirements and tools in de codec. Onder consensus word dan aanvaard wat relevant is voor standaardisatie. Bij VP8/VP9 beslist google aleen de requirements en de tools in de codec. In dit opzicht kan je wel zeggen dat Google zijn marktpositie (monopolie) gebruikt om technologie te pushen naar gebruikers.

Daarnaast is het doel van VP8/VP9 en H.264/H.265 anders. Bij VPx is er veel meer gericht naar internet streaming waar het bij H.26x meer gaat over een general purpose codec. Ze met elkaar vergelijken is dus ook een beetje appelen en peren vergelijken, met de "juiste" settings en testsequences kan je kiezen welke codec dat er als beste uitkomt.
Bij H.264/H.265 wordt de codec publiek ontwikkeld en iedereen kan inbreng doen naar requirements and tools in de codec. Onder consensus word dan aanvaard wat relevant is voor standaardisatie.
De _bedrijven_ die patenten hebben bepalen wat relevant is voor de standaardisatie. Oftewel wie krijgt hoeveel geld van de licentie kosten.
Bij VP8/VP9 beslist google aleen de requirements en de tools in de codec. In dit opzicht kan je wel zeggen dat Google zijn marktpositie (monopolie) gebruikt om technologie te pushen naar gebruikers.
Iedereen mag de codec gebruiken zonder toestemming of licentie kosten. Iedereen mag de codec dus ook gewoon links laten liggen.
Daarnaast is het doel van VP8/VP9 en H.264/H.265 anders.
De ene wil er geld mee verdienen en de ander wil gewoon een codec zonder gezeik.
Bij VPx is er veel meer gericht naar internet streaming waar het bij H.26x meer gaat over een general purpose codec.
Want een codec die kleine bestanden geeft, hoge kwaliteit geeft en makkelijk streamed is iets heel anders dan wat H.26x wil...
Ze met elkaar vergelijken is dus ook een beetje appelen en peren vergelijken, met de "juiste" settings en testsequences kan je kiezen welke codec dat er als beste uitkomt.
Want er is geen verschil tussen Xvid of X264. Het is een kwestie van de "juiste" settings en testsequences.
En het probleem? Zowel de browser als de betreffende website ondersteunen ook netjes h.264 zodat geen enkele website uitgesloten word bij de browser en geen enkele browser uitgesloten word bij de website.
En het probleem? Zowel de browser als de betreffende website ondersteunen ook netjes h.264 zodat geen enkele website uitgesloten word bij de browser en geen enkele browser uitgesloten word bij de website.
Ik weet niet waar je op reageert maar elke browser die geen geld wil betalen voor codecs word uitgesloten.
En VP9 is een open formaat: Andere browsers kunnen de technologie ook gebruiken. Firefox bijvoorbeeld gebruikt op dit moment ook de WebM (VP8) formaat.
Hoe zit dat, als ik mijn films omzet naar x264 draag ik niks af?
Ben juist een voorstander van h265 na vergelijksfilms met h264 te hebben gezien.
Als consument ben je vrijgesteld van het betalen van deze royalties. In den beginne was deze vrijstelling tijdelijk, maar ik geloof dat de MPEG-LA deze uitzondering ondertussen onbeperkt in tijd heeft gemaakt. Als softwaremaker moet je dan weer wel een bijdrage betalen vanaf je product een aantal gebruikers kent of wanneer het product commercieel gebruikt word. Om een klein voorbeeld te geven, wanneer Mozilla ondersteuning zou toevoegen aan Firefox zou hen dit ongeveer 5 miljoen dollar per jaar kosten.
wanneer Mozilla ondersteuning zou toevoegen aan Firefox zou hen dit ongeveer 5 miljoen dollar per jaar kosten.
Nee want firefox kan gewoon aanwezige codecs gebruiken.
Vanaf windows Vista zijn alle windows versies standard uitgerucht met een meegeleverde h.264 codec en ook vrijwel alle oudere XP installaties hebben al de h.264 codec erop staan.
Ook de iOS, blackberry en android plaforms komen standard met de h.264 codec meegeleverd.

Firefox is dus ook begonnen met het ondersteune van h.264.
Het idee van de video tag is juist dat er GEEN codecs op het OS hoeven te staan om licentie gezeur te voorkomen.

In landen met software patenten is het voor oa Linux onmogelijk om ondersteuning voor h.264 mee te leveren (default)
Maar ja, de codecs / libraries moeten toch ergens staan. Waar staan die dan? Is dat server-side?
De webbrowser zal zelf de video analyseren en dan de juiste decoder kiezen die deze browser aan boord heeft.
[...]

Nee want firefox kan gewoon aanwezige codecs gebruiken.
Vanaf windows Vista zijn alle windows versies standard uitgerucht met een meegeleverde h.264 codec en ook vrijwel alle oudere XP installaties hebben al de h.264 codec erop staan.
Ook de iOS, blackberry en android plaforms komen standard met de h.264 codec meegeleverd.

Firefox is dus ook begonnen met het ondersteune van h.264.
Je zegt het zelf al. Firefox ondersteund geen h.264. Als het OS toevallig een codec heeft dan kan Firefox die mogelijk gebruiken. Maar als Firefox op een OS zit wat die codec niet heeft dan verdwijnt die ondersteuning ineens. Dus nu mag de website gaan melden dat hun website compatible is met: Windows7.

Zeg maar dag tegen je mooie open vrij beschikbare internet.
Geef mij maar h.265
Geef mij maar h.265
Ja gatver wie wil er nou gratis vrij beschikbare codecs gebruiken! Het is veel beter om per apparaat en per stuk stoftware licentie kosten te moeten betalen.
VP8, de videocodec die Google twee jaar geleden introduceerde.
VP8 is toch al veel ouder dan dat? Daarnaast heeft Google die codec niet gemaakt, ze hebben het bedrijf dat dat gedaan heeft opgekocht.
met behoudt van dezelfde videokwaliteit.
Auw. :)

[Reactie gewijzigd door Onno op 11 mei 2013 14:53]

On2 Technologies had de code van VP3 aan Xiph.org gedoneerd, en dat is theora geworden.
On2 ging door met VP4, tot en met VP8, waarna Google het overkocht in 2010.
Maar On2 had VP8 al in 2008 uitgebracht.
"Doel is om de bitrate met 50 procent te verlagen ten opzichte van VP8 met behoudt van dezelfde videokwaliteit." Had veel liever gezien dat ze de bitrate gelijk hielden en de beeldkwaliteit verhoogde, ook voor gameplay video's zou een verhoging van de toegestane framerate helpen maar nee ze moeten het gewoon kleiner maken. Voor mij is dit dus compleet nutteloos gezien ik toch al makkelijk 1080p kan streamen zonder er op te wachten, Ach het zal wel weer om kostenbesparing gaan.
Het zou wel logisch zijn dat de kwaliteit ook toeneemt bij een gelijke bitrate, dus wat jij wil.
Dat Youtube niet alles gratis in 4k kan gaan uitzenden is ook wel begrijpelijk, of je krijgt voor elke video 30 seconden reclame te zien, het is maar wat je wil.
Dat komt op hetzelfde neer. Een lagere bitrate bij dezelfde kwaliteit is praktisch hetzelfde als dezelfde bitrate bij hogere kwaliteit.
Nokia handelt allicht in opdracht van hoofdsponser Microsoft - een herhaling van het SCO-verhaal (zie groklaw.net)?
Nokia werd enigzins geforceerd om hun patenten kenbaar te maken omdat de IETF aan de leden (waaronder Nokia) vroeg of zij hun rechten wilden afstaan voor VP8.
Nokia gaf aan dat zij ten minste 86 patenten wereldwijd hebben mbt VP8 waarvan ten minste 12 verschillende.
Maar dit is VP9 dus, niet VP8. Neem aan dat vervanging van een aantal patentgevoelige technieken onderdeel is van de verbeteringen...
Kan iemand specifiek uitleggen wat nou precies vp9 is? Wat zijn precies de meerwaarde van deze codec?

[Reactie gewijzigd door aygul12345 op 12 mei 2013 11:03]

Net zoals VP8: opensource / free software (BSD-license), geoptimaliseerd als internet content video codec, niet als broadcast video codec (zoals bv. de MPEG family of codecs, en ook H264 en H265).

Beter dan VP8: beter geoptimaliseerd voor HD materiaal (d.m.v. een variable recursive block structure die van 64x64 tot 4x4 pixels per block ondersteunt), gebruik van nieuwe technieken uit de academische wereld (bv. asymetrische sine-based transforms in combinatie met de klassieke cosine-based transforms), betere mogelijkheden voor parallelisatie (multi-threading), en allerlei andere dingen - samen iets in de richting van 50% kleinere bestanden vergeleken met H264 (of VP8) op HD materiaal, en in de richting van de 30% kleinere bestanden op lage-resolutie materiaal.

[Reactie gewijzigd door Beelzebubu op 12 mei 2013 16:09]

op 17 juni zal er een codefreeze plaatsvinden
Dit klopt dus niet - er zal een specificatie freeze plaatsvinden. D.w.z., op dat moment zal er een bitstream specificatie uitkomen, en als je a.d.h. daarvan een decoder maakt, zal deze alle toekomstig gemaakte VP9 bestanden kunnen decoderen, zelfs als deze met een VP9 encoder is gemaakt die 5 jaar later wordt gereleased. Er kunnen en zullen echter nog wel degelijk verbeteringen aan zowel encoder (kwaliteit en snelheid) als ook aan de decoder (snelheid) worden gemaakt, maar die moeten dus compatible zijn met de originele bitstream specificatie die op 17 juni wordt gereleased. De code wordt dus continue door-ontwikkeld, maar de specificatie van de bitstream zal niet verder veranderen.

Op dit item kan niet meer gereageerd worden.