Ik heb uiteindelijk een gebruikte server gekocht via Amazon Renewed – hij heeft dual Xeons met in totaal 56 cores. Wanneer ik naar de taakbeheerder kijk, is het gebruik tijdens encodes vrij laag, zelfs bij hoge prioriteit. Is er een extra parameter die ik aan Handbrake moet doorgeven om optimaal gebruik te maken van de extra cores?
Bedankt! Will.
Gebruik je hardware-encoding? In dat geval is de beperkende factor mogelijk je grafische kaart en niet de cpu.
Ik heb hardware-encoding expliciet uitgeschakeld – ik gebruik een RTX A4000-kaart voor Blue Iris-videostream encode/decode, wat hem flink belast. Ik heb geprobeerd via de systeeminstellingen expliciet alleen 30 cores te gebruiken – we zullen zien of dat iets uitmaakt.
Helaas geen succes. Ik heb de expliciete core-selectie teruggedraaid en op hoge prioriteit gezet – nog steeds relatief laag processorgebruik tijndens encodes.
Ik heb wat gezocht op de HandBrake-site – er lijkt geen optie te zijn om het aantal threads dat het mag gebruiken aan te geven, tenzij ik iets over het hoofd zie. Ik ga nu FFMPEG onderzoeken.
Bedankt! Will.
Ik heb handmatig het FFMPEG-profiel ingesteld om 50 cores te gebruiken - dat resulteerde in iets hogere CPU-belasting, maar tragere conversietijd.
Ik probeer de Handbrake CLI te upgraden naar 1.51 om te zien of dat de belasting verandert. Ik heb ook de tijdelijke map ingesteld op een lokale SSD in plaats van de netwerkschijf om er zeker van te zijn dat dat geen bottleneck is.
Als ik me echt ambitieus voel, zal ik kijken wat ik uit PerfMon kan halen. Bedankt! Will.
De CPU-belasting is niet veranderd, maar Handbrake is duidelijk veel sneller dan FFMPEG voor CPU-gebaseerde encodes. Ik ben geüpgraded naar de nieuwste 2.8x stabiele build van FFMPEG en 1.51 van Handbrake CLI.
Helaas is het niet zo eenvoudig, omdat het van andere factoren afhangt.
Elk encodeerprofiel kan worden opgesplitst in meerdere acties: decoderen, transcoderen of recoderen, filters (bijsnijden, interlacing, schalen, ruis, etc.).
Niet alle hardware (en onderliggende software) ondersteunt alle bewerkingen. Sommige onderdelen worden dus door de hardware uitgevoerd, andere door software. Wanneer dit gebeurt, is er ook een component van communicatie en gegevensoverdracht tussen de cpu, geheugen, grafische kaarten via de databus. Afhankelijk van hoe de bewerkingen worden uitgevoerd en in volgorde gebracht, kan de data heen en weer gaan over de bus voor een enkele bewerking, of misschien wordt het alleen uitgevoerd door de grafische kaart, alleen door de cpu, of een combinatie.
Daarom zul je zien dat het niet alleen gaat om het aantal cores, maar om welke bewerkingen moeten worden uitgevoerd, door wie, en waar die bewerkingen plaatsvinden. Als Handbrake het aantal keren dat data heen en weer stroomt tussen de cpu en GPU kan verminderen, kan dat verklaren waarom het beter presteert dan ffmpeg.
Het kunnen ook de filters zijn die verschillen tussen Handbrake- en ffmpeg-profielen. We proberen ze gelijk te houden, maar er zijn altijd kleine verschillen in hoe elke software een filter implementeert. Sommige kunnen het naar de GPU overhevelen, andere niet, weer andere gebruiken een mix van GPU en cpu voor een enkele bewerking, wat het nog trager kan maken dan een cpu-only bewerking, omdat de data tijd op de bus doorbrengt met heen en weer reizen.
Er zijn bewerkingen (zoals decoderen) die vaak efficiënter zijn op nieuwere cpu’s, omdat de tijd die nodig is om de data naar de GPU te sturen en terug een hogere latentie heeft dan de tijd die de cpu nodig zou hebben om de bewerking uit te voeren.
Wanneer je zoveel cores gebruikt, is het het beste om te kijken hoe je bewerkingen apart kunt opdelen voor cpu en GPU, en ik geloof dat ffmpeg je dat toestaat wanneer je een volledig aangepaste commandoregel maakt. Je hebt ook gedetailleerde informatie nodig over de mogelijkheden van je GPU om het te optimaliseren.
