Apple voegt zich bij alliantie voor ontwikkeling av1-videocodec

Apple heeft zich bij de alliantie van onder meer Google en Microsoft gevoegd voor de ontwikkeling van een nieuwe videocompressietechnologie, av1. Deze waarschijnlijke opvolger van hevc en vp9 is in staat om videobestanden nog verder te comprimeren.

Nu Apple is toegetreden tot de Alliance for Open Media, betekent dit dat het bedrijf uit Cupertino in de toekomst ook de av1-codec zal gaan ondersteunen. CNet heeft Apple benaderd met een verzoek tot commentaar, maar het bedrijf heeft niet gereageerd, waardoor het nog onduidelijk is wat Apple met de in ontwikkeling zijnde videocodec van plan is.

Apple heeft in 2017 hevc of h.265 omarmd als codec voor het het leveren van 4k- en hdr-content, terwijl Google gebruikmaakt van de opensourcecodec vp9. Beide codecs zijn opvolgers van h264, ook wel bekend als avc. Vp9 vergt geen betaling van royalty's, terwijl dat bij hevc wel het geval is.

Av1, of voluit AOMedia Video 1, is nog in ontwikkeling, maar een eerste versie van de codec zou in de komende weken gereed moeten worden. Eerder gaf Mozilla aan dat de av1-videocompressie in de Firefox-browser leidde tot video's die wat bestandsgrootte betreft 25 tot 35 procent kleiner waren dan het geval is bij hevc of vp9.

De Aliance for Open Media werd in 2015 opgericht door onder andere Microsoft, Google, Intel, Mozilla, Amazon, Netflix en Nvidia met als doel het ontwikkelen van een nieuwe verbeterde videocompressiemethode die geschikter is voor het leveren van content over netwerken. De nieuwe av1-codec moet een opensourcecodec worden zonder de verplichting er royalty's voor te moeten betalen.

Reacties (89)

[Peetke]

Recent is ook Facebook erbij gekomen:
http://aomedia.org/press-...board-as-founding-member/

De opvolgers van de vp8 en vp9 codecs belooft echt goed te worden. En met deze grote clubs, kan een succes niet echt meer uitblijven. VP9 is naast YouTube en Netflix nooit enorm doorgebroken. Dat zie ik met AV1 wel flink verbeteren. Vooral ook omdat echt alle chip-bakkers meedoen (Intel, Broadcom, AMD, ARM, NVIDIA)

Eigenlijk alle internetreuzen doen nu mee:
Founding members are Amazon, Apple, ARM, Cisco, Facebook, Google, IBM, Intel, Microsoft, Mozilla, Netflix and NVIDIA.

[Reactie gewijzigd door Peetke op 25 juli 2024 01:43]

[terradrone]

Het zalmij benieuwen. Hevc comprimeert "bepaald" materiaal beter dan avchd/h264, maar bij bijv. footage van 35mm film met veel film grain heeft hevc weinig voordelen. Bij goed comprimeerbaar materiaal, met weinig microdetails is er winst te behalen, en zal av1 hier ook weer een schepje bovenop doen. Maar dit alles is zeker niet zo zaligmakend als men ons doet geloven.

Te weten: bij een op 35mm geschoten film wordt nogal eens een despeckle filter toegepast, waardoor alle film grain verdwijnt , en de comprimeerbaarheid enorm toeneemt. Zo zijn er tal van "truukjes" die leiden tot hogere compressieratios, maar vaak onderwater niets meer doen dan de kluit belazeren.

[.oisyn]

Zo zijn er tal van "truukjes" die leiden tot hogere compressieratios, maar vaak onderwater niets meer doen dan de kluit belazeren.

Euhm, dat is het hele idee van lossy compressie. Geen enkele vorm van compressie kan élke mogelijke input in minder bits representeren dan het origineel, dat is wiskundig gewoon onmogelijk. Er worden concessies gemaakt door veel voorkomende elementen een kleinere representatie te geven en weinig voorkomende een grotere. In het geval van lossy compressie worden ogenschijnlijk moeilijk waarneembare delen weggelaten. Film grain voegt veel random noise toe, en als er iets is dat slecht comprimeert dan is het wel random data. Als je dat eruit filtert dan kun je dus veel beter comprimeren.

Het punt bij film grain is dat het eigenlijk helemaal niet uitmaakt hoe de pixels precies varieren. Je zou het achteraf ook gewoon weer toe kunnen voegen, als random noise. Pixel voor pixel klopt het doelmateriaal dan niet met het bronmateriaal, maar het effect blijft hetzelfde. Als je hiermee een veel betere compressieratio kunt krijgen, wat is dan eigenlijk het probleem?

[Reactie gewijzigd door .oisyn op 25 juli 2024 01:43]

[PrisonerOfPain]

Voor de duidelijkheid: film grain en random noise zijn niet hetzelfde en zien er ook niet hetzelfde uit.

[.oisyn]

Dat hangt af van je definitie van random noise. Als je dat interpreteert als white noise, dan idd niet. Maar het is weldegelijk random (niet per se uniform), en het is noise.

[Carbon]

Geen enkele vorm van compressie kan élke mogelijke input in minder bits representeren dan het origineel

Maar daar staat dan weer tegenover dat de in de praktijk voorkomende inputs een deelverzameling is van alle mogelijke inputs!

[.oisyn]

Inderdaad, daar haakte ik op in met deze zin:

Er worden concessies gemaakt door veel voorkomende elementen een kleinere representatie te geven en weinig voorkomende een grotere.

[terradrone]

Onjuist, filmgrain noise is niet zomaar random noise zojuist je beweert. Het is een interactie met bijv chromatische informatie zoals vastgelegd op film. Kijk bijv naar Queen - live in montreal, wat een prachtig voorbeeld is van hoe filmisch footage kan zijn. Je kan daar sterk op filteren, en later weer ruis toevoegen, waarbij ik je nu al kan beloven dat voor- en na niets met elkaar van doen hebben.

