Google stapt over op VP8-codec en webrtc voor Hangouts

Google is begonnen om binnen zijn Hangouts-chatdienst videobeelden via zijn eigen VP8-codec te comprimeren in plaats van de h.264-codec. Ook wil Google het webrtc-protocol gaan gebruiken, zodat Hangouts in moderne browsers zonder plug-ins gebruikt kan worden.

De keuze voor VP8 als codec ligt voor de hand: Google is eigenaar van de VP8-codec nadat het deze in handen had gekregen met de overname van On2 Technologies. De codec is opensource en kent in tegenstelling tot h.264 geen verplichte afdracht van royalty's. De codec wordt samen met audio in de WebM-container gedistribueerd en is onderdeel van een streven van Google om royalty-vrije html5-multimediatechnologieën naar voren te schuiven, zoals het WebP-formaat voor afbeeldingen. Inmiddels ondersteunen browsers als Chrome, Opera en Firefox de VP8-codec en Google acht de tijd nu rijp om zijn Hangouts-dienst van de codec gebruik te laten maken bij videochats.

Chee Chew, vice president of engineering bij Google, laat aan GigaOM weten dat de VP8-codec beelden van webcams met lagere bitrates dan h.264 kan comprimeren zonder zichtbaar kwaliteitsverlies. Daarbij wordt een 720p-resolutie aangehouden. Bovendien is er met de VP8-codec ten opzichte van h.264 minder rekenkracht nodig. Wel is er brede ondersteuning voor gpu-acceleratie voor h.264, waar voor het decoderen van VP8 de cpu aan het werk moet.

Chew claimt dat er met VP8 tot tien 720p-streams mogelijk zijn binnen Hangouts, terwijl veel pc's bij een dergelijk aantal streams in h.264 onvoldoende cpu-kracht hebben. Na een beperkte test moeten de komende maanden vrijwel alle Hangouts-gebruikers gaan communiceren via VP8, maar Browsers die de codec niet herkennen, zoals Internet Explorer en Safari, kunnen terugvallen op h.264-streams.

Google wil in Hangouts ook gebruik gaan maken van het webrtc-protocol. Dit realtime audio- en videoprotocol moet het mogelijk maken dat de Hangouts-omgeving in moderne browsers niet langer plug-ins nodig heeft. Bovendien is webrtc volgens Chew inmiddels voldoende gerijpt om breed ingezet te gaan worden.

Reacties (67)

[SuperDre]

De codec is opensource en kent in tegenstelling tot h.264 geen verplichte afdracht van royalty's

Daar zijn de meningen nog zwaar over verdeelt omdat het nog niet allemaal goed uitgezocht is.

met lagere bitrates dan h.264 kan comprimeren zonder zichtbaar kwaliteitsverlies.

Tja, wat voor de ene acceptabele kwaliteitsverlies is, wil niet betekenen dat dat voor andere ook zo geldt. meestal is het dan een stuk softer, maakt niet zo veel uit op een klein 5" full hd schermpje, maar op een 24" wordt het al meteen een stuk duidelijker, en over veel grotere schermen is het dan wel heel duidelijk (omdat er dan ook nog upscaling plaatsvindt).

[mcDavid]

[...]


Daar zijn de meningen nog zwaar over verdeelt omdat het nog niet allemaal goed uitgezocht is.

heeft weinig met uitzoeken te maken. De codec is gewoon royalty-vrij, alleen zijn er patent claims van Nokia, die van mening is dat de codec inbreuk maakt op haar patenten. Of dat zo is zal een rechter moeten bepalen. En al is dat zo, dan nog betekent dat niet per definitie dat de codec niet meer royalty-vrij zal zijn. Nokia kan er voor kiezen de patenten open te stellen, of google kan een schikking treffen.

[...]


