Heeft ram snelheid invloed op video encodering?

[Verwijderd]

Mijn systeem bevat 64GB ddr4 ram (8 x 8GB dimms, die 'maar' draaien op 2.133Mhz). Maar wel quad channel mode.

Naar mijn eigen zeggen heb ik het gevoel dat video encodering op mijn pc wel aardig lang duurt, ook al heb ik een 6 core processor welke is overgeklokt naar 4.2Ghz.

Nu las ik op sommige websites dat geheugensnelheid van invloed zou zijn op video encodering. Echter, ik snap niet helemaal hoe geheugensnelheid in verband zou moeten worden gebracht met video encodering dat puur gedaan wordt door de processor. De snelheid van het opslagmedium maakt in dit geval ook niet veel uit, immers uit doelbestand is meestal maar een paar GB groot. Maar, in hoeverre speelt de snelheid van het geheugen eigenlijk mee? Mijn veronderstelling was altijd dat geheugen altijd, in welke vorm dan ook, vele malen sneller is dan de processor of welk opslagmedium dan ook.

Alhoewel ik naar onderstaande resultaten van CrystalDiskMark kijk, uitgevoerd op de Ramdisk, begin ik ook hier weer aan te twijfelen. Eerlijk gezegd zou ik het niet weten of wat ik hier zie van invloed is op de snelheid van video encodering. Ik hoor graag jullie mening.

[TERW_DAN]

Je CPU doet bewerkingen, maar moet deze natuurlijk wel ergens vandaan lezen en ergens naartoe schrijven. En daar komt je geheugen om de hoek kijken. Dus traag geheugen kan wel een belemmering gaan vormen voor videoencoding. Hoeveel is lastig te zeggen, hangt van het programma af, en hoeveel bandbreedte je CPU evt tekort komt (al kom je met Quad Channel al een heel eind).

Simpele manier om het te testen,. Benchmark het, klok je geheugen 1 stapje terug en benchmark nog een keer. Zit daar dan een groot verschil in, dan kan het uit gaan maken als je het geheugen sneller klokt. Maakt dat niets uit, dan zal sneller niet heel veel toe gaan voegen.

[Verwijderd]

Met 'benchmarken' bedoel je in dit geval dus het encoderen van dezelfde video met dezelfde settings en dan kijken of een lagere geheugenkloksnelheid effect heeft op de encoderingsnelheid.

Dat is inderdaad wel een goed idee. Want ik denk niet dat de processor te licht is voor deze taak. 6 cores, 12 threads, overgeklokt naar een stabiele 4,2Ghz op 1,25v, met een Noctua tower cooler wordt ie weliswaar rond de 80 graden tijdens het coderen, maar dat is nog binnen de marge.

[White Feather]

Verwijderd schreef op vrijdag 21 juni 2019 @ 23:29:
Mijn veronderstelling was altijd dat geheugen altijd, in welke vorm dan ook, vele malen sneller is dan de processor

Een klein plaatje met daarin de snelheid van het “interne geheugen” van je cpu, de level 1 datacaches, de level 2 en 3 en het Ramgeheugen:



