Ich spreche nicht vom Enkoding durch FFMPEG, aber das weißt Du sicher weil Du meinen beitrag gewissenhaft gelesen hast.
Auch weißt Du, dass ich nicht vom XQ rede, weil Du meinen Beitrag sehr aufmerksam verfolgt hast, das weiß ich auch (auch schon vorher hast Du das festgestellt, als ich behauptet habe, DNxHD444 hätte eine höhere Datenrate als PR4444 bei HD, so aufmerksam bist Du). Auch hast Du festgestellt dass ich den Link nicht parat habe (ich bin übrigens noch auf der Arbeit, und hatte auch keine Zeit ihn zu suchen), denn Du hast meinen Beitrag gewissenhaft gelesen.
Die Quellen qaren u.a. die Alexa, aber auch Rekorder wie der Gemini. Es ist natürlich die berechtigte Frage ob es am Codec oder an den Geräten liegt, aber da Du mir ja freundlicherweise auch Material der Alexa schickst, kann ich annehmen dass Du meinst dass eben diese ja richtige 12bit aufzeichnet (nicht XQ, aber das weißt Du ja, Du liest ja aufmerksam)
Du musst mir kein Alexa-Material schicken, ich habe hier Terabytes herum liegen, aber danke für den Link.
Hast also auch mal so Material angeschaut, find ich gut. Und hast es mal im Vektorscope durchleuchtet, durchgecheckt ob da echte 12bit anliegen oder nur den Header ausgelesen, ins Whitepaper geschaut und beschlossen, dass das so stimmt?
Ich behaupte doch nicht, er sei nicht 12bit. Nur dass ich vorsichtig wäre ihn automatisch auf ein Podest (vor anderen Codecs die nur 10bit machen) zu stellen, weil es Zweifel gab/gibt/geben wird. Macht das Whitepaper von Grassvalley halt nicht besser, DNxHD nicht schlechter.
Kannst sonst auch Googlen, da findet man dazu auch etwas; aber da Du die Antwort ja schon hast kannst Dir das ja auch sparen, knowledge is power.
olja hat geschrieben: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
Naja, immerhin habe ich über Marketing, Strategie und Unternehmensberatung seit Jahren einen professionellen Hintergrund - und ich nehme an das dies bei dir auch so ist. :)
motiongroup hat geschrieben: lies nochmals was urtona geschrieben hat.. du suchst immernoch den fehler an der falschen stelle..
Nein, ich suche nicht an der falschen Stelle - denn ich suche überhaupt diesbezüglich überhaupt nicht mehr weiter. Der Befund, dass der QT-Dekoder unter Windows Mist ist, ist halt so. Mehr ist dazu nicht zu sagen - das wird durch eine weitere Suche auch nicht anders.
Urtona hat geschrieben:Realitätsferner geht es eigentlich kaum noch.
Was soll den realitätsfern sein? Immer solche unbelegten hingeworfenen Phrasen.
Urtona hat geschrieben: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.
Typisches Beispiel - du begehst hier den Fehler dass du nur deine eigene Welt siehst. In der hast du sogar recht - warum sollte jeman der auf einem Apple editiert ProRes zu Cineform transkodieren? Stimmt - das wäre unsinnig.
Nur davon rede ich ja nicht.
Denn was ist, wenn man eben NICHT auf dieinem Macbook arbeitet sonder unter Windows? Das soll es ja auch geben.... ;) ... und dann schaut das anders aus.
Nachdem ich in der Windows-Welt das UHD-ProRes des Shoguns eben in Vegas nicht verarbeiten kann (und zwar gleich aus 3 verschiedenen Gründen), war ich auf der Suche nach einem 10bit fähigem Codec mit dem die Verarbeitung in Vegas oder auch Edius gut geht. Und für diesen Zweck kann man eben entweder zum Canopus HQX oder zum Cineform codec transkodieren. Das geht dann in diesen NLEs sehr gut - den der Canopus HQX ist in 10bit in Edius sehr performat, und der Cineform ist in Vegas nativ implementiert und daher für diese Software ideal.
Das ist ein gut funktionierender Workflow - für mich. Muss ja nicht für dich passend sein. Also bitte nicht immer alles als Unfug abtun - nur weil man selbst den Nutzen eines workflows für sich selbst nicht direkt entdecken kann.
wolfgang hat geschrieben:
Naja, immerhin habe ich über Marketing, Strategie und Unternehmensberatung seit Jahren einen professionellen Hintergrund - und ich nehme an das dies bei dir auch so ist. :)
Uiii ....Hast du dich auch beraten bei der Auswahl deiner Produktkette, Appleabhängikeit auf Windowsrechnern ohne ausgiebigen Test? Das nenn ich mal ne risikofreudige Entscheidung.
Sony gehört im Gegensatz zu vielen anderen zu den offiziellen ProRes-Lizenznehmern, wie man der offiziellen Quelle entnehmen kann (apple.com). Manifestiert sich zum Beispiel in ihrer Catalyst-Software. Ist die auch langsam unter Windows?
olja hat geschrieben:Uiii ....Hast du dich auch beraten bei der Auswahl deiner Produktkette, Appleabhängikeit auf Windowsrechnern ohne ausgiebigen Test? Das nenn ich mal ne risikofreudige Entscheidung.
Du verarschen kann ich mich auch selbst - ziehe wem anderen durch den Kakao.
Was interessierts dich? Und ja, der dort beschriebene Fehler liegt eindeutig an ihnen.
Jott hat geschrieben:Sony gehört im Gegensatz zu vielen anderen zu den offiziellen ProRes-Lizenznehmern, wie man der offiziellen Quelle entnehmen kann (apple.com). Manifestiert sich zum Beispiel in ihrer Catalyst-Software. Ist die auch langsam unter Windows?
Nein, denn der Catalyst importiert ProRes nur in der Apple Version, nicht in der Windows Version.
dienstag_01 hat geschrieben:So isser halt, der Wolfgang. Wenn irgendwas nicht klappt in seinem Samelsurium an Software - er findet den SCHULDIGEN.
Schwachsinn zum Quadrat.
dienstag_01 hat geschrieben:Das es mit Premiere laut Artikel keine Probleme gibt, ach was, lassen wir uns doch von Fakten nicht irritieren ;)
Kann ja nichts dafür dass du das Faktum nicht verstanden hast. Adobe hat halt einen eigenen Dekoder programmiert WEIL der offizielle so ein großer Mist ist. Na klar kann das theoretisch jede Firma machen. Nur das kostet Geld, warum soll das jemand investieren weil Apple halt geschlampt hat? Adobe hats halt anders entschieden - die wollen ja ihr Abo auch an Apple User verkaufen.
wolfgang hat geschrieben:
Kann ja nichts dafür dass du das Faktum nicht verstanden hast. Adobe hat halt einen eigenen Dekoder programmiert WEIL der offizielle so ein großer Mist ist.
Mist ist das, was du da gerade wieder schreibst. Adobe hat keinen eigenen Decoder geschrieben, sondern nur vernünftig an QT angedockt...mit ner Helper-Application... Premiere Pro is a 64-bit application, but the QuickTime libraries are only 32-bit, meaning that Premiere cannot interface with QuickTime directly. In order to read ProRes files via QuickTime, Premiere uses a 32-bit "Adobe QT32 Server" helper process. This is a separate 32-bit application which handles QuickTime I/O and communicates with 64-bit Premiere via the system's internal network stack.
Contrast this with other, more open formats which Adobe can support in a 64-bit application directly (via their own MediaCore engine) without relying on 32-bit helper processes and network I/O. Note that not all QuickTime files must be read via QuickTime; MediaCore can handle many QuickTime codecs itself. However, proprietary QuickTime codecs like ProRes and DNxHD must be handled via QuickTime in the manner described above.
Auch Sony muß das tun, sollte es 64 Bit sein. Ist ihnen aber wohl noch nicht so gelungen.
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 (!!) blah...
Seit wann können GoPros denn Cineform schreiben?
Weißt du überhaupt was Cineform ist?
Wenn man schon so vollmundig vom Leder zieht, sollte man vorher seine Fakten auf die Reihe bekommen.
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 (!!) blah...
Seit wann können GoPros denn Cineform schreiben?
Weißt du überhaupt was Cineform ist?
Wenn man schon so vollmundig vom Leder zieht, sollte man vorher seine Fakten auf die Reihe bekommen.
Frank Glencairn hat geschrieben:Wie steht nicht da?
Welchen Teil von "direkt beim Import GoPro 4 Cineform nach ProRes.." hast du nicht verstanden?
Glaube ich hab das schon verstanden, Go Pro Cineform nach Prores...was ist dir denn daran nicht klar ? Hier hat doch keiner vom Leder gezogen. Da steht nicht aus der GoPro Cam...sondern GoPro-Cineform nach Prores.
ansonsten..zu GoPro
Im März 2011 erwarb das Unternehmen CineForm. Die Akquisition beinhaltete die Rechte am CineForm-444-Videocodec, den GoPro seit 2011 im 3DHero-System verwendet.
Quelle WIki
Davon abgesehen nehme ich nicht diesen Umweg, sondern haue das Material (LOG) direkt in FCPX und grade das lieber da.
Die einzige Kamera die Cineform aufzeichnen kann ist die Kinefinity - die GoPros können das nicht, die schreiben nur den minderwertigen Mp4.
Da hier kaum einer die KineMini hat, dürfte kann das deshalb eher ein exotischer Workflow sein.
Cineform ist dagegen ein hochwertiger Wavelet Codec ahnlich wie R3D von Red. Deshalb würde auch niemand der noch ganz bei Sinnen ist, irgendwelches Material zuerst nach Cineform, und danach nochmal nach Prores transcodieren.
Frank Glencairn hat geschrieben:Jetzt noch mal zum mitschreiben:
Die einzige Kamera die Cineform aufzeichnen kann ist die Kinefinity - die GoPros können das nicht, die schreiben nur den minderwertigen Mp4.
Cineform ist dagegen ein hochwertiger Wavelet Codec ahnlich wie R3D von Red. Deshalb würde auch niemand der noch ganz bei Sinnen ist, Cineform nach Prores transcodieren, weil das ne Verschlechterung mit sich bringen würde.
Wer schreibt denn, das die GoPro das kann ? Oder wir reden aneinder vorbei.
Da steht doch nur GoProCineform-Codec, wo der herkommt, steht doch da nicht.
Viele pumpen ihr GoPro-Material in Cineform-Studio und legen da das Protune-Material (LOG) rein. Danach gehts eben weiter.
ansonsten guck einfach unter cineform.com Convert all camera and file-based formats into GoPro/CineForm master files
Ich glaub die Verwirrung rührt daher, dass es "GoPro Cineform" genannt wurde, wobei man dann das Produkt "GoPro" direkt in Verbindung gebracht hat.
Wobei es halt GoPro Studio heißt, aber nicht wirklich GoPro Cineform, sondern nur Cineform. Zumindest auf deren Website ist nur einmal von "GoPro Cineform" die Rede, und das nur beim Punkt Metadaten
Ja, es geht ja hier nur um den Codec. Und da Gopro Cineform gekauft hat, heißt der eben so. Und man darf auch davon ausgehen, das aus einer einer GoPro nicht nur Video kommt, sonder auch Time- und Hyperlapse aus Stills gemacht werden, die dann im Studio zusammengeschraubt werden und ggf. als Cineform exportiert werden. (Noch nicht getestet, mach ich auch alles im FCPX)
Die Archivierung verwendet das GoPro CineForm-Format. Das CineForm-Format eignet sich am besten für den Export einer qualitativ hochwertigen Master-Datei für die Übertragung zu Archivierungszwecken.
Aber was anderes wurde auch gar nicht geschrieben.
olja hat geschrieben:Und da Gopro Cineform gekauft hat, heißt der eben so.
Darüber kann man streiten, weil die Firma ihn selbst nicht so nennt.
Man sagt zwar nun Blackmagic Fusion, aber Mocha heißt nocht nicht Boris Mocha. Ist halt so eine Frage.
Aber ist ja auch Wurscht, glaube nur dass die Verwirrung mit der Kamera GoPro daher kam (weil der Codec eigentlich nicht so heißt, nur die GoPro Studio Software)
CameraRick hat geschrieben:Auch weißt Du, dass ich nicht vom XQ rede, weil Du meinen Beitrag sehr aufmerksam verfolgt hast, das weiß ich auch...
[...] Du musst mir kein Alexa-Material schicken, ich habe hier Terabytes herum liegen, aber danke für den Link.
Entschuldige, aber hast Du nicht das o.g. Whitepapoer kritisiert, eben weil es "DNxHD 444 ignoriert"? Dann berücksichtige doch bitte eben auch ProRes XQ, also beide Codecs in ihrem maximalen Leistungsumfang. Ansonsten ist es ein Vergleich zwischen Äpfeln und Birnen.
Und wenn Du denn wirklich mit Alexa Material arbeitest, frage ich mich, warum Du dann schreibst "Wenn man das am Computer rechnet, quasi mit nativen 12bit Clips (aus RAW oder 3D), kann das natürlich wieder anders aussehen..."? Denn Du kannst ja selbst sehen, wie es aussieht, liegt Dir doch mindestens 12Bit RAW "in mehreren Terabyte" vor.
wolfgang hat geschrieben:Typisches Beispiel - du begehst hier den Fehler dass du nur deine eigene Welt siehst. [...] Denn was ist, wenn man eben NICHT auf dieinem Macbook arbeitet sonder unter Windows?
[...] Das ist ein gut funktionierender Workflow - für mich. Muss ja nicht für dich passend sein. Also bitte nicht immer alles als Unfug abtun - nur weil man selbst den Nutzen eines workflows für sich selbst nicht direkt entdecken kann.
Ich bin in Teilen bei Dir - wenn für Dich ein Workflow gut funktioniert, ja dann ist es doch fein.
Wenn aber ein bestimmter Workflow - hier die Arbeit mit ProRes unter Vegas oder whatever - jedoch für Dich nicht funktioniert, dann eruiere bitte auch die Ursache konkret, bevor Du wetterst. Noch einmal: Ruckelt ProRes auf Windows-NLEs, liegt es nicht an ProRes. Und schon gar nicht an Apple.
Ich beschwere mich auch nicht, dass Avid ihre Codecs auf dem Mac nicht unter dem AV Foundation Framework implementiert, sondern nur eine QT-Version von DNxHD anbietet, und somit das System vergleichsweise mehr belastet, als ProRes. Ich antizipiere, dass es nicht zwingend Avids Sache ist, für bestmögliche DNxHD/HR -Unterstützung unter FCPX zu sorgen, sondern in dem Fall Apples.
Frank Glencairn hat geschrieben:
[blablabla]
Na, was war hier Deine Intention? Ablenkung vom Thema mit unliebsamen Fakten? Oder schlichte Provokation? Ersteres ist Dir in Teilen gelungen (herzlichsten Glückwunsch), Letzteres nicht.
motiongroup hat geschrieben:jetzt wäre es interessant wie sich Avids DNxHD HR Codes verhalten die auch via QT angebunden sind.. ist das unter Windows auch so gebremst...
Selbst unter OSX enkodiert DNxHR bei mir schneller als Prores, zumindest die 444 Varianten. Andernfalls waren sie gleich auf (422 Dinger).
Dekodieren hab ich noch nicht getestet, da bin ich mir auch nicht sicher wie so ein Testaufbau gut ginge :/
DaVinci liest meine in AE enkodierten DNxHR im MOV Container gar nicht erst.
Glaub ich blind.
Nur macht das einen neuen Test (erstmal) hinfällig, also ob die Problematik bei DNxHR ähnlich ist.
Da wird nichts ausgebremst, es ist einfach noch stillgelegt
olja hat geschrieben:Adobe hat keinen eigenen Decoder geschrieben, sondern nur vernünftig an QT angedockt...mit ner Helper-Application...
In der Branche geht diese Information herum dass sich Adobe eine eigenen Importer geschrieben hat. Mir ist ziemlich egal wie man das programmiertechnisch genau nett - kümmrt den Anwender einen feuchten Sche...
Frank Glencairn hat geschrieben:Cineform ist dagegen ein hochwertiger Wavelet Codec ahnlich wie R3D von Red. Deshalb würde auch niemand der noch ganz bei Sinnen ist, irgendwelches Material zuerst nach Cineform, und danach nochmal nach Prores transcodieren.
Eben. Es ist schon erstaunlich dass GoPro nach der Unternehmensakquisition von Cineform diesen hochwertigen Codec zum transkodieren anbietet, damit man das auf diversen Systemen schlecht abspielbare GoPro Material eben besser bearbeiten kann. Fakt ist, dass sich heute der Codec über die Gratis-Version von GoPro Studio in jedem Windows System installiert und dann anderen Applikationen zur Verfügung steht.
olja hat geschrieben:Und da Gopro Cineform gekauft hat, heißt der eben so.
Komischerweise scheint der Codec im Produkt selbst unter den Namen "Cineform" auf. Aber abgesehen davon - ist das wohl auch nicht wirklich wichtig.
motiongroup hat geschrieben:jetzt wäre es interessant wie sich Avids DNxHD HR Codes verhalten die auch via QT angebunden sind.. ist das unter Windows auch so gebremst...
Das für DNxHR zur Verfügung gestellte codec package erlaubt wenigstens den Import von Shogun-Aufnahmen in Windowsapplikationen wie Vegas und Edius. Ein erster Test zeigt, dass es in Vegas keinen Lumashift zu geben scheint - was schon mal was ist.
Vom Playback-Verhalten ist der UHD-DNxHR in ersten Tests allerdings bei mir eher noch schlechter als UHD-ProRes. Also so gesehen ist das keine echte Verbesserung - wenn aber wenigstens mal keine Lumaspreizung auftritt ist das wenigstens eine sinnvolle Verbesserung.
Wie es in Edius ausschaut habe ich mir noch nicht angesehen.
Urtona hat geschrieben:Ich bin in Teilen bei Dir - wenn für Dich ein Workflow gut funktioniert, ja dann ist es doch fein.
Wenn aber ein bestimmter Workflow - hier die Arbeit mit ProRes unter Vegas oder whatever - jedoch für Dich nicht funktioniert, dann eruiere bitte auch die Ursache konkret, bevor Du wetterst. Noch einmal: Ruckelt ProRes auf Windows-NLEs, liegt es nicht an ProRes. Und schon gar nicht an Apple.
Ich beschwere mich auch nicht, dass Avid ihre Codecs...
Na schön dass mir wenigstens ein Workflow zugestanden wird, der in Settings wie dem meinem halt tatsächlich funktioniert und sinnvoll ist. :)
Und natürlich kann man einem alten 32bit Codec vorhalten dass er so Dinge wie Lumaspreizungen und schlechten Playback-Verhalten verursacht. Und da das ein Apple Produkt ist, ist wohl Apple daran nicht unbeteiligt.
Wenn du das anders siehst dann siehst du es halt anders. Das ist dir ja überlassen. Aber ich sehe es eben anders. Seltsam dass hiermit offenbar einige echte Probleme haben dürften.
olja hat geschrieben:Adobe hat keinen eigenen Decoder geschrieben, sondern nur vernünftig an QT angedockt...mit ner Helper-Application...
In der Branche geht diese Information herum dass sich Adobe eine eigenen Importer geschrieben hat.
Und das stimmt eben nicht.
Wenn man mal auf der Adobe-Seite guckt, liest man beim Support sowas hier:
The QuickTime video out system is a black box to us: QT32 Server makes a request and receives data with no knowledge of what is happening inside QuickTime.
Und
This request is made to the QuickTime video out system, a legacy 32-bit QuickTime API that Apple no longer supports.
Ich habe mal für mich selbst einen kurzen Test beim Abspielen mit dem MPC-HC 1.7.6 unter Windows gemacht (i7-980 Sechskerner mit 3,33 GHz und Hyperthreading):
HD MOV mit ProRes HQ422 ... CPU-Last 12-15% (verteilt auf 3 echte & 3 virtuelle Kerne)
HD AVI mit Cineform 422 ... CPU-Last 5-6% (verteilt auf 4 echte & 3 virtuelle Kerne)
UHD MOV mit ProRes HQ422 ... CPU-Last 63-75% (verteilt auf 6 echte & 6 virtuelle Kerne)
UHD AVI mit Cineform 422 ... CPU-Last 12-14% (verteilt auf 5 echte & 3 virtuelle Kerne)
Mit CPU-Last ist immer die Gesamtlast des Systems bezogen auf 6+6 Kerne gemeint.
EDIT:
Der Quicktimeplayer lastet das System bei UHD MOV mit ProRes HQ422 übrigens nur mit 20% aus. Spielt aber nicht ruckelfrei, im Gegensatz zum MPC-HC.
Die Last erzeugt beim Abspielen mit Quicktime selbst die Quicktimeplayer.exe, beim MPC-HC ist es die mpc-hc.exe, dieser dekodiert ProRes über den LAV Video Decoder
wolfgang hat geschrieben: Und da das ein Apple Produkt ist, ist wohl Apple daran nicht unbeteiligt.
LOL. Da ist wohl Hopfen und Malz verloren.
Interessant ist, dass Dir nicht nur hier, sondern offensichtlich auch in Deinem eigenen Forum bereits seit Tagen von Deinem eigenen "Team" vergeblich versucht wurde nahe zu bringen, wo der Hase denn im Pfeffer liegt.
Urtona hat geschrieben:Egal. Frei nach Elbert Hubbard: Das Rezept für dauerhafte Unwissenheit ist, mit seinen eigenen Meinungen und seinem Wissen zufrieden zu sein.
Und nicht der Reflexion fähige Applefans werden nie zulassen, dass auch mal an Apple Kritik geübt wird. Das nenne ich Glückseeligkeit und selbstverschuldete Unmündigkeit.
Und zwar sage ich das - und nicht irgendein Dritter dessen Worte du dir aufgrund mangelnder Selbstständigkeit ausborgen mußt.
ich benutze doch nicht einen der Flexibelsten und besten Codecs die es gibt auf einem Produkt das dafür optimiert ist um vollkommen problemlos in sehr guter Qualität ans Ziel zu kommen.
Das ist doch nur Apple verarsche.
Ne besser einen Codec benutzen den keiner meiner Kunden lesen kann, der nicht auf jedem System funktioniert und das ganze mit 20 Worakarrounds.
Weil ich brauche Apple nicht um mich zu verarschen, ich verarsche mich selbst viel besser!
glückwunsch, alles richtig gemacht.
-------------------------------------------------------
leave the gun take the cannoli
------------------------------------------------------- www.movie-grinder.com
Es scheint sicher zu sein, dass die Red Weapon ProRes bekommt. Damit wären dann endgültig alle Profikamera-Hersteller im Boot. Das erklärt auch endlich den blöden Namen: nicht Waffe zum Filmen, sondern Waffe gegen Arri.
Schlechte Zeiten für ProRes-Hasser im Post-Bereich, spannende Zeiten für Apple und fcp x.
na ja jott, da muss sich eben was ändern unter windows.. wenn 4k prores unter windows ne peinigung unter 99.9% der applikationen darstellt wirds bei 6k noch gruseliger... nachdem qt definitiv begraben ist gibts auch keine andere möglichkeit es sei denn man will zusperren.. hat adobe unter osx auch mal versucht und ist in die hose gegangen..
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.