Daarnaast is de ene filmgrain de ander niet. Er is niet 100 jaar lang één type film gebruikt en ieder type film heeft weer zn eigen visuele kenmerken, los van wat de filmmaker heeft bedoelt.

Daarnaast is er niet gezegd dat we hier perse over lossy compressie spreken. Er zijn slimme hybride tussenvormen en het staat eenieder uiteraard vrij hier in te duiken.

[Infor40]

Je kunt wel degelijk compressie doen zonder kwaliteitsverlies, denk aan ALAC en FLAC.

[Cerberus_tm]

Maar zijn punt was dat je die compressie niet met winst kunt toepassen op elke mogelijke inhoud. M.a.w. het hangt van de inhoud af hoe effectief je compressie is.

[xONet]

Misschien lees ik je verkeerd:

Geen enkele vorm van compressie kan élke mogelijke input in minder bits representeren dan het origineel, dat is wiskundig gewoon onmogelijk.

Dat is toch precies wat er gebeurt bij non-lossy compressie (flac, bmp)?
Je kunt om te beginnen elke vorm van herhaling coderen zonder enig kwaliteitsverlies, toch?

[.oisyn]

Ik heb het over élke mogelijke input. Herhalingen alleen vormen niet de complete set van mogelijke inputs, daar zitten ook inputs bij met alleen maar random bits.

Stel je wilt 128 bits comprimeren. Dan heb je dus 2¹²⁸ mogelijke inputs. En stel je hebt een magisch compressiealgoritme dat altijd een ratio van 50% garandeert. Dan is je output dus altijd 64 bits. Maar als je output 64 bits is, heb je maar 2⁶⁴ verschillende outputs. Hoe kun je nou 2¹²⁸ unieke inputs mappen op 2⁶⁴ outputs?

Als sommige inputs kleiner worden, dan impliceert dat dat andere inputs groter moeten worden. Al kun je stellen dat de output nooit meer dan 1 bit groter hoeft te zijn dan de input. In die bit geef je aan of de data gecomprimeerd is of niet. Is het resultaat van de compressie groter dan de input, dan gebruik je gewoon het origineel.

[Reactie gewijzigd door .oisyn op 25 juli 2024 01:43]

[EraYaN]

Even voor de goede orde, bitmaps zijn een volledige uncompressed formaat.

[TheMak]

Nou, van een foto is het aantal punten, en aantal kleurwaarden wel kleiner dan de realiteit.

[EraYaN]

Als je zo gaat doen zijn BMP, WAV, FLAC etc ook lossy compression, omdat het niet de hele werkelijkheid weergeeft.

Iedereen is het er ooit over eens geworden dat dit bitmaps wel degelijk uncompressed zijn, net als WAV dat is voor audio.

[perpetualrabbit]

Doe jezelf een plezien en zoek het Nyquist theorema op

[EraYaN]

Dat heeft verder vrij weinig met compressie te maken. Dat is een ding voor sampling frequenties met perfecte meetapparatuur. Laat dat nou net niet bestaan.

[perpetualrabbit]

Nee, het Nyquist theorema zegt dat een signaal binnen een bepaalde bandbreedte X _exact_ kan worden gereproduceerd met een sampling frequentie van 2X.
zie: https://en.wikipedia.org/...3Shannon_sampling_theorem
Dus voor geluid waarbij frequenties onder 10 Hz en boven 20kHz simpelweg niet door het menselijk oor gehoord kan worden betekent dit dat een sampling frequentie van 40kHz geluid _exact_ kan weergeven. Dus niet "lossy" zoals jij zegt, en wel degelijk de "hele werkelijkheid" wat jij ontkent. Daarnaast is ook een sampling diepte van meer dan 16bits onzinnig. Geluids apparatuur die 96kHz, of 192kHz en op 24 bits samplen, is daarmee volkomen onzinnig, tenzij je vleermuizen wilt opnemen of iets dergelijks. Die maken ultrasoon geluid van 20kHz tot 100kHz en daar heb je dus een sampling frequentie van 200kHz voor nodig.
Lees vooral de doorwrochte uiteenzetting van de maker van de excellente Vorbis en Opus codecs voor geluid: https://people.xiph.org/~xiphmont/demo/neil-young.html

Bij spatiële frequenties zoals in foto's is de informatie tweedimensionaal, en bij MRI scans en seismologisch bodemonderzoek heb je zelfs drie dimensies. Maar voor het signaal per dimensie gaat het theorema nog steeds op: je hebt twee keer het aantal samples per cm (of per boogminuut of wat je eenheid ook maar is) nodig dan het aantal nog los te onderscheiden details wat je wilt coderen. Daarmee kun je dan _exact_ de werkelijkheid _tot aan dat niveau van detail_ weergeven. Dus 50 pixels per cm betekent 100 samples per cm. Over de kleurdiepte en aantal kleurbanden heb ik het dan nog niet gehad, maar onze ogen hebben drie verschillende kleurreceptoren, en reageren ongeveer logaritmisch op de hoeveelheid energie die op een cel valt. Aangezien onze ogen adaptief zijn hebben we een dynamisch bereik van 10⁷ binnen een veel grotere band van 10¹⁴. Dus als de energie in een band X is, dan ziet je oog (ongeveer) log(X). Dus een signaal van rood=1 (Joule per vierkante boogminuut of zoiets) neem je waar als log(1)=0 en rood=10⁷ als log(10⁷)=7. De band van 0 t/m7 is fijner verdeeld in een paar honderd los waarneembare stapjes, zodat je met 8 bit 256 stapjes van ~0.027 hebt. Een stapje omhoog betekent dus 10⁰ ⁰²⁷=1.065 keer meer energie. Op die kleine stapjes tussen 0 en 7 kun je dus weer de stellingen van Nyquist en Shannon loslaten. Dus als je 2X zo fijn samples neemt dan het kleinste logaritmische energie-intensiteits-verschil dat het menselijk oog kan waarnemen, dan geef je de exacte kleurwerkelijkheid tot aan de precisie weer die onze ogen kunnen waarnemen. Doe je minder dan dat, dan kun je in principe kleurbanden zien.
Lossy codecs maken gebruik van verdere beperkingen van onze zintuigen, bijvoorbeeld het feit dat een heel zacht geluid door een harde drum wordt gemaskeerd. Of als je in de auto zit kun je van een fietser met een felle ledlamp alleen nog die lamp en niet de fietser (of trouwens de weg) zien. Die niet-waarneembare data kun je dus weggooien.
Non-lossy maar wel compressed codecs zoals Flac doen gewone data-compressie die na decompressie weer exact de oorspronkelijke data oplevert. Die comprimeren tot ongeveer 25%, dus van 5MB/minuut naar ~1.25MB/m. Een goeie lossy compressie is al gauw 1MB/m, zodat ik het hele punt van lossy codecs voor geluid eigenlijk niet meer zie.

