Chaos en orde rond videocodecs

De strijd tussen h265, av1, vp9 en h266

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.

Reacties (156)

[Xieoxer]

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]

[GillisB]

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.

[Postman]

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?

[GillisB]

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.

[jabwd]

h264 heeft een resolutie limiet, echte 4k is in principe niet te halen.

[hkok4]

Kijk, weer wat geleerd.

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?

[Mathijs]

Dat is niet meer zo, aangezien het max level is verhoogd.
In Premiere is de hoogste setting "unrestricted" en daaronder komt "6.2".

Dat is voldoende voor 8K@120fps.

In principe kun je het volgende aanhouden:

High profile

1080P25/30 = 4.1
1080P50/60 = 4.2
4K25/30 = 5.1
4K50/60 = 5.2
8K25/30 = 6.0
8K50/60 = 6.1
8K100/120 = 6.2

Voor meer exotische framerates kun je hier kijken naar de complete tabel:
https://en.wikipedia.org/wiki/Advanced_Video_Coding#Levels

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]

[bbob]

Gebruik je als ondersteunen van het coderen geen videokaart die h.265 ondersteund ?

[GillisB]

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)

[bbob]

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.

[GillisB]

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)

[bbob]

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.

[Madshark]

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.

[GillisB]

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.

[dipje2]

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.

[bbob]

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.

[dipje2]

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

[MadMarky]

Waarom kies je ervoor om dit met CPU te doen en niet met GPU? Dat is immers vele malen sneller?

Edit:
Te snel gelezen, videokaarten ondersteunen de encoden kennelijk niet goed genoeg

[Reactie gewijzigd door MadMarky op 23 juli 2024 15:33]

[sjoerdmekenkam]

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

[kiang]

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]

[sjoerdmekenkam]

helder!

[NaliXL]

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

[dec0de]

Ik denk eerder dat ze de hele video opsplitsen in frame bundels, en dat elke core bijv 60 frames doet van een 16 minuten filmpje.

Encoderen en decoderen gaat al heel erg multithreaded

[harrytasker]

Dat noemen ze volgens mij checkerboarding en gebeurd heel veel in spelletjes om de GPU te ontlasten.

[Tweakert99]

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]

[Jhojo]

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.

[airell]

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]

[dasiro]

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.

[Xieoxer]

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.

[Some12]

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.

[Temenes]

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.

[GerritGekke]

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.

[erwinb]

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.

[d1zzje]

Bedankt voor de nuttige informatie, nooit geweten dit.

[Terrestrial]

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

[fapkonijntje]

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]

[slijkie]

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?

[Anoniem: 1330988]

Encoderen is volgens mij bij uitstek geschikt voor multi-threading. Is een many core AMD server chip (Threadripper) er niet toe in staat?

[Xieoxer]

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.

[theguyofdoom]

Je hebt meer aan SIMD (met name AVX2) en daar is AMD minder goed in dan Intel.

[Reactie gewijzigd door theguyofdoom op 23 juli 2024 15:33]

[Tim2010]

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?

[dec0de]

Dat is dus niet zo
Zie de reactie van ferdinant hierboven

[ferdinand]

Je hebt meer aan SIMD (met name AVX2) en daar is AMD minder goed in dan Intel.

AMD is vanaf zen2 beter in AVX2 dan Intel. Jouw informatie was tot 2016 relevant.

[Morzzz]

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]

[beerse]

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.

[Wildfire]

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]

[johnkeates]

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]

[tss68nl]

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.

[Werelds]

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.

[HollowGamer]

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.

[Werelds]

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

[CAPSLOCK2000]

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.

[Eonfge]

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]

[Pinkys Brain]

Volgens de EPO slaat dat alleen maar op software die geen technische effecten heeft.

Advocaten, bodem van de zee, etc ...

[sympa]

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.

[RiDo78]

De moderne CPU's hebben ook hardware encoding/decoding mogelijkheden aan boord. Voor een overzichtelijke tabel check Wikipedia:

https://en.wikipedia.org/wiki/Intel_Quick_Sync_Video

[Wildfire]

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]

[dipje2]

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.

[SuperDre]

Ja, en die mogelijkheden zijn dus vooral gebaseerd op de gebruikte codecs.

[beerse]

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.

[Janjaapszoon]

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.

[nr12]

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]

[kevints]

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

[Anoniem: 979365]

dit doet mij denken aan een reclame.....gigabit internet? E-mail?

Nu denken we nog dat het allemaal niet nodig is, tot we het in huis hebben staan allemaal.

[Robbaman]

Op een normaal beeldscherm, daar heb je het al. Zometeen komt de VR revolutie of de 360-graden revolutie of watdannook, en is 8k weer veel te weinig.

Bij meer mogelijkheden stijgen ook de wensen mee.

[svenk91]

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.

[Juzzby]

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.

[Cid Highwind]

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.

[Lennie]

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]

[beerse]

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.

[Anoniem: 1330988]

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?

[Eonfge]

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.

https://www.videolan.org/legal.html

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]

[x280]

Helemaal wel, de filmpjes die worden opgenomen met mijn iPhone worden ook niet overal afgespeeld zodra ik ze verstuur zonder te converteren ...

[Anoniem: 1330988]

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.

[x280]

Op een windows 10pc speelt het ook niet altijd af.

(Voor mij zijn er genoeg oplossingen maar de leek huilt elke keer van help hij doet het niet)

[Anoniem: 1330988]

Er is naar de leek toe altijd nog de youtube/vimeo route. Succes gegarandeerd.

[Fireshade]

Op een windows 10pc speelt het ook niet altijd af.

Zijn dat h265 videos?
Windows 10 ondersteunt dat niet standaard meer helaas.
Die codec kan je los erbij kopen voor Windows 10 in de Store.

[Reactie gewijzigd door Fireshade op 23 juli 2024 15:33]

[x280]

Apple communiceerd ook niet meer dan “hoge video kwaliteit”.

[yrosma]

Er is een link naar de store waarmee je de hevc codec gewoon kunt installeren zonder de 1 euro te betalen

https://www.microsoft.com...vetab=pivot%3Aoverviewtab

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

[yorroy]

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.

[Mathijs]

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.

[Anoniem: 1330988]

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.

[Rennie]

En hoe staat x264 en x265 hier in het verhaal in? Wat is het verschil tussen x264 en h264 en x265 en h265. Dat heb ik nooit begrepen.

[The Inquisitor]

H.264 is de codec en X.264 is de encoder, hetzelfde geldt voor h265/x265. X264 is gewoon een open souce programma om video te converteren naar H.264.

[Wildfire]

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.

[Werelds]

H.264/H.265 zijn de recepten, x264/x265 zijn de bakkers die het recept volgen. De video die er uit komt is de cake

[Wildfire]

Da's een iets betere vergelijking ja

[blackSP]

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

[GertMenkel]

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.

[copyer]

Dus de oplossing is een media speler bv. Odroid n2 in samenwerking met Coreelec..

[dipje2]

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.

[Anoniem: 1330988]

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.

[computerjunky]

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.

[cricque]

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]

[computerjunky]

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.

[Cid Highwind]

Dit!

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.

[computerjunky]

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]

[memphis]

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.

[SadisticPanda]

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

[Lennie]

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]

[computerjunky]

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.

[Lennie]

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]

[Harm_H]

De laatste, 53 minuten durende episode van het tweede seizoen van de serie Jessica Jones was maar liefst 293GB groot

Ik mis als lezer hoe groot hij dan is met de codecs. Hoeveel maakt elke codec ervan?

[beantherio]

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.

[Anoniem: 979365]

dat is ook niet de vraag...

zoals ik ook wil weten, wat is het verschil Met en of Zonder codec?

[Superstoned]

Nou ja het hangt af van de kwaliteit. Ik schat zo tussen de 2 en 15 gigabytes. (Ze maken natuurlijk een tiental versies in verschillende kwaliteit)

[Aegir81]

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]