Ontwikkelaars beginnen bouw opensource-hevc-encoder

Een aantal ontwikkelaars is onder de projectnaam Kvazaar op GitHub begonnen met de bouw van een opensource-hevc-encoder. Veel features van de geavanceerde videocompressiemethode ontbreken nog.

Hevc is de opvolger van de veelgebruikte h264-codec en wordt onder andere gebruikt om 4k-videostreams te comprimeren. Gemiddeld zou hevc bestanden en streams 50 procent beter kunnen comprimeren dan h264. Hoewel hevc nog weinig gebruikt wordt, is de verwachting dat de codec in de komende jaren een snelle opmars zal maken.

Naast al verkrijgbare commerciële hevc-encoders en -decoders is inmiddels op GitHub een project gestart voor de ontwikkeling van een opensource-hevc-encoderimplementatie. De encoder, die Kvazaar moet gaan heten, moet een GNU GPLv2-licentie krijgen. Ook wordt gewerkt aan x86- en x64-Windowsversies van de encoder, terwijl er ook Linux-implementaties beschikbaar komen.

Veel onderdelen van de hevc-specificatie zijn nog niet of slechts deels in de Kvazaar-encoder verwerkt. Ook zijn er nog veel optimalisaties nodig. Onduidelijk is nog wanneer de encoder voldoende volwassen zal zijn om breed gebruikt te gaan worden.

Reacties (55)

[rb338]

Het gaat hier dus specifiek om de encoder. De titel is hierin wel duidelijk, maar het artikel schept verwarring met de term 'codec'. Codec (coder-decoder) zou betekenen dat zowel het encoden als decoden mogelijk is, maar dat is met Kvazaar niet het geval. Die is namelijk specifiek voor het encoden, dus de titel is juist.

Voor de decoder is overigens ook een open-source project: https://github.com/OpenHEVC/

[Reactie gewijzigd door rb338 op 22 juli 2024 23:08]

[Dimitri R]

Je hebt gelijk, dus fixed: 'encoder' verder in het artikel gebruikt.

[Durandal]

Mijn vraag is dan of die codec ook de huidige x264 streams efficienter kan coderen.

[johnbetonschaar]

Dat lijkt me niet erg waarschijnlijk, als de H264 codec nog ruimte zou hebben om geavanceerdere encoders te maken die betere of even goede beeldkwaliteit bij lagere bitrate oplevert, dan was het waarschijnlijk niet nodig geweest om H265 te ontwikkelen.

x264 staat bekend als een van de betere H264 encoders, misschien wel de beste, en is volgens mij al vrij lang min of meer uitontwikkeld. Wellicht is het wel mogelijk om met extreem dure (in termen van benodigde CPU power) analyse van het bronmateriaal of nog complexere voorspellende algoritmes de encoder te verbeteren, maar dat staat los van de codec, zulke technieken zou je bij H265 namelijk ook eerst moeten 'uitvinden' om ze te kunnen toepassen.

Belangrijk punt om in je achterhoofd te houden is dat video codecs niet voorschrijven hoe je het beste een encoder kunt schrijven, alleen maar met welke basis algoritmes je de geencodeerde informatie kunt vastleggen en hoe je de bitstream moet opbouwen. Hoe je repeterende of (voor het oog) redundante informatie in het beeldmateriaal kunt 'ontdekken' is eigenlijk een totaal andere tak van sport, die wel afhankelijk is van de codec (die moet wel de mogelijkheden bieden om bepaalde encoding technieken toe te passen), maar niet door de codec zelf wordt gespecifieerd. Vandaar dat er ook zoveel verschil in kwaliteit van encoders zit, en er zo veel proprietary commerciele encoders bestaan waar technieken in gebruikt worden die niet algemeen of openbaar bekend zijn.

[kiang]

