slashCAM Forum

Kurztest: Kurztest: 4K Editing: ProRES-Codec mit PC-Bremse - Mythos oder Wahrheit? von rudi - 16 Mar 2015 11:54:00
>Decodiert Quciktime am PC langsamer als auf dem Mac? Im Rahmen unserer kommenden 4K Codec-Tests wollten wir zu Beginn einmal dieser Frage auf den Grund gehen...
zum ganzen Artikel

"Abschließend steht somit immerhin fest, dass der ProRES-Decoder von Apple am PC unter DaVInci Resolve tatsächlich nur halb so schnell arbeitet wie auf dem Mac."

Also doch kein Mythos.

Mich würde mal interessieren, wie ihr überhaupt gemessen habt. Oder spielt das heutzutage keine Rolle mehr ;)

Bin mal sehr gespannt darauf wie Apple sich verhält wenn sie QT in OSX endlich mal gekillt haben. Ob sie AVFoundation auch auf den PC bringen werden? Wäre langsam mal Zeit.

Die Frage wäre auch, ob man nicht die alternative (und dazu noch Open Source...) ProRes-Implementation von ffmpeg bzw. libavcodec so nach Windows portieren könnte, dass er sich als Ersatz für Apples Decoder verwenden lässt. ProRes-Encoding bekäme man dann noch gratis dazu...

Nein dieses Thema ist absolut kein Mythos, gerade ich habe in letzter Zeit immer wieder auf die Probleme mit der Dekodierung von UHD-ProRes hingewiesen. Sowohl in Edius wie auch in Vegas sehe ich - auf meinem ähnlich betragten Schnittrechner i7 2600K 4.3 Ghz - das gleiche Thema: unter Edius läuft der Puffer leer, und auch in Vegas bekomme ich nicht die volle Framerate.

Die Daten liegen hier auf einem ausreichend schnellen Raid-System - und bei Cineform unter Vegas oder auch dem Canopus HQX oder auch XAVC beobachte ich im gleichen System dieses Verhalten einfach nicht.

Nach Ausschluß anderer Gründe ist es definitiv so, dass die Dekodierleistung leider eher schwach ist. Schön dass man hier zum gleichen Schluß kommt - auch wenn ich es weniger schön finde dass diese Findings zunächst als "Mythos" eingestuft worden sind.

cantsin hat geschrieben:Die Frage wäre auch, ob man nicht die alternative (und dazu noch Open Source...) ProRes-Implementation von ffmpeg bzw. libavcodec so nach Windows portieren könnte, dass er sich als Ersatz für Apples Decoder verwenden lässt. ProRes-Encoding bekäme man dann noch gratis dazu...

Es sollte schon ein offiziell lizensiertes Modul geben, Open Source KANN funktionieren, muss aber nicht. Und ob libavcodec die Lösung für sowas ist, ist fraglich. Zu bloated für einzelne Codec NLE Implementierungen.

Sowas wie die Scratch Implementierung wäre sehr wünschenswert, nur halt in bezahlbar. ;)

auch wenn ich es weniger schön finde dass diese Findings zunächst als "Mythos" eingestuft worden sind.

wo wurde das als Mythos eingestuft...? es ist FAKT das Vegas und Edius mit Prores schlechte Leistung erbringen, andere Hersteller das Thema angegangen sind und gelöst haben..

Naja, dass der Slashcam-Artikel eine fette Zwischenüberschrift "Der ProRES Mythos" hat, hilft nicht gerade bei der Klärung der Tatsache, dass es sich gerade um keinen Mythos handelt...

Ach LIES doch mal den Artikel. Vor allem das Ende. Jetzt hast hier das Faktum, dass Resolve unter Windows ProRes halb so schnell dekodiert wie am Apple. Nach diesem Test ist der Mythos damit bestätigt.

Resolve, Edius, Vegas haben komischerweise das gleiche Problem. Wieso nur?

wolfgang hat geschrieben: Resolve, Edius, Vegas haben komischerweise das gleiche Problem. Wieso nur?