[kozue]

Maar het gaat hier niet eens zozeer om het maken van een codec die alle denkbare bronbestanden beter comprimeert dan z'n voorganger, maar om het bouwen van een codec die op z'n minst alle bestaande codecs kan vervangen en ondersteund wordt op ieder platform. Dus niet zoals de VP9/H265 split nu, veroorzaakt door bedrijven als MPEGLA die geld willen voor het gebruik van een codec. Niemand zit te wachten op dure gesloten codecs vol patenten, behalve de patentbezitters uiteraard, dus nu werkt de hele industrie eindelijk samen om daar vanaf te komen. Dat is veel belangrijker dan of zo'n codec film grain beter comprimeert dan H264.

[EraYaN]

Het mooie van Av1 is dat het net zo goed al dan niet beter is, maar volledig vrij van enige royalties.

Te weten: bij een op 35mm geschoten film wordt nogal eens een despeckle filter toegepast, waardoor alle film grain verdwijnt , en de comprimeerbaarheid enorm toeneemt. Zo zijn er tal van "truukjes" die leiden tot hogere compressieratios, maar vaak onderwater niets meer doen dan de kluit belazeren.

Je mag ook wel vermelden dat de inscanresolutie vaak veel hoger is dan de doel resolutie. Dus dat "truukje" zit hem ook al in de downscaling en is helemaal geen "belazering", niemand wordt echt beter van alle film grain, al helemaal niet digitaal. Daarbij is de compressieratio vrijwel altijd vast bij video codecs, het is meer de resulterende kwaliteit die er onder te lijden heeft.

[SpankmasterC]

Even nagelopen hoe het zit qua founding members en de chipbakkers (want het is natuurlijk wel fijn als de nieuwe codec hardwarematig wordt ondersteund). Founding members zijn techreuzen: Amazon, Cisco, Google, Intel Corporation, Microsoft, Mozilla en Netflix. Later zijn zowel AMD, ARM als NVIDIA aangesloten dus qua hardware ondersteuning op de desktop/laptop zit het wel goed. Grote spelers op smartphone-gebied als Qualcomm en Samsung ben ik nog niet tegengekomen...

[nils83]

Raar maar waar, Apple is ook een founding member.

[Frubelaar]

Dat is inderdaad erg raar omdat het de kop v/h artikel tegenspreekt.
Apple haakt later aan.

[job_h]

Jullie hebben allebei gelijk Apple is er later bijgekomen, maar wel als founding member. Het is een beetje apart, maar niet uniek. Facebook is ook later als founding member erbij gekomen. Waarschijnlijk is dit gebeurt omdat Apple en Facebook ook wat te zeggen wilden hebben, en volgens de AOMedia website moet je daarvoor een founding member zijn.

http://aomedia.org/about-us/

The Alliance for Open Media is governed by founding member companies.

Beiden zijn dus later toegetreden als founding members:
Facebook: http://aomedia.org/press-...board-as-founding-member/
Apple: https://www.cnet.com/news...ne-video-compression-av1/

[Reactie gewijzigd door job_h op 25 juli 2024 01:43]

[EraYaN]

Maar vooral veel geld en/of resources inleggen. En de rest heeft ze er maar al te graag bij.

[ExtendedCaesar]

Qualcomm en Samsung hoeven dat ook niet? Ik dacht namelijk dat hun ontwerpen gebaseerd zijn op de ARM architectuur. En ARM zit er al in. Lijkt mij dus dat ARM de codec in de architectuur gaat ondersteunen, en dat Qualcomm, Samsung en andere ARM chipbakkers dus ook automatisch ondersteuning hebben? Of mis ik iets?

[SpankmasterC]

Over het algemeen zit de hardware decoder als fixed function stukje silicon in een chip, dus los van de GPU en CPU. ARM biedt vast standaardblokken aan, maar zowel Samsung als Qualcom maken ook hun eigen cores en gpu's. Dus ARM gaat het waarschijnlijk inderdaad aanbieden, maar aangezien Samsung en Qualcomm ook zoveel zelf maken is daarmee niet direct gezegd dat ze het hardwarematig ondersteunen.

[kidde]

Ook Ittiam en Verisilicon , Chipsnmedia en Allegro zitten in het clubje, en zij bieden net als ARM 'ontwerp bouw blokken' (IP/ RTL) aan. Qualcomm, Intel, Apple et all kunnen dus kiezen waar ze het ontwerp kopen, of dat ze het zelf ontwerpen; als ze het zelf ontwerpen kunnen ze Argon (ook uit t clubje) weer vragen als consultant mee te helpen met het ontwerp; die helpen ARM namelijk ook bij het ontwerp.

[Reactie gewijzigd door kidde op 25 juli 2024 01:43]

[The Zep Man]

Grote spelers op smartphone-gebied als Qualcomm en Samsung ben ik nog niet tegengekomen....

ARM zit in de alliantie. Daardoor kunnen Qualcomm en Samsung de kat uit de boom kijken en later de vruchten plukken. Voor ARM is het interessant om dit zelf hardwarematig te ondersteunen, omdat de chips in meer zaken gebruikt worden dan enkel smartphones.

[Reactie gewijzigd door The Zep Man op 25 juli 2024 01:43]

[Balance]

