X264-ontwikkelaar vindt VP8 onder meer buggy en langzaam

Reacties

« 1 2 »

Door bram_001, donderdag 20 mei 2010 14:48

Waarom hebben ze dan niet gekozen voor een x264 codec?

Door jDuke, donderdag 20 mei 2010 14:50

Licentiekosten

Door cdwave, donderdag 20 mei 2010 15:14

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

Door dmantione, donderdag 20 mei 2010 18:46

...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 donderdag 20 mei 2010 18:47]

Door _Pussycat_, donderdag 20 mei 2010 22:52

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.

Door dmantione, vrijdag 21 mei 2010 08:07

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

Door hAl, donderdag 20 mei 2010 15:21

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.

Door kidde, donderdag 20 mei 2010 15:42

Door ajmwegman, donderdag 20 mei 2010 15:46

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

Door Azzmodan, donderdag 20 mei 2010 15:47

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

Door dj_tjerk, donderdag 20 mei 2010 15:48

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 donderdag 20 mei 2010 15:50]

Door hAl, donderdag 20 mei 2010 16:22

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.

Door Pyronick, donderdag 20 mei 2010 17:40

Nóg niet.

Door hAl, donderdag 20 mei 2010 17:44

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

Door leuk_he, donderdag 20 mei 2010 15:55

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.

Door hAl, donderdag 20 mei 2010 16:27

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.

Door leuk_he, donderdag 20 mei 2010 17:15

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.

Door hAl, donderdag 20 mei 2010 17:45

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

Gewoon gratis is wat die willen

Door loetje6, donderdag 20 mei 2010 18:46

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

Door hAl, vrijdag 21 mei 2010 08:02

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

Door feelthepower, donderdag 20 mei 2010 14:50

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

Door t-h, donderdag 20 mei 2010 14:51

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 donderdag 20 mei 2010 15:26]

Door Carbon, donderdag 20 mei 2010 15:02

In tegenstelling tot x264 is VP8 open-source.

x264 is ook open-source!

[Reactie gewijzigd door Carbon op donderdag 20 mei 2010 15:03]

Door TGEN, donderdag 20 mei 2010 15:04

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).

Door hAl, donderdag 20 mei 2010 15:25

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.

Door kidde, donderdag 20 mei 2010 15:43

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?

Door hAl, donderdag 20 mei 2010 16:30

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

Door kidde, donderdag 20 mei 2010 16:39

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.

Door hAl, donderdag 20 mei 2010 17:47

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 hAl op donderdag 20 mei 2010 17:47]

Door kozue, vrijdag 21 mei 2010 00:10

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.

Door hAl, vrijdag 21 mei 2010 08:19

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 hAl op vrijdag 21 mei 2010 08:21]

Door hAl, donderdag 20 mei 2010 17:50

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

Door loetje6, donderdag 20 mei 2010 19:01

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

Door worldcitizen, donderdag 20 mei 2010 22:22

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.

Door hAl, zaterdag 22 mei 2010 14:31

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

Door Blokker_1999, donderdag 20 mei 2010 15:46

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.

Door hAl, donderdag 20 mei 2010 16:31

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.

Door kozue, vrijdag 21 mei 2010 00:12

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.

Door hAl, zaterdag 22 mei 2010 14:32

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.

Door Wientje, donderdag 20 mei 2010 15:36

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.

Door worldcitizen, donderdag 20 mei 2010 22:11

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.

Door Jeanpaul145, donderdag 20 mei 2010 15:38

... 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.

Door hAl, donderdag 20 mei 2010 16:47

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.

Door worldcitizen, donderdag 20 mei 2010 22:16

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.

Door hAl, zaterdag 22 mei 2010 14:34

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

Om controle te krijgen op de videocodec bijvoorbeeld.

Door Reason, donderdag 20 mei 2010 17:39

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..

Door packman, donderdag 20 mei 2010 18:16

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.

Door johnbetonschaar, donderdag 20 mei 2010 16:49

x264 is ook open source

Door imp4ct, donderdag 20 mei 2010 14:53

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.

Door Carbon, donderdag 20 mei 2010 14:54

x264 is een open-source encoder voor h264.

Waarschijnlijk weet je nu ook het antwoord op je vraag

Door Azzmodan, donderdag 20 mei 2010 15:03

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.

Door hAl, donderdag 20 mei 2010 15:27

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.

Door Sorcerer8472, donderdag 20 mei 2010 15:45

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)

Door Blokker_1999, donderdag 20 mei 2010 15:49

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?

Door Azzmodan, donderdag 20 mei 2010 15:54

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).

Door hAl, donderdag 20 mei 2010 16:50

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

Door kidde, donderdag 20 mei 2010 16:41

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?

Door hAl, donderdag 20 mei 2010 17:54

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.

Door Grauw, donderdag 20 mei 2010 21:36

Let wel even op wie het schrijft he.

[Reactie gewijzigd door Grauw op donderdag 20 mei 2010 21:37]

Door johnkessels87, donderdag 20 mei 2010 14:49

Dit gaat net boven mijn pet... kan iemand dit voor mij simpel uitleggen?