Ich mag Vegas, aber verminderte Performance ist mit ProRes in Vegas leider das kleinste Problem, die Dekodierung nach Computer RGB und der Gammashift sind für mich viel gravierender :(

ja lies nochmals genau, hab ich was von Resolve geschrieben?Da steht "andere Hersteller das Thema angegangen sind und gelöst haben." Langsam geht die Jammerei und die Wortklauberei wirklich auf den ......

Wenn hier ein Testbericht diskutiert wird dann kann man wohl erwarten dass dieser gelesen wird. Und sorry, dort ist halt von Resolve die Rede. Wenn es dir nicht passt - tja sei mir nicht böse, aber das ist nicht mein Problem.

Und jammern? Wie kommst zu dieser Wahrnehmung? Wir reden hier tatsächlich von Fakten. Aber eher davon, dass der alte QT Dekoder unter Windows Schrott ist. Jetzt halt auch für Resolve aufgezeigt. Das zu verleugnen ist sinnlos.

Und klar hat das gute Stück auch Luma-Themen, die Lumaspreizung ist ja inzwischen bekannt. Tritt etwa auch in TMPGenc auf. Zumindest beim Shogun Material habe ich aber keine markante Farbveränderung gesehen.

was verstehst daran nicht, die Firmen die die Prores codierung nicht gebacken bekommen müssen sich etwas überlegen Punkt andere haben ihre Aufgaben gemacht wie Adobe und andere auch. mehr gibts dazu nicht zu sagen, da kannst noch 100 Jahre über den beschissenen QT Decoder für Windows schimpfen wird sich daran nichts ändern... schreibs Sony und gut ists.. also nix Mythos FAKT

“Apple ProRes has become a de facto format in the industry for feature film, episodic television and documentary production,” said Steve Bannerman VP of Marketing at ASSIMILATE. “Windows users of professional media and entertainment solutions have typically had to rely on substandard encoding solutions. Quality often suffered and render speeds were painfully slow. We are thrilled that ASSIMILATE now delivers best-in-class cross-platform functionality to our customers with officially licensed and certified ProRes, ensuring consistency in workflow and providing an industry-standard deliverable to both Mac and Windows users.”

da heist es eben Zahlen, Mieten oder Warten..

Ist der Brandstifte schuld am Feuer, oder die Feuerwehr weil sie nicht gelöscht hat? Wenn nun auch slashcam die miese Performance des Dekoders unter Windows bestätigt - warum sollen immer die Anderen schuld sein, die diesen Dekoder nicht einmal programmiert haben?

Du sprichst von Fakten. Ich sehe hier nur, dass frech gefordert wird dass Andere die Versäunisse von Apple korrigieren sollen. Warum saniert Apple nicht selbst seinen leistungsschwachen Dekoder?

Mir ists egal, ich habe meine Lösungen. Ich habe auch kein Vorurteil gegen Apple, ich schreibe das hier gerade von einem Apple Produkt. Aber bei dir darf keiner Ursache und Wirkung darlegen. Da ist halt nicht der Brandstifter der böse Bube, sondern die Feuerwehr ist schuld. So gehts natürlich auch! :)

was wird das hier die Hättitätiwari Gschicht..? Apple hat im 2008er Jahr für die alte QT Plattform unterer Windows eine Prores Erweiterung geliefert das das Material gelesen werden kann.. selbst unter den drei von dir genannten Tools mit denen du arbeiten kannst ist bei Verwendung dieser Erweiterung die Perf komplett unterschiedlich und auch deren Funktion und Stabilität.

Als Beispiel Adobe, Adobe hat damit kein Auslangen gefunden und haben wie auch immer einen anderen praktikablen Weg gefunden um ihre Leistung zu finden, Scratch und Quantel ebenso.. Ob Apple Interesse daran das Vegas oder Edius das Material in RT oder sonst was abspielt wird sicher viele Unterschiedliche Interessen(Lizenzkosten, Marktinteresse, Wettbewerbsverzerrung,usw) streifen von denen wir hier eher keine Ahnung oder Einblick haben..

