Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Je kunt ook een cookievrije versie van de website bezoeken met minder functionaliteit. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , reacties: 34, views: 17.981 •

De Xiph.org Foundation, onder andere de ontwikkelaar van de audiocodecs ogg vorbis en opus, werkt aan een videocodec. Mede om patentproblemen met codecs als h264 en mpeg2 te voorkomen, gebruikt de Daala-codec een andere compressiemethode.

De Daala-codec, zoals de voorlopige codenaam luidt, die nog een 'pre-alfa'-stempel heeft, gebruikt een methode van lapped transforms. Deze compressiemethode wordt met name gebruikt door audiocodecs. Zo hanteren onder andere de mp3-, aac- en ogg vorbis-codec een dergelijke compressie om audiobestanden compacter te maken. Xiph.org ontwikkelde zelf al de vrij te gebruiken ogg vorbis-codec.

Xiph.org zegt onder andere voor deze compressiemethode te hebben gekozen omdat de patenten van de huidige videocodecs weinig ruimte overlaten voor patentvrije codecs. Populaire codecs als h.264 en mpeg2 gebruiken een op pixelblokken gebaseerd discrete cosine transform-algoritme.

Daala is nog verre van compleet. Volgens Xiph.org is het vorige maand gelukt om met een testversie van de Daala-codec een videoclip over een internetverbinding te encoderen en te decoderen. De broncode van de codec is vrij beschikbaar waardoor ook externe developers met de codec aan de slag kunnen.

Daala

Reacties (34)

Op zich is het leuk om te zien dat dit soort patenten vervolgens leiden tot innovatie, omdat ze omzeild moeten worden. Maar ik ben bang dat het resultaat wel van mindere kwaliteit is, aangezien men toch de meest voor de hand liggende dingen al gebruikt in de patenten. Maar goed, wie weet.

Het ziet er iniedergeval wel een stuk minder blokkerig uit, aangezien ze denk ik niet met blokken werken.
Opus is in ieder geval wel de beste lossy audiocodec op dit moment. Beter dan mp3, aac, amr-wb, .... En dit is zowel op kwaliteit als delay.

Bewerkt: Lossy toegevoegd naar aanleiding van de terechte opmerking van @HerrPino hieronder.

[Reactie gewijzigd door TheodoorDG op 23 juni 2013 15:21]

Opus is in ieder geval wel de beste audiocodec op dit moment.
Je bedoeld natuurlijk beste 'lossy' audiocodec. Want anders is het wel erg ruim genomen. Opus haalt het absoluut niet bij lossless codecs :) Iets waar we uiteindelijk weer naartoe gaan, op het moment dat opslagruimte geen rol meer speelt ... zoals de 1000TB/DVD waar van de week over werd gesproken. Gaan we allemaal weer terug, waar we begonnen zijn .wav :)
Of naar .flac natuurlijk, is nog iets kleiner in grootte, maar nog steeds lossless. :)
Je vergeet wel een beetje de snelheid waarmee data verwerkt kan worden mee te nemen in je beredenatie. Prima 1000TB maar als ik daar maar met bv 20MB/s iets mee kan wil je alsnog alles zo klein mogelijk erop wegschrijven.
Een FLAC bestand heeft zelden tot nooit een bitrate boven de 5000kbps, wat neerkomt op zo'n 0,6MB/s.

De meeste FLAC bestanden zitten op minder dan 1/5e daarvan, dus 20MB/s lijkt me ruim voldoende voor specifiek deze (muziek) toepassing?

[Reactie gewijzigd door ThePendulum op 24 juni 2013 12:37]

