Neue Apple Mac mini und MacBook Pro Modelle mit M2, M2 Pro und M2 Max

[Frank Glencairn]

Nicht nur das, es geht viel schneller.

Für gewöhnlich brauch ich ja verschiedene Formate, verschiedene Sprachen, mit und ohne Untertitel und auch verschiedene Codecs.
Wenn ich jetzt jedes mal jeden Effekt, jede Noise Reduction, zig Nodes mit werweißwasallem etc. für jedes Format aufs neue durchrechnen muß macht das halt überhaupt keinen Sinn.

Von nem Masterfile flutscht das ganz anders. Da brauch ich dann bloß die Untertitel umschalten, oder verschiedenen Tonspuren aktivieren.

[iasi]

@iasi
Ein Master ist doch immer sinnvoll, auch praktisch, weil aus dem Master kannst du dann ja zig verschiedene Delivery Formate raus rendern. Und bist dabei auf der sichereren Seite, weil das Master bleibt dasselbe.
Das schliesst eventuelle Render Fehler viel eher aus.
Zumindest nach meiner Logik.

Aber mit Dcp hab ich natürlich keine Erfahrung.
Gruss Boris

Du müsstest schon ein Lossless-Format haben, um Generationenverluste auszuschließen.

Es ändert aber auch nichts daran, dass man bei Änderungen am Projekt dann doch auch wieder in ein Master exportieren müsste.
Die Tester hatten bis zum letzten Tag am Projekt gearbeitet.
Letztlich spart es dann sogar einen Arbeitsschritt, wenn man direkt in ein DCP exportiert.

[iasi]

Nicht nur das, es geht viel schneller.

Für gewöhnlich brauch ich ja verschiedene Formate, verschiedene Sprachen, mit und ohne Untertitel und auch verschiedene Codecs.
Wenn ich jetzt jedes mal jeden Effekt, jede Noise Reduction, zig Nodes mit werweißwasallem etc. für jedes Format aufs neue durchrechnen muß macht das halt überhaupt keinen Sinn.

Von nem Masterfile flutscht das ganz anders. Da brauch ich dann bloß die Untertitel umschalten, oder verschiedenen Tonspuren aktivieren.

Wenn ich ein DCP brauche und bis zum letzten Tag am Projekt feile, brauch ich doch nicht den Umweg über ein Masterfile.

[Darth Schneider]

@iasi
Ich sehe keinen Grund
Ich fahre meistens mit einem ProRes 4:2:2 HQ, Master, das genügt für das was ich filme, mit der 4K Pocket und mit der S5.

Das ist verlustfrei genug um es ganz locker noch einmal zu wandeln…
Und der einzig massgebliche Schaden beim wandeln entsteht doch so oder so bei h265/h264/mp4 und so weiter.
Und bis im letzten Moment daran feilen kann ich doch auch so.
Ich denke du suchst nach einem Schatz den es gar nicht gibt.
Und äh, mir musst das ja nicht glauben, aber glaub es doch einfach dem Frank.;)
Gruss Boris

[Frank Glencairn]

Du müsstest schon ein Lossless-Format haben, um Generationenverluste auszuschließen.

Meine Masterfiles sind selbstverständlich unkomprimiert - was denn sonst?

[Darth Schneider]

Morgen Frank

Wäre es für mich mit der Pockrt öauch sinnvoller weniger zu komprimieren als Pro Res 4:2:2 HQ ?
Ich dachte mit das genügt..;)))
Sollte ich besser mit 4:4:4 ?
Gruss Boris

[vaio]

Morgen Frank

Wäre es für mich mit der Pockrt öauch sinnvoller weniger zu komprimieren als Pro Res 4:2:2 HQ ?
Ich dachte mit das genügt..;)))
Sollte ich besser mit 4:4:4 ?
Gruss Boris

Hallo Boris, ich bin zwar genau wie du nicht professionell unterwegs, aber egal mit welcher „Pro Res-Vorlage“ du herausrechnest, es ist nicht verlustlos - man spricht von einem Intermediate-Codec. Wie bereits oft geschrieben, kann man auch keine Informationen hinein rechnen, wo es keine gibt (4:2:2 vs 4:4:4).
Ich lege für ausgewählte Files eine Archivdatei an - je nach Originalformat wähle ich ebenfalls einen Intermediate-Codec. Dabei habe ich keinen „Standard“, sondern wähle aus den „Blumenstrauß“ an Möglichkeiten, die für mich geeignetste Einstellung aus. Weiterhin macht es für mich auch keinen Sinn, ein h.264-File in ein höherwertiges Format zu speichern (archivieren), wenn ich es ohnehin nicht weiterverwenden werde. Von unkomprimiert möchte ich gar nicht erst anfangen, bin ja schließlich nicht beim Fernsehen…
Gruß Michael

[Darth Schneider]

Danke dir vaio
Also ProRes 4:4:4 nehm ich auch nur, wenn ich erst mit 4K BRaw Q0/Q1 oder mit HLG aufnehme um dann ein HDR/HLG daraus zu machen/auf dem TV anschauen zu können….
Oder genauer gesagt, um damit herum zu spielen….;)))
Was ja immer noch voll Neuland für mich ist.

Ich stehe was den Master Format Blumenstrauss angeht sonst immer noch ein wenig auf dem Schlauch…
Ich dachte mir darum bisher einfach mit ProRes 4:2:2 HQ bin ich auf der relativ sicheren Seite.
Nicht zuletzt wegen Zukunftssicher….und weil mein iMac nicht der schnellste ist.
Gruss Boris

[Darth Schneider]

@iasi
Hab jetzt mal nen Vergleich gemacht.

Und habe einmal ein in ProRes HQ gefilmtes Projekt von Resolve direkt als h264 Delivery herausgerechnet und ich habe beim zweiten Mal, erst über ein ProRes HQ Master und dann erst auf H264 gerendert.