Je kan nu al zelf een AV1-stream afspelen: Firefox Nightly voegt ondersteuning toe voor open en efficiënte AV1-codec

[TopGun2010]

Voor mensen die graag YouTube4K op de ATV4K willen is Vimeo echt een goed alternatief, deze is beschikbaar als app voor de ATV4K en heeft WEL h265. Zoek op 4k of 4k hdr en je krijgt zeer veel materiaal en het ziet er goed uit!!

[paltenburg]

Hoe kan dat? Dat er nog zoveel ontwikkeling en vooruitgang in videocodecs zit.

[Verwijderd]

Compressie is feitelijk een compromis tussen verwerkingskracht en bestandgrootte. Gezien het feit dat de verwerkingskracht toeneemt neemt de compressie ook (nog) steeds toe.

[Reactie gewijzigd door Verwijderd op 25 juli 2024 01:43]

[Abom]

Compressie is feitelijk een compromis tussen verwerkingskracht en bestandgrootte. [...]

En het weg laten van (overbodige) beeldinformatie.

Een belangrijk aspect van compressie is het weg laten van beeldinformatie die, voor het menselijk oog/brein, bijna niet zichtbaar is.

Algoritmen worden steeds uitgebreider en complexer om alles steeds verder te optimaliseren.

Leuk Nederlands videocompressie verhaal: Sloot Digital Coding System.

[johnbetonschaar]

En het weg laten van (overbodige) beeldinformatie.

Een belangrijk aspect van compressie is het weg laten van beeldinformatie die, voor het menselijk oog/brein, bijna niet zichtbaar is.

Dat is natuurlijk waar, maar niks nieuws. Zelfs de aller simpelste oer-codecs doen precies dat. Wat ArtGod bedoelt is dat het door vebeterde hardware mogelijk is om steeds 'duurdere' algoritmes te gebruiken om weggecomprimeerde beeld informatie zo goed mogelijk te reconstrueren.

Om een voorbeeld te geven: een belangrijk aspect van video codecs is Motion Compenstation [1], waarbij bewegende beelden worden ge-encodeerd door niet elk frame op te slaan, maar bepaalde frames op te slaan als een voorspelling ('predicted frames') gebaseerd op een vorig en/of volgend frame ('intra frames'), en een set bewegingsvectoren die de encoder uit het bronmateriaal heeft gedestileerd. Wat in de gecomprimeerde video stream wordt opgeslagen is de data uit de originele frames + de bewegingsvector + het verschil tussen wat je zou zien als je simpelweg de data uit de intra frames zou verplaatsen met de bewegings vector, en het originele beeld. Vooral voor frames met weinig of goed voorspelbare beweging (panning shots bijvoorbeeld) bevat het ge-encodeerde verschil veel minder informatie dan het origineel, en het menselijk oog ziet veel minder goed als daar ook nog eens wat mee 'gesjoemeld' wordt door data weg te laten.

De vooruitgang in video codecs zit er onder meer in dat modernere codecs bijvoorbeeld meer frames kunnen gebruiken voor predictie in plaats van 1 of 2, dat de motion vectors hogere resolutie kunnen hebben (sub-pixels), dat er complexere beeld filters kunnen worden gebruikt bij het toepassen van de verschil vectors, etc. Dit kost allemaal gruwelijk veel rekenkracht, vandaar dat codecs niet meer toestaan dan wat op het moment van de specificatie redelijkerwijs te implementeren is op bestaande hardware. Modernere codecs verruimen de specificaties van wat een encoder kan en mag doen, waardoor de compressie omhoog kan, maar de ondergrens voor rekenkracht ook.

Overigens zullen er vast ook allerlei nooit eerder gebruikte compressie technieken in een codec als av1 toegepast worden, hetzij omdat ze vroeger 'te duur' waren, hetzij omdat ze nog niet uitgevonden waren. Maar ik vermoed vooral het eerste.

Het Sloot verhaal is trouwens een groot broodje aap, daar is volstrekt geen theoretische onderbouwing voor te vinden.

[1] https://en.wikipedia.org/wiki/Motion_compensation

[Luno]

Het enige dat me ooit verbaasd heeft over Sloot's compressie is dat iemand (met name Roel Pieper) erin getrapt is. Dit bewijst eens te meer dat iedereen genept kan worden.

[djexplo]

Nee, er is zo iets als "Shannon's theorema", wat een harde wiskundig limiet geeft voor de capaciteit van een communicatie kanaal, en daarmee ook een harde limiet voor de compressie-ratio van bepaalde data.

Het komt er op neer als je een foto comprimeert met alleen maar blauwe pixels, dat als je 1 pixel weet zijn buurman goed voorspelbaar is. Dus hoge compressie factor mogelijk. Maar als je een foto vult met alleen maar (witte) ruis, dan zegt 1 pixel niks over zijn buurman, en zal de compressie factor 0 zijn.

Maar dit is alleen geldig voor lossless compressie, dus b.v. PNG. Op het moment dat je informatie weg gooit die de gebruiker niet opvalt dan kan je natuurlijk veel hogere ratio's halen.

[Carbon]

[delete]

[Reactie gewijzigd door Carbon op 25 juli 2024 01:43]

[GeroldM]

~[delete]

Is wel een zeer extreme vorm van compressie...

[gepebril]

En meestal ook latency. Want betere compressie betekent meestal meer frames samenvoegen.

[phoenix2149]

Beetje gekke opmerking.

Beetje als: "Hoe kan dat? Dat er nog steeds ontwikkeling en vooruitgang in verbrandingsmotoren zit?"

Ontwikkeling en vooruitgang gebeurd continu in alle facetten van bedrijfsleven en maatschappij. Soms zelfs te snel. Zo was bijvoorbeeld de Audi A2 een enorme vooruitgang. Licht, zuinig maar duur door de technieken destijds. Of HDR, waarbij de (huidige consumenten) TV's er eigenlijk nog niet klaar voor zijn (helderheid en bitdiepte scherm). HDR ziet er echt fantastisch uit (Samsung MU8000), helder is echt helder schaduwen zijn echt donker, maar nog steeds vol met contrast en definieerbaarheid, mits het goed is geïmplementeerd (in het medium) en ingesteld (je TV). Maar het is er nog niet helemaal vind ik.

