MPEG-5 Lcevc-codec die compressieprestaties andere codecs verbetert is voltooid

De MPEG-5 Lcevc-videocodec is onlangs voltooid. Deze videocodec is geen zelfstandige, nieuwe codec, maar moet vooral beschouwd worden als een add-oncodec. Die gaat uit van een bestaande videocodec en verbetert vervolgens de codeerefficiëntie flink.

V-Nova, het leidende bedrijf achter de codec, meldt dat de Lcevc-codec onlangs tijdens een vergadering van de Moving Picture Experts Group de zogeheten Final Draft International Standard-status heeft bereikt. Het bedrijf omschrijft de Lcevc, ofwel Low Complexity Enhancement Video Coding, als 'de eerste internationaal geaccrediteerde verbeteringsstandaard voor elk bestaand en toekomstig videocompressiesysteem'. Het werkt in combinatie met elke andere videocodec, zoals AVC, HEVC, AC1, EVC of VVC. In feite is de technologie een versie of doorontwikkeling van de Perseus-software van V-Nova.

De werking

Guido Meardi, de ceo en oprichter van V-Nova, legt aan SVG Europe uit dat Lcevc geen nieuwe codec is, maar een 'codecversterker'. "Het heeft een andere codec nodig en kan direct geïmplementeerd worden, omdat er geen nieuwe hardware vereist is. Het kan gebruikt worden als een software-upgrade van een app, een software-upgrade van de transcoder en je kan er ook naar kijken vanaf een website met HTML-5 met weinig resterende accucapaciteit en het werkt gewoon".

Lcevc is in feite een hybride codec. De basis wordt gevormd door een versie van het bronmateriaal te encoderen op een lagere resolutie, waarbij een bestaande codec wordt gebruikt. Dit is de basislaag. Die lagere resolutie garandeert dat er minder energie en bandbreedte nodig is. Er zijn minder pixels, dus is minder rekenkracht vereist. Vervolgens komt de verbeteringslaag, waar het draait om het toevoegen van additionele details en resolutie; deze data wordt gecomprimeerd via Lcevc, waarbij ook het opschalen van het beeld plaatsvindt. Het verschil tussen deze lagere resolutie en de verbeteringsversie, wordt geëncodeerd. Door de basislaag is Lcevc backward compatible en kan een Lcevc-stream gewoon worden afgespeeld, ook al herkent de speler de Lcevc-data niet.

Toepassingen

Lcevc richt zich vooral op die plekken waar er beperkingen aanwezig zijn in de rekenkracht van apparaten en netwerkleveringscapaciteiten. Een belangrijk probleem bij de toepassing van de nieuwere codecs zoals H265, AV1 en H266 in bijvoorbeeld de televisiewereld en door video-on-demandplatforms, is dat er heel veel processorkracht nodig is om in real time te encoderen.

Daar gaat Lcevc niet direct een oplossing voor bieden, maar het is wel een codec die onder meer een verschil kan maken voor broadcasters. De scenario's waar de add-oncodec vooral een toegevoegde waarde kunnen hebben zijn met name OTT-streams, waaronder sport- en e-sportsuitzendingen, vr-toepassingen, sociale media, videocommunicatie en gezondheidstoepassingen, zoals chirurgie van afstand. Bij dat laatste moet de nieuwe codec bijvoorbeeld videobeelden met een hogere resolutie mogelijk maken bij dezelfde bandbreedte.

Luis Vicente, de ceo van Eleven Sports, een bedrijf dat allerlei sport-tv-kanalen bezit, zegt zich erg te verheugen op de 'baanbrekende' kansen die MPEG-5 Lcevc biedt. "Het zal de wereld van sport-, media- en entertainment-videolevering veranderen, door een betere dienstverlening mogelijk te maken tegen substantieel lagere kosten. Ik ben er ook van overtuigd dat het een belangrijke rol zal spelen in onze weg naar nul latency."

Prestaties