Und siehe da, ich finde die Version, erst über das ProRes HQ Master File gerendert, sieht gefühlt doch ein Tick knackiger und sauberer aus.
Auch scheinen die problematischen dunkleren Stellen im Hintergrund ein wenig weniger Rauschig zu sein.

(Alles in Resolve Studio, neuste Version18, ich ging bewusst nicht über Handbreak…)
Weil das dcp rechnest du ja auch direkt über Resolve…

Aber ich bin ja natürlich gar nicht der Pixel Peeping Typ, der eingezoomter Standbilder miteinander am Rechner vergleicht. Ich denke das bringt nix.
Ich mache das immer nur am bewegten Bild, auf meinem neuen 55 Zoll OLED LG TV..

Probier das doch mal selber..
Vielleicht ist meine Einschätzung ja auch relativ, oder falsch..;)

Gruss Boris

[Axel]

Und habe einmal ein in ProRes HQ gefilmtes Projekt von Resolve direkt als h264 Delivery herausgerechnet und ich habe beim zweiten Mal, erst über ein ProRes HQ Master und dann erst auf H264 gerendert.

Und siehe da, ich finde die Version, erst über das ProRes HQ Master File gerendert, sieht gefühlt doch ein Tick knackiger und sauberer aus.
Auch scheinen die problematischen dunkleren Stellen im Hintergrund ein wenig weniger Rauschig zu sein.

(Alles in Resolve Studio, neuste Version18, ich ging bewusst nicht über Handbreak…)

Das besagt nicht zwingend etwas über den Qualitätsunterschied zwischen ProRes und H.264, sondern womöglich über den weniger guten Encoder in Resolve:

AME (den ich wegen AAE noch habe) liefert bessere Qualität als Resolve. Und was ist mit Handbrake? Das müsste man mal vergleichen. Jedenfalls ist ProRes, wie oben schon gesagt wurde, eigentlich nur noch als Kompromiss sinnvoll, wenn man einen Zwischenexport machen muss, aber gleichzeitig keine gigantischen unkomprimierten Dateien haben möchte.

[Darth Schneider]

@Axel
Ich mache das normalerweise auch eher über Handbreak, aber weil es ja dem iasi darum ging einfach nur von Resolve direkt heraus zu rechnen habe ich das gelassen.

Zumal ich finde Resolve macht das direkte h264/ h265 Rendering eigentlich mittlerweile mehr als gut genug, zumindest für meine Ansprüche.
Probier es mal…
Wobei ich auch mit h264/h265 immer ans Maximum der Datenrate gehe und mich nie an dem Minimum orientiere. Egal ob mit Hanbreak oder mit Resolve.

Das war früher noch ein Thema wegen fehlender Kompatibilität der TV Geräte, und hohen USB Stick und Hdd Speicherpreisen, aber ist doch aber heute eigentlich gar nicht mehr nötig.
Je höher die Bitrate/Datenrate desto besser, das ist mein Motto…;)

Eine Stunde HD h264 Video finde ich sollte jedenfalls immer über 10GB haben, mindestens…Lieber 12…
Sonst hat das die Tendenz zur Suppe..;)))
Gruss Boris

[Axel]

Wir reden hier von unterschiedlichen Dingen. Dass während der Bearbeitung das Ausgangsmaterial geschont werden muss ist klar. Premiere-User rieben das FCP-Usern früher in die Fresse. Wir rendern nur vom Original, während ihr einen verlustbehafteten Schnittcodec nehmt und noch nicht einmal (wie bei Proxies) später wieder auf das Original verweist. Das war so, aber das war damals. Für die meisten machte es keinen Unterschied. Für Kino wurde auf Film aufgenommen, analog unkomprimiert, aber dann, zack!, auf HD-Video gescannt und für locker zehn Jahre (ab 1999) auch nicht mehr zurückgeblickt (vom Fazen abgesehen). Die Premierianer sprachen aber hier i.d.R. von AVCHD (oder, noch davor, von DV).

Für DCP heute gilt, dass auf Leinwänden von Hauswandbreite Pixel so groß sind wie einzelne Stückchen Ritter Sport (kommt im Durchschnitt tatsächlich hin, manchmal größer). Und klar dass, je nachdem wie nah man rangeht, man dann Kompressionsartefakte deutlich und störend wahrnehmen würde. Ich bin lange nicht mehr Vorführer, aber JPEG2000, was der einem DCP zugrunde liegende Distributionscodec war, entsprach ziemlich genau ProRes444, war also, um einen Fachterminus einzuführen, gut genug. Man konnte auch AVCHD zu einem DCP machen. Dann durfte man nur nicht zu genau hingucken.

Ironischerweise kann ich heute ähnliche Größenverhältnisse mit Leichtigkeit reproduzieren. Die Codecs sind besser geworden, die Encoder sind besser geworden. Der Zuschauer, an den du dich wendest, weiß nicht, wie verlustarm dein Original war (denn der Acquisationscodec ist ja komprimiert, auch natürlich BRAW), er sieht nur, was du ihm als Endergebnis präsentierst. Und das muss für deine Ansprüche gut genug sein.

Alle modernen NLEs rendern mit den Originalen, aber es gibt Unterschiede in der Qualität der Kompression bei der Ausgabe. Welche Kompromisse kannst du akzeptieren, ab wann sieht das Ganze Scheiße aus und all deine Mühe war für die Katz? Es hat mit der Datenrate auch zu tun, aber eben nicht nur.

[AndySeeon]

Und habe einmal ein in ProRes HQ gefilmtes Projekt von Resolve direkt als h264 Delivery herausgerechnet und ich habe beim zweiten Mal, erst über ein ProRes HQ Master und dann erst auf H264 gerendert.

Und siehe da, ich finde die Version, erst über das ProRes HQ Master File gerendert, sieht gefühlt doch ein Tick knackiger und sauberer aus.
Auch scheinen die problematischen dunkleren Stellen im Hintergrund ein wenig weniger Rauschig zu sein.

