Warum verbraucht reverse playback so viel Ressourcen?

[klusterdegenerierung]

Mal ne Frage an die Profis.
Warum tun sich NLEs so schwer mit dem Rückwerts abspielen?
Liegt es nur an bestimmten Codecs oder was gibt es da für Gründe?

Danke für Eure Erfahrungen! :-)

[Valentino]

Liegt in erster Linie an den Codecs mit GoP-Strucktur. Hierbei wird aus einem Key bzw. I-frame mehrere Einzelbilder errechnet. Dies kann aber immer nur in eine Richtung passieren, also nach Vorne und deswegen müssen erst alle Zwischenbilder errechnet werden und dieser dann in umgedrehter Reihenfolge wiedergeben werden.

Bei einem Codec bzw. Material das schon aus Einzelbildern besteht, existiert dieses Problem nicht, da die Bilder einfach in einer anderen Reihenfolge wiedergeben werden und eben keine Zwischenbilder mehr errechnet werden müssen.

[TheBubble]

Praktisch alle temporal komprimierenden Codecs, aber auch viele Container, sind dafür optimiert, nur in einer Richtung verarbeitet zu werden.

Die Daten, die jeweils verarbeitet werden müssen, beziehen sich oft auf vorangegangene Daten. Darum muss beim zeitlich umgedrehten Abspielen viel mehr Aufwand getrieben werden. Das fängt bei den Containern an (z.B. Transport streams) und geht über die GoP-Strukturen von temporal komprimierenden Codecs bis hin zur Entropiekodierung größerer Datenblöcke.

[dienstag_01]

Dies kann aber immer nur in eine Richtung passieren, also nach Vorne

Falsch.

[klusterdegenerierung]

Danke euch für die prompte und tolle Antwort!
Aber ändern kann man für den Schnitt daran nichts, oder?

Was wäre wenn ich ein komplettes Projekt in Reverse bearbeiten müßte, gibt es da einen sinnvollen Weg,
ausser erst all das Rohmaterial rückwerts raus zu rendern?
Danke :-)

[TheBubble]

Aber ändern kann man für den Schnitt daran nichts, oder?

Ein paar Dinge kann man schon machen:

1. Einen Frame-basiert arbeitenden Codec für Video und Audio verwenden ("I-frame only") und
2. einen Container, der ein möglichst direktes Auffinden von Frames erlaubt und
3. ein Schnittprogramm, das all dies unterstützt.

Letztlich ist es die Kombination, die man braucht. Probiere es mit einen I-frame only Intermediate-Codec und unkomprimierten Audio-Daten in einem einfachen Container.

[pixler]

@dienstag 01

Und die Begründung zu "Falsch" lautet ?

Ich habe schon viele Beschreibungen zur GoP Struktur gelesen und alle sagen das gleiche...ausgehend vom I-Frame können die Folgebilder nur in eine Richtung errechnet werden. Wenn Du das anders siehts würde mich eine Erklärung sehr interessieren.

[dienstag_01]

@dienstag 01

Und die Begründung zu "Falsch" lautet ?

Ich habe schon viele Beschreibungen zur GoP Struktur gelesen und alle sagen das gleiche...ausgehend vom I-Frame können die Folgebilder nur in eine Richtung errechnet werden. Wenn Du das anders siehts würde mich eine Erklärung sehr interessieren.

Echt? Zeig mal.

[pixler]

z.B.

https://de.wikipedia.org/wiki/Bildergruppe

https://www.radonmaster.de/robernd/tMPEG.html


Es wäre nett Du würdest mich erhellen würdest weshalb dem nicht so ist. anstelle einfach lakonische Bemerkungen zu machen wie "Falsch" oder "zeig mal". Thanks

[dienstag_01]

FALSCH ist es deshalb, weil es sowieso einen Unterschied in der Reihenfolge der angezeigten zu der der kodierten Bilder gibt. Heisst, dass z.B. das Bild 246 im Stream bei der Ausgabe der das Bild 244 sein kann/ist.
Vielleicht hätte ich besser irrelevant schreiben sollen ;)

