Beiträge von Inspector42

    Seitdem Intel mit QuickSync dedizierte Hardware für das Dekodieren von Video eingeführt hat, hat sich mir die Frage gestellt, was das für Video Editing in Final Cut Pro bedeutet, im besonderen mit den AMD Grafikkarten ab Polaris.

    Nachdem ich viel im Netz gesucht habe, ohne eine klare Antwort zu finden, habe ich mal einen kleinen Selbstversuch gestartet.


    Dabei haben mich vor allem zwei Dinge interessiert:

    1. Nutzt FCPX (10.4.8) eigentlich das volle Potenzial meiner Grafikkarten AMD RX-570 ? Schliesslich wurde die Grafik-Engine gerade auf Metal umgestellt
    2. Kann ich mit meinem betagten System noch halbwegs vernünftig in 4K arbeiten ?

    Da ich Videos nur als Hobby betreibe, war mir zunächst wichtig, mal die Grenzen des vernünftigen Arbeitens auszuloten.

    Daher habe ich mal folgendes Projekt in FCPX 10.4.8 unter macOS 10.15.6 aufgesetzt, welches nur Clips mit h.264 und h.265 nach dem Import beinhaltet und einige Effekte.



    Hauptakteure in diesem Versuch sind die IvyBridge CPU i5-3570K mit 4,3GHz und 16GB RAM und die Sapphire RX-570 Nitro+ mit 4GB RAM (angebunden über 8 PCI3.0 Lanes des Prozessors)

    Die Mediendaten werden von einer Samsung 970-EVO SSD gelesen und auch dorthin geschrieben. Sie ist über PCI3.0 mit 4 Lanes direkt an den Prozessor angebunden und liefert mehr als ausreichend Bandbreite.


    Gemessen habe ich jeweils die Last beim Abspielen des Projektes im Viewer. Dabei sei noch zu sagen, dass ich das Background Rendering abgeschaltet habe, um das Rendern während des Abspielens von der Graphikkarten zu erzwingen.

    Ich habe dann in zwei Stufen zunächst den langen Basisclip in ProRes transkodiert (create optimized media) und dann auch den ersten Clip in der Mitte.

    Alle Daten habe ich in der folgenden Tabelle zusammengefasst.



    Zunächst werden die Original-Clips mit dem Hardware Decoder der RX-570 dekodiert, was ich mit AMD GPU Menue überprüft habe. Das erklärt auch die relativ niedrige Last auf der CPU.

    Man sieht ebenfalls sehr schön, dass mit der steigenden Komplexität die Last der RX-570 für das Rendern hochgeht.

    Die Überraschung kam dann im Schritt 2. Mit dem Vorhandensein von ProRes "optimized media" für den Basis Clip steigt die CPU Last an. Die Last auf der RX-570 sinkt nur geringfügig.

    Noch deutlicher wird der Effekt, wenn auch der mittlere Clip eine ProRes Version im Projekt hat.

    Man sieht ebenfalls, dass der Clip mit doppelter Bildrate und 10Bit keinen Einbruch erzeugt, sowohl der Hardware-Decoder als auch ProRes scheinen da sehr effizient zu sein.

    Als Referenz habe ich dann mal das ganze Projekt offline gerendert und siehe da, jetzt hat wie erwartet praktisch nur noch die CPU zu tun - dekodieren der gerederten ProRes Caches.

    In der Grafik, die nur fokussiert auf die Phasen A, B und C erstellt wurde, wird das nochmal deutlicher.

    Beim Offline-Rendern läuft übrigens sowohl der i5-3570K als auch die RX-570 auf praktisch 100%, inkl hardware decoder - so toll es sein.



    Hardware encoding funktioniert übrigens auch, allerdings habe ich noch keine Qualitätsvergleiche angestellt und da ich das offline Rendering auch zur Not über Nacht laufen lassen kann, habe ich mir die Zeit für Benchmarks hier mal gespart.


    Das Fazit für mich ist nun, dass der Einbau einer potenten Grafikkarte die Schwäche meines in die Jahre gekommenen Prozessors für den Videoschnitt zu einem ausreichende Grad kompensieren kann und dass "optimized media" in Form von ProRes mit potentestem Hardware-Dekoder eher kontraproduktiv zu sein scheint. Das gilt zumindest für die Performance beim Editieren. Da meine Videoquellen aber ohnehin kein ProRes oder Raw Format erzeugen, ergibt sich auch kein zusätzlicher Qualitätsverlust.


    Vermutlich sieht das Ganze anders aus, wenn man noch intensiver Filter und Effekte einsetzt oder gar Color Grading anwirft, bei dem dann praktisch jeder einzelne Frame durch die Mangel gedreht wird.

    Ich für meinen Teil bin erstmal zufrieden und kann vermutlich noch ein bisschen mit meinem System leben.

    DRM ist zwar relativ weit unten auf meiner Prioritätenliste, aber irgendwie nervt es, nicht zu wissen, warum etwas nicht funktioniert.

    Der Verdacht, dass es mit der Board-ID und dem Fehlen dieser in Teilbereichen zu tun haben könnte, hat sich bisher nicht bestätigt.

    dmidecode zeigt überall, wo Board-ID auftaucht, die richtige vom iMacPro. Auch sonst konnte ich keine Lücken in den PlatformInfo relevanten Bereichen ausmachen.

    Offenbar tut OC mit den Angaben zu PlatformInfo „Generic“ und „Automatic“ alles notwendige.


    Die Installation des letzten Supplementary Updates hat nichts an der DRM Problematik geändert und die Verwendung von OC 0.6.0 inkl. aller neuen Versionen der Kext aus dem August Release von Acidanthera hat auch keine Verbesserung gebracht.


    Das Löschen aller User-Caches unter ~/Library/Caches hat auch keine Wirkung gezeigt.


    Ohne ein besseres Verständnis über die DRM Funktion hinter den Kulissen bleibt noch eine komplette Neuinstallation. Im Netz findet sich zu DRM nichts brauchbares.


    Ich bleibe weiter am Ball und berichte, wenn es was neues gibt.

    Ja, den Guide kenne ich. Mit 10.15.5 hat die Kombination aus iMacPro1,1 und ausgeschalteter IGPU nach diesem Guide super funktioniert. DRM funktioniert seit 10.15.6 mit gleicher Konfiguration nicht mehr.


    greecedrummer: Hatte mir OpenCore-Configurator schon mal angeschaut, aber aufgrund der Warnungen bisher nicht genutzt. Mit dem Clover Configurator vom gleichen Author habe ich nur gute Erfahrung gemacht.

    Bzgl. der Properties fehlt mir aktuell noch die Übersicht, was zwischen DataHub, NVRAM und SMBIOS primär ist und was nur während des Hochfahrens kopiert wird. Das ist leider in der OpenCore Beschreibung nicht eindeutig und bei Clover gab es da nur einen Block für SMBIOS.


    Update: griven hat hier schon mal einen Teilaspekt beleucht, also werde ich mich da mal weiter reingraben

    Vielen Dank greecedrummer, das Tool kannte ich noch nicht, hilft aber tatsächlich, Ordnung ist die Sache zu bringen.

    Leider funktioniert DRM mit den nightly builds von gestern (opencore, lilu, virtualsmc, whatevergreen) genausowenig 😩


    Bezüglich der AppleID hatte ich bisher keine größeren "Screw-Ups" mit vermeintlich neuen Macs, hatte bis vor 2 Monaten allerdings auch noch clover laufen und penible alle Felder im SMBIOS setup ausgefüllt und die auch immer fleißig in alle Testkonfigurationen kopiert. OC benutzt ja im Generic-Teil nicht alle Daten (z.B. fehlt ein Eintrag für die Board-ID) - ich bin bisher davon ausgegangen, dass die automatisch von OC abgeleitet werden, da sie redundant sind.

    Das Hinzufügen von device-properties sollte auch keine solchen Nebenwirkungen haben 🤔, zumal ich ja schon das iMac Pro1,1 Profile eingestellt hatte und via shiki-id die dazu passende board-id injiziert hatte. Aber ich bin weit entfernt davon, alle Zusammenhänge zu verstehen.


    Naja, der nächste offizielle release von acidanthera steht ja für Anfang August an und so dringend brauche ich DRM auf meinem Hackintosh nicht, ich hab auch noch offizielle Apple Hardware. Wenn es mir wieder in den Fingern juckt, setze ich mich vielleicht vorher nochmal dran.

    Update: Habe mich vor dem Einspielen von nightly builds nochmal bei Acidenthera auf Github und im insanelyMac - WEG support thread umgeschaut.

    Mehr aus Interesse habe ich mal die Erfahrung von real3x nachvollzogen und bei den device properties für die Graphikkarte shikigva|number|80 und shiki-id|string|Mac-7BA5B2D9E42DDD94 eingetragen. Nun geht das Abspielen in der TV+ App, aber Amazon prime auf Safari geht immer noch nicht.

    Was mich noch mehr verwundert ist, dass ich mich erneut mit meiner Apple-ID anmelden musste und mein iPhone behauptete, dass ich mich mit einem neuen Mac anmelden wollte.

    Vielleicht ist da doch noch irgendwas in meiner Konfiguration verschoben - werde mal weiter forschen und dann berichten.

    Das mit dem „Hackintosh-Geschäft“ war nicht wirklich im Sinne einer kommerziellen Nutzung gemeint, daher auch in Anführungsstrichen😉

    Mir war einfach die original Hardware entweder zu teuer oder zu unflexibel.

    Ich baue meine eigene Hardware schon seit den 80ern selber, damals noch mit Z80, aber das ist eine andere Geschichte.


    Auf jeden Fall schon mal Danke für den Hinweis. Ich muss mich bei den nightly builds noch einarbeiten, hatte bisher das selber Kompilieren wegen potentiell zusätzlichen Fehlerquellen durch mein Unwissen immer vermieden.

    Aber irgendwann ist immer das erste Mal.

    Moin zusammen,


    ich bin neu in diesem Forum, aber schon seit 2012 im "Hackintosh-Geschäft". Wie man meinem Profil entnehmen kann, ist meine Hardware zumindest im Kern auch noch aus der Zeit.

    Nach einer gründlichen Überarbeitung der gesamten Konfiguration inkl. einiger Hardwareanpassungen hatte ich bis letzte Woche ein rundum stabiles System, bei dem auch alle Funktionen bis auf kleine Unzulänglichkeiten (z.B. die EJ168 Controller spielen nur mit USB3 Geräten) funktionierten. Dazu habe ich am Ende das iMacPro1,1 Profil verwendet und CPUFriend für das PowerManagement der CPU konfiguriert, mit dem sowohl Video Encoding mit HW Beschleunigung, DRM und sleep/wake funktionierten. Ansonsten läuft alles unter OpenCore 0.5.9 mit den zum selben Zeitpunkt freigegebenen Erweiterungen von Acidanthera (Lilu, VirtualSMC, Whatevergreen und AppleALC).

    DRM lief unter 10.15.5 ohne Probleme, ich konnte alle Spielarten von FairPlay nutzen. Seit ich letzte Woche auf 10.5.6 aktualisiert habe (was übrigens wie von anderen auch berichtet "Mac like" ohne Komplikationen ablief), streikt FairPlay sowohl in Safari als auch in der AppleTV App. in der Apple TV App funktionieren weder bereits heruntergeladenen Filmen noch Streaming :-( , Ton wird abgespielt, aber das Bild zeigt entweder nur schwarz oder rote oder grüne Streifen oder Klötze. Lediglich das FairPlay1 Testvideo vom Dortania-Guide läuft noch.


    Interessanter Weise funktioniert DRM nun auch nicht mehr, wenn ich von der Backup-Partition mit 10.5.5 starte ...

    Hardware Video De-/Encoding funktioniert weiterhin (bis auf die bekannten Animositäten von FCPX und Compressor) und Hackintool zeigt auch "VDA Decoder fully supported" an.


    Habe sowohl den Pre-Linked Kernel als auch den dyld shared cache aktualisiert und den Rechner de-authorisiert und wieder neu autorisiert und im Syslog kann ich auch keine brauchbaren Hinweise ausmachen.

    Entweder hat der neue AMD Treiber jetzt eine andere Konfiguration oder es hängen noch alte Token oder Schlüssel in irgendeinem Cache, die nicht mehr zum aktualisierten System passen.


    Hat das Phänomen sonst noch jemand ? Habe bisher dazu noch nichts gefunden, auch in anderen Foren nicht. Habe mal meine OC config angehängt, lediglich Seriennummern und MAC-Addresse aus dem Eintrag "ROM" entfernt