Edius X ab 4K kaum zu gebrauchen

Wie sich das Mavic-Videomaterial sich auf meinem Intel-PC verhält kann ich leider nicht testen weil
es mir an Videotestmaterial gebricht, Stelle doch mal bitte einen Download hier rein.

Hi,

für H.264 / H. 265 Material wäre ein aktuelle Intelprozessor (12. oder 13. Gen.) sicherlich die bessere Wahl gewesen, da Edius dort sehr stark auf QuickSync (Intel-Grafik) setzt. Aber grade mit den Materialien aus Drohnen und Smartphones hat Edius bei der Decodierung auch oft seine Probleme. Das liegt an deren ungünstigen Komprimierung. Die Berechnung dauert zu lange, sodass sich der Puffer nicht füllen kann. Da kommen einige andere NLEs, wie Resolve besser mit solchem Material klar.

Zudem musst Du bedenken, dass es sich um 5.1K-Material handelt. Zu UHD/4K, wird das erst auf der TL. Bedeutet, die Rechenleistung ist höher als bei "normalen" UHD-Material.

In Deinem Screenshot sieht soweit alles ok aus. Wobei ich dazu raten würde auf alle Fälle auf T-Sturen und möglichst auch auf VA-Spuren zu verzichten. Das hat aber nichts mit Deinem Problem zu tun, sondern ist eine generelle Empfehlung.

Interessant wäre aber noch ein Screenshot Deiner Projekteinstellungen und vielleicht auch den ein Ausdruck von MediaInfo des Quellmaterials. Noch besser wäre natürlich ein Test-Clip, wie Pee geschrieben hat.

Was Du als Lösung mal probieren könntest, die Qualität der Vorschau zu vermindern. Dazu rechts oben über den Recorder von Voll auf z.B. 1/2 zurückgehen.

Dabei wird nur die Anzeige vermindert, diese Einstellung hat also keinen Einfluss auf einen Export.

Allerdings wirkt das grade bei solchen Drohnen-Material meist nicht oder nur wenig, da das Problem eben im Decoder liegt, nicht in der Darstellung.

Eine weitere Maßnahme wäre der Modus > Proxy-Modus.

Dieser sollte auch in der Einstellung "Groß" (Systemeinstellungen > Anwendung > Proxy) eine flüssige Bearbeitung erlauben und ein kaum vermindertes Bild liefern.

Die dabei notwendige Erstellung der Proxys dauert etwas, liefert aber vernachlässigbar kleine Dateien. Allerdings musst Du vor einem Export den Proxy-Modus wieder ausschalten, da sonst des verminderte Material verwendet würde.

Günstig wäre natürlich die Umandlung des Materials in der Bin in GV HQX. Braucht aber halt sehr viel Speicherplatz.

Nur als schelle Hilfslösung für den unmittelbaren Schnitt eignet sich auch das Abspielen mit zuvor gefüllten Puffer. Dazu die Umschalttaste halten und Enter oder Leertaste drücken.

Die Wiedergabe starte dann erst, wenn der Puffer vollständig gefüllt ist. Das reicht - je nach Material - dann für einige Sekunden flüssiges Abspielen aus, bis halt der Puffer geleer ist.

Wie gesagt keine Dauerlösung, kann aber beim Schnitt helfen.

Gruß

Peter

Moin,

ich arbeite mit einem Schulfreund zusammen, der viel mit DJI-Drohnen fliegt. Unter anderem auch die verschiedene Mavic- Varianten.

Ja, in Edius ruckeln sie meist alle, da der Puffer schnell leer ist. Ausnahme: alte Inspire Aufnahmen.

Der Tipp von Gurlt (Auflösung herunter) funktioniert aber. Damit kann man die Clips flüssig abspielen und schneiden. Ohne Proxys oder Umwandlungen machen zu müssen.

Das Resolve damit besser klar kommt liegt wohl an der besseren Dekodierung der DJI kodierten mp4 (H464/465) Dateien. Das gleiche gilt aber auch für Canon RAW-Clips (egal ob 4K oder 8K).