https://en.wikipedia.org/wiki/Inter_frame
siehe Bild GOP

[freezer]

@dienstag 01

Und die Begründung zu "Falsch" lautet ?

Ich habe schon viele Beschreibungen zur GoP Struktur gelesen und alle sagen das gleiche...ausgehend vom I-Frame können die Folgebilder nur in eine Richtung errechnet werden. Wenn Du das anders siehts würde mich eine Erklärung sehr interessieren.

Das Stichwort lautet B-Frames (bidirectionally predicted pictures).

[pixler]

Ok, Danke.

Was ist denn Eure Erklärung weshalb Filme mit GOP Struktur beim Rückwärtsspielen (Editor oder Player) immer wie die Sau Ruckeln ?

[dienstag_01]

Naja, *ruckeln* ist ja nun wieder was ganz anderes, als *sich schwer tun*.
Ruckeln kann es ja schon deshalb, weil Unschärfe *entgegengesetzt* der (Rückwärts-) Bewegung läuft.
(Ein Auto fährt sozusagen in die Unschärfe, normal wäre die hinter ihm)

[pixler]

Wenn ich das gleiche Material in einen All-I Codec umrechne und es Rückwärts laufen lasse, läuft aber alles flüssig. Das ein fahrendes Auto die Unschärfe nach sich zieht wäre mir noch nie aufgefallen und wenn dem so wäre, würde dies mit einem All-I Codec ja auch nicht gehen.

[klusterdegenerierung]

Schon klar, aber das ist ja kein ruckeln im klassischen Sinne!
Wenn ich in Premiere etws rückwärts auf der Timeline habe, dann läuft das echt übel, wenn man es dann noch time remappen muß,
dann gehts quasi garnicht mehr.

Das sieht dann ungefähr so aus wie Vorwärts in Resolve vor 2 Jahren! ;-))

[pixler]

Eben - weshalb läuft dann ein GOP Movie rückwärts so schlecht wenn es denn nach "Dienstag_01" nicht an der GOP Struktur liegt?

[TomStg]

Auf meiner PP 2017.2 Timeline laufen FHD-Clips aus der PXW-X70 in XAVC Long GOP 4:2:2 10 Bit mit Lumetri-Effekt rückwärts genauso glatt wie vorwärts. Das Ganze mit Win 10 und einer GTX 1080.
Daraus schließe ich, dass heftiges Hakeln (nicht Ruckeln) beim Rückwärtsabspielen nicht nur vom Codec abhängt, sondern mindestens genauso stark auch von der verwendeten Grafikkarte. Oder anders ausgedrückt: In PP 2017.2 spielt der Codec keine Rolle, sobald ausreichend Grafik-Power im Spiel ist.

[klusterdegenerierung]

Wie stehe ich dann bei PP 2017 mit einer GTX970 da?
Muß ich dazu noch extra etwas einstellen oder irgendeinen Cuda Voodoo machen? ;-)

[DenK]

Bei mir läuft Sony XAVC-I, 4K mit Lumetri Lut + Scharfzeichner + Stabilisierung drauf mit einer GTX970 rückwärts auch genauso wie vorwärts.

[TomStg]

Muß ich dazu noch extra etwas einstellen oder irgendeinen Cuda Voodoo machen? ;-)

Habe mal den Apple-Jüngern bei ihrem Morgengebet Richtung Cupertino zugesehen. San José für Adobe liegt ja gleich nebenan. Also machte ich mit. Siehe da, es funktioniert...

Im Ernst: Da auch eine GTX 970 offenbar keine Probleme beim Rückwärtsspielen hat, könnte evtl. die Anbindung der Karte an das System Einfluss haben. Das müssten aber andere beurteilen. Die Infos von studio1production hast Du alle gelesen?

[Axel]

Wie stehe ich dann bei PP 2017 mit einer GTX970 da?
Muß ich dazu noch extra etwas einstellen oder irgendeinen Cuda Voodoo machen? ;-)