In cijfers voor de 7900X (quad core geheugencontroller, dus Ram is nog erg snel in verhouding:

Ram: 70 GB/s
Level 3 cache: 464 GB/s (6,6x sneller dan Ram)
Level 2 cache: 985 GB/s (14x sneller dan Ram)
L1 datacache: 2220 GB/s (31,7x sneller dan Ram)

Ram is voor een cpu dus supertraag geheugen. Het grote voordeel is dat het ook erg groot is, het wordt namelijk gerekend in GB, level 1 cache is zo’n 32 KB, level 2 zo’n 256/512 KB, level 3 tot 16 MB op socket 1151 V2 en enkele tientallen op socket 2066.

Hier worden een aantal ramsnelheden vergeleken. Er zit maximaal zo’n 20% tussen 2133 en 4400-geheugen.
https://www.tomshardware....est-ram-speed,5951-4.html (is wel gebaseerd op Dual channel socket 1151)

[Verwijderd]

Zo, dat is een wereld van verschil. De onwetendheid over dit geheel, daar kijk ik echt wel even van op.
Aldus de fabrikant van mijn moederbord ondersteunt het bord het volgende geheugen:

8 x DIMM, Max. 64GB, DDR4 3200(O.C.)/3000(O.C.)/2800(O.C.)/2666(O.C.)/2400(O.C.)/2133 MHz Non-ECC, Un-buffered Memory
Quad Channel Memory Architecture

Dus maximaal DDR4 3200, en ik heb nu 2133. Ik denk niet dat dat zo heel veel verschil uitmaakt. Of ik moet al een ander moederbord vinden waarop de i7 5820k past (socket 2011-3) en ook sneller (en meer) geheugen ondersteunt. Of gewoon de gehele set verkopen en een compleet nieuwe set kopen, maar dat loopt aardig in de papieren. Maar met bv. de AMD Ryzen Threadripper 1950X heb je wel een beest van een CPU voor een 'schappelijke' prijs.

Keuzes keuzes keuzes. :-)

[ Voor 4% gewijzigd door Verwijderd op 22-06-2019 17:25 ]

[maratropa]

Je encode in hevc/h256 of h264? Dat zijn cpu heavy formaten.

Wat vind je traag?

je kunt ook kijken of je iets met een gpu encoder kunt doen..

[Nox]

Verwijderd schreef op zaterdag 22 juni 2019 @ 17:25:
Zo, dat is een wereld van verschil. De onwetendheid over dit geheel, daar kijk ik echt wel even van op.
Aldus de fabrikant van mijn moederbord ondersteunt het bord het volgende geheugen:

8 x DIMM, Max. 64GB, DDR4 3200(O.C.)/3000(O.C.)/2800(O.C.)/2666(O.C.)/2400(O.C.)/2133 MHz Non-ECC, Un-buffered Memory
Quad Channel Memory Architecture

Dus maximaal DDR4 3200, en ik heb nu 2133. Ik denk niet dat dat zo heel veel verschil uitmaakt. Of ik moet al een ander moederbord vinden waarop de i7 5820k past (socket 2011-3) en ook sneller (en meer) geheugen ondersteunt. Of gewoon de gehele set verkopen en een compleet nieuwe set kopen, maar dat loopt aardig in de papieren. Maar met bv. de AMD Ryzen Threadripper 1950X heb je wel een beest van een CPU voor een 'schappelijke' prijs.

Keuzes keuzes keuzes. :-)

Kijk dan naar de 3950X, stuk goedkoper.

Probeer ook eens te kijken wat er gebeurt als je naar 4x8GB gaat, dat heeft vaak nog wel effect op je geheugen. Kan je misschien naar 2666 of 2400. 32GB is zat voor encoding, je hebt niet een enorme bak nodig of wel?

[Verwijderd]

maratropa schreef op zaterdag 22 juni 2019 @ 20:43:
Je encode in hevc/h256 of h264? Dat zijn cpu heavy formaten.

Wat vind je traag?

je kunt ook kijken of je iets met een gpu encoder kunt doen..

h264, want de helft van de filmpjes zijn bestemd voor YouTube, en YouTube ondersteunt nog geen h265. Bovendien h265 kost nog meer tijd met encoderen.

De video editor maakt al gebruik van gpu acceleratie, en ja, wat is traag? Een 1080p video op 60fps die een klein uurtje duurt kost ongeveer 45 minuten encoderings tijd.

Nox schreef op zaterdag 22 juni 2019 @ 23:37:
[...]
Kijk dan naar de 3950X, stuk goedkoper.