Liever flac, zoals al vermeld, niet alleen kleiner, maar ook standaard te voorzien van diverse metadata, waar dit ontbreekt bij wav.
Als je het linkje bekijkt in het artikel zie je dat het wel degelijk met blokken werkt :) Alleen in tegenstelling tot andere codec's maakt deze gebruik van 'lapped transform' om de grenzen tussen blokken te verminderen in het eindresultaat.
Joepie, weer een extra codec die de markt kan versnipperen. Ik ben altijd al een voorstander gewees van opeb technieken, maar heb niet het idee dat ze ooit ver zullen komen. Om veel gebruikt te worden, moet de codec ondersteund worden door zowat alles. Dat is de grootste reden dat verouderde codecs als mp3 nog steeds zo veel gebruikt worden. Ieder media apparaat ondersteund het. En dat is ook waar ogg gefaald heeft. Ogg was technisch beter maar kon je nergens op gebruiken. Ik zie daala dezelfde kant wel op gaan.

De grootste oorzaak is closed source software. Ik weet zeker dat je die bestanden op linux af zal kunnen spelen, maar bedrijven zoals microsoft en apple willen niks weten van open codecs. Die willen hun eigen gesloten technieken doordrukken, want daar is geld mee te verdienen, met open codecs niet. Zolang mensen closed systemen blijven gebruiken zijn dit soort codecs al kansloos bij voorbaat. Kijk maar naar webm, dat zie je ook nog steeds nergens.
Dan moet je toch eens gaan rondkijken hoor. WebM wordt wel degelijk meer en meer gebruikt. Zie onder andere http://en.wikipedia.org/wiki/WebM#Services.
De grootste oorzaak is closed source software.
Ben ik het niet mee eens. De grootste oorzaak is gewenning, daarna kostenoverwegingen en ondersteuning door derde partijen.

MP3 is een formaat dat al sinds jaar en dag wordt gebruikt omdat het destijds een relatief goede en goedkope oplossing was. 'Open' codecs waren destijds (1992, 1994) überhaupt amper aan de orde, dus het was altijd kiezen tussen gesloten en gesloten.

Vanwege de relatief lage kosten wordt het veel ingezet, raakt de consument er gewend aan en ondersteunen derde partijen voornamelijk deze codec. Na jaren zit het echter zo vastgeroest dat men er moeilijk meer vanaf komt; zowel aan de consumer als producer kant. Dat heeft dus niks met open/closed te maken, maar puur met gemakzucht en gewenning van zowel klant als aanbieder.
Zolang mensen closed systemen blijven gebruiken zijn dit soort codecs al kansloos bij voorbaat.
Zolang mensen niet af durven te stappen van het bekende en zolang third-parties geen prettige ondersteuning inbouwen in hun producten / software zijn dit soort codecs al kansloos bij voorbaat.

Er moet voor de eindgebruiker zo min mogelijk veranderen; en het liefst voor de developer ook.
Men heeft geen zin om een codec pack te moeten downloaden om een film te kunnen kijken of muziek te kunnen luisteren, het moet 'gewoon werken'.
De reden waarom men geen codec wil downloaden is denk ik geen luiheid.

Het is meer de slechte ervaringen in het verleden met het installeren van een codec waarna andere films ineens niet meer wilden afspelen, verder zijn mensen ook bang voor virussen en malware.

De websites waar de codecs te downloaden zijn zien er vaak ook niet vertrouwenwekkend uit en je moet ook ontzettend oppassen dat er geen ongewilde software wordt geïnstalleerd omdat je ergens een vinkje over het hoofd hebt gezien.
Een nog veel groter probleem is dat de ene codec vaak zo geschreven wordt dat hij ook bestanden kan afspelen die eigenlijk door een andere codec afgespeeld moeten worden.

Als je pech hebt, dan heb je uiteindelijk een APE, FLAC, WavPac en ALAC codecs nodig, maar deze spelen allemaal ook WAV en MP3 af. Bij video-codecs geldt hetzelfde, maar sommige video-codecs kunnen ook audioformaten afspelen.

Zo heb je in no-time je hele systeem overhoop liggen.

Zelf installeer ik al jaren geen losse codecs meer, behalve FLAC en APE. (Soms wil ik een APE hercoderen naar FLAC.)

Misschien zijn die zelfs ook al niet meer nodig; ik weet het niet heel zeker, maar wellicht kan Foobar deze formaten zelf al afspelen, en heb je wellicht voor CueTools en CueRipper geen codec-installatie (meer) nodig. Ik moet dat eens bekijken.