Volgens V-Nova maakt MPEG-5 Lcevc het mogelijk om een betere beeldkwaliteit te bereiken tegen een 40 procent lagere bitrate, zowel voor live-content als video-on-demand-leveringen. Daarnaast zegt het bedrijf dat er een verbetering van de encodeerefficiëntie wordt bereikt met een factor van twee tot vier keer.

Een vergelijking uit het onderzoek van Jan Ozer, waarbij het verschil in kwaliteit zichtbaar is als Lcevc niet en wel wordt toegepast bij het bronmateriaal, in dit geval GTA V

Die stelling van V-Nova wordt bevestigd door codec-expert Jan Ozer, die de capaciteiten van MPEG-5 Lcevc heeft onderzocht. Hij bekeek 33 1080p-testclips van meerdere genres, waaronder games, films, sportbeelden en animaties, waarbij wisselende bitrates zijn gebruikt die met de meest relevante gebruikersscenario's corresponderen. Zijn conclusie luidt dat de toepassing van Lcevc bij x264, waarschijnlijk de bekendste encoder van de nog altijd dominante H264-codec, het mogelijk maakt om dezelfde visuele kwaliteit als bij alleen x264 te genereren, tegen 60 procent van de benodigde data. Daarnaast bleek de toepassing van Lcevc in combinatie met x264 bij hogere bitrates meer details en minder compressie-artefacten op te leveren.

Slagingskansen

Lcevc heeft nogal wat eigenschappen die de codec tot een succesverhaal moeten kunnen maken. Los van de verbetering van de efficiëntie, kan het volgens CSI Magazine snel geïmplementeerd worden. Er is bovendien al een software-implementatie van Lcevc beschikbaar in de sdk, aangevuld met een early access-bètaprogramma. Daarnaast is de code geoptimaliseerd voor Android, iOS, web en HTML 5, zodat het snel kan worden ingezet door partijen, zonder dat er gewacht hoeft te worden op hardware.

Op papier heeft V-Nova ook het voordeel dat het met Lcevc de 'stammenstrijd' tussen verschillende kampen omzeilt om de nieuwe dominante videocodec te worden. AVC, ofwel H264, is nog altijd het meest dominant, maar de directe opvolger HEVC is er al even. Daarnaast is er de opensourcecodec AV1 en twee echte codecs van de volgende generatie, te weten Mpeg-5 essential video coding of EVC en H266 of VVC. Lcevc heeft in zoverre geen last van de strijd tussen deze codecs en de verschillende partijen die erachter zitten, omdat het al deze codecs kan verbeteren en ermee kan samenwerken.

Veel zal echter afhangen van het verdienmodel van Lcevc. De chaos rondom de licentiesituatie bij H265 en de drie verschillende patentpools van deze codec maken duidelijk dat dit soort factoren de adoptie van een videocodec tot op zekere hoogte in de wielen kunnen rijden. Bovendien kunnen er altijd partijen opstaan die de afname van licenties afdwingen als partijen Lcevc willen gebruiken, omdat ze van mening zijn dat de codec gebruikmaakt van een of meer patenten van deze partijen. Waarschijnlijk zal in december duidelijkheid komen over de situatie ten aanzien van de royalties en licenties voor het gebruik van Lcevc.

Reacties (40)

[Werelds]

Omdat de titel van het artikel ietwat onduidelijk is: LCEVC maakt deel uit van de MPEG-5 standaard, maar is zelf geen codec. Om precies te zijn is het "part 2" van de MPEG-5 standaard; EVC is deel 1, VVC (of H.266) is deel 3. Samen vormen al die dingen de MPEG-5 standaard, maar eigenlijk zal alleen VVC daadwerkelijk een codec krijgen, LCEVC kan daar dan eventueel gebruik van maken

[Reactie gewijzigd door Werelds op 23 juli 2024 00:22]

[_Thanatos_]

Dat is nog steeds niet echt duidelijk. Dus EVC en VVC zijn delen 1 en 3. Waar is deel 2? Wat bedoel je met dat VVC een codec "krijgt"? Wie gaat die maken dan? LCEVC kan dan *waar* precies gebruik van maken?

[Werelds]

Deel 2 = part 2 = LCEVC

