2015 deed zijn intrede en de taart met twee kaarsjes stond klaar voor high efficiency video coding. Hevc ofwel h265 werd twee jaar oud en de videocodec leek een succesvolle toekomst tegemoet te gaan. Ten opzichte van voorganger h264, die nog altijd veel wordt gebruikt, is de nieuwe compressiestandaard een stuk efficiënter. Ook op het juridische vlak van patenten en de te betalen royalty's leek het wel snor te zitten. Opensourcealternatieven leken geen serieuze vuist te kunnen maken en bovendien zat 4k eraan te komen. Al met al genoeg elementen voor een stevige en aanhoudende wind in de rug voor h265.
Binnen een half jaar werd er echter volop geklaagd. In een artikel uit september 2015 uitte Joe Inzerillo zijn ongenoegen, zoals al valt op te maken uit de titel: 4K gets thumbs down from Discovery, BBC and others at IBC. De toenmalige cto van Major League Baseball Advanced Media was niet te spreken over de licentiesituatie. Daarbij werd zelfs voorgesteld om gebruikers van de h265-standaard een percentage van hun omzet te laten betalen, dus royalty's voor content die met h265 is gecodeerd. Inzerillo gaf aan dat geen enkel mainstreambedrijf daarvoor ging tekenen en hij was stellig in zijn oordeel dat 'het h265-patentgebeuren de 4k- en 8k-verkopen de wind uit de zeilen nam'.
De onduidelijkheid en complexiteit rondom de voorwaarden voor het gebruik van h265 leidden tot een bundeling van de krachten op het opensourcefront. De Alliance for Open Media, opgericht door onder meer Amazon, Facebook, Google, Microsoft, Mozilla en Netflix, kondigde in september 2015 aan dat er gewerkt werd aan een codec zonder royalty's: av1. Verder hanteert Google nog zijn eigen royaltyvrije vp9-codec en onlangs is de opvolger van h265 aangekondigd, met de voorspelbare aanduiding h266, of versatile video coding. Het landschap wordt er dus allerminst overzichtelijker op. Hoe gaat encoderen in zijn werk, welke verschillende videocodecs zijn er allemaal, wat hebben gebruikers eraan, hoe presteren ze en wat zijn de slagingskansen, gelet op alle bijkomende juridische aangelegenheden?
Statistieken en nerds zijn een goede combinatie en daar is YouTube het mee eens. Tijdens het afspelen van een YouTube-video op bijvoorbeeld een televisie is het 'Statistieken voor nerds'-venster te openen, met allerlei informatie over die afgespeelde video, zoals de verbindingssnelheid en de huidige resolutie. Daar is ook te zien welke codecs YouTube toepast bij het streamen van video's: veelal de vp9-codec van Google voor het beeldmateriaal en opus of aac voor de audiocompressie.
Een gemiddelde kijker of luisteraar heeft doorgaans niet in de gaten dat er sprake is van compressie, en dat er dus nogal wat wiskunde en algoritmen zijn gebruikt om de video's tot in de huiskamer te brengen. Stream een episode op Netflix en nergens staat dat de video is gecodeerd met h264 of av1. Stop echter een uhd-blu-rayschijfje in een daarvoor geschikte speler en de film wordt enkel weergegeven doordat de speler is ingericht om de compressie via de hevc-standaard te decoderen. Daar zie je verder niets van. Werp een blik op de achterkant van het doosje van een uhd-blu-rayfilm en je vindt genoeg disclaimers waarin bijvoorbeeld Dolby en andere merknamen worden genoemd, maar nergens wordt vermeld dat videocodec h265 is toegepast voor de compressie.
Het nut van compressie
Dergelijke technische informatie zal het grote publiek ook niet interesseren, maar het belang van compressie is groot. Zonder goede compressie past een film niet zomaar op een willekeurig blu-rayschijfje, neemt een rip van de film op een blu-rayschijfje aanzienlijk meer schijfruimte in beslag en zal een stream van een video-on-demanddienst een onoverkomelijk obstakel vormen voor de bandbreedte waarover de gemiddelde consument beschikt.
Anne Aaron, werkzaam bij Netflix als leidinggevende bij de afdeling Encoding Technologies, gaf een sprekend voorbeeld van de problemen die opdoemen bij het zonder compressie streamen van content naar de televisie van de thuisgebruiker. De laatste, 53 minuten durende episode van het tweede seizoen van de serie Jessica Jones was maar liefst 293GB groot toen die als ruw beeldmateriaal aan Netflix werd aangeleverd, conform de jpeg 2000-compressiestandaard. Dat zou vervolgens neerkomen op een datarate van 750Mbit/s. Voor verreweg de meeste consumenten is dat veel hoger dan wat hun internetverbinding haalt. Daarom is het zaak om dat via compressie met pakweg een factor honderd te verkleinen en de beeldkwaliteit er niet te veel onder te laten lijden, zodat het er nog goed genoeg uitziet bij een bitrate van 7,5Mbit/s.
Jessica Jones
In landen waar vooral de smartphone wordt gebruikt en waar Netflix dus vooral mobiel wordt bekeken, zijn mobiele databundels leidend en die zijn lang niet altijd toereikend. Zelfs als de compressie de bitrate terugbrengt tot 750kbit/s, zit je in combinatie met de bandbreedte voor de audio met een vaste databundel van 2GB per maand na het bekijken van vijf uur Netflix al aan de limiet. Voor Netflix en andere streamingdiensten is het dan belangrijk om de beste algoritmen en videocodecs te gebruiken voor een zo hoog mogelijke compressie.
Voorheen gebruikte Netflix veelal een codeoptimalisatiemethode waarbij per titel werd geanalyseerd wat het optimale recept voor het coderen was. Daarbij was de complexiteit leidend. Een film met veel beweging en snelle actie is een stuk complexer en vergt dus meer bits om de informatie te comprimeren en door te geven dan een film met minder beweging of een animatievideo. Zo vergde het relatief eenvoudig te coderen BoJack Horseman 680kbit/s, terwijl Jessica Jones 910kbit/s nodig heeft. Deze besparing bij BoJack Horseman heeft het voordeel dat de animatieserie nu in hd-kwaliteit kan worden gecodeerd rond de 900kbit/s. Per-title encoding of complexity-based encoding heeft dus het voordeel dat per titel de beste aanpak wordt gekozen, zodat er meer bandbreedte vrijkomt om bijvoorbeeld de kwaliteit te kunnen verhogen.
Inmiddels is optimized shot-based encoding leidend bij Netflix. Daarbij wordt het gekozen codeerrecept niet bepaald aan de hand van de hele serie of film, maar op basis van individuele shots uit die content. Ook dit is weer bedoeld om de beste kwaliteit te bereiken met de minste benodigde bits. In vergelijking met de bitrate van 750kbit/s die via complexity-based encoding wordt bereikt bij een waargenomen kwaliteitspercentage van iets boven de zeventig, is bij optimized shot-based encoding op basis van vp9 slechts 270kbit/s nodig bij dezelfde kwaliteit. Dat maakt dat er meer ruimte komt om de kwaliteit te verhogen en gebruikers met weinig beschikbare bandbreedte of kleine databundels kunnen hiermee meer content bekijken.
VMAF of Video Multimethod Assessment Fusion is een maatstaf van Netflix voor het evalueren van de videokwaliteit van het gedecodeerde beeld ten opzichte van het referentiebeeld. Bij deze maatstaf wordt de door de gebruikers ervaren kwaliteitsscore geschat op basis van verschillende kwaliteitsbeoordellingsalgoritmen in combinatie met een support vector machine. Die laatste is een algoritme waarbij zaken als antiruis, verlies aan detail en de visuele natuurgetrouwheid van het beeld een rol spelen.
Hoe werkt videocompressie?
Simpel gezegd kan compressie, en dus beduidend kleinere filmbestanden, alleen gerealiseerd worden door niet alle informatie tot op de pixel nauwkeurig voor elk frame in kaart te brengen. Er moet als het ware informatie genegeerd worden. Daarmee is de compressie doorgaans lossy; het eindresultaat voor de consument is een benadering van de originele content en zal niet exact dezelfde kwaliteit hebben als het origineel. De efficiëntie van compressiemethodes, de effectiviteit van de toegepaste algoritmen en de mate van informatie die wordt genegeerd, zijn grofweg bepalend voor het kwaliteitsverlies ten opzichte van het ruwe materiaal.
Hoe gaat de compressie in zijn werk en hoe zijn daar verbeteringen in aan te brengen? We willen niet vervallen in een gedetailleerde bespreking van de combinaties van verschillende technieken en de achterliggende complexe wiskunde. We kijken slechts hoe standaardcompressietechnieken in beginsel werken en hoe dat proces bij h264 en veel andere codecs is verbeterd.
Voorspellende gaven
Stel je een denkbeeldige scène uit een video voor, waarbij de camera stilstaat en is gericht op een boom waaraan een bonte specht zich vastklampt en met zijn snavel af en toe in de boomstam hakt. In het eerste frame is de vogel nog met zijn kop van de stam verwijderd, maar in het volgende frame zit ie al met zijn snavel tegen de boomschors. In dit voorbeeld heeft alleen de vogel bewogen. De rest, zoals de boom, de lucht en de takken op de achtergrond, is grotendeels onveranderd tussen de twee frames. Zonder compressie zouden volledige beschrijvingen van de scène in beide frames moeten worden worden verstuurd. Met compressietechnieken valt de beeldinformatie in elk frame weliswaar te comprimeren, maar moet nog altijd behoorlijk wat data worden verstuurd. Dat komt mede doordat elk frame afzonderlijk wordt gecomprimeerd, ook al haalt het tweede frame nogal wat informatie uit het eerste.
Die herhaling en de daarmee gepaard gaande extra data is eigenlijk overbodig, want in deze specifieke scène hoeft alleen rekening gehouden te worden met de beweging van de specht. Om compressie op basis hiervan mogelijk te maken, vormt het eerste frame de basis. Dit wordt ook wel het I-frame, keyframe of referentieframe genoemd. Na het decoderen van dit frame kan het volledige beeld worden weergegeven. Het staat dus op zichzelf en is niet afhankelijk van andere frames. Het tweede frame met de specht die op de boomschors inhakt, staat niet op zichzelf en is gebaseerd op het I-frame. Dit wordt het P-frame genoemd met de p van predictive. Dit frame is gebaseerd op een voorspelling vanuit het vorige frame. In plaats van het hele beeld te versturen, wordt bekeken welke gebieden zijn veranderd ten opzichte van het vorige beeld. Zijn er delen die niet veranderd zijn, zoals in dit geval het grootste deel van de boom en de achtergrond, dan wordt die informatie niet opgeslagen of verzonden. Bij de delen waar wel verandering is, volgt compressie. Dan zijn er ook nog B-frames, die wat beeldinformatie betreft zijn gebaseerd op eerdere en toekomstige frames.
Macroblocks
Dat negeren van de beeldinformatie ten opzichte van eerdere frames gebeurt door een frame op te delen in vakjes, ofwel macroblocks. Zie het als een raster dat over het frame wordt geplaatst. Bij een P-frame wordt geanalyseerd welke blocks wel en niet zijn veranderd. Bij geen verandering worden die blocks niet verwerkt. De blocks die wel zijn veranderd, worden gecomprimeerd. Op deze manier kan bij het tweede frame een aanzienlijke hoeveelheid data worden bespaard, oplopend tot 80 procent of meer.
Voorbeeld uit een white paper van Samsung van hoe op basis van I- en P-frames bandbreedte kan worden bespaard. Hier wordt een I-frame opgevolgd door 29 P-frames, waarna weer een nieuw I-frame begint. De benodigde bandbreedte is een stuk hoger bij de I-frames, omdat er een grotere hoeveelheid data wordt verzonden. Zeker bij P-frames met weinig beweging en dus weinig verschil is de bandbreedte een stuk lager.
Verbeteringen bij h265 ten opzichte van h264
Dit concept vormt de basis van h264, waarbij de individuele blocks een formaat van maximaal 16x16 pixels kunnen hebben. H265 gebruikt ook nog steeds de blocks als basis en gebruikt verder een vergelijkbare aanpak bij het coderen, maar verbetert de prestaties van voorganger h264 onder meer door meer flexibiliteit bij de blocks toe te passen. Het maximale formaat is bij h265 een stuk groter en gaat tot 64x64 pixels. Deze blocks worden bij h265 coding tree blocks genoemd, omdat ze kunnen worden onderverdeeld in subgedeeltes. Een ctb van 64x64 kan bijvoorbeeld worden verdeeld in vier blocks van 32x32, die op hun beurt zijn te verkleinen in blocks van 16x16 of 8x8. Deze kleinere blocks binnen een ctb worden coding units genoemd. Deze kunnen vervolgens weer worden opgedeeld in transform units van 32x32, 16x16, 8x8 of 4x4. Deze units vormen de basiseenheid voor de voorspelling binnen de h265-compressiestandaard.
Een coding tree block met vier coding units die rechtsboven en linksonder ook weer zijn opgedeeld in transform units. De cijfers geven de scanvolgorde aan.
Grotere ctb's leiden tot een hogere efficiëntie, maar vergen ook meer codeertijd. Die hogere efficiëntie komt voort uit de hogere mate van flexibiliteit die coding en transform units mogelijk maken. Kleine units worden vaak gebruikt bij gedetailleerde gebieden, zoals hoeken van objecten, terwijl grotere units vaak gebruikt worden om egale gebieden of gebieden met weinig beweging te voorspellen. Door de grotere ctb's en de kleinere units zijn meer vormen mogelijk en kan een codeersysteem een beeld veel efficiënter opbreken in grote blocks, terwijl waar nodig kleinere blocks worden ingezet voor de fijne details. Dat levert een flinke besparing in de bandbreedte op en leidt door de optie van kleine units voor de details niet tot een verslechtering van de beeldkwaliteit ten opzichte van h264.
Macroblocking van het beeld van een bewakingscamera conform h264 (links) en h265. De veel efficiëntere grote blocks kunnen worden gebruikt voor gedeelten waar weinig gebeurt en waar weinig detail noodzakelijk is. Kleinere blocks worden toegepast bij de details en in de gebieden waar activiteit plaatsvindt.
Een andere belangrijke verbetering ten opzichte van h264 is de manier waarop h265 inspeelt op bewegende objecten. Door effectief in te spelen op beweging kan ook aanzienlijk worden bespaard op de bandbreedte of opslagruimte. Stel dat er in een video een auto voorbijrijdt. Bij een stilstaande camera beweegt alleen de auto in een serie frames. Grote delen van het beeld zien er dan vaak in opeenvolgende frames hetzelfde uit, alleen zijn bepaalde delen naar een nieuwe positie verschoven. De koplampen van de auto zitten bijvoorbeeld net in een ander block ten opzichte van een vorig frame.
Links de negen richtingen bij h264 en daarnaast de veel verfijndere richtingsinformatie die in h265 wordt gebruikt
De richting van die verschuiving wordt aangeduid als de motion vector. Het gaat hier om intra prediction: het proberen om informatie te halen uit de omliggende blocks. Het valt echter niet altijd mee om die overeenkomende blocks precies te laten overeenkomen tussen de verschillende frames, dus is het ook nodig om kleine veranderingen bij een block door te geven. H264 heeft maximaal negen richtingen om de beweging van een block aan te geven, terwijl dat er bij h265 in totaal 34 zijn. Door de negen richtingen bij h264 lukt het lang niet altijd om de beweging exact te beschrijven en moeten vaak kleine aanpassingen worden doorgegeven. De 35 richtingen om blockbewegingen door te geven bij h265 maken dat proces veel preciezer en dus hoeft er minder informatie te worden doorgegeven voor het beschrijven van veranderingen of afwijkingen.
Het landschap van videocodecs
Codec is een samenstelling van coder en decoder, en staat voor een systeem dat een audio- en/of videosignaal kan comprimeren en dat signaal vervolgens ook weer kan omvormen tot de gewenste audio en video. De komst van nieuwe codecs is een logisch gevolg van de niet aflatende behoefte om steeds meer data zo efficiënt mogelijk te versturen, en van de toenemende beschikbare rekenkracht en bandbreedte. Daar komt bij dat er geld valt te verdienen met videocodecs, dus hebben bedrijven niet per se de behoefte om zich bij een codec van andere bedrijven aan te sluiten. Ze komen soms liever met een eigen compressiestandaard, zeker als dat besparingen oplevert aan royalty's voor andermans codecs. Zo is een landschap ontstaan dat altijd in beweging is en waarin verschillende codecs worden gebruikt, die ook met elkaar wedijveren. Om daar wat meer op in te zoomen, staan we hieronder stil bij enkele videocodecs die nu de dienst uitmaken of dat wellicht in de toekomst gaan doen.
H264
Advanced video coding, ook wel aangeduid met h264 of mpeg-4 part 10 advanced video coding, werd in 2003 gestandaardiseerd door de ITU-T Video Coding Experts Group en de ISO/IEC Moving Picture Experts Group. De Moving Picture Experts Group zal een belletje doen rinkelen als de naam wordt afgekort tot mpeg. De groep zit achter de videocodec die vandaag de dag nog overal is te vinden. Uit gegevens op Statista zat h264 tussen 2016 en 2018 op een marktaandeel van rond de 80 procent, iets waaraan h265, Googles vp9 en WebM bij lange na niet konden tippen en dat is nog altijd het geval.
MeFeedia liet in 2011 zien hoe snel h264 een opmars heeft gemaakt bij html5-video's op het web. In januari 2010 was de codec verantwoordelijk voor 10 procent van de html5-playback en in juni 2011 was dat al gegroeid tot 69 procent. Deze groeispurt werd verklaard door de opkomst van moderne browsers en de enorme groei in de mobiele sector, waarbij vooral naar Android en iOS kan worden gekeken. Verder heeft de opkomst van op video gerichte tablets een duit in het zakje gedaan, net als slimme tv's en blu-rayspelers. H264 wordt overal toegepast, van streamingdinesten en blu-rays tot aan browsers, besturingssystemen, mobiele platforms, opnameapparaten, kabel- en satelliet-tv, en digitale beveiligingscamera's.
H265
In de begintijd van h264 stond een efficiëntere codec al te trappelen. De in 2013 geïntroduceerde opvolger h265, ook bekend onder de naam hevc en eveneens ontwikkeld door de ITU-T Video Coding Experts Group en de ISO/IEC Moving Pictures Experts Group, zat er al aan te komen wegens voorstellen van de groepen om de h264-standaard te verbeteren. Die verbeteringen, waaronder de ondersteuning van resoluties tot 8192x4320 pixels en een 10bit-kleurruimte, vergden nogal wat extra rekenkracht en die was destijds nog onvoldoende beschikbaar. Om te voorkomen dat de chips overuren moesten draaien en de stroomrekening te veel zou oplopen, werd niet tot het uiterste gegaan bij de mate van compressie in h264. Met de gaandeweg toegenomen rekenkracht en de teruglopende kosten was h265 later wel kansrijk. Ten opzichte van h264 vergt h265 grofweg tien keer zoveel rekenkracht.
De belofte was even simpel als aantrekkelijk: een besparing tot 50 procent in bandbreedte ten opzichte van h264 bij dezelfde videokwaliteit. Daarmee is de nieuwere codec ook een stuk geschikter voor 4k-video's, aangezien al die extra data niet hoeft te leiden tot veel grotere bestanden. Er zijn studies waarbij die besparing op de bits bij 4k-materiaal zelfs opliep naar 64 procent. Niet toevallig is h265 de codec die gebruikt wordt voor de compressie van films op uhd-blu-rays. Ook streamingdiensten maken er gebruik van en uiteraard kunnen allerlei videospelers, zoals Kodi en VLC, met h265 gecomprimeerde data decoderen en afspelen. Dergelijke spelers kunnen handig zijn, mede doordat Microsoft ondersteuning voor h265 uit Windows 10 haalde met de Fall Creators Update.
Uit het Video Developer Report 2019 van Bitmovin blijkt dat h264 nog altijd heer en meester is. In 2019 gaf 91 procent van de ondervraagde ontwikkelaars aan het te gebruiken of in de komende twaalf maanden te gaan implementeren, tegenover 43 procent voor h265. Mpeg2 was goed voor 29 procent, gevolgd door vp9 met 12 procent en av1 met 7 procent. H265 is overduidelijk groeiende, maar kan zijn voorganger voorlopig niet van de troon stoten.
Vp9
Naast de Moving Picture Experts Group heeft ook Google zich niet onbetuigd gelaten. Vp9 kwam uit in 2013 als de opvolger van vp8 en is de dominante codec op YouTube. Ook webbrowsers als Chrome, Opera, Edge en Firefox ondersteunen de codec; er is Android-ondersteuning sinds versie 4.4 KitKat en ook veel smart-tv's ondersteunen vp9-decoding. Netflix maakt eveneens gebruik van vp9 en met de komst van iOS 14 lijken ook iPhone-gebruikers YouTube-video's in 4k en hdr te kunnen streamen, wat voorheen niet kon. Dat komt doordat Google begin 2017 is gestopt met de ondersteuning van h264, is overgestapt op vp9 en hevc niet heeft omarmd. Apple weigerde tot nu toe om vp9 te omarmen, waarschijnlijk mede omdat het bedrijf in hevc heeft geïnvesteerd. Vp9 ondersteunt 4k, 10 of 12bit en hdr, en is daarmee net als hevc geschikt voor uhd-content.
Av1
Vp10 was in de maak en Google publiceerde er onder meer code voor in 2015, maar het bedrijf heeft besloten om vp10 te laten opgaan in een andere videocodec: AOMedia Video 1 of av1. Deze codec is naast vp10 gebaseerd op technologie van de Daala-codec van de Xiph.Org Foundation en Mozilla, en de Thor-codec van Cisco Systems. Av1 kwam in begin 2018 uit en is ontwikkeld door de Alliance for Open Media. Zowel Google als Apple maakt daarvan deel uit, naast veel andere grote namen, zoals Netflix, Facebook, LG, Microsoft en Samsung. Netflix is eerder dit jaar ook al in beperkte vorm begonnen met streamen via de av1-codec, en YouTube en Vimeo maken er ook in beperkte mate gebruik van.
Omdat av1 een relatief jonge codec is, is er nog geen brede ondersteuning. Er is softwarematige ondersteuning door Chrome, Opera, Edge en Firefox, maar de software-implementaties van de av1-standaard, zoals de code-intensieve Libaom-referentiecodec, de voor datacenters en Intel Xeon-processors bedoelde svt-av1-codec en de dav1d-decoder, zijn nog niet allemaal uitontwikkeld en bugvrij. Op hardwarevlak is het niet beter; er zijn nog maar weinig processors of socs die hardwarematige av1-decoding ondersteunen. De Oppo Reno3 5G vormt een uitzondering, doordat deze smartphone is uitgerust met de MediaTek Dimensity 1000, de enige smartphone-soc die het ondersteunt. YouTube voor Android TV is in het voorjaar geüpdatet met av1-ondersteuning. Veel Android TV-apparaten met ondersteuning voor hardware-accelerated av1-decoding zijn er echter niet en de nieuwe Nvidia Shield TV uit 2019 biedt evenmin soelaas. Alleen socs als de Broadcom BCM72190/72180 en de Realtek RTD1311/RTD1319 vormen een uitzondering. LG's 8k-oled-tv's in de ZX-lijn ondersteunen av1 en dat geldt ook voor alle 8k-tv's van Samsung die in 2020 uitkomen.
H266/VVC
De ISO/IEC Moving Picture Experts Group heeft niet stilgezeten en heeft begin deze maand de officiële opvolger van h265 uitgebracht, samen met Fraunhofer HHI, de Video Coding Experts Group en een aantal grote spelers uit de techsector, zoals Apple, Ericsson, Intel, Huawei, Microsoft, Qualcomm en Sony. De opvolger heet h266 of versatile video coding. H266 zou in vergelijking met hevc een stuk efficiënter zijn op het vlak van het compressiealgoritme. Volgens Fraunhofer HHI worden nieuwe chips met hardwarematige ondersteuning voor h266 momenteel al ontworpen en de eerste softwarecoders moeten in de herfst uitkomen.
Veel moet nog duidelijk worden, maar h266 zal volgens het consortium weer een flinke stap voorwaarts zijn ten opzichte van h265. Fraunhofer HHI gaf daar een voorbeeld van; een negentig minuten durende uhd-video zou met h265 10GB data opleveren en bij h266 zou dat bij dezelfde kwaliteit uitkomen op 5GB. De codec zou vooral erg effectief zijn bij videomateriaal met een hoge resolutie, waarbij het instituut specifiek het streamen van 4k- en 8k-video's noemt. Ook high dynamic range en 360-gradenvideo's worden ondersteund.
H266 gaat ook nog steeds uit van de principes van zo ongeveer alle voorgangers: de codeeraanpak op basis van het eerder besproken concept van blocks, waarbij elk frame in blocks wordt opgesplitst, waarna alle blocks in een volgorde worden verwerkt. Volgens Christian Feldmann van Bitmovin heeft het consortium dus niet het wiel opnieuw uitgevonden en is h266 geen revolutie, maar vooral een evolutie. Zo zijn bijvoorbeeld de blocks weer een stuk groter; waar ze bij h264 en h265 een formaat hebben van respectievelijk 16x16 en 64x64 pixels, is dat bij h266 128x128 pixels. Om de blocks te coderen, moeten ze meer dan eens opgeknipt worden in kleinere blocks en dat opknippen kan op heel veel manieren gebeuren, leidend tot allerlei vormen. Dat maakt dat de coding units bij h266 veel flexibeler zijn en daarmee veel beter kunnen inspelen op de content die gecomprimeerd moet worden. De sterk toegenomen flexibiliteit is goed nieuws voor de mate van compressie, maar betekent automatisch ook extra hoofdbrekens voor de coder, want die moet alles proberen en berekenen hoe het beste opgesplitst kan worden.
Links de wijze van partitioning/opsplitsen bij h265 en daarnaast de veel grotere flexibiliteit die betracht kan worden bij h266
Evc
Mpeg komt overigens ook nog met twee andere, nieuwe codecs: evc en lcevc. Lcevc is min of meer een add-oncodec, die uitgaat van h264 of h265 en de codeersnelheid daarvan verbetert. Deze codec laten we hier verder buiten beschouwing. Mpeg-5 essential video coding of evc is te beschouwen als een alternatief voor h265 en moet niet alleen een bitratebesparing opleveren van grofweg 31 procent ten opzichte van h264 of 26 procent ten opzichte van h265; de codec is vooral ook bedoeld om iets te doen aan de bekritiseerde licentiestructuur van h265. Evc wordt door mpeg omschreven als 'een codeerstandaard voor degenen die een ISO-standaard willen gebruiken, maar niet in staat zijn hevc te gebruiken'. De codec heeft een deel dat royaltyvrij is en een beter presterend deel, het Main-profile, waaraan wel royalty's zijn verbonden. Dit gedeelte hanteert tools die aan- of uitgezet kunnen worden zonder dat de prestaties er serieus onder lijden.
Na een in oktober 2018 uitgebrachte call for proposals koos mpeg voor het voorstel van Qualcomm, Huawei en Samsung. In april 2020 werd de First Draft International Standard-beschrijving van evc uitgebracht en een maand later gaven Qualcomm, Huawei en Samsung aan de standaard te omarmen. De drie bedrijven hebben naar eigen zeggen elk aanzienlijk bijgedragen aan de nieuwe standaard en geven aan de codec vooral te willen inzetten voor content met 4k, 8k, hdr, vr en ar. Ze zeggen ook het Frand-principe te zullen eerbiedigen. Het betekent dat een patenthouder aangeeft dat hij bereid is de patenten waarvan de technologie in een standaard terechtkomt, beschikbaar te stellen aan geïnteresseerden, door onder redelijke voorwaarden een licentie voor het gebruik van de patenten te verstrekken. De uiteindelijke licentievoorwaarden worden uiterlijk in april 2022 gepubliceerd. Pas als die voorwaarden er zijn, wordt duidelijk of de bedrijven woord hebben gehouden en of de situatie nog altijd overzichtelijk is met een enkele patentgroep.
Licentiechaos bij h265 en opensourceconcurrentie
De komst van vp9 en vooral av1 kan niet los worden gezien van de licentiechaos die h265 heeft gecreëerd. Vp9 en av1 staan namelijk nadrukkelijk te boek als open source en zijn codecs waarvan het gebruik niet gepaard gaat met de betaling van royalty's. Delen van de vp9-standaard zijn weliswaar onderdeel van patenten van Google, maar de aan de codec gerelateerde patenten zijn gratis te gebruiken conform het concept van wederkerigheid. Zolang de gebruiker niet overgaat tot juridische stappen met betrekking tot de patenten, zijn ze vrij te gebruiken.
Patentpools
Hoe anders was en is dat bij h264 en vooral h265. Een bedrijf dat of organisatie die een product met h265-ondersteuning wil uitbrengen, moet eerst licenties afnemen uit in ieder geval drie patentgroepen: Velos Media, Mpeg LA en HEVC Advance. Mpeg LA geeft patenten in licentie van onder meer Apple, Canon, JVC Kenwood en Samsung, terwijl HEVC Advance dat doet voor patenten van onder andere Dolby Labs, Mitsubishi, Samsung, Philips en Warner Bros. Entertainment. Velos Media geeft licenties voor patenten van bijvoorbeeld Ericsson, Panasonic, Qualcomm, Sharp en Sony. Technicolor leek los van HEVC Advance te gaan opereren om zijn patenten bilateraal in licentie te geven, maar het bedrijf trad in oktober 2019 alsnog toe tot deze groep, nadat het in 2018 zijn patenten had verkocht. De reden voor het bestaan van drie pools in plaats van een enkele is simpel: geld. Codec-expert Jan Ozer stelt dat bijvoorbeeld iedereen in HEVC Advance de kans had tot MPEG LA toe te treden, maar ervoor koos dat niet te doen. De motivatie daarvoor was de gedachte dat men meer geld kon verdienen met een andere groep.
Aandeel van patentbezitters in de h265-standaard. Afbeelding: IPWatchdog
Onzekerheid en vertraagde innovatie
Deze patentgroepen zijn in feite pogingen om licentieafnemers een mate van zekerheid te geven dat hun licentie dekking biedt voor zoveel mogelijk patenten. Dat is een stuk handiger dan apart gaan onderhandelen met alle individuele patenteigenaren en het neemt in ieder geval deels de zorgen weg van mogelijke rechtszaken wegens schending van een bestaand hevc-patent. De pool van HEVC Advance bevat zo'n 10.800 patenten, terwijl de pool van MPEG LA ongeveer 7400 patenten heeft. Beide pools delen zo'n 5160 patenten van bedrijven als Canon, JVC Kenwood, Samsung, NEC en Ideahub. Het idee is dat als een bedrijf licenties van alle drie de pools afneemt, veel gedekt is en dat het risico op juridische procedures met andere eigenaren van intellectuele eigendom heel klein is.
Toch is dat niet zo. IPWatchdog schreef in 2018 dat er nog altijd grote techbedrijven met patenten zijn die niet zijn toegetreden tot een van de pools, zoals LG en Huawei, al traden beidebedrijven begin dit jaar uiteindelijk alsnog toe tot HEVC Advance. Dan zijn er ook bedrijven als Samsung en Mediatek, die slechts een deel van de relevante patenten in een of meer patentenpools hebben ingebracht. Twee jaar geleden was twee derde van de relevante patenten geen onderdeel van een van de drie pools. Ook al is dat deel inmiddels wat kleiner, het betekent nog altijd een behoorlijke mate van onzekerheid. Het helpt ook niet dat de verschillende pools niet al vanaf dag één hun licentievoorwaarden gereed hadden. MPEG LA kwam daar in september 2014 mee, HEVC Advance in 2015 en Velos Media was nog veel later.
Die voorwaarden waren bijvoorbeeld dat bij MPEG LA de eerste honderdduizend apparaten royaltyvrij waren, inclusief software-implementaties. Daarna was er een tarief van 20 dollarcent per apparaat tot een jaarlijks maximum van 25 miljoen dollar. HEVC Advance kwam in eerste instantie met een royaltytarief van 2,60 dollar per apparaat en een royaltytarief voor content van 0,5 procent van de omzet. HEVC Advance voerde na veel kritiek weliswaar verlagingen en aanpassingen door, maar de kosten bleven hoog. Ten opzichte van h264 zijn de licentiekosten bij h265 een paar maal zo hoog bij verkoop van meer dan vijf miljoen apparaten.
Volgens een advocaat met kennis van de materie leidden deze hoge kosten, en het gebrek aan transparantie en duidelijkheid tot aarzeling bij contentproviders en sommige hardwareproviders om 4k-technologie te implementeren. Bij gebrek aan duidelijkheid over de tarieven en wat de pools gaan doen, is afwachten een logisch gevolg. Dat heeft volgens hem geleid tot vertraging bij de introductie van uhd-blu-raydiscs en grote streamingplatforms. "Die vertraging was grotendeels een kwestie van geld. Het werd ook wel een beetje veroorzaakt door de concurrerende formats van elke patentpool, maar ze gebruiken de onderliggende compressietechnologie op dezelfde manier."
Prestaties van hevc, av1 en vvc
In het voorgaande zijn al de nodige claims voorbijgekomen waarbij bedrijven achter een codec met een percentage aangeven hoeveel efficiënter hun codec is ten opzichte van een eerdere of concurrerende codec. Om daar wat dieper op in te gaan en iets te kunnen zeggen over de prestatieverhoudingen van vvc, av1 en h265, kunnen we kijken naar eerdere praktijktests.
BBC Research & Development, de technische onderzoeksafdeling van de Britse omroeporganisatie, voerde vorig jaar een test uit waarin naar voren kwam dat vvc, in de vorm van vtm, ofwel het vvc test model, ten opzichte van h265 27 procent beter scoorde op de bitratebesparing bij hd-video en 35 procent bij uhd-video. Av1 bleek tijdens de test redelijk vergelijkbaar met h265.
Uit de grafieken voor de uhd-video's blijkt dat vvc ten opzichte van hevc consistent hogere peak signal-to-noise ratio-waarden haalde bij een gelijke bitrate. De peak signal-to-noise ratiois een kwaliteitsmaatstaf, net als het eerder genoemde vmaf. Ook is te zien dat av1 en hevc elkaar niet veel ontlopen, al benadrukken de onderzoekers dat av1 een belangrijk voordeel heeft. Naarmate de bitrate verder oploopt, haalt hevc av1 in en haalt het een hogere kwaliteit voor dezelfde bitrate. Av1 produceert echter juist video van een hogere kwaliteit op lagere bitrates. Dat laatste, dus gedecodeerde video van een hogere kwaliteit in scenario's met een lage bitrate, is sterk gewenst bij coderen.
Dit vertelt echter niet het hele verhaal. De tijd die een codec nodig heeft om video's te verwerken, is misschien net zo belangrijk. Oplopende verwerkingstijden betekenen oplopende complexiteit en dus de noodzaak van meer computerrekenkracht. Het coderen van video gebeurt doorgaans aan de kant van de omroep of de streamingdienst, mede omdat daar de benodigde rekenkracht aanwezig is. Er moet echter ook gedacht worden aan het scenario van de thuisgebruiker die een video uploadt of een rip maakt van een blu-ray. Het beperken van de complexiteit is zeker voor de thuisgebruiker belangrijk, maar ook voor bedrijven. Zij kunnen dan tijd en kosten besparen door sneller te coderen, al dan niet op goedkopere, eenvoudigere apparaten.
Uit de test van de BBC blijkt dat de efficiëntere compressie van vvc een prijs heeft. In vergelijking met hevc duurt coderen met vvc 6,5 keer zo lang en decoderen 1,5 keer zo lang. Als av1 tegen hevc wordt afgezet, blijkt dat coderen met av1 4 keer zo lang duurt, maar 8 procent sneller is te decoderen. Dit laatste maakt volgens de onderzoekers weer duidelijk dat av1 sterk is geoptimaliseerd voor streaming.
In een ander onderzoek van de Moscow State University werd dit punt van de extra tijd voor coderen met av1 nog eens benadrukt: "Av1-coder heeft een extreem lage snelheid." In een vergelijking met vp9 en hevc kwam av1 wel duidelijk als beste uit de bus, met de kanttekening dat de av1-coder nog niet denderend was en de nodige verbeteringen kon gebruiken. Uit de resultaten blijkt dat av1 dezelfde kwaliteit als de x264-decoder wist te bereiken en daarvoor slechts 55 procent van de data nodig heeft. Vp9 bleek iets beter te presteren dan hevc.
In weer een ander onderzoek uit maart van dit jaar blijkt dat av1 ten opzichte van hevc een bitratebesparing van 7,3 procent haalt bij uhd-video's en 3,8 procent bij hd-video's. Vtm liet av1 echter weer ver achter zich, met besparingen die tussen de 27 en 30 procent lagen. De onderzoekers concluderen dan ook dat de prestatie van av1 een kleine verbetering is ten opzichte van hevc, terwijl zowel av1 als hevc significant slechter presteert dan vtm.
Slot
De grote vraag is hoe het veld er over pakweg vijf jaar uitziet. Hoe dominant is h264 dan nog en heeft diens opvolger dan echt het stokje overgenomen of blijven de licentiecomplexiteit en het daarmee gepaard gaande negatieve imago de h265-codec parten spelen? Av1 is specifiek in het leven geroepen als reactie op de licentiechaos die h265 heeft gecreëerd en lijkt daarmee automatisch een streepje voor te hebben. Mpeg reageerde weer op het ogenschijnlijke royaltyvrije karakter van av1 door evc uit te brengen. En het duurt nog wel even voordat vvc echt tot leven komt, maar hoe levensvatbaar deze zeer geavanceerde maar zeer complexe codec wordt, is nog niet te zeggen. Het is lastig het landschap van over vijf, laat staan tien jaar te schetsen. Veel hangt af van marktbeslissingen, hoe goed codecs (verder) worden ontwikkeld, of er voldoende hardwarematige ondersteuning komt en of er voldoende goedwerkende decoders verschijnen. Het is misschien ook veelzeggend dat er allerlei bedrijven zijn die in meer dan één codec hebben geïnvesteerd. In zekere zin is dat wedden op meer dan één paard.
Leonardo Chiariglione
Leonardo Chiariglione, een Italiaanse technicus en medeoprichter van mpeg, durft ook nog geen duidelijke winnaars en verliezers aan te wijzen, al is hij wel duidelijk over de organisatie die hij in 1988 heeft opgericht en waaruit hij in juni van dit jaar vertrok. Hij omschrijft het als een 'feodale organisatie' met de nodige logheid en waar onnozele bureaucraten de dienst uitmaken. Veel vertrouwen in mpeg heeft hij niet, maar volgens hem is er vanuit technisch oogpunt weinig dat de drie mpeg-codecs - vvc, evc en lcevc - kan laten ontsporen. Hij stelt dat het gat dat hevc heeft achtergelaten, is opgevuld door av1 en dat vvc zomaar hevc achterna kan gaan, mede doordat het aantal patenthouders volgens hem bij vvc nog veel groter is.
Het in 2018 in het leven geroepen Media Coding Industry Forum, bedoeld om de adoptie van mpeg-standaarden en het licentieproces te bespoedigen, heeft volgens de Italiaan nog weinig voortgang geboekt. Hij zegt dat het je ook moeilijk voor te stellen is dat vvc het beter gaat doen dan hevc. Het kan weleens een heel donker scenario worden voor vvc, omdat de adoptie ervan in de broadcastwereld jaren zal duren, als het al gaat gebeuren, aldus Chiariglione. Evc, een standaard die hij eigenhandig heeft gestimuleerd, acht hij veelbelovend, omdat de kwaliteit vergelijkbaar is met of beter is dan die van av1, maar dan moet er wel een licentie komen en zover zijn Qualcomm, Samsung en Huawei nog niet. Chiariglione zegt dat het hem nooit te doen was om het succes van evc, maar dat evc interne competitie teweegbrengt en zodoende de kansen van vvc kan vergroten. De eenvoudigere en flexibelere licentiesituatie bij evc en av1 kan ertoe leiden dat vvc-patenthouders gedisciplineerd worden en niet anders kunnen dan komen met een degelijke licentie. "Hoewel ik zo'n ontwikkeling verwelkom, schat ik de kans dat dat gebeurt niet hoog in."
Av1 toch niet royaltyvrij?
Is av1 dan echt niet te stoppen? De codec wordt veelal gepresenteerd als het royaltyvrije alternatief, maar dat beeld behoeft toch de nodige nuance. Sisvel heeft in maart een av1-patentpool aangekondigd. De oorspronkelijke pool bestond uit JVC Kenwood, NTT, Orange, Philips en Toshiba, die overigens ook allemaal patenten in licentie geven aan MPEG LA. Sisvel werd echter benaderd door verschillende bedrijven, waarbij hun ip-claims werden onderzocht. Dat leidde tot negen nieuwe leden voor de patentpool, waaronder Dolby Labs en Ericsson.
De verwachting is dat de deelnemers komen tot een licentie voor bijna tweeduizend av1-patenten. Volgens Sisvel-ceo Mattia Fogliacco is dit een logische ontwikkeling. Hij geeft aan dat het doel van de Alliance for Open Media, het niet hanteren van royalty's, erg moeilijk is. "Elke videocodeertechnologie van de afgelopen dertig jaar is het resultaat van samenwerkingen tussen bedrijven en investeringen van die bedrijven. Het is moeilijk te geloven dat één groep, zelfs een alliantie met de grootte van AOMedia, alle technologie kan ontwikkelen die leidt tot een videocodec." Volgens Fogliacco zijn de voorgestelde av1-royalty's, te weten een standaardtarief van 0,32 dollar voor consumentenbeeldschermapparaten en 0,11 dollar voor consumentenapparaten zonder beeldscherm, redelijk en zal AOMedia dat ook erkennen.
De consument
Wat moet de consument die graag naar streamingdiensten kijkt, weleens video's maakt en uploadt, en zelfs weleens een eigen blu-ray ript, met al deze ontwikkelingen? De betere efficiëntie van nieuwere codecs is in theorie goed nieuws voor iedereen, maar betekent ook meer eisen aan de hardware. En als de bitratebesparingen alleen worden gebruikt om aan de kant van de aanbieder kosten te besparen, heb je er als consument niet veel aan. Lagere bandbreedtes voor dezelfde kwaliteit is vooral goed nieuws in regio's waar mobiel gebruik dominant is of waar beperkte data-abonnementen zijn. Een gemiddelde consument in Nederland met een snelle breedbandverbinding en geen datalimiet heeft in principe weinig aan besparingen op de bandbreedte, tenzij Netflix, Disney+, Amazon Prime en andere streamingdiensten de extra headroom gebruiken om ook de kwaliteit een boost te geven.
In deze coronatijd zien we dat de steamingdiensten maar wat graag voldoen aan een bedenkelijk verzoek vanuit de EU om de kwaliteit van de streams te verlagen. Het aanbieden van lossless audioformaten of het hanteren van bitrates die de 20Mbit/s halen en voorbijgaan, lijkt voorlopig toekomstmuziek. De betere compressie van de nieuwere codecs maakt het mogelijk om de streamingkwaliteit te verbeteren, maar in hoeverre dat gaat gebeuren, hangt af van de commerciële keuzes van deze bedrijven. De bitrate van minder dan 1,5Mbit/s waarmee sommige hd-streams het momenteel nog moeten doen, zegt wellicht veel over de manier waarop de betere compressie zal worden ingezet.
Ik werk in de wereld van codecs, VOD platforms en televisie. Grootste probleem op dit moment is met de nieuwste generatie codecs, is dat zo veel CPU power vereist om realtime H.265 / AV1 / H.266 encoderen. Ik heb nog niet de kans gehad om processoren van 10K te gebruiken en te meten of het lukt, maar de huidige server processoren lukt het niet. Je zult dedicated FPGA kaart moeten aanschaffen dat specifiek goed is in 1 taak: encoderen van een codec. Deze kaarten zijn niet goedkoop, maar we goedkoper dan een high end server CPU (https://www.intel.com/con...sors/platinum-8380hl.html). Op dit moment zie je weinig/geen Live televisie kanalen met 4K UHD, omdat voor deze partijen extreem duur is om realtime te encoderen. De huidige 4K UHD kanalen zijn vooraf uitgerekende video’s, en worden op de dag zelf uitgespeeld. Hierdoor kunnen ze net als VOD platforms paar dagen van te voren rustig laten uitrekenen voor dat het bestand nodig is. Ik verwacht pas over 2 jaar dat de nieuw generatie codec met de allernieuwste hardware een beetje realtime kan encoderen. Voor VOD platform maakt dit niet uit en zullen vrij snel overstappen naar nieuwere generaties codec. Hun rekenen deze codecs in hun rekenfarms uit, maar dan kan dus een paar dagen duren tot zo bestand klaar is. Als het bestand eenmalig is uitgerekend, kun je het dus overal voor inzetten. De huidige devices zijn snel genoeg om het bestand te decoden en af te spelen.
Edit: Ik heb leuk topic gevonden op het Anandtech forum, mensen testen met hun hardware hoe goed hun computer presteert als ze H.265 proberen encoderen in 4K UHD: https://forums.anandtech....265.2544492/post-40089077 De topic laat goed zien hoe weinig FPS de huidige generatie hardware kan creëren. Dat is veel te laag voor Europese broadcast standaarden, omdat we voor 4K UHD minimaal 50fps moeten behalen. Het lieft wil je sneller, omdat je ook nog wat overhead wilt hebben voor andere logica.
[Reactie gewijzigd door Xieoxer op 23 juli 2024 15:33]
Ik ben dagelijks bezig met het hercomprimeren van video's in H.265. We hebben heel wat moeten zoeken en vergelijken om van 264 naar 265 te gaan. Wat ziet er het beste uit? Wat is het snelste? Wat gebruikt het minste bitrate? Uiteindelijk hebben we besloten van het volgende te gebruiken:
Preset high crf21 met schrijven van 'pass1 log' (bepalen bitrate nodig) en dan de bitrate gebruiken samen met de log om een pass 2 te maken.
Ik heb een 8700K op een allcore 4.7GHz (12 threads - AVX enabled - 10 threads gebruikt voor compressie)
Een nieuwe 4K HDR film zonder ruis duurt dan ongeveer 3 dagen en heeft een bitrate van 4000-8000 naargelang het type (actie/tekenfilm)
Een 4K HDR met ruis daarentegen (oudere films) zonder filter is een ramp, bitrates van 20.000+ zijn dan geen uitzondering. We opteren dus voor een ruisfilter, maar dit zorgt er wel voor dat het 7 dagen duurt voor een film...
Een paar kleine 15W NUCjes zorgen voor de HD films.
Erg interessante cijfers en instellingen dit. Heb je toevallig ook de gegevens de over de besparing die je bereikt tussen 4k 264 en 4k 265 (en hetzelfde voor de HD bestanden)?
En gebruik je ook dezelfde instelling voor HD recodering?
4k 264 hebben we nooit gedaan, waarom zou je het HDR signaal verwijderen?? Wat ik wel kan zeggen is dat de bitrate van 264 (1080p) soms exact hetzelfde is als de bitrate van 265 (4K HDR), en je kan zeggen dat de 4K veel beter is.
Voor 1080p en minder gebruiken we identiek dezelfde settings. Voor 264 gebruikten wij dezelfde manier van werken maar met 'very high' preset (met een paar tweaks) ook op crf21 en 2pass.
Winst in bitrate is ongeveer 30% als je 264 en 265 vergelijkt. (eindbestand, dus met audio gemuxt)
Winst in kwaliteit is er ook, we hebben een test gedaan waarbij we het verschil maakten tussen originele frame en gecomprimeerde, en dat versterkten met factor 100. Zo bepaalden we de kwaliteit. We hebben getest met tekenfilm, actie, DVD, 4K, 1080p... zoals ik al zei, maanden werk....
Elke 'upgrade' die we maken 264->265->265v2 (onlangs grote update) proberen we alle 3 de factoren te verbeteren.
Dus een 4k compressen middels h264 is dus eigenlijk jezelf voor de gek houden? Je denkt dat je nog steeds 4K kijkt, maar in werkelijkheid gebeurt er iets anders?
Hoe hoger het level, des te zwaarder voor de decoder, dus voor compatibiliteit met hardware decoders kun je het beste het zo laag mogelijke level aanhouden dat nodig is voor je resolutie en framerate.
[Reactie gewijzigd door Mathijs op 23 juli 2024 15:33]
Ja en nee.
Voor het decoderen gebruiken we hardware support.
Voor het encoderen niet, aangezien de hardwaresupport beperkter is dan software. Zonder moeilijke woorden op te moeten zoeken even een voorbeeld:
Codec ondersteund volgende settings/modus: A tem Z
Software ondersteund A tem Z
Hardware ondersteund A tem H
Als we dezelfde zettings via hardware probeerden, ging het inderdaad sneller... maar de geavanceerde instellingen en modussen gebruikte het niet, aangezien die niet ondersteund waren.
Maw, het is een uitgeklede 265, die eigenlijk niet veel voordeel bied tov 264. (Als we mediainfo vergeleken bij de eindresultaten zagen we dit heel duidelijk)
Goed te weten dat hardware die dus claimt H.265 encoderen te ondersteunen dat dus maar deels doet. Staat zoets in de hardware specs of zijn jullie daar nu per toeval achtergekomen.
Per toeval.
Als we testen deden tussen snelheid HW/SW encoderen, dan was de HW altijd sneller. Maar waarom je dan met dezelfde encoding settings grotere bestanden en slechtere visuele kwaliteit kreeg bij HW, liet ons het eens verder onderzoeken.
Het is al wel een tijdje geleden. Het kan zijn dat hun interne codecs beter zijn geworden....
Een andere hint (dat het over een afgeslankte versie encoder ging) was het feit dat de encoder (in het grafische stuurprogramma) amper 20% van de size was van de andere codec die we gebruikten.
Vergeet ook niet dat 'standaardsettings' een heel deel van de speciale encoding afzet. Net zoals hier in het artikel stond over de richting waarin pixels konden verschuiven en gedetecteerd worden door de codec, was het in 264 enkel in 5 richtingen, tenzij je naar 'placebo' settings ging, dan waren het er pas 9 zoals in het artikel staat.
Zo kan je er ook van uitgaan dat h265 basic maar 9 richtingen ondersteund en pas bij tweaken en/of placebo settings alle 35 ondersteund. Maar ik wil niet weten hoe lang je dan bezig bent met encoding...
(bovenstaande is niet 100% bewezen, maar is min of meer wel ongeveer hoe het werkt, hoe de documentatie het beschrijft en hoe we het hebben gezien in onze tests)
Neem aan dat het zo in de hardware van gpu zit dat jullie instellingen er dus niet bijzitten of misschien is het een driver verhaal van de gpu kaart die deze setting niet ondersteund.
Maar interessant om te weten dat hardware encoden dus ook dit soort problemen kan geven. Als je het niet weet zal niemand je het vertellen.
Voor het encoderen niet, aangezien de hardwaresupport beperkter is dan software.
Welke hardware heb je getest ? Er zitten namelijk nogal behoorlijke verschillen tussen een Intel QSV (en dat ook weer onderling per generatie), AMD en NVidia, en dan ook nog eens tussen de generatie GPU.
Zo heeft NVidia's Turing GPU (oa. RTX serie) ondersteuning voor HEVC B frames, en is de overall quality ook een flink stuk beter t.o.v. Pascal ( GTX10x0 ).
De voorwaartse stappen van Turing zijn intussen zo goed, dat de kwaliteit vergelijkbaar is met CPU encoding op medium preset.
Een consumenten Turing GPU zou met alle toeters en bellen minstens 30fps in 8K HEVC moeten halen.
Getest op 9xx en 10xx kaarten van NVidia en Intel QSV.
Maar zoals je zelf zegt, Turing GPU is vergelijkbaar met CPU medium, dus nog even geduld om echt op 'high' presets te kunnen werken, zoals we momenteel doen.
Zoals ik hierboven al heb vermeld, de huidige manier van werken hebben we besloten te gebruiken na het grondig afwegen van alle mogenlijkheden.
De fixed-function chips op videokaarten zijn rete snel, maar halen bij lange niet de kwaliteit (met dezelfde bitrate) van een (goede) software oplossing.
Turing is wel beter geworden dan Pascal bij de Nvidia kant. Ik heb geen actuele ervaring met de amd kant.
Er is wel acceleratie mogelijk (dat de software dus bepaalde dingen probeert te doen op de shaders van een gpu, dat is wat anders dan de fixed function nvenc encoder bijvoorbeeld) maar dat hangt dus af van de software.
Er was ooit een OpenCL accelerated build van x264, maar dat zette niet veel zoden aan de dijk.
Adobe heeft pas best recentelijk een update uitgebracht die 'gebruikt maakt van de gpu voor encoden' en ik geloof dat doe gpgpu gebaseerd is, niet fixed function.
Als software zegt 'gpu gebruiken voor encoden' is het dus altijd maar de vraag of het nvenc/vce/qsv is (en je dus bent overgeleverd aan de kwaliteit die de gpu er van maakt met geen tot weinig invloed van de software), of dat het echt een implementatie is die gpgpu gebruikt.
Buiten de pro-wereld / serverwereld wordt er nog een hoop op de cpu gedaan als kwaliteit-per-bitrate belangrijk is.
Dank je voor de uitleg, toch blijft het apart, geen gpu zou dit toch moeten kunnen zelfs met de instellingen die software ook kan. Is het een driver kwestie van de gpu of zit het encoderen dan maar beperkt hardwarematig ingebakken.
Begrijp dus nu als je leest dat hardware x.264 of 265 kan encoderen je dat goed moet bekijken.
Fixed function chipjes zijn zwarte dozen. De software geeft het input, heeft wat parameters om aan te passen, en het chipje geeft output. Zonder controle. Het algoritme zit dus hard-coded op de chip en is niks mee te doen. Deze zijn - tot nu toe - duidelijk optimized for speed en niet voor kwaliteit per bitrate.
Programmeren op de gpu (gpgpu, de eerste gp staat for general purpose) Kan in principe alles wat de cpu kan.. Wil niet zeggen dat alles handig kan. Korte antwoord is, blijkbaar is het niet zo simpel op encoding taken _goed_ op de gpu te doen. Het kan wel, hier en daar verschijnen goede oplossingen.. Meer zo simpel blijkbaar nog niet.
Een moderne codec moet naar een aantal seconden aan videobeeld tegelijk kijken. Wat ik er van begrijp - en ben absoluut geen expert hier - is dat de bottleneck vooral zit in memory access van gpgpu. De bakken aan data die nodig zijn voor de calculaties heen en weer sturen naar de cpu vertraagt de boel. Gpu's werken vooral als het algoritme lekker lang kan crunchen op hetzelfde kleinere stukje aan memory. Maar de bakken aan data van een stukje video in 4k uncompressed maken het moeilijker.
Het bestaat zeker wel, begrijp me niet verkeerd. De makers van de open-source encoder x265 (wat weinig met x264 van doen heeft behalve de lijkende naam) hebben zelf wel een gpu accelerated codepath, maar die houden ze commercieel. Geen idee wat de performance er van is (snelheid VS kwaliteit VS bitrate).
misschien een ultiem domme vraag: is het mogelijk om het originele beeld beeld op te delen in een grid van bijvoorbeeld 16 vlakken en deze vlakken apart te coderen en bij het afspelen weer te fuseren? Zo zou je de load kunnen verdelen ipv de hele stream encoderen in 1 taak plaatsen
Dat kan zeker, al zijn er twee nadelen (io ga nu enkel over hevc in detail, over andere codecs weer ik weinig):
Ten eerste lever je wel wat coding efficiëntie (kwaliteit per bit) in, omdat je intra predictie niet werkt over de "knip" die je maakt (blokken die op naburige blokken zijn gebaseerd). Dat valt wel erg mee, ik heb daar testen mee gedaan, een 4K beeld in 4 delen had nagenoeg geen effect op de efficiëntie. In 16 delen wordt wel wat meer, ik zou dat enkel bij 4k doen. Bij 1080p wil dit zeggen dat je het beeld in stukken van 480x270 opdeelt, oftewel 8 bij 5 CBTs. Van die 40 blokken liggen er 22 CBTs aan de randen, en die hebben suboptimale efficiëntie. De impact wordt dan wel erg breed.
Ten tweede is er een risico dat je block artefacten krijgt op de randen van die gebieden, waardoor je je "knip" gaat zien. Dat kan je weer reduceren door de inloopfilter (een proces op het einde van het encoden van elke frame) dan weer over het hele frame te doen. Bij hevc zit daar namelijk een deblocking filter in (kort gezegd: edges van coding blocken worden geblurd, maar enkel daar waar dat de kwaliteit van de video verbetert. De encoder checkt waar dit het geval is en stuurt dat mee in de stream) en die kan dat wel oplossen. Maar dat wil dus zeggen dat je een deel van de encoder wel weer op 1 machine moet doen, je kan dan dus niet aparte steams sturen.
[Reactie gewijzigd door kiang op 23 juli 2024 15:33]
Misschien kan dat, maar dan mis je wel veel compressiemogelijkheden wat betreft de intra prediction (wanneer een bewegend object verplaatst van het ene blok naar het andere).
Ik heb weinig verstand van computer architectuur, maar vind het wel erg interessant! In het artikel staat “ Volgens Fraunhofer HHI worden nieuwe chips met hardwarematige ondersteuning voor h266 momenteel al ontworpen”, weet iemand of er toevallig een ‘voor dummies’ uitleg is waarom er nieuwe hardware moet komen voor een softwarematige aanpassing? Of is die conclusie uberhaubt al niet goed?
@tweakers hieronder, bedankt voor de uitleg!
[Reactie gewijzigd door Tweakert99 op 23 juli 2024 15:33]
In Jip en Janneke: Om een plank op te hangen dienen er 2 gaten geboord te worden, 2 pluggen geplaatst te worden en schroeven ingedraaid te worden, hierna hangt de plank. Al deze stappen worden dus nu softwarematig gedaan, echter kan een deel van de instructies verwerkt worden in de hardware van de chip. Dus de gaten en pluggen worden hardwarematig geregeld en er hoeven alleen nog schroeven te worden ingedraaid. Hierdoor is er veel minder rekenwerk nodig om de plank op te hangen.
Zoals Jhojo hierboven uitlegt. Zo zijn er ook chips die speciaal een deel in de hardware hebben voor compressie of encryptie en alleen snel is voor dát doel. Als een apart deel van een CPU dat kan afhandelen (hardwarematige ondersteuning), dan hoeft het 'general purpose' deel dit niet te doen. Die is gemaakt om héél véél taken uit te voeren, maar is daardoor 'gemiddeld' snel voor al die taken.
[Reactie gewijzigd door airell op 23 juli 2024 15:33]
als je voor een bepaalde taak een bewerking moet doen die een CPU met 2 of 3 bestaande instructies kan uitvoeren en je een nieuwe instructie maakt die de bewerking ineens kan uitvoeren, dan kan die de taak veel efficiënter uitvoeren. Instructiesets zitten voorgebakken in CPU's en zijn niet uit te breiden, vergelijk het een beetje met een rekenmachine die enkel kan optellen: 1+1+1 = 3 zijn 2 bewerkingen terwijl 1x3 = 3 slechts 1 bewerking is.
Op dit moment zijn er twee typen encoders en decoders: softwarematig of hardwarematig. Vaak bij nieuwe codecs lossen verschillende partijen het eerst softwarematig op, omdat hardwarematige oplossingen niet direct beschikbaar zijn en alleen op nieuwere type hardware beschikbaar is. Voorde huidige hardware is software matige decoding van een H.265 of AV1 bestand niet zo probleem, maar een hardwarematige oplossing is vele male sneller, omdat op de processor een extra chip is geleverd die specifiek deze codec snel kan uitpakken (decoden). Daarom is de laatste generatie Raspberry Pi een ideale mediaspeler, omdat deze mini computer een hardwarematige oplossing heeft. Als je dit softwarematig zou moet doen, dan is CPU flink aan het blazen. Er bestaan ook hardwarematige encoders, en deze worden ook geleverd bij Intel processoren. Alleen deze "standaard" encoders zijn beperkt met instel configuraties. Dit is niet elkaar voor partijen zoals Netflix. De voorkeur gaat dan altijd uit naar softwarematige encoder oplossingen. Voor H.264 kan dit prima met de huidige hardware.
In een computer zit een CPU (centrale processor, bijvoorbeeld een Intel) die alles kan berekenen wat je er maar tegenaan gooit. (Software dus)
Dat is op papier prima, ware het niet dat zo’n ding niet geoptimaliseerd is voor bepaalde taken: het moet zo algemeen bruikbaar zijn als maar kan.
Dat maakt zo’n algemene rekenchip erg inefficient en dus trager dan een chip die speciaal is gemaakt voor een enkele (type) taak: een hardware decoder chip dus.
Ik ben vooral benieuwd hoe het staat met encoders op FPGA. NGCodec toonde vorig jaar een live demo met vp9, hevc en av1. FPGA's zijn natuurlijk ook niet goedkoop maar het geeft je natuurlijk wel wat flexibiliteit naar de toekomst toe.
Ik weet niet wat goedkoop of duur is in deze industrie, maar dat maakt ook niet veel uit. Want als er aan de andere kant bijvoorbeeld meer inkomsten gegenereerd kan worden door (live) 4K tv aan te bieden dan doet goedkoop of duur er minder toe. Het gaat om de ROI! Het is een keuze om er een grote of misschien helemaal geen marge op te draaien. Duur is subjectief! Dat er veel geld in omgaat geloof ik graag.
Ik ben wel eens op de IBC geweest en heb daar gesproken met een Japanner van NTT Electronics. Zij bouwen hardware matige codecs voor zowel realtime coderen en decoderen van 4k en 8k content.
Realtime in dit geval was dan wel met 120ms vertraging.
zie ook deze link voor de devices die ze daarvoor gebruiken.
Jij trekt rare conclusies die op niks gebaseerd zijn. Geen Televisie kanalen met 4K/UHD ? En extreem duur om realtime te encoderen? Hoe kom je hier bij? 4K encoders zijn er al vele jaren en die kosten neit significant duurder dan een HD variant. En het is geen verschil wat jij er op uitzend.. of het materiaal nu HD is of 4K maakt allemaal niks uit, het wordt allemaal realtime gecomprimeerd. Hier zit de uitdaging ook niet.. Alleen voor 4K/UHD moet de gehele uitzendketen geschikt worden gemaakt (camera's, studio's, opslagmedia etc) en ook de gehele broadcast keten, het is niet alleen die encoder maar ook de bandbreedte kost geld en de kabelaar of iptv boer moet het ook willen doorgeven, als je kijkt hoeveel zenders wij nog in SD krijgen terwijl ze voor de aanbieder wel in HD beschikbaar zijn.. zegt dat een hoop. .
En toch vraag ik mij af als telefoons van meer dan 2 jaar oud 4k video in h265 opnemen, hoe lastig kan het dan zijn voor jouw doelgroep? Zet je misschien niet de juiste hardware in.
Ik snap dat de kwaliteitseisen bij een smartphone camera veel lager liggen en als je h265 opnames vergelijkt met h264 merk je dat het verschil inderdaad niets voorstelt, maar de hardware is er dus al wel in midrange socs die een paar tientjes kosten. Hoe lastig kan het zijn om een fatsoenlijke hardware encodingoplossing te maken die wel aan je eisen voldoet?
En ja software encoding voor h265 is waardeloos, dat is een feit.
Vanaf een Nvidia gtx1660 heb je ookal 8k hardware hevc met goede b frame support.
[Reactie gewijzigd door fapkonijntje op 23 juli 2024 15:33]
Wat ik dan niet begrijp, broadcasters hebben forse budgetten, een fatsoenlijke hardware encoder moet dan toch niet heel moeilijk zijn? Ik wacht al tijden op 4K50 F1 bij Ziggo. We weten dat RTL (nog) in Duitsland het doet en Sky in UK. Viasat in Scandinavië. Maar hier niet. Het is lijkt mij al in 4K50 encode door de F1 op locatie. (Denk ik zo). Ziggo heeft volgens mij een 4K test kanaal, maar alsnog niet uit aan het zenden. Snap niet waarom niet. Zou de codecs een reden zijn?
Tot een bepaald hoogte. Bijvoorbeeld H.264 is ideaal met 8 cores multi-threading. Ga je hoger met het aantal cores, dan is je effect minimaal. Afhankelijk van de codec kan multi-threading ideaal zijn, maar sommige processen tijdens encoderen is single core performance en blocking.
Is dat zo? Volgens mij zag ik benchmarks waar AMD's 3900X de nieuwe 10900K van Intel verslaat in Handbrake, Premiere Pro en After Effects. Is een Intel chipje dan echt beter om te hebben als je veel videobewerking/encoding/streaming doet?
Je moet een general purpose (x86) CPU simpelweg niet lastig vallen met video encoding of processing. Die aanpak is weergaloos inefficient.
GPU kan een betere oplossing zijn (nieuwste nvenc op Nvidia's Turing gebaseerde kaarten is top), maar software als VLC (geen hardware deinterlacing), MacOS (geen hardware deinterlacing en geen hardware encoding) moet het wel gebruiken...
[Reactie gewijzigd door Morzzz op 23 juli 2024 15:33]
Het laatste jaar heb ik het niet meer zo bijgehouden maar voor het encoderen van video is een dedicated video-chip inderdaad de snelste. Maar als je ook goede kwaliteit wilt overhouden met de zelfde video-specificaties en de zelfde bandbreedte blijkt een proces dat op de cpu draait een veel betere kwaliteit te leveren. De echte puristen hadden het zelfs over een single-core proces.
De achtergrond is dat de dedicatet hardware, de video-kaart of wat dan ook per beeld wel goed kan comprimeren maar juist het genereren van de tussen-frames en daarbij rekening houden met de vorige en eventueel ook het volgende frame bij videokaarten wat lastiger is dan op de cpu.
Zoals gezegd, mogelijk baseer ik mij op verouderde informatie maar het is mij sinds de invoer van mpeg-1 na mjpeg al verteld en bij h264 nog steeds.
Mijn AMD Ryzen 9 3950X (16 cores, 32 threads) kan niet realtime H265 doen. Op een beetje kwaliteit ben ik voor een film van 1.5 uur meerdere uren aan het encoden. Alleen op slechte kwaliteit lukt het realtime.
(ik gebruik Handbrake trouwens, X265 10bit HDR medium quality encode)
Begrijp me niet verkeerd, dit is nog steeds een puike prestatie. Ik had voorheen een i7-7820X die significant slechter presteerde. Aantal cores maakt wel verschil ja
[Reactie gewijzigd door Wildfire op 23 juli 2024 15:33]
Ik weet niet of je in een situatie zit waarbij je toegang hebt tot de IP Cores voor FPGA's maar wij hebben ze in AWS op FPGA nodes draaien (AV1) en dat werkt 1.5x realtime op alle profielen die we qua invoer gehad hebben. Ik zit zelf meer aan de technische kant dan de AV kant maar ik heb nog geen performance problemen kunnen meten. Ik weet niet of het al commercieel verkrijgbaar is (in elk geval nog niet op de marketplace voor zo ver ik kan zien) maar het zit er dus aan te komen zolang je niet nog zelf servers aan het kopen bent. Voor H266 nog niet gezien, behalve een paar filenames van de IP cores voor Xilinx Virtex FPGAs die er op duiden dat de engines er wel zijn maar blijkbaar nog niet gedeeld worden (zal wel een licentie dingetje zijn waar de legal departments over bekvechten).
[Reactie gewijzigd door johnkeates op 23 juli 2024 15:33]
Canon (R5) en Nikon (A7s III) verkopen camera's die real time 4K H.265 60fps en zelfs 8K H.265/30fps coderen.
Dat wordt dus gewoon door een on-board processor op een batterij gedaan. Beide hebben wel wat uitdagingen met warmteproductie wat je rekenkracht onderstreept, maar het moet toch wel heel gek lopen als die cameras met closed body alle externe codering het nakijken geven.
Zoals @HollowGamer al zegt, zit het belang voor de consument in de web browsers.
Hoe goed of slecht een codec is maakt uiteindelijk geen donder uit als deze niet door webbrowsers ondersteund wordt. De adoptie van h264 (AVC) heeft heel lang geduurd door de onzinnige patenten en royalties er omheen. Daardoor kan een organisatie als Mozilla er geen gebruik van maken, die kunnen dat simpelweg niet betalen (laat staan dat het bijhouden lastig is zonder veel tracking; dus dan zit je standaard op de maximale kosten). De enige reden dat h264 inmiddels wél overal ondersteund (en dus gebruikt) wordt, is omdat Cisco binaries beschikbaar heeft gesteld die gratis gebruikt kunnen worden, waarbij zij zelf opdraaien voor de licentiekosten aan MPEG LA. En door hetzelfde geneuzel heeft h265 (HEVC) de strijd al verloren.
Hoe graag sommigen HEVC meer gebruikt zouden willen zien, is dat inmiddels een verloren zaak. Het gaat simpelweg niet meer gebeuren, omdat iedereen die er daadwerkelijk toe doet er niet achter staat. Je zou wellicht denken dat alle bedrijven maar wat graag winst zouden willen maken op zo'n veelgebruikte codec, maar de 7 oprichters van AOMedia zijn moderne bedrijven die begrijpen dat je de codec eerst bij álle consumenten moet krijgen voordat deze gebruikt kan worden. Deze 7 oprichters zijn Amazon, Cisco, Google, Intel, Microsoft, Mozilla en Netflix. En inmiddels maken bedrijven als AMD, ARM en Apple ook deel uit van de organisatie. Veel van deze bedrijven maken ook deel uit van MPEG-LA/HEVC Advance en dergelijke, maar stellen hun patenten dus beschikbaar voor AV1. De enige browser die HEVC ondersteunt is Safari en dat gaat niet meer veranderen.
Vooralsnog lijkt hetzelfde zich te herhalen met VVC. Er zijn wederom meerdere partijen die er geld uit proberen te halen. Als dat gebeurt, is VVC, net als HEVC, gedoemd te falen. Dat ze op hardware royalties vragen is nog te begrijpen, maar als ze niet meteen vanaf dag 1 alle software implementaties volledig gratis maken tot in de eeuwigheid, dan kan die codec meteen weer de prullenbak. Bij HEVC kreeg men eind 2016 door dat er geen animo was in die onzin en maakten ze software implementaties royalty-free, maar toen was het al te laat.
Ik vraag mij ook af of iedereen wel zit te wachten op nog meer codecs en extensies. Met AV1 zit je in theorie de komende jaren goed, terwijl je bij die andere maar moet afwachten inderdaad of het nog iets word en je niet weet aan wie je royalties moet gaan betalen. Dat laatste kan overigens ook een probleem worden voor AV1 zoals genoemd in het artikel, maar het is en blijft wel (grotendeels) opensource.
Betere codecs zijn altijd welkom, maar dan moeten ze ook wel beschikbaar zijn voor iedereen. Zelfs 10% minder bandbreedte voor dezelfde beeldkwaliteit is uiteraard gunstig voor onze internet verbindingen.
Over Sisvel maak ik me geen zorgen, dat is gewoon een troll bedrijf. Ze zijn in Luxemburg gevestigd en hebben al meerdere zaken verloren omdat we hier in Europa strenger zijn. Bestaat grotendeels uit de kleinere aandeelhouders qua patenten omtrent al deze codecs, met uitzondering van IP Bridge; maar dat is zelf ook een patent troll die zich vooral op de VS richt omdat het daar zo makkelijk is. Er zitten wel bedrijven als Dolby en JVCKENWOOD in, maar die hebben weinig in te brengen, die proberen gewoon wat extra centen te verdienen.
Los daarvan wens ik ze echter veel succes tegen AOMedia op te boksen. Daar zitten ook patenthouders in die net even iets harder terug kunnen slaan. Amazon, Apple, Cisco, Facebook, Google, IBM, Intel, Microsoft, Nvidia, Samsung en Tencent hebben stuk voor stuk genoeg patenten om mee terug te slaan. De reden dat ik deze bedrijven er uit pik is omdat ze ook stuk voor stuk genoeg centen hebben om geheel zelfstandig enige kosten op te vangen. Het aantal miljarden dat in AOMedia zit ligt een flink stuk hoger dan in dat groepje van Sisvel
Dit is wel zo'n zaak die vragen oproept over het patentsysteem en zeker het softwarepatent.
Helpt het de innovatie of werkt het juist tegen?
Op het eerste gezicht is het natuurlijk beter dat je 1 licentie kan afnemen in plaats van dat je over 10.000 patenten moet onderhandelen, maar ja, dat lijkt in praktijk dus niet te werken, je blijft met onzekerheid zitten en onzekerheid remt groei en ontwikkeling. Bedrijven durven dus niet gebruik te maken van de nieuwste techniek maar kijken de kat uit de boom.
Je zou kunnen redeneren dat die verschillende codecs goed zijn voor de innovatie, want concurrentie zorgt voor vooruitgang. Maar dat is hier niet de situatie want die codecs concurreren niet op techniek maar op licenties en rechtszaken. Dat is mooi voor de juristen, maar technisch gezien schieten we er niks mee op.
Er was nog even hoop dat open source codecs dat zouden verbeteren, maar er zijn zo ontzettend veel patenten dat het onmogelijk is om een codec te maken die boven alle verdenking verheven is. Let wel: ik zeg niet dat het technisch gezien onmogelijk is, maar dat je toch dure rechtszaken aan je broek gaat krijgen waar je je tegen moet verdedigen, ook al heb je duidelijk gelijk. Met 10.000 patenten kun je altijd wel iets vinden om moeilijk over te doen.
Op grond van dit artikel zou je kunnen zeggen dat er heel veel tijd en moeite verspild wordt omdat de juristen het niet eens kunnen worden, niet omdat er technisch gezien veel concurrentie is. Na jaren van onderhandelen is er nog steeds geen duidelijkheid. Zelfs over H264 is er nog onduidelijkheid en dat bestaat grotendeels uit 20 jaar oude techniek (de standaard is nieuwer, maar de gebruikte techniek is uiteraard ouder dan de standaard die er gebruik van maken).
Wat we natuurlijk niet weten is hoe het was gegaan zonder patenten. Het zou kunnen dat al die bedrijven dan hadden besloten dat ze geen moeite willen steken in het ontwikkelen van nieuwe technieken. Dat geloof ik niet want ze willen toch geld verdienen en zelfs als alles mag worden gekopieerd zal het tijd kosten om nieuwe technieken over te nemen en te integreren in je eigen product. Mobiele telefoons, de belangrijkste markt van dit moment, gaan een jaar of drie mee. Tegen de tijd dat het nieuwste model in de winkel ligt moet de opvolger al in ontwikkeling zijn. Concurrenten kunnen je techniek wel jatten maar kunnen die pas in de volgende cyclus integreren, zeker als ze dan pas beginnen met de techniek te onderzoeken. Om bij te blijven zullen ze zelf hun eigen onderzoek moeten doen.
Maar we kunnen wel naar het groter patroon kijken. Dan zie je dat na een technische doorbraak de techneuten er als eerste opduiken en niemand zich bekommert over patenten. Tal van nieuwe bedrijfjes schieten uit de grond die allemaal proberen iets van de nieuwe techniek te maken en razendsnel problemen oplossen en verbeteringen doorvoeren. Na een tijdje drijft er een winnaar boven en pas dan gaan mensen nadenken over patenten enzo. Dat wekt de indruk dat patenten niet worden gebruikt om innovatie te stimuleren maar vooral om concurrenten dwars te zitten.
De echte grote doorbraken komen trouwens zelden van grote bedrijven maar van universiteiten en startups. Ik wil niet beweren dat die grote bedrijven niks bijdragen want dat doen ze wel, maar het is minder dan die patentpool suggereert. De meeste van die patenten hebben ze namelijk niet zelf ontwikkeld maar ingekocht.
Het hele verhaal van de kleine uitvinder die beschermd moet worden tegen het grote gemene bedrijf is ook niet hoe de praktijk werkt. In praktijk kunnen kleine uitvinders niet betalen voor de dure advocaten die nodig zijn om het op te nemen tegen een reusachtig bedrijf. Je kan wel gelijk hebben, maar als je falliet gaat voor de rechtszaak is afgerond dan heb je nog niks.
Ik maakte al de opmerking, waarvoor ik [s]ben[/s] was gedownvote, dat dit in de eerste plaats een Amerikaans probleem is. Software patenten bestaan niet in de EU, en de enige rede waarom bedrijven zoals een Philips zich er aan houden, is omdat ze anders niet in de VS mogen leveren.
En verder helemaal eens, het octrooi systeem is tot op het bot corrupt en manipulatief. Het is zwaar in het voordeel van grote multinationals met grote juridische afdelingen, en kleine partijen kunnen er amper iets mee. Zie ook Submarine Patents, en Patent Ambushes.
[Reactie gewijzigd door Eonfge op 23 juli 2024 15:33]
Precies, maak je een open source codec, an kikjrg je teveel marktaandeel, dan word je aangeklaagd. Degene met meeste geld wint. Want de kleine partij moet opgeven.
De moderne Intel CPU's (vandaar de naam Intel Quick Sync). En dan -in principe- alleen bij gebruik van de geïntegreerde GPU.
Het is inderdaad wel een stuk sneller dan een software implementatie, maar als je gaat kijken naar kwaliteitsverschillen dan valt praktisch altijd op dat een software encoder betere kwaliteit kan leveren dan deze hardware encoders (uitgezonderd de erg dure commerciële hardware encoders wellicht).
[Reactie gewijzigd door Wildfire op 23 juli 2024 15:33]
Wat een mooi voorbeeld is, want 3 van de codecs besproken (av1, evc, vvc) staan daar unsupported across the board .
Blijf het wel tof vinden dat dingen zoals 10bit/12bit encoding nu ook in de hardware encoders zitten.. (je snelheid op de cpu stort echt in als je dat op een cpu doet ).
Kwaliteit van het fixed function spul blijft om te huilen, en het is meer bedoeld voor transcoding of zaken waar kwaliteit per bitrate niet het ultimatum is.
Hevc (en h264 for that matter) Kan zo veel meer resultaat halen dan wat de nvenc / vce / qsv chipjes doen.
De RaspberryPi heeft sinds het begin een hardware mpeg decoder aan boord. Maar standaard mag (mocht?) die niet gebruikt worden omdat de licentie niet betaald was. Er is (was?) een extra licentie nodig van zo'n €2,50 (https://codecs.raspberrypi.org/mpeg-2-license-key/)
Al valt het mij op dat de huidige raspberry-pi-s daar niet meer zo de nadruk op leggen.
Voor de andere cpu-s zal de licentie voor de mpeg decoder ongetwijfeld in de prijs van de cpu zijn verrekend.
Ik vraag mij af of er ooit een tijd komt waarbij compressie niet meer nodig is. Wanneer netwerken beter worden dan zou het kunnen. Al het coderen en decoderen kost immers ook energie.
Echt uncompressed wordt heel groot. Mijn uncompressed renders zijn rond de 12 mb per frame (16 bit) (op full HD). Dus als we naar 4k uncompressed gaan op 16 bit wordt dat bijna 50 mb per frame. Per seconden is dat dan 1.2 gb. Een film van 2 uur komt dan uit op 8.64 TB. Denk dat dat niet echt goed is voor de energie consumptie eerlijk gezegd, dan kan je beter coderen en decoderen . Het versturen en opslaan van zo veel data kost namelijk ook energie.
[Reactie gewijzigd door nr12 op 23 juli 2024 15:33]
Hangt volledig samen met hoe ver "wij" de resoluties nog omhoog willen gooien, hoeveel kleuren wij willen zien en hoevaak per seconde dit binnen moet komen. Ik gok dat qua resolutie men wel klaar is na 8K. Op een normaal beeldscherm is het verschil al lastig genoeg te zien
Maar vooral het coderen is iets dat je 1x doet en dan naar N devices kan sturen / schijfjes kan drukken. Zelfs met sneller internet moeten er toch een hoop extra bits worden rondgepompt. Als netwerktechnologie zo ver vooruit gaat, zal encoder/decoder technologie ook vooruit gegaan zijn natuurlijk.
Wat misschien wel gebruikelijker gaat worden, en nu alleen de enthusiasts doen, is dat je 1 apparaat hebt die de zwaar gecomprimeerde versie binnenhaalt en dan transcode naar een beter ondersteunde maar minder efficiënte codec. Maar voor dit op goede kwaliteit realtime kan, kan je het al niet voor streams gebruiken.
Hmm, het is lastig om de toekomst te voorspellen, maar laten we stellen dat we over 10 jaar 4k 120 fps 12bit als uitgangspunt nemen voor "normaal". 4096x2160 geeft 8,847,360 pixels. Iedere pixel bestaat uit 3 componenten: rood, groen en blauw die ieder 12 bit in beslag nemen. Dat zijn 36 bits per pixel en 36 * 8,847,360 = 318,504,960 bits per beeld. Ofwel 38,220,595,200 bits per seconde of wel 38 gbps. Het zou wel interessant zijn om na te rekenen hoeveel energie het zou kosten om dat naar x miljoen netflix abbonnees te versturen vs 1x encoden en dan de kleine versie naar die abbonnees te versturen.
Ik denk van niet. Simpelweg omdat alles gedreven wordt door geld. Eén keer je film converteren naar een lagere bitrate die voor 99% van de eingebruikers acceptabel is spaart simpelweg een hoop kosten aan bandbreedte. Dat is winst voor de aanbiedende partij die ze nooit zullen laten liggen.
En die 1% voor wie de kwaliteit niet voldoende is kan nog naar vaste schijfjes. Maar zelfs daarop zit compressie. Of men dat laatste echter überhaupt waar kan nemen in vergelijk met het bronmateriaal, ik durf het te betwijfelen.
Een interessant vergelijk is hoe het op het moment in videogameland gaande is: Jarenlang was er een drang naar hogere resoluties, met als klapper de huidige generatie waarin het een geval van pure prestige was om je game in native 4K te draaien. Sony heeft hier van het begin af aan niet aan mee gedaan en checkerboarding geïntroduceerd om de kwaliteit van 4K te benaderen met een flinke besparing op de benodigde systeemprestaties. De hardcore PC wereld verguisde het, want het was niet native en deed af aan kwaliteit, terwijl het voor velen toch echt een goede oplossing was.
Inmiddels zie je dat hard- en softwarefabrikanten op consoles én PC inzetten op niet-native 4K oplossingen om de overgebleven resources op een zinvollere manier in te zetten. Soms is een benadering dus meer dan goed genoeg en is er geen reden voor consumenten om uit puristisch perspectief aan ongecomprimeerd vast te houden.
Nou, ik weet dat bij streaming van browser naar browser (videochat) op een smartphone of tablet gaat het meeste energie gebruik niet naar encoding/decoding (als er hardware ondersteuning is voor als H.264), maar het scherm en het gebruik van draadloos netwerk (een statistiek die komt uit WebRTC verhaal en die doen dus ook nog encryptie).
Dus dat geeft al aan dat hardware encoding/decoding efficienter is dan draadloos netwerk
[Reactie gewijzigd door Lennie op 23 juli 2024 15:33]
Maak je geen zorgen, compressie en ook encodering blijft nodig en wordt steeds nodiger. Op de hdmi kabel wordt het video signaal al gecomprimeerd. Reken even mee:
1, full-hd beeld is 1920 x 1080 pixels. Laten we voor 1 pixel voor het gemak 4 bytes nemen. Dan is 1 beeld al 8 MByte groot. Dat is 64 MBits. Dan wil je 60 beelden per seconde zien dus moet er 4 GigaBit over de lijn van de blue-ray speler naar de tv. En dan wil je 4k beeld: 4 keer zo veel pixels per plaatje: 16 Mbit/sec. En in HDR kwaliteit: 20 a 30 MBit/sec.
Natuurlijk, zo hier en daar valt wel wat te verbeteren. Bijvoorbeeld de plaatjes in jpeg over sturen.... Tel al die verbeteringen bij elkaar op en je hoeft alleen de bordjes nog maar in te vullen.
Volgens mij raakt dit de consument niet, net zoals die geen weet heeft van de codecs die door de verschillende streaming platforms en fysieke dragers gebruikt worden en gebruikt zijn in het verleden. Veel thuisgebruikers zullen niet eens weten dat DVD-video gebruikmaakt van MPEG-2, zelfs niet als ze tooltjes hebben gebruikt ooit om zelf DVD's te maken of te kopieren.
In het downloadcircuit ligt dat net iets anders. Je ziet bijv dat sinds de Pi 4 hardwarematige ondersteuning heeft voor HEVC/H.265 dat torrents met video in dit formaat populairder zijn geworden. Dus uitgerekend in het illegale circuit waar uiteraard ook geen royalties worden betaald is het bewustzijn rondom codec support hoger.
VVC klinkt trouwens wel tof. Dus wederom wordt een videobestand straks ongeveer half zo groot t.o.v. de voorgaande codec met behoud van kwaliteit. Ik vraag me af waar dit stopt. Hoeveel informatie kunnen we dus nog weggooien uit een datastream zonder dat ons brein dat in de gaten heeft?
Dus uitgerekend in het illegale circuit waar uiteraard ook geen royalties worden betaald is het bewustzijn rondom codec support hoger.
Ik wil je er graag op wijzen dat software patenten zoals die in video-codecs, alleen bestaan in de VS. Het is hier in Europa volstrekt legaal om encoders en decoders te verspreiden welke HVEC en VVC kunnen afspelen, zonder licenties te betalen. Tekstboek voorbeeld, VLC:
VideoLAN is an organization based in France.
Therefore, most of the following page is redacted in French and refers to French law, which is the only one to be applicable to VideoLAN.
[...]
Neither French law nor European conventions recognize software as patentable (see French section below).
Therefore, software patents licenses do not apply on VideoLAN software.
Ik ben zelf betrokken bij de distributie van multi-media codecs in de Linux wereld, en zolang ik dat doe voor niet-Amerikaanse organisaties zit dat juridisch helemaal snor.
Edit 1. -1? Duidelijk veel medewerkers van Amerikaanse patentbureaus hier.
Edit 2. Rectificatie, dus toch meer VLC gebruikers dan patentbureau klerken
[Reactie gewijzigd door Eonfge op 23 juli 2024 15:33]
Ja de iphone. Daar noem je wat. Klopt inderdaad wel. Ik gebruik overwegend Signal als messenger en die stuurt alle media origineel door. Dat is prettig want dan krijgt de ontvanger de beste kwaliteit door. Maar met video is dat inderdaad een probleem. Overigens kan ik op mijn Android video's gemaakt op iphones gewoon afspelen. Het probleem speelt bij mij juist andersom. De iphone heeft een beperktere ondersteuning voor codecs. Mogelijk biedt VLC een oplossing.
Als je die geinstalleerd hebt werkt hevc ook in edge. Tenminste met emby. We gebruikte altijd de emby webapp om het transcoderen van de custom nas te testen door een hevc af te spelen. Tot we er bij toeval achter kwamen toen we dit een keer met edge probeerde dat deze hevc niet hoefde te transcoderen
Ik ken het inderdaad alleen maar omdat ik vroeger veel heb gedownload.
Dan moet je je downloads afstemmen op welke apparatuur je gebruikt.
Het is me overigens wel tegengevallen hoe de ondersteuning van smart TVs was voor H265. Bovendien had je een beste CPU of videokaart nodig om dit op een relatief oude pc te kunnen afspelen.
Tegenwoordig gebruik ik alleen nog maar streaming en on demand diensten en interesseert het me eigenlijk niet wat YouTube of Netflix gebruikt. Ik ga er vanuit dat zij een goede keuze voor maken voor zo hoog mogelijke kwaliteit vs zo min mogelijk bandbreedte.
Desalniettemin interessant artikel.
Ik vraag me af waar dit stopt. Hoeveel informatie kunnen we dus nog weggooien uit een datastream zonder dat ons brein dat in de gaten heeft?
Het stopt iedere keer bij wat de huidige hardware real-time kan decoderen voor een schappelijke prijs.
Het moet wel "overal" op afgespeeld kunnen worden voordat je een grote adoptie gaat zien.
Daardoor is het ook een kip-ei verhaal.
Ik bedoel dit meer in wetenschappelijke zin. Waar ligt de grens? Hoeveel bits kunnen we in theorie nog weggooien voordat ons brein het in de gaten heeft? H.265 bereikt grofweg dezelfde kwaliteit als H.264 met de helft van het aantal bits. H.266 doet dat trucje nog een keer dus die halveert het aantal benodigde bits t.o.v. H.265. Dat moet ergens een keer stoppen, los van technologische limieten. Een knappe kop kan dat vast wel een keer berekenen.
H.265 is een specificatie, X.265 is een encoder. Ik las ooit ergens eens dat je het ene als het recept kunt zien en het andere als de resulterende cake.
Steeds meer codecs en ondertussen kan mijn 8 jaar oude 46" Samsung oled het niet meer aan. 3500 euro en de laatste firmware update kwam in 2016. Waarom is dat een probleem? Omdat ik vanachter mij VPN download, alles op een 128gb stick zet en zo met m'n tv alles afspeel. Alleen wordt alles steeds minder...
Tja, VP9 is zeven jaar geleden uitgekomen dus hardwareondersteuning voor het afspelen van YouTube kun je wel vergeten. TV-fabrikanten hebben (of, in ieder geval, hadden) de neiging zwaar ondermaatse processors in hun TV's te stoppen, dus software-encoding zal zo'n ding nooit doen; vaak zitten er namelijk mobiele chips in die dingen en dat is goed voor de codecondersteuning maar biedt weinig rekenkracht, helemaal na acht jaar.
Als je de films toch zelf downloadt, kun je ze met bijvoorbeeld Handbrake (of een Plex servetje) zelf omzetten naar een codec die de TV ondersteunt. Daar worden je films veel groter van en het kan zijn dat de USB-poort van de TV de sustained bitrate niet aan kan (zelf meegemaakt bij een nog oudere TV), maar de hardwaredecoder van je TV kan dan wel ineens weer zijn ding doen.
Dit is overigens ook precies waarom ik mijn mediasysteem extern van mijn TV heb. Dat smart-spul wordt op den duur alleen maar ouderwets. Een Android-ID of Kodi-box waar je de USB-stick ik kan steken is geen overbodige luxe. Het spul kost je nog eens een euro of zeventig, maar dan ben je de komende jaren wel weer bij qua mediafunctionaliteit en hoef je niet opnieuw zo'n enorm bedrag voor een TV af te tikken.
Jammer genoeg doen desktop-CPU's en -GPU's maar weinig meer dan h264, VP9 en misschien nog h265. Mobiele chips van fabrikanten als Qualcom en MediaTek ondersteunen veel meer in hardware en daardoor kunnen telefoons nog zo goed video afspelen waar het op andere apparaten steeds langzamer wordt.
Die wereld gaat nou eenmaal hard.. Als je kijkt naar de mobiele wereld dan is 8 jaar een eeuwigheid.
Om een voorbeeld te geven, ik zat nog niet zo lang geleden op een Core i7 uit de 2000 serie, met een gtx 760. Kon nog redelijk meekomen als je geen te hoge eisen had.
Maar 4k YouTube of andere dingen? 4k h265 of vp9 decoden op de cpu dat trok ie echt niet, en de gpu had nog net geen ondersteuning voor die codecs.
Maar m'n telefoon deed het zonder problemen .
Zo'n tv of mobiel kan het nu eenmaal omdat er specialized hardware in zit voor de codecs.. Die snapt een nieuwe codec niet, en je kan niet je chipje vervangen door een firmware upgrade..
Maar wat andere meldden.. Als je veel geld uitgeeft voor een tv dan doe je dat voor het scherm... Ondersteuning kan je nog oprekken door een externe speler te gebruiken (ie Nvidia shield). Stukken goedkoper dan de tv vervangen lijkt mij.
Ik ben erg tevreden met wat mijn Samsung 2017 weet af te spelen, maar ik snap ook dat dat ooit wel gaat veranderen. Maar moet ook zeggen dat ik meer streaming diensten gebruik en de laatste keer dat ik een bestand heb willen afspelen op mijn tv al niet meer kan herinneren... But that's me.
Een Raspberry Pi 4 is niet zo duur. Kan je voorlopig alles mee afspelen en die TV kan mooi offline. En die Pi plak je aan de achterkant van de tv. Dan zie je er niks van.
Tja leuk die ruimte besparing maar mijn tv snapt niet eens x265 dus dat en alles wat nieuwer is boeit me niet. Ik koop liever 6tb extra voor 120 euro dan dat ik een nieuwe tv moet kopen voor 1000. mijn laptop vind overigens x265 helemaal niet leuk.
Wat mij betreft blijft x264 de standaard. Online is de stap terug van x265 naar x264 vaak al gemaakt omdat er gewoon te slechte ondersteuning is door apparatuur zelfs na zoveel jaar nog.
Yups uitzenden in iets wat op veel apparaten niet ondersteund is heb je niks aan. Maar een app zou wel kunnen detecteren kan ik codec x gebruiken, dan doe ik dat. Kan ik dat niet heb ik een fallback, op die manier kan op zijn minst al een stap gemaakt worden. Uiteraard is er een punt waarop je support voor het oude laat vallen. Maar dit is pas als slechts nog een klein percentage het niet aankan. Als video aanbieder kan je je het niet permitteren om even 50% van je klanten te verliezen
[Reactie gewijzigd door cricque op 23 juli 2024 15:33]
Ja en wat mij betreft doen ze eerst wat aan die belachelijke 640 bitrate voor audio. Het is met een beetje geluid setup gewoon belabberd.
Ik gebruik altijd een bepaald stukje van een film om te testen of alles goed ingesteld staat. Nu heb ik de blue-ray rip op usb met 9k bitrate voor audio maar zag sat deze ook op netflix stond. En ben werkelijk een dag bezig geweest voordat ik doorhad dat het geluid niet klopte in de netflix stream door de belabberde bitrate. Surround effecten mossen de bass is flat en de hele audio klinkt wat dof. De gehele emersie van de audio is compleet om zeep geholpen door bezuinigen op de bitrate.
Vreemde is dat in theorie arc of spdif niet eens in staat is om de 9k bitrate van de DTS HD MA te transporteren naar de receiver maar toch is het een wereld van verschil.
Maarja als bitrate geld kost denk ik dat downloaden de norm blijft en netflix niet meer is dan een online bibliotheek waarin in bij hou wat ik wil zien en af en toe een serietje kijk waarvoor ik de receiver niet gebruik.
Er ligt zoveel nadruk op beeld dat geluid een totaal ondergeschoven kindje is. Voor video staan complete megabits aan bandbreedte beschikbaar en kan je ook naar gelang je wens de kwaliteit op- of afschalen, maar audio is op vele platforms, zelfs die actief met audio adverteren (Amazon Music, Youtube) eigenlijk niet om aan te horen. Die laatste twee haal ik expliciet aan vanwege mijn negatieve ervaring met Amazon Music. Audio klinkt daar noemenswaardig vlak. Goed genoeg voor tijdens het stofzuigen of in de auto wellicht, maar mijn zelfgeripte MP3's klinken stukken beter. Op Youtube klinkt de meeste content ook bagger, maar dat kan ook aan de uploader liggen.
Wat Netflix betreft heb ik nooit echt een goed vergelijk kunnen maken. Het schijnt wel dat ze daar in 2019 tenminste de bitrate naar 640kbps hebben gegooid. Jammer dat men hier geen hogere kwaliteit biedt bijvoorbeeld middels een opt-in voor mensen die er werkelijk baat bij hebben.
Ja ik zie op een 65 inch tv liever 1080p met hoge kwaliteit audio dan 4k met de huidige bagger audio.
En ik ben echt ver van een audiofiel maar sinds ik mijn huidige setup heb (te zien in profiel en midrange op zijn best) merk ik gewoon dat goede audio een wereld van verschil maakt.
Ik heb er werkelijk 2 jaar over gedaan om er achter te komen waarom soms mijn audio ronduit bagger was en soms gewoon goed. Ik had hier last van bij films muziek en radio maar na een tijd ging ik een patroon zien in welke bronnen het probleem hadden zo waren er bepaalde radio stations gewoon bagger (gestreamed van telefoon) en anderen hadden veel meer body en alle tonen waren helderder (gestreamed via tv box met hogere bitrate).
Wat betreft mijn voorbeeld met netflix. Ik ben benieuwd of er verschil in details en helderheid enz is als ik via de tv speaker afspeel. dit heb ik nog niet eens overwogen te testen. Ik weet dus niet eens of mensen met gewoon tv speakers hier ook baat bij hebben. Als die er ook baat bij hebben dan hebben alle andere setups zoals bijvoorbeeld een soundbar dat ook.
En ik weet niet hoeveel dit netflix kost maar een euro meer betalen voor de optie high quality audio (minimaal 1536 als bitrate) zou ik prima vinden. Maar ze zullen op die extra kwaliteit ook wel winst willen maken want niets kan extra tegen kostprijs in deze wereld om je klanten blij te maken.
tot die tijd zal ik gewoon blijven downloaden tenzij het me even niet boeit dat zet ik gewoon netflix aan. Zo kijk ik snacht's vaak een serie en dan kan ik moeilijk mijn surround set aanzetten. Dan trillen de buren uit hun bed en op laag volume is het effect er gewoon niet en heeft het dus ook geen zin.
[Reactie gewijzigd door computerjunky op 23 juli 2024 15:33]
Kijk maar naar Digitenne. Die zijn sinds een jaar overgestapt op een nieuw systeem met een andere codec (en mogelijk andere frequenties) en alle hardware is dan ineens uitgeschakelt.
Hevc 8\10 bit wordt op heel veel apparaten ondersteund tegenwoordig.
Verschillende kastjes voor onder de tv, mijn satellietontvanger doet het ook.
H264 bit wordt wel meer ondersteund, dat wel maar als ze 10 bit zijn, dan spelen ze weer niet af...
Online is de stap al vaak terug gemaakt omdat sommige zien hevc als de wonder codec, gaan ze 1080p materiaal met bitrate van minder dan 2000 gebruiken of een encoded source nog eens tevoren.
Probleem vooral online is dat x265 encoding redelijk wat power vreet(en nee gpu komt uit inner buurt van kwaliteit (op lagere bitrate) en gaat trager....
Nieuwe standaarden zijn vooral interresant voor: 4k of lage bandbreedte landen of bedrijven die liever geen royalties willen betalen voor H.264. Ik heb redelijk nieuwe TV en 4k daarop is echt wel mooier dan 1024p (Full HD aka 1k)
[Reactie gewijzigd door Lennie op 23 juli 2024 15:33]
Grappige is alleen dat die lage bitrate landen helemaal geen x265 of later ondersteunende hardware hebben. Je heb er immers redelijk nieuwe hardware voor nodig.
De nieuwe standaarden helpen wel bij reductie van bandbreedte behoefte (bij gebruik van zelfde resolutie), en dat is geen probleem want decoding is veel minder calculatie intensief dan encoding.
In kort gezegd: als de bottleneck niet de CPU is maar de bandbreedte dan is betere encoding van de zelfde resolutie beter want dan kun je bijvoorbeeld in eens wel 1024p (Full HD) Youtube kijken. Terwijl men eerder 1024p niet kon kijken omdat er niet genoeg bandbreedte was.
[Reactie gewijzigd door Lennie op 23 juli 2024 15:33]
De insteek van die paragraaf is slechts om duidelijk te maken dat het belang van compressie heel groot is. Niet om een vergelijking te maken tussen de prestaties van verschillende codecs.
Dat hangt af van de kwaliteitsinstellingen. Netflix past de stream ook voortdurend aan mocht je internetverbinding sneller/trager worden tijdens het lijken.
Vroeger heb ik nog wel eens geëxperimenteerd met de verschillende kwaliteitsinstellingen in Handbrake om het verschil te kunnen zien. Maar nu opslagruimte goedkoper is (en het dus niet meer op een cd'tje hoeft te passen) kijk ik niet meer naar het aantal MB's die nodig zijn om een filmpje op te slaan. En als ik een filmpje deel dan gebruik ik vaak toch Google Photos/Youtube om het filmpje te delen, dan weet ik zeker dat iedereen het kan bekijken.
[Reactie gewijzigd door Aegir81 op 23 juli 2024 15:33]
Binnen een half jaar werd er echter volop geklaagd. In een artikel uit september 2015 uitte Joe Inzerillo zijn ongenoegen, zoals al valt op te maken uit de titel: 4K gets thumbs down from Discovery, BBC and others at IBC. De toenmalige cto van Major League Baseball Advanced Media was niet te spreken over de licentiesituatie. Daarbij werd zelfs voorgesteld om gebruikers van de h265-standaard een percentage van hun omzet te laten betalen, dus royalty's voor content die met h265 is gecodeerd. Inzerillo gaf aan dat geen enkel mainstreambedrijf daarvoor ging tekenen en hij was stellig in zijn oordeel dat 'het h265-patentgebeuren de 4k- en 8k-verkopen de wind uit de zeilen nam'.
:strip_exif()/i/2003740754.jpeg?f=imagegallery)
:strip_exif()/i/2003741568.jpeg?f=imagegallery)
:strip_exif()/i/2003740750.jpeg?f=imagegallery)
/i/2003742714.png?f=imagegallery)
:strip_exif()/i/2003741860.jpeg?f=imagegallery)
:strip_exif()/i/2002922808.jpeg?f=imagegallery)
/i/2005626858.png?f=fpa)
/i/2005017354.png?f=fpa)
/i/2004791476.png?f=fpa)
/i/2004620250.png?f=fpa)
/i/1316076409.png?f=fpa)
:strip_exif()/i/1273482314.jpeg?f=fpa)
/i/2001904313.png?f=fpa)
/i/1317305413.png?f=fpa)
/i/1333367498.png?f=fpa)
/i/2003706442.png?f=fpa)
:strip_exif()/i/2003046176.jpeg?f=fpa)
/i/2002201373.png?f=fpa)
/i/2000609487.png?f=fpa)
:strip_exif()/i/1404378176.jpeg?f=fpa)
/i/1388770794.png?f=fpa)
/u/479384/crop58e4c54c15b23_cropped.png?f=community){kind=small}
/u/3106/crop601874b34ff83_cropped.png?f=community){kind=small}
:strip_icc():strip_exif()/u/585119/crop606d74514b715_cropped.jpg?f=community){kind=small}
:strip_icc():strip_exif()/u/102432/bash.jpg?f=community){kind=small}
/u/1982/crop5a048313062a4_cropped.png?f=community){kind=small}
:strip_exif()/u/32998/tweakpiggy_anim.gif?f=community){kind=small}
:strip_icc():strip_exif()/u/219059/crop5efafd1bd64af_cropped.jpeg?f=community){kind=small}
/u/51802/new-user-icon.png?f=community){kind=icon}
:strip_exif()/u/68185/crop5aacf7c17c46e_cropped.gif?f=community){kind=small}
/u/35505/flx_70x70.png?f=community){kind=small}
/u/62384/crop61891f444d6e9.png?f=community){kind=small}
:strip_icc():strip_exif()/u/331924/icon.jpg?f=community){kind=icon}
/u/59561/crop581d08355d484_cropped.png?f=community){kind=small}
:strip_icc():strip_exif()/u/385137/crop564b75609bf0c_cropped.jpeg?f=community){kind=small}
:strip_icc():strip_exif()/u/230241/crop5db74093e7dc1_cropped.jpeg?f=community){kind=small}
:strip_icc():strip_exif()/u/346435/crop58d9871d74295_cropped.jpeg?f=community){kind=small}
:strip_exif()/u/10069/neutron1.gif?f=community){kind=small}
:strip_exif()/u/218071/crop56c86faf16f74_cropped.gif?f=community){kind=small}
/u/226258/tweakersavatar.png?f=community){kind=avatar}
:strip_icc():strip_exif()/u/289675/crop6401bf2c85501_cropped.jpg?f=community){kind=small}
:strip_icc():strip_exif()/u/79614/Family-Guy-Victory-is-Ours.jpg?f=community){kind=small}
.:strip_icc():strip_exif()/u/57655/SuperTeamLogo.jpg?f=community){kind=small}
/u/286795/crop5b1a42cd59dfd_cropped.png?f=community){kind=small}
/u/113709/galactic_empire_60pix.png?f=community){kind=small}
:strip_icc():strip_exif()/u/137008/fable.jpg?f=community){kind=small}
:strip_icc():strip_exif()/u/354678/2250559_9176873_lz%252060x60.jpg?f=community){kind=small}
/u/321057/crop67ea60f405df9_cropped.png?f=community){kind=small}
.:strip_icc():strip_exif()/u/109168/crop5c6ad3dc9bc0f_cropped.jpeg?f=community){kind=small}
:strip_icc():strip_exif()/u/187763/crop60f56b0420357.jpg?f=community){kind=small}
/u/13460/JUN982.GIF?f=community){kind=small}
/u/292867/crop5630e1f334453_cropped.png?f=community){kind=small}
/u/267471/crop5c90d1e00cf68_cropped.png?f=community){kind=small}
:strip_icc():strip_exif()/u/111040/4900_Colours_60.jpg?f=community){kind=small}
:strip_icc():strip_exif()/u/81611/headcrop.jpg?f=community){kind=small}
:strip_icc():strip_exif()/u/222579/crop58e660ba93218_cropped.jpeg?f=community){kind=small}