Belangrijk punt om in je achterhoofd te houden is dat video codecs niet voorschrijven hoe je het beste een encoder kunt schrijven, alleen maar met welke basis algoritmes je de geencodeerde informatie kunt vastleggen en hoe je de bitstream moet opbouwen. Hoe je repeterende of (voor het oog) redundante informatie in het beeldmateriaal kunt 'ontdekken' is eigenlijk een totaal andere tak van sport, die wel afhankelijk is van de codec (die moet wel de mogelijkheden bieden om bepaalde encoding technieken toe te passen), maar niet door de codec zelf wordt gespecifieerd. Vandaar dat er ook zoveel verschil in kwaliteit van encoders zit, en er zo veel proprietary commerciele encoders bestaan waar technieken in gebruikt worden die niet algemeen of openbaar bekend zijn.

Dikke +3 voor jou Velen weten dit niet, maar dit is absoluut waar. Elke codec maakt een afweging tussen complexiteit (hoe snel encodeer je?) en efficiëntie (hoeveel kwaliteit behoudt je tov de bitrate). Die afweging wordt gemaakt zowel bij software encoders (hogere complexiteit betekent dat het proces langer zal duren) als hardware encoders (hogere complexiteit betekent meestal een meer ingewikkeldere chip, die dus duurder is en mogelijks meer stroom gebruikt).

Het formaat zegt dus niets over de efficiëntie, enkel over de potentiële efficiëntie. Wie een slechte encoder schrijft kan namelijk perfect een HEVC stream produceren die er slechter uitziet dan de h264 stream en toch meer ruimte inneemt.

De potentie van HEVC is echter een stuk hoger dan die van h264, zoals al aangetoond in de testen van de JCT-VC.

[Niosus]

Ik denk dat je hem verkeerd begrijpt. Vanuit andere comments kan ik afleiden dat hij bedoelt of je videos die nu in h264 aangeboden worden binnenkort naar hevc kan overzetten (via bron eventueel) en plaats besparen. In dat geval gaat er door de veel efficientere structuur van hevc weldegelijk een groot verschil gemaakt worden.

[kiang]

wat bedoel je met coderen? Bedoel je encoderen ('opnemen') of transcoderen (stream omzetten van ene codec naar andere)? Je commentis namelijk wat vreemd.

Het gaat hier over een HEVC encoder, gebruikt dus om HEVC streams op te nemen. Je kunt er geen h.264 streams mee encoderen of decoderen, dat is een heel andere codec, waarvoor er al tientallen efficiënte (software en hardware) encoders bestaan.

Jouw vraag lijkt dus een beetje op vragen of een dvd recorder ook video casettes kan opnemen. Neen: de twee zijn heel andere formaten.

Overigens: je hebt het over x264, maar he bedoelt h264 streams h.264 is het formaat, x264 is een open source library om h.264 te encoderen.

[Reactie gewijzigd door kiang op 22 juli 2024 23:08]

[Hierodemus]

h.264 is het formaat, x264 is een closed source library om h.264 te encoderen.

Niet helemaal, x264 is namelijk een open source library.

[kiang]

Bedankt om me erop te wijzen, reactie aangepast!

[Durandal]

Coderen is niet decoderen, en ook niet transcoderen. Encoderen is volgens mij Engels, coderen gewoon Nederlands. Verder weet ik wat een codec is.

Ik bedoelde of hij ook de huidige 720p/1080p content efficienter comprimeert dan h264 doet, of dat hij alleen efficienter is op 4k.
M.a.w. is het nuttig om de content opnieuw te comprimeren met HEVC?

(overigens zie ik niet in hoe mijn initiele vraag off-topic is)

[Reactie gewijzigd door Durandal op 22 juli 2024 23:08]

[rob12424]

Encoderen= inpakken
Decoderen = uitpakken

transcoderen = het formaat wijzigen in ander formaat (eigenlijk meestal voor transport)

Eigenlijk gebeurt er dus dit door een Encoder:

Je hebt fruit: De Encoder gooit het in een blender. Het is nu een ander formaat (vruchtensap) Het is nu veel compacter dan het fruit (getranscodeerd) En kan dus sneller verzonden worden en neemt minder ruimte in.

Dan komt de Decoder die pakt het vruchtensapje uit en maakt er pecies weer het fruit van wat er in het vruchtensapje ging.

[Durandal]

Waar die +3 vandaan komt weet ik niet (Ja eigenlijk weet ik het wel; het is droevig gesteld met het hedendaagse taalkennis), maar zoals ik hierboven dus al zei: Coderen is Nederlands, encoderen is een Engels woord.
Je hebt dus coderen en decoderen.