In einem anderen Thread war kürzlich ein Artikel verlinkt, in dem dargelegt wurde, was Premiere mit der GPU macht und was mit der CPU. Und warum Benchmark-Tests häufig so realitätsfern sind. Wenn es um reines Playback von H.264 geht, da ist das Stichwort Dekodierung (CPU). In einer "normalen" Timeline, die lang und komplex ist und noch gar keine Effekte enthält, wird die Grafikkarte kaum beansprucht. Und reverse playback fällt unter Playback. Nun kann man sich angucken, wie die Hardwareauslastung von Rückwärts im Vergleich zu Vorwärts ist, sich am Kopf kratzen und gegebenenfalls sein System aufrüsten - oder schlicht rendern. Die Beobachtung, dass mit einem Intraframe-Codec das Playback dramatisch verbessert wird, von Renderzeiten zu schweigen, deutet ebenfalls eine Alternative an. Die Frage könnte auch lauten, warum verbraucht Premiere so viel Ressourcen? Nicht optimierte Konfiguration? Gewiss, aber das ist halt nur einer von mindestens drei Faktoren. Der zweite wäre eine falsche Erwartungshaltung des Benutzers. Der dritte die Tatsache, dass die hochkomprimierten Consumercodecs relativ schnitt-unfreundlich sind und ungeachtet der nominellen Hardwareleistung Ressourcen verschwenden.

[TomStg]

Muss ergänzen:
Da Decoding und Encoding bei Premiere zunächst allein von der CPU gemacht werden, hat diese natürlich auch noch Einfluss. Erst mit den verschiedenen Effekten wird die GPU wirksam - vorausgesetzt der jeweilige Effekt wird von der GPU unterstützt. Dies trifft bei Premiere aber inzwischen für die wichtigsten Effekte zu.
In meinem Desktop sitzt noch ein relativ betagter i7-3930K 3,20GHz. Aber das scheint zusammen mit der GTX1080 auszureichen.

Dass Long Gop das System mehr beansprucht als I-Frame hat natürlich nichts mit Premiere zu tun, sondern ist grundsätzlich der unterschiedlichen Arbeitsweise der Codecs geschuldet. Die Frage könnte also auch lauten: Warum verplempern Nutzer nicht-performanter Systeme Zeit und Geld, um ihr Material in "schnittfreundliche" Codecs mit diversen Qualitätseinbußen zu wandeln, wenn es auch ohne dem geht?

[Axel]

Die Frage könnte also auch lauten: Warum verplempern Nutzer nicht-performanter Systeme Zeit und Geld, um ihr Material in "schnittfreundliche" Codecs mit diversen Qualitätseinbußen zu wandeln, wenn es auch ohne dem geht?

Weder Zeit noch Geld noch Qualitätseinbußen, wenn man es richtig macht. Aber jedem Tierchen sein Pläsierchen, und viele, viele Threads auch in der Zukunft über Echtzeitgrenzen und hakelnde Performance.

[blickfeld]

Warum verplempern Nutzer nicht-performanter Systeme Zeit und Geld, um ihr Material in "schnittfreundliche" Codecs mit diversen Qualitätseinbußen zu wandeln, wenn es auch ohne dem geht?

weil mit proxies zu arbeiten industriestandart ist. simple as this. proxies machen einfach viel sinn. in der finalen ausspielung, kann man dann immer noch auf die orginaldateien zurückgreifen.

[Jörg]

axel schreibt

Und reverse playback fällt unter Playback.

möchte das ergänzen:
Solche Geschwindigkeitseffekte sind GPU unterstützte Effekte, kann man gerne prüfen, wenn man MercuryEngine abschaltet.

[Axel]

weil mit proxies zu arbeiten industriestandart ist. simple as this. proxies machen einfach viel sinn. in der finalen ausspielung, kann man dann immer noch auf die orginaldateien zurückgreifen.