Das Zauberwort heißt Infrastruktur und da muss sich ein System Einfügen.. In deinem Fall ist der Drecks Prores Codec von Apple durchgefallen... passt.. die Welt wird sich weiter drehen..
Entweder kommts von Apple oder von Sony und aber auch nur dann wenn sich alles für Prores entscheidet was ich mir nicht vorstellen kann.. Gott gab uns die Vielfallt ;-)…..

Frag mal die SlascamRed. an ob sie nicht mit den VEGAS und EDIUS Trials die selben Test fahren könnten und die Ergebnisse veröffentlichen würden..

Und mit der 32 Bit Version, die nicht mehr als 4 GB addressieren kann, hat das nichts zu tun (ohne jetzt tiefer drüber nachdenken zu wollen) ?

Ich lese nur nichts darüber in dem Tröt...

Einfach abwarten: mit Cineform und DNxHR stehen zwei Codecs bereit, die das Zeug haben, Quicktime auf dem PC vergessen zu machen.

Kann sein...aber hier wird gerätselt, warum QT unter WIN so lahm ist....und Mythen aufgestellt. Soweit ich gerade lese (flüchtig), gibts QT unter WIN nur als 32 Bit Version, anstatt 64 wie unter MAC. Ich als Hausfrau würde mich jetzt mal ganz naiv fragen, ob es nicht damit was zu tun hat.
Um das gehts doch hier, oder ?

Dass eine 64Bit Version per se schneller wäre, ist durchaus argumentierbar. Der Kern des Problems scheint dennoch, dass Apple der Win Port schlicht egal ist.

Jetzt mal ganz nüchtern betrachtet...von der anderen Seite...strategisch sogar nachvollziehbar bei der augenblicklichen Entwicklung. Apple ist nun mal kein Samariter und ich denke das ich durchaus strategisch so gewollt.

Also, wenn es keine 64 Bit Version unter WIN von QT gibt, brauche ich auch nicht rumzuorakeln. Je nachdem wie die Hersteller das Problem gelöst haben und wahrscheinlich müssen sie Workarounds schaffen. Der eine schafft es effektiv im Handling, der andere garantiert nur die Funktionalität. Auch wenns lahm ist..

Ansonsten hier das Gleiche ;-)

http://hitfilm.com/forum/discussion/586 ... ons-answer

olja hat geschrieben:Jetzt mal ganz nüchtern betrachtet...von der anderen Seite...strategisch sogar nachvollziehbar bei der augenblicklichen Entwicklung. Apple ist nun mal kein Samariter und ich denke das ich durchaus strategisch so gewollt.

Na klar - durch die blosse Existenz eines ProRes-Decoders für Windows kann Apple ProRes glaubhaft als plattformübergreifenden Standard verkaufen, während durch die miese Performance unter Windows zugleich der Wettbewerbsvorteil der eigenen Plattform gesichert wird. Das macht Apple ja auch mit anderer Software wie z.B. iTunes. (Genauso, nur aufs Betriebssystem bezogen umgekehrt, hat's früher Microsoft zu seligen Word 6-Zeiten mit den ultralahmen Mac OS-Portierungen seiner Software gemacht.)

cantsin hat geschrieben: Na klar - durch die blosse Existenz eines ProRes-Decoders für Windows kann Apple ProRes glaubhaft als plattformübergreifenden Standard verkaufen, während durch die miese Performance unter Windows zugleich der Wettbewerbsvorteil der eigenen Plattform gesichert wird. Das macht Apple ja auch mit anderer Software wie z.B. iTunes. (Genauso, nur aufs Betriebssystem bezogen umgekehrt, hat's früher Microsoft zu seligen Word 6-Zeiten mit den ultralahmen Mac OS-Portierungen seiner Software gemacht.)

eben ;-)...so ist das. Man nennt es auch Wettbewerb, der die Entwicklung vorantreibt...oder auch Schachspiel..find ich nicht sooo schlimm.
Letzendlich könnten sie ja auch FCPX unter WIN bringen...wär aber unklug..:-)