Ein Grund liegt, für mich darin, dass Resolve die Ressourcen der GraKa mehr ausnützt. Soll ja (irgendwann) kommen. Der andere ist die Zusammenarbeit DJI+Canon mit den Edius- bzw. Blackmagic Entwicklern. Und natürlich kann ein BRaw-File und was damit ähnlich ist, am besten von einem BM-Programm bearbeitet werden.

Dafür gibt es in Resolve ab Werk keine vernünftige Unterstützung um Canon Logs zu verwenden. Erst mit händischen Anpassungen hab ich es dann hinbekommen in Resolve. Das geht bei Edius besser/einfacher.

mein Workflow ist so:

1. Dateien nach Reihenfolge ordnen - Helligkeit, Schärfe, Farben anpassen .

2. Auflösung runter 1/2 oder 1/4,

3. Schneiden, und evtl. Transitions, Titel, Effekte (grob) einfügen und im vollen Auflösungsmodus ansehen) Das schafft Edius weil aufwendige Effekte schon von guten GraKas unterstützt werden. Ton hinzufügen oder editieren.

4. Erst jetzt wieder im Vollen Anzeigemodus rendern. (je nach Länge Kaffee, Essen oder Ruhepause (Nacht).

5. Ergebnis kontrollieren, Änderungen vornehmen (meist Timing) und jeweils rendern sind meist nur ein paar Sekunden. Darauf kann ich warten.

6. Masterprojektdatei sichern.

Solange Edius die GraKa mehr oder weniger links liegen lässt (außer bei Effekten) wird sich daran wohl auch nicht ändern.

LG

Uwe

Zitat von yubi

Der Tipp von Gurlt (Auflösung herunter) funktioniert aber. Damit kann man die Clips flüssig abspielen und schneiden.

Danke, das ist interessant zu wissen.

Auf meinem System (ohne QuickSync) funktioniert das mit Material aus der DJI Osmo Pocket halt nicht so gut. Deshalb war ich mir da unsicher.

Zitat von yubi

Ein Grund liegt, für mich darin, dass Resolve die Ressourcen der GraKa mehr ausnützt.

Wobei - wie ja schon von mir geschrieben - Edius eben bei H.264/H.265 sehr stark auf die Intel-Grafik (QuickSynk) setzt.

Und grade die Intel CPUs der 12. und 13. Generation bieten da mit ihren überarbeiteten Grafiken auch ggü. guten Grafikkarten erhebliche Vorteile.

Das ist aber halt auf einem AMD-System nicht möglich.

Zitat von DeejayMD

Den Testclip...

Habe ich mir ebenfalls heruntergeladen und wie eigentlich nicht anders zu erwarten ruckelt es auch bei mir.

Der Puffer kann sich beim Abspielen nicht füllen. Ein zuvor gefüllter Puffer ist nach ca. 25 Sekunden leer gesaugt.

Ebenfalls erwartungsgemäß liegt die Auslastung der Nvidia bei mir bei unter 20%.

Die CPU (18 Kerne/36 Threads) ist ebenfalls insges. nur zu unter 20% belastet.

Dabei zeigt der Ressourcenmonitor ganz typisch für dieses Problem, dass nur einige wenige Threads (bei mir 6) höher ausgelaste sind, z.T. bis 100%. Die anderen dümpeln knapp über der 0-Line vor sich hin.

Dies liegt daran, dass die Decodierung von diesem speziellen Material offenbar nicht auf weitere Prozesse aufteilen kann, um die anderen Kerne/Threads nutzen zu können. Alles wird sozusagen nacheinander in nur wenigen Prozessen abgearbeitet.

Ob das jetzt direkt am verwendeten Decoder selbst, oder einer davor liegenden Programmroutine, die dann erst den Decoder anspricht, liegt, kann Dir nur GV beantworten.

Andere H.264-Dateien kann Edius jedenfalls mit einer gleichmäßigen Auslastung auf alle vorhandenen Kerne aufteilen, wodurch diese sich dann auch ruckelfrei abspielen lassen.

Zitat von DeejayMD

das Heruntersetzen der Vorschauqualität, selbst auf 1/16 bringt, außer Augenkrebs, absolut überhaupt nichts, was ich sehr merkwürdig finde.

Weil das Problem eben bei der Decodierung des Quellmaterials liegt.

Der Aufwand der Decodierung bleibt halt immer gleich. Denn reduziert wird ja nur die Vorschau des dann bereits decodierten Materials. Aus dem gleichen Grund bringt es bei diesem Problem normalerweise auch nichts die Auflösung der Projekteinstellung zu reduzieren. Das Quellmterial bleibt ja gleich.

Zitat von DeejayMD

auch UHD ruckelt bei mir, egal ob h.265 oder h.264

Aus welcher Quelle?

Es kommt halt nicht nur auf den Codec an, sondern auch wie das Material encodiert wurde.

Zitat von DeejayMD

habe alle T- und Audiospuren rausgeschmissen. Hat keinen Effekt

Kann es auch nicht. Denn wie schon oben geschrieben hat das nichts mit Deinem Problem zu tun.

Es ging nur darum, dass Du in Deinen Projekten generell keine T-Spuren verwenden solltest.

Diese sind nur ein Überbleibsel aus vergangenen Zeiten. Auch Titel gehören heute auf V-Spuren.

Die Audio (A-Spuren) solltest Du auch nicht löschen. Die sollten auch immer verwendet werden.

Nur würde ich halt auch dazu raten generell keine VA-Spuren (also Bild und Audio in einer Spur) zu nutzen, sondern immer getrennte V- und A-Spuren.

Bei Projekten mit vielen Audiospuren machen sich VA-Spuren einfach nicht so gut.

Und da das Testvideo keinen Tonanteil hat, sondern nur einen Bildanteil, macht es eigentlich gar keinen Sinn das auf eine VA-Spur zu legen.

Zitat von DeejayMD

Proxymodus funktioniert zwar, aber produziert natürlich "Datenmüll", welcher bei großen Projekten schnell viel Speicher frisst. Ich habe mir bisher damit beholfen, dass ich extrem problematische Clips mit "Umschalt+G" rendere. Besser als die komplette Timeline zu rendern.

Der Nachteil beim temporären Rendern (und da gehört auch Umschalt+G dazu) ist halt, dass Änderungen zur Ungültigkeit der Renderdatei führen können. Es muss dann jedesmal wieder neu gerendert werden, was halt viel Zeit kostet.

Hinsichtlich des geringeren Speicherbedarfs kommt es halt darauf an wie groß der Anteil der Clips ist, die nicht ruckelfrei laufen.

Sind es nur wenige, wird temporäres Rendern oder auch Umwandeln in HQX tatsächlich günstiger sein.

Ab einem gewissen Grad wird dann aber doch der Proxy-Modus weniger Speicherplatz benötigen, da die Proxy-Dateien im Vergleich zum Quellmaterial wesentlich kleiners sind, Renderdateien, bzw. HQX Umwandlungen aber immens groß..

Zitat von DeejayMD

Beim Rausrendern ist die NVIDIA-Unterstützung wieder super!

Absolut, grade mit Edius X.

Denn beim Encodieren (Export) wird auch die Leistung der Nvidia gut abgerufen. Das Problem ist wie gesagt das Decodieren, Hier spricht Edius die Nvidia kaum an.

Zitat von DeejayMD

Hinzu kommt, dass AMD im Jahre 2021 die besseren Chips produzierte, was Preisleistung angeht.

Darüber streiten sich die Geister.

Grade für den Videoschnitt sind erfahrungsgemäß Intel-Systeme meist die bessere Wahl, da auf diesen entwickelt wird. So manche AMD CPU, die sich von den Testwerten her dem Intel-Modell überlegen zeigte, lag dann in tatsächlichen Einsatz als Schnittrechner hintendran.

Zitat von DeejayMD

Mir ist ebenfalls aufgefallen, dass Edius mit den Videos aus DJI-Drohnen so seine Probleme hat. Lief es mit der Inspire 1 noch recht flüssig fing es ab der Mavic 2 Pro an schwierig zu werden. Die 10bit-HLG-Files aus meiner Panasonic GH5 hingegen laufen recht flüssig.

Ja, wie gesagt liegt es tatsälich daran, wie die Kamera das Material encodiert.

Bei machen Quellmaterialien geht da halt nichts, auch wenn vergleichbares, oder vermeintlich schwierigeres Materal einwandfrei funktioniert.

Gruß

Peter

Zitat von DeejayMD

1. Den Testclip habe ich hier heruntergeladen:

Das Video mit dem Wasserfall finde ich dort nicht.

Finde dort nur etwas mit:
"Anmerkung: Ich werde ProRes-Dateien so schnell wie möglich hochladen!"

Zitat von Pee

Das Video mit dem Wasserfall finde ich dort nicht.

Es geht auch nicht um den Wasserfall, wo der herhommt oder warum der im Link auftaucht, weiß ich auch nicht.

Aber es geht um den Clip auf dem Waldweg aus dem Screencapture aus #1. Dieser ist unter den Video "Click 3" zu finden.

Wie gesagt lässt sich der auf meinem Core-X-System, welches ja über kein QS verfügt, nicht ruckelfrei abspielen. Interessant wäre deshalb, ob der auf Deinem Rechner (i9 9.Gen) mit QS läuft. Oder noch besser auf einem Intel System mit einer CPU der Gen. 12 oder 13, wenn hier ein Mitleser über ein solches verfügt.

Gruß

Peter

Danke Peter,

den Clip DJI_0026 habe ich in ein UHD-Projekt geladen der Wiedergabepuffer
wird sehr schnell gefüllt und bleibt stabil über die Clipzeitlänge, Wiedergabepuffer 4GB.
Der Clip wird mit roter Linie markiert wenn man die Wiedergabe startet.

Über die BM Intensity I/O Karte wir die Vollbildvorschau ausgeben auf einen HDTV.

Die Wiedergabe ruckelt leicht, wenn man da noch einige Filter auflegt wird es schlimmer.
Ich möchte mit solchen Clips nicht arbeiten wollen. auch nicht mit verminderter Auflösung
oder Proxy oder Vorschaurendering.

Zitat von Pee

den Clip DJI_0026 habe ich in ein UHD-Projekt geladen der Wiedergabepuffer
wird sehr schnell gefüllt und bleibt stabil über die Clipzeitlänge,...

...

Die Wiedergabe ruckelt leicht, wenn man da noch einige Filter auflegt wird es schlimmer.

Könnte das leichte Ruckeln dann aber an den 25p der Aufnahme liegen?

Denn beim Abspielen über einen Player (VCL und Win Medienwiedergabe) sehe ich das auch. 25p ruckelt ja bei Bewegungen sowieso relativ schnell. Und bei dem Clip scheint mir einfach die Bewegungsunschärfe zu fehlen.

Zumindest scheint da QS wirklich der ausschlaggebende Faktor zu sein.

Gruß

Peter

Zitat von gurlt

Könnte das leichte Ruckeln dann aber an den 25p der Aufnahme liegen?

Bestimmt nicht, denn in DaVinci Resolve läuft der Videoclip superweich, so wie man sich
die vollauflösende Vorschau wünscht, DVR nutzt die Grafikkarte viel besser aus.
92-100% GPU-Auslastung, die Intel-CPU unterstützt das System noch mit bis zu 23%.

Nachtrag für EDIUS X:

5,8% GPU-Auslastung, die Intel-CPU unterstützt das System noch mit bis zu 39,4%.

Zitat von gurlt

Wie gesagt lässt sich der auf meinem Core-X-System, welches ja über kein QS verfügt, nicht ruckelfrei abspielen. Interessant wäre deshalb, ob der auf Deinem Rechner (i9 9.Gen) mit QS läuft. Oder noch besser auf einem Intel System mit einer CPU der Gen. 12 oder 13, wenn hier ein Mitleser über ein solches verfügt.

Also auf meinem System läuft der Clip nur ganz minimal ruckelig (bei 100%). Allerdings hab ich auch mal einen Test mit Magix Video Pro X15 gemacht. Da läuft es komplett ruckelfrei.

Zitat von Grauer Tiger

Also auf meinem System läuft der Clip nur ganz minimal ruckelig (bei 100%). Allerdings hab ich auch mal einen Test mit Magix Video Pro X15 gemacht. Da läuft es komplett ruckelfrei.

EDIUS X gerät bei der Echtzeitwiedergabe der modernen Videoformate in den Rückstand.

Zitat von Grauer Tiger

Also auf meinem System läuft der Clip nur ganz minimal ruckelig (bei 100%). Allerdings hab ich auch mal einen Test mit Magix Video Pro X15 gemacht. Da läuft es komplett ruckelfrei.

Das ist bei meinem VDL 2024 Premium ebenfalls der Fall.

Hallo,

Da sind wir wieder beim Thema über die Zukunft unserer Schnittsoftware. Ich bin seit Version 1 dabei und merke das unser Edius deutlich in‘s Hintertreffen gerät. Wenn nicht die Gewohnheit und die lange Einarbeitung in eine andere Software wäre…

Also liebe Entwickler - oder gibt es nur noch einen Teilzeitprogrammierer- bitte bald eine wirklich neue Version 10.5, die hatte ja immer Neuerungen. Es ist schön das der neue Aufbau viele Möglichkeiten gibt, aber es sollten auch Ergebnisse folgen.

LG

Elimar

Hard- und Softwarestand siehe Signatur.
Mein Test (ohne Effekte):

Edius CPU 20-25%, Intel 10-15%, Nvidia 0%: leichtes Ruckeln in der Vorschau
Resolve (18.5.1): CPU ~15%, Intel 0%, Nvidia 30-35%: flüssige Vorschau ohne Ruckeln

Video deLuxe 2023: CPU 25-35%, Intel 12%, Nvidia 35%: flüssige Vorschau ohne Ruckeln
Mediaplayer Classic (1.7.13): CPU 17%, Intel 85%, Nvidia 0%: flüssige Vorschau ohne Ruckeln

Dabei habe ich für Edius ein Projekt mit der Original-Auflösung erstellt, bei Resolve den Clip in ein UHD-Projekt und bei VdL in FHD-Projekt importiert.
LG

Zitat von hearmyvoice

Dabei habe ich für Edius ein Projekt mit der Original-Auflösung erstellt, bei Resolve den Clip in ein UHD-Projekt und bei VdL in FHD-Projekt importiert.

Wie gesagt liegt das Problem in Edius bei der Decodierung des Quellmaterial, nicht bei der Skalierung. Diese dürfte als Dowscaling auch eher weniger Probleme bereiten.

Aus irgendwelchen Gründen kann Edius weder die volle Power der CPU, noch die der GPU nutzen.

Zitat von gurlt

Aus irgendwelchen Gründen kann Edius weder die volle Power der CPU, noch die der GPU nutzen.

Nicht Fisch nicht Fleisch. Es fehlt die Optimierung über Intel hinaus. Für NVIDIA und RADEON.

Ein Kombi-Betrieb bleibt ein Nadelöhr, da dabei ja Intel die Daten entpackt und die Grafikkarte die entpackten Daten in voller Breite "durchschleusen" muss.

Dementsprechend sollte das Video dort gepackt und entpackt werden, wo es auch dargestellt werden soll, sprich wo der Monitor dran hängt.