Door appel437, donderdag 20 mei 2010 14:52

simpel: "Wij van WC eend, adviseren WC-eend"

dit zijn 2 videocodecs die concurreren om de nieuwe standaard te worden. neem dit dus vooral niet te serieus.

Door Rainlife, donderdag 20 mei 2010 15:03

strikt genomen meer van "Wij verdelers van WC eend, adviseren WC-Eend" (of licentiehouders of wat dan ook)

Door Carbon, donderdag 20 mei 2010 15:05

simpel: "Wij van WC eend, adviseren WC-eend"

Het x264 project heeft geen enkele relatie met de MPEG-LA dus in zoverre gaat het WC-eend verhaal niet op.

Door kidde, donderdag 20 mei 2010 15:58

Maar ze hebben er hun ziel en zaligheid in gelegd.

Als u vijf jaar lang met Ruby leert programmeren, en er hier en daar wat geld mee kan verdienen, bent u ook niet blij als Python populairder wordt en Ruby bijna overbodig maakt, en zal u er ook alles aan doen om de publieke opinie te beinvloeden door te zeggen dat Python bagger is. Dan kan u als 'freelance onafhankelijk consultant' namelijk meer geld blijven verdienen.

Door Carbon, donderdag 20 mei 2010 16:59

Maar ze hebben er hun ziel en zaligheid in gelegd.

Vast en zeker, maar daarvan lees ik niets terug in die analyse.

bent u ook niet blij als Python populairder wordt en Ruby bijna overbodig maakt,

h264 wordt op dit moment wereldwijd gebruikt voor digitale TV (zowel SD als HD), camcorders en fototoestellen (AVCHD), videobewaking, Blu-ray, online video verhuur (Voodoo, iTunes, NetFlix)

maw werk genoeg voor h264 specialisten.

Door tuXzero, donderdag 20 mei 2010 21:16

Nog wel ja, waarom is de enige die deze kritiek heeft ook gelijk de concurrent? Heeft Google hier niet genoeg onderzoek naar gedaan?

Door YopY, donderdag 20 mei 2010 15:06

simpel: "Wij van WC eend, adviseren WC-eend"

Technisch gezien is het "Wij van WC eend vinden product X niet zo goed werken omdat de chemische samenstellingen rommelig zijn en omdat het langer in moet weken voordat het effectief is".

Door ppl, donderdag 20 mei 2010 18:07

Bijna goed, je vergeet namelijk de versie erbij te vermelden. De uitspraken over VP8 moet je sowieso met een korrel zout nemen omdat men uitgaat van oudere documentatie dan die nu is vrijgegeven. Er kan het e.e.a. al gewijzigd zijn in de specificatie en men kan wat betreft encoders/decoders inmiddels ook al zo ver zijn dat een aantal problemen al zijn weggewerkt. Wat die x.264 developer constateert is door het verschil in versie van VP8 wellicht niet juist meer. Dit afgezien van het feit dat hij er alle belang bij heeft om z'n eigen x.264 projectje als beter te bestempelen. Ik zie dan ook liever berichten van onafhankelijke mensen die met de huidige vrijgegeven documentatie aan de slag gaan en op basis daarvan de verschillende codecs met elkaar vergelijken.

Voor de rest vind ik de vergelijking op bepaalde punten ook maar erg magertjes. Het is veel vergelijken met vroeger en wat er toen is gebeurd. Je krijgt dan dingen als "vroeger ging het zo dus dat kan nu ook weer gebeuren!". Sja, het kan ook gewoon niet gebeuren natuurlijk maar dat vertelt hij er dan weer niet bij. Eigenlijk is de eerste 25% van de review op dat niveau, dan hoef ik de rest al niet meer te lezen omdat dit gewoon dooddoeners zijn.

Door hAl, zaterdag 22 mei 2010 14:40

Hoe kom je erbij dat de kritiek is gebaseerd op oude versies van de VP8 specs en dat er sindsdien iets in verbetert ?
De betreffende blogpost is een dag gepost na de WebM aankondiging en dat is tijd zat om de eventuele nieuwste versie te bekijken (en de eventueel verschillen mee te nemen in de analyse. Het blijkt ook want haalt informatie aan uit de laatste document versie (namelijk dat het een final document is)

Door jDuke, donderdag 20 mei 2010 14:49

Nu zal er wel een kern van waarheid inzitten, maar volgens mij zijn ze ook wel bang dat ze wat markt verliezen...

Google zal zeker hard aan werken om eea in orde te maken. Ze hebben het ook maar overgekocht.

Door worldcitizen, donderdag 20 mei 2010 14:50

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.

Door Goderic, donderdag 20 mei 2010 14:54

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.

Door worldcitizen, donderdag 20 mei 2010 14:56

Kortom hij spreekt zich zelfs tegen!

Mooi betrouwbaar artikel.

Heeft iemand de WC eend gezien?

Door humbug, donderdag 20 mei 2010 15:04

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.

Door Mellow Jack, donderdag 20 mei 2010 15:20

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

Door packman, donderdag 20 mei 2010 18:22

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.

Door jessewillem, donderdag 20 mei 2010 15:30

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.

Door matzo, donderdag 20 mei 2010 15:01

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

Door hAl, donderdag 20 mei 2010 16:52

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.

Door xentron, donderdag 20 mei 2010 15:05

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.

Door hAl, donderdag 20 mei 2010 15:31

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.

Door Blokker_1999, donderdag 20 mei 2010 15:50

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.

Door hAl, donderdag 20 mei 2010 16:53

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

Door kidde, donderdag 20 mei 2010 22:57

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.

Door Goderic, donderdag 20 mei 2010 23:16

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.

Door Thundy, vrijdag 21 mei 2010 13:41

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.

Door hAl, zaterdag 22 mei 2010 14:45

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.

Door Peter, donderdag 20 mei 2010 14:55

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.

Door YopY, donderdag 20 mei 2010 15:09

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.

Door Goderic, donderdag 20 mei 2010 15:17

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.

Door CAPSLOCK2000, donderdag 20 mei 2010 14:55

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 donderdag 20 mei 2010 14:57]

