Quicktime für Windows ist unsicher und die Lücken werden nicht mehr gefixt. So tönt es heute aus der Presse. Wir fassen zusammen was Videobearbeiter unter Windows bedenken sollten....
Lösung:
1. Quicktime plugin im Browser abschalten, tut sowieso jeder HTML5 Video.
2. Quicktime für Editing weiterverwenden
3. So, wo war nun das Problem ?
Nunja.. das ist die "ich will weiter arbeiten" Lösung, aber ich glaube Apple hat damit sämtliche ProRes Gerätehersteller (recorder,player,ingest,transcode) gründlich verarscht. Weil: Produktion rein nur auf Macs ? Apple träumt wohl.
Wer neue Videopipelines aufbaut wird nun alles tun und ProRes meiden. Es geht dann in Zukunft (abgesehen von RAW), um DNxHD vs Cineform.
Hey, weiss einer hier was mit dem GPU Codec DANIEL von Cinegy nun los ist ? Das Teil ist Klasse, aber closed...
Und wann baut denn einer mal ein open source video/audio container für OpenEXR ? Wir leben immer noch im image-sequenz Zeitalter. Und nein, MXF ist mit EXR reiner Pfusch.
1. In: 4K 12bit RAW 444 ACES 15-Fstops
2. Out: HD 8bit H264 420 rec.709 8-9 Fstops
3. Shit!
enilnacs hat geschrieben:
Wer neue Videopipelines aufbaut wird nun alles tun und ProRes meiden. Es geht dann in Zukunft (abgesehen von RAW), um DNxHD vs Cineform.
Wenn eher DNxHR, und der macht ohne Quicktime bisher auch keinen Spaß auf Windows. Da müste Avid noch einmal umbauen.
enilnacs hat geschrieben:
Und wann baut denn einer mal ein open source video/audio container für OpenEXR ? Wir leben immer noch im image-sequenz Zeitalter. Und nein, MXF ist mit EXR reiner Pfusch.
enilnacs hat geschrieben:
Wer neue Videopipelines aufbaut wird nun alles tun und ProRes meiden. Es geht dann in Zukunft (abgesehen von RAW), um DNxHD vs Cineform.
Wenn eher DNxHR, und der macht ohne Quicktime bisher auch keinen Spaß auf Windows. Da müste Avid noch einmal umbauen.
enilnacs hat geschrieben:
Und wann baut denn einer mal ein open source video/audio container für OpenEXR ? Wir leben immer noch im image-sequenz Zeitalter. Und nein, MXF ist mit EXR reiner Pfusch.
ja du hast recht, HR, das meinte ich.
Mit MXF sebst, kein Problem, es ist Standard. Ich meinte MXF als EXR container. Das dauert noch lange. War bei RAW auch so.
Apropos Daniel.. warum nicht ? Cinegy sollte das Ding open source machen dann haben Alle was davon. Oder zumindest license-based wie MPEG. Anstatt irgendwo zu verrotten. 4300(!!!) fps bei 4K und 1100fps(!)bei 8K auf aktuellen GPUs ? Will haben! :-P
IMHO sollten Codecs open source sein. Das sind ja Standards.
1. In: 4K 12bit RAW 444 ACES 15-Fstops
2. Out: HD 8bit H264 420 rec.709 8-9 Fstops
3. Shit!
Einfache Möglichkeit, die bisher fehlt: auf Quicktime-Codecs verzichten.
Was ist daran einfach? Die Kamera auf der Arbeit nimmt .mov auf und unsere gesamte Firma ist auf Windows Basis. Soll ich jetzt zum Chef gehen und sagen: "hey, ich kann meine Arbeit nicht mehr machen."?
Hoffentlich führt diese Situation dazu, dass alle Hersteller von Windows-Videobearbeitungssoftware (incl. Adobe, Sony, Grass Valley, Blackmagic) ihre Programme Quicktime-kompatibel machen, ohne auf Apples Quicktime zurückzugreifen. Damit wäre auch das heutige Ärgernis der miesen Quicktime-Performance und -Kompatibilität unter Windows behoben. Ggfs. kann man dafür ja auf Open Source-Bibliotheken wie libavcodec zugreifen. (Deren LPGL-Lizenz erlaubt den Einbau in nichtfreie Software.) Mit dem in der libavcodec reverse-engineertem ProRes hatte ich noch nie irgendwelche Probleme.
enilnacs hat geschrieben:
Apropos Daniel.. warum nicht ? Cinegy sollte das Ding open source machen dann haben Alle was davon. Oder zumindest license-based wie MPEG. Anstatt irgendwo zu verrotten. 4300(!!!) fps bei 4K und 1100fps(!)bei 8K auf aktuellen GPUs ? Will haben! :-P
Es geht doch nicht um wollen. Ich will auch das fliegende Superauto und einen Haustieraffen, aber ich glaube eben nicht dass wir das irgendwann bekommen.
Was die Leistungsangaben angeht - das sollte man vielleicht erstmal abwarten, da dreht uns doch eh die Lesegeschwindigkeit den Hals um ;)
Ich sehe das Ende von QT auf Windows eigentlich sehr positiv. Es ist nun "offiziell" EOL (war aber seit Jahren ein offenes Geheimnis), und es liegt jetzt an den NLE Herstellern, unter Windows hoffentlich eigene und neue Ersatzschnittstellen an die Stellen der alten QT API zu setzen. Premiere läuft ja seit einigen Jahren 1A ohne QT, es fehlt dann halt der ProRes Decoder, was natürlich bei non ProRes / Imagesequenzen relativ Wurst ist. Was Avid angeht, nunja, bei denen freut es mich noch am meisten, weil da QT7 immer noch viel zu viel vom NLE ausmacht, wenn ich da alleine an die schaurigen Exportfunktionen denke.... Resolve bin ich gespannt drauf, Edius scheint ja auch eher QT dependent zu sein... es bleibt also spannend 2016/17 ;)
Unabhängig von der Panikmache... Adobe braucht für Prores wirklich noch das komplette QT? Angeblich kommt auch Lightroom nicht ohne QT zurecht was ein bisschen befremdlich wirkt... Die aktuelle Magix ProX kann Prores nun auch ohne QT verarbeiten.. Bei uns kommt es nicht herunter warum auch...
merlinmage hat geschrieben:Premiere läuft ja seit einigen Jahren 1A ohne QT, es fehlt dann halt der ProRes Decoder, was natürlich bei non ProRes / Imagesequenzen relativ Wurst ist.
Auch bei einer CC2015 Installation mahnt Premiere das Fehlen von Quicktime beim Öffnen an. Als Grund werden nicht fehlende Decodern, sondern nicht funktionierende Effekte genannt.
merlinmage hat geschrieben:Premiere läuft ja seit einigen Jahren 1A ohne QT, es fehlt dann halt der ProRes Decoder, was natürlich bei non ProRes / Imagesequenzen relativ Wurst ist.
Auch bei einer CC2015 Installation mahnt Premiere das Fehlen von Quicktime beim Öffnen an. Als Grund werden nicht fehlende Decodern, sondern nicht funktionierende Effekte genannt.
Sollte man vielleicht bedenken ;)
Bei mir kommt seit der CC13 oder 14 nichts mehr beim Start ;)
Mir ist es erst aufgefallen, dass ich kein QT installiert habe, als ich ein ProRes File importieren wollte.
Edit: Verwechselst du das wieder was mit deinem heißgeliebten Avid? ;) Da wird unter Windows ja noch alles von QT7 genutzt was gerade geht, gerade auch die extrem schnellen Output Optionen ;) Bin mal echt gespannt, wie fix Avid ihr Input/Output Gestell ohne QT7 erneuern kann ;)
OS? Auf 8.1 Pro hatte ich es tatsächlich nicht. Ändert aber auch nichts daran, dass Premiere mit dem Wegfallen von QT7 mit Abstand am wenigsten Probleme hat.
Professionell wäre es von Apple gewesen, wenn sie:
1.) das End of Life (EOL) angekündigt hätten, damit Softwarehersteller darauf angemessen reagieren können,
2.) bis zum EOL alle bekannten Sicherheitslücken gepatcht hätten.
camworks hat geschrieben:und: ich wünschte, Die Edius HQ/HQX-Codecs wären offen und jedermann könnte sie implementieren.
Das sind sie doch schon und seit seit gut einem halben Jahr.
Zwischen "offen und jedermann könnte sie implementieren" und dem kostenlosen Download eines nicht-offengelegten Codecs liegt allerdings noch ein gewaltiger Unterschied... Man könnte schnell vom Regen in der Traufe landen, falls sich in ein paar Jahren das Spiel, das Apple mit Quicktime/ProRes spielt, bei HQX (oder anderen Intermediate-Codecs wie Cineform) wiederholen sollte.
DV_Chris hat geschrieben:Hier die Stellungnahme von Adobe zum Thema:
Wow, hier kommt 'raus, dass die Warnung mittlerweile offiziell von CERT (dem amerikanischen Äquivalent des deutschen BSI) verbreitet wird: https://www.us-cert.gov/ncas/alerts/TA16-105A
- Immerhin gut, dass Adobe an der Sache arbeitet und der Quicktime-Schrottcode endlich (!) entsorgt wird, so wie der Flash-Schrottcode bei den Browsern.
cantsin hat geschrieben:... Immerhin gut, dass Adobe an der Sache arbeitet und der Quicktime-Schrottcode endlich (!) entsorgt wird, so wie der Flash-Schrottcode bei den Browsern.
Ich wüsste nicht, dass Adobe an der Entsorgung ihres eigenen Flashcodes aktiv mithilft - im Gegenteil, sie tun seit langem so, als ob ihre Dauer-Sicherheitsupdates eine Dauer-Verbesserung bringen würden.
Sicherheitsprobleme der schrumpfenden Flashgemeinde scheinen A. dabei am A. vorbeizugehen - sonst hätten sie den Schrottcode längst neuprogrammiert oder endlich gelöscht.
cantsin hat geschrieben:Immerhin gut, dass Adobe an der Sache arbeitet und der Quicktime-Schrottcode endlich (!) entsorgt wird, so wie der Flash-Schrottcode bei den Browsern.
Die Ursprünge von QuickTime sind zwar alt, aber das macht es nicht einfach pauschal zu Schrott. Wer sagt Dir denn, das möglicher Ersatz keine unentdeckten Probleme mitbringt? Ist die installierte Basis erst mal groß genug, dann weckt sie automatisch ein Interesse, nach Fehlern zu suchen. Und fehlerfreie Software düfte es praktisch gesehen nicht geben...
TheBubble hat geschrieben:
Die Ursprünge von QuickTime sind zwar alt, aber das macht es nicht einfach pauschal zu Schrott.
Quicktime unter Windows ist alter, unterirdisch performender 32bit-Schrott, der in Programmen wie Premiere und Resolve durch spezielle Kompatiblitäts-Server am Leben bzw. Laufen gehalten werden muss.
cantsin hat geschrieben:... Immerhin gut, dass Adobe an der Sache arbeitet und der Quicktime-Schrottcode endlich (!) entsorgt wird, so wie der Flash-Schrottcode bei den Browsern.
Ich wüsste nicht, dass Adobe an der Entsorgung ihres eigenen Flashcodes aktiv mithilft - im Gegenteil
Sorry, hier hatte ich mich grammatikalisch falsch bzw. missverständlich ausgedrückt. Ich meinte nicht, dass Adobe an der Entsorgung von Flash mitarbeitet, sondern dass Quicktime in Windows-NLEs der gleiche Albtraum ist wie Flash in Browsern.
cantsin hat geschrieben:sondern dass Quicktime in Windows-NLEs der gleiche Albtraum ist wie Flash in Browsern
Avid basiert schon ewig auf Quicktime. Immerhin Marktführer bei den NLEs im professionellen Bereich. Oder einer der Marktführer ;)
Also ich kann nichts schlechtes sagen ;)
QuickTime ist doch seit 2007 mit dem 64 Bit Carbon API auch in den Macs auf dem Rückzug. Schließlich ist das ein relativ niedriges Niveau, Audio und Video in Systemen zu behandeln.
Da ist es doch mehr als konsequent, dass das Zeug in externen Systemen als erstes nicht mehr gepflegt wird.
Ist doch nur eine Frage der Zeit, bis alle Reste des Frameworks auch aus den Macs verdampft sind.
Und warum sollten Formen, wie ADOBE nicht den Quarz Composer unterstützen ?
Den direkten Zusammenhang dazu, dass auf PCs kein MPEG 2 mehr laufen sollte, sehe ich noch nicht.
Außerdem sind solche Tools wie QTKit, AV Foundation, Javascript und Quartz Composer doch völlig im Trend, können doch App Schreiber auch darauf zurückgreifen, die keine einzige Zeile Code schreiben können.
cantsin hat geschrieben:
Quicktime unter Windows ist alter, unterirdisch performender 32bit-Schrott, der in Programmen wie Premiere und Resolve durch spezielle Kompatiblitäts-Server am Leben bzw. Laufen gehalten werden muss.
Wo liegt die Schuld bei einer nur für 32-Bit-Programme verfügbaren Library, wenn 64-Bit-Prozesse sie über (unperformante) Zwischenschichten nutzen?
Also in der Praxis sehe ich da keine Probleme. ProRes zu Cineform transkodiert und die Sache funktioniert in vielen Schnittsystemen problemlos.
Ich sehe auch keinen Grund jetzt nicht mehr in ProRes 10bit 422 aufzuzeichnen, diese ganze Warnungsmeckerei empfinde ich als sinnlos. Darum braucht man auch nicht unmittelbar in der weiteren Verarbeitungsstufe 10bit 444 oder noch besser. Es werden jetzt nicht alle die Rekorder wegwerfen, oder auch nicht mehr intern in Prores aufzeichnen. Und nicht jedermann geht auf raw oder XAVC.
Ja dass XAVC als hochwertiger Akquisitionscodec in 10bit 422 eine sehr gute Alternative ist, das halte ich auch für unbestritten. Aber ist eigentlich jedem klar dass XAVC im Abspielverhalten noch immer schwieriger ist als etwa Cineform? Wers nicht glaubt kann es gerne selbst probieren.
Also wenn man nicht ProRes mit Cineform kominieren soll, dann hätte ich gerne konkrete Alternativen. Wohlgemerkt für bestehende Schnittsysteme.
Eine Alternativ die ich selbst anbieten kann wäre über den Catalyst Prepare (aber in der Apple Welt) zu XAVC zu transkodieren. Oder aber über TMPGenc 6 zu H.264 10bit 422 zu transkodieren. Aber zweiteres verstehen gerade älteren Schnittsysteme wie Vegas nicht, für Vegas sollte es wenn H.264 schon XAVC oder XAVC-L oder XAVC-S sein.
bei der ganzen debatte sollte man nicht übersehen, dass es dabei nicht um probleme mit dem quicktime-format bzw. container geht, sondern um die reale implementierung des entsprechenden frameworks als häufig genutzte windows multimedia-schnittstelle. auch sehr viele andere formate, die man auf den ersten blick gar nicht damit in verbindung bringt, sind auf dieser nur als third party "quicktime components" umgesetzt und stützen sich auf die selbe problematische basis. leider gibt es meiner einschätzung nach auch wenig bis gar keine greifbaren alternative, mit denen man diese schnittstelle kurzfristig und plattformübergreifend ersetzten könnte. das war ja ohnehin schon bisher immer ein großes problem, weil die windows quicktime implementierung qualitativ und performanceseitig tlw. grobe allseits bekannte mängel zeigt, deren folgen sich in praktisch allen kommerziellen anwendungen in ganz ähnlicher weise zeigen (bspw. off-by-one frame-versatz bei div. h.264 files).
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.
