WebRTC-werkgroep stelt zowel h264- als VP8-ondersteuning verplicht

De RTCWEB Working Group, onderdeel van de IETF, wil zowel de VP8- als de h264-codec verplicht stellen voor browsers die de WebRTC-standaard ondersteunen. Er is een lange tijd strijd geweest over welke codec de standaard zou moeten worden, maar daar lijkt nu een einde aan te komen.

VP8 heeft voor softwaremakers het voordeel dat zij zich geen zorgen hoeven te maken over het afdragen van licentiegelden. Ook wordt deze codec, die afkomstig is van Google, onder andere door Chrome en Firefox ondersteund. H264 vergt wel het afdragen van royalty's, maar de ondersteuning voor deze codec is veel breder dan die voor VP8. Zo kan vrijwel elk mobiel apparaat h264-video's hardwarematig decoderen.

De opstellers van de standaarden achter WebRTC, een protocol dat plug-in-loze audio- en videocommunicatie in browsers mogelijk maakt, kwamen jarenlang niet tot een eensluidend antwoord op de vraag welke codec-ondersteuning verplicht zou moeten worden. Inmiddels is er toch een compromis gevonden: de RTCWEB Working Group wil dat browsers en andere software die de WebRTC-standaard ondersteunt beide codecs verplicht moet ondersteunen. Als alle leden met dit voorstel instemmen lijkt de jarenlange onenigheid tot een einde te zijn gekomen.

De adoptie van WebRTC verloopt inmiddels voorspoedig. Chrome, Opera en Firefox ondersteunen de standaard al enige tijd en Microsoft wil in toekomstige versies van Internet Explorer ook WebRTC omarmen. Mozilla, lang tegenstander van integratie van de h264-codec, koos voor Firefox uiteindelijk voor OpenH264, waarbij Cisco de licentiekosten afdraagt. Overigens werken een aantal Mozilla-developers binnen de Xiph.org Foundation aan Daala, een videocodec die de kwaliteit en compressiefactor van de nieuwe compressiegeneratie h265 minimaal zou moeten evenaren.

Reacties (40)

[Peetke]

Lopen ze niet achter te feiten aan? Nu YouTube al over is op VP9 en h265 op allerlei plaatsen al in gebruik is, is VP8 en h264 nu pas als standaard benoemen een beetje laat.

[Maurits van Baerle]

Dit gaat om toepassing in een videochat protocol, niet om het weergeven van 4K video's. In dit geval spelen laag energieverbruik en brede hardwareondersteuning de hoofdrol, niet beeldkwaliteit bij grote resoluties.

[Verwijderd]

Punt is dat windows 10 straks standaard al h.265 ondersteunt en dus ook alle browsers op Windows 10 zullen het ondersteunen.
Een codec die ongeveer de helft van de data benodigt van h.264 en juist die de hoeveelheid data is juist voor de kwaliteti en performance van streaming video extreem belangrijk.
Het is zinloos om nu h.264 of VP8 verplicht te stellen.
Die codecs zijn al obsolete tegen de tijd dat WebRTC breed wordt ingezet.

[Solstice]

Het gaat om minimaal h264 en VP8. Natuurlijk kan de webbrowser gerust daarnaast optioneel VP9 en H265 bieden.
Overigens, op dit moment gebruiken bijna alle hardware en video conferencing systemen h264, die op deze manier kunnen verbinden met webrtc clients.

En webRTC wordt nu uitgerold, dus obsoleet worden deze codecs nog lang niet.

En h265 en vp9 hebben meer rekenkracht nodig dan h264 en vp8. Dat zullen veel mobiele apparaten nog niet aankunnen. Dat komt ook allemaal weer goed uiteindelijk.

[Verwijderd]

En h265 en vp9 hebben meer rekenkracht nodig dan h264 en vp8

Het is heel moeilijk om nu al uitsrpaken te doen over de performance van de encoders en decoders van h.265 en VP9 omdat dergelijke encoders en decoders nog in ontwikkeling zijn en er dus in de beginjaren telkens nieuwe snellere versies zullen komen.
Belangrijk zal zijn dat er brede hardware ondersteuning komt voor encoding en decoding van deze nieuwe codecs. Het uitrollen van die brede ondersteuning kan met name op mobiele platforms waar de levensduur van hardware realtief laag is snel gebeuren maar zal nog verscheidene jaren duren.

[OddesE]

Tja maar gemiddeld genomen geldt wel de regel dat meer compressie bij gelijke kwaliteit meer rekenkracht kost. Je ruilt als het ware rekenkracht in voor opslagruimte. Dus de stelling dat de volgende generatie codecs meer rekenkracht vereist is wel zeer plausibel. Het lijkt me veilig om daar maar vanuit te gaan totdat het tegendeel bewezen is.