Das besagt nicht zwingend etwas über den Qualitätsunterschied zwischen ProRes und H.264, sondern womöglich über den weniger guten Encoder in Resolve

Deswegen verwende ich das Voucoder- Plugin in Resolve, welches die gleichen Encoder wie Handbrake verwendet und bypasse damit den Resolve- internen Encoder.

Gruß, Andreas

[Darth Schneider]

Danke, aber Leider halt nur für Windows.
Oder hab ich was übersehen ?

Ich bleib somit für mich privat wenn das so ist, auch beim H264/h265 Rendering in Resolve….

(Ich meine wenn ich den Unterschied zu Handbreak auf meinem 55 Zoll Tv eh mittlerweile (seit Version 18) nicht sehe, dürfte das überhaupt keine Rolle spielen…;)))

Und für die bezahlenden Kunden bleibe ich aus Sicherheit bei Handbreak. (Vorerst)
Blackmagic schläft ja nicht…

@Axel
Das du mal Filmvorführer warst finde ich ja sowas von cool… ;)
Gruss Boris

[Axel]

@Boris
Mir selbst ist die Qualität von Resolve „gut genug“. Ich finde den Direktupload zu Youtube ungemein praktisch. Ginge es mir um hypothetische bessere Uploadfiles, könnte ich auch nach wie vor einen ProRes-Master exportieren und diesen dann in AME oder Handbrake kleinrechnen. Auch der praktisch unbegrenzt konfigurierbare Compressor-Export wäre eine Option.
Auch hier kann man leicht in die Verlustangst-Falle tappen. Auch Youtubes Encoder sind besser geworden. Ich sah ein paar „Experten“-Tutorials, die auf H.265 als für Youtube geeigneten Kompromiss schwören. Das Resolve-Preset kann man ebenfalls so benutzerdefinieren, dass es HEVC mit 10bit 422 ausgibt, was mE für alles unter DCP völlig reicht.

[Axel]

Weil mir diese Upgrade-Geschichte keine Ruhe ließ, habe ich jetzt ca. 30 Videos zum Thema gesehen und versuche hier mal, einen Überblick über die Ausstattungsunterschiede zu geben, soweit sie für Videobearbeitung interessant sind. Das heißt, ich lasse Spiele und Blender und Konsorten bewusst außen vor.

MacMini M1 mit 512GB und 16GB Speicher, Asgoodasnew: 800 €.

> Um erstmal wieder auf die Frage zurückzukommen, warum nicht die Basis-Version mit 256/8 für (schluck) immer noch 575 € (Asgoodasnew)? Weil eine der leicht zu überprüfenden Tatsachen ist, dass bei leichtem bis normalem Gebrauch von 4k Video mit Farbkorrektur und Effekten der RAM-Bedarf laut Aktivitätsanzeige die 8GB komplett ausreizt. Er liegt typischerweise bei ca. 12 GB. Der Rest wäre Swap. Auch 16GB können angesprochen werden, aber seltener.

> Wie allgemein bekannt, packt das Gerät diese Anforderung sehr gut. Es gäbe praktisch keinen Grund, upzugraden, bzw. ein teureres Gerät zu kaufen.

MacMini M2 mit 512GB und 16GB Speicher, Apple: 1159 €.

> ist M2 tatsächlich so viel schneller als M1? Ich schätze, das wird in der Timeline-Performance keinen Unterschied machen. Er hat zwei CPU-Kerne mehr und allgemein eine bessere Architektur, aber er rendert wohl wahrscheinlich nur ein paar Prozent schneller, und die (ebenfalls) 16-Core Neural Engine scheint etwas flotter zu sein. Ohne Frage wird das ein guter Einstiegs-Mac sein, und die 360 € Unterschied zum Vorgänger könnten es dem einen oder anderen wert sein.

MacMini M2 Pro mit 512GB und 16GB Speicher, Apple: 1549 €.

> 390 € Unterschied zum kleinen, dafür ein stärkerer Chip, mehr Cores und vor allem vier Thunderbolt 4 - Anschlüsse (und, aber das betrifft ja fast nur Gamer, HDMI mit bis zu 240 Hz bei 4k).

> Erste Erfahrungsberichte zeigen, dass das bei Voll-Last ein kleiner Wasserkocher ist. Er wird 90° warm, und man hört mit bloßem Ohr den Lüfter, dem trotzdem merkwürdigerweise nie mehr als 60% seiner Umdrehungen erlaubt werden. Was das bedeutet? Das weiß man noch nicht so genau, aber ich sehe es als ein für Apple Silicon eher schlechtes Zeichen.

> die Frage ist, in welchem Szenario der Mini Pro besser wäre, mal von Renderzeiten abgesehen, die aber auch eher kürzer sind anstatt radikal kürzer.

MacMini Pro mit 512 GB, 32GB, Apple: 10-Core CPU - 2009 € und 12-Core CPU - 2354 €

Rein preislich gesehen überschreiten wir hier leicht den Preis (bei diversen Drittanbietern ab 1999 €) des schwächsten

M1 Studio Max mit 512 GB, 32 GB

> bereits 24-Core GPU (im Vergleich zu 10-Core beim Mini und 16-Core beim Mini Pro)

> zwar nur HDMI 2.0, dafür serienmäßig zwei zusätzliche USBC-Buchsen und ein SD-Kartenslot vorne. Auch, für den, der's braucht, 10GB Ethernet.

> 32 GB werden nur in absoluten Extremfällen angesprochen. Zum Beispiel 6k BRAW nativ mit Farbkorrektur, komplexen Fusion-Grafikanimationen und temporaler sowie spatialer Rauschunterdrückung. Während aber ein von den specs her vergleichbarer PC mit dedizierter und dezidierter Grafikkarte manche Clips schlicht nicht rendert, weil die Grafikkarte "voll" ist, macht der Max tapfer bis zum Ende weiter (auch, wenn er zuvor nur in 8fps statt 16fps - beides keine Echtzeit - abspielen kann).