Van Dale over coderen:
co·de·ren (codeerde, heeft gecodeerd) 1in code overzetten

Van Dale over encoderen:
Geen resultaat voor ' encoderen '

Verder mag ik er natuurlijk wel vanuit gaan, en dat deed ik ook, dat elke tweaker/geek weet wat coderen, decoderen en transcoderen is; dat was hier nooit het discussiepunt.
Overigens is het eigenlijk compressie, want het gaat er niet om dat het in code word omgezet, maar dat het gecomprimeerd wordt.

[kiang]

Absoluut, HEVC is een stuk efficiënter voor eender welk formaat. Source: eigen ervaring met universitair onderzoek, en als je wilt ook de volgende quote op wikipedia

HEVC is targeted at next-generation HDTV displays and content capture systems which feature progressive scanned frame rates and display resolutions from QVGA (320x240) to 4320p (8192x4320), as well as improved picture quality in terms of noise level, color spaces, and dynamic range.

[Twilkie]

Het gaat over een HEVC encoder, niet decoder.

[kiang]

Zag ik ook net Comment aangepast

[lordgoblin99]

Het gaat over de opensource Kvazaar codec in het artikel, als je het hebt over een codec, moet zowel encoderen als decoderen mogelijk zijn.

[84hannes]

x264 is een open source library om h.264 te encoderen.

Van hun website:

x264 is a free software library and application for encoding video streams into the H.264/MPEG-4 AVC compression format, and is released under the terms of the GNU GPL.

[Reactie gewijzigd door 84hannes op 22 juli 2024 23:08]

[MAX3400]

Mijn vraag is dan of die codec ook de huidige x264 streams efficienter kan coderen.

Waarom een encoded file nogmaals encoden zodat je 2 decoders nodig hebt om uiteindelijk weer beeld te krijgen?

[Verwijderd]

Waarom een encoded file nogmaals encoden zodat je 2 decoders nodig hebt om uiteindelijk weer beeld te krijgen?

Even los van het feit dat je dat sowieso niet moet doen bij lossy methodes (altijd het origineel her-encoderen)... je hebt dan nog steeds maar 1 decoder nodig; die van de laatste encoder.

Als je een Word bestandje ZIPt en daarna RARt heb je wel 2 decoders nodig (die voor RAR en die voor ZIP), aangezien beide de invoer zo nemen als die is. Bij lossy audio en video encoders bekijken ze het eigenlijke beeld - en niet de ruwe bits/bytes - interpreteren die, en encoden het op hun eigen manier. In ZIP-/RAR-taal zou dat hetzelfde zijn als dat de RAR 'encoder' eerst de ZIP uitpakt, en daarna opnieuw in RAR formaat inpakt.

[BugBoy]

Waarschijnlijk bedoelde de poster of een H.264 stream getranscode kan worden naar H.265. Je kunt natuurlijk H.264 decoderen en opnieuw coderen met H.265, dus het is wel degelijk mogelijk. De vraag is of je het moet willen.

Het nadeel van transcoden is dat de artifacts van de originele codec ook gecomprimeerd worden. Dergelijke artifacts kunnen een negatief effect hebben niet alleen een negatieve beeldkwaliteit tot gevolg, maar vaak zijn ze ook nadelig voor de compressie-ratio (artifacts kunnen onlogisch zijn, waardoor het lastiger te comprimeren is).

Het is dus beter om het origineel te encoden, maar dat moet je dan nog wel hebben.

[Durandal]

Dat heb ik ook niet gezegd; je kan opnieuw van de bron coderen.

[Soldaatje]

Efficienter in de zin van kleinere bestanden met eenzelfde kwaliteit, vast wel.
Maar of het ook de moeite waard is en wat het kost aan stroom en cpu/gpu kracht is nog maar de vraag.

Edit: Ik bedoel meer: als je nu al een archief met h264 1080p materiaal hebt is het dan de moeite waard om alles te gaan transcoden? Misschien met speciale hardware?

[Reactie gewijzigd door Soldaatje op 22 juli 2024 23:08]

[kiang]