Door Laurens-R, donderdag 20 mei 2010 15:05

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 donderdag 20 mei 2010 15:07]

Door kidde, donderdag 20 mei 2010 16:29

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.

Door hAl, donderdag 20 mei 2010 17:56

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.

Door loetje6, donderdag 20 mei 2010 19:06

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...

Door worldcitizen, donderdag 20 mei 2010 22:42

hAl = Microsoft medewerker?

Door kidde, donderdag 20 mei 2010 23:17

Door hAl, zaterdag 22 mei 2010 14:48

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

Door hackerhater, vrijdag 21 mei 2010 16:22

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

Door hAl, zaterdag 22 mei 2010 14:46

Nee

Door The_Worst, donderdag 20 mei 2010 23:27

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 donderdag 20 mei 2010 23:28]

Door Wientje, donderdag 20 mei 2010 15:07

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.

Door Kheldar, donderdag 20 mei 2010 16:11

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 donderdag 20 mei 2010 16:15]

Door BtM909, donderdag 20 mei 2010 14:58

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

Door hAl, donderdag 20 mei 2010 16:59

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.

Door Goderic, donderdag 20 mei 2010 23:20

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 donderdag 20 mei 2010 23:21]

Door snirpsnirp, donderdag 20 mei 2010 14:59

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

Door dj_tjerk, donderdag 20 mei 2010 16:19

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.

Door mashell, donderdag 20 mei 2010 17:00

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.

Door Rune, donderdag 20 mei 2010 17:28

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.

Door hAl, donderdag 20 mei 2010 17:00

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

[Reactie gewijzigd door hAl op donderdag 20 mei 2010 17:01]

Door kidde, donderdag 20 mei 2010 18:28

"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 donderdag 20 mei 2010 18:28]

Door spoonman, donderdag 20 mei 2010 14:59

... 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 donderdag 20 mei 2010 15:01]

Door Keypunchie, donderdag 20 mei 2010 15:02

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.

Door spoonman, donderdag 20 mei 2010 15:06

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

[Reactie gewijzigd door spoonman op donderdag 20 mei 2010 15:10]

Door Nicholai, donderdag 20 mei 2010 15:03

Een fout wordt toch opgeheven omdat in het decodeer deel ook dezelfde fout zit?

Edit: zo dat was slecht typ werk

[Reactie gewijzigd door Nicholai op donderdag 20 mei 2010 19:04]

Door Laurens-R, donderdag 20 mei 2010 15:09

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 donderdag 20 mei 2010 15:12]

Door dj_tjerk, donderdag 20 mei 2010 16:24

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.

Door Carbon, donderdag 20 mei 2010 15:44

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 donderdag 20 mei 2010 16:21]

Door dotnetpower, donderdag 20 mei 2010 17:52

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 vrijdag 21 mei 2010 08:49]

Door Carbon, donderdag 20 mei 2010 18:44

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.

Door Rune, donderdag 20 mei 2010 17:29

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 Rune op donderdag 20 mei 2010 17:33]

Door jwstolk, donderdag 20 mei 2010 22:46

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.

Door Sorcerer8472, donderdag 20 mei 2010 15:00

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 donderdag 20 mei 2010 15:12]

Door dj_tjerk, donderdag 20 mei 2010 16:29

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).

Door hAl, donderdag 20 mei 2010 17:31

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 hAl op donderdag 20 mei 2010 17:58]

« 1 2 »

Op dit item kan niet meer gereageerd worden.

15:12	Symantec neemt Verisign Security over
14:13	Google kondigt online-opslag voor ontwikkelaars aan

Nieuws I/O

Shortcuts

Categorieën

Lees meer over

Gerelateerde content

Gerelateerde jobs

Reacties

26-05 Nieuws

09:05 Productreviews

09:02 Vraag & Aanbod

25-05 Jobs

07:50 Etc.

09:06 Reacties

09:06 Forum

25-05 Gesponsorde acties

00:16 Tweakblogs

26-05 Computable headlines

25-05 CRN headlines