> Wärmeentwicklung dabei unter 50°, Lüfter auf 40%, unhörbar in dem größeren Chassis.

Der Studio könnte für Apple eine Sackgasse sein, denn die Verkaufszahlen blieben (gegenüber Mini und den MacBooks und sogar 2019-er MacPros) weit hinter den Erwartungen zurück. Ob es also ein M2 Studio, geschweige denn M3 Studio geben wird, ist gar nicht sicher. Aber im Augenblick erscheint mir der Studio vernünftiger als der Mini Pro. Dass der Ultra eigentlich Käse ist, weil das Preis-Leistungsverhältnis gegenüber ähnlich teuren PCs nicht mehr stimmt, wurde oft genug bewiesen.

[Frank Glencairn]

Aaaaalso......

Zunächst ein mal - warum sollte ich irgendwas geringeres als die bestmögliche Qualität (unkomprimiert) benutzen?

Dann: Das hauseigene (über CPU) H264 aus Resolve ist qualitativ eher so mittelprächtig (im Vergleich zu Handbrake).
Wenn man dann auch noch über die GPU raus rechnet wird''s eher noch schlechter - dafür hat man dann auch noch ein größeres File am Ende.

Für DCPs benutzt Resolve den Kakadu Codec - ein JPEG2000/Wavelet Codec der quasi Industriestandard ist.

Prores kann man schon machen, ist aber kein Vergleich mit unkomprimiert.
Ob man das in allen Fällen immer sieht? Wahrscheinlich nicht, aber das führt mich wieder zu der Eingangsfrage:

Warum sollte ich auf irgendwas anderes als die bestmögliche Qualität setzen, wenn sie mir doch zur Verfügung steht.

[pillepalle]

Dann: Das hauseigene (über CPU) H264 aus Resolve ist qualitativ eher so mittelprächtig (im Vergleich zu Handbrake).

Und den Unterschied sieht man? Ich frage mal so ganz unbedarft, weil ich Projekte für Youtube eigentlich immer direkt aus Resolve in H264 rendere. Wie wäre es denn dann besser? Erst aus Resolve in ProRes rendern und dann mit Handbrake in H264?

VG

[Frank Glencairn]

Theoretisch wäre das beste unkomprimiert aus Resolve - dann H264 in Handbrake.
Allerdings rechnet YT dein File sowieso noch in zig andere Codecs und Datenraten um, dahast du dann null Kontrolle drüber.

Prinzipiell gilt natürlich auch bei YT junk in > junk out - das heißt je besser das File ist, das du den YT Encodern zum Fraß vor wirfst, desto besser wir das Ergebnis - nur bis zu einem gewissen Grad natürlich. Im Prinzip könntest du ja auch ein Prores hoch laden, ich glaub mittlerweile frisst YT sogar Cineform, was nochmal besser wäre, aber du zahlst halt mit entsprechenden Uploadzeiten.

Es ist halt immer so ne Balance die man finden muß. Für jemand mit nem Glasfaser Anschluß ist das womöglich gar kein so großes Thema.

Mein persönlicher Kompromiss ist unkomprimiert aus Resolve raus > h264/65 mit nem entsprechend gut getunten Preset in Handbrake umrechnen - kann man natürlich auch in Resolve über den Vukoder machen - sollte auf's gleiche raus kommen.

[Jörg]

Meine letzten Projekte habe ich final direkt aus Resolve via vukoder in H264/H265 rausgerechnet.
Qulität? Hochzufrieden.
Ich kann CPU und GPU Ergebnis nicht mal mit Mühe unterscheiden.
Zwischenschritte wie Animationen oder ähnliches werden, wie immer, in Zwischencodecs gerechnet.

[AndySeeon]

Ich zitiere:

Deswegen verwende ich das Voucoder- Plugin in Resolve, welches die gleichen Encoder wie Handbrake verwendet und bypasse damit den Resolve- internen Encoder.

Gruß, Andreas

[pillepalle]

Das einzige was mir aufgefallen war ist, dass es natürlich Sinn macht bei Youtube 4K Footage hochzuladen, weil die Datenraten dann höher sind. Da sieht man dann tatsächlich einen deutlichen Qualitätssprung zu FHD. Aber ich werde das in einer ruhigen Stunde mal testen. Macht vermutlich nur Sinn, wenn man wirklich das Maximum an Qualität aus H264 heraus holen möchte. Aber warum dann überhaupt H264? Für Youtube und Co. ist's aber vermutlich eher schnuppe.

Ich hatte bisher eher das Problem, dass enigen meiner Kunden selbst die H264 Files für den Upload zu groß waren. Da sollte ich die dann so stark komprimieren, dass es wirklich gruselig aussah.

VG

[Axel]

Dann: Das hauseigene (über CPU) H264 aus Resolve ist qualitativ eher so mittelprächtig (im Vergleich zu Handbrake).

Und den Unterschied sieht man? Ich frage mal so ganz unbedarft, weil ich Projekte für Youtube eigentlich immer direkt aus Resolve in H264 rendere. Wie wäre es denn dann besser? Erst aus Resolve in ProRes rendern und dann mit Handbrake in H264?

VG

Der oben von mir verlinkte Differenz-Comp-Clip legt genau das nahe. In diesem Fall wäre Unkomprimiert wohl Perlen vor die ***. Zwar stimmt der Spruch "garbage in = garbage out", wir sollten aber einen realistischen Blick auf das Ausgabeziel werfen. Wenn das noch nicht sicher ist und eine Veröffentlichung im Kino nicht ausgeschlossen, kann ich Franks Argumentation folgen.