Ben erg blij dat ook Apple zich aan sluit. Als deze drie grote spelers op de software markt en grote spelers op de hardware markt (NVIDIA, AMD, ARM) op een lijn zitten voor een volgende codec zie ik alleen maar voordelen ten opzichte van ondersteuning van de (te ontwikkelen) codec.

edit:
zoals @Peetke hieronder dus ook zegt met bron

[Reactie gewijzigd door phoenix2149 op 25 juli 2024 01:43]

[gepebril]

Ontwikkelingen gaan niet altijd verder. Vroegah "konden" we mensen naar de maan brengen. Daarna nooit meer langs van Allen belt..... Toevallig......

[Reactie gewijzigd door gepebril op 25 juli 2024 01:43]

[phoenix2149]

Dat men er ooit in is geslaagd, met heel veel geluk denk ik, om op de maan te laden wil dus zeggen dat er stilstand is? Dat is best een kortzichtige blik IMHO

Oh, dus al die tests met raketten en landen op platformen in zee zie jij niet als ontwikkeling. Onderzoek naar habitats voor op mars en geplande missies in de nabije toekomst is geen ontwikkeling?

Dat men verstandiger is geworden en niet over elkaar heen struikelt om de eerste op de maan (of mars) te zijn zoals ze dat in die jaren hebben gedaan is ook wat voor te zeggen.

[gepebril]

Ik begrijp je antwoord.
Vroeger werden grenzen verlegd aangaande mensen in de ruimte.
Nu worden zaken efficiënter gemaakt, al meer dan 48 jaar.........

Als je dat in een bedrijfstak voor elkaar krijgt en je krijgt jaarlijks een fors budget.....dan riekt dat toch een beetje corruptie max scale.
Net zo iets als, nou we doen niet meer aan CPU's en zijn teruggegaan naar transsistoren, nu geen koperverbindingen, maar nanoverbindingen, zodat wattages bijna 0 zijn. Vind u dat in 48 jaar niet voldoende "progressie", hoe bedoelt u?

[paltenburg]

Compressie-algoritmes zijn echter meer een theoretisch iets. Zovan hoe kan het dat er na tientallen jaren van ontwikkeling nog stappen van 35% kunnen worden gemaakt, het is niet alsof er twintig jaar geleden geen slimme mensen waren die het konden bedenken.

Maar de antwoorden van "ArtGod" en "Primuszoon" geven een goeie verklaring hiervoor.

[phoenix2149]

eh, ik begrijp niet helemaal waar je nu op doelt.

Uiteraard weet ik dat compressie-agoritmes een theoretische ontwikkeling is. Ik beaam eigenlijk een beetje wat AerGod en Primuszoon zeggen met: "Ontwikkeling en vooruitgang gebeurd continu in alle facetten (dus ook hardware die het vervolgens mogelijk maakt) van bedrijfsleven en maatschappij. Soms zelfs te snel."

Je hebt mij nergens horen zeggen dat ik het gek vindt dat er nog (grote) stappen worden gemaakt of dat er twintig jaar geleden geen slimme mensen zware... Sterker nog die waren er en waren op sommige vlakken hun tijd vooruit waardoor ontwikkelingen op gegeven moment uit hun hybernatie komen en worden afgemaakt en uitgebracht.

[paltenburg]

"Ontwikkeling en vooruitgang gebeurd continu in alle facetten van bedrijfsleven en maatschappij."

Nou, compressie van stilstaande plaatjes zit bijvoorbeeld bijna geen ontwikkeling meer in (of althans lang niet zo veel als video. Je hoort er iig nooit meer iets over). Vandaar mijn vraag.

[phoenix2149]

oh? en de recent uitgebrachte HEIF door apple (gebaseerd op HEVC overigens)

Google is bezig met een beter algoritme voor beeldopslag. https://arstechnica.com/information-technology/2017/03/google-jpeg-guetzli-encoder-file-size/

Natuurlijk is er constant ontwikkeling gaande. Dat het (nog) niet mainstream bekend is wil niet zeggen dat het niet gebeurd.

EDIT:
Hier een aantal andere ontwikkelingen genoemd: https://www.cnet.com/news/google-jpeg-graphics-compression-guetzli-research-web/

[Reactie gewijzigd door phoenix2149 op 25 juli 2024 01:43]

[koelpasta]

Ontwikkeling en vooruitgang gebeurd continu in alle facetten van bedrijfsleven en maatschappij.

Dat heeft op zich niks met die vraag te maken.
Videocompresie gaat over entropie.
Het rare is dus dat er in video blijkbaar nog 25~35% aan informatie weg te gooien valt.

[Terracotta]

Het is niet per se raar dat er daar zoveel weg te gooien valt. De rekenkracht die nodig is om van een 'beknopte omschrijving' (encodeerde data) tot een volledig beeld te komen neemt enorm toe als de omschrijving beknopter wordt. Ook hier zal een limiet op zitten, maar gezien de huidige codecs al behoorlijk wat aan rekenkracht opnemen, hebben we die limiet duidelijk nog niet bereikt.

[Primuszoon]

Ik denk dat snellere processoren en andere hardware technologie het comprimeren perfomanter maken waardoor dit ook voor 'live' doeleinden gebruikt kan worden. HEVC was bvb vroeger niet mogelijk op de toen bestaande hardware (probeer maar eens hevc te decoderen op een cpu uit 2010 met een bescheiden grafische kaart).

[Clemens123]

Maar dat heeft minder met de prestaties van de CPUs/GPUs te maken, maar gewoon met het feit dat er geen HEVC Decoder ingebouwd zat (met een actuele CPU lukt het ook niet HEVC 4k te decoderen, dat lukt enkel met de hardwarematige HEVC Decoder die weiliswaar in de actuele CPUs en GPUs ingebakken zit). De hoofdreden waarom men pusht naar betere maar rekenintensievere standaards zin de hogere resoluties, met name 4k en 8k.