VVC/H.266 is een specificatie, net zoals AVC/H.264 en HEVC/H.265 dat zijn, het is geen software. De bekendste bijbehorende codec van die laatste twee is respectievelijk x264 en x265. Wie die dingen maakt hangt helemaal af van het doel. Er zijn OSS oplossingen (x26x, FFMPEG, dat soort dingen), maar bedrijven als Google of Netflix hebben intern hun eigen codecs

[Reactie gewijzigd door Werelds op 23 juli 2024 00:22]

[ludonis]

Wat industriekennis misschien om toe te lichten. We werken als bedrijf al lang met V-Nova samen, maar ik vrees dat tweakers in de val trapt van hun lepe marketing trekken.

V-Nova ontwikkelde enkele jaren geleden de Perseus Codec. Deze codec werkt volgens de principes van LCEVC. De grote beperking bij implementatie is echter dat DRM niet kan samenwerken hiermee en dat er een decode volledig in software moet. Als resultaat is de Perseus Codec nooit echt in productie gedeployed, zelfs niet door de investeerders van V-Nova (zoals Sky).
De LCEVC standaard is een manier van V-Nova om nu rond deze beperkingen te komen. Echter om er echt rond te komen, moet er nu nog een decoder gemaakt worden in hardware om dit op te vangen. Zo schreven wij in het verleden een decoder volledig in Javascript, wat zeer mooie demo's oplevert, maar in praktijk weinig inzetbaar is. Gezien V-Nova hier wel degelijk geld mee moet verdienen, verwacht ik dat de nieuwe problemen naar adoptie eerder vanuit commerciële hoek gaan komen. V-Nova is namelijk een bedrijf dat nog steeds enkel verliezen draait (maar ze organiseren wel leuke feestjes).

Fun fact: Op een bepaald ogenblik zat er een bug in onze decoder waardoor de enhancement niet toegepast werd. Voor we dit opmerkten, was er een demo met hun CEO, die over de twee identieke beelden ook de feedback gaf dat de output toch duidelijk beter was... Ik zou de opmerking van Jan Ozer ook met een korrel zout nemen, hij is niet bepaald neutraal...

[donaldk]

Doet Gay Bell nog steeds de PR voor V-Nova? Je hebt het over lepe marketing.

Een van de eerste pers conferenties van V-Nova op IBC, waren er wel wat enkele voorbeelden. Vooral op low datarate mobiele netwerken, maar eerlijk gezegd trials, demo's niks commercial deployment. Later was er wel een deal voor compressie voor aanvoer naar Italie over Eutelsat. Was het nou voor Rai of voor Mediaset, oh nee voor Sky Italia, het is ook al weer half decennium geleden, dus weet het ook niet allemaal direct meer uit mijn hoofd. Eutelsat is ook een aandeelhouder, Sky was nog geen aandeelhouder, dus als die een link moeten op zetten voor 4K aanvoer geen massa distributie dus codec standaard is irrelevant.

https://www.v-nova.com/eu...-matches-rai-uhd-channel/

V-Nova was een beetje uit beeld tot dat vorig jaar MPEG/ITU standaardisatie naar voren kwam.

Binnen DVB is het een oud idee, nooit aangeslagen, in combinatie met Hierarchical modulation.

In ATSC 3.0 wordt met een Hierarchische opzet gewerkt voor HDR.

Is het lower resolution base layer met metadata voor reconstructie? COncept had Philipsook voor zijn HDR systeem. Keuze bij broadcaster tussen SDR +metadata of HDR+metadata.

[Reactie gewijzigd door donaldk op 23 juli 2024 00:22]

[ludonis]

