Netflix gaat gebruikmaken van Intels opensource-encoder voor av1-videocodec

Netflix en Intel hebben op de in Las Vegas gehouden National Association of Broadcasters Show bekendgemaakt dat ze de handen ineen hebben geslagen voor de ondersteuning en ontwikkeling van de eerder onthulde SVT-AV1, een opensource-encoder voor de av1-videocodec.

Intel heeft Scalable Video Technology for AV1, of kortweg SVT-AV1, officieel aangekondigd en brengt de encoder uit volgens een BSD+Patent, wat het volgens de Amerikaanse chipmaker eenvoudig maakt om het te gebruiken en commercialiseren voor ontwikkelaars. Het betalen van royalties is daarbij niet aan de orde.

De SVT-AV1-encoder werd eerder al uitgebracht op GitHub, maar in Las Vegas volgde de officiële presentatie, waarbij bekend werd dat Netflix met Intel gaat samenwerken. SVT-AVC1 is een opensource-encoder voor de av1-videocodec. Deze codec, die waarschijnlijk bestaande codecs als hevc en het door Google gebruikte vp9 zal gaan vervangen, vergt veel minder bandbreedte.

De encoder is niet direct geschikt of bedoeld voor de thuisgebruiker, aangezien de systeemeisen niet mals zijn. Zo is op een systeem met 112 logische kernen 48GB nodig om een stream in 4k-resolutie met 10bits-kleuren te draaien. De software is met name bedoeld voor servers die worden ingezet voor het online streamen van video, waarbij Intel het heeft geoptimaliseerd voor Core-processors van de Skylake-generatie en Intel Xeon-cpu's.

Netflix heeft in september 2015 samen met Amazon, Cisco, Google, Intel, Microsoft en Mozilla de nonprofitorganisatie Alliance for Open Media opgericht. Deze partijen zijn daarmee de drijvende krachten achter de ontwikkeling van de av1-codec. Apple voegde zich begin 2018 ook bij de alliantie, net als Samsung dat onlangs deed.

Reacties (52)

[JackDashwood]

Deze codec, die bestaande codecs als hevc en het door Google gebruikte vp9 zal gaan vervangen, vergt veel minder bandbreedte.

Dat zijn twee nogal vrij grote claims. Het lijkt mij nog niet helemaal niet zeker dat AV1 de vervanger zal zijn van HEVC. Zo werd destijds ook geroepen dat VP8 de vervanger was van H264 en VP9 de vervanger van HEVC. In beide gevallen is dat absoluut niet gebeurd.

Vergeet ook niet dat vooralsnog geen enkel apparaat over een AV1 hardware decoder beschikt. Dus voordat AV1 mainstream kan gaan moet iedereen een nieuwe telefoon/tablet/smart-tv/whatever hebben die AV1 kan afspelen. Daarnaast zal de groep achter HEVC ook niet stilzitten en waarschijnlijk hun licenties aanpassen om beter te kunnen concurreren met AV1. Dan heb je ook nog de 4K Blu-ray standaard die HEVC zal blijven gebruiken en niet over zal gaan op AV1.

Wat mij betreft is het nog veel te vroeg om AV1 de vervanger van HEVC te noemen.

[Terrestrial]

Helemaal mee eens.. Er wordt allang ontwikkeld aan H.266 wat de officiële opvolger wordt van H.265/HEVC dient te worden.

[Peetke]

Het is inmiddels wel een compleet ander speelveld. Alles is streaming geworden, schijfjes doen er niet meer toe. Daarmee is alles veel flexibeler geworden.

Daarnaast zit er nu een consortium spelers achter, van heb ik jou daar:
https://aomedia.org/membership/members/

Dus hopelijk eindelijk de echte doorbraak voor opens-source AV1 en Opus audio.

[sdk1985]

Het is inmiddels wel een compleet ander speelveld. Alles is streaming geworden, schijfjes doen er niet meer toe. Daarmee is alles veel flexibeler geworden.

Daarnaast zit er nu een consortium spelers achter, van heb ik jou daar:
https://aomedia.org/membership/members/

Dus hopelijk eindelijk de echte doorbraak voor opens-source AV1 en Opus audio.