Voor video gebruik ik VLC.

als Foobar en/of VLC een file niet kunnen afspelen, dan gaat hij de prullenbak in.

[Reactie gewijzigd door Katsunami op 23 juni 2013 19:09]

10 codecs op je PC hebben die allemaal dezelfde formaten (ook) kunnen afspelen hoeft in theorie geen probleem te zijn.

Zolang je een 'control center' hebt voor het beheren van je media playback welke de (door jou ingestelde) codecs aanroept is er niks aan het handje.

Zelf gebruik ik Winamp voor muziek en Zoomplayer voor video.
Zoomplayer is gemaakt a la MPC-HC en staat je dan ook toe om àlle codecs die op je systeem staan te configureren, prioriteren en selecteren.
Vind de vrijheid heeerlijk.
En voor de leken onder ons werkt alles overigens prima out-of-the-box zonder configuratie.

Enige dat bij mij OOTB niet werkte was SPDIF pass-through.. uiteindelijk gefixt door AC3Filter als default audio decoder in te stellen en in het (enorm aangename) AC3Filter configuratie scherm de gewenste chain in te stellen.

VLC gebruikte ik vroeger.. maar ben destijds overgestapt op Zoomplayer/MPC-HC omdat ik op geen enkele manier SPDIF passthrough werkend kon krijgen. Of het aan VLC lag of aan (mijn audio instellingen in) windows weet ik niet.. wèl weet ik dat ik het met zoomplayer/MPC-HC binnen 10 minuten opgelost had.
De ondersteuning voor OggVorbis* is meer wijdverspreid dan je denkt. Het staat alleen bijna nooit bij de specs. Ik had eerst zo'n super cheap chinese "mp3 speler" gekregen, met een bedrijfslogo er op (beurs reclame). Die bleek tot mijn verbazing prima OggTheora af te spelen. Inclusief metadata lezen. Stond niet op het doosje.

*Ogg is alleen de container, Vorbis is de audio codec
Toen ik ooit een losse mp3 speler had, had ik die specifiek uitgezocht op het ondersteunen van ogg. Toen zag alles er nog rooskleurig uit. Maar toen kwamen er steeds meer en meer apparaten en ondertussen gebruik ik die oude mp3 speler niet meer. Sinds die speler heb ik nooit meer iets gehad dat ogg ondersteund. De goedkope merkloze die ik een keer als promo had gehad niet, de geintegreerde autoradio niet, zelfs m'n PS3 en iPhone niet. Tegenwoordig doe ik geen moeite meer en gebruik ik alleen nog maar mp3. Dat is het enige dat overal op werkt. En dat terwijl ik vroeger zelfs m'n hele muziekcollectie op m'n laptop in ogg had om ruimte te besparen op die kleine harddisc.
Ogg faalde niet, de gebruikers faalden. Ik heb met veel plezier al jaren Ogg gebruikt voor vrijwel al mijn audio, ik lette er ook op dat de apparaten die ik gebruikte dit ondersteunden. Ogg had als grootste probleem dat het niet significant beter was dan MP3, niemand geeft een reet om een 0.1 tot 30% performance winst als ze het amper kunnen horen.

Microsoft is hier in vrijwel compleet irrelevant, niemand met een degelijke hoeveelheid gezond verstand gebruikt enkel codecs die standaard met Windows megeleverd wordt of hun media speler. Op Windows installeren mensen gewoon iets als MPC/VLC/MPlayer en dan hebben ze iedere codec onder de zon. Het meest belangrijke platform is Android en die heeft dit soort codecs vaak zelfs out ok the box.

Apple heeft zelfs enkele van hun codecs vrij gegeven, denk hier bij aan ALAC.
Het enige echt grote obstakel voor nieuwe video codecs is het feit dat mensen hun hardware decoders er op moeten bouwen, het is pas sinds kort dat dit met bijvoorbeeld Webm gebeurt waar een grote groep bedrijven steun aan bied, de vraag is dus of een "kleinere" codec als Daala daar tegen op kan boksen.