Auch ohne sich sklavisch danach zu orientieren, was irgendein Profi-/Industrie- Standard ist, bin ich dafür, immer das zu nutzen, was am besten funktioniert. Wenn ich Clips nativ schneiden kann, in nur geringem Maße Postpro betreibe und das alles fluppt, warum sollte ich da aufrüsten oder die Clips umcodieren? Mache ich überwiegend auch nicht. Ein 8-Minuten Hochzeitsvideo, ziemlich geradlinig geschnitten und mit ein wenig CC-Polishing, da bremst nichts. Aber was Längeres oder Komplexeres? Ein knapp drei Minuten langes Musikvideo mit Multicam, viel Retiming, Effekten und Look-Gedöns kann bereits eine Herausforderung der ernsteren Art sein. Ist es dann klug zu sagen, okay, ich mache meinen Rechner zum fiesesten Terminator unter der Sonne, und der Spacko-Codec, den der nicht unter jeder Bedingung in Echtzeit zur Sau macht, muss erst noch geschrieben werden?

Denn die Consumer-Codecs, auch das zu Recht gelobte XAVC, sind in mehr als einer Hinsicht spackig. Man braucht kein Pixelpeeper zu sein, um zu erkennen, dass etwa komprimiertes Rauschen in Slog die Hölle ist (Blockartefakte jenseits der Auflösungsgrenzen, siehe Yedlin-Videos). Man hat die Qualitätseinbußen schon auf der Akquisitionsseite, sie entstehen nicht beim Dekomprimieren in einen Intermediate (wie TomStg andeutet) und bei Proxy (wie blickfeld anmerkt) ja sowieso nicht. Wie gesagt, nichts grundsätzlich gegen nativen Schnitt, aber das Verhältnis von lächerlich verkapseltem und schnittunfreundlichem Original und den nötigen Pferdestärken, um dieses Manko zu kompensieren, kann irrational und mit Grund als Ressourcenverschwendung betrachtet werden. Und tatsächlich gar keinen Unterschied in puncto Qualität machen (bzw., wenn ich mit ProRes/Raw-Rekorder aufnehme, diese nativen Consumer-Codec-Fehler von Anfang an vermeiden).

Eine weitere heute vergessene Technik ist das Vorschaurendern. Temporäre Dateien, die Echtzeit bringen, wo mein System an die Grenzen gelangt. Eine Zumutung? Warum? Ich fahre ja auch mit meinem Auto nicht überwiegend rückwärts, nur in Ausnahmefällen. Etwa beim Einparken. Ab wann installiere ich mir eine Rück-Kamera, um meinen Nacken zu schonen? Autovergleiche hinken immer. Aber warum nicht alle Tricks nutzen?

Und reverse playback fällt unter Playback.

möchte das ergänzen:
Solche Geschwindigkeitseffekte sind GPU unterstützte Effekte, kann man gerne prüfen, wenn man MercuryEngine abschaltet.

Ach so. Okay, wusste ich nicht.

[TomStg]

Und tatsächlich gar keinen Unterschied in puncto Qualität machen (bzw., wenn ich mit ProRes/Raw-Rekorder aufnehme, diese nativen Consumer-Codec-Fehler von Anfang an vermeiden).

Und auch nur in diesem Fall macht es Sinn, direkt mit ProRes/DNxHD aufzunehmen. Aber eine nachträgliche Wandlung in verlustbehaftete Codecs macht jedes Originalmaterial schlechter als es vorher war und kostet nur Zeit.