Tja, wat voor de ene acceptabele kwaliteitsverlies is, wil niet betekenen dat dat voor andere ook zo geldt. meestal is het dan een stuk softer, maakt niet zo veel uit op een klein 5" full hd schermpje, maar op een 24" wordt het al meteen een stuk duidelijker, en over veel grotere schermen is het dan wel heel duidelijk (omdat er dan ook nog upscaling plaatsvindt).

Lees nog een keer, er staat "zonder zichtbaar kwaliteitsverlies", niet "zonder onacceptabel kwaliteitsverlies". Als je het niet kunt zien, kun je het niet zien. Het blijft een subjectieve claim, maar VP8 is echt niet (meer) inferieur t.o.v. H.264.

[Reactie gewijzigd door mcDavid op 23 juli 2024 14:57]

[RuddyMysterious]

alleen zijn er patent claims van Nokia, die van mening is dat de codec inbreuk maakt op haar patenten. Of dat zo is zal een rechter moeten bepalen.

<Farnsworth>Good news everyone!</...>

Good News from Germany

Today a court in Mannheim, Germany, ruled that VP8 does not infringe a patent owned and asserted by Nokia. This decision is an important and positive step towards the WebM Project's ultimate goal: ensuring the web community has an open, high-quality, freely licensed video codec. Google's intervention in the underlying lawsuit (Nokia v. HTC) was a strong show of support for open standards like VP8.

We believe that the web succeeds through community-developed innovation. VP8 brings that principle to video: a codec that anyone can use and build upon. The WebM Project’s next-generation video codec, VP9, is already available and we look forward to continuing our work with the broader community to help video on the open web keep getting better, faster.

Matt Frost is Senior Business Product Manager for the WebM Project

bron op blog.webmproject.org via osnews.com

edit: awww snap,

[...]

In summary, Nokia won a case before a Dutch appeals court, narrowly lost a VP8-related one in Germany (which it may appeal and/or pursue in other jurisdictions), and one other Nokia case was stayed, which benefits HTC for the time being but could still result in an injunction if Nokia defends the patent before the Federal Patent Court of Germany.

bron op fosspatents.com

[Reactie gewijzigd door RuddyMysterious op 23 juli 2024 14:57]

[Verwijderd]

Je vergeet uit je links te kopieren:
narrowly lost a VP8-related one in Germany (which it may appeal and/or pursue in other jurisdictions),

[SirBlade]

Gezien het recente gedrag van Google richting Nokia smartphones denk ik niet dat Nokia er voor zal kiezen om die patenten open te stellen zonder dat Google daar heel veel tegenover zal moeten stellen.

[Verwijderd]

Wat voor gedrag tegenover Nokia smartphones? Je merkt er echt helemaal niks van op een N9 hoor.

[Verwijderd]

-Recente- gedrag. Een N9 is recent? Nope.

[DeadMetal]

Natuurlijk niet. Een foto van 5MP ziet er op 10x15cm immers ook heel anders uit dan op een beeldscherm op Times Square. Op een 24" scherm wordt het geheel meer uitgerekt t.o.v. 5inch scherm, dus minder pixels per vierkante centimeter.

[Sleepkever]

Oftwel, hang nog steeds volledig af van de resolutie van het scherm. Ik durf te wedden dat een lagere resolutie foto eerder opvalt op een printje van 10x15 dan op dat scherm van times square. Dat times square scherm kan prima 500x500 pixels zijn of 1366x768, onafhankelijk of dat ding nou groter is of niet. De totale resolutie de geprint word op dat 10x15 foto is al snel vele malen hoger.

Je pixels per vierkante centimeter maken inderdaad uit. Zowel van de bron als wat het uiteindelijke medium maximaal weer kan geven. En kijkafstand speelt ook nog een rolletje aangezien wij mensen maar tot een bepaald punt dingen kunnen onderscheiden.

[Verwijderd]

Ik denk dat je me verkeerd begrepen hebt, het ging over het kwaliteitsverlies. Volgens SuperDre wordt kwaliteitsverlies duidelijker op een 24" scherm dan op een 5" scherm. Wat onjuist is. 480p ziet er op een 5" scherm even brokkelig uit als op een 27". Natuurlijk wel bij normaal gebruik.