Zelfs als blij Linux gebruiker en open source/open standaard fanaat zie ik hier nog niet echt een probleem, uiteindelijk wint de beste codec meestal, vroeg op de markt komen is daar een onderdeel van.
Ogg had als grootste probleem dat het niet significant beter was dan MP3, niemand geeft een reet om een 0.1 tot 30% performance winst als ze het amper kunnen horen
Ik dacht dat ogg (veel) beter is dan mp3: op 128 kbit siginificant beter dan mp3 lees ik overal. En 30% performance winst? Hoe bedoel je dat dan? Dat het sneller decodeerd? Dan is het toch juist super wenselijk? Zeker ook op mobile devices?
Ogg was helemaal niet zo slecht. Een 80 kbit ogg klonk beter dan een 128 kbit mp3. En ook een stuk beter dan wma, maar dat is gelukkig nog meer gefaald dan ogg. MS heeft aan iedere fabrikant voor ondersteuning betaald in mp3 spelers etc en geen enkele consument wilde het gebruiken. Maar dat terzijde.

Hardware decoders zijn geen obstakel. Hardware decoders zijn een handigheidje, meer niet. De meeste mensen weet niet eens hoe iets afgespeeld wordt. Die downloaden een video en zolang het afspeelt zijn ze tevreden.
Hardware decoders zijn geen obstakel. Hardware decoders zijn een handigheidje, meer niet.
Onzin. Wat denk je dat er gebeurt met de batterijduur als je mobile device een bestand met de CPU gaat decoderen ipv via een dedicated chip? Daar zit het grote voordeel in mbt hardware acceleratie: het decoderen kost minder stroom op mobile en de performance gaat omhoog (denk aan het decoderen van HD video, standaard met VBR). Ook gaan fabrikanten geen codecs ondersteunen als het niet in hun hardware chips zit, bang dat ze zijn om voor gebruikers een slechte user experience te creëren.
Het problem is niet closed source software maar het feit dat alle commercieel geproduceerde media niet met open-codec gecodeerd worden. Gevolg is dat de gebruikers van die content dus voornamelijk niet-open codec ondersteuning nodig hebben. Persoonlijk heb ik daarom nog nooit Ogg nodig gehad om iets af te spelen.

En zelfs al zou er een open source codec zijn die beter is, dan is er inmiddels heel veel content in MPEG2/H264. Zou je deze willen converteren zit je ook weer met kwaliteitsverlies. Beeldinformatie die niet in de originele stream zit kun je er ook niet bijverzinnen. Je kunt hooguit iets winnen op de benodigde opslag maar dat is tegenwoordig steeds minder een probleem.\

Voor online streamen kan het nog wel zinvol zijn, maar daar zie je dat ongeacht welke codec gebruikt wordt de aanbieder niet voor kwaliteit gaat maar voor zo min mogelijk bandbreedte (zie YouTube 1080p videos: lage framerate, lage bitrate, geen HD audio, geen surround audio -> zeer slechte kwaliteit in vergelijking met een bluray film).
Je draait zaken om: er wordt niks met open codecs gecodeerd omdat er geen ondersteuning voor is. Iemand die een bestand maakt, wil dat het afspeelbaar is op zoveel mogelijk apparaten. Die gaat dus geen codec gebruiken waarmee meer dan 90% van z'n gebruikers geen beeld te zien krijgt. Die pakt dus codecs die standaard op OS X en Windows werken, en zo'n codec is h264. Daarom vind je die codec overal.

Er is overigens niemand die beweert dat je je oude content opnieuw moet encoden. Die bestanden blijven prima werken zoals ze nu zijn. Nieuwe codecs zijn voor nieuwe content.
Of je draait het zelf juist om; omdat er niks mee gecodeerd wordt komt er ook geen ondersteuning.

Het gaat allemaal om vraag/aanbod. Als een codec significant beter is dan de huidige standaard en eenvoudig te implementeren, dan zal deze snel aan terrein gaan winnen. (meer aanbod) Meer terrein betekent ook meer vraag naar ondersteuning.
Meer vraag naar ondersteuning zorgt er voor dat een codec tot 'standaard' verheven kan worden.