Wel, heel veel van de demo's waar ik weet van heb van V-Nova waren fake: hoge encodes tegenover lage encodes. De reden die ze altijd aanhalen is omdat het makkelijker is. Ik heb wel echte demo's gezien die er vaak iets minder indrukwekkend uitzagen.
Het is naar mijn weten inderdaad ook nooit echt commercieel gedeployed, ook al klinkt hun commerciële aanpak redelijk vriendelijk (je betaalt een percentage van de bandbreedte kosten die je normaal uitspaart door de betere compressie). Nadeel is dat dit natuurlijk veel ingrijpende cijfers nodig heeft: aantal minuten playback, en zelfs specifiek welke frames. Veel voer voor discussie. Tel daar bij op dat het niet werkbaar is voor DRM, en je eindigt bij user generated content. Daar zijn significant minder use cases voor. Intussen staan ook de andere codecs natuurlijk niet stil. Deze voegen ook steeds betere filtering toe, waardoor het nut van de techniek vermindert. (En laat nu net de grootste UGC-boer voortrekker zijn van AV1).
In theorie is de oplossing van V-Nova zeker interessant. In praktijk zie ik een aantal beperkingen.

[Superstoned]

Ik snap niet zo hoe dit hele ding werkt. Waarom zou het nu beter zijn om twee codecs over elkaar te leggen in termen van kwaliteit en performance dan het gewoon in 1x doen? Wat is er zo magisch aan dat het EN sneller is EN betere kwaliteit geeft tegen lagere bitrate, maar dat het niet gewoon in H265 of VC1 gedaan had kunnen worden?

Is het alleen beter omdat het H265 technieken gebruikt boven op een H264 stream ofzo? En is het niet beter qua rekenkracht, bitrate en kwaliteit dan VC1?

Of is het gewoon kompleet gebakken lucht?

[ludonis]

Het is niet compleet gebakken lucht. Er is wel degelijk een verbetering te behalen.

In essentie komt het neer op het volgende: de meeste codecs die vandaag gebruikt worden zijn block based: ze splitsen het beeld op in rechthoeken die steeds kleiner worden. Afhankelijk van hoeveel compressie je doorvoert, hoe minder groot de kleinste rechthoeken zijn. Bij een slechte compressie, of als je het beeld hard opblaast, dan kan je deze duidelijk zien.

De techniek gebruikt bij een overlay is niet block based, maar kan een andere techniek gebruiken, bijvoorbeeld filters met edge detectie, of filtering in bepaalde vector gebaseerde vormen of tekst. Op die manier kan je de rechthoekvorming redelijk eenvoudig tegengaan, wat voor een visueel beter beeld lijkt te zorgen. Waar veel codecs standaard bepaalde filters hebben die blocking tegen moeten gaat, spreken we vaak nog over oude technieken, en zijn deze niet altijd in elke decoder ingebakken.

Bij ons was er altijd discussie wat er nu het beste uit kan zien, en het antwoord is niet simpel. Als je puur naar VMAF en vergelijkbare scores kijkt, dan zie je dat er een heel groot verschil is tussen de soorten content. Een belangrijke factor is ook snelheid van beweging: waar een stilstaand beeld er vaak beter uit ziet, is dat voor een bewegend beeld niet altijd het geval.

[Sando]

Maar dan spreek je toch gewoon van een andere codec?

Stel je bent programmeur en je maakt een programma dat verschillen zoekt in frames, je zorgt voor configureerbare keyframe-inzet, aantal bi-directional frames, aantal prediction frames, omvang van de macroblokken, hoe ver en in welke richting je wilt zoeken naar macroblocks op hoeveel frames afstand, en je noemt dit x264.

Als je nu naast of in plaats van rechthoekige slices van macroblokken ook inter- of intraframe vector patches wilt zoeken, dan moet je toch gewoon je programma aanpassen? Want het zoeken naar die blokken is heel veel werk (zet je zoekkader maar eens op "insane" tijdens het encoden) dus als je vervolgens die data moet weggooien omdat je in een vector-pass een heel ander resultaat krijgt, ja dan is het alsof je Doom 4 speelt terwijl een demo van GTA 5 op de achtergrond draait.

Een encoder doet vrij rechttoe-rechtaan werk. Er is weinig (geen?) ruimte om in te haken.

Het klinkt allemaal in het slechtste geval een beetje als een fantastisch verhaal om een nieuwe cryptocurrency te kunnen verkopen, en in het beste geval als een idee voor de basisprincipes van de volgende codec, met misschien de hoop om dit idee te patenteren om er zo geld aan te verdienen.