Edith sagt: Hab hier im Rahmen eines Homeuseprogramms für 12 Euro die Office Suite bekommen...habe mich für MAC entschieden. gerade mal Word 2011 und nen olles Excel, Powerpoint...schweinerei ;-) Warum macht Microsoft das nicht so wie unter Win ;-)

DV_Chris hat geschrieben:Einfach abwarten: mit Cineform und DNxHR stehen zwei Codecs bereit, die das Zeug haben, Quicktime auf dem PC vergessen zu machen.

so ist es und gott sei dank haben wir noch die wahl.. und wenns die atomos geräte auf dnxhr patchen ist die welt wieder in ordnung...

Dear Shogun faithful,

We have been working hard to finalise the new AtomOS 6.2, promised for the end of February. Based on the beta version of the firmware in action at BVE (24-26th Feb) we have decided that the final public version still needs some work and won't be ready until mid March. There have been some delays due to 3D LUT compatibility testing, DNxHR official approval from Avid & working out the easiest way to implement these new more complex functions. Although we are close, our policy is always that we won’t release anything until absolutely perfect.

We realise you all want and need the new functions, however they will take around a week or so more to finalise. Sorry to keep you waiting but these are important features we want to get right.

die hersteller die sich damit auseinandersetzen müsser weil sie den support für prores brauchen setzen das um, suchen zertifizierte lösungen in zusammenarbeit mit apple und gut ists..für die anderen gilt ingest, transcode und danach weiter in ihrer standard nle...

und ja olja microsoft macht es ebenso... fängt schon bei dateisystem an wo sich die firmen wie apple und ms auch nichts schenken.. wie schon geschrieben planung der infrastruktur-kaufen-verwenden und nicht kaufen und danach herumraunzen..

Nochmal meine Frage an Slashcam: Wie habt ihr die Zeit für das Decoding gemessen?

motiongroup hat geschrieben: und ja olja microsoft macht es ebenso... fängt schon bei dateisystem an wo sich die firmen wie apple und ms auch nichts schenken.. wie schon geschrieben planung der infrastruktur-kaufen-verwenden und nicht kaufen und danach herumraunzen..

Genau so ist es. Eigenartiges Anspruchsdenken, weil nicht für die Konkurrenz performant entwickelt wird...wär auch unlogisch im dem Wettbewerb.

Also, so mystisch finde ich das alles gar nicht, 32 gegen 64 Bit laufen zu lassen und sich zu wundern, warum es langsamer ist..;-)

Also, so mystisch finde ich das alles gar nicht, 32 gegen 64 Bit laufen zu lassen und sich zu wundern, warum es langsamer ist..;-)

Klar, wer glaubt, dass ein 32bit-System per se langsamer ist als ein 64bit-System, der wundert sich nicht.
Alle anderen denken sich ihren Teil ;)

aha.....weiter geht der Mythos. Wenn ich was vergleiche, dann unter gleichen Bedingungen. ansonsten würd ich mir gar nicht die Mühe machen, oder irgendwelche Theorien aufstellen

Und addressierbare Speichergröße scheint bei 4k Files ja anscheinend auch keine Rolle zu spielen :-)

Müßig das jetzt herausfinden zu wollen. Reassemble doch einfach den code und forsche für dich weiter ;-)

Ansonsten bissl was zum Lesen
http://de.wikipedia.org/wiki/4-GB-Grenze

Mit meinem geringen Programmierung-Background würde ich mal sagen, dass alleine 32 vs. 64 Bit den Unterschied nicht erklären kann, aber je nach Register-Optimierung könnte da schon etwas Performance stecken bleiben.

