MMM ist dort: IBC 2022 und EDIUS - Grass Valley Foren
Vielleicht gibt es hier bald einen Bericht darüber?

Videoaktiv hat Infos veröffentlicht
videoaktiv.de/praxistechnik/in…t-messe-in-amsterdam.html

Jetzt gibt´s Neuigkeiten von Edius

Meine Einschätzung: Für "uns" als normale Anwender wird sich also mit 10.33 nichts ändern; immer noch keine flüssige Darstellung eines DJI-Mavic-streams (wie es z.B. der VLC-player sehr gut vormacht) und so vieles, welches das Leben leicht machen würde...
Aber einen kleinen Hoffnungsschimmer für später gibt es ja vielleicht doch: Die OFX-bridge.
Hoffentlich wenigstens weitere Verbesserungen an der Render-Baustelle. Bei mir hat sich unter 10.32 die Stabilität deutlich verbesser, so dass der Rechner pro Arbeitstag meistens nur noch ein oder zweimal einen Neustart erfordert. Dem komme ich derzeit mit selbst veranlaßten Neustarts nach 3-5 Stunden zuvor ;)....
Grüße,
Jaeger

VCL ist halt ein Player, also ein reines Abspieltool. Das ist etwas völlig anderes als ein NLE zur Bearbeitung von Videos, auch wenn da natürlich ebenfalls ein Bild gezeigt wird.
Und das Material aus solchen Geräten wie DJI Mavic oder auch Smartphones ist halt auf Grund der für eine Bearbeitung ungünstigen Komprimierung nicht so leicht zu verarbeiten. Wobei es sicherlich auch NLEs gibt, die damit etwas besser zu Rande kommen mögen als Edius.

Auf die native OFX-Unterstützung bin ich auch schon sehr gespannt. Wenn dort dann auch endlich NEAT Video (natürlich die OFX-Version) mit mehr als 8bit Farbtiefe unterstützt würde, wäre das ein eindeutiger Fortschritt. Darauf warte ich schon lange.


Derartiges kenne ich nicht.
Bei mir arbeitet Edius X auch mit dem anspruchsvollem BRAW 6K-Material ohne Abbrüche oder Einfrieren.


Gruß
Peter

Also ich habe mit dem Abspielen der DJI Mini 3 - Dateien in 4K (auch nachbearbeitete D-Log) auf der Timeline kein Problem, werden flüssig abgespielt...

Da wir in unserem Büro viel rendern (c4D) haben wir Workstations mit Doppel-Xeon Platinum 8160 , also 96 threads; Win 10 Pro, 21H2 - 19044.2006, 128 GB, ausschließlich Samsung-SSD´s, RTX 5000.

Ich denke, das fehlende Quicksync ist hier der Pferdfuss; daher immer wieder mein Wunsch nach alternativer Unterstützung durch die Graka.
Auch ich kann mich nicht mit stand-alone-Programmen anfreunden, da die Einsatz-Notwendigkeit im Workflow erst entsteht. Alle Projekte haben UHD 60p, viel Einsatz von Mercalli (letzte plugin-Version) und neat. Hier passieren auch die meisten Abstürze. Manchmal - wie ich schon vor kurzem beschrieben hatte - nicht mal mit Neustart oder Renderdateilöschung zu beheben, sondern nur mit Verschieben des betreffenden clips auf eine andere Spur.
Wenn die neue OXF-bridge wirklich ermögliche könnte, die Plugins schneller und stabiler und vor allem 10-Bit-fähig zu nutzen, würde ich sehr viel entspannter mit Edius arbeiten, zumal bald auch unsere Footage immer 4:2:2, 10 Bit haben wird.

Herzliche Grüße,
Jaeger

ASUS Z170-A, INTEL Core i7-6700K, 32 GB DDR4 RAM, GTX 1070 8GB GDDR5, SAMSUNG 850 Pro 500-GB, LG-BH16NS55, iiYama E2409HDS
- WIN-10/64 PRO (21H2-19044.2006), Firefox, WeTransfer, ImageBurn u.a.
- EDIUS-X(10.32.8750)-WG, RESOLVE-18.0.3.0005 Studio u.a.

Hi,

da kommt es halt darauf an, was ihr verarbeitet.
Bei H.264/H.265 Material (wie wohl aus der DJI vorliegen dürfte) wäre die QS-Unterstützung wertvoll. Bei Materialien wie ProRes oder BRAW bringt das wenig bis nichts, da sind mehr Kerne besser (deshalb bei mir ja auch die Core-X CPU).

Neat und vermutlich auch Mercalli dürften QS nicht unterstützen ( @kpot11 , Kurt, kannst Du dazu was sagen?).
Ansonsten ist die mit Edius X eingeführte Unterstützung der (einer) Nvidia-Karte schon sehr gut und lastet diese durchaus aus. Allerdings halt immer nur eine Nvidia, auch wenn im System mehr verbaut sind.

Aber bei bestimmten Quellmaterial auf der TL - da offenbar insbes. H.264 - kann es bei diesen beiden PlugIns (insbes. wenn dann auch noch in Kombination auf dem selben Clip) zu übermäßig langen Rechenzeiten kommen. Neat geht dann z.B. durchaus bis auf eine Renderzeit zurück, die sonst von nur 1 Thread geleistet würde.
M.E. dürfte das an einer zu langsamen Decodierung des TL-Materials liegen, sodass die vollen Rechenressourcen dann nicht ausgenutzt werden. Tatsächlich wird dann dabei eine vorhandene GraKA auch nur minimal belastet.