Jouw redenering zit er trouwens al helemaal compleet naast aangezien je geen rekening houdt met het nut. De schermen op times square bekijk je van op tenminste 10m, uw foto van 10x15 op een cm of 25. En dan heeft een print nog tientallen keren een grotere resolutie dan een scherm.

[Recursio]

Even kritisch lezen:

"Chew claimt dat er met VP8 tot tien 720p-streams mogelijk zijn binnen Hangouts, terwijl veel pc's bij een dergelijk aantal streams in h.264 onvoldoende cpu-kracht hebben."

Even opknippen in twee stukken:

[1]
"Chew claimt dat er met VP8 tot tien 720p-streams mogelijk zijn binnen Hangouts ..."
>>> Ik zie hierbij geen claim over het aantal mogelijk simultane streams bij h.264 (Waarbij ik maar even de aanname maak dat het om simultane streams gaat, want dat staat er niet bij.) Bovendien is dit deel van de claim al waar als er 1 PC is waar dit mee kan. De claim is ook nog waar als er PC's zijn die tot 20 (of 100, of ...) h.264-streams simultaan kunnen afspelen, want daar wordt geen bewering over gedaan.
Op basis van het aantal streams dat simultaan afgespeeld kan worden, kan h.264 dus prima superieur zijn aan VP8 volgens deze formulering.

[2]
"...terwijl veel pc's bij een dergelijk aantal streams in h.264 onvoldoende cpu-kracht hebben."
>>> Hier wordt dus niets gezegd over het aantal PC's dat moeite heeft met een 'dergelijk aantal streams' bij de h.264-codec.

Kortom, het is op basis van deze 'claim' goed mogelijk dat er meer PC's moeite hebben met het simultaan afspelen van VP8-streams dan met h.264-streams. M.a.w. dit is geen 'claim' maar een uitspraak waar mr./ ms. Chew niet op aangesproken kan worden, want de 'claim' is multi-interpretabel, terwijl de mogelijke betekenissen elkaar tegenspreken. We dienen mr./ ms. Chew dus te geloven, of ergens benchmarks vandaan halen, want met deze lege bewering kunnen we niet zoveel.

Dergelijke suggestieve beweringen horen m.i. niet in journalistieke teksten thuis, tenzij ze begeleid worden door kritische vragen / onderzoek.

[Reactie gewijzigd door Recursio op 23 juli 2024 14:57]

[GlowMouse]

Als je zo kritisch gaat lezen, kun je beter de bron pakken:

One of the key advantages of VP8 is that it will enable Hangouts in HD, something that Chew said simply wasn’t possible with H.264, because handling HD streams from 10 participants would have required too much processing power.

De vraag is wat je met 10 HD-streams moet. Die passen nooit tegelijk op één scherm. Als je de streams buiten beeld pauzeert of in een lagere resolutie streamt, volstaat h.264 wellicht gewoon.

Wat nergens genoemd wordt, is dat het encoderen van VP8 veel meer processing power kost dan encoderen van h.264. Tegenwoordig kan het encoderen op sommige gpu's, maar dat zijn juist de pc's waar het decoderen ook al snel gaat.

[RobIII]

De vraag is wat je met 10 HD-streams moet. Die passen nooit tegelijk op één scherm.

Je krijgt 10 (HD) streams binnen die dan (downscaled weliswaar) naast elkaar weergegeven worden; er wordt geswitched naar "degene die aan 't woord is" -> *plop* HD stream van die persoon zonder te hoeven "switchen" van "SD" naar "HD". Gewoon niet meer downscalen.

Wat nergens genoemd wordt, is dat het encoderen van VP8 veel meer processing power kost dan encoderen van h.264

Toch heb je netto doorgaans maar 1 stream te encoderen en 1 of meer* streams te decoderen (* en bij een hangout is natuurlijk de bedoeling dat het dan over 2 of meer streams gaat, in dit voorbeeld zelfs 10). Onder de streep hou je dan dus minder CPU verbruik over