Die Bemerkung "ist Industrie-/Profi-Standard" halte ich zu diesem Thema für Gerede nach dem Motto "Ham wah schon imma so gemacht!" ProRes wurde von Apple 2007 entwickelt, damit deren Hard- und Software mit dem damals neuen AVCHD umgehen konnte. Dass aus ProRes ein "Industrie-/Profi-Standard" wurde, hat nichts mit Qualitätsmerkmalen dieses Codecs zu tun, sondern mit der weiten Verbreitung von Apple-Hard- und -Software im Medienbereich. Das gilt auch für DNxHD, weil der Avid - mangels Alternativen - ein sehr häufig verwendetes Schnittprogramm war. Da inzwischen aber PC-Hard- und Software deutlich leistungsfähiger zum halben Apple-Preis geworden ist, braucht es diesen sog. "Industrie-/Profi-Standard" grundsätzlich nicht mehr. Denn weder Proxies noch Wandlungen von Originalmaterial sind hilfreich, wenn es schnell gehen muss - und schon gar nicht bei komplexen Schnittprojekten, wo es Einbindungen von Motion Graphics, umfangreichen Fotomaterial, aufwendigem Vfx und komplexen Audio gibt.

Natürlich reden wir hier nicht von GoPro- oder AVCHD-Material - wobei letzteres in diversen Vergleichstest unter bestimmten Umständen bei gleicher Datenrate sogar Vorteile gegenüber ProRes zeigt. Aber zB ein XAVC-I oder XAVC-L mit 100, 200 oder 500 Mbps ist ganz sicher kein dubbeliger Codec, den nur unbedarfte Amateure benutzen, weil sie zu blöd sind, die ach so tollen Intermediate-Codecs einzusetzen.

Es mag schwerfallen, die deutlich veränderte Situation auf dem Hard- und Softwaremarkt zur Kenntnis zu nehmen. Noch schwerer mag es sein, einstmals bewährte und liebgewonnene Workflows nicht nur in Frage zu stellen, sondern diese auch zu ändern. Aber wir kennen alle die Konsequenzen: Stillstand ist Rückschritt - sogar bei diesem Thema.

[Jott]

Wenn es aber mit im Hintergrund generiertem - also ohne Zeitverlust - ProRes oder ähnlichem trotzdem noch schneller fluppt, wäre deine Haltung Sturheit. Und es fluppt eigentlich immer schneller, naturbedingt. Bei Interframe gegen Intraframe gewinnt letzteres immer, egal auf welcher Hardware. Auf Original zurückschalten vor der Ausgabe geht ja auch immer, sollte man einen Unterschied sehen und ihn nicht nur unterstellen. Heißt: ohne jeden Zeitverlust schneller arbeiten, also Zeitgewinn. In dafür optimierten NLEs jedenfalls. Sich religiös gegen zeitoptimierte Workflows zu sperren (du hast doch was gegen religiöse Ansichten in Sachen Software?), wäre schon seltsam. Aber das soll gerne jeder machen, wie er's für richtig hält.

Der Fragesteller dieses Threads mit dem Rückwärtsspielproblem hat jedenfalls zwei Antworten zum Aussuchen bekommen: Rechner aufrüsten oder Workflow optimieren.

[blickfeld]

Und tatsächlich gar keinen Unterschied in puncto Qualität machen (bzw., wenn ich mit ProRes/Raw-Rekorder aufnehme, diese nativen Consumer-Codec-Fehler von Anfang an vermeiden).

Denn weder Proxies noch Wandlungen von Originalmaterial sind hilfreich, wenn es schnell gehen muss - und schon gar nicht bei komplexen Schnittprojekten, wo es Einbindungen von Motion Graphics, umfangreichen Fotomaterial, aufwendigem Vfx und komplexen Audio gibt.

Sorry, dass ist einfach falsch. Zum einen sollten/können die Proxies während der Datensicherung vor Ort generiert werden. Wenn nen DIT dabei ist, kann auch schon eine vorläufige CC auf die Proxies gelegt werden, Audio mit angelegt werden und die notwendigen Burnins vorgenommen werden.
Wenn man solo unterwegs ist und vor Ort nicht machen kann, kann Premiere wunderbar im Hintergrund die Proxies generieren. Proxies verschnellern einfach den Workflow, wenn man sie einzusetzen weiß. Die Proxies später in DaVinci oder dem Finishing Tool deiner Wahl zu ersetzen, ist nahezu automatisch getan. Wenn Du vor Ort die Proxies generiert hast, freuen sich auch sämtliche PostPro Departments jenseits des Schnitts. Z.B. die Effekt-Leute. Die brauchen dann selbst keine mehr Rechnen, wenn Sie welche benötigen.
Vielleicht sieht Dein Workflow keine Proxies vor, jedoch sind sie aus betriebswirtschaflicher Sicht eigentlich ein Nobrainer.
My 2 Cents