Absoluut. HEVC neemt ongeveer 50% minder bandbreedte, wat zeker bij 4k streams wenselijk is: die nemen namelijk 4 keer meer ruimte in dan 1080p streams.

Daarbovenop is HEVC veel beter geschikt voor resoluties boven de 1080p, doordat er grotere blokgroottes (64x64, tov 16x16 in h.264) ondersteund worden.

[Blokker_1999]

Het is niet omdat het aantal pixels verviervoudigd dat de bandbreedte dat ook doet. Ja, de vereiste bandbreedte stijgt aanzienlijk, maar zal minder dan een vervierdoudiging zijn.

[DieterVDW]

Ik denk dat de poster doelt op de ongecomprimeerde bandbreedte.
4k bevat nu eenmaal 4x meer pixels dan 1080p .

Maar natuurlijk is er geen kat die die streams ongecomprimeerd zal streamen of opslaan .

[kiang]

Klopt, maar op hogere resoluties wordt dit aandeel kleiner en kleiner, tot een insignificant verschil.

Source: heb ik zelf onderzoek naar gedaan, met HEVC. Als je een 8k video opsplitst in 16 1080p streams, nemen die 16 streams tezamen minder dan 1 procent extra banbreedte in. tov de 8k stream.

De reden is dat het aandeel van geaffecteerde coding units (nieuwe blokstructuur in HEVC, maar het geldt even goed op de macrblokken in AVC) een stuk kleiner is op hogere resoluties, en dat het effect op de geaffecteerde blokken kleiner.

Als je een video gaat opdelen in tiles van kleiner dan 500x500, pas dan ga je een groter effect zien op de bandbreedte.

[Reactie gewijzigd door kiang op 22 juli 2024 23:08]

[TTIelu]

Gaat niet aanslaan vrees ik..

Ongeacht of dit project opensource is of niet, (grote) bedrijven moeten voor het gebruik van HEVC (en de bijhorende patenten) nog steeds licentiegelden betalen - besparen doen ze er dus amper mee.

Verder heeft dit project een GNU GPLv2-licentie - waardoor dat industriele integratie in closed source projecten niet mogelijk zijn (en dus ook geen aandacht/toevoegingen uit de industrie zal krijgen).

Tenslotte gaat het hier om een encoder, niet om een opensource codec - welke volgens mij interessantere toepassingen in de opensource wereld kan hebben.

[Giesber]

Net zoals xvid en x264 ook gigantisch geflopt zijn omdat het open source projecten zijn, waarbij licentiegelden betaald moeten worden?

Of het de nieuwe de-facto standaard zal worden weet waarschijnlijk nog niemand, maar om het project zomaar ten dode op te schrijven lijkt mij niet correct gezien de geschiedenis van xvid en x264.

[mashell]

Verder heeft dit project een GNU GPLv2-licentie - waardoor dat industriele integratie in closed source projecten niet mogelijk zijn

Dat kan met GPLv2 heel goed. Duizenden producten met Linux onder GPLv2. Die nare dingen die bedrijven belemmerend vinden zitten juist in GPL v3.

[Dreamvoid]

Beter zou idd een BSD-licensie zijn, die meer vrijheid biedt aan developers.

[oef!]

x264 Wordt veelvuldig ingezet bij de aanlevering via "alternatieve" bronnen. Het lijkt me dan ook dat x265/kvazaar deze traditie gaat voortzetten.

[Dreamvoid]

Als je al illegaal films loopt te verspreiden, dan is het gebruik van een encoder waarvoor geen licensiegeld is betaald wel het laatste waar je je druk om maakt.

[Surkow]

Commercieel gebruik is gewoon mogelijk en er zijn zat partijen die bijdragen aan ontwikkeling van open source encoders (zoals x264).

[Reactie gewijzigd door Surkow op 22 juli 2024 23:08]

[MAX3400]

Ondanks dat ik niet geheel thuis ben in encoding en standaarden, wat is nu het verschil tussen de opvolger H265/x265 en deze hevc?

Er is namelijk ook al een project om x265-encoding in een opensource-format op te leveren: https://bitbucket.org/multicoreware/x265/wiki/Home

[Goderic]

H265 is precies hetzelfde als HEVC, afaik is HEVC de officiële benaming en wordt de naam h265 veel gebruikt omdat het de opvolger is van h264.
x265 en Kvazaar zijn beide open source encoders om video naar het HEVC formaat om te zetten.

[Rafe]

Als ik https://bitbucket.org/multicoreware/x265/commits/all gebeurt er nog wel wat? Ook GPLv2 overigens.

[kiang]

HEVC en h.265 zijn exact hetzelfde, net zoals h.264 en AVC hetzelfde zijn.

Het een is gewoon de benaming gebruikt door de MPEG, het ander de benaming door de VCEG.

[rb338]

HVEC = H.265

X.265 is weliswaar gestart als open-source project, maar volgens mij niet echt van de grond gekomen. De mensen achter X.264 doen niet mee aan X.265. Ik denk dat daarom het werk onder de pakkende naam Kvazaar gestart is.

[Nees]

Of deze:
http://code.google.com/p/x265/

Of is dat dezelfde?

Deze is in elke geval al in ontwikkeling sinds 2012. Tweakers had op z'n minst een beetje research had kunnen doen, want nu lijk het alsof de codec in het nieuwsbericht de enigste en eerste is.

[crazylemon]

Ze zijn amper klaar met hardwarematige decoders voor H264. Die zitten er dus voor Jan. L. in wanneer dit de nieuwe standaard gangbaar wordt?
Wat voor een CPU-power heb ik nodig om dit zonder schokken te bekijken vergeleken met 4k in H264?
MAKEN ZE DAT DING OOK DIRECT VOOR 8k en 16k? Zodat we niet om de 3 jaar nieuwe shit moeten kopen?

[Durandal]

Ik neem aan dat de efficientiewinst afneemt met elke nieuwe generatie van compressie (grootste stappen zet je het eerst), dus vroeg of laat loont het niet meer om een nieuwe encoder te maken.
50% meer compressie t.o.v. h264 is echter nog heel wat. Als de volgende stap 30% is dan zal die ook nog wel komen..

Trouwens, fabrikanten worden heel blij als je om de 3 jaar nieuwe shit moet kopen.

[crazylemon]

Ahh je bent fabrikant

[- peter -]

Oftewel dit is h265. Misschien goed om ook even te vermelden in t artikel?

[Gody]

Volgens Tweakers hier inderdaad wel.

[ATS]

Zijn de technieken die nodig zijn om HEVC te encoden niet gepatenteerd dan? Leuk als je dan een open source implementatie hebt, als je vervolgens op het moment dat je het toepast je een patentclaim aan je broek hebt hangen...

[Dreamvoid]

Open source wil niet zeggen patentvrij. Je kan heel goed open source code schrijven met gepatenteerde technologie. Zodra je het gebruikt, moet je betalen - zo is het nu al jaren het geval bij de diverse open source mpeg 1/2/4 encoders en decoders. Als je VLC bijvoorbeeld gebruikt ben je als gebruiker verantwoordelijk voor licensiebetalingen (das ook de reden dat het bedrijfsmatig zelden wordt gebruikt).

[Reactie gewijzigd door Dreamvoid op 22 juli 2024 23:08]

[Durandal]

Dat is een beetje grijs gebied v.w.b. open source. Ten eerste zijn software patenten discutabel in Europa. Ten tweede wordt er geen winst gemaakt, en ten derde is het voor eigen gebruik en de eindgebruiker kan het zelf (direct of indirect) compileren.
Patenten verbieden je niet ze voor eigen gebruik te implementeren.

[appies]

iets voor netflix? Een platformloze stukje software dan eindelijk. Of zitten we dan met de beveiliging te kijken?

[pbruins84]

Netflix gebruikt al HEVC voor zijn 4k-streams

[appies]

Ah, thanks wist ik nog niet!

[Verwijderd]

Merk op dat dit een academic open source project is van de Ultra Video group van Tampere University of Technology, Finland:
http://ultravideo.cs.tut.fi/#encoder

[vharten]

Zouden ze al in de buurt komen van het Sloot Digital Coding System qua compressie?

http://jansloot.telcomsoft.nl/

[crazylemon]

Ah je bedoeld die "blackbox" tech die nooit bewezen is?