Zu der Zeit, als die Ur-Pocket herauskam (hat nichts mit der Kompression zu tun, ist nur zeitliche Einordnung) gab es einige prominente Youtuber, unter anderem Philip Bloom, die empfahlen, auf Youtube nur ProRes hochzuladen, weil das am wenigsten Artefakte produzieren würde. In HD-Videos konnten die Unterschiede im Vergleich sichtbar gemacht werden. Es steht dir frei, das auszuprobieren, können ja kurze Schnippsel sein. Das Problem - heute noch - bei Youtube sind SD-Auflösungen, die ungeachtet der Uploadqualität unterirdisch sind. Man kann nur hoffen, dass derjenige, der sein Video guckt, wenigstens in 720p guckt. Man kann etwas gegen Posterisierung (auch bekannt als Banding) tun, indem man 10-bit hochlädt. Das hilft leider nicht gegen die Bewegungsartefakte und Pixelblöcke in 640p und darunter, selbst, wenn der Upload in HD oder UHD erfolgte. Aber ein ProRes-Upload hilft auch nicht. Wie gesagt, probier im Vergleich H.265 10-bit, getrost aus Resolve heraus und vergleiche die verschiedenen Auflösungen auf Youtube. Finde ich einen gangbaren Kompromiss.

[pillepalle]

Dr. Alzheimer läßt Grüßen *g*

Hatte den Voucoder bereits installiert, aber nie benutzt, weil total vergessen :) Es gibt allerdings recht viele Einstellungen bei der Konfiguration. Da muss man sich erstmal durchtesten...

VG

[DKPost]

Weil mir diese Upgrade-Geschichte keine Ruhe ließ, habe ich jetzt ca. 30 Videos zum Thema gesehen und versuche hier mal, einen Überblick über die Ausstattungsunterschiede zu geben, soweit sie für Videobearbeitung interessant sind. Das heißt, ich lasse Spiele und Blender und Konsorten bewusst außen vor.

MacMini M1 mit 512GB und 16GB Speicher, Asgoodasnew: 800 €.

> Um erstmal wieder auf die Frage zurückzukommen, warum nicht die Basis-Version mit 256/8 für (schluck) immer noch 575 € (Asgoodasnew)? Weil eine der leicht zu überprüfenden Tatsachen ist, dass bei leichtem bis normalem Gebrauch von 4k Video mit Farbkorrektur und Effekten der RAM-Bedarf laut Aktivitätsanzeige die 8GB komplett ausreizt. Er liegt typischerweise bei ca. 12 GB. Der Rest wäre Swap. Auch 16GB können angesprochen werden, aber seltener.

> Wie allgemein bekannt, packt das Gerät diese Anforderung sehr gut. Es gäbe praktisch keinen Grund, upzugraden, bzw. ein teureres Gerät zu kaufen.

MacMini M2 mit 512GB und 16GB Speicher, Apple: 1159 €.

> ist M2 tatsächlich so viel schneller als M1? Ich schätze, das wird in der Timeline-Performance keinen Unterschied machen. Er hat zwei CPU-Kerne mehr und allgemein eine bessere Architektur, aber er rendert wohl wahrscheinlich nur ein paar Prozent schneller, und die (ebenfalls) 16-Core Neural Engine scheint etwas flotter zu sein. Ohne Frage wird das ein guter Einstiegs-Mac sein, und die 360 € Unterschied zum Vorgänger könnten es dem einen oder anderen wert sein.

MacMini M2 Pro mit 512GB und 16GB Speicher, Apple: 1549 €.

> 390 € Unterschied zum kleinen, dafür ein stärkerer Chip, mehr Cores und vor allem vier Thunderbolt 4 - Anschlüsse (und, aber das betrifft ja fast nur Gamer, HDMI mit bis zu 240 Hz bei 4k).

> Erste Erfahrungsberichte zeigen, dass das bei Voll-Last ein kleiner Wasserkocher ist. Er wird 90° warm, und man hört mit bloßem Ohr den Lüfter, dem trotzdem merkwürdigerweise nie mehr als 60% seiner Umdrehungen erlaubt werden. Was das bedeutet? Das weiß man noch nicht so genau, aber ich sehe es als ein für Apple Silicon eher schlechtes Zeichen.

> die Frage ist, in welchem Szenario der Mini Pro besser wäre, mal von Renderzeiten abgesehen, die aber auch eher kürzer sind anstatt radikal kürzer.

MacMini Pro mit 512 GB, 32GB, Apple: 10-Core CPU - 2009 € und 12-Core CPU - 2354 €

Rein preislich gesehen überschreiten wir hier leicht den Preis (bei diversen Drittanbietern ab 1999 €) des schwächsten

M1 Studio Max mit 512 GB, 32 GB

> bereits 24-Core GPU (im Vergleich zu 10-Core beim Mini und 16-Core beim Mini Pro)

> zwar nur HDMI 2.0, dafür serienmäßig zwei zusätzliche USBC-Buchsen und ein SD-Kartenslot vorne. Auch, für den, der's braucht, 10GB Ethernet.

> 32 GB werden nur in absoluten Extremfällen angesprochen. Zum Beispiel 6k BRAW nativ mit Farbkorrektur, komplexen Fusion-Grafikanimationen und temporaler sowie spatialer Rauschunterdrückung. Während aber ein von den specs her vergleichbarer PC mit dedizierter und dezidierter Grafikkarte manche Clips schlicht nicht rendert, weil die Grafikkarte "voll" ist, macht der Max tapfer bis zum Ende weiter (auch, wenn er zuvor nur in 8fps statt 16fps - beides keine Echtzeit - abspielen kann).

> Wärmeentwicklung dabei unter 50°, Lüfter auf 40%, unhörbar in dem größeren Chassis.

Der Studio könnte für Apple eine Sackgasse sein, denn die Verkaufszahlen blieben (gegenüber Mini und den MacBooks und sogar 2019-er MacPros) weit hinter den Erwartungen zurück. Ob es also ein M2 Studio, geschweige denn M3 Studio geben wird, ist gar nicht sicher. Aber im Augenblick erscheint mir der Studio vernünftiger als der Mini Pro. Dass der Ultra eigentlich Käse ist, weil das Preis-Leistungsverhältnis gegenüber ähnlich teuren PCs nicht mehr stimmt, wurde oft genug bewiesen.