[Reactie gewijzigd door RobIII op 23 juli 2024 14:57]

[Mathieu_Hinder]

Hoe het ook zij, de streams moeten op een bepaald moment geëncodeerd worden. En daarbij gebruikt VP8 meer cpu-kracht dan h.264. Om te zeggen dat h264 dan dit niet aankan en VP8 wel, klopt gewoon niet.

[Remenic]

Maar jij lijkt te vergeten dat elke PC het encoderen van zijn stream voor z'n rekening neemt. 1 stream per PC wat geencodeerd wordt, plus 10 die gedecoceerd worden.

Als het encoderen 2x zoveel tijd kost, maar het decoderen gaat per stream een kwart sneller, dan heb je netto nog steeds winst.

Wat jij met die laatste zin doet is trouwens woorden verdraaien. Er wordt toch duidelijk gezegd dat h.264 niet 10 HD streams tegelijk kan decoderen op een gemiddelde PC.

[Ryangr0]

Ik snap even iets niet. Waarom overstappen op een zeer verouderde en vooral achterhaalde codec als VP9 and H265 om de hoek staan?

[Blokker_1999]

Omdat vp8 vandaag al breed beschikbaar is in verschillende browsers. Je gaat toch niet kiezen voor een standaard die niemand heeft. En h.265 zal hetzelfde probleem meekrijgen als 264: wel een open standaard, maar niet gratis te gebruiken.

[Ryangr0]

Ik wacht liever even en dat ik dan een moderne (betere) codec heb in plaats van zo snel mogelijk een verouderde codec implementeren, vooral als de nieuwe standaard zo dichtbij is, maar goed. Google zal er wel haar redenen voor hebben. Ik blijf het vreemd vinden. De verschillen tussen VP8 en VP9 zijn immens.

[Zer0]

Als VP9/h.265 gereleased worden zullen ze niet direct door alle browsers ondersteunt worden, en duurt het ook nog even voor ze genoeg verspreid zijn onder de gebruikers.

[Verwijderd]

Omdat vp8 vandaag al breed beschikbaar is in verschillende browsers.

Google had al bijna een half jaar de tijd om VP9 in Chrome uit te rollen of in de Google gesponsorde borwsers van FF en Opera. En dat zijn ook nu ook al de enige browsers die out of the box VP8 ondersteunen.

[Verwijderd]

Jezus Christus. Je stuurt hier 5 berichten tegen VP8 die allemaal zwaar suggestief en ongefundeerd zijn. Wat is jouw probleem?

[Verwijderd]

Hoezo ongefundeerd.
Ik gaf zelf nog een bron link naar een artikel waarin stond dat Google afgelopen mei nog aandrong op snelle invoer van VP9 en nu 4 maanden later gaan ze zelf niet over op VP9 maar op VP8.

[elley]

Ik hoop dat hij zonder plugin eindelijk eens wat stabiliteit wint. Ik gebruik hangouts dagelijks op mijn werk als deel van apps, en die plugin is een draak van software. Collegas liggen ook wel te vloeken, te herinstalleren, or browsers te herstarten omdat alles opeens onmenselijk traag wordt.

Hopen dat het pluginloos wel vlot werkt... Maar als je dan leest dat het ook nog maar de vraag is of het al volwassen genoeg is...

[aCCuReRaS]

Gebruik hem ook dagelijks. Op Mac in Chrome geen last van crashes o.i.d.
Collega's met Windows hebben meer last, maar dan voornamelijk issues met geluid.

[elley]

Onder Ubuntu draait hij ook stabiel. Werk ik onder Windows, dan is het een ramp.

[4bit]

Doe zoals ik en houd het gewoon bij google talk. Dat werkt nog steeds fantastisch en gebruikt amper resources. En je kan tenminste zien wie er online/bezet/afwezig is.

[Jazco2nd]