[Bonthouse]

Streaming video is de nieuwe game en bandbreedte kost centen, natuurlijk blijft men dan door ontwikkelen om betere kwaliteit te krijgen met nog minder bits en byes

[StraightOn.NL]

En nu audio nog. Als je een goede HEVC / x265 / h265 video (met geluid) bekijkt komt de meeste data van de audio kanalen. Nu kan ik mij zo voorstellen dat audio een complexer signaal is met minder duplicering dan video maar het blijft toch vreemd dat je video stream in 4k kleiner is dan je 5.1 DTS stream

Weet iemand hoe dat zit en of er in audio compressie ook nog ontwikkelingen zijn?

[The Collector]

Kijk maar eens naar OPUS, http://opus-codec.org/ Zover ik het allemaal kan volgen de beste lossy codec voor audio op dit moment.

[seba]

En het leuke is dat OPUS 2 compressiemodellen heeft. 1 die heel geschikt is voor low-bandwith video conferenties en 1 die heel geschikt is voor goede kwaliteit muziek etc.

[Firecrash]

Goed teken dat Apple hierin mee gaat. Hun verleden staat nou niet echt bepaald vol met samenwerking in een standaard ondersteunen...

[ThomasG]

Op het moment dat het een goede standaard is, zijn ze daar vrijwel altijd in mee gegaan. Natuurlijk zijn er momenten geweest waar ze dat niet gedaan hebben. Maar bij een standaard worden vaak compromies gesloten, want de deelnemers hebben vaak allemaal eisen en wensen en dat betekend soms dat de standaard niet is geworden wat het had moeten zijn; of niet kan wat Apple ermee wilt bereiken. Apple kwam dan met een eigen alternatief wat technisch gezien beter was (bijv lightning vs micro-usb), maar helaas wel Apple-only is.

[Werelds]

Apple gaat mee met een standaard als ze er brood in zien. De kwaliteit van de standaard heeft er niets mee te maken. Als het van een concurrent komt zijn ze standaard vrij afhoudend.

Enkele voorbeelden:
- VP9 (Google) is gewoon een goede, open codec en ze ondersteunen deze niet. Met name voor UHD materiaal is VP9 beter dan H264 en vereist minder rekenkracht dan H265.
- APNG (Mozilla) is 12 jaar geleden mede door Apple (en bijvoorbeeld bedrijven als Symantec ) afgeschoten. Vervolgens bedenkt Apple in 2014 dat zij nu iets beters dan GIF willen en implementeren het alsnog.
- Opus? Vorbis? Of zelfs FLAC? Allemaal niet ondersteund.
- Heel veel onderdelen van HTML5/CSS3 ondersteunen ze nog altijd niet of slechts deels in beide versies van Safari; omdat ze er zelf geen gebruik van maken. Nieuwere dingen als Payment Request verwacht ik eigenlijk nooit ondersteuning voor, omdat zij daar hun eigen product hebben. Maar ook iets heel belangrijks als Media Queries volgen ze na al die jaren nog steeds de standaard niet voor.

Als de druk eenmaal te groot is dan volgen ze uiteindelijk vaak wel, dat is wat nu het geval is. Zij waren tot nu de enige relevante afwezige in deze alliantie. Als ze niet mee gaan doen dan zitten over 2 jaar met de gebakken peren omdat hun afzetmarkt niet groot genoeg is om iedereen te dwingen te betalen voor HEVC licenties.

Hun eigen alternatieven zijn ook niet altijd beter of gewenst. FireWire is het perfecte voorbeeld. Sowieso al duurder en lastiger te implementeren dan USB - en dan moesten fabrikanten ook nog licentiekosten aan Apple betalen.

Dat laatste is meteen het centrale punt voor veel van Apple's keuzes: licenties. Hoewel er veel op naam van Apple staat, gaat het net als bij Google veelal om patenten verkregen door acquisities. Het verschil is dat waar Google eerder de neiging heeft er een open licentie aan te hangen, Apple vaak juist gewoon alles in de MPEG-LA pool gooit om er meer voor te kunnen vangen.

[OkselFris]

Nog steeds gaat Apple mee met standaarden. Wat jij echter zegt is dat ze niet alle standaarden ondersteunen. Nou denk ik dat veel systemen dat niet doen. Je kan ook altijd nog via codecs of een app ondersteuning toevoegen.
Je noemt bijv VP9, daar is bekend van dat deze nogal onder een discutabele licentie beschikbaar wordt gesteld, daar is veel kritiek op. Daar zit een behoorlijke arm van Google in... en ik kan me voorstellen dat bedrijven dat ontwijken.
Als je kijkt wat ze software matig gebruiken, dan kan je niet anders concluderen dat ze veelal standaarden volgen. Maar er zijn nou eenmaal meerdere standaarden.
Bij hardware zit er vaak een ander verhaal achter en is vaak de huidige standaard niet toereikend. Zoals we zagen met de lightning connector, of hun eigen msata alternatief omdat de standaard laat op gang kwam.

Je haalt FireWire aan, inderdaad een afwijkend, maar ook een standaard. Ze boden naast FireWire ook nog altijd USB aan. Was het Apple niet die alle oude poorten afzwaaide t.b.v. USB? (Beetje hetzelfde als het USB-C verhaal). FireWire had echter voordelen t.o.v. USB.
Als je naar de historie kijkt hebben ze heel vaak standaarden omarmt en hebben ze soms rigoreuze stappen genomen om een standaard door te voeren.

En wat betreft HEVC of AV1, de ene is er al, de andere nog niet officieel en is het niet zo vreemd dat ze de eerste omarmt hebben. Natuurlijk hebben ze er ook een belang in.

[Reactie gewijzigd door OkselFris op 25 juli 2024 01:43]

[Werelds]