[zlois]

Um auf die ursprüngliche Frage zurückzukommen:
Es ist tatsächlich so, dass ein Long-GOP Videostream nur für die Wiedergabe in einer Richtung ausgelegt ist, nämlich vorwärts.

Eine GOP (Group of pictures) besteht aus drei verschiedenen Arten von Frames:
I-Frames: Enthalten ein vollständiges Bild
P-Frames: Enthalten ein Differenzbild, das sich auf das letzte I- oder P-Frame bezieht
B-Frames: Enthalten Differenz- und Bewegungsinformationen aus vorherigen und nachfolgenden Frames
Nehmen wir einmal eine typische GOP mit einer GOP-Size von 12 Frames an: IBBPBBPBBPBB
Jedes der drei P-Frames bezieht sich auf das vorhergehende P- oder I-Frame. Eine Dekodierung ist somit nur von links nach rechts möglich. Ist das vorhergehende I- oder P-Frame nicht bekannt, kann keine sinnvolle Dekodierung erfolgen. B-Frames sind nochmals aufwändiger, diese beziehen sich nämlich sowohl auf vorhergehende als auch auf nachfolgende Frames, was den Rechenaufwand entsprechend erhöht.

Tatsache ist:
Wird ein Long-GOP Videostream vorwärts abgespielt, kommen also die Frames in der richtigen Reihenfolge, kann jedes Frame einzeln dekodiert und dargestellt werden (wie gesagt mit Ausnahme von B-Frames, für die der nächste I- oder P-Frame zuvor dekodiert werden muss). Spielt man das Video nun rückwärts ab, bezieht sich jedes Frame, das an den Dekoder gelangt, auf ein zukünftiges, das noch nicht bekannt ist. Es muss also die gesamte GOP (die bei modernen Codecs noch um ein Vielfaches länger sein kann, als im obigen Beispiel angegeben, und u.U. mehrere Sekunden Videomaterial enthalten kann) eingelesen, dekodiert, zwischengespeichert und dann in umgekehrter Reihenfolge abgespielt werden. Und während die zwischengespeicherten Bilder abgespielt werden, muss schon wieder die nächste komplette GOP eingelesen, dekodiert und zwischengespeichert werden...
Ein Rechner, der in der Lage ist, das Video vorwärts problemlos abzuspielen, kann dementsprechend durchaus massive Schwierigkeiten haben, dies in umgekehrter Reihenfolge zu machen.

Um meine Behauptungen auch durch eine wissenschaftliche Quelle, die mir vorliegt, zu belegen:
Chang-Hong Fu, Yui-Lam Chan, & Wan-Chi Siu. (2006). Efficient reverse-play algorithms for MPEG video with VCR support. IEEE Transactions on Circuits and Systems for Video Technology, 16(1), 19–30. https://doi.org/10.1109/TCSVT.2005.856901

[Axel]

Tatsache ist:
Wird ein Long-GOP Videostream vorwärts abgespielt, kommen also die Frames in der richtigen Reihenfolge, kann jedes Frame einzeln dekodiert und dargestellt werden (wie gesagt mit Ausnahme von B-Frames, für die der nächste I- oder P-Frame zuvor dekodiert werden muss).

