IBC2022

  • Workgroup Version X

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • MMM ist dort: IBC 2022 und EDIUS - Grass Valley Foren
    Vielleicht gibt es hier bald einen Bericht darüber?
    Servus, Pee
    EDIUS X WG, DVR 18 Studio, i9-9900K mit Intel HD-630, 32GB RAM, SSD-System + Diverse FP,
    NVIDIA GF-RTX 2060 Super 8GB, W10Pro(21H2), 32" LG PC-Monitor, 32" HDR(HLG)-Vorschau TV per BM Intensity Pro 4K
    Sony ZV-1 mit Zhiyun Crane M2 , GoPro Hero 7 Black, DJI Pocket 2, DJI Mavic Mini, Mercalli V6 SAL, Luminar 4.3.4
  • 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
  • Jaeger schrieb:

    Bei mir hat sich unter 10.32 die Stabilität deutlich verbesser, so dass der Rechner ...
    Um welche Hardware handelt es sich dabei? // Muster siehe meine Signatur.
    Welche WIN-Version?
    kurt
    HW: ASUS Z170-A; Proz: i7-6700K; RAM: 32 GB DDR4; GPU: RTX-3070, 8GB GDDR5; SSD: SAMSUNG-850-Pro, 500 GB
    SW: WIN-10/64 PRO (22H2-19044.2130), Firefox u.a.
    NLE: EDIUS-X(10.34.9631)-WG; RESOLVE-18.1.1.0007 Studio
  • Jaeger schrieb:

    immer noch keine flüssige Darstellung eines DJI-Mavic-streams (wie es z.B. der VLC-player sehr gut vormacht)
    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.


    Jaeger schrieb:

    so dass der Rechner pro Arbeitstag meistens nur noch ein oder zweimal einen Neustart erfordert.
    Derartiges kenne ich nicht.
    Bei mir arbeitet Edius X auch mit dem anspruchsvollem BRAW 6K-Material ohne Abbrüche oder Einfrieren.


    Gruß
    Peter
    ASUS Prime X299-A II, i9-10980XE, 64 GB, Nvidia RTX 2080Ti, BMD UltraStudio 4K Mini, RME Fireface 400, Win 11 Pro , EDIUS WG X
  • Jaeger schrieb:

    immer noch keine flüssige Darstellung eines DJI-Mavic-streams
    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...
    Grüße
    Hans

    ________________________________________________________________________________________
    ASUS Prime Z390-A, Intel i9-9900K, GTX1660S-6G Super, BM Intensty Pro 4K
  • 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.
  • Jaeger schrieb:

    Ich denke, das fehlende Quicksync ist hier der Pferdfuss; daher immer wieder mein Wunsch nach alternativer Unterstützung durch die Graka.
    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
    ASUS Prime X299-A II, i9-10980XE, 64 GB, Nvidia RTX 2080Ti, BMD UltraStudio 4K Mini, RME Fireface 400, Win 11 Pro , EDIUS WG X
  • gurlt schrieb:

    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.
    1) Das ist auf jeden Fall zu empfehlen, da hier ein Beschleunigungsfaktor von bis z.B. 10 erreicht werden kann (nicht zuletzt durch den Intra-Codec von HQX).

    2) Clips vor der Verwendung in einer Timeline/Sequenz in HQX(fine) in der BIN umwandeln wäre eine weitere Alternative. Damit könnte man sich Shift+Q ersparen.

    3) Quick-Sync: Weiß ich nicht (mehr?) auswendig; werde ich klären.

    kurt
    HW: ASUS Z170-A; Proz: i7-6700K; RAM: 32 GB DDR4; GPU: RTX-3070, 8GB GDDR5; SSD: SAMSUNG-850-Pro, 500 GB
    SW: WIN-10/64 PRO (22H2-19044.2130), Firefox u.a.
    NLE: EDIUS-X(10.34.9631)-WG; RESOLVE-18.1.1.0007 Studio
  • 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.
    ---------------------------------------------
    Mainboard Asus Prime Z370-A, CPU Coffeelake i7-8700 mit CPU-Grafik HD Graphics 630, NVidia GTX 1050 Grafikkarte, Win 10 (64 bit).
  • 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.
  • KlausM schrieb:

    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.




    kpot11 schrieb:

    Mercalli-5 (PlugIn) benutzt die Intel-Grafik.
    Ok, Danke.
    Da ich eben kein QS habe konnte ich das nicht feststellen.


    Gruß
    Peter
    ASUS Prime X299-A II, i9-10980XE, 64 GB, Nvidia RTX 2080Ti, BMD UltraStudio 4K Mini, RME Fireface 400, Win 11 Pro , EDIUS WG X
  • 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.
  • kpot11 schrieb:

    // NeatVideo muss ich mir noch ansehen.
    Wie o.a. zur Information der Forumsbenutzer:
    Meine Fragen an NeatVideo und die Antworten dazu:

    1) In unseremEDIUS-Forum (Edius–10.32) ist die Frage aufgetaucht, obNeatVideo(aktuelle Version) die interne Intel-Grafikkarte (“QuickSync”) benutzt (falls im Prozessor aktiv).
    No, it does not use Intel Graphics.

    2) Bzw. welche der drei u.a. Ressourcen benutzt NeatVideo:
    a) CPU
    b) Intelgrafikkarte (“QuickSync”)
    c) Nvidia-Grafikkarte
    CPU and supported NVIDIA and AMD GPUs.

    3) Wenn b) UND c) im PC vorhanden sind: Werden beide benutzt?
    No, only NVIDIA/AMD.

    4) Hauptsächlich benutzte Codecs:
    Interframe Codecs: h.264, h.265
    Intraframe-Codecs: HQX
    That is not relevant to the work of a video effect. It is a job of Edius itself to interact with codecs. Video effects do not interact with codecs.

    PS: Ich habe die o.a. Antworten von NeatVideo nach nur 20 min erhalten und möchte mich für diese (nicht selbstverständliche) rasche Reaktion auch an dieser Stelle bei NeatVideo (Vlad) ausdrücklich bedanken !!

    kurt
    HW: ASUS Z170-A; Proz: i7-6700K; RAM: 32 GB DDR4; GPU: RTX-3070, 8GB GDDR5; SSD: SAMSUNG-850-Pro, 500 GB
    SW: WIN-10/64 PRO (22H2-19044.2130), Firefox u.a.
    NLE: EDIUS-X(10.34.9631)-WG; RESOLVE-18.1.1.0007 Studio
  • KlausM schrieb:

    Bei dem schnellen und langsamen Material h264 würde ich mal die Struktur der K, I und P Frames untersuchen.
    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.




    kpot11 schrieb:

    4) Hauptsächlich benutzte Codecs:
    Interframe Codecs: h.264, h.265
    Intraframe-Codecs: HQX
    That is not relevant to the work of a video effect. It is a job of Edius itself to interact with codecs. Video effects do not interact with codecs.
    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
    ASUS Prime X299-A II, i9-10980XE, 64 GB, Nvidia RTX 2080Ti, BMD UltraStudio 4K Mini, RME Fireface 400, Win 11 Pro , EDIUS WG X