Waarom hopen we op een doorbraak? Is het niet prettig dat x265 nu gewoon hardwarematig in de cpu, videokaart, telefoon en tablet zit? Zitten we te wachten op nog een extra dedicated chip?

[Peetke]

Dit gaat natuurlijk meegebakken worden in bestaande silicon, niet op een extra dedicated chip. Zo ging dat ook al met vp8, vp9, x264, x265. Er zijn een aantal effecten:
-De codec is nieuwe en efficiënter: hogere bitrate bij zelfde bandbreedte, of veel minder bandbreedte (minder buffering) tov van HEVC/x265.
-AV1 vervangt een hele set aan codecs met 1 nieuwe (VP10, Theora, Daala (Xiph/Mozilla), Thor (Cisco). Net zoals met Opus combineert het dus een hele hoop partijen en zal dit zorgen voor extra innovatie&robuustheid van deze codec.
Maar ook al zou je nooit deze codec gebruiken heeft iedereen voordeel:
-De MPEG club heeft al meermaals de eisen en royalties versoepeld. Zo is er dus al een uitstralend effect op bestaande gesloten codecs.
-De MPEG club heeft een goede schop onder zijn kont gekregen en is veel harder gaan ontwikkelen.

[sdk1985]

Tussen (gpu) offloading en hardware acceleratie zit nog wel een verschil. Voor een praktijk voorbeeld zie de Raspberri Pi 3 icm x264 decode mogelijkheden: https://www.reddit.com/r/...264_encoding_with_ffmpeg/

Praten we over hardware acceleratie dan praten we over fysieke toevoegingen aan de hardware voor een bepaalde codec. Zie ook bijvoorbeeld Intel Gemini Lake die straks VP9 hardware matig kunnen draaien:

quote: https://nl.hardware.info/...-voor-10-bits-hevc-en-vp9

Intel's opvolger van Apollo Lake - Gemini Lake - krijgt een hardwarematige 10-bit VP9-decoder aan boord. Dat meldt Phoronix op basis van een document van Intel. Het betekent in de praktijk dat we in de toekomst efficiënter video kunnen kijken op zuinige Celeron- en Pentium-processors. Apollo Lake kennen we als de 6-10 watt verbruikende chips die voorheen Atom heetten.
Deze serie chips heeft Goldmont CPU-cores en GPU's die we ook bij Skylake zagen. Dat betekent dat er tot nu toe een halfbakken 8-bit VP9-decoder in zat die veel rekenkracht vergde omdat veel nog softwarematig gebeurde. Met de beperkte rekenkracht van de Apollo Lake-chips is dit uiteraard meer problematisch dan met een volwaardige desktop-chip. Kaby Lake voor de desktop bracht een volledige 10-bit VP9-decoder, wat inhoudt dat beelden native gedecodeerd kunnen worden, inclusief die met 10-bits kleuren. Deze VP9-decoder gaat dus ook naar Gemini Lake komen. Tevens gaat het decoderen van 10-bits HEVC ook hardwarematig.

Grote voordeel van echte hardware acceleratie is dat dit veel efficienter kan plaatsvinden.

Ik weet niet hoe lang jij al computers gebruikt om media af te spelen maar pak hem beet 15 jaar geleden was er echt een wildgroei aan codecs. Om een willekeurige video file af te kunnen spelen was er al snel het advies om maar een codec pack met daarin tientallen, zo niet honderden codecs te installeren. Dat punt zijn we gelukkig voorbij want x264 heeft momenteel een gigantisch marktaandeel. Gevolg hiervan is dat vrijwel elk apparaat sinds een jaar of 5 hardware matig x264 kan decoderen (en soms encoderen) wat voor de consument enorm prettig is. Je video speelt niet alleen af, dat was vroeger al heel wat, hij speelt ook nog energie zuinig af.

Gaan we terug naar een scenario van meerdere concurrerende codecs dan is het moderne 'gpu offloading' een veel realistischer scenario dan dat je erop rekent dat elke codec een fysieke hardwarematige implementatie krijgt. Dat maakt chips immers groter, duurder en onzuiniger. Gevolg van een stap richting gpu offloading is juist weer een daling in efficiëntie.

Nu zal dat bij één concurende codec familie niet direct mis hoeven lopen. Maar stel eens hardop de vraag hoe erg de 'macht van x264/x265 nu eigenlijk is. Natuurlijk is het irritant als jij Google, Netflix, enz bent. Dan kost het knaken. Maar als eindgebruiker valt er weinig te klagen. Niet wanneer je voor 100 euro een telefoon dan wel tablet koopt die het probleemloos afspeelt. De royalty problematiek is meer een moreel verwijt dan dat 'wij' er echt last van hebben.

[Reactie gewijzigd door sdk1985 op 23 juli 2024 04:01]

[Bruin Poeper]

Daarnaast zit er nu een consortium spelers achter, van heb ik jou daar:
https://aomedia.org/membership/members/

Daar zit niet één TV-fabrikant bij...

[Peetke]

Ik zie gewoon Samsung staan, en eigenlijk alle chipbakkers (Broadcom, Intel, AMD, ARM, Realtek, Samsung). Dus elke TV vanaf een bepaald punt zal hardware support krijgen.

En vergeet niet dat Chromecast (Google), FireTV (Amazon), AppleTV tegenwoordig ook in vele miljoenen getale over de toonbank gaan.

[Terrestrial]

Nou vergeet het maar, streaming is niks vergeleken bij de broadcast apparatuur en daar zit de leidende draad.

[dasiro]

ik denk dat het net omgedraaid is: broadcasts zijn simpel gezegd 1 enkele stream die door duizenden/miljoenen kijkers tegelijk bekeken wordt, terwijl providers met streaming content (à la netflix) per gebruiker een aparte stream moeten opzetten terwijl er minstens dezelfde beeldkwaliteit wordt verwacht en het standaard-aanbod al vaak beter is dan broadcasts, zie het reguliere tv-aanbod dat je beperkt in 720p/1080i vindt terwijl quasi elke iets of wat zichzelf respecterende streaming content-provider vlot 1080p, 1440p of zelfs 2160p ("4K") aanbiedt.

[terradrone]

je vergelijkt echt appels met peren; dezelfde beeldkwaliteit?? Jij denkt alleen maar in resolutie. Maar de totaalsom van factoren die de kwaliteit van een uiteindelijke videostream bepalen is door veel meer zaken van invloed dan alleen resolutie. Dit is net zoiets als denken in megapixels bij fotocamera's, als het aantal megapixels maar "groot" zijn dan moet het goed zijn.

Maar de praktijk is anders: de kwaliteit van veel videostreams, zoals netflix ed, is relatief gezien om te janken. Met bitrates van 6mbit en lager voor 1080p is dit beduidend minder dan bijv. de 12mbit+ die ziggo over het netwerk pompt en canaal digitaal richting de 20mbit over de satelliet.

Kijk je naar netflix 4k met ca 16mbit bitrate, dan mag je dit eigenlijk niet echt uhd noemen. Dit is zo'n lage bitrate, bedenk je dat UHD Bluray bitrates van tegen de 100mbit kent.

Wat betreft broadcast streams, dit is weer een heel niveau hoger qua kwaliteit. Waar de consumet vroeger bevoorbeeld vhs tapes gebruikte, was in de broadcastwereld betacam en umatic gemeengoed. Zo is dit nu ook met digital video: peperdure hardware video processing en hoge bitrates, dus heel anders dan de "rommel" waar consumenten mee werken.

[ArvidWillem]

De bandbreedte dicteert de kwaliteit niet.

Bij canal hebben ze oude encoders bij Ziggo nieuwe.

Die nieuwe encoders zijn vele malen efficiënter in live encoden... Dus, kun je met minder bandbreedte de zelfde kwaliteit hebben...

[terradrone]

Dit is alweer erg kort door de bocht: als je weet precies welke encoders waar staan dan graag bron vermelden, of tenminste merk en type, zomaar iets roepen kunnen we allemaal. canal digitaal doet gewoon h264 op één vd hoogste bitrates die we in nederland qua tv als particulier kunnen krijgen, daarna volgt ziggo. En ik uit eigen observatie weet dat canaal digitaal er fantastisch uitziet, in tegenstelling tot bijv kpn tv over dsl (mpeg4 lage bitrate, maar wel fullhd ;-) ) .