Die Konsequenz ist für *Playback*, dass in einer Timeline, die ständig länger und komplexer wird, immer mehr I-,B- und P-Frames außerhalb der Clipauswahlen existieren, denn wir schneiden ja kurze Subclips. Es ist also kein gleichbleibend hoher Rechenaufwand, Long-GOP-Footage nur abzuspielen, sondern ein stetig wachsender. Jeder hat wohl mal die Erfahrung gemacht, dass das Playback beim zweiten Durchgang sauberer läuft. Was geschieht da? Werden die benötigten Bild- und Bewegungsinformationen (verbundenes Audio muss freilich auch dazu gerechnet werden) zusammengefasst, quasi neu gemappt und gehen in einen permanenten Cache, der bei Programmstart in den Arbeitsspeicher geladen wird? Anders kann ich es mir nicht vorstellen.

Das Beharren darauf, immer nur das Original zu bearbeiten, kann man als Purismus (mit dem immer wiederkehrenden Argument der Qualitätserhaltung) sehen, aber erstens muss man zugeben, dass es ein Handicap ist. Zweitens greift das Qualitätsargument bei Proxy überhaupt nicht und bei einem guten Intermediate ebenso wenig. Dieselben Nativ-Fundis, die immer nur Long-GOPs subclippen, exportieren sehr häufig keine unkomprimierten Master, sondern irgendein Mpeg4-File in etwas höherer Datenrate. Damit widersprechen sie der Logik des (Adobe-) Gurus Stu Maschwitz, der in seinem alten "DV Rebel" gebietet NO RECOMPRESSION! - und DV war sogar intraframe-kodiert.

So lange ich UHD XAVC direkt bearbeiten kann, ohne dass der Schnitt hakelig oder zäh wird, stellt sich die Frage nicht. Ich sehe allerdings öfter, dass Leute Zeit und Geld für System-Upgrades und tüftelige Neukonfiguration aufwenden, weil ihre Erwartungshaltung die ist, dass nativ günstiger und zeitsparender ist. Das verstehe ich nicht, aber muss ich ja auch nicht.

Da der TO klusterdegenerierung auch Resolve nutzt, hat er eine Möglichkeit, den m.E. besten, weil einfachsten aller Proxy-Workflows mal auszuprobieren. Rückwärts hakelt? Rechtsklick auf den fraglichen Footage-Clip (im "EDIT"-Room) >Generate Optimized Media. Dann unter der Topmenu-Zeile Playback checken, ob Use Optimized Media If Available angehakt ist (ist sowieso der Default, kann man sich also i.d.R. schenken, mit "use" ist ausdrücklich nur Playback gemeint). Kein Umschalten nötig. Nur ausgewählte Problemstellen brauchen Proxies. Schnelles Encoding (abhängig vom ausgewählten Codec, ein Intraframe-Codec mit für UHD halber Auflösung bietet sich an). Kein Versehentliches Exportieren von Proxy (wie es etwa mit FCP passieren kann, wenn man vergisst, vorher auf Original zurückzuschalten). Von dieser Eleganz ist Premiere meilenweit entfernt.

Anhand von Resolves Philosophie kann man auch das Qualitäts-Argument entkräften. Farbkorrektur mit Masken? Entrauschen? Das macht man natürlich nicht mit Proxies. Aber der Schnitt ist dann schon abgeschlossen. Es ist relativ egal, ob die Vorschau mit zig Nodes hakelt oder für Echtzeit gerendert werden müsste.

[blickfeld]

. Kein Umschalten nötig. Nur ausgewählte Problemstellen brauchen Proxies. Schnelles Encoding (abhängig vom ausgewählten Codec, ein Intraframe-Codec mit für UHD halber Auflösung bietet sich an). Kein Versehentliches Exportieren von Proxy (wie es etwa mit FCP passieren kann, wenn man vergisst, vorher auf Original zurückzuschalten). Von dieser Eleganz ist Premiere meilenweit entfernt.