Agree! Ik heb Hangouts paar keer een kans gegeven maar het is zo een grote stap terug. Werkt voor geen meter. Op je telefoon heb je nieteens meer een contact list. Fuck hangouts. Het leverde bij ons alleen maar enorme irritaties op!

[Brummetje]

Op de desktop client kun je gewoon zien of iemand online/afwezig is hoor

[pibara]

Werkt nog steeds? Wordt gewoon bruut van je mobiel gedonderd door Google en staat niet meer in de playstore.

[catfish]

het "probleem" met Nokia lijkt wel van de baan:
http://blog.webmproject.o...od-news-from-germany.html

[Verwijderd]

Lijkt inderdaad
narrowly lost a VP8-related one in Germany (which it may appeal and/or pursue in other jurisdictions),

[Verwijderd]

Nokia heeft meerdere patenten ingezet tegen VP8. (Bron)
Nokia heeft bovendien aangegeven aan de IETF 86 patenten in verschillende landen te hebben met betrekking tot VP8 (minstens 12 verschillende)
Bovenstaand artikel gaat over 1.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 14:57]

[Verwijderd]

Als je hangouts niet gebruikt, heb je dan geen 'last' van VP8?

[Mathieu_Hinder]

Ik vermoed dat het ook de bedoeling is dat YouTube uiteindelijk overstapt op VP8, en zo'n beetje alle Google diensten.

[Verwijderd]

Wil je weten of een bestand op Youtube VP8 is? Je kan het downloaden en dan in de codec kijken.
Downloaden gaat als volgt:
1) speel het youtube filmpje af. Kopieer de url.
2) start vlc en in het menu "media" selecteer je "open network stream" en je plakt hierin de url.
3) in menu "tools" ga naar "media info". Onderaan staat "location". Kopieer die regel
4) in de browser, plak deze regel in de adresbalk. Je kan dan het bestand downloaden.
5) start het in vlc. In het menu "tools" selecteer "codec information" en voila.

[Jazco2nd]

H 265 heeft nog veel meer rekenkracht nodig maar heeft ook slechts de helft van de bandbreedte nodig tov H264 voor dezelfde kwaliteit. VP8 heeft minder rekenkracht nodig dan H264, dat is zeker waar, maar je haalt ook een lagere kwaliteit bij dezelfde bandbreedte. Geen probleem voor Google, dan verhoog je de bandbreedte, Google genereert toch al een groot aandeel van alle data (vooral met YouTube) dus dat vinden ze helemaal niet erg.

[laptopleon]

"Chew claimt dat er met VP8 tot tien 720p-streams mogelijk zijn binnen Hangouts, terwijl veel pc's bij een dergelijk aantal streams in h.264 onvoldoende cpu-kracht hebben. "

Tien 720p streams, toe maar, ik heb al moeite iemand te vinden binnen mijn contactenkring, die überhaupt wil video-chatten ipv bellen. Bij tien streams maak ik me meer zorgen over de datasnelheid. En dan hebben we hier in Nederland nog relatief snelle verbindingen.

[Verwijderd]

Chee Chew, vice president of engineering bij Google, laat aan GigaOM weten dat de VP8-codec beelden van webcams met lagere bitrates dan h.264 kan comprimeren zonder zichtbaar kwaliteitsverlies. Daarbij wordt een 720p-resolutie aangehouden. Bovendien is er met de VP8-codec ten opzichte van h.264 minder rekenkracht nodig.

Dit lijkt een duidelijk bullshit verhaal. Je moet gewoon testen met een gelijke bitrate en dan zie je precies welke de beste codec is. In alle meer objectieve test is dan h.264 de betere codec dan VP8.
Testen met ongelijke bitrates is onzin omdat bij goede kwaliteit video elk beetje extra kwaliteit een veel hogere bitrate oplevert.

Verder is het bijna lachwekkend dat Google hun nieuwe VP9 codec niet durft in te zetten terwijl ze een paar maanden geleden nog aandrongen op snelle inzet van die codec.
Is die codec dan toch slechter dan altijd geclaimed?
Google urges fast adoption of VP9 video compression