En de leeftijd van een transcoder / encoder dicteert de kwaliteit ook niet: digital cinema packs voor aanlevering in bioscopen werken deels gewoon op motion jpeg2000 streams, reusachtig hoge bitrates op een relatief oude codec. En dat levert fantastische plaatjes op.

[Luuk1983]

Net als resolutie zegt bandbreedte ook lang niet alles. De gebruikte codering en compressie speelt hier ook een belangrijke factor in.

[terradrone]

de totaalsom wordt bepaald door bitrate, resolutie, codec , encoding tijd (moeilijkheidsgraad / kwaliteit hardware codecs) , kwaliteit bronmaterial, eventueel framerate altering, interlacing / deinterlacing , anamorphic encoding, kwaliteit decoders, etc etc. Dus HEEL veel factoren die uiteindelijk maken wat je te zien krijgt.

[RoyD]

Natuurlijk gaat Netflix niet pas encoden op het moment dat er een stream opgevraagd wordt. Er zullen meerdere streams in verschillende kwaliteit al klaarstaan in hun harde schijven.

[Peetke]

Zelfs de BBC staat er bij. Dus niet alleen gans internet, ook broadcast fossielen.

[PPie]

BBC iPlayer?

[aileron]

Helemaal mee eens.. Er wordt allang ontwikkeld aan H.266 wat de officiële opvolger wordt van H.265/HEVC dient te worden.