[Verwijderd]

Ik ga daar ook wel van uit dat het meer performance vraagt maar als er een dedicated hardware chip in een SoC de encoding en decoding doet merk je daar niks van.

[Dual Infinity]

Vergis je niet. HEVC (h265) is echt behoorlijk zwaar.
Zie bijvoorbeeld deze data:
"On November 14, 2013, DivX developers released information on HEVC decoding performance using an Intel i7 CPU at 3.5 GHz which had 4 cores and 8 threads.[86] The DivX 10.1 Beta decoder was capable of 210.9 fps at 720p, 101.5 fps at 1080p, and 29.6 fps at 4K"
( http://en.wikipedia.org/w...lementations_and_products )

Natuurlijk is dat geen dedicated hardware en daarbij geldt ook nog dat HEVC decoding/encoding beter parallelliseerbaar kan zijn dan AVC decoding/encoding, maar dat het zwaar is lijkt me wel duidelijk.

[Verwijderd]

Decoding is bovendien niet het grote probleem. Encoding is het probleem.
WebRTC communicatie vereist real time encoding op redelijk resoluties en dat vereist gewoon voor h.265 gewoon dedicated hardware

[Reactie gewijzigd door Verwijderd op 23 juli 2024 22:01]

[niqck]

Obsolete is een groot woord. Alles hercoderen neemt veel tijd in beslag dus voor de huidige video's zal die wel nog een tijdje gebruikt worden. MP3 is ook al 20 jaar oud en wordt nog steeds gebruikt hoewel er ondertussen al veel betere codecs zijn.

Mijn ganse DVD en BR collectie heb ik in h264 ge-encodeerd op mijn NAS staan. Voornamelijk omdat mijn RPi's h264 probleemloos afspelen. En zelfs al komt er een RPi met h265 ondersteuning, dan nog zie ik mij niet alles opnieuw hercoderen naar h265. Zeker niet omdat ik omwille van qualiteit alles terug van bron zou hercoderen... Aan deze collectie ben ik al een paar jaar bezig

[Verwijderd]

Alles hercoderen neemt veel tijd in beslag dus voor de huidige video's zal die wel nog een tijdje gebruikt worden

Bij webRTC gaat het met name om real time communicatie. Niet over bestaande video's.
Ook zin er nu nog nauwelijk WebRTC implementaties.

Bij WebRTC valt dus eigenlijk nauwelijks iets te hercoderen en kan een nieuwe betere codec heel snel ingezet worden.

En grote partijen zoals netflix die gigantisch veel videodata over het web versturen zullen zoveel kosten besparen met streamen van h.265 dat ze heel snel overgaan zeker voor hun nieuwe en hun populaire producties.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 22:01]

[OddesE]

Domme vraag misschien maar geldt deze eis (ondersteunen van zowel VP8 als h264) nu ook voor de video tag? Of staat dit daar helemaal los van? Want als dit ook voor de video tag geldt dan zie ik het nut van ondersteunen van deze veelgebruikte codecs wel.

Zelfs al geldt het niet daarvoor, dan nog lijkt het logsich dat de browsers, als ze voor WebRTC toch beide codecs moeten ondersteunen, dit ook voor de video tag zullen gaan doen. En dus geeft dat een heleboel voordelen voor video sites lijkt me. Zouden we nu eindelijk van de Flash player af komen?

[Verwijderd]

Het staat daar los van.

Alle belangrijke browsers ondersteunen overigens al h.264 voor de video tag.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 22:01]

[Rob Wu]

Chromium (niet Google Chrome) ondersteunt standaard geen h.264 (en in 2011 had Google gezegd dat ze het niet meer wilde ondersteunen, maar het is nu nog steeds ondersteund).

En Firefox heeft pas recent standaard ondersteuning voor h.264 toegevoegd aan Firefox op Linux (sinds 33 als ik me niet vergis).

Brede ondersteuning voor h.264 is dus iets recents.

En ondersteuning in WebRTC voor h.264 impliceert dat de video tag deze moet ondersteunen, want dat is de manier waarmee video streams getoond worden.

[niqck]

Inderdaad. Maar mijn reactie was eerder op het "tegen dan zijn die codecs obsolete". De laatste keer dat ik in de winkel liep zag ik nog steeds nieuwe DVD's met MPEG2... pokke-oud in IT-termen maar verre van obsolete. Zelfde zal zijn met h264. Die codec zal ook nog jaren meegaan gezien het wijde gebruik en adaptie momenteel; RPi, GSM's, Tablet etc... bijna allemaal hebben ze HW-versnelling voor h264. Dan ga je die niet zo snel de vuilbak insmijten.