Het moet dus uiteindelijk van 2 kanten komen; zowel de codec die zich moet bewijzen als de ondersteuning die moet worden verschaft.

Als de codec zich niet kan bewijzen of niet voldoende vooruitgang biedt dan kan je hoog en laag springen maar dan zal men deze natuurlijk nooit gaan gebruiken.
De grootste oorzaak is closed source software.
Neen, de grootste oorzaak is het feit dat alle hardware (mobiele telefoons, tablets, graphics cards) tegenwoordig support heeft voor H264.

Kijkend naar de toekomst: er is in veel hardware support voor de DCT transformatie. De lapped transformatie, hoewel deze mooiere resultaten geeft, wordt natuurlijk nergens ondersteund, dus ik vraag mij sterk af of deze codec ooit praktisch inzetbaar zal zijn en geaccepteerd zal worden.
Gebruikers interesseren zich niet voor hardware support. Alleen voor "speelt het af?", en in de meeste gevallen speelt het prima met een software decoder. Zo'n probleem is het ontbreken van hardware ondersteuning niet.
Ik verwacht zeer sterk dat ook de patenten-industrie uiteindelijk met lapped transforms zal komen. Zodra het in een MPEG standaard zit, wordt het door iedereen ondersteund.

De grootste oorzaak is dan ook gewoon business: de MPEG codecs hebben grote bedrijven achter zich, een organisatie die het uitroept tot 'de' standaard, en een slim patentbureau die je 'beschermt' als je ze betaalt. Ze beschermen natuurlijk alleen hun eigen codecs.
In het voorbeeldplaatje ziet de lapped transform variant er beter uit dan de DCT variant. Ik vraag mij af of dit bij dezelfde compressie is gemaakt. Als dit zo is zou dat betekenen dat deze compressie vele malen beter is dan DCT.

Mits het niet ontzettend veel (C/G)PU vereist zie ik het wel veel gebruikt worden. Bedrijven als Google en Facebook zouden hiermee miljarden kunnen besparen aan bandbreedtekosten. Dezelfde kwaliteit kan immers met minder data worden aangeboden.

[Reactie gewijzigd door cyberstalker op 23 juni 2013 14:41]

Google heeft zijn eigen VP8/9 codec, ook DCT-gebaseerd. Google de laatste tijd echter last van het "not invented here"-syndroom. Ook al zou Daala betere compressie gaan bieden, dan heeft nog betwijfel ik of Google het actief gaat ondersteunen en gebruiken; ze raken dan de controle kwijt.
Google heeft zeker geen NIH syndroom. Hun VP8 en VP9 codecs zijn onderdeel van hun strategie om het voor iedereen mogelijk te maken om zonder royalties te betalen video content op het web te kunnen produceren en consumeren. Google ondersteunde eerst VP3/Theora, wat ontwikkeld werd als VP3 door On2, en werd later doorontwikkeld als Theora door Xiph (die ook Ogg Vorbis ontwikkelden en nu Daala ontwikkelen). De kwaliteit van Theora was echter ongeveer vergelijkbaar met DivX, dus een generatie terug ten opzichte van H.264.

Daarom kwam Google met WebM, wat een combinatie is van de VP8 video codec en Xiph's Vorbis audio codec. Ze hebben VP8 helemaal niet zelf uitgevonden (dus geen NIH), maar gekocht van On2. Het presteerde ongeveer vergelijkbaar met H.264, dus natuurlijk gingen ze deze patentvrije codec pushen.

VP9 is een doorontwikkeling van VP8, net zoals H.265 een doorontwikkeling is van H.264. WebM zal door Google geupdate worden van VP8 naar VP9 voor video, en van Vorbis naar Opus voor audio. Opus is een nieuwe generatie lossy audio codec, weer ontwikkeld door Xiph in samenwerking met Skype. Het is beter dan alle bekende lossy audio codecs: MP3, Ogg Vorbis en AAC. Daarnaast is het eindelijk eens een patentvrij codec dat gestandaardiseerd is door de IETF, en onderdeel is van de WebRTC standaard. Succes verzekerd dus.