Tuurlijk gaat niet iedereen mee met alle standaarden. Apple heeft er echter een handje van om echt tegendraads te willen zijn - Microsoft was dat vroeger ook, maar de afgelopen 4-5 jaar zijn zij juist veel voortvarender geworden dan Apple. Ondersteuning via codecs of apps toevoegen is er bij Apple niet bij en ook nooit echt geweest. Het probleem is dat Apple veelal dingen ondersteunt die niet gratis zijn, waarmee brede ondersteuning al heel snel achter blijft. Dat zou niet zo'n probleem zijn als ze dan ook gratis codecs ondersteunden, maar dat is helaas niet zo.

Wat is er discutabel aan de licentie van VP9? Open, gratis, BSD licentie. Ik weet niet over welke kritiek jij het hebt, want juist op de belangrijkste markt voor VP9 (het web, in al z'n vormen) is ondersteuning voor VP9 op dit moment gewenst, althans tot AV1 klaar is. De ronduit slechte ondersteuning van codecs (zowel audio als video) is een doorn in het oog van elke webdeveloper; met dank aan Cisco kunnen we tegenwoordig gelukkig relatief probleemloos h264 gebruiken, maar dat was in het begin behoorlijk anders.

De enige standaard die ik me op dit moment te binnen schiet waar Apple niet alleen actief voorstander van was, maar zelfs ontwikkeld had en open beschikbaar maakte, is Mini DisplayPort. En dat heeft flink wat invloed gehad ja. En laat daar nou heel toevallig vrijwel dezelfde licentie aan hangen als er nu aan Google's VP9 hangt

[Jorick]

VP9 was/is een prima codec en vormt ook de basis voor av1-codec. Wat de adoptie van VP9 vooral heeft tegengehouden is dat de encoder(s) wat achterliepen op die van HEVC wat betreft kwaliteit/compressieratio en dat in veel gevallen hardwarematige ondersteuning (zowel en- als decoding) in veel apparaten ontbrak, iets dat de laatste tijd overigens wel steeds beter werd wat ondersteuning betreft.

Apple heeft (of had) belang bij HEVC omdat zij daar royalties voor opstrijken. En dat is een beetje waar het mis is gegaan met de adoptie van HEVC, de royalties voor het gebruik waren veel te hoog waardoor partijen zoals Google zelf maar codecs gingen ontwikkelen. Uiteindelijk kiest Apple geld voor haar eieren door te kiezen voor wat vrijwel zeker H264 zal opvolgen als dé standaard videocodec voor het internet.

[Carbon]

Wat is er discutabel aan de licentie van VP9? Open, gratis, BSD licentie.

Ik meen mij te herinneren dat er clausule was waarin stond dat de licentienemer geen rechtzaken tegen Google mocht starten

Apple heeft (of had) belang bij HEVC omdat zij daar royalties voor opstrijken.

Je hebt het over de MPEG-LA

VP9 maakt gebruik van MPEG-LA patenten en sinds 2013 hebben Google een de MPEG-LA een overeenkomst afgesloten.

[Reactie gewijzigd door Carbon op 25 juli 2024 01:43]

[Werelds]

Ik meen mij te herinneren dat er clausule was waarin stond dat de licentienemer geen rechtzaken tegen Google mocht starten

Ah. Zie mijn reacties hier en hier. Gaat alleen om aanklagen met betrekking tot patenten rondom WebM en VP8/VP9. En zoals ik zei, dat is exact wat er in Apple's licentie voor MiniDP staat; je mag Apple niet aanklagen met betrekking tot patenten rondom MiniDP (de taal van de licentie is iets vager dan die van Google; ze zouden het nog wel kunnen rekken tot patenten van Apple in z'n algemeen, maar dat is niet de bedoeling).

Als je een bedrijf aan gaat klagen over patenten in gratis software/hardware/ontwerpen die je dan wel zelf gebruikt ben je natuurlijk vreemd bezig

[Carbon]

FireWire is het perfecte voorbeeld. Sowieso al duurder en lastiger te implementeren dan USB - en dan moesten fabrikanten ook nog licentiekosten aan Apple betalen.

FireWire was in technisch opzicht superieur aan USB 1.1 / 2.0
Geen centrale controller, daisy chain, full-duplex,streaming, multiple master
Al dat moois kwam helaas met de nodig complexiteit.

en dan moesten fabrikanten ook nog licentiekosten aan Apple betalen.

USB is niet gratis voor fabrikanten!

Of zelfs FLAC?

FLAC wordt sinds iOS 11 ondersteund!

[Reactie gewijzigd door Carbon op 25 juli 2024 01:43]

[Werelds]

FireWire was in technisch opzicht superieur aan USB 1.1 / 2.0
Geen centrale controller, daisy chain, full-duplex,streaming, multiple master
Al dat moois kwam helaas met de nodig complexiteit.

Ik zeg ook niet dat FireWire geen voordelen had, maar de licentiekosten hebben het de nek omgedraaid. Apple wilde er in het begin $1 per poort voor hebben.

USB is niet gratis voor fabrikanten!

Nee, maar de kosten zijn verwaarloosbaar vergeleken met FireWire. Als ik het me goed herinner, kost het lidmaatschap jaarlijks $4000.

FLAC wordt sinds iOS 11 ondersteund!

Niet in Safari, je kunt nog steeds geen FLAC in HTML5 Audio stoppen

[rbr320]

Aan het lijstje voorbeelden die @Werelds al geeft en die allemaal kloppen, wil ik graag ook nog Vulkan toevoegen. Een prima open standaard voor 3D rendering, net als DX12 afgeleid van Mantle van AMD waardoor deze syntactisch erg op elkaar lijken, en ondersteund door een grote en vooral relevante groep bedrijven zoals Valve, Epic, Google, AMD en NVidia. Waarom Apple zich dus vast blijft houden aan hun eigen Metal is mij persoonlijk een raadsel.

[nils83]

Ik zie die comment vaak langskomen, evenwel zonder enige vorm van onderbouwing.

Apple is helemaal niet tegen standaarden en ze hebben veel zelf (mee-)ontwikkeld aan heel wat standaarden. Denk bvb aan FireWire, Thunderbolt, Mini DisplayPort... Dan is er nog een heel resem aan software welke ze als open-source vrijgeven, een zeer bekende en populaire is nu bvb Swift.