[Verwijderd]

Obsolete als in gedateerd
Het is raar om in een standaard voor de toekomst codecs te benoemen die niet meer relevant zullen zijn tegen de tijd dat deze standaard echt breed geimplementeerd zal worden.
Het lijkt meer een politieke beslissing dan een zinvolle toevoeging aan de standaard.

[kidde]

Als WebRTC breed geïmplementeerd word, dan die video standaarden ook & zijn ze per definitie relevant.

Net als WebRTC breed geïmplementeerd wordt en spijkerschrift
een vereiste zou maken, dat spijkerschrift dan ook weer relevant maakt.

[Verwijderd]

Alle moderne televisies kunnen nog steeds mpeg-1 signalen vertalen naar beeld maar dat betekent niet dat mepg-1 nog een relvante codec is.
Die codec was obsolete zodra mpeg 2 werd geintroduceerd.
h,264 zal nog redelijk lang bestaan voor video omdat televisies en decoders een lange levenscyclus hebben maar op de computer en zeker op mobieltjes zal h.265 snel een grote speler worden. Over twee jaar hebben alle 95% van nieuwe computers en alle midrange en hoger mobieltjes standaard hardware matige ondersteuning voor de h.265 codec.
En het implementatiebereik van WebRTC zal dan nog steeds klein zijn. Webstandaarden hebben vaak 5 tot 10 jaar nodig om echt groot te worden. Over tien jaar is h.264 op het internet al lang voorbij gestreeefd door h.265.

[niqck]

Een beetje conservatief zijn kan geen kwaad. h.265 is nog maar een dik jaar een standaard (1e versie). De 2e versie is nog geen maand aangenomen als standaard.
Uiteindelijk is het altijd een beetje achterop hinkelen met standaarden; er wordt constant gewerkt aan verbeteringen maar je moet ooit een beslissing nemen. Veel van die beslissingen worden niet op 1 dag genomen maar zijn gevolgen van eerdere keuzes.
Wie weet komt h.265 in WebRTC 1.1 of zo...

[Mraedis]

De werkgroepen lopen hier altijd wel wat achter op de praktijk, vele browsers hebben deze codecs al een tijdje in de maak voor ondersteuning. Je vraagt je af wat het nut is van zo'n certificatie als het toch 'oude' standaarden zijn.

[Maurits van Baerle]

Het gaat er om dat ALLE browsers ALLE door WebRTC officieel aangewezen standaarden moeten ondersteunen. Anders kunnen sommige mensen niet met anderen praten.

h.264 ondersteuning zit overal wel in, VP8 zeker niet. Dit betekent nu dat iedere browser die WebRTC wil ondersteunen ook VP8 moet gaan implementeren.

[Verwijderd]

Dat zal weinig uitmaken.
Microsoft zal vrijwel zeker kiezen om VP8 (eigendom van Google) niet te ondersteunen en dan maar een onvolledig WebRTC implementatie te ondersteunen of in het uiterste geval vp8 wel te ondersteuen maar toch de codec niet met windows mee te leveren (terwijl h.264 al jaren gewoon standaard met windows word meegeleverd).
Effectief zal bijna iedereen dus h.264 gebruiken en niet VP8.
h.264 is sowieso van de twee de betere codec en iedereen heeft die al op de computer staan.
En zodra h.265 zal worden meegeleverd met Windows 10 en in de browser van iOS/OS X, zal die codec superssnel breed uitgerold worden en zal die code het overnemen omdat het een veel betere streaming performance geeft

[Reactie gewijzigd door Verwijderd op 23 juli 2024 22:01]

[Neko Koneko]

Microsoft van 5 jaar geleden zou inderdaad op die manier reageren, maar tegenwoordig lijkt MS zich iets beter aan de standaarden te willen houden, dus goede kans dat ze het gewoon gaan ondersteunen.

Nu maar hopen dat Google niet juist zijn huidige kansloze zelf gaat zijn en het MS op een of andere manier moeilijk gaat maken om de standaard te implementeren. Google denkt nog steeds dat het hip is om MS te pesten

[kidde]

Daar noemt u een extra reden voor mensen om Chrome of Firefox als standaard browser op Windows 10 te zetten, net terwijl ik dacht dat de tijden dat IE geen standaarden ondersteunt achter ons lagen.

[Verwijderd]

Microsoft zal daarvoor kiezen omdat er nog zaken spelen als dit:
http://finance.yahoo.com/...-files-two-162700176.html
Eerder heeft HTC al twee vp8 patentzaken afgekocht in een geschil met Nokia.

Het zou voor Microsoft op dit moment heel dom zijn om een miljard kopieen te verspreiden van een dergelijke codec.

Verder staat ook al vrij vast dat Apple de VP8 en VP9 codec niet zal ondersteunen dus voor alle relevante mobiele toepassingen is opname van de VP8 codec in WebRTC nutteloos. Daar ga je geen extra risico van een miljarden lawsuit mee lopen.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 22:01]

[mikesmit]

De standaarden zijn altijd tergend traag. HTML5 had eigenlijk al 10 jaar geleden klaar moeten zijn en komt als mosterd na de maaltijd. De ontwikkeling van HTML5.1 of 6 had nu al in een ver gevorderd stadium moeten zitten om voor te blijven lopen op de nieuwe ontwikkelingen en technische mogelijkheden.

Ook moeten standaarden pas gepresenteerd worden wanneer ze bijna klaar zijn om verschillende implementaties te vermijden

[lepel]

Mooi zo! Ik vind het heel interessant om deze artikelen te lezen. In het vorige artikel werd al genoemd dat Apple ook is toegetreden tot de WebRTC werkgroep en hier lees ik weer dat zelfs Microsoft het wilt gaan ondersteunen. Wat is er dan met Microsofts eigen CU-RTC-Web gebeurd?

In ieder geval: mooie ontwikkeling. Betere ondersteuning op mobiele platformen is gewenst en met het verplichtstellen van beide codecs weer een stap in de goede richting.

[Maurits van Baerle]

De twee standaarden gaan op termijn fuseren. Microsofts ideeen over hoe de standaard er uit zou moeten zien worden erg geprezen maar ze waren te laat en niet compatible met een enorme installed base aan bestaande SIP implementaties.

Er wordt nu gewerkt aan een update van WebRTC (versie 1.1 zeg ik uit m'n hoofd) waar een flink deel van Microsofts verbeteringen in zitten.

[lepel]

Ik dacht dat dit ORTC was en vooral een soort "add-on" word op WebRTC, maar ik kan ernaast zitten.

[Maurits van Baerle]

Klopt, het wordt een soort modulaire uitbreiding. Ik zal het linkje even zoeken...

Gevonden. Een van de mensen achter WebRTC legt uit hoe dit zo ontstaan is en waar ze nu mee bezig zijn qua convergentie: http://arstechnica.com/in...?comments=1&post=27973147

[Reactie gewijzigd door Maurits van Baerle op 23 juli 2024 22:01]

[lepel]

Thanks, die had ik nog niet gezien!

En voor mensen die meer over ORTC willen weten: http://ortc.org/

[Verwijderd]

WebRTC ORTC wordt ook wel WebRTC 2.0 genoemd.
Het is alleen niet backwards compatibel met WebRTC 1.0 dus huidige WebRTC 1.0 implementaties zullen vervangen moeten worden.

[biteMark]

En de grote afwezige in het rijtje, Safari? Is daar iets over bekend?

[JeffMetDubbelF]

Nope
http://iswebrtcreadyyet.com/

[lepel]

Apple heeft zich bij de WebRTC werkgroep gevoegd maar er is nog niks bekend over toekomstige ondersteuning. Hopelijk betekend dit dat er op korte termijn ondersteuning voor Safari en Mobile Safari aan zit te komen.

[biteMark]

Ik hoop het ook. Gezien de commerciële aard van Apple zie ik ze wel h264/h265 ondersteunen, maar VP8/VP9 van aartsvijand Google..?

[lepel]

Hoop niet dat ze zo kortzichtig zijn aangezien het een royalty free formaat is. Maar het is toch Apple en die zijn net zoals bijv. Microsoft graag koppig.

[biteMark]

Ik weet niet of het koppig is... Ik kan het me ergens ook nog wel voorstellen. Het is toch een belangrijke concurrent en die wil je niet graag in de kaart spelen. Apple wil Google natuurlijk niet groter maken dan het nu al is

[lepel]

Weet niet of je zou kunnen zeggen dat je Google groter maakt, VP8 is vrijgegeven onder een "irrevocable free patent license" dus de enige profijt die Google er van kan hebben is een bredere ondersteuning voor een royalty vrije codec. Ze verdienen er niks aan lijkt me en met ondersteuning in bijv. Safari maak je het webdevelopers alleen maar makkelijker en ondersteunen browsers dus 'meer' voor consumenten.

[Snippo]

Is er ook iets bekend over wanneer de browsers dit willen gaan ondersteunen?
Firefox ondersteunt beide al, maar geen enkele andere browser biedt op dit moment ondersteuning voor allebei.