Daala is een compleet nieuwe video codec ontwikkeld door Xiph, voor de generatie na VP9/H.265. Het is nog niet echt in een staat om door wie dan ook te worden ondersteund. Je kan ervan uit gaan dat het te zijner tijd zal worden ingediend bij standaardenorganisaties IETF en W3C, en misschien zal worden opgenomen in de WebRTC standaard en HTML.
In geval van VP8 hebben ze de invention letterliijk gekocht, en daarmee hebben ze er alle controle over. Het audiogedeelte is inderdaad het open Vorbis, maar audio is niet zo boeiend als video.

Google is de laatst tijd aan het afbouwen qua open standaarden en interoperabiliteit. XMPP is uit hun IM-platform gegooid. Zelfs het op XMPP gebaseerde Wave doen ze niks meer mee. WebKit was niet goed genoeg meer, maar hebben ze geforkt. Android is een fork en kloon van Linux en Java (Linux is nu weer mainlined) zodat ze er de totale controle over houden.

Dat ze dingen als SPDY en WebM royalty free houden is mooi, maar puur in eigenbelang. Android is pas open na de release; ontwikkeling is achter gesloten deuren. Of het allemaal evil is mag je zelf bepalen, maar voor mij staat Google in hetzelfde rijtje als Microsoft, Oracle, Apple, ...
In het voorbeeldplaatje ziet de lapped transform variant er beter uit dan de DCT variant. Ik vraag mij af of dit bij dezelfde compressie is gemaakt. Als dit zo is zou dat betekenen dat deze compressie vele malen beter is dan DCT.
Nee, want daala is nog geen echte video codec (het ondersteunt bv. nog niet eens inter compressie). Als je ze op dezelfde bitrate zou gebruiken, dan zou daala er rampzalig uitzien. Geef het nog een jaar of misschien zelfs twee, en dan kun je echte bitrate/kwaliteit vergelijkingen doen. Tot die tijd is het een research-project.

(Vat dit overigens niet negatief op, ik vind het cool dat ze dit proberen. Ik hoop dat het werkt!)

[Reactie gewijzigd door Beelzebubu op 23 juni 2013 18:21]

Het voorbeeld-plaatje is wel een beetje selectief - de lapped transform maakt wel gebruik van pre- en post-filter, maar de DCT maakt [i]niet[]i/ gebruik van een in-loop deblocking filter. Dat is niet een eerlijke vergelijking.

De lapped-transform is trouwens o.a. een onderdeel van JPEG-XR, dus om nou te zeggen dat je met deze nieuwe techniek alle patenten omzeilt, omdat het niet in H264 werd gebruikt, is nogal kortzichtig. Daarbij is JPEG-XR ook niet echt een toonbeeld van succes vergeleken met andere vergelijkbare projecten die standaard DCT gebruikten (bv. JPEG). Doet me denken aan de craze over wavelets enkele jaren geleden (bv. JPEG-2k, Dirac) - dat is ook nooit echt van de grond gekomen.
Wat voor garanties geven ze dat deze techniek inderdaad geen patenten van derden schend? Zijn ze bereid hun klanten/gebruikers financieel/juridisch bij te staan als deze worden aangeklaagd door een patent-eigenaar? Of wordt het straks net zoals Google met Android: laat fabrikanten zelf maar opdraaien voor bijkomende licentiekosten.
Dit is een research project. Ze geven nog niet eens garantie dat de techniek daadwerkelijk werkt! Je moet dit zien als de eerste stap naar de opvolger van VP9/H.265; verre toekomst.

Op dit item kan niet meer gereageerd worden.



Populair: Mobiele netwerken Gamecontrollers Game-accessoires Smartphones Sony Microsoft Apple Games Consoles Politiek en recht

© 1998 - 2014 Tweakers.net B.V. Tweakers is onderdeel van De Persgroep en partner van Computable, Autotrack en Carsom.nl Hosting door True

Beste nieuwssite en prijsvergelijker van het jaar 2013