axel, erklär mir doch mal, wo das problem mit premiere und proxies ist? ich glaube einfach, deine kenntnisse sind wie bei den playback und das das playback cpu gesteuert ist. falsches wissen. bei premiere stellst du am anfang des projektes z.b. ein, dass du importierte medien als proxies haben willst. mehr machst du nicht. du kannst mit dem ame auch einfach eingeben, dass sobald dateien in einem bestimmten verzeichniss abgelegt werden, dass diese automatisch umgerechnet werden, ohne einen mausklick. alles im hintergrund. eleganter geht kaum. du stellst mit einem knopfdruck alle proxies ein und aus. einfach mal mit dem programm beschäftigen, anstatt behauptungen rauszuhauen.
aber kläre mich auf. ich mag davinci und die proxy funktion, wo ist diese mächtiger als die proxyfunktion von premiere?
würde mich nur interessieren, da davinci bei weiter mehr nutze als premiere. davinci hat einige vorteile gegenüber premiere, jedoch die proxiefunktion zu nennen halte ich für fragwürdig...
oder es direkter zu sagen, es nervt, wenn ohne das wissen behauptungen rausgehauen werden. jedenfalls mich.

[Jörg]

noch ne Ergänzung ;-))

bei dem von blickfeld beschriebenen Proxyablauf ist noch nicht mal die Gefahr gegeben, die Proxyversion rauszurendern. Premiere schaltet automatisch auf die Originale.
Wenn ich 4/x K files schneide, wird APP und MediaEncoder gleichzeitig über ein script gestartet, mein Standardprojekt wird geöffnet.
Es folgt der Import der files vom Speichermedium via Medibrowser, in den Voreinstellungen ist die Proxyerstellung in ein zuvor gewähltes Format gewählt.
Hätte ich nen Hund, würde ich mit dem für ein paar Minuten rausgehen, so lese ich im Forum, oder leere die Krebsreusen...
Das wars schon, alles andere läuft so einfach, flüssig, wie 2010 mit 720p 50, vorwärts, rückwärts, diagonal...
Darf also auch auf betagteren Rechnern ganz komfortabel laufen.

[blickfeld]

noch ne Ergänzung ;-))

bei dem von blickfeld beschriebenen Proxyablauf ist noch nicht mal die Gefahr gegeben, die Proxyversion rauszurendern. Premiere schaltet automatisch auf die Originale.
Wenn ich 4/x K files schneide, wird APP und MediaEncoder gleichzeitig über ein script gestartet, mein Standardprojekt wird geöffnet.
Es folgt der Import der files vom Speichermedium via Medibrowser, in den Voreinstellungen ist die Proxyerstellung in ein zuvor gewähltes Format gewählt.
Hätte ich nen Hund, würde ich mit dem für ein paar Minuten rausgehen, so lese ich im Forum, oder leere die Krebsreusen...
Das wars schon, alles andere läuft so einfach, flüssig, wie 2010 mit 720p 50, vorwärts, rückwärts, diagonal...
Darf also auch auf betagteren Rechnern ganz komfortabel laufen.

ich dachte, dass wäre klar, das premiere die orginaldateien für das rendern benutzt. daher verstehe ich alexs einwände auch nicht.

[Jörg]

daher verstehe ich alexs einwände auch nicht.

solche Einwände sind doch ganz normal, wenn man nicht permanent auf diesem NLE werkelt.

Und selbst wenn man das tut...ab und an lernt man etwas dazu.
Ich habe gerade zu diesem Problem einen Versuch gemacht:
4 k file importiert, wie oben, der AME ertsellt ein proxy.
Originalfile auf die timeline, proxyschalter aktiviert, und die Geschwindigkeit umgestellt.
Jetzt der Lerneffekt:
der AME rechnet auch hier ein proxy des Reverseclips, und danach läuft das Teil auf nem 8jährigen i7 sowas von sanft rückwärts...

Und wenn man schon am Basteln ist...
Diese 4K 25 p Reversesequenz in eine FHD 50p Sequenz eingefügt, Optical float aktiviert, auf FHD skaliert, Ergebnis ist ein wunderbarer downconvert
von 4k auf fullhhd mit verdoppelung der framerate.Ganz ohne ruckeln.
Zur Beachtung, opticalflow wird erst nach timelinerendern sichtbar!