Maar aangezien ze van MPEG een status hebben gekregen zal het wel in grote lijnen iets toevoegen en begrijp ik het dus niet helemaal.

[ludonis]

Niet helemaal. Het punt is dat de metadata die je gebruikt voor de volgende filters incrementeel is: indien je de metadata niet hebt of kunt interpreteren, werkt de onderliggende codec gewoon en ziet het er gewoon minder goed uit.

[Sando]

Is de USP dan backwards compatibility? Anders klinkt het een beetje omslachtig, alsof het beter direct in de/een codec kan worden gebouwd.

Alsof je een audiostream encodeert met 576 MP3 sample blocks, met daarbovenop 384 AAC sample blocks in een metadata stream. Je kunt dan net zo goed 960 AAC sample blocks gebruiken en MP3-ondersteuning weglaten.

[ludonis]

De USP is inderdaad compatibiliteit met bestaande hardware. De feed kan bijgevolg efficiënt gedecodeerd worden en devices die de extra metadata niet begrijpen, kunnen nog steeds dezelfde data gebruiken (maar hebben iets lagere kwaliteit). Dit spaart weer een hoop in distributie, zeker als dit via multicast verloopt op een private network (waarom het bvb voor Sky etc interessant is).

[Superstoned]

Ok, dat is dus het verhaal. Het voegt een laagje toe die een bestaande codec stream kwalitief kan verbeteren zonder dat er hardware ondersteuning hoeft te zijn. Het zal dus wel minder effectief zijn dan direct gewoon H265 ofzo gebruiken, maar als er alleen H264 ondersteuning is en je hebt nog wat CPU cycles over kun je alsnog H265 kwaliteit behalen zonder het volledig op de CPU te hoeven doen terwijl als er geen extra CPU rekenkracht is dan is de stream wel een stukkie inefficient maar het werkt tenminste nog.

Tja, in een wereld met veel legacy apparaten is het op zich wel interessant en nuttig, snap ik... Maar lastig te snappen voor een simpele ziel als ikzelf, dank voor de uitleg ;-)

[toxict]

DLSS op codec niveau?
Dat is waar dit naar riekt, nietwaar?

[ArnoutV]

Het lijkt een beetje op het concept van JPEG 2000, alleen dan met 2 lagen.
De oorspronkelijke lage resolutie encoding en dan een extra laag waar de volle (output) resolutie is gecodeerd met als basis de lage resolutie data.

Multiple resolution representation
JPEG 2000 decomposes the image into a multiple resolution representation in the course of its compression process. This pyramid representation can be put to use for other image presentation purposes beyond compression.

Progressive transmission by pixel and resolution accuracy
These features are more commonly known as progressive decoding and signal-to-noise ratio (SNR) scalability. JPEG 2000 provides efficient code-stream organizations which are progressive by pixel accuracy and by image resolution (or by image size). This way, after a smaller part of the whole file has been received, the viewer can see a lower quality version of the final picture. The quality then improves progressively through downloading more data bits from the source.

[Reactie gewijzigd door ArnoutV op 23 juli 2024 00:22]

[Niet Henk]

Niet helemaal: het idee achter JPEG 2000 was dat je meerdere resoluties had, zodat je eerst een lage-resolutie variant kon inladen en weergeven als placeholder, en hierna meerdere hogere resolutie-varianten, zonder dat er veel dubbel opgeslagen hoeft te worden omdat de informatie uit de lagere-resolutie variant deels hergebruikt wordt (of de hogere-resolutie variant zelfs geheel niet gedownload hoeft te worden als de afbeelding al groot genoeg is).

Als ik dit goed lees, gaat het hier enkel om één downscaled variant (de hoge-resolutie variant is er niet meer), plus extra informatie om deze effectief te kunnen upscalen (dus wel iets DLSS-achtigs), plus correcties waar die upscaling fouten maakt zodat je artefacten van je upscaling weg kan werken.

Het voordeel t.o.v. gewoon een lagere resolutie variant upscalen is dus dat je die extra informatie meekrijgt waardoor je erg accuraat kan upscalen.

Het grote verschil met bijvoorbeeld JPEG2000 of andere meerdere-resolutie technieken is dat je dus effectief 2 geheel losstaande componenten hebt: apart lageresolutie videomateriaal dat door een standaardcodec weergegeven kan worden, en aparte upscaling-informatie, waarvoor het doelapparaat de Lcvec codec moet begrijpen. Het is dus backwards compatible met de codec die het gebruikt voor het lage-resolutie beeldmateriaal, wat implementeren makkelijk maakt (ondersteund je browser/TV/mediaspeler het niet? Dan heb je slechtere beeldkwaliteit maar werkt het wel).

Je hebt i.t.t. JPEG2000 dus ook nooit 3 of meer resoluties, maar altijd maar één lage resolutie, en de upscaled + gecorrigeerde hoge-resolutie.

[ArnoutV]

Je hebt volgens mij helemaal gelijk en dat is wat ik volgens mij met minder woorden zelf ook vast stelde.

Het lijkt een beetje op het concept van JPEG 2000, alleen dan met 2 lagen.
De oorspronkelijke lage resolutie encoding en dan een extra laag waar de volle (output) resolutie is gecodeerd met als basis de lage resolutie data.

[Reactie gewijzigd door ArnoutV op 23 juli 2024 00:22]

[Sando]

Niet helemaal: het idee achter JPEG 2000 was dat je meerdere resoluties had, zodat je eerst een lage-resolutie variant kon inladen en weergeven als placeholder, en hierna meerdere hogere resolutie-varianten, zonder dat er veel dubbel opgeslagen hoeft te worden omdat de informatie uit de lagere-resolutie variant deels hergebruikt wordt

Is dat niet precies wat de originele JPEG al doet in progressive mode?

quote: Wikipedia

There is also an interlaced progressive JPEG format, in which data is compressed in multiple passes of progressively higher detail. This is ideal for large images that will be displayed while downloading over a slow connection, allowing a reasonable preview after receiving only a portion of the data.

[Aidix]

Zo was daar ook ooit MP3 Pro wat een 48 of 64kbit MP3 stream opleukte met een kleine extra 'SBR' bitstream om zo het geluid te krijgen van een 96-128kbitMP3.

[Marctraider]

DLSS op codec niveau druist in tegen de definitie van wat een codec moet doen.

Machine learning moet altijd als optionele post-processing want het blijft altijd een approximatie en kan geen directe afleiding zijn op code niveau wat je terug kan 'reassemblen'.

[Niet Henk]

Dat is dus precies het punt hier:

Je hebt je standaard codec, bijvoorbeeld HEVC, die gebruikt wordt voor het lage-resolutie materiaal.

Je hebt een gestandaardiseerde upscaler die de hoge-resolutie content benadert.

En, i.t.t. simpel upscalen, heb je correctie-informatie, wat de upscaler kan gebruiken om fouten bij het benaderen te corrigeren.

Je kan wel zeggen dat dit niet is wat een codec moet doen, maar lossy codecs benaderen altijd, en als dit op deze manier veel effectiever kan, en backwards compatible is met de standaard-codec, dan lijkt me dat toch mooi? En je kan in theorie zelfs met deze aanpak een lossless codec schrijven, door correcties voor alle fouten die de codec maakt mee te geven.

Lijkt me zeker niet out-of-scope voor een codec. Klinkt als een heel elegante aanpak die toestaat dat oude apparaten of apparaten die niet genoeg rekenkracht hebben om te kunnen upscalen altijd bij het lage-resolutie materiaal kunnen.

[MSalters]

Al sinds MP3 is compressie een approximatie. Dit zijn allemaal lossy codecs.

Wat betreft de lossy compressie met een neuraal netwerk: dat is helemaal geen gek idee, want we weten dat de decoding in jouw hoofd ook door een neuraal netwerk gebeurt. En recente AI ontwikkelingen zijn wel vaker gebaseerd op de interactie van meerdere neurale netwerken (Teacher-student setups, adverserial learning, of de meeste bekende, deep fakes).

Ik heb net vandaag naar de presentaties van de DCASE 2020 AI conferentie zitten kijken. De Johannes Kepler University had een mooi verhaal over de detectie van storingen in machines met behulp van audio: als een AI het geluid goed kan comprimeren, dan werkt de machine normaal.

[Superstoned]

Er is ook ergens op 't internet een super interessante video chat youtube video te vinden waarbij AI wordt gebruikt om een stream van iets van 300kb/sec terug te brengen naar 1 of 2 kb/sec. - super clever natuurlijk. Niet helemaal perfect, maar heeeeeel aardig.

Ok, heb het ff opgezocht - 't is van NVIDIA, super cool project:

https://www.dpreview.com/...itional-video-compression

[hottestbrain]

DLSS doet echter de upscaling met een AI algoritme dat per game getraind moet worden, dat lijkt hiet niet het geval.

[Werelds]

DLSS is niet meer per game getraind. DLSS "1.9" (Control, Augustus 2019) en 2.0 (April 2020) werken beide met netwerken die agnostisch getraind zijn, in plaats van per game.

[hottestbrain]

Ah ik loop ernstig achter zie ik, excuus. Het AI punt blijft, per game niet.

[_Thanatos_]

Waarom zou AI een punt zijn om te maken dan? Wat Nvidia voor games gebruikt, kan toch ook voor video gebruikt worden, of zie ik dat verkeerd?

[hottestbrain]

Nee het punt was dat er voor deze lcevc codec geen AI gebruikt wordt als ik het goed lees, niet dat het in theorie niet zou kunnen

[_Thanatos_]

Ah ok, maar een specifieke Nvidia-implementie van zo'n codec zou dat wel kunnen, toch? Het is niet alsof er ooit maar één implementie van deze codec zal bestaan. Je hebt de opensource codecs, eentje van Microsoft, eentje van Google, eentje van Nvidia voor hun CUDA-cores en AI-gebeuren, en mss maakt AMD er ook wel een die van de AMD-equivalente GPU-technieken gebruikmaakt.

[dmantione]

De MPEG is ter ziele. Dit zal dus geen officiële MPEG-standaard zijn. Even lijkt er wel een relatie te zijn met de MPEG, het lijkt als ik het zo niet zo te zijn dat iemand de naam van de MPEG heeft gestolen? Kan de auteur met zijn beschikbare informatie toelichten hoe dit nu zit?

[Werelds]

De MPEG groep was altijd al een verzameling van werkgroepen omtrent ISO/IEC standaarden. Vroeger was deze groep autoritair, maar door de komst van het internet was er een noodzaak voor standaarden die geen bakken met geld kostten. Dat resulteerde in concurrerende codecs. Doordat een groot deel van de stakeholders heel erg ouderwets en/of hebberig is, is de ontwikkeling van HEVC ook erg traag gegaan. Een deel van de groep wilde niet afzien van licenties en royalties, waardoor er heel veel compromissen zijn gesloten. Ik kan er nog heel lang over door gaan, maar als puntje bij paaltje komt is MPEG als groep simpelweg achterhaald. Het heeft heel lang als een kartel geopereerd en dat werkt gewoon niet meer.

Dat betekent allemaal echter niet dat de naam "MPEG" verdwijnt. Dat is inmiddels een ingeburgerde term die voor 99,9% van de wereldbevolking helemaal niet synoniem met de groep is. Nee, MPEG is "video". MPEG is ook geen handelsnaam, -merk of eigendom van wie dan ook. Niet dat men dat niet geprobeerd heeft; ook Philips heeft dat geprobeerd. MPEG zal hoogstwaarschijnlijk de term blijven die ISO/IEC hanteren voor video standaarden

[Zer0]

Volgens mij is men gewoon doorgegaan zonder Leonardo...
https://www.mpegstandards.org/whats-new-in-mpeg/
https://www.mpegstandards.org/meetings/mpeg-133/

[Admiral Freebee]

Lcevc is in feite een hybride codec. De basis wordt gevormd door een versie van het bronmateriaal te encoderen op een lagere resolutie, waarbij een bestaande codec wordt gebruikt. Dit is de basislaag. Die lagere resolutie garandeert dat er minder energie en bandbreedte nodig is. Er zijn minder pixels, dus is minder rekenkracht vereist. Vervolgens komt de verbeteringslaag, waar het draait om het toevoegen van additionele details en resolutie; deze data wordt gecomprimeerd via Lcevc, waarbij ook het opschalen van het beeld plaatsvindt. Het verschil tussen deze lagere resolutie en de verbeteringsversie, wordt geëncodeerd. Door de basislaag is Lcevc backward compatible en kan een Lcevc-stream gewoon worden afgespeeld, ook al herkent de speler de Lcevc-data niet.

Als ik het goed begrijp kunnen niet compatibele spelers dan enkel het lage resolutie basismateriaal afspelen dat gecodeerd is met de oorspronkelijke codec. Zij krijgen dan eigenlijk mogelijk een slechtere beeldkwaliteit dan als het materiaal op een hoge resolutie was gecodeerd met de oorspronkelijke codec?

Het lijkt me dat dit gebruikt wordt om te voorkomen dat materiaal gecodeerd met mpeg-5-lcevc niet zou werken op bestaande spelers en dat de adoptie daardoor achterblijft. Het is een manier om ervoor te zorgen dat het materiaal op z'n minst afspeelt, ook al is de kwaliteit niet goed.

Ik vraag me dan wel af hoe men de extra data toevoegt zonder de compatibiliteit stuk te maken. Ik weet dat sommige standaarden toestaan dat er onbekende data toegevoegd wordt dat niet compatibele spelers gewoon kunnen negeren maar het artikel claimt dat deze codec toegepast kan worden op alle bestaande en toekomstige codec en dat lijkt mij een sterke uitspraak.

[Eonfge]

Op papier heeft V-Nova ook het voordeel dat het met Lcevc de 'stammenstrijd' tussen verschillende kampen omzeilt om de nieuwe dominante videocodec te worden.
[...]
Waarschijnlijk zal in december duidelijkheid komen over de situatie ten aanzien van de royalties en licenties voor het gebruik van Lcevc.

En daarmee zal bepaald worden of LCEVC ooit interessant wordt voor AV1. Bedrijven zoals een Google, Netflix en Amazon zitten druk te pushen op AV1 omdat ze dan geen bergen licentiekosten moeten afdragen. LCEVC kan wel lekker roepen dat ze onpartijdig en ongebonden zijn aan de codec-strijd, maar zodra ze er voor kiezen om hun patenten-claim te houden, dan komen ze duidelijk in het kamp van EVC en VVC terecht.

[Mr. Bakkebaard]

Het idee om de bitstream op te splitsen in meerdere layers die elk wat meer detail toevoegen bestaat al heel lang, zoals onder andere in H.264 Scalable Video Coding: https://en.wikipedia.org/wiki/Scalable_Video_Coding

Ik vraag me af hoe deze encoder presteert ten opzichte van de x.264 implementatie hiervan.

[Galactic]

Ik vraag me af wie het nog begrijpt inderdaad.

[ExManolo]

Inderdaad, en ook of dat allemaal werkelijk een verbetering is. Ik keek laatst een wat oudere film uit mijn verzameling en vond, ondanks wat ruis, het beeld veel stabieler en scherper dan die tegenwoordige schuimrubberen pastel beelden die continu veranderen qua detail.

[SpiceWorm]

Cool dat tweakers weer gewoon over dit soort dingen bericht! Er zit weer beweging in de computermarkt.

[Pietjebit]

Dit doet me denken aan FAROUDJA’S F1 VIDEO BITRATE REDUCER uit 2015.
En de overname van de patenten door V-Nova.
https://www.v-nova.com/v-...nts-faroudja-enterprises/
De co-founter van Faroudja Xu Dong is een nieuw bedrijfje gestart genaamd MatrixView Technologies.
https://www.MatrixView.com

[Reactie gewijzigd door Pietjebit op 23 juli 2024 00:22]