[Reactie gewijzigd door Verwijderd op 23 juli 2024 14:57]

[Verwijderd]

Ik denk niet dat VP9 tegenvalt. Het is gewoon VP8 dat getweakt is voor snelle datadoorvoer van grote omvang. De drivers zullen nog wel geoptimaliseerd moeten worden en dat kost tijd.
Vergeet niet dat VP8 er eigenlijk al bestond toen Google het overnam. Dus dit is geoptimaliseerd naar filesize. Toen Google VP9 begon te ontwikkelen, legde ze de nadruk op doorvoersnelheid natuurlijk.

[Lennie]

VP9 en H.265/HEVC gebruiken, dacht ik meer dan 2x zo veel CPU voor het encoderen, hoe denk je anders dat men de helft bandbreedte kan gebruiken ?

Tevens is er hardware op de markt dat VP8 ondersteund en er is maar 1 player voor VP9, dat is Google Chrome op dit moment.

VP9 is nog een beetje te vroeg om te gebruiken, net als H.265/HVEC

[esperanto]

allemaal leuk die open codecs.... jammer dat ze dan de open standaard xmpp droppen

[Fuzzillogic]

VP8 hebben ze in volledig eigen beheer. Over WebRTC hebben ze ook zeer veel zeggenschap, want ze maken immers een extreem populaire browser. XMPP daarentegen is veel meer in handen van de community.

Ik vind het gedrag van Google in deze dus schijnheilig: de standaarden zijn dan misschien wel "open" volgens de definitie en licentie, maar ze willen open standaarden alleen gebruiken als deze niet al té open zijn. Zie ook Android en Java/Dalvik.

[i-chat]

java/dalvik ligt niet aan google he, het was oracle die daar zo extreem lastig over doet, java is geen open platform en dus niet geschikt als basis voor een bsd-achtig android..

[Dreamvoid]

Java is wel een open platform (zie het OpenJDK project). Google's Dalvik JVM voldeed volgens Oracle niet aan de voorwaarden - en aangezien Android een miljardenbusiness is, was dat voor hen de moeite waard om een rechtszaak aan te spannen. Die ze vervolgens verloren.

[pibara]

Vandaar dat de Java taal qua ontwikkeling gewoon hardstikke dood is zinds Oracle Sun heeft overgenomen. Alle leuke features zoals o.a. lambda's (die concurernde talen al eventjes een tijdje op orde hadden) zijn leuk uitgesteld van de 7 naar de 8 versie bijvoorbeeld. Ik had een paar jaar geleden nooit gedacht dat ik het zou zeggen, maar JavaScript is ondertussen een meer volwassen en up-to-date taal dan Java geworden, laten we hopen dat Google dat ook in gaat zien, en een migratie pad in zet van Java naar JavaScript. Aansluitend bij andere JavaScript based mobiele platformen. Oracle heeft Java gewoon dood gemaakt, laten we die eens zo mooie taal begraven met een overdaad aan respect voor bewezen diensten, en verder gaan met een volwassen taal die wel met de tijd is meegegaan.

[Lennie]

Google ziet dat wel zitten, men was liever direct met ChromeOS op de markt gekomen in plaats van Android. Android moesten ze gewoon doen om te voorkomen dat ze irrelevant werden, Microsoft had dat veel te laat ingezien.

[Verwijderd]

Overstappen op JacaScript zou ik geniaal handig vinden voor mijn webapp!

[Mathieu_Hinder]

Het was Google die hele stukken code letterlijk had gekopieerd Het was dus wel degelijk hun schuld en niet meer dan normaal dat Oracle daar lastig over deed.

[coolmos]

Google heeft helemaal niks letterlijk gekopieerd.

Ze hebben gebruik gemaakt van de API's. Dat valt onder fair use. De rest hebben ze zelf geschreven.

Lees het anders even na.