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.
Möglich, dass das ein Workarround für sonstwas ist, aber nicht, um das 4GB Problem zu eliminieren.
EDIT: Wie schon weiter oben gesagt, wenn die Files ohne installiertes Quicktime laufen, dann kann man davon ausgehen, dass Adobe eine Art *eigenes* Quicktime hat.
Zuletzt geändert von dienstag_01 am Di 17 Mär, 2015 13:55, insgesamt 1-mal geändert.
macht die gegenprüfung mit qt pro und verwendet die filter und editmöglichkeiten... wenns dort auch eckt ist's eben so... wenns dort funktioniert wäre es zu überdenken worans liegt..
Ne, das Problem besteht weiterhin. Trotzdem wird eine 32 Bit Komponente, die 1.Speicherlimitierungen hat und 2. Workarounds für 64 Bit Applikationen braucht damit sie genutzt werden kann mit einem reinen 64 Bit Komponente verglichen. Da kann man nicht so tun, als dass das keine Rolle spielt.
Doch, kann man. Wenn du dir die unterschiedlichen Werte von Mac und PC für Premiere und PC und PC für Premiere und Resolve anschaust, kommst du vielleicht auch auf die Möglichkeit anderer Gründe ;)
dienstag_01 hat geschrieben:Doch, kann man. Wenn du dir die unterschiedlichen Werte von Mac und PC für Premiere und PC und PC für Premiere und Resolve anschaust, kommst du vielleicht auch auf die Möglichkeit anderer Gründe ;)
Eine 64 Bit Applikation kann die 32 Bit QT gar nicht direkt nutzen und es erfordert einen Workaround, die bei einem schlecht mit Reibungsverlusten, bei dem anderen effektiv und gut gelöst sind.
Grund ist aber trotzdem die 32 Bit Version und wenn es eine 64 er geben sollte, dann würde Resolve wahrscheinlich genau so arbeiten wie auf dem Mac. Adobe hat's eben gelöst.
ich habe das Gefühl das der Mercedes Motor im Force India auch langsamer ist als der Mercedes Motor im Mercedes.
Ich bitte um Aufklärung, weil das für mein Leben ungemein wichtig ist.
-------------------------------------------------------
leave the gun take the cannoli
------------------------------------------------------- www.movie-grinder.com
Ja, genau so kann man es sehen. Wenn ich nen verlustreiches Getriebe dazwischen habe, bleibt nur der Name.
Mal von der Abobeseite:
Adobe After Effects CS5 and Adobe Premiere Pro CS5 use TCP to communicate with the QuickTime server (Adobe QT32 Server) and Dynamic Link manager. Some firewall software (such as ZoneAlarm) blocks this communication, mistaking it for a security threat. The communication between these components is limited to the local computer, which is enough for most firewall software to recognize the communication as safe. Some firewall software, however, requires that connections to these components are explicitly allowed.
Und evtl. machen das ja andere Hersteller ähnlich oder anders. (Resolve QTDecoder.exe ?) Aber man sieht, das bei dem Workaround sogar Firewalls zum Versagen der Applikation führen kann, da das ganze über TCP geschieht.
Und das ganze Geraffel muß sein, weil die 32erQT Komponente nicht angesprochen werden kann.
Peppermintpost hat geschrieben:ich habe das Gefühl das der Mercedes Motor im Force India auch langsamer ist als der Mercedes Motor im Mercedes.
Ich bitte um Aufklärung, weil das für mein Leben ungemein wichtig ist.
:) ganz genau... du hast die geschichte doch selbst schon getestet..drecks zeug dieses prores unter windows..
Grund ist aber trotzdem die 32 Bit Version und wenn es eine 64 er geben sollte, dann würde Resolve wahrscheinlich genau so arbeiten wie auf dem Mac. Adobe hat's eben gelöst.
Das ist deine Annahme ;)
Das die sehr wahrscheinlich nicht den Tatsachen entspricht zeigt, dass 64bit Mac und 32bit PC einen viel geringeren Unterschied machen als eine laut Vermutung gut bzw. schlecht programmierte Schnittstelle zu Quicktime vom PC aus (Premiere und Resolve). Oder anders: wenn QT von mehr als 4GB wirklich profitieren würde, sollte es als 64bit Application signifikant schneller arbeiten als die 32bit-ige. Tut es aber nicht. Ergo kann man sagen: die Anbindung an die Software spielt eine viel entscheidendere Rolle als die 4GB Limitation ;)
Und das der Artikel beschreibt, nur bei Prores gab es solchen gravierenden Unterschiede, sollte einen eigentlich nochmal in ganz andere Richtungen denken lassen ;
selbst unter edius wie in diesem beispiel spielt doch die geschichte sogar im mischbetrieb als pip mit unterschiedlichem quellmaterial inkl prores422hq in RT ab..;) wahnsinn was alles möglich ist.. :)
Grund ist aber trotzdem die 32 Bit Version und wenn es eine 64 er geben sollte, dann würde Resolve wahrscheinlich genau so arbeiten wie auf dem Mac. Adobe hat's eben gelöst.
Das ist deine Annahme ;)
Das die sehr wahrscheinlich nicht den Tatsachen entspricht zeigt, dass 64bit Mac und 32bit PC einen viel geringeren Unterschied machen als eine laut Vermutung gut bzw. schlecht programmierte Schnittstelle zu Quicktime vom PC aus (Premiere und Resolve). Oder anders: wenn QT von mehr als 4GB wirklich profitieren würde, sollte es als 64bit Application signifikant schneller arbeiten als die 32bit-ige. Tut es aber nicht. Ergo kann man sagen: die Anbindung an die Software spielt eine viel entscheidendere Rolle als die 4GB Limitation ;)
Und das der Artikel beschreibt, nur bei Prores gab es solchen gravierenden Unterschiede, sollte einen eigentlich nochmal in ganz andere Richtungen denken lassen ;
Warum plapperst du es jetzt erst nach ? Ich habe geschrieben entweder oder....im ersten Ansatz, nachdem hier wildeste Diskussionen über Apples Unfähigkeit enstanden waren. Der Grund ist für mich die 32 Bit QT Komponente.
Und ob das Speicheradressieren ne Rolle spielt, wissen die Hersteller, mehr braucht man hier nicht spekulieren. Oder eben beides, die Anbindung an QT hatte ich ebenfalls beschrieben.
Bleibst du bei der Aussage, das es egal ist und keine Rolle spielt ? Jedenfalls scheint ja Resolve zu Wuppen auf 64Bit QT, je nachdem wie die Anwendung eben gestrickt ist.
Und nochmal...
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.
Ja, du sagst es: Für dich ;)
Vielleicht testet ja Slashcam noch einen anderen 4K Codec mit Quicktime, dann wissen wir genaueres. Zumindest haben sie ihren Artikel nicht *Das 32bit QT-Problem* betitelt. Du würdest das ja machen ;)
Ich würde jedenfalls keinen daraus keinen Mythos bauen, sondern mir die Unterschiede erstmal angucken. Und da springt nunmal die 32 Bit QT Komponente ins Auge, die so nicht ohne Umwege angesprochen werden kann, bzw auch Speicherlimitierungen hat.
Einfach mal Google anwerfen und die Sache weiterverfolgen. Mir ist es eh wurscht, brauch ich eh nicht. Evtl. aber mal einen Gedanken wert, bevor das Gejammer weiter in die falsche Richtung geht ;-)
Warum fällt da denn bei 4K auf ? Mir fallen da auf Anhieb ganz andere Speicherdimensionen ein, die geschaufelt werden müssen bzw. werden die Limitierungen jetzt erst sichtbar.
Slashcam..Die einzelnen Prozesse (Auslastung) schon mal untersucht ? Evtl. macht ja die Schnittstelle richtig Stress (QT-Decoder bei Resolve ? so in der so in der Richtung...QT-Server bei Adobe) Und wenn TCP als Transport genommen wird, dann mal Netzwerkperformance gucken...so als erster Ansatz.
Also nicht nur die Prozessorleistung, sondern sich die einzelnen Prozesse angucken.
Jeder Codec ob komprimiert oder unkomprimiert hat seine eigenen Vor- und Nachteile. Auch unkomprimierte Codecs verhalten sich nicht alle gleich, und werden zusätzlich je nach verwendeter Software unterschiedlich performant unterstützt. Das gilt nicht nur für ProRes, sondern für alle bekannten Codecs.
Das ProRes im Speziellen nicht das Performance Wunder ist, das ist jedem klar der schon einmal unterschiedliche Codecs benutzt hat. Auch das gilt für ProRes auf Mac und auf dem PC. Auch auf dem Mac gibt es Codes die deutlich performanter laufen als ProRes.
Jeder Codec ist ein Kompromiss den wir eingehen, bei dem wir Performance, Qualität, Datenmengen, Kompatibilität und Benutzerfreundlichkeit gegeneinander abwegen.
Wer die Überschrift des Slashcam Beitrags liest stellt ja sofort fest, das ProRes hier unter speziellen Vorzeichen getestet wurde, nämlich ProRes als Arbeits Codec für 4k.
Apple hat diesen Codec aber entwickelt als HD in den Startlöchern stand und noch weitestgehend SD produziert wurde. Bei der Benutzung von ProRes im HD Kontent hat ja keiner Probleme, selbst ein i3 oder C2D Prozessor hat ausreichend Rechenleistung um ProRes 444 in HD Ruckelfrei abzuspielen.
ProRes ist ein Codec der sehr Benutzerfreundlich ist, die Qualität ist für einen Komprimierten Codec ausgezeichnet, die Datenmengen sind niedrig und die Kompatibilität ist hervorragend.
Bei ProRes also davon zu sprechen, das Apple einen schlechten Job gemacht hat, oder der Vergleich mit dem Brandstifter sind absurd.
Wenn dem so wäre, dann würde ich darum bitten hier mal einen alternativen Codec zu nennen, wo der Job besser gemacht wurde.
Der einzige verbreitete Codec der als echte Alternative zu ProRes bezeichnet werden kann ist DNxHD. Die Qualität von DNxHD spielt ungefähr in der gleichen Liga wie ProRes, die Performance ist deutlich besser, dafür ist es bei weitem nicht so Benutzerfreundlich, und mit schlechterer Kompatibilität.
Aber es steht ja jedem frei diesen oder einen anderen Codec zu benutzen.
Das Apple aber nicht die maximale Aufmerksamkeit aufwendet um ProRes auf Windows performanter zu machen ist doch auch nicht weiter verwunderlich. Zum einen ist 4K Editing nur für einen homöopatischen Anteil Ihrer Kunden interessant, weil ein Grossteil selbst der Videoaffinen noch unter 1080 arbeiten, zum anderen verkauft Apple nunmal keine Windows Rechner, und zum guten Schluss muss man sich natürlich auch einmal Gedanken machen in wie weit es überhaupt sinnvoll ist in 4k zu schneiden.
4K in ProRes 444 bedeutet eine Datenrate von über 200mb/sec (nur geschätzt, nicht nach gerechnet), die aller meisten Systeme auf dem Markt liegen aber bei einer konstanten Datenrate von unter 100mb/sec.
Das eine moderne SSD auch gerne einmal 500mb/sec liefert ist dabei uninteressant, weil ich noch nirgendwo in keiner einzigen professionellen Postproduktion Workstations mit SSD Raids gesehen habe (bedeutet nicht das es das nicht gibt), macht auch keinen Sinn weil der Preis pro GB bei SSDs einfach noch viel zu hoch ist. Genau das gleiche gilt für Netzwerke auch hier ist der Standart unter 100mb/sec.
Also ich finde den Slashcam Test interessant weil ich daraus ggf Performance Probleme ableiten bzw verhindern oder einschätzen kann.
Eine weitere Bedeutung hat der Test aber nicht, und da es sowieso keine Alternative zu ProRes gibt bleibt nicht mehr als das einfach als gegeben zu akzeptieren.
Einzig die jenigen die ausschliesslich mit ProRes arbeiten, aber noch auf einem PC unterwegs sind könnten sich aufgrund des Beitrags überlegen OSX als Betriebssystem in Betracht zu ziehen. Mehr nicht.
Apple bashing aufgrund des Slashcam Beitrags entbehrt jeder Grundlage.
Da gibts ganz andere Dinge wofür Apple Bashing auch verdient hat.
-------------------------------------------------------
leave the gun take the cannoli
------------------------------------------------------- www.movie-grinder.com
Peppermintpost hat geschrieben:
Einzig die jenigen die ausschliesslich mit ProRes arbeiten, aber noch auf einem PC unterwegs sind könnten sich aufgrund des Beitrags überlegen OSX als Betriebssystem in Betracht zu ziehen. Mehr nicht.
.
Aus der Sicht gesehen natürlich richtig. Auf Portierungen und Gnade eines Herstellers für ein anderes System zu hoffen (wenn er nicht durch Hardware die Finger im Spiel hat), ist doch immer mit ein wenig Risiko behaftet. Man sollte schon vorher wissen, was man will und wer zuerst beliefert wird, bzw. was man zwecks Wettbewerbsvorteil einfach liegen lässt.
Siehe in diesem Thread hier. Evtl. hat der Test ja auch gezeigt, wo jetzt die Grenzen liegen, oder man erschlägt das Problem mit Hardware ;-).
motiongroup hat geschrieben:
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..
Durchaus nen Gedanke...4k Prores ...gleiche Hardware, gleiches QT ;-)
Peppermintpost hat geschrieben:Apple hat diesen Codec aber entwickelt als HD in den Startlöchern stand und noch weitestgehend SD produziert wurde.
Das ist durchaus richtig - aber dennoch ist der Codec eben nicht ausreichend weiter entwickelt worden. Das beobachtet man bei anderen Codecs eben nicht, die werden sehr wohl weiter entwickelt oder ergänzt. Gutes Beispiel ist der Canopus HQX, der den Canopus HQ ergänzt/nachgefolgt ist.
Peppermintpost hat geschrieben:Bei der Benutzung von ProRes im HD Kontent hat ja keiner Probleme, selbst ein i3 oder C2D Prozessor hat ausreichend Rechenleistung um ProRes 444 in HD Ruckelfrei abzuspielen.
Nur hat sich die Welt eben weiter entwickelt. Nimm das Material eines Shoguns in UHD-ProRes 422, oder eines Q7 und teste das. Du wirst feststellen dass du es nicht einmal auf dem von Slashcam genannten Testrechner i7 2600K übertaktet auf 4.4. Ghz aus allen Anwendungen ruckelfrei abspielen kannst.
Peppermintpost hat geschrieben:ProRes ist ein Codec der sehr Benutzerfreundlich ist, die Qualität ist für einen Komprimierten Codec ausgezeichnet, die Datenmengen sind niedrig und die Kompatibilität ist hervorragend.
Stimmt leider so absolut nicht, zumindest nicht in der Windows-Welt. Zahlreiche Applikationen haben beim ProRes Lumaspreizungen - und je nach ProRes Quelle manchmal auch Farbveränderungen. Kompatibel würde ich das daher nicht nennen.
Wenn du meinst das ProRes alteingessesen ist - dann definitiv ja. Aber wir erleben mit dem Codec in Wirklichkeit immer wieder unsere blauen Wunder.
Peppermintpost hat geschrieben:Bei ProRes also davon zu sprechen, das Apple einen schlechten Job gemacht hat, oder der Vergleich mit dem Brandstifter sind absurd.
Wenn dem so wäre, dann würde ich darum bitten hier mal einen alternativen Codec zu nennen, wo der Job besser gemacht wurde.
Natürlich hat Apple einen schlechten Job gemacht. Wobei ich die Argumente mit dem Konkurrenzverhältnis zur Windows-Welt sogar nachvollziehen und verstehen kann. Aber bitte dann sollten sie halt gar keinen Codec für Windows publizieren und den nicht weiter zu entwicklen - und um den Eindruck zu erwecken dass dieser Codec plattformübergreifend sei.
Denn ihr vergeßt hier, dass es nicht Microsoft ist der die Probleme hat. Die Probleme haben die kleinen Anwender, die unter den Performance-Problemen leiden. Microsoft tut das eher wenig weh.
Und da Apple genau wissen muss wie schlecht der Codec im UHD-4K-Zeitalter performt - denn frei skalierbar ist der Codec ja seit geraumer Zeit - wäre hier eine Überarbeitung durchaus mal angebracht gewesen.
Und weil du nach alternativen Codecs frägst: na klar gibts die. Nimm den Canopus HQ, Canopus HQX, Canopus YUV, Cineform, XAVC. All diese Codecs sind durchaus performater - und zwar auch unter 4K/UHD.
Die Canopus codecs sind ja inzwischen auch gratis für den Endanwender erhältlich, Cineform etwa über die Installation der Gratisversion von GoPro Studio.
Peppermintpost hat geschrieben:Der einzige verbreitete Codec der als echte Alternative zu ProRes bezeichnet werden kann ist DNxHD. Die Qualität von DNxHD spielt ungefähr in der gleichen Liga wie ProRes, die Performance ist deutlich besser, dafür ist es bei weitem nicht so Benutzerfreundlich, und mit schlechterer Kompatibilität.
Aber es steht ja jedem frei diesen oder einen anderen Codec zu benutzen.
DNxHD ist performater, aber auch für den gibt es Applikationen wo er leider nur unter Farbverschiebungen arbeitet. Konkret ist das etwa in Edius der Fall - in Vegas hingegen wieder nicht. Leider ist der Codec halt auf HD begrenzt - ich bin schon gespannt wie DNxHR sein wird.
Und ich würde dem nicht zustimmen, dass dies DNxHD die einzige Alternative zu ProRes ist - die Liste alternativer Codecs ist durchaus lange. Siehe oben.
Die Tests unter Edius und Vegas habe ich übrigens schon vor geraumer Zeit veröffentlicht - zwar nicht mit der Messung die hier gemacht worden ist. Aber da ich ziemlich genau die gleiche Maschine verwendet - auch einen i7 2600K 4.3 Ghz - kann ich genau sagen, dass unter Vegeas und Edius das UHD-ProRes nicht einmal mehr ruckelfrei abgespielt werden kann. Bei Vegas läuft es mit reduzierter Framerate (obwohl auf der gleichen Maschine UHD mit den genannten anderen codecs durchaus noch läuft), und bei Edius läuft der Puffer leer. So gesehen ist das alles bekannt.
zu den Codecs die du aufgezählt hast. Canopus funktioniert meines Wissens nicht auf Mac oder Linux, ich konnte auch bei Google nichts entsprechendes finden.
Cineform hab ich selbst noch nie benutzt, hab mir aber von befreundeten Post Menschen sagen lassen, das sie es IMMER SOFORT in irgend ein anderes Format wandeln weil es sich so schlecht verarbeiten lässt, aber das kann ich nur so wieder geben ohne eigene Erfahrung damit zu haben.
XAVC ist ein Kamera Format aber kein Produktions Format wenn ich nicht irre.
Aber alle von dir aufgelisteten Codecs haben alle gemeinsam, das man den dafür entsprechenden Codec erstmal instllieren muss, was teilweise nicht einfach ist entsprechende Installer zu finden.
Das gilt natürlich auch für die von mir beforzugten Codecs DNxHD oder Blackmagic YUV, aber ProRes hat nunmal den gewaltigen Vorteil, das es im Grunde ohne Probleme auf jedem System zu benutzen ist durch die extrem hohe Verbreitung von Quicktime.
Das spricht nicht gegen deine Codecs aber sie sind halt genau so speziell wie DNxHD und damit nur für eine kleine Zielgruppe.
@Goldwing
prores 422 und DNxHD220 haben beide die gleiche Farbtiefe, Datenrate und Kompressionsverhältniss, die spielen also genau in der gleichen Liga, ProRes444 ist ein RGB und kein YUV Codec wie DNxHD oder ProRes422 und der spielt entsprechend natürlich in einer anderen Liga da hast du recht, daher ist er auch ein sehr guter Intermediate Codec aber RGB sendet nunmal keiner ;-)
-------------------------------------------------------
leave the gun take the cannoli
------------------------------------------------------- www.movie-grinder.com
Man kann ja ganz allgemein mal fragen, wieso einige Cam- und Recorder-Hersteller auf ProRes setzen. Vielleicht gabs ja n paar IPads von Aple für nass ;)
Da lob ich mir DNxHD, ein File, auf beiden Systemen verwertbar, ohne Zucken, so macht es Sinn.
Mal wieder viel Lärm um nichts. Zunächst mal hat das mit ProRes an sich als Codec mal so gar nichts zu tun, sondern mit dem Framework, das für seine Verarbeitung besorgt: Quicktime auf dem PC, AV Foundation (namens Core Media etc) auf dem Mac.
Im Übrigen verarbeitet das 64Bit AV Foundation Framework auf dem Mac auch nur H.264 und ProRes, keine Fremd-Codecs - diese werden eben auch auf dem Mac mit Quicktime 32Bit dekodiert, denn Quicktime wurde auch dort nie auf 64Bit gehoben.
Daher auch, Zitat Artikel: "Die Unterscheide beliefen sich bei allen anderen Codecs im Rahmen von +/-15 Prozent. Nur bei ProRES gab es einen signifikanten Unterschied." (Im Übrigen ist wohl ProRes gemeint, wie im gesamten Artikel.)
Zum schwarzen Peter: Apple entwickelt Quicktime schon seit Jahren auf dem Mac nicht mehr weiter, und soll dann für die geneigten PC-User für eine anständige ProRes-Decodierung /- Encodierung sorgen? Sischer, sischer... :-)
Ich rufe gern in Cupertino an und mach mich stark, wenn Adobe Pr und Ae auf dem Mac die QTkit-Krücke entzieht und auf AV Foundation setzt, wie hier in Aussicht gestellt:
"We have made significant progress in moving away from the QuickTime API's, and towards either writing the files natively or with the assistance of the AV Foundation API. Apple is deprecating QuickTime, integrating the important functions of that platform into Mac OS via AV Foundation. After Effects has a lot of code that relies on QuickTime API's, and it is important that we proceed carefully in following Apple's API changes, as moving the code between API's is a complex task." (https://forums.adobe.com/message/6045338)
dienstag_01 hat geschrieben:Man kann ja ganz allgemein mal fragen, wieso einige Cam- und Recorder-Hersteller auf ProRes setzen. Vielleicht gabs ja n paar IPads von Aple für nass ;)
Vor allem so unbedeutende Iditoten wie Arri und Sony :-)))...Jo, für nen paar IPads ändert man schon seine Strategie..
Der Tröt ist lustig...macht viel Freude...vor allem Wolfgang, der es noch nicht kapiert hat.
QT unter WIn ist eben anders als unter OSX...die Krücken die dafür gebaut werden müssen sollten dir nach dem Thread auch klar sein.
Es nutzt nichts wütend auf dem Boden rumzutrapeln....QT unter Win und 4k ProRes ist jetzt einfach mal kacke...und ? Gibt doch genug Alternativen, Software, Hardware oder OS...
wolfgang hat geschrieben:
Natürlich hat Apple einen schlechten Job gemacht. Wobei ich die Argumente mit dem Konkurrenzverhältnis zur Windows-Welt sogar nachvollziehen und verstehen kann. Aber bitte dann sollten sie halt gar keinen Codec für Windows publizieren und den nicht weiter zu entwicklen - und um den Eindruck zu erwecken dass dieser Codec plattformübergreifend sei.
.
Clever, oder ? :-))...auf Apple läufts dann eben besser...das ist die Botschaft
zu den Codecs die du aufgezählt hast. Canopus funktioniert meines Wissens nicht auf Mac oder Linux, ich konnte auch bei Google nichts entsprechendes finden.
Cineform hab ich selbst noch nie benutzt, hab mir aber von befreundeten Post Menschen sagen lassen, das sie es IMMER SOFORT in irgend ein anderes Format wandeln weil es sich so schlecht verarbeiten lässt, aber das kann ich nur so wieder geben ohne eigene Erfahrung damit zu haben.
XAVC ist ein Kamera Format aber kein Produktions Format wenn ich nicht irre.
Du hattest nach Codecs gefragt - und nicht gesagt dass du das für den Mac oder Linux haben willst. Es gibt diese Codecs, darüber brauchen wir eigentlich nicht zu diskutieren.
Dass sich hier die Welt in ihre Lager aufteilt ist halt leider so. Natürlich wurden mit Cineform Kinofilme produziert, natürlich kann man längst XAVC in der Windows-Welt nativ editieren - und um den 10bit Charakter zu erhalten auch als Ausgabeformat verwenden. Heute sehen wir etliche neue Wege, die beschritten werden.
olja hat geschrieben:Der Tröt ist lustig...macht viel Freude...vor allem Wolfgang, der es noch nicht kapiert hat.
Lieber Freund oder liebe Freundin (Hausfrau?), ich glaube ich habe das besser kapiert als du.
Und nein: es ist nicht clever von Apple Kunden derart zu veraschen, indem man sie mit schlecht funktionieren Produkten quält und sie gängelt. Ganz im Gegenteil - wenn du glaubst dass heute so nachhaltige Kundenbindung funktioniert dann hast du die Grundlagen nicht verstanden.
Ich will und werde hier keine grundsätzliche Diskussion um Apple führen - aber für mich ist dieser Codec eben genau die gegenteilige Botschaft: vertraue nicht auf etwas von Apple - denn du fällst damit nur rein. Das lehrt mich die Investition in den Shogun und die Codec-Thematik.
Und wer will den eine Marke kaufen der er nicht vertrauen kann? Keiner!
Ich hoffe wir sehen für meinen Shogun wirklich in naher Zukunft DNxHR. In der Zwischenzeit wandle ich ProRes zu Cineform und gut ist es.
Ich will und werde hier keine grundsätzliche Diskussion um Apple führen - aber für mich ist dieser Codec eben genau die gegenteilige Botschaft: vertraue nicht auf etwas von Apple - denn du fällst damit nur rein. Das lehrt mich die Investition in den Shogun und die Codec-Thematik.
gelungen wolfgang :-) lies nochmals was urtona geschrieben hat.. du suchst immernoch den fehler an der falschen stelle..
wolfgang hat geschrieben:
Lieber Freund oder liebe Freundin (Hausfrau?), ich glaube ich habe das besser kapiert als du.
Und nein: es ist nicht clever von Apple Kunden derart zu veraschen, indem man sie mit schlecht funktionieren Produkten quält und sie gängelt. Ganz im Gegenteil - wenn du glaubst dass heute so nachhaltige Kundenbindung funktioniert dann hast du die Grundlagen nicht verstanden.
Na dann lieber Freund :-)...
Welches Produkt soll dich denn an Apple binden ? Sony Vegas ? Apple hat QT32 bereitgestellt, die Specs sind in einem fast 500 Seiten PDF-Dokument im Internet für jeden lesbar. Adobe hat es offensichlich geschafft, eine performante Schnittstelle zu bauen, Edius, Vegas und Resolve womöglich nicht...Und auch nicht Hitfilm oder sonstwer...
Du würdest als Hersteller natürlich zusehen, das die Konkurrenz immer genau so perfomant läuft...notfalls statten wir sie ebenfalls mit einem 64 Bit Quicktime aus...damit es gar keine Unterschiede gibt....
Träum mal weiter...oder mach die Augen auf, wie der Markt funktioniert und kauf das, was passt.
Gibt genug Alternativen ;-) ..aber rumzumosern, weil Apple-Produkte auf PC-NLE's nicht mehr so performant sind...ist einfach nur naiv..ganz ehrlich
wolfgang hat geschrieben:
Und nein: es ist nicht clever von Apple Kunden derart zu veraschen, indem man sie mit schlecht funktionieren Produkten quält und sie gängelt. Ganz im Gegenteil - wenn du glaubst dass heute so nachhaltige Kundenbindung funktioniert dann hast du die Grundlagen nicht verstanden.
[...] Und wer will den eine Marke kaufen der er nicht vertrauen kann? Keiner!
[...] In der Zwischenzeit wandle ich ProRes zu Cineform und gut ist es.
Realitätsferner geht es eigentlich kaum noch.
An Nörgelei mangelt es diesem Forum ja wahrlich nicht, aber auch mit viel Mühe fällt es schwer, auch nur einen Beitrag zu finden, indem sich ein Mac-Cutter, der nicht eben bis zum Hals im A.... von 90er NLE-Bedienkonzepten steckt, mit einem schlecht funktionierendes System quält.
ProRes nach Cineform zu transkodieren ist allerdings ein erfrischender Vorschlag für einen Workflow, von dem man sich als "gegängelter" Apple-Kunde allerdings nichts annehmen sollte.
Im Gegenteil wandelt man hier direkt beim Import GoPro 4 Cineform nach ProRes um, und kann sich so auch an ein problemloses (!) Editing mit 4K Streams on Location auf einem Macbook (!!) erfreuen. Klingt komisch, ist aber so.
Das eröffnet dann auch ein paar Zeitfenster, die es erlauben, hier Beiträge für taube Ohren zu schreiben.... Over, und so was von out.
Das Whitepaper ignoriert auch einfach mal zur Gänze, dass es einen DNxHD 444 gibt, der sogar eine höhere Datenrate als Prores4444 aufweist.
Nur 10bit, aber da gibts ja auch genug Rufe, ob Prores überhaupt auf echte 12bit bringt (Whitepaper sagen halt auch nicht immer alles)
CameraRick hat geschrieben:
Das Whitepaper ignoriert auch einfach mal zur Gänze, dass es einen DNxHD 444 gibt, der sogar eine höhere Datenrate als Prores4444 aufweist.
ProRes 4444 XQ - 12 Bit, 500 MBit/s, und ein Alphakanal mit bis zu 16 Bit.
Urtona hat geschrieben:ProRes 4444 XQ - 12 Bit, 500 MBit/s, und ein Alphakanal mit bis zu 16 Bit.
Sticht. Jetzt Du.
Ich sprach von dem Normalen, nicht XQ.
Wobei der XQ ja auch bei GrassValley keine Erwähnung findet (glaube auch dass der neuer ist, als deren Whitepaper)
Hat keiner behauptet. Aber wenn mehrere Leute, die Material untersuchen etc zu dem Schluss kommen, dass da irgendwie mehr 10 als 12bit drin sind, kommt man halt ins Grübeln.
Oder ist es automatisch wahr, wenn es in einem Whitepaper steht? Dann sollten alle Firmen ihre Marketingabteilung die Sachen in Whitepaper schreiben lassen, das wird ein Fest :)
Keine Ahnung was Du denkst, aber ich pflege leider keine Lesenzeichen-Sammlung mit dem Titel "Links, um in Forendiskussionen echt smart auszusehen" :/
Waren u.a. Beobachtungen von den FFMPEG Leuten als die Frage aufkam, wieso PR4444 in ffmpeg nur als 10bit geht und kein 12 bit da wäre.
Es ging darum, dass in PR444 aufgenommene Signale nachweislich nicht 12bit gewesen sind; Material aus div Quellen (Kamera, Rekorder) die nativ PR4444 aufnehmen wurden da beschaut.
Wenn man das am Computer rechnet, quasi mit nativen 12bit Clips (aus RAW oder 3D), kann das natürlich wieder anders aussehen; aber das finde ich im Endeffekt überhaupt nicht so interessant, wenn die Quelle mitunter schon nicht hinter her kommt.
Ich meins nicht bös, aber nur weil Dinge in einem Whitepaper stehen heißt es eben nicht automatisch dass das auch alles richtig ist und so. Schau mal ins Grassvalley Whitepaper, das ist zwar so nicht direkt falsch aber ziemlich unvollständig; da fängt es ja schon an.
Wahrscheinlich belächelst Du das jetzt, und denkst sonst etwas von mir. Aber darf ich Dich fragen: was gibt Dir die Gewissheit dass es unbedingt 12bit sind? Weils im Whitepaper steht oder aus anderen Gründen?
CameraRick hat geschrieben:Waren u.a. Beobachtungen von den FFMPEG Leuten als die Frage aufkam, wieso PR4444 in ffmpeg nur als 10bit geht und kein 12 bit da wäre.
Jau, alles, aber auch alles liegt an ProRes.
Die FFMPEG Leutchen, auf die Du anspielst, haben seit 2013 Probleme, mit FFMPEG 12 Bit rauszurechnen. Könnte das wohl an FFMPEG liegen (Rethorische Frage)?
CameraRick hat geschrieben:Es ging darum, dass in PR444 aufgenommene Signale nachweislich nicht 12bit gewesen sind
Nachweislich? Quelle?
Und bitte nicht von irgendwelchen Foren-Leutchen...
CameraRick hat geschrieben: Wenn man das am Computer rechnet, quasi mit nativen 12bit Clips (aus RAW oder 3D), kann das natürlich wieder anders aussehen; aber das finde ich im Endeffekt überhaupt nicht so interessant, wenn die Quelle mitunter schon nicht hinter her kommt.
Welche Quelle kommt da nicht hinterher? Konkret?
Einfach mal weniger spekulieren, und einfach mal spekulatives Hörensagen-Foren-Gebrabble nicht immer als gesetze Wahrheit verkaufen. Die Zeit lieber ins Verifizieren der eigenen Argumentation investieren:
ALEXA Footage in allen ProRes Derivaten bis einschließlich 4444 XQ sowie ARRIRAW (definitiv 12 Bit) und auch DNxHD zum Download und lustigem Transkodieren und Verifizieren.
Das Ergebnis lässt sich aber vorwegnehmen: Ruckelt ProRes und/oder ist nicht bis 12Bit tief, such den Fehler nicht beim Codec....
Rechtliche Notiz: Wir übernehmen keine Verantwortung für den Inhalt der Beiträge
und behalten uns das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.