[loekf2]

Ik vind het wel een goeie stap van Apple. Kan dit betekenen dat we ooit 4K support in Safari en bv. op de AppleTV 4K gaan zien ? Beide vereisen VP9 support en tot nu toe (min of meer) weigert Apple VP9 te supporten.

[Verwijderd]

Lijkt me niet omdat VP9 volkomen in eigendom van Google is, het is dus geen open standaard.

Lijkt me eerder dat Google overstapt op AV1 voor Youtube. Deze standaard is wel open.

Of Google maakt VP9 een open standaard. Zou kunnen als AV1 zekerheid heeft gekregen te slagen.

[Werelds]

VP9 is weldegelijk een open standaard. De enige beperking aan het gebruik van VP9 is dat je Google niet aan klaagt voor patent inbreuk

De enige reden dat Apple VP9 (en VP8) niet ondersteunt is omdat ze dat simpelweg niet willen.

[nils83]

Die beperking is wel een gigantische, gezien Google zowat overal voorkomt.

[Werelds]

Mijn excuses, ik had wellicht iets duidelijker moeten zijn. Het gaat er om dat je ze niet aan klaagt met betrekking tot patenten rondom WebM, VP8 en VP9. Overige patenten staan er los van

[Pendora]

Er is iig in Safari gewoon 4K support. Alleen VP9 wordt niet ondersteund door Apple. HEVC in 4K wordt gewoon afgespeeld.

[loekf2]

Bedoel ook Youtube support.

[N8w8]

Ik hoor dit wel vaker, maar met youtube-dl (in Debian) kan ik 4K streams ook krijgen als h.264/AVC:
$ youtube-dl -F http://youtu.be/K4YDMmWBac4|grep 2160
266 mp4 3840x2160 DASH video 22155k , avc1.640033, 30fps, video only, 300.25MiB
313 webm 3840x2160 2160p 23008k , vp9, 30fps, video only, 324.06MiB
Met youtube-dl heb ik ook geen last van 18+ restricties, en hij omzeilt (soms?) ook geofencing.
Ik weet niet wat voor funkys het allemaal uithaalt om alles meedogenloos te kunnen rippen maar het werkt top. Misschien werkt t ook wel op Apple, of wil die 4K echt alleen afspelen als het h.265/hevc is?

[SSH]

Goede stap? Enigszins laat, alsof ze nog hoop hadden op een andere manier meer geld te verdienen.

[rbr320]

Hopelijk betekend dit dat je straks op Linux ook naar Netflix kan kijken in resoluties hoger dan 720p.

Overigens is het "Open" in Alliance for Open Media natuurlijk relatief. De specificatie mag dan misschien open zijn met open source implementaties, maar gezien de partijen die er aan mee doen ga ik er vanuit dat er wel gewoon ondersteuning voor DRM wordt geboden. Daar heb ik persoonlijk geen problemen mee, maar het is misschien wel het benoemen waard.

[Umbrah]

Ik denk dat daar de grote blokkade eerder de DRM is. En dan is wildvine eigenlijk bést vriendelijk.

Er zijn overigens genoeg linux-kernel gebaseerde OS-en die wél op max (4k/HDR/Dolby) netflix kunnen afspelen, Android, WebOS, Meego, etc... Ze zijn alleen niet GNU-based.

[rbr320]

Ik denk dat daar de grote blokkade eerder de DRM is. En dan is wildvine eigenlijk bést vriendelijk.

Ik ben niet zo thuis in de wereld van de DRM, maar ik had gehoopt dat met de implementatie van EME op Linux in zowel Firefox als Chrome dit opgelost zou zijn. Voor zover ik weet is dat echter niet het geval.

Er zijn overigens genoeg linux-kernel gebaseerde OS-en die wél op max (4k/HDR/Dolby) netflix kunnen afspelen, Android, WebOS, Meego, etc... Ze zijn alleen niet GNU-based.

Dat klopt en dat is het kromme dus ook. Netflix in 1080p of zelfs 4k streamen vanaf mijn Android telefoon naar de Chromecast werkt prima maar beschouw ik als een work-around aangezien ik meer achter mijn PC zit dan achter de TV. In de browser kom ik onder Linux niet hoger dan 720p.

[mOrPhie]

Dit is een goede zaak. De Apple-TV gaat hier bijvoorbeeld van profiteren, omdat deze nu niet hoger dan 1440p-content krijgt van YouTube, omdat Google bij h.264 en h.265 niet meer dan 1440p ondersteunt. Erg fijn dat ze iets van een deal hebben nu, want het was een beetje gekke situatie.

[N8w8]

Met youtube-dl kan ik 4K krijgen in h.264 (zie mn vorige reactie).
Al vind ik het wel verdacht dat iedereen dit zegt, terwijl het bij mij prima werkt. Zou Google expres Apple zitten te fucken?

[mOrPhie]

Geen idee. Of Google dit express doet is koffiedik. Het feit is dat de YouTube-app op de AppleTV (de app is gemaakt door Google) het niet toestaat en dat dat vermoedelijk komt omdat ze VP9 gebruiken voor de hogere resoluties en de AppleTV dit niet ondersteunt. Hoe youtube-dl dit doet? Geen idee ook.

Overigens ondersteunt de AppleTV 2160p60 content van zowel h.264 als h.265/hevc, dus dat kan het niet zijn.

Wel interessant verder dat youtube-dl. Zal er eens naar kijken, want als devver kan ik een eigen app sideloaden immers. Als ik met hulp van een Pi dan aan 4k-streams kan komen, is dat misschien niet eens zo'n gek idee.

[Reactie gewijzigd door mOrPhie op 25 juli 2024 01:43]

[seba]

Dit is ook veelbelovend voor webrtc, waar apple nu als enige niet de vpX codecs ondersteund.

[nils83]

Geef ze tijd, Apple heeft nog maar een paar maanden support voor WebRTC toegevoegd. Veel te laat natuurlijk, maar de rest komt wel.