Dadurch kann es auch zeitweise so wirken als wäre Edius / der Rechner "eingefroren". In einigen Fällen kommt dann sogar die Edius Fehlermeldung, welche aber bei (sehr langem) Abwarten von allein verschwindet.

Umgehen kann man dies, wenn das Quellmaterial (z.B. per Shift+Q Rendern, oder Umwandeln) zuvor in GV HQ/HQX gewandelt wird und Mercalli/Neat dann auf der TL erst auf diese HQ/HQX-Dateien angewendet wird. Die Rechendauer beider Prozesse zusammen ist wesentlich kürzer, als die direkte Berechnung aus H.264.
Nachteil ist dabei halt nur der erhöhte Speicherbedarf durch die nicht zu unterschätzenden HQ/HQX-Dateien.


Gruß
Peter

Das OFX Thema ist wirklich genial.
Scheinbar läuft auch MB Looks, was ich oft nutze und daher immer auf Edius 9 zurück greifen musste. Wenn das jetzt in Edus 10 geht wäre das ein echter Fortschritt.

DJI Material macht bei mir übrigens keinerlei Probleme.

Das Umwandeln in HQX (Standard) mache ich ohnehin, da ich derzeit noch viel Quellmaterial mit H264 / h265 habe. Das "mit dem länger Warten" kenne ich, insbesondere beim Hochfahren großer Projekte und kann das Ignorieren der Fehlermeldung voll und ganz bestätigen.
Trotzdem hängt sich Edius im Zusammenhang mit Mercalli immer wieder (vielleicht 2 mal am Tag) auf; dies aber nur nach längerem Arbeiten. Habe die Backupzeit auf 5 Minuten gestellt, um mich nicht immer zu sehr zu ägern...
Ich trimme übrigens logischerweise alles Quellmaterial vor der Wandlung in HQX, um den Speicherbedarf zu minimieren.
Mercalli und Neat werden übrigens extrem durch die vielen Kerne beschleunigt (nur wenn HQX vorliegt); das ist in der Pryxis kein wirklicher Flaschenhals mehr. Das Rendern dauert etwas mehr als die cliplänge.

Dabei sollte H265 Material noch länger benötigen als H264, da 265 vorwärts und rückwärts Bezüge hat während 264 nur vorwärts Bezüge hat. Wenn die Bilder einzeln per Bildnummer angesprochen werden, dann muss zum vorhergehenden Keyframe gesprungen werden und von da aus das entsprechende Interframe berechnet werden. Sind mehrere Interframes vor dem gesuchten Bild, dann muss man sich immer zum gesuchten Bild "durchhangeln". Das ist, was Zeit kostet.

Bei HQX ist jedes Bild komplett. Deshalb geht es da soviel schneller. Da gibt es den sogenannten Frameserver, der jedes einzelne Bild ausgibt und für Berechnungen zur Verfügung stellt.

Neat vergleicht ja selbst Bildsequenzen, um das Bildrauschen reduzieren zu können.

Vermutlich werden da dann die einzelnen Frames abgefragt und übergeben.

Hätte man da einen rollierenden Puffer, der eine Sequenz von allen Bildern zwischen zwei Keyframes beinhaltet, dann könnte man verzögerungsfrei diesen Sequenzbereich analysieren.

Deshalb werden die h264/265 quasi durch Mehrfachdekodierung gebremst, um jedes Frame einzeln ansprechen zu können.

In diese Richtung geht ja auch meine Vermutung.

Wobei halt eben neben dem Codec selbst wohl insbes. auch die Art der Codierung eine große Rolle spielt.
UHD H.264-Material aus meiner Osmo Pocket (1) zusammen mit Neat braucht ewig. Vergleichmaterial aus einer anderen Kamera (Canon?) lief da unter sonst gleichen Bedingungen wesentlich besser.


Beim Mercalli 5 Pro PlugIn (also nicht RT) ist es ähnlich, aber nicht ganz so auffällig.




Ok, Danke.
Da ich eben kein QS habe konnte ich das nicht feststellen.


Gruß
Peter

Bei dem schnellen und langsamen Material h264 würde ich mal die Struktur der K, I und P Frames untersuchen. Bestimmt sind die langsamen auch die LongGOP Formate bzw. die, welche viel I und P Frames zwischen den Keyframes haben. Je länger die Ketten der aufeinander aufbauenden Frames sind, desto öfter müssen sie für Analysesoftware durchlaufen werden, um jedes Bild zwischen den Keyframes einzeln zu rekonstruieren.

Die Vergleichclips habe ich nicht mehr, da diese nicht von mir stammten.
Die MediaIndo der Osmo Pocket Clips sehen für mich eigentlich völlig ok aus. Kein LongGOP. Lediglich die ReferenzFrames stehen auf 1, bei den meisten mir bekannten War das m.E. 2.




Und genau das ist halt das Problem.
Hier bremst die Decodierung durch Edius die Verarbeitung aus. Bei HQX passiert das dann logischerweise nicht.

Gruß
Peter