Also in After Effects ist 32GB Ram absolut kein Extremfall. Darunter wird es bei komplexen Comps schon eher eng würde ich sagen. Zumindest auf Windows. Bei mir nutzt AE eigentlich immer zwischen 70% und 80% von 64GB Ram.
Es kann natürlich sein, dass das auf den M-Chips besser läuft, aber generell konnte AE eigentlich noch nie genug Ram haben.

Und man muss auch bedenken, dass bei den M-Chips ja alles Shared Memory ist. Die 32GB wären also Ram UND GPU Memory. Am Ram würde ich da nicht sparen.

[andieymi]

Und man muss auch bedenken, dass bei den M-Chips ja alles Shared Memory ist. Die 32GB wären also Ram UND GPU Memory. Am Ram würde ich da nicht sparen.

Jo, aber nicht vergessen dass Unified Memory heißt, dass sowohl GPU als auch RAM beliebig über die SSD auslagern können. Zwar in der Theorie langsamer, in der Praxis fragwürdig wie viel.

Ich bin absolut kein Fanboy, aber die Krux liegt darin:

"Zumindest auf Windows."

In allen Benchmarks die ich kenne war am Ende der letzte 15-30K Mac Pro mit 192GB RAM Aufwärts trotzdem langsamer als ein Studio mit M1 Ultra oder Max mit 32GB.
Die Vergleiche funktionieren mit Architekturumstellung wirklich nicht mehr gut, außer wenn man innerhalb einer Architektur vergleicht.

[DKPost]

Und man muss auch bedenken, dass bei den M-Chips ja alles Shared Memory ist. Die 32GB wären also Ram UND GPU Memory. Am Ram würde ich da nicht sparen.

Jo, aber nicht vergessen dass Unified Memory heißt, dass sowohl GPU als auch RAM beliebig über die SSD auslagern können. Zwar in der Theorie langsamer, in der Praxis fragwürdig wie viel.

Ich bin absolut kein Fanboy, aber die Krux liegt darin:

"Zumindest auf Windows."

In allen Benchmarks die ich kenne war am Ende der letzte 15-30K Mac Pro mit 192GB RAM Aufwärts trotzdem langsamer als ein Studio mit M1 Ultra oder Max mit 32GB.
Die Vergleiche funktionieren mit Architekturumstellung wirklich nicht mehr gut, außer wenn man innerhalb einer Architektur vergleicht.

Eben, die M-Chips lassen sich schwer durch irgendwelche Zahlen oder Benchmarks mit Windows Hardware vergleichen.
Ich würde evtl. sogar einen etwas langsameren, finalen Export in Kauf nehmen, wenn vor allem in AE das eigentlich Arbeiten mal halbwegs Spaß machen würde.
Laut diesem Vergleichsvideo mit der Workstation ist das bei den M-Chips ja scheinbar so. Preislich wird sich das nicht viel nehmen, einen eventuellen M2 Studio mit Max CPU und Ram wird man sich auch nicht unter 7.000€ bekommen. Dafür könnte man easy eine gleich potente oder ziemlich sicher auch schnellere Workstation bauen, aber eben nur in messbaren Zahlen, nicht gefühlter Schwuppzidität. Aber scheinbar funktioniert die Software-Portierung für Silicon ja wirklich herausragend gut, so dass man wirklich schön flüssig arbeiten kann. Und der Stromverbrauch ist natürlich auch ein riesen Pluspunkt für Apple Silicon. Ob der Chip da 100° warm wird oder der Lüfter hochdreht interessiert mich absolut null (hier brät ein Skylake-X vor sich hin).

[markusG]

> 32 GB werden nur in absoluten Extremfällen angesprochen. Zum Beispiel 6k BRAW nativ mit Farbkorrektur, komplexen Fusion-Grafikanimationen und temporaler sowie spatialer Rauschunterdrückung. Während aber ein von den specs her vergleichbarer PC mit dedizierter und dezidierter Grafikkarte manche Clips schlicht nicht rendert, weil die Grafikkarte "voll" ist, macht der Max tapfer bis zum Ende weiter (auch, wenn er zuvor nur in 8fps statt 16fps - beides keine Echtzeit - abspielen kann).

Jo, aber nicht vergessen dass Unified Memory heißt, dass sowohl GPU als auch RAM beliebig über die SSD auslagern können. Zwar in der Theorie langsamer, in der Praxis fragwürdig wie viel.

Was ich hierbei nicht schnalle: das Problem trat [im Video] auch beim reinen CPU-rendern auf. Swap Memory ist schon ziemlich alt, hier ist die Frage ob es a) ein Bug von Resolve ist oder b) eine fundamentale Inkompatibilität mit dem Windows-Scheduler. Sprich: ob das in absehbarer Zeit lösbar ist. Denn der M2 mit 16GB (iirc) hat es ja gewuppt...

> die Frage ist, in welchem Szenario der Mini Pro besser wäre, mal von Renderzeiten abgesehen, die aber auch eher kürzer sind anstatt radikal kürzer.

Falls die Frage ggü dem MacBook (allerdings: MBP M1 Max) gilt - wird sie in diesem Artikel (teils) beantwortet:
https://www.golem.de/news/apple-m2-max- ... 71570.html

Der Hauptvorteil durch die bessere Kühlung macht sich bemerkbar bei Aufgaben, wo GPU- und CPU-Last gleichmäßig verteilt ist. Also sehr Anwendungsspezifisch.

[Axel]