Aber auch egal, was es ist. Wichtiger erscheint mir, dass man unter Windows mit ProRES 422 HQ (wie es viele Kameras und Recorder aufzeichnen) echte Prozessorleistung verschenkt, wenn man unter Resolve (und wohl auch Edius und Vegas) arbeitet. Wer sich also einen PC kauft der einen schnelleren Prozessor hat als ein Mac, auf dem er dann in erster Linie ProRES seiner Pocket schneidet, hat nichts vom schnelleren Prozessor.

Die Messung wollte ich in einem Folge-Artikel näher erläutern. Hier vielleicht schon mal ein Vorgriff zur Erklärung:

Nachdem wir festgestellt haben, dass die Prozessor-Auslastung durchaus ein gutes Maß für das Scrubbing und Playback-Verhalten eines Codecs ist, geben wir diese an. Allerdings schwankt diese während der Wiedergabe je nach Codec unterschiedlich stark. Auch hier wählen wir dann einen pragmatischen Ansatz. Wir geben anstatt einer durchschnittlichen Prozessorauslastung die Spitzenauslastung an, da uns diese besonders relevant vorkommt. Denn bei 100 Prozent Spitzenauslastung fängt jedes System zu ruckeln an, selbst wenn die durchschnittliche Auslastung nur 70 Prozent beträgt.

. ...

mehr demnächst

Ach Gott, das hab ich ja gar nicht gewusst ;)
Die Frage ist ob mehr als 4GB für die Dekodierung überhaupt was bringen. Ansonsten ist es nämlich wurscht. Und das rauszubekommen, naja, da spekulieren wir lieber mal noch bissel, wie Mircrosoft das mit Word gemacht hat ;)

On Windows Adobe had to write their own QuickTime server application to get around the 32 bit limitation of QT, but I suppose Apple is less interested in allowing that sort of workaround in OSX.


Das hab ich gerade aufgeschnappt...evtl. sollte man da dochmal nachforschen ,-)
Zumindest würde ich es tun, anstatt blind zu spekulieren.

For PC users there is a further complication and that relates to source material that uses the QuickTime 32 Server add-on, for .MOV or ProRes or even DNxHD in a QT container. QuickTime on a PC is a 32-bit application. It not only shows the dreaded 'gamma-shift' problems, but the major problem is the 32 bit nature of QuickTime. That simply means that the processing, when using the QT 32 Server add-on, occurs in a 4 GB memory space, even when 64 GB of memory is installed. The consequence is much more page-file swaps than would be normal on a system with lots of memory, causing severe performance degradation, but the other drawback is the very limited threading capability of this add-on, causing a far from efficient use of all the logical cores in the system. That is the simple reason ProRes 444, ProRes 422 and DSLR QT are ranked in the most CPU demanding column in the graph above.

Wenn Adobe die 32bit Limitation von Quicktime mit einer eigenen Application (oder Bibliothek) umgehen wollte, müsste es Quicktime Movies auch ohne installiertes Quicktime öffnen können. Ansonsten greift es eben doch auf diese Quicktime zu.
So siehts aus, Kaffeesatzleser ;)

Hab wohl die Fähigkeit, Kaffesatz auch zu deuten und nicht gleich in Verschwörungtheorien zu verfallen. Lies einfach mal...ganz langsam..oder soll ich übersetzen ?

Ich hatte mich auf den Slashcam Artikel und seine Deuter bezogen ;)
Am PC unter Premiere fast genauso schnell wie am Mac, unter Resolve (PC) dann ungefähr doppelt so lang - so die Aussagen im Artikel.
Wenn diese Performance-Unterschiede an der 4GB Grenze liegen würden, müsste Premiere die wirklich ausgehebelt haben (angeblich mit einer eigenen Bibliothek) - und dann müsste Quicktime ohne Quicktime laufen ;)

EDIT: manchmal ist es auch hilfreich, mal eine Quellenangabe zu einem Zitat zu machen.

Passt doch, nicht anderes hat Motiongroup geschrieben.
Premiere ist von Adobe...und die haben eben einen Workaround geschaffen (Adobe-QT32-Server.exe ?), andere eben nicht.