Pula Reup, QSV Speed Optimierung

Das zweite Pula Video kürzte ich um eine weitere Minute. Wartezeit an Kassen interessiert niemanden. Ich schaute aber weiter nach Optionen, wie ich den Workflow verbessern kann. DaVinci ist während Encodings blockiert.

In der Hinsicht macht der Media Encoder bei Adobe doch etwas Sinn. Ein separates Programm, was nur für den Output zuständig ist.

Ich schaute wieder nach aktuellen PC Preisen und Chips. Das kleinste Gehäuse – ASRock Deskmini B660 war vor einigen Wochen für wohl €179 im Angebot. Das Ding würde mit einem i5 gut funktionieren, nur sind mir €250 dafür zu viel. In Q2’22 sollte noch ein i3 12300HL herauskommen, der komischerweise auch 2 Videoengines besitzt. Online fand ich den noch bei keinem Händler. In Sachen Watt wäre er für das Minigehäuse besser geeignet, weil es im B660 nur max. 75W für die CPU gibt. Wenn die hohen Strompreise nicht wären, käme eine GPU in Frage. Allerdings haben die i3 CPUs noch weniger GPU Power – 80 Units beim i5 ist schon mickrig. So richtig lohnt sich das alles nicht.

Nach alle dem Recherchieren ging’s etwas an die Arbeit. Ich fand Get-MediaInfo, was einige Scripte vereinfachen könnte. Bisher machte ich HW Decoding per vordefinierten Camera-Settings. Für bessere Stabilität in gemischten Sources wurden die Sachen aus den Metadaten heraus gelesen. Beides hat seine Berechtigung. Beim concat Job sollte ja QuickSync nicht genutzt werden.

Es stehen massig Proxy-Generierungen an. Per -vf "vpp_qsv=deinterlace=0:scale_mode=0:w=640:h=360:async_depth=0" ging’s nun mit 4×85 fps. Warum hatte ich da s nicht vorher probiert – immer nur 1-8… Async über 0 brachte eine Drosselung. Man muss auch alle Decoder zugleich aufrufen, weil die CPU sonst irgendwie die Last verteilt und QSV Cores nur zu 75% nutzt. Wie ich das besser, als über einen Sleep in meinem Powershell Script steuern kann, blieb unklar. Leider nutzen die QSV Decoder nicht dynamisch alle Ressourcen. Wenn also der erste Encode fertig wird, beschleunigt der Rest nicht. Bei 4 Videos mit H.264 jedenfalls brachte Sleep 0.0 pro Terminal Window die meisten fps, bei 5 Videos (mit einem HEVC Decoding) Sleep 0.1+ – dann 80fps+ x 5 (vor meiner Mediainfo Abfrage). Decoding ist das Bottleneck – klar bei 5x4K60.

H.265 läuft separat und die 80fps 4K->360p werden damit extra geliefert. Bei 2 HEVC vielleicht sogar 2×80? Schon erstaunlich, was mit 17W heutzutage so alles geht – quasi 50MByte/s mit 5x4K60 Video-Transcoding. Mit 2-3facher Performance hätte ich dann die USB HDD mit den 100-150MByte als Bottleneck.

In Intels Meteor Lake (Gen 14) sollen die QuickSync Cores außerhalb der CPU angeordnet werden. Dann das Ganze nächstes Jahre oder später, sodass ich auf 13 Gen gar nicht so scharf bin, wenn da Iris/Xe noch keinen AV1 Encoder hat. Es bleibt also vorerst bei Proxies mit inzwischen ausreichend schneller Parallel-Erstellung und der zu guten 2TB 980 Pro + eventueller 2.5“ SATA SSD.

Kleiner Fortschritt in Scripten heute, um auf der Mini Hardware des HP 250 G8 das Maximum heraus zu holen. Ein Script für die Proxy-Erstellung aller Videos muss dann eben eine Weile laufen, wenn ich schlafe. Mit 1.3x Realtime tagsüber zu langsam.

Mit einem Listenjob-Script (Invoke-CommandOnList), sollte die Sache dann gehen. Alles muss ja in Gruppen gebatcht werden – 5 Videos max. parallel. Jetzt also Festplatten aufräumen und Arbeitslisten erzeugen. Wird schon.