@DKPost
Um den erwähnten Studio auf 64GB Ram zu bringen, müsstest du nochmals 460 € in die Hand nehmen. Ich habe zwar AAE, habe es aber in puncto RAM nie getestet, weil ich es nie als Echtzeit-Programm aufgefasst habe. Nach allem, was ich gesehen habe, sind Silicon-Macs eigentlich nicht so gut für Adobe. Premiere benutzt trotz Unterstützung immer noch nur 20-30% des Speichers. Da wundert es nicht, dass sowohl die Timeline- als auch die Renderperformance immer noch hinterher hinken. Wie dem auch sei, meine Übersicht ist halt persönlich gefärbt von meiner Präferenz für FCP und Resolve (leider noch nicht von Fusion, da weiche ich gerne auf AAE oder immer öfter zu Motion aus). Viele Apps sind nicht die Kandidaten für diese Macs, und das ist ja auch okay so.

[andieymi]

Eben, die M-Chips lassen sich schwer durch irgendwelche Zahlen oder Benchmarks mit Windows Hardware vergleichen.

Drum habe ich auch den Vergleich zum intel Mac Pro referenziert, weil sich der anhand der Architektur schon eher zu Windows vergleichen lässt. Das Problem finde ich ist oft, dass es zu wenige Komplettsystem-Benchmarks zwischen M1 und Windows gibt, weil fast nur Komplettsysteme gegeneinander testbar sind, diese sich bei Windows aber fast nie gleichen meiner Erfahrung nach auch einer teilweise deutlichen Schwankungsbreite unterworfen sind.

Ich bin mir auch recht sicher, dass man mit einer 4-5K Netto Windows-Workstation auch preislich bald einmal den Silicon-Macs das Wasser abgrräbt, aber da sind wir dann halt auch schon in einer Preisklasse, den nicht jeder hier und nicht mal jede kleine Werbe-Film-Bude 4x rumstehen hat.

Umgekehrt wage ich rein meiner Erfahrung mit beiden Systemen zu behaupten, dass die Flüssigkeit, die man mit fast jedem momentanen Mac System (egal ob M1/2, Mini / Studio) quasi schon ab der Einstiegsklasse bekommt von vielen Windows-Geräten zum gleichen Preis nicht erreicht werden.

Das liegt eben auch an der GPU-Problematik, die momentan unter Windows-DIY vorherrscht - da kostet die GPU oft fast vergleichbar viel wie ein M2-Mini mit nicht mehr Basis-Specs und wenn man von wirklichen leistungshungrigen und teilweise auch schlecht optimierten Tools (da kann man After Effects mittlerweile nicht mehr ganz ausnehmen) um diesen dann in spezifischen Anwendungen (VFX fällt da wohl darunter) zu schlagen, wo für vieles andere der Mac einfach im Gesamtpaket überlegen ist, wenn's um Schnitt, Fotobearbeitung, ein bisschen Grading & vieles mehr geht - da sind wir noch gar nicht bei Effizient, Lautstärke, etc.

> 32 GB werden nur in absoluten Extremfällen angesprochen. Zum Beispiel 6k BRAW nativ mit Farbkorrektur, komplexen Fusion-Grafikanimationen und temporaler sowie spatialer Rauschunterdrückung. Während aber ein von den specs her vergleichbarer PC mit dedizierter und dezidierter Grafikkarte manche Clips schlicht nicht rendert, weil die Grafikkarte "voll" ist, macht der Max tapfer bis zum Ende weiter (auch, wenn er zuvor nur in 8fps statt 16fps - beides keine Echtzeit - abspielen kann).

Jo, aber nicht vergessen dass Unified Memory heißt, dass sowohl GPU als auch RAM beliebig über die SSD auslagern können. Zwar in der Theorie langsamer, in der Praxis fragwürdig wie viel.

Was ich hierbei nicht schnalle: das Problem trat [im Video] auch beim reinen CPU-rendern auf. Swap Memory ist schon ziemlich alt, hier ist die Frage ob es a) ein Bug von Resolve ist oder b) eine fundamentale Inkompatibilität mit dem Windows-Scheduler. Sprich: ob das in absehbarer Zeit lösbar ist. Denn der M2 mit 16GB (iirc) hat es ja gewuppt...

Ich glaube auch nicht, dass sich das intel-übliche Swap Memory außer dem grundlegenden Funktionisprinzip direkt mit Windows vergleichen lässt.

Wie ich das verstanden habe, können unter Windows zwar GPU als auch CPU bestimmte Bereiche im Speicher ansprechen, nicht allerdings gleichzeitig und nicht jeweils übergreifend. Sondern jede Komponente für sich, mit seperat zugewiesenen und fix bleibenden Größenordnungen.

Unified Memory funktioniert dagegen gleichzeitiger, dynamischer und mit weniger hin- und herkopiererei zischen CPU/GPU, RAM & SSD:
https://www.mactechnews.de/news/article ... 76424.html

[DKPost]

@DKPost
Um den erwähnten Studio auf 64GB Ram zu bringen, müsstest du nochmals 460 € in die Hand nehmen. Ich habe zwar AAE, habe es aber in puncto RAM nie getestet, weil ich es nie als Echtzeit-Programm aufgefasst habe. Nach allem, was ich gesehen habe, sind Silicon-Macs eigentlich nicht so gut für Adobe. Premiere benutzt trotz Unterstützung immer noch nur 20-30% des Speichers. Da wundert es nicht, dass sowohl die Timeline- als auch die Renderperformance immer noch hinterher hinken. Wie dem auch sei, meine Übersicht ist halt persönlich gefärbt von meiner Präferenz für FCP und Resolve (leider noch nicht von Fusion, da weiche ich gerne auf AAE oder immer öfter zu Motion aus). Viele Apps sind nicht die Kandidaten für diese Macs, und das ist ja auch okay so.

Ich baue normalerweise so alle 4 oder 5 Jahre einen neuen Rechner. Da finde ich 500€ für 32GB RAM jetzt nicht die Welt.

[markusG]

Wie ich das verstanden habe, können unter Windows zwar GPU als auch CPU bestimmte Bereiche im Speicher ansprechen, nicht allerdings gleichzeitig und nicht jeweils übergreifend. Sondern jede Komponente für sich, mit seperat zugewiesenen und fix bleibenden Größenordnungen.

Unified Memory funktioniert dagegen gleichzeitiger, dynamischer und mit weniger hin- und herkopiererei zischen CPU/GPU, RAM & SSD:
https://www.mactechnews.de/news/article ... 76424.html

So wie ich das verstanden habe, geht es schlicht um Geschwindigkeit, und nicht um die Verfügbarkeit. Wäre letzteres ein Problem, würde das ja eher für einen Bug sprechen.

Ich habe in meinem Privat-Rechner eine RTX3060 mit 12GB stecken; im Task-Manager wird jedoch angezeigt, dass sie ebenfalls Gemeinsamen Speicher hat (zusätzlich 32GB vom Systemspeicher) - sprich: VRAM und RAM sind von der GPU abrufbar und bilden einen Speicherpool; und da es in dem Beispiel ja um GPU-Rendering ging, wundert mich der Abbruch des Rendervorgangs, v.a.D. ohne Fehlermeldung.

In dem Video wird iirc aber auch klar, dass auch beim M1/M2 usw. RAM nicht plötzlich irrelevant sind (im Sinne der Größe).

Ich baue normalerweise so alle 4 oder 5 Jahre einen neuen Rechner. Da finde ich 500€ für 32GB RAM jetzt nicht die Welt.

Mein kompletter PC hat - nur mit interner GPU - gerade mal 800€ gekostet, inkl. 64GB Ram und 2TB SSD. Inzwischen gibt es den teils für die gleiche Kohle mit dedizierter GPU...dafür kann ich dann eben kein FCP benutzen. Horses of courses.

[Axel]

Ich baue normalerweise so alle 4 oder 5 Jahre einen neuen Rechner. Da finde ich 500€ für 32GB RAM jetzt nicht die Welt.

[DKPost]

Eben, die M-Chips lassen sich schwer durch irgendwelche Zahlen oder Benchmarks mit Windows Hardware vergleichen.

Drum habe ich auch den Vergleich zum intel Mac Pro referenziert, weil sich der anhand der Architektur schon eher zu Windows vergleichen lässt. Das Problem finde ich ist oft, dass es zu wenige Komplettsystem-Benchmarks zwischen M1 und Windows gibt, weil fast nur Komplettsysteme gegeneinander testbar sind, diese sich bei Windows aber fast nie gleichen meiner Erfahrung nach auch einer teilweise deutlichen Schwankungsbreite unterworfen sind.

Ich bin mir auch recht sicher, dass man mit einer 4-5K Netto Windows-Workstation auch preislich bald einmal den Silicon-Macs das Wasser abgrräbt, aber da sind wir dann halt auch schon in einer Preisklasse, den nicht jeder hier und nicht mal jede kleine Werbe-Film-Bude 4x rumstehen hat.

Umgekehrt wage ich rein meiner Erfahrung mit beiden Systemen zu behaupten, dass die Flüssigkeit, die man mit fast jedem momentanen Mac System (egal ob M1/2, Mini / Studio) quasi schon ab der Einstiegsklasse bekommt von vielen Windows-Geräten zum gleichen Preis nicht erreicht werden.

Das liegt eben auch an der GPU-Problematik, die momentan unter Windows-DIY vorherrscht - da kostet die GPU oft fast vergleichbar viel wie ein M2-Mini mit nicht mehr Basis-Specs und wenn man von wirklichen leistungshungrigen und teilweise auch schlecht optimierten Tools (da kann man After Effects mittlerweile nicht mehr ganz ausnehmen) um diesen dann in spezifischen Anwendungen (VFX fällt da wohl darunter) zu schlagen, wo für vieles andere der Mac einfach im Gesamtpaket überlegen ist, wenn's um Schnitt, Fotobearbeitung, ein bisschen Grading & vieles mehr geht - da sind wir noch gar nicht bei Effizient, Lautstärke, etc.

Was ich hierbei nicht schnalle: das Problem trat [im Video] auch beim reinen CPU-rendern auf. Swap Memory ist schon ziemlich alt, hier ist die Frage ob es a) ein Bug von Resolve ist oder b) eine fundamentale Inkompatibilität mit dem Windows-Scheduler. Sprich: ob das in absehbarer Zeit lösbar ist. Denn der M2 mit 16GB (iirc) hat es ja gewuppt...

Ich glaube auch nicht, dass sich das intel-übliche Swap Memory außer dem grundlegenden Funktionisprinzip direkt mit Windows vergleichen lässt.

Wie ich das verstanden habe, können unter Windows zwar GPU als auch CPU bestimmte Bereiche im Speicher ansprechen, nicht allerdings gleichzeitig und nicht jeweils übergreifend. Sondern jede Komponente für sich, mit seperat zugewiesenen und fix bleibenden Größenordnungen.

Unified Memory funktioniert dagegen gleichzeitiger, dynamischer und mit weniger hin- und herkopiererei zischen CPU/GPU, RAM & SSD:
https://www.mactechnews.de/news/article ... 76424.html

Generell läuft auf meinem mittlerweile 5 Jahre alten Rechner (mit RTX3080 Upgrade) alles recht gut. Resolve wird bei vielen Nodes + NR mal zickig, und AE muss einfach von Grund auf neu programmiert werden, was ja schon seit vielen Jahren gefordert wird. Aber normaler Schnitt, auch von RAW oder h264 stellt auch für mehrere Jahre alte Windows-Kisten doch eigentlich kein Problem dar.
Nur VFX und Compositing in AE lassen mich momentan gespannt auf einen eventuellen Mac Studio M2 warten.

[markusG]

Ich baue normalerweise so alle 4 oder 5 Jahre einen neuen Rechner. Da finde ich 500€ für 32GB RAM jetzt nicht die Welt.

Wäre es mal so einfach^^



Schade dass es so wenig After Effects Vergleiche gibt, und Puget Benchmarks sprechen dann auch eine eigene Sprache...immerhin ein Szenario, wo der Blick zum Ultra lohnt^^ (wenn da nur nicht der hohe Preis wäre :( )