Ja, zo ken ik er nog eentje. Ze zijn allang bezig met AV2. Het gaat er om dat het speelveld is veranderd. Wanneer hardware support gemeen goed wordt en de hardware eisen straks niet meer zo schrikbarend zijn omdat elke huis tuin en keuken pc dat heeft gaat dit wel echt een impact maken.
AV1 is voor de lange termijn en met alle grote spelers die hier achter zitten gaat het hoe dan ook groot worden. Maar dat duurt nog wel even 3 jaar ofzo.

[Reactie gewijzigd door aileron op 23 juli 2024 04:01]

[Terrestrial]

Als je bedenkt dat HEVC in 2013 af was en we nu 5-6 jaar verder zijn en het merendeel nog steeds H.264 gebruikt, de support voor HEVC eigenlijk pas net op gang komt. Besef dat veel mensen hun devices dit nog niet eens ondersteunen, reken maar op een traject van 8+ jaar voor dat iedereen er van kan genieten. En H.266 staat ook voor eind 2020 gepland.

Ik heb niks tegen AV1 maar de ervaring leert gewoon dat dit soort dingen vaak mislukken. De hele wereld gebruikt mpeg/H.26x en dat gaat niet zomaar veranderen.

[terradrone]

Precies wat je zegt: hevc speelt op de meeste devices heden ten dage nog steeds niet. Geen hardware playback mogelijk of maar deels, door bijvoorbeeld geen support voor 10bit video decoding (gt1030 onder linux icm kodi). Ook veel gebruikte apparatuur kan hier nog niet mee overweg, zoals smartphones. Stuur maar eens een hevc videoclip met whatsapp, daar is een externe player voor nodig of het werkt helemaal niet. Gelukkig zijn de er LAV filters die in het windows domein uitkomst kunnen bieden, maar ook hier geld, vaak geen hardware decoding. Ook hevc decoding op populaire SOC's zoals amlogic en rockchip werkt zelf nu vaak nog niet goed door allerlei problemen , oude kernels, oude drivers etc.

Maw. voordat deze codec überhaupt mainstream zou kunnen gaan worden , god, we zijn zo tien jaar verder. De enige twee formaten die op dit moment goed zijn doorgedrongen in de markt (qua hard- en software support) zijn h.264 en het oudere mpeg2 . Al het andere, vp8, vp9, hevc, av1 etc is moeilijk bruikbaar.

[Quindor]

Ik heb een volledige andere ervaring, alles wat van de laatste jaren speelt HEVC af in hardware. PC, Telefoons (zelfs Galaxy S7), tablets, zelfs mijn NVidia Shield van enkele jaren oud heeft er geen enkele moeite mee (in Kodi). Mijn TV gebruikt ook HEVC in combinatie met Netflix, etc.

Dus HEVC is naar mijn mening ook echt wel doorgedrongen inmiddels, zonder kun je niet eens 4K Netflix kijken.

Hetzelfde met YouTube, VP8 en VP9 ondersteuning zit in de meeste hardware de laatste jaren en iedereen die YouTube kijkt gebruikt het.

Dus ik denk dat we een stuk verder zijn dat je doorhebt of merkt, ze bieden nog wel backup H.264 aan (beide YouTube en Netflix) voor legacy apparaten, maar standaard is het VP9/HEVC op dit moment. Elke bit die ze niet hoeven te versturen scheelt in het geld!

p.s. Dat Kodi onder Linux geen 10Bit HEVC doet op een GT1030 ligt aan VDPAU ondersteuning die geen 10Bit kan. Onder Windows werkt dat prima (niet dat ik voorstel dat je dat perse gaat draaien, maar het is niet dat de chip het niet kan). CUVID kan het inmiddels wel, maar dat gebruikt Kodi nog niet native maar moet met MPV nog steeds.

[Hakker]

Het is maar een decoding optie. Of het nu VCC, H266, AV1 of iets anders wordt maakt geen barst uit om het te implementeren in hardware. Tijd is alles wat nodig is zoals je zelf al zegt. AV1 is nu al even af dus kan men ook daadwerkelijk aan de encoders en decoders werken.
H.266 staat op de planning om in 2020/2021 af te zijn qua specificatie en dan kan men daarmee pas aan de encoders/decoders gaan werken.

Vergeet daarnaast niet dat de grootste streaming diensten aan AV1 hebben meegewerkt. Dit om ook onder de licenties uit te komen aangezien AV1 licentievrij is tegenover H.266. Licentie vrij wil dus ook zeggen dat het in goedkope chips makkelijker zal komen. Helemaal als ze ook nog eens promoter partners zijn.

[kiang]

Dat zijn twee nogal vrij grote claims. Het lijkt mij nog niet helemaal niet zeker dat AV1 de vervanger zal zijn van HEVC. Zo werd destijds ook geroepen dat VP8 de vervanger was van H264 en VP9 de vervanger van HEVC. In beide gevallen is dat absoluut niet gebeurd.

Verschil is dat ten tijde van die VP8 claim AVC al goed ingeburgerd was. HEVC zie ik tegenwoordig amper, op nieuwe telefoons is het een optie om als encoder te gebruiken, maar standaard zie ik die tot nu toe altijd uit staan, en ergens anders heb ik HEVC in de praktijk eigenlijk nog niet gezien.

Ik kan me vergissen natuurlijk, want ik check niet altijd en overal de codec

[ANdrode]

Wat betref de systeemeisen: Dit gaat (waarschijnlijk) om de hoeveelheid geheugen die nodig is doordat je paralleliseert over 56/112 cores. De hoeveelheid geheugen per core is laag (+-420mb per logische core) - waarschijnlijk is de hoeveelheid cores nodig in verband met throughput.

Bij (4K, real time) encoden heb je een trade off tussen kwaliteit, bandbreedte en throughput, het is mooi als je met nieuwe cpu extensies en cpus vrijwel geen concessies meer hoeft te doen.

[OruBLMsFrl]

Lijkt niet alleen real-time te zijn, encoder vereist altijd wat meer RAM dan de huidige lijkt het op.

https://github.com/OpenVisualCloud/SVT-AV1
RAM Requirements
The SVT-AV1 Encoder adapts to the system that is being ran on. The memory requirements depend on the number of cores the system contains, the input frame rate of the input sequence (-fps) and the look ahead distance passed to the encoder (-lad). The SVT-AV1 Encoder application will display an error if the system does not have enough RAM to support the encode prior to the start of the encode. The following table shows the minimum amount of RAM required for some standard resolutions of 10bit video per stream:

4k
8 cores = 14 GB
40 cores = 24GB

1080p
8 cores = 6 GB
40 cores = 10 GB

720p
8 cores = 4 GB
40 cores = 7 GB

Cores hierboven zijn opgegeven vCPU's. Ofwel een systeem met 16 GB RAM kan met HyperThreading/SMT uitgeschakeld 4k 10-bit HDR materiaal encoden *
Heb je zelfs met dat uitgeschakeld nog altijd meer dan 8 cores over, dan is er vast ook wel budget voor 24 GB RAM of meer **
* hoewel je er dan weinig anders meer mee zal kunnen doen tijdens het encoden door zo'n hoeveelheid geheugen in gebruik
** of je moet cores uitschakelen

[ArvidWillem]

real time av1 encoder bestaat nog niet.
Ateme (ook van AOM en mijn werkgever) heeft al een offline AV1 encoder beschikbaar voor selecte klanten, however duurt het 3+ uur voor 10min content (4k) aangezien het nog niet bepaald snel gaat. optimalisaties zijn we aan het uitvoeren...

We werken nauw samen met Intel en misschien komt er een deze dagen HW support voor zowel de encode-side and decode-side.

VLC heeft al een nightly build die AV1 aan kan, zal niet lang duren voor telefoontjes en tv's het ook kunnen.

aangezien het 100% licentie-loos is, is het meer een technologie die HEVC kan vervangen om kosten te besparen op licenties, niet op bandbreedte.

dan moet je kijken naar AV2 of inderdaad H266.

AV1 is gemaakt om "naast" HEVC te draaien, er is geen claim dat er minder bitrate gebruikt gaat worden.

[Balance]

Je kan hem ook zelf uittesten, alle code staat op GitHub. Ook zijn er 64-bits Windows-builds beschikbaar op AppVeyor, download de SvtAv1Enc.dll en SvtAv1EncApp.exe. Vervolgens in cmd naar je downloadfolder, en dan kan je de opties bekijken met SvtAv1EncApp -help.

[koenieee]

Interessant! Iemand enig idee hoe dat zit met DRM (Widevine etc.) en deze encoder? Of zijn dat twee losse zaken?

[OverSoft]

DRM zit meestal op de wrapper (bijvoorbeeld AVI of MKV) niet op de codec.

[- peter -]

Ben benieuwd naar de systeemeisen voor het afspelen. Vermoed dat er toch wel hardwarematige decoders nodig zijn om dit een beetje te kunnen gebruiken. Al zijn encoding eisen natuurlijk niet te vergelijken met het decode gedeelte.

[Reactie gewijzigd door - peter - op 23 juli 2024 04:01]

[Peetke]

VP9 viel al erg mee. Processor kan het gemakkelijk afspelen, tenzij er grote resolutie en framerate. Je hebt wel een erg dikke Xeon nodig voor encoding zo te zien:
https://www.phoronix.com/...x=Intel-SVT-AV1-Announced
1080P@60fps 10bit zit je al op een zeer recente "2nd-Generation Intel Xeon Scalable processor".

Maar vergeet niet dat in erg veel hardware van al een aantal jaar VP8 en VP9 hardwarematig ingebakken zit; silicon support zal nu nog sneller en breder zijn.

[mutley69]

De hamvraag is - kan AMD die versnelling inbouwen in de GPU/CPU's zonder gepest te worden door Intel? Zoniet is 't niet vrij - en maakt Intel zich schuldig aan anticompetitief-gedrag (opnieuw).
Waarom vind ik zo weinig laptops met ryzen cpu's in Bananenrepubliek Belgie? Is dat Intel's gedrag?

[Jack Flushell]

Zelfs de titel niet gelezen? Opensource.

[freaky]

Open source is niet perse copyright/patent/royalties vrij. Je kunt de broncode lezen.

[Jack Flushell]

Klopt. Moet je de licentie bij vermelden. Die staat in het artkel (BSD+).

[418O2]

Niet per se, maar lees de 2e alinea eens voor je gaat roeptoeteren

[The_Wounded]

Het is open-source met bsd licentie, staat in het artikel. Ze kunnen hiervoor dus hardwarematige versnelling ontwerpen als ze dat willen

[Reactie gewijzigd door The_Wounded op 23 juli 2024 04:01]

[burne]

De hamvraag is - kan AMD die versnelling inbouwen in de GPU/CPU's zonder gepest te worden door Intel?

De instructies die helpen met decoderen op de client zitten al sinds 2013-2015 gewoon in de mainstream CPU's, zowel die van Intel als die van AMD.

[Anoniem: 80910]

Maar dat is nodig om realtime te encoden neem ik aan? Zal bij de thuisgebruiker dus dan bv 30x langzamer gaan maar wel kunnen omzetten? Of lukt dat omzetten dan niet omdat je hardware niet krachtig genoeg is?

[ANdrode]

The new SVT-AV1 codec is unique in that it allows encoders to scale their performance levels based on the quality and latency requirements of the target applications — ranging from highest quality video on demand (VOD) to livestreaming use cases. The high-quality encoding and decoding in SVT-AV1 will enable developers working with visual cloud workloads to get them to market faster. The codec is optimized for video encoding on Intel Xeon Scalable processors.

De Xeon Scalable processors worden waarschijnlijk in het bijzonder genoemd omdat deze (a) de throughput hebben om livestreaming te doen en (b) nieuwe CPU extensies [voor versnelling] ondersteunen.

[latka]

En omdat ze van Intel zijn. Het zou raar zijn als een Intel project AMD epyc voor zou schrijven voor de beste performance.

[ANdrode]

Als de code het goede pad kiest [dit deed de ICC eerder niet. e.g. agner blog] dan zit daar geen bias in tussen AMD en Epyc. Sterker nog: De intel compiler presteerde beter op AMD dan de andere compilers.

Epyc heeft op dit moment geen AVX-512 support en bij de huidige generatie geen goede AVX-256 support (wordt opgebroken en duurt daardoor veel langer - maar CPU houdt wel zelfde clocks ipv de ~20% drop bij Intel).

Dit soort code is de perfecte use case voor dit soort extensies en daarom een demo voor Intel.

AMD processors kunnen dit op dit moment gewoon niet in één socket. Daarnaast zal de implementatie door andere instructies (en mogelijk minder handmatige assembly tuning) minder zijn. Of deze throughput met meer sockets (en NUMA domains) schaalt kan ik geen uitspraken doen.

[rolf1234]

Ik ben benieuwd wat de reden hierachter is. Een goede stap richting het 5g gebeuren, maar is het juist niet veel beter om het op het apparaat te decoderen? zeker als mensen series willen downloaden en onderweg verder willen kijken.. Maar ja, niet echt een kenner op dit gebied, misschien zit ik helemaal fout.

[Robbaman]

Het gaat om de encoder hier volgens mij. Het decoderen gebeurt natuurlijk op het apparaat waar bekeken wordt.

[Jory]

Het decoderen gebeurt ook op het apparaat van de gebruiker. Dit gaat enkel over het encoderen.
Als ik de aankondiging van Intel lees zie ik dingen als 50% minder data. Dat is voor een partij als Netflix natuurlijk erg interessant, want dataverkeer zal voor hen een erg grote kostenpost zijn. De isp's zullen het ook niet erg vinden.

[Anoniem: 1128097]

Zozo, mag dat van de aandeelhouders? Want opensource staat toch gelijk aan piracy?

[computerjunky]

Zie hier echt totaal de waarde niet van in.
Als je al zulke achterlijke hardware nodig heb voor 1 video streamen dan gaat dat zich toch nooit terugverdienen voor netflix om zo eborm veel in hardware te moeten investeren.
De hardeare die nodig is verdien je toch nooit terug.
Als 16 mensen 1.5 uur per dag kijken met een abbo van 15 euro dan is dat 240 euro in de maand.
Zon cpu alleen kost al duizende euro's. En dan de ram rack moederbord enz enz nog.

Vraag me af hoe ze dat winstgevend gaan krijgen

[Reactie gewijzigd door computerjunky op 23 juli 2024 04:01]

[- peter -]

Ze hoeven elke video maar 1 keer om te zetten natuurlijk. Dus dat is even wat werk en kosten, en dan kan je er de vruchten van plukken. Denk niet dat zo'n server echt een probleem is voor Netflix.

[OruBLMsFrl]

Plus, ze hoeven dit waarschijnlijk ook slechts te doen voor de top 100 meest bekeken items van het moment om een zeer interessante bandbreedte besparing te realiseren. Juist voor die meest bekeken content verdienen een paar van dat soort encoding servers zich snel terug.

Dat de rest nog niet in AV1 beschikbaar is maakt voor de gemiddelde eindgebruiker maar weinig uit, die heeft content hooguit iets sneller offline beschikbaar en in de toekomst mogelijk wat minder verbruik in de databundel als er ook smartphone ondersteuning komt.

[Nicked]

Dat wordt winstgevend omdat dit encoden maar één keer hoeft voor elke video en vervolgens bij elke keer dat de video gestreamd wordt, Netflix bandbreedte bespaart. En die besparing is Netflix heel veel geld waard.