Probeer ook eens te kijken wat er gebeurt als je naar 4x8GB gaat, dat heeft vaak nog wel effect op je geheugen. Kan je misschien naar 2666 of 2400. 32GB is zat voor encoding, je hebt niet een enorme bak nodig of wel?

Dat is een optie, maar dan zou ik inderdaad compleet ander geheugen moeten kopen en deze 2133Mhz 64GB er uit moeten halen. Ik denk dat de gehele set, de 64GB ram, de processor en het moederbord, die verder heel goed samengaan beter te verkopen zijn als een set.

Misschien is het nog optioneel om het geheugen te overklokken

[ Voor 41% gewijzigd door Verwijderd op 23-06-2019 19:05 ]

[maratropa]

@Verwijderd welke video editor? Vaak is gpu versnelling in edit apps het versnellen van effecten en beeldbewerkingen, niet het encoden bij exporteren. Welke edit app is het en welke gpu heb je?

[Osiris]

Verwijderd schreef op zondag 23 juni 2019 @ 18:58:
[...]

h264, want de helft van de filmpjes zijn bestemd voor YouTube, en YouTube ondersteunt nog geen h265. Bovendien h265 kost nog meer tijd met encoderen.

Bedenk tevens goed dat je H.264-settings (of beter: je x264-settings waarschijnlijk ) heel veel invloed heeft op je encodeer-snelheid. Je kunt immers kiezen voor aan de ene kant van het spectrum de veryslow preset met aan de andere kant van het spectrum de ultrafast preset. Omgekeerd evenredig met de encodeer-snelheid is dan de uiteindelijke bestandsgrootte en daarmee je codeer-efficiëntie

Voorbeeldjes op het internet genoeg:

https://write.corbpie.com...code-speed-and-file-size/

http://blogs.motokado.com...mparison-of-x264-presets/

Je kunt je wellicht ook voorstellen dat de ultrafast-preset méér nut heeft bij heel snel RAM dan de veryslow-preset. Immers, de veryslow moet moeilijkere berekeningen uitvoeren, terwijl de ultrafast waarschijnlijk meer data heen en weer moet pompen. Nu weet ik dit niet zeker, dus zou ook best interessant kunnen zijn om de grafiekjes zoals in de voorbeeldpagina's hierboven gepresenteerd uit te voeren bij verschillende RAM-kloksnelheden

[ Voor 4% gewijzigd door Osiris op 23-06-2019 20:23 ]

[Nox]

Verwijderd schreef op zondag 23 juni 2019 @ 18:58:
[...]

h264, want de helft van de filmpjes zijn bestemd voor YouTube, en YouTube ondersteunt nog geen h265. Bovendien h265 kost nog meer tijd met encoderen.

De video editor maakt al gebruik van gpu acceleratie, en ja, wat is traag? Een 1080p video op 60fps die een klein uurtje duurt kost ongeveer 45 minuten encoderings tijd.

[...]

Dat is een optie, maar dan zou ik inderdaad compleet ander geheugen moeten kopen en deze 2133Mhz 64GB er uit moeten halen. Ik denk dat de gehele set, de 64GB ram, de processor en het moederbord, die verder heel goed samengaan beter te verkopen zijn als een set.

Misschien is het nog optioneel om het geheugen te overklokken

[YouTube: Newegg DIY Garage: ASUS X99 Overclocking Guide - Manual & Automatic]

Een 1950x heeft ook ddr4 nodig mocht je overigens echt 64GB nodig hebben is het overigens wel verstandig te kijken naar TR, ik weet niet of de x570 bordjes lekker werken met 64GB, even opzoeken dus.

[computerjunky]

YouTube: Is Fast RAM A Waste? Unleashing the Core i9-9900K with DDR4-4000


CPU > GPU met de juiste software > SSD naar SSD opslag > ram

[Verwijderd]

Zonder verdere testen te doen vraag ik me af OF mijn geheugen wel de beperkende factor is.

Wat namelijk opvallend is, is dat met Handbrake mijn CPU wel tot 100% belast wordt, en dan draait ie op 4,2Ghz alle 6 cores. Dus hoe kan dat dan met 2.133Mhz geheugen? De computer is dan ook bijna niet te bedienen omdat Handbrake zowat 99% van de CPU in beslag neemt.

(Tip overigens, je kunt via de task manager -> tab 'details' -> programma -> rechtermuis > optie 'set affinity' één of meerdere cores uitschakelen voor dat programma, of voor elk programma dan ook. Kan handig zijn als je nog iets anders wil doen op de pc, maar een applicatie vreet al je CPU kracht op).

[maratropa]

@Verwijderd ben nog steeds benieuwd naar alle specs van je pc en welk edit programma het is

[Verwijderd]

maratropa schreef op vrijdag 28 juni 2019 @ 20:53:
@Verwijderd ben nog steeds benieuwd naar alle specs van je pc en welk edit programma het is

Had ik dat niet genoemd dan? X99 platform, een intel i7-5820k processor, 64GB ram en een GTX1080ti video kaart. Alle overige is volgens mij niet zo van belang voor wat betreft encodering.

Ik maak gebruik van 2 programma's.

Voor puur comprimeren is het Handbrake
Voor video editen is het Wondershare Filmora, echter dit programma comprimeert bij lange na niet zo goed als Handbrake.

[White Feather]

Verwijderd schreef op vrijdag 28 juni 2019 @ 20:48:
Zonder verdere testen te doen vraag ik me af OF mijn geheugen wel de beperkende factor is.

Wat namelijk opvallend is, is dat met Handbrake mijn CPU wel tot 100% belast wordt, en dan draait ie op 4,2Ghz alle 6 cores. Dus hoe kan dat dan met 2.133Mhz geheugen? De computer is dan ook bijna niet te bedienen omdat Handbrake zowat 99% van de CPU in beslag neemt.

(Tip overigens, je kunt via de task manager -> tab 'details' -> programma -> rechtermuis > optie 'set affinity' één of meerdere cores uitschakelen voor dat programma, of voor elk programma dan ook. Kan handig zijn als je nog iets anders wil doen op de pc, maar een applicatie vreet al je CPU kracht op).

Dat je processor op 100% staat wil niet zeggen dat hij 100% van zijn snelheid haalt. Het kan zijn dat hij soms op het geheugen staat te wachten, wat bij sneller geheugen minder zou zijn. Maar dat is relatief weinig.

Dat je niet meer kunt werken komt omdat Handbrake op te hoge prio staat. Dat kun je in het programma zelf aanpassen. Dat is een eenmalige actief en handiger dan de affinity aanpassen. Als je Photoshop bijvoorbeeld gebruikt, dan zet je Handbrake wat lager en dan werkt Photoshop volgas, en wat PS niet nodig heeft, gebruikt Handbrake.

[Verwijderd]

White Feather schreef op vrijdag 28 juni 2019 @ 21:50:
Dat je processor op 100% staat wil niet zeggen dat hij 100% van zijn snelheid haalt. Het kan zijn dat hij soms op het geheugen staat te wachten, wat bij sneller geheugen minder zou zijn. Maar dat is relatief weinig.

Dit klinkt een beetje tegenstrijdig als je zegt dat de processor op het geheugen staat te wachten maar ondanks dat wel 100% 'belast' blijft. Ik zou nog steeds een test doen.

Ik heb nu mijn CPU op een OC staan van 4.2Ghz. Ik zal eens een korte beeldscherm opname maken met de screenrecorder (2 a 3 minuten) en vervolgens dit bestand 2x coderen, maar op verschillende CPU snelheden.

Ik laat de resultaten hieronder weten.

[Verwijderd]

Je kunt proberen je geheugen op 2400 Mhz en 2666 Mhz te draaien met wat meer voltage.
1,35V is geen probleem voor DDR4

[White Feather]

Verwijderd schreef op vrijdag 28 juni 2019 @ 21:55:
[...]

Dit klinkt een beetje tegenstrijdig als je zegt dat de processor op het geheugen staat te wachten maar ondanks dat wel 100% 'belast' blijft. Ik zou nog steeds een test doen.

Ik heb nu mijn CPU op een OC staan van 4.2Ghz. Ik zal eens een korte beeldscherm opname maken met de screenrecorder (2 a 3 minuten) en vervolgens dit bestand 2x coderen, maar op verschillende CPU snelheden.

Ik laat de resultaten hieronder weten.

Stel dat je een huis bouwt en je wacht op bakstenen om te bouwen, dan kun je pas gaan zitten (idle) als je geen bakstenen meer hebt (dus minder dan 100% bezig).
Als je er 2 seconden over doet om te gaan zitten en je iedere keer maar 1 seconde hoeft te wachten, heb je dus nooit kunnen zitten, maar heb je wel x keer die seconde moeten wachten. Je had dus meer kunnen doen als je niet had moeten wachten, maar je hebt nog steeds 0% van de tijd kunnen zitten, dus 100% bezig geweest.

Stel dat je 99 seconden over het verwerken van 1 baksteen doet, dan ben je dus 99% efficiënt geweest (99 van de 99+1 seconden) de meerwaarde van het sneller aangeven van de baksteen is dus erg klein.

Als je 4 seconden doet over het verwerken van de baksteen, ben je dus maar 80% efficiënt geweest (4 van de 4+1 seconden).

In beide gevallen staat je cpu op 100%, maar in geval 2 is er nog een flinke verbetering te halen door sneller geheugen.

Jij hebt echter al quad channel geheugen, 4 kanalen dus versus de gebruikelijke 2.
Daardoor is het qua pure data doorvoer dus al veel minder van belang hoe snel het geheugen is, je hebt immers in de basis al 2x zoveel bandbreedte.

Quad versus dual channel geheugen: http://www.pcworld.com/ar...heir-performance.amp.html

Maakt dus geen jota uit, alleen bij 7Zip maakt het uit. Er is bij de rest blijkbaar genoeg bandbreedte met de gebruikte geheugrnsnelheid.

Alvast even een opmerking bij de benchmark die je gaat doen. Als je je cpu minder snel gaat later draaien, zou je processor theoretisch verhoudingsgewijs de data sneller moeten krijgen en dus per MHz sneller moeten encoderen.
Het encode-programma is echter niet het enige dat draait, alle overige programma's hebben opeens meer cpu -tijd nodig voor hetzelfde werk.

[Verwijderd]

Test gedaan. Ik heb met mijn Samsung S9 telefoon een 4K opname gemaakt van 60 fps die ongeveer 2 minuten duurde. Ik heb em gemakshalve maar op mijn monitor gericht.

Dit is het originele bestand:



In Handbrake heb ik dezelfde settings gebruikt:
- Codec : H264 (x264)
- Constant Frame Rate
- Frame Rate : 60 FPS
- Slider encoding speed : Medium
- Slider encoding settings: 22
- Audio : Mp3 128Kbit/s

Processor overgeklokt naar 4,2 Ghz, encodeerde dit bestand in : 4:56 min
Processor standaard op 3,3 Ghz, encodeerde dit bestand in : 7:06 min

Eindelijk door dezelfde settings te gebruiken werden beide bestanden nagenoeg even groot:


Conclusie, de hierboven genoemde suggestie dat een lager geklokte processor sneller zou encoderen is dus niet waar. Ik heb in het bijzonder aandacht geschonken aan de achtergrond processen, dat deze hetzelfde zouden zijn. Je hebt altijd wel een minuscule afwijking maar het verschil kan nooit bijzonder groot zijn geweest. Het lijkt er dus op dat mijn ram de processor op 4,2Ghz wel kan bijbenen.