X264-ontwikkelaar vindt VP8 onder meer buggy en langzaam

Volgens een ontwikkelaar van de x264-bibliotheek is de door Google vrijgegeven VP8-codec nog te buggy en langzaam. Ook zou het compressie-algoritme te veel lijken op h.264, waardoor in de toekomst alsnog patentproblemen kunnen ontstaan.

In een posting op het Diary Of An x264 Developer-weblog wordt de vrijgegeven code van de WebM-encoders en -decoders uitvoerig tegen het licht gehouden. De videokwaliteit van de VP8-codec, die deel uitmaakt van het nieuwe WebM-videoformaat, zou beter zijn dan het nu vrij te gebruiken Ogg Theora. De kwaliteit zou echter achterblijven bij die van video's die met de h.264-codec zijn gecomprimeerd. De ontwikkelaar plaatst de videokwaliteit tussen die van Xvid en de kwaliteit van Microsofts VC-1-codec. Hij plaatst ook kritische noten bij de kwaliteit van de broncode. De code zou slecht zijn gedocumenteerd en omdat zowel de encoder als de decoder grote stukken code delen, zouden bugs vrijwel altijd in beide onderdelen voorkomen.

Ook wordt de VP8-decoder als zeer langzaam bestempeld; hij zou zelfs trager zijn dan FFmpeg’s h.264-decoder. Ook de encoder zou traag zijn en onvoldoende snelheid hebben om op minder krachtige systemen realtime-compressie van hd-streams uit te voeren. De x264-bibliotheek zou in de snelste modus viermaal sneller videostreams kunnen comprimeren.

De x264-ontwikkelaar haalt ook een gevoelig punt aan over de mogelijke patentkwestie rondom het WebM-project. Hij stelt dat VP8 leentjebuur heeft gespeeld bij de h.264-codec. Volgens hem zouden gebruikers van de door Google als patentvrij aangeprezen WebM-codec zich hierdoor allerminst veilig moeten voelen.

Concluderend noemt de x264-ontwikkelaar de code van de VP8-codec nog niet geschikt voor grootschalig gebruik, omdat de broncode te buggy zou zijn en nog veel features mist. Ook zou het gevaar van patentclaims op de loer liggen. De keuze van Google voor de Matroska-container en de Ogg-audiocodec kan wel op goedkeuring rekenen; deze twee projecten zouden momenteel het beste zijn wat op dit gebied in de opensource-wereld is te halen.

Reacties (144)

[Peter]

De reden hiervoor is vrij duidelijk: het is een nieuwe codec. Waar H264 al vele jaren aan optimalisaties, zowel aan de encoder als decoder kant gekregen heeft, is VP8 nog een relatief nieuwe codec die pas sinds enige maanden überhaupt cross-platform is. Er wordt verwacht dat de codec in de komende maanden een enorm sterke boost gaat krijgen op het gebied van performance.

Daarnaast heeft Gregory Maxwell al inhoudelijk gereageerd op de opmerkingen van Jason Garrett-Glaser, wat zeker een interessant stuk is om te lezen. Ook Anne van Kesteren heeft er op zijn blog een bericht over gepost.

Uiteindelijk heeft Google met VP8 een hele reële optie geboden voor HTML5, het internet en mogelijk ook voor toepassingen op andere media. Door de codec totaal rechten- en kostenvrij uit te geven heeft VP8 daarmee een heel groot voordeel bovenop H264. Dat VP8 in de komende maanden z'n echte potentie nog moet laten zien is duidelijk, maar gezien namen als Mozilla, Opera, AMD, nVidia, Qualcomm, Skype, Adobe en Texas Instruments, en in mindere mate ook Microsoft (Apple heeft nog geen uitspraak gedaan) zich achter de codec positioneren mag het duidelijk zijn dat er zeker een toekomst is. Wat voor een toekomst, met welke ondersteuning, kwaliteit en interoperabiliteit dat zal nog moeten blijken.

[YopY]

De reden hiervoor is vrij duidelijk: het is een nieuwe codec.

Gemaakt met de kennis, ervaring en requirements van video en HD-video encoding die over de jaren opgebouwd zijn door deze of gene. Het wiel opnieuw uitvinden leidt in veel gevallen tot een beter wiel, indien goed uitgevoerd en/of door de juiste personen.

[Goderic]

De reden hiervoor is vrij duidelijk: het is een nieuwe codec. Waar H264 al vele jaren aan optimalisaties, zowel aan de encoder als decoder kant gekregen heeft, is VP8 nog een relatief nieuwe codec die pas sinds enige maanden überhaupt cross-platform is. Er wordt verwacht dat de codec in de komende maanden een enorm sterke boost gaat krijgen op het gebied van performance.

Dat dacht de auteur van het artikel eerst ook, maar het blijkt niet te kloppen:

nitially I was intending to go easy on On2 here; I assumed that this encoder was in fact new for VP8 and thus they wouldn’t necessarily have time to make the code high-quality and improve its algorithms. However, as I read through the encoder, it became clear that this was not at all true; there were comments describing bugfixes dating as far back as early 2004. That’s right: this software is even older than x264! I’m guessing that the current VP8 software simply evolved from the original VP7 software. Anyways, this means that I’m not going to go easy on On2; they’ve had (at least) 6 years to work on VP8, and a much larger dev team than x264’s to boot.

[Sorcerer8472]

Let wel dat x264 al een behoorlijk lang open-source ontwikkeltraject achter zich heeft waarbij encoder en decoder steeds beter zijn geworden binnen de bestaande H.264-standaard.

Google zelf geeft al aan dat VP8 nog een stuk beter kan binnen de bestaande standaard. Echter Jason Garrett-Glaser (die zelf aan x264 werkt, dus wel een beetje bevooroordeeld misschien) geeft aan dat hij denkt (na het doorlezen van de code) dat de kwaliteit van high profile h.264 niet haalbaar is binnen de huidige VP8-specificaties zoals Google die op tafel heeft gelegd.

Hij is van mening dat de specs nog zullen moeten worden aangepast om H.264-kwaliteit te bereiken. Ik vraag me af in hoeverre je dat kunt beoordelen door anderhalve dag met de code te spelen, maargoed, we zullen zien. Overigens geeft hij ook aan dat hij de specs niet heel duidelijk vindt, en dat er soms naar lappen (voorbeeld/referentie)code wordt verwezen in plaats van dat er daadwerkelijk een specificatie wordt neergelegd.

De kwaliteit in de screenshots die hij post ziet er aardig uit (hoewel high profile H.264 duidelijk beter is). Het is in ieder geval een stap voorwaarts vanaf Theora Video en ik denk/hoop dat de komende maanden duidelijk zal worden hoe het met patenten staat.

Hoe dan ook heeft Google mooi op een presenteerblaadje patches voor ffmpeg, een SDK en een reference encoder neergelegd. Als developer kun je dus al lekker aan de slag ermee

-toevoeging:-
En inderdaad: Garrett-Glaser vergelijkt met name High Profile H.264 met VP8, terwijl juist het Baseline Profile belangrijk is omdat juist dit op mobiele apparaten kan worden afgespeelt (High Profile is de hoge kwaliteit zoals het bijv. op blurays staat). Zie http://lists.wikimedia.or...ch-l/2010-May/047795.html (bedankt BtM909, had 'm nog niet gezien )

[Reactie gewijzigd door Sorcerer8472 op 1 augustus 2024 21:58]

[dj_tjerk]

Neemt niet weg dat Baseline H264 van x264 er nog steeds beter uitziet dan VP8. En je moet ook niet vergeten dat Jason duidelijk zegt dat VP8 een aantal nodeloos ingewikkelde algoritmes heeft (als in, cpu intensief). Sommige daarvan kan je dan weer uitzetten, maar ik denk niet dat ik wil zien wat dat met de kwaliteit doet.

Aan de andere kant kijk ik erg uit naar de ontwikkelingen van VP8, en ik hoop dat ze wat nuttige psy-optimizations kunnen doorvoeren (en daar zal Jason misschien wel bij willen helpen; zeker als zijn kindje MB-Tree in VP8 zou passen op een of andere manier).

[Verwijderd]

Garrett-Glaser vergelijkt met name High Profile H.264 met VP8, terwijl juist het Baseline Profile belangrijk is omdat juist dit op mobiele apparaten kan worden afgespeelt (High Profile is de hoge kwaliteit zoals het bijv. op blurays staat

Juist h.264 biedt dus de mogelijkheid om verschillende profiles ondersteuning t e bieden aan mobieltjes (baseline profile) en aan normale webcontent (main profile) en aan goede HD content (high profile).

Met VP8 schurk je aan bij de video voor mobiletjes kwaliteit. Dat is toch onzinnig voor gebruikers die een HD film willen van het internet voor op hun HD televisie.

Daarom blijft nu ook de noodzaak voor h.264 over.

[Reactie gewijzigd door Verwijderd op 1 augustus 2024 21:58]

[bram_001]

Waarom hebben ze dan niet gekozen voor een x264 codec?

[t-h]

Waarom hebben ze dan niet gekozen voor een x264 codec?

VP8 is onderdeel van het WebM videoformaat. Een gratis en open-source methode voor video-compressie. x264 is een open-source onderdeel van de met patenten beschermde H.264-methode voor video-compressie. De open-software is door patenten gesloten. Gebruik van VP8 is dus goedkoper (gratis), en daarmee economisch aantrekkelijker dan H.264/AVC.

Off-topic (enigszins):
Het biedt een interessante nieuwe factor in de oorlog van Apple tegen Adobe's Flash. Apple pleit voor HTML5 + H.264 video ter vervanging voor Adobe Flash Video. Door de patenten op H.264 is de door HTML5 getoonde video eigenlijk gesloten, en door de daarvoor te betalen licentiekosten zit niet iedereen op H.264 als standaard te wachten.

Kwalitatief gezien heeft Apple de beste keuze gemaakt: HTML5 is een snellere, stabielere en meer open keuze dan Flash, en zoals we vandaag hebben geleerd is H.264 voorlopig nog flink beter dan VP8. In de discussie rond open software is echter de keuze van Google een betere: HTML5 + WebM.

Google heeft nu een machtspositie. Ze zijn op YouTube begonnen met HTML5 spelers en sinds de introductie van de iPhone ondersteunt YouTube H.264 video's. De afhankelijkheid van Flash verkleint snel. Door een eigen open codec heeft Google de 'nuclear option': de optie om ondersteuning voor H.264 uit YouTube te schrappen en over te stappen op WebM. Apple zal moeten volgen.

Totdat Google beslist heeft Apple een strategische beslissing te maken. Door Google te paaien en vrijwillig over te stappen op WebM, en wellicht zelfs te helpen bij het verbeteren van de video-kwaliteit, kan Apple via WebM op de iPhone en iPad het bekijken van YouTube ondersteunen. Dan is iedereen klaar voor HTML5 en een open video-standaard. En dat is een hele zware klap voor Adobe's Flash.

@Carbon en @TGEN: klopt, verhaal bijgewerkt.

[Reactie gewijzigd door t-h op 1 augustus 2024 21:58]

[Verwijderd]

Flash is slechts een container. Er zijn verschillende videoformaten die ondersteund o.a. h264. Op de youtube servers staats alles in h264 formaat opgeslagen. Als je een filmpje bekijkt wordt deze data geladen, in een flashcontainer geplaatst en naar je browser gestuurd. Als je het filmpje vanaf een iPhone bekijkt wordt de data geladen en naar de youtube app gestuurd. Als je het bekijkt met html5 wordt het in de video tag gestuurd.

Mocht Google h264 schrappen op youtube dan is er vanaf vandaag op morgen niemand nog die die filmpjes kan bekijken behalve degenen die VP8 decoders hebben. Aangezien de standaard nu pas gepubliceerd is, zullen die niet veel mensen zijn. Jou nuclear option houdt dus zelfmoord in.

In het normalere geval, waarbij Google ook video's in VP8 wilt aanbieden heeft het tweemaal zoveel opslagruimte nodig. 1 keer voor het filmpje in h264 en 1 keer voor het filmpje in VP8. Dit brengt een extra kost met zich mee die in het geval van html5+h264 onbestaande is. Dus zelfs al heeft VP8 geen licentiekosten, dan wilt dat nog niet zeggen dat het ook goedkoper is.

Wat ik wil zeggen is dat technische vergelijkingen en open-source vs. closed maar een deel van het verhaal vormen. De economische realiteit maakt het witte vs zwarte ridder verhaal heel wat complexer.

[Verwijderd]

Mocht Google h264 schrappen op youtube dan is er vanaf vandaag op morgen niemand nog die die filmpjes kan bekijken behalve degenen die VP8 decoders hebben. Aangezien de standaard nu pas gepubliceerd is, zullen die niet veel mensen zijn. Jou nuclear option houdt dus zelfmoord in.

Dit is heel erg overdreven. Ze hoeven maar te wachten tot adobe VP8 cq WebM in flash geimplementyeerd vanaf dag kunnen ze per direct over naar VP8.

nieuws: Google geeft licentievrije WebM-videoformaat vrij

Google heeft zijn VP8-codec vrijgegeven onder de naam WebM. De videocodec zal onder andere ondersteund worden in de browsers van Mozilla en Opera, evenals IE9 van Microsoft. Adobe doet ook mee met zijn Flash-plugin.

In het normalere geval, waarbij Google ook video's in VP8 wilt aanbieden heeft het tweemaal zoveel opslagruimte nodig. 1 keer voor het filmpje in h264 en 1 keer voor het filmpje in VP8. Dit brengt een extra kost met zich mee die in het geval van html5+h264 onbestaande is. Dus zelfs al heeft VP8 geen licentiekosten, dan wilt dat nog niet zeggen dat het ook goedkoper is.

Het is wel goedkoper zodra Abode flash met WebM ondersteuning heeft kunnen ze h264 dumpen. Mogelijk dat dit zelfs als positieve effect heeft dat h264 ook licentie vrij wordt.

Wat ik wil zeggen is dat technische vergelijkingen en open-source vs. closed maar een deel van het verhaal vormen. De economische realiteit maakt het witte vs zwarte ridder verhaal heel wat complexer.

Helemaal niet waar omdat iedere belangrijke browser en Flash WebM gaan ondersteunen.

[Jeanpaul145]

... en zoals we vandaag hebben geleerd is H.264 voorlopig nog flink beter dan VP8.

Ik zou, gezien de bron, heel voorzichtig zijn met het klakkeloos aannemen van wat gezegd is als waar. De ontwikkelaar van x264 heeft heel veel te verliezen bij de succesvolle implementatie van VP8. Totdat dit door een onafhankelijkere bron bevestigd wordt zie ik alles wat hier gezegd is als FUD.

[Verwijderd]

De ontwikkelaar van x.264 heeft een behoorlijk goede reputatie en onderbouwt dat met codec die waarmaakt wat hij zegt.

On2 heeft een juist reputatie dat de door hen aangekondigde codecs VEEL slechter presteren dan ze eerder beweerden.
Zo zou VP7 al veel beter presteren dan h.264.
Een claim die ze ook nooit hebben waargemaakt.
En eerder beweerden ze dat VP8 50% beter zou presteren dan h.264.
Ook dat is nooit door iemand serieus genomen.

Ook heeft nooit sinds VP6 dat enige tijd in flash gebruikt is eigenlijk nooit meer een significate marktpartij een On2 codec in gebruik genomen. Toch wel vreemd als hun claims over superieure VP7 en VP8 codecs echt waaar geweest zouden zijn.

[Verwijderd]

Ook heeft nooit sinds VP6 dat enige tijd in flash gebruikt is eigenlijk nooit meer een significate marktpartij een On2 codec in gebruik genomen. Toch wel vreemd als hun claims over superieure VP7 en VP8 codecs echt waaar geweest zouden zijn.

IMO helemaal niet vreemd. On2 was een commerciële partij die licentie gelden vroeg. Als ze te duur waren of als ze van eindgebruikers ook verwachten dat ze licentie gelden betaalde is het snel einde oefening zeker als h264 op dat moment goedkoper was.

Nu Google eigenaar is van On2 is het roer omgegaan.

Ik kan me niet voorstellen dat de VP implementatie van On2 slecht zijn. Waarom zou Google veel geld betalen voor een bedrijf met brakke codec?
Dan hadden ze beter geld in het pushen van Theora kunnen steken.

[Verwijderd]

Waarom zou Google veel geld betalen voor een bedrijf met brakke codec?

Om controle te krijgen op de videocodec bijvoorbeeld.

[Reason]

Dat dacht ik dus ook precies. Wij van wc-eend!!
Maar goed, hij kan natuurlijk best gelijk hebben, maar tot er inderdaad een onafhankelijke partij zijn licht over heeft laten schijnen, zie ik het ook als gebakken lucht..

[packman]

Die persoon is een ontwikkelaar van een opensource h.264 implementatie. Die heeft weinig te 'winnen' bij het afbreken van VP8. Ook heeft hij een behoorlijk sterke reputatie in het hele video-codec wereldje.

Als je zijn beweringen zou gelezen hebben zou je zien dat deze technisch onderbouwd zijn, en merken dat die mens duidelijk weet waarover hij het heeft. Ook zegt hij zelf dat hij teleurgesteld is, en hij betwijfelt of dit formaat vrij van patenten kan zijn als het op sommige vlakken enorm op h.264 lijkt.

[TGEN]

x264 is ook open-source. Het probleem is echter dat de H.264 (ook bekend als AVC) standaard, welke x264 een encoder-implementatie van is, niet vrij is van patenten.

On-topic: het was al van mijlen ver aan te zien komen dat Dark Shikari VP8 niks zou vinden. Zijn kritiek spitst zich ook voornamelijk toe op de door Google beschikbaar gestelde implementatie, en niet zozeer op de standaard (die inderdaad veel weg heeft van H.264).

[Verwijderd]

Zijn kritiek spitst zich ook voornamelijk toe op de door Google beschikbaar gestelde implementatie, en niet zozeer op de standaard (die inderdaad veel weg heeft van H.264).

Hij noemt juist de specificaties for het formaat onduideleijk en vaag en niet implementeerbaar.

En wil je aub niet aan VP8 refereren als een standaard. Het is een propriety formaat van Google en dat heeft echt niets met een standaard te maken.
h.264 is namelijk WEL een standaard en wordt als formaat niet door een bedrijf gecontroleerd.

[kidde]

Hij noemt juist de specificaties for het formaat onduideleijk en vaag en niet implementeerbaar.

En hoe komt het dan dat het al door Opera, Mozilla en Adobe geimplementeerd wordt?

[Verwijderd]

Die kopieren gewoon decoder code die ze van Google gekregen hebben.
Is BSD licentie dus kan makkelijk in alle software overgekopieerd worden.

[kidde]

Exact, dat was wat ik wilde horen. Het wordt dus tijd dat de boel ITU / ISO-gecertificeerd wordt.

Hebben we de komende twee jaar tenminste weer iets te doen. Kijk, nu praten we

Kan ITU specificaties via fasttrack door ISO loodsen? Dan kan h.264 haar voorsprong als open standaard behouden.

[Verwijderd]

Het wordt dus tijd dat de boel ITU / ISO-gecertificeerd wordt

Het is een teken aan de wand dat Google de VP8 codec specificatie niet aan een stadnaardisatie instutuut heeft aangeboden.

Daardoor blijft het een propriety Google formaat en dat is een slechte zaak.

[Reactie gewijzigd door Verwijderd op 1 augustus 2024 21:58]

[kozue]

Het is een teken aan de wand dat Google de VP8 codec specificatie niet aan een stadnaardisatie instutuut heeft aangeboden.

Daardoor blijft het een propriety Google formaat en dat is een slechte zaak.

Niks Google-formaat. Ze hebben het vrijgegeven, onder een BSD-achtige licentie zelfs, jij kan het gewoon vrij gebruiken als je wilt. Het is net zo proprietary als een BSD kernel.

[Verwijderd]

Niks Google-formaat. Ze hebben het vrijgegeven, onder een BSD-achtige licentie zelfs, jij kan het gewoon vrij gebruiken als je wilt. Het is net zo proprietary als een BSD kernel.

Niks formaat onder BSD licentie.
Ze hebben de codec implementatie onder een BSD licentie vrijgegeven.

Het formaat bestaat uit een formaat defintie/specificatie en die kun je niet onder een software licentie vrijgeven. Daar hebben ze dus een aparte afgeleide licentie voor

De formaat licentie komt daarmee overeen met de gratis licentie voor de binaire office formaten van Microsoft die je ook gratis mag implementeren en gebruiken.

[Reactie gewijzigd door Verwijderd op 1 augustus 2024 21:58]

[Verwijderd]

Kan ITU specificaties via fasttrack door ISO loodsen? Dan kan h.264 haar voorsprong als open standaard behouden

AVC/h.264 is al jaren geleden een ISO/IEC standaard geworden en wordt sindsdien gezamelijk onderrhouden door ITU en ISO/IEC.

Zie ISO/IEC 14496-10 - MPEG-4 Part 10, Advanced Video Coding

[Verwijderd]

Het is niet alleen de open standaard het grote probleem is dat h264 voor altijd licentie vrij zal zijn.

Voor een opensource product is het praktisch zo goed als onmogelijk om licentie gelden te innen. Daarom is het beter om een open licentie en patent vrije implementatie te gebruiken.

[Verwijderd]

Voor een opensource product is het praktisch zo goed als onmogelijk om licentie gelden te innen.

Er wordt genoeg geld met browsers verdiend om die licentie te kunnen betalen. Bovendien kunnen ze ook best een deal sluiten met Google dat die de h.264 codec zouden leveren en de licentie ervan betalen. Zo ingewikkeld is dat niet en wel veel goedkoper dan een volledig nieuw codec introduceren die meer bandbreedte en opslagruimte kost

[Verwijderd]

Waarom ISO certificeren. ISO heeft geen waarde meer sinds Microsoft de boel opgeblazen heeft

[Blokker_1999]

VP8 mag dan geen ISO standaard zijn, het mag wel als standaard omschreven worden imho, zeker als er meerdere implementaties van (mogelijk) zijn kan je van een standaard spreken.

En h.264 word niet door een bedrijf gecontroleerd, maar wel door een grote groep bedrijven. En aangezien h.264 vol met patenten zit is het onmogelijk om er zo maar gebruik van te maken.

[Verwijderd]

Er zijn helemaal geen meerdere implementaties van. Iedereen kopieert gewoon die vrijgegeven rommel van Google/On2.
Dat kan ook niet anders want de spec is onvoldoende goed om de code uit te implmenteren.

[kozue]

Waarom die code opnieuwe schrijven als er al vrij beschikbare code voor is? Doe jij altijd werk dubbel voor je baas? Ga jij ook eerst je eigen office suite maken voordat jij een briefje gaat typen?
Het is helemaal niet nodig om nog een implementatie te maken. Wat wel nodig is, is een repository met een maintainer, waar mensen bugfixes enzo naartoe kunnen sturen, zodat de code bijgewerkt blijft, in plaats van na de release gaat zitten versloffen en iedereen er na een tijdje een eigen implementatie met eigen modificaties op na houdt.

[Verwijderd]

Waarom die code opnieuwe schrijven als er al vrij beschikbare code voor is?

Omdat die codec matig presteert bijvoorbeeld.
Trager dan x.264 wat al niet een al te snelle codec is.

[Carbon]

In tegenstelling tot x264 is VP8 open-source.

x264 is ook open-source!

[Reactie gewijzigd door Carbon op 1 augustus 2024 21:58]

[johnbetonschaar]

x264 is ook open source

[jDuke]

Licentiekosten

[Verwijderd]

De kosten van opslag bandbreedte zijn veelal hoger dan licentiekosten van h.264 video.

Een partij als Google zou de hele wereld van een gratis h.264 codec kunnen voorzien voor een fractie van de kosten die ze nu moeten maken om VP8 te promoten en die ze krijt zijn aan extra kosten voor opslag en datatransport.

[dj_tjerk]

Even voor de goede orde, google gebruikt net zo goed h264 hoor. En betaalt daar ook gewoon braaf licentiekosten voor.

En daarnaast, On8 had een gesloten codec die ze probeerden te verkopen (ook al viel te verwachten dat het zou voortboorduren op hun eerdere werk). H264 is ontwikkeld als een open standaard, met het hele proces van voorstellen etc. Je kan nu ook kijken wat voor voorstellen er al allemaal zijn voor h265 (veel rotzooi).

[Reactie gewijzigd door dj_tjerk op 1 augustus 2024 21:58]

[Verwijderd]

google gebruikt net zo goed h264 hoor. En betaalt daar ook gewoon braaf licentiekosten voor.

Voor youtube hoeven ze geen licentiekosten te betalen hoor.
Wel voor Chrome.

[Pyronick]

Nóg niet.

[Verwijderd]

En er is ook geen indicatie dat dat straks anders zal zijn.

[ajmwegman]

Goedkoper in bandbreedte, is bij een site als Youtube natuurlijk ontzettend belangrijk.
Niet te vergeten ook voor het milieu!

[Azzmodan]

Ik denk dat hij doelt op het feit dat Google nu zowel H264 voor de huidige apparaten moet ondersteunen alswel het nieuwe WebM formaat.

[cdwave]

Niet alleen kosten. De huidige H264 camera's komen met een verschrikkelijke licentie, die erop neer komt dat je filmpjes die je met de camera maakt niet op Youtube mag zetten.

bron:
http://www.osnews.com/sto...Threatened_by_the_MPEG-LA

[dmantione]

...waarbij wel de nuancering vergeten wordt dat bij een patent alleen het commercieel uitbaten van de uitvinding omvat en het dan nog om Amerikaanse patenten gaat die nergens anders geldig zijn.

D.w.z. je kunt rustig je filmpjes op Youtube zetten, want die zijn niet commercieel en ook niet onder Amerikaans recht geschoten.

[Reactie gewijzigd door dmantione op 1 augustus 2024 21:58]

[_Pussycat_]

hmm. Youtube/google is een amerikaans bedrijf en wil met de videos geld verdienen. Zouden zij dan niet op termijn in de problemen komen.

on-topic: hulde aan Google voor deze geweldige actie. Zonder Google was het internet nooit daar waar het vandaag is.

[dmantione]

Nou ja, problemen, Google betaalt gewoon voor het gebruik van MPEG4.

[leuk_he]

Je bedoeld licentie. Niet zozeer de kosten. De kosten zijn nu (relatief?) laag. Echter voor commercieel gebruik kunnen in de toekomst de kosten wellicht toenemen, of voor sommige modellen heel hoog uitpakken. Als je per stream moet betalen dan kan dat b.v. voor google heel erg hoog uitpakken.

[Verwijderd]

Echter voor commercieel gebruik kunnen in de toekomst de kosten wellicht toenemen.

Nee dat kan helemaal niet zo maar
Veel van de bedrijven in de MPEG-LA patentpool hebben zich vanuit hun medewerken aan de standaardisatie van h.264 of vanwege hun deelname in het blu ray consortium verplicht om de technolgie tegen reasonable tarieven ter beschikking te stellen.
Je kunt niet het ene jaar bedrag X reasonalbe noemen en dan ineens het dubbele. Daarmee beland je snel voor de rechter.

Daarnaast heeft de MPEG-LA patentpool die de licneties afhandelt ook regels daarvoor. Zo mogen tarieven per 5 jaar maximaal 10% stijgen.

[leuk_he]

Blijkbaar is die garantie niet genoeg. mozilla heeft juist om de onzekere toekomst gekozen om geen licentie te nemen.

Een gratis licentia (NU)omzetten naar 0,01 cent per afgespeelde video is heel redelijk, maar een enorme verhoging t.o.v. gratis.

[Verwijderd]

Mozilla heeft gekozen voor het gratis principe. Niks gelul met de onzekere toekomst.

Gewoon gratis is wat die willen

[Verwijderd]

patent vrij, dat is wat zij willen. Gratis is was anders

[Verwijderd]

Dat is onjuist want op VP8 rusten ook patenten. In iedergeval die van On2 (google) zelf.
Maar die worden gratis gelicensieerd door Google.
Gratis is dus waar het om gaat

[Azzmodan]

H264 is niet open, het kan dus nooit door iedereen vrij gebruikt worden.

WebM is wel open, iedereen kan dus hier een implementatie voor maken en dit gebruiken.

[Verwijderd]

h.264 is wel open. Iedereen kan daar een implementatie van maken en de spec worden gecontroleerd door een stadnaardisatierogaan met open besluitvormingsproces.

WebM is niet open want de VP8 specs geven onvoldoende informatie hoe je die specs moet implemnteren en Google controleert volledig de specificaties en kan die naar believen veranderen/aanpassen zonder inspraak van andere partijen.

[Azzmodan]

Dat de standaard beschikbaar is wil nog niet zeggen dat het open is. Mensen moeten er nog steeds voor betalen om het te mogen gebruiken, dat eind gebruikers het op het moment nog vrijelijk mogen gebruiken is niet relevant in dat.

WebM is volledig open en vrij, en uitgegeven onder een BSD licentie. Iedereen kan dar dus naar believen in aanpassen (alleen heb je dan de kans dat alle andere mensen je video niet meer kunnen spelen).
Dat de specs niet voldoende informatie geven voor een implementatie vind ik een bizarre claim die bots met het feit dat nu al Mozilla, Opera en Google een implementatie hebben gerealizeerd in hun browsers (respectievelijk Firefox Nightly, Opera Labs, Chromium).

[Verwijderd]

VP8 is als formaat precies net zo vrij als de binaire Office bestanden van Microsoft.
Alleen leveren die daar tien keer meer documentatie over.

[kidde]

WebM is niet open want de VP8 specs geven onvoldoende informatie hoe je die specs moet implemnteren en Google controleert volledig de specificaties en kan die naar believen veranderen/aanpassen zonder inspraak van andere partijen.

Zo is Microsofts OOXML Office Open XML toch ook begonnen Daar zag u geen problemen in, en dat is nu ook een open standaard. Toch?

[Verwijderd]

Microsoft heeft juist hun formaat aan een stadnaard organisatie overgedragen en die onwikkelen dat verder.
Microsoft is dus juist geen eigenaar van OOXML maar wel van de binaire .doc voorloper daarvan.

VP8 is meer als die binaire voorloper.
In handen van een bedrijf maar gratis te gebruiken.
VP8 is niet meer open als de .doc files van Microsoft.

[Sorcerer8472]

WebM is de container en die is wel open want WebM = MKV, met het enige verschil dat er behalve VP8+OggVorbis geen andere codecs in mogen! (geen idee of er wel subs en alternatieve audiotracks in mogen trouwens)

[Blokker_1999]

Weet je, dan kan je gaan zeggen dat ODF ook geen open standaard is. Die standaard mist namelijk ook nog een deel van zijn specificaties waardoor implementaties van elkaar verschillen.

En wat ben je met een standaard als je deze niet zomaar kan verdelen naar je klanten toe? Ga je hen de broncode geven en zeggen : compileer alles zelf maar en neem maar contact op met mpeg voor de licentiekosten?

Ik heb de vraag hier al eens eerder gesteld. Wat is het beste : een open standaard die niet gratis is, of een minder open standaard die wel gratis is?

[feelthepower]

Dat is een H264 implementatie...
Vanwege geld dus!

[imp4ct]

Goeie vraag, maar waarschijnlijk ligt het in het feit dat Google alles wat met die VP8 codec te maken heeft zelf heeft opgekocht.

Nu, ik veronderstel dat Google ook wel een team op deze codec zal plaatsen of het bedrijf / groep dat achter de codec zit gewoon z'n werk laat verder doen. 't Is niet dat Google niet over voldoene "smart minds" of geld beschikt om ervoor te zorgen dat deze codec een stuk beter wordt in de toekomst.

[Carbon]

x264 is een open-source encoder voor h264.

Waarschijnlijk weet je nu ook het antwoord op je vraag

[Grauw]

Let wel even op wie het schrijft he.

[Reactie gewijzigd door Grauw op 1 augustus 2024 21:58]

[spoonman]

... en omdat zowel de encoder als de decoder grote stukken code delen, zouden bugs vrijwel altijd in beide onderdelen voorkomen.

Ben ik nu echt de enige die hierbij de wenkbrauwen fronst?

[Reactie gewijzigd door spoonman op 1 augustus 2024 21:58]

[Carbon]

Ben ik nu echt de enige die hierbij de wenkbrauwen fronst?

Simpel voorbeeld:

// common.h
int scaling();

// common.c
int scaling()
{
return 2.1;
}

// encoder.c
#include "common.h"
int encode(int i)
{
return i * scaling();
}

// decoder.c
#include "common.h"
int decode(int i)
{
return i / scaling();
}

Stel dat in een nieuwe versie iemand een typefout (2.11 ipv 2.1) in scaling() heeft gemaakt, deze fout wordt niet opgemerkt omdat decode(encode(n)) gewoon n oplevert, maw precies wat je verwacht.

Het probleem wordt pas ontdekt als iemand met de nieuwe decode() iets probeert te decoderen wat met de oude encode() is gecodeerd.

Video codecs zijn natuurlijk veel complexer dan dit voorbeeld, dergelijke bugs kunnen zich b.v. manifesteren als moeilijk waarneembare artifacts. De één ziet het de andere niet.
De kans dat het te laat wordt ondekt is dus heel reëel en dat kan een groot probleem worden als je al video gecodeerd hebt met de 'foute' codec.

Dat het nu al een probleem is blijkt wel uit de discussie die Garrett-Glaser aanhaalt:

<derf> gmaxwell: It survives it with a patch that causes artifacts because their encoder doesn’t clamp MVs properly.
<gmaxwell> ::cries::
<derf> So they reverted my decoder patch, instead of fixing the encoder.
<gmaxwell> “but we have many files encoded with this!”
<gmaxwell> so great.. single implementation and it depends on its own bugs.

[Reactie gewijzigd door Carbon op 1 augustus 2024 21:58]

[dotnetpower]

Daarvoor hebben ze dus "Unit Testing" voor uitgevonden :-)

Edit:
@carbon hieronder:
Geen idee of ze daaraan gedacht hebben, ik heb de code zelf niet doorgenomen / ingezien, overigens hebben ze code volgens mij net in handen en zullen ze misschien eerder bezig geweest zijn met de grove kantjes recht te strijken en eventueel documentatie te maken, afhankelijk van in wat voor staat ze alles hadden aangetroffen, daarop zit dan ook nog de "druk" van de community om dit z.s.m. te doen.

Het ging me verder puur om je voorbeeld, normaal gesproken schrijf je vooraf of achteraf Unit tests op basis van de specificaties en om delen van je code te testen in verscheidene situaties, als iemand dus om whatever reason een typo maakt zoals in je voorbeeld zou die dus nooit door de test heen komen omdat degene die de specificatie heeft bedacht en een unit test heeft geschreven niet die output verwacht.

Oftewel je voorbeeld zou dan niet opgaan omdat de output die verwacht wordt bij de decode en encode functie direct failed in de unit test :-)

Overigens moet je altijd even je changes controleren eer je ze commit in SVN / CVS,
ook om te voorkomen dat je nog wat test code erin hebt staan en commit ;-)

En zal iemand de commits die gedaan zijn moeten valideren.

[Reactie gewijzigd door dotnetpower op 1 augustus 2024 21:58]

[Carbon]

Wel vreemd dat ze bij een bedrijf als Google daar niet aan gedacht hebben

Unit testen gaat je in het geval van een lossy video codec niet helpen omdat b.v. een kleine aanpassing al invloed heeft op de output.

[Keypunchie]

Waarom zou je de wenkbrauwen fronsen?

Ik ben geen programmeur, maar hergebruik van code lijkt me alleen maar efficient. Op zich zijn encoderen en decoderen van video twee zeer gerelateerde zaken, dus waarom geen code hergebruiken?

En als je een bugje uit de een haalt, dan haal je hem dus ook meteen uit de andere.

[spoonman]

Ja, dat bedoel ik dus ... (volgens het artikel is dat dus een negatief punt)

[Reactie gewijzigd door spoonman op 1 augustus 2024 21:58]

[Laurens-R]

Nee, ik zat dat stuk ook al enigzins vertwijfeld te lezen.... bij dat soort uitspraken ga je toch twijfelen aan de beste man Wat een kulargument. Duidelijk gevalletje... ik zal en moet slechte punten vinden.

Nog nooit van een developer gehoord die tegen code re-use is!

[Reactie gewijzigd door Laurens-R op 1 augustus 2024 21:58]

[dj_tjerk]

Niet zozeer dat. Maar er is geen duidelijke standaard waaraan de decoder of encoder aan moet voldoen. De standaard staat ahw in de implementaties, en als die implementaties fout zijn, gaat het mis.

Om het anders te zeggen, schrijvers van nieuwe decoders weten niet precies hoe ze een decoder moeten implementeren, omdat er niet ergens eenduidig staat aan welke eisen een decoder moet voldoen. Het enige wat ze hebben is een buggy implementatie.

[Verwijderd]

Nee, ik dacht ook gelijk: 'Huh.. generieke implementatie is toch juist iets goeds?'
Refactoring is iets waar nogal op gehamerd wordt.
Het houdt nl. ook in dat als je een bug oplost, het gelijk op 2 plaatsen is opgelost.

Met twee verschillende code-trees die hetzelfde zouden moeten doen krijg je al snel dat ze uit sync gaan lopen. Stel je voor dat je ergens een buffer van 32K alloceert, en om wat voor reden dan ook verhoog je die naar 48K. Op een gegeven moment heb je dus een encoder die ergens een buffer van 32K gebruikt en een decoder die een buffer van 48K gebruikt. Op het oog niets mis mee, maar op een gegeven moment, bij bepaalde uitzonderingssituaties gaat de encoder dood en de decoder niet. Als je maar genoeg van dat soort situaties hebt, ben je op een gegeven moment vanzelf de wanhoop nabij.

[Reactie gewijzigd door Verwijderd op 1 augustus 2024 21:58]

[jwstolk]

Door de zelfde code twee keer te gebruiken heb je ook dubbel zo veel kans om om de bug te vinden. Dit lijken mij dus juist allemaal voordelen. Dit in combinatie met het noemen van "gevaar van patentclaims" terwijl ze zelf juist met hun X264 patenten schermen, maakt de reactie van de X264 ontwikkelaars erg ongeloofwaardig.

[Verwijderd]

Een fout wordt toch opgeheven omdat in het decodeer deel ook dezelfde fout zit?
Edit: zo dat was slecht typ werk

[Reactie gewijzigd door Verwijderd op 1 augustus 2024 21:58]

[Verwijderd]

Er kijken nu miljoenen ogen naar de code, dus die bugs zullen verdwijnen. Dat zouden ze bij mpegla ook eens moeten proberen.

[mashell]

Er kijken nu miljoenen ogen naar de code, dus die bugs zullen verdwijnen

Naar code kijken doet geen bugs verdwijnen en we hebben al eerder bij open source code gezien dat deze amper na gelezen wordt. Het is echt maar een handje vol fantiekelingen die dat doen. Het succes van open source is niet de openheid maar dat die openheid vrije verspreiding en gebruik afdwingt.

[Verwijderd]

Inderdaad, code lezen alleen is niet genoeg, dat kan iedereen wel. De tijd erin steken de code te begrijpen, dat is andere koek. Ik zie ook vaak genoeg andermans code voorbij fietsen, maar om te begrijpen wat bepaalde code doet, en waarom (en vooral ook, waarom niet op een andere manier) dat kost toch aardig wat tijd, hoor.

[dj_tjerk]

Wat moeten ze proberen? Er is een H264 reference encoder, en daar kijken ook genoeg slimme ogen naar, en daar worden ook gewoon bugjes in gefixt (maar dat zijn er niet veel). Verder heeft de MPEG-LA daar niet zoveel mee te maken, die beheert voornamelijk de patent-pool.

[Verwijderd]

MPEG-LA doet in patenten. Dat is per definitie gepubliceerde en voor iedereen inzichtelijk informatie.

[Reactie gewijzigd door Verwijderd op 1 augustus 2024 21:58]

[kidde]

"We claim:

1. A computer-readable medium storing computer-executable instructions for causing a video decoder programmed thereby to perform a method of reconstructing one or more video images in a video sequence, the method comprising: for each macroblock of plural macroblocks, decoding a coded block pattern, wherein the coded block pattern includes first coded block pattern information for plural luminance blocks of the macroblock, wherein the coded block pattern includes second coded block pattern information for plural chrominance blocks of the macroblock, wherein the coded block pattern indicates which of the plural luminance blocks and the plural chrominance blocks have corresponding transform coefficient data in a bitstream, wherein each of the plural macroblocks has a macroblock type, wherein the macroblock type is intra for at least one of the plural macroblocks, and wherein the decoding comprises for each macroblock of the plural macroblocks: receiving an entropy code in the bitstream, wherein the received entropy code reflects joint entropy encoding of the first coded block pattern information together with the second coded block pattern information, and determining the coded block pattern for the macroblock based at least in part upon the received entropy code; and using the coded block pattern for each macroblock of the plural macroblocks during reconstruction of the one or more video images. "

Jahoor, dat begrijpt iedereen, veel overzichtelijker dan code

[Reactie gewijzigd door kidde op 1 augustus 2024 21:58]

[CAPSLOCK2000]

Ik heb al ergens gelezen dat het na-apen van h264 juist een voordeel is vanuit het oogpunt van patenten.

Als je als ontwikkelaar de specificatie van h264 pakt en vervolgens zorgt dat je onderdelen die gepatenteerd zijn een klein beetje aanpast zodat het net niet meer onder het patent valt, dan heb je een codec die bijna net zo goed is al h264 en toch geen h264 patenten schendt.

De kans dat het andere patenten schendt is dan maar heel klein want dan had h264 dat waarschijnlijk ook gedaan. Als er toch een patent wordt geschonden dan zal de eigenaar ook het h264 consortium moeten aanvallen en dat is zo zwaar verdedigd dat niemand dat aandurft.

Persoonlijk vind ik een vrije codec belangrijker dan een super compacte codec. Bandbreedte en rekentijd worden steeds goedkoper, h264 licenties niet.

[Reactie gewijzigd door CAPSLOCK2000 op 1 augustus 2024 21:58]

[Laurens-R]

Daar zit al een probleem; patenten gaan zelden over een specifieke implementatie, maar meer over een overkoepelende denkwijze/idee/technologie zonder specifiek op de exacte werking in te gaan.

Dus simpelweg na-apen met een paar wijzigingen gaat simpelweg niet werken.

[Reactie gewijzigd door Laurens-R op 1 augustus 2024 21:58]

[The_Worst]

Niet helemaal waar.

Gregory Maxwell zegt als reactie op deze x264-ontwikkelaar:

Codec patents are, in general, excruciatingly specific — it
makes passing the examination much easier and doesn't at all reduce
the patent's ability to cover the intended format because the format
mandates the exact behaviour.

Oftewel, dat patenten heel specifiek zijn klopt normaal wel maar juist bij codecs zijn ze zeer specifiek. Vandaar dat er dus ook ongeveer 1200 patenten van 25 bedrijven op H.264 zitten.

[Reactie gewijzigd door The_Worst op 1 augustus 2024 21:58]

[kidde]

Volgens een Xiph ontwikkelaar wel:

There is a good defense. When someone actually gives you the patent
numbers of the patents that they claim you infringe. You can often code
around it. I have read a lot of "codec" patents. Many can be avoided by
simply doing things differently-but mathematically "equivalent" as far
as the format is concerned.

van de mailing-lijst

De mensen bij Xiph zijn degenen die VP3 distribueren en dus het risico lopen aangeklaagd te worden. Dus vermoedelijk weten ze waar ze het over hebben, en anders gaat het zeker binnenkort blijken.

[Verwijderd]

Zo heeft bijvoorbeeld On2 gekozen om B-frames te vermijden.
Dat is echter een slechte beslissing die veel compressie potentieel teniet doet en de codec gewoon minder goed maakt.

[Verwijderd]

interessant, zoveel ge-bash door hAl. Is een duidelijk teken dat MS belang heeft bij een 'overwinning' van h.264 Waarom zou je denken. Wellicht om het OSS projecten wat moeilijker te maken...

[Verwijderd]

hAl = Microsoft medewerker?

[hackerhater]

Gezien zijn gedrag hier en op webwereld : ja
En nog een mega irritante ook

[Verwijderd]

Nee

[Verwijderd]

Wat ben jij een eng klootzakje zeg Kidde.
Wordt jij betaald om hier andere mensen aan te vallen of zo?

[Verwijderd]

Tenzij natuurlijk het h264 consortium het schenden van patenten aanklaagt. Ook hoeft de eigenaar niet per se het h264 consortium aan te vallen. Eén van de grootste nadelen van open-source op dit vlak is dat iedereen die het gebruikt een doelwit is. Een bedrijf kan in principe zelfs individuen aanklagen. Bij h264 geeft de licentie je ook een bescherming. Een bedrijf kan nooit individuen aanklagen maar alleen diegenen die de licentie uitschrijven m.a.w. het h264 consortium.

Voor sommige bedrijven weegt het op om licenties te betalen en zodoende zich in te dekken tegen evenuele derden.

[Kheldar]

MPEG-LA geeft alleen licenties uit voor de patenten die de partners ook daadwerkelijk in bezit hebben. Als er dus een derde partij op de proppen komt met een eerder patent, dan mogen alle individuele gebruikers alsnog betalen.

Doordat er echter zoveel bedrijven vertegenwoordigd zijn in MPEG-LA, is de hoeveelheid patenten die ze samen bezitten enorm. Mocht er dus een derde partij op de proppen komen met zo'n eerder patent, dan zullen deze bedrijven er alles aan doen om dit bedrijf te stoppen, om zo hun gebruikers via een omweg te beschermen en hun eigen geloofwaardigheid te bewaren.

Waarschijnlijk wordt het dan weer een standaard patent war, waarbij partij A partij B aanklaagt om patent 1 en vervolgens partij B partij A aanklaagt om patent 2 en er uiteindelijk niets gebeurt.

Bij open source is deze strategie veel lastiger, door het gebrek aan de enorme hoeveelheden patenten op van alles en nog wat. Maar als er een partij met eerdere patenten op de proppen komt, moet er in principe bij zowel open source als bij h264 betaald worden.

[Reactie gewijzigd door Kheldar op 1 augustus 2024 21:58]

[BtM909]

Tja, iedereen kan kritiek geven, maar dan moet het wel iets onderbouwder zijn dan nu

http://lists.wikimedia.or...ch-l/2010-May/047795.html
You should have seen what VP3 was like when it was handed over to
Xiph.Org. The software was horribly buggy, slow, and the quality was
fairly poor (at least compared to the current status).

Jason's comparison isn't unfair but you need to understand it for what
it is— he's comparing a very raw, hardly out of development, set of
tools to his own project— which is the most sophisticated and mature
video encoder in existence. x264 contains a multitude of pure encoder
side techniques which can substantially improve quality and which
could be equally applied to VP8. For an example of the kinds of pure
encoder side improvements available, take a look at the most recent
improvements to Theora:
http://people.xiph.org/~xiphmont/demo/theora/demo9.html

Ik verwacht dat hier heel snel verbeteringen in gaan komen en met de push vanuit Adobe's Flash en Youtube

[Verwijderd]

Een groot probleem is dat nu iedereen die 'kut code' die Google nu gereleased heeft aan het kopieren is en aan het inbouwen.
Ook gaan nu alle codec vergelijkingen die 'matige code nu uittesten en de verschillen publiceren. dat gaat natuurlijk geen websites overhalen om h.264 op te geven. Die willen gewoon de beste kwaliteit video leveren tegen de minste bandbreedte.

En iedereen heeft toch wel h.264 iop zijn/haar computer staan.

[Goderic]

Zoals ik hier ergens boven ook al gezegd heb, uit het artikel van deze x264 dev:

Initially I was intending to go easy on On2 here; I assumed that this encoder was in fact new for VP8 and thus they wouldn’t necessarily have time to make the code high-quality and improve its algorithms. However, as I read through the encoder, it became clear that this was not at all true; there were comments describing bugfixes dating as far back as early 2004. That’s right: this software is even older than x264! I’m guessing that the current VP8 software simply evolved from the original VP7 software. Anyways, this means that I’m not going to go easy on On2; they’ve had (at least) 6 years to work on VP8, and a much larger dev team than x264’s to boot.

Wat er in die mail staat is dus ronduit onzin. Deze software is al 6 jaar oud, ouder dan x264.

[Reactie gewijzigd door Goderic op 1 augustus 2024 21:58]

[Verwijderd]

Ook wordt de VP8-decoder als zeer langzaam bestempeld; hij zou zelfs trager zijn dan FFmpeg’s h.264-decoder.

!=

Decoder: Seems to be straightforward enough. Nothing jumped out at me as particularly bad, slow, or otherwise, besides the code quality issues mentioned above.

[xentron]

Gek dat het in het tweakers.net artikel dan anders word geschreven dan op de x264 diary blog. Lijkt mij juist dat hij alleen maar critisch is over de huidige stand van de codec en de encoder, dat het misschien nog wat teveel lijkt op hoe H.264 werkt en over de nog aanwezige bugs.

Ik ben wel benieuwd naar de toekomst van VP8, als het straks een beetje dezelfde kwaliteit kan leveren als de H.264 codec zonder de licentie kosten kan het zeker een leuk alternatief worden om te gaan gebruiken in de HTML5 spec. Nu alleen maar hopen dat je niet voor elke browser een andere codec nodig hebt. Zijn we eindelijk een beetje cross-browser compatible met HTML/CSS (eindelijk geen (of in ieder geval nauwelijks) losse stylesheets meer nodig voor huidige IE browsers) krijgen we deze onzin weer.

We zullen zien wat er gaat gebeuren.

[Verwijderd]

Lijkt mij juist dat hij alleen maar critisch is over de huidige stand van de codec en de encoder

Behalve dan dat de spec final is en de decoder nu als referentie dient voor anderen zodat er straks heel veel slechte implementaties ontstaan.
Als google had gewacht en de spec had verbeterd een de codec had verbeterd hadden ze volgens deze ontwikkelaar een veel beter product opgeleverd.

[Blokker_1999]

Aangezien het nu open source is kan er desnoods een gemeenschap zich achter de verbetering zetten. Het is trouwens de open source wereld die om de vrijgave van deze codec gevraagd heeft.

[Verwijderd]

De codec code is open source.
De specificatie is gewoon van Google en die mag je niet veranderen.

[kidde]

Wat een nonsense, elders klaagt u dat er geen specificatie is, en nu is de specificatie van Google?

Uit een stukje software kan men een formaat afleiden. En bij VP8 is dat makkelijk omdat de software open source is, en het van de eigenaar van de software mag.
Wie de standaard heeft afgeleid, kan hem veranderen, immers: Nergens staat dat dat niet mag, en uitgeven, dat is nu eenmaal het gevolg van de BSD licentie.

Dus dat iets dat er niet is van Google is, is toch een beetje raar? Iedereen kan uit de implementatie de standaard afleiden, en wie dat doet bezit op dat moment de standaard.

[Goderic]

Maar als je encoder van de standaard specificatie afwijkt heb je gewoon een andere codec gemaakt die incompatibel is met decoders die wel de standaard specificatie volgen.

Met als gevolg dat je een betere codec hebt die niemand kan afspelen.

[Thundy]

Het idee lijkt mij dan ook dat je uit de encoder de standaard afleid en vervolgens zelf een eigen betere encoder schrijft voor dezelfde standaard...

Maar volgens mij vind deze blogger de standaard zelf gewoon slechter dan H.264 want hij geeft ook gelijk aan dat hij geen grote verbeteringen voor de encoder code ziet.

Kortom met slechte referentiecode kun je een eind komen zolang de standaard maar ruimte tot verbetering mogelijk maakt.

[Verwijderd]

Er is wel degelijk een bitstream formaat specificatie en er is ook open source codec software.
Helaas staat in de bitstream formaat specificatie niet alleen een beschrijnving in van het formaat maar staat die ook vol met allerlei C code.
Een formaat druk je normaal niet uit in C software.
Dat is een teken dat de specifciatie niet goed beschreven is en dat ze dan maar uit hun eigen implimentatie code in de formaat specifcatie hebben gestopt. Dat is heel slecht omdat daardoor het formaat niet goed optimaliseerbaar is.

[Goderic]

Zoek dan ook even het juiste stukje?

VP8, as a decoder, decodes even slower than ffmpeg’s H.264. This probably can’t be improved that much.

[matzo]

Waarom, als het artikel intern zichzelf tegenspreekt, moet tweakers daarop wijzen, niet zomaar 1 van de twee visies zonder argumentatie overnemen.

[Verwijderd]

Ik zie geen tegenspraak.
Dat je geen losse elementen zie die de codec nodeloos traag maken betekent nog niet dat de codec goed presteert. Het duidt er eerder op dat de performance een structureel probleem is dat moeilijk oplosbaar is omdat er niet een duidelijke bottleneck is aan te wijzen.

[Verwijderd]

Kortom hij spreekt zich zelfs tegen!

Mooi betrouwbaar artikel.

Heeft iemand de WC eend gezien?

[humbug]

Niet echt. De code is schijnbaar traag maar er zitten geen duidelijk slechte stukken tussen die, wanneer aangepakt, snel grote verbetering in de performance kunnen opleveren.

[jessewillem]

Maar als VP8 toch de standaard wordt. Zal de code waarschijnlijk wel verbeteren. Maar ik vind dat men niet uit mag gaan op een blog voor nieuws.

[Mellow Jack]

Vind de persoon die de blog schrijft... Al had jij het gevonden of al was het een feit was het wel onderbouwd met argumenten enz

[packman]

Maar het gaat hier wel over een persoon die in het hele video-codec wereldje een ijzersterke reputatie heeft... Hij heeft zelf al meerdere keren op z'n blog zwaktes van h.264 aangehaald, en is heeft overlaatst zware critiek geuit op voorstellen voor de h.264 opvolger als zijnde zinloos en onrealistisch in 'real world' applicaties...

Ik volg z'n blog al enige tijd - en dit lijkt me niet meteen iemand die blind zijn videoformaatje gaat verdedigen.

[mcDavid]

"wij van WC-eend..."

Het kan trouwens best dat h.264 beter is. Dat mag best. Maar VP8 is licentievrij en open-source. En daarom zéér geschikt voor web-based content.

Blijven we h.264 lekker gebruiken voor de HD-films, en VP8 voor de lolcats.

[Carbon]

Maar VP8 is licentievrij

Dat is maar de vraag......

[Verwijderd]

VP8 is niet open source. het is een formaat met open-source implementatie.

h.264 is een echte standaard die ook geimplementeerd is in open source

[Pyronick]

Zover ik weet is WebM een container formaat, VP8 is slechts een video codec. En die is wel geheel open-source volgens een BSD-type licentie model.
Vrijwel hetzelfde BSD licentie model als Android, Chrome, Vorbis, Theora en nu ook WebM zelf.
Alleen Matroska valt onder de LGPL licentie, welke zover ik weet nóg "vrijer" is.

Zover ik weet is H.264 wel gesloten, enkel de broncode van de encoders/decoders zijn open.

Correct me if I'm wrong though.

[Verwijderd]

Een formaat zoals VP8 (of ook WebM) kan niet open source zijn.
Een formaat heeft namelijk geen source maar heeft een specificatie/definitie. Als deze specificatie voor iedereen beschikbaar is en voor iedereen is in te bouwen is het formaat in principe open.

Een BSD licentie is een software licentie en kan dus ook niet gelden voor het formaat maar wel voor de codec die ermee gebouwd is. Die codec kan naturlijk wel open source zijn.

h.264 is een standaard van ITU en ISO/IEC en de specificatie daarvan is voor iederen beschikbaar. Het formaat zelfs is dan ook gewoon een open formaat.
De technologie gebruikt in alle h.264 implementaties is echter wel deels gepatenteerd. De codec is dus niet echt vrij (als in vrij van patenten). De bekende patenten zijn echter wel alle RAND (dus tegen redelijke tarieven en bruikbaar voor iedereen) gelicensieerd. Dat is gebeurd via een patentpool.

Ook voor h.264 kunnen er open source codec implementaties zijn.
De bekendste daarvan is in ieder geval x.264. De bekenste gesloten implementatie is die van CoreAVC die vooral bekend staat om de zeer efficiente decoder.

[ytsmabeer]

Patenten patenten en nog eens patenten.
Daar zal alles wel weer op uit draaien.
De maker van VP8 is ouder dan H264, maar zover uik begrijp is er geen documentatie over de patenten uit die tijd.
H264 dat later kwam heeft wel patenten op papier staan, en kan dus anderen aanklagen, dat terwijl er een grote kans is dat hun patenten of uitvindingen niet door hun gedaan zijn, maar wel door hun gepatenteerd.

Overigens blijkt uit niets dat theora en ogg voor H264 moest vrezen om de patenten, de grote fabrikanten verwachten nou juist uit een verborgen patenthouder die straks ineens op staat en geld claimed.

To be continued

[Sorcerer8472]

Nee, VP3 (nu Theora Video) is ouder dan H264. Op een pagina achter één van de links hierboven wordt aangegeven dat bij Theora niemand zich zorgen maakte om patenten, onder andere ook omdat VP3 zo oud is dat delen eerder als prior art voor H264 werden gezien dan andersom. Da's dus wat anders en om die reden heeft daar ook nooit iets over patenten gespeeld (wat bijv. wel bij Microsofts VC1 is gebeurd, google er maar op).

En verder is het inderdaad afwachten... Vooral grote bedrijven kunnen erg veel last krijgen van zo'n soort rechtszaak, als die er komt... We zullen zien dus.