Edius 9.31 WG hängt beim Rendern von XAVC-I bei 93%

  • Workgroup Version 9.x
  • Edius 9.31 WG hängt beim Rendern von XAVC-I bei 93%

    Neu

    Edius 9.31 Work Group hat beim Rendern wohl neuerdings ein Problem.
    Ich rendere eine UHD File in XAVC-I und ab 93% geht der Fertigstellungs-Prozentsatz nicht mehr weiter und die Restzeit erhöht sich immer weiter.
    Es hilft nur noch abbrechen.
    Was neu ist(ist mir jedenfalls bisher nicht aufgefallen) - die bis dato gerenderte File(93%) ist nach dem Abbruch vorhanden.
    Dadurch konnte ich die Quell File am Punkt 93% überprüfen - es ist jedoch alles in Ordnung.
    Gruss
    Jürgen
    _______________________________________________________________________________________________________________________
    Triple Boot:Win10/Win10/Win10/I7-5930K/GTX 780/ 1TB SW RAID:1000MB Read-Write/15TB Video RAID:650MB Read-Write/Intel X550
    Triple Boot:Win7/Win10/Win10/I7-6950X/GTX 1080/SW:M.2 5300MB Read-2100 Write/15TB Video RAID:850MB Read-Write/BMD 4K Extreme
    both on:10Gbps Media sharing Network, 10Gbps NAS
  • Neu

    Ich habe jetzt die gleiche Quellfile mit HQX gerendert.
    Das Ergebnis ist das gleiche - Edius hängt bei 93% und es geht nur noch Abbrechen.

    Zur Zeit läuft der Versuch der Ausgabe mit H264.
    Mir kommt es so vor, daß es nicht so ist wie gewohnt.
    Es dauert unheimlich lange und die CPU ist nicht wie üblich bei fast 100%.
    Für eine Timeline von 3:8:34 will er 3 Stunden und 20 Minuten rendern - indiskutabel !
    Gruss
    Jürgen
    _______________________________________________________________________________________________________________________
    Triple Boot:Win10/Win10/Win10/I7-5930K/GTX 780/ 1TB SW RAID:1000MB Read-Write/15TB Video RAID:650MB Read-Write/Intel X550
    Triple Boot:Win7/Win10/Win10/I7-6950X/GTX 1080/SW:M.2 5300MB Read-2100 Write/15TB Video RAID:850MB Read-Write/BMD 4K Extreme
    both on:10Gbps Media sharing Network, 10Gbps NAS
  • Neu

    Hallo Jürgen,

    könntes tdu das selbe Problem haben wie DCH-Treiber für Intel UHD 630-Grafikkarte: kein Quicksync mehr?
    Speicherplatz noch genügend vorhanden - überprüfen!
    Temperaturproblem? Überprüfen!
    Gruß Heinz
  • Neu

    Hallo Heinz,

    ich denke nicht, meine I7-6950X hat keine Grafik und somit kein Quick Sync.

    Ich habe jetzt per Image auf Edius 9.30 WG zurückgesetzt, der Fehler ist der gleiche.
    Jetzt lösche ich auf der Timeline von hinten angefangen Clips.
    Gruss
    Jürgen
    _______________________________________________________________________________________________________________________
    Triple Boot:Win10/Win10/Win10/I7-5930K/GTX 780/ 1TB SW RAID:1000MB Read-Write/15TB Video RAID:650MB Read-Write/Intel X550
    Triple Boot:Win7/Win10/Win10/I7-6950X/GTX 1080/SW:M.2 5300MB Read-2100 Write/15TB Video RAID:850MB Read-Write/BMD 4K Extreme
    both on:10Gbps Media sharing Network, 10Gbps NAS
  • Neu

    Wenn es bei 9.30 auch so ist, scheint es nicht das (offensichtlich) neue Problem der 9.31 zu sein.
    Hast du das entsprechende Stück mal gerendert und es dann versucht?
    Die Quelldatei ist aber in Ordnung, oder?
    Sonst versuch doch mal den Teil bei 93% in eine neue Sequenz zu legen und die zu rendern. Um den Fehler einzugrenzen...
    ---------------------------------------------
    Mainboard Asus Prime Z370-A, CPU Coffeelake i7-8700 mit CPU-Grafik HD Graphics 630, NVidia GTX 1050 Grafikkarte, Win 10 (64 bit).
  • Neu

    Ja, richtig - scheint nicht an der 9.31 zu liegen.
    Ich habe jetzt bei der Quelldatei begonnen von hinten her die Clips zu löschen.

    Eine der gelöschten Clips scheint es zu sein.
    Jetzt ist das rendering zu 100% durchgelaufen.
    Mal sehen ob ich an den Clips was falsches finde.
    Gruss
    Jürgen
    _______________________________________________________________________________________________________________________
    Triple Boot:Win10/Win10/Win10/I7-5930K/GTX 780/ 1TB SW RAID:1000MB Read-Write/15TB Video RAID:650MB Read-Write/Intel X550
    Triple Boot:Win7/Win10/Win10/I7-6950X/GTX 1080/SW:M.2 5300MB Read-2100 Write/15TB Video RAID:850MB Read-Write/BMD 4K Extreme
    both on:10Gbps Media sharing Network, 10Gbps NAS
  • Neu

    Ich habe das Problem gefunden.
    Es war eine Still Datei die zwar nur einfach als File vorhanden war aber zweimal mit dem gleichen Namen in der gleichen Bin stand.
    Ich wusste garnicht das das möglich ist.

    Dabei ist Edius offensichtlich beim rendern ins Schleudern geraten.
    Gruss
    Jürgen
    _______________________________________________________________________________________________________________________
    Triple Boot:Win10/Win10/Win10/I7-5930K/GTX 780/ 1TB SW RAID:1000MB Read-Write/15TB Video RAID:650MB Read-Write/Intel X550
    Triple Boot:Win7/Win10/Win10/I7-6950X/GTX 1080/SW:M.2 5300MB Read-2100 Write/15TB Video RAID:850MB Read-Write/BMD 4K Extreme
    both on:10Gbps Media sharing Network, 10Gbps NAS
  • Neu

    Juergen E schrieb:

    Es war eine Still Datei die zwar nur einfach als File vorhanden war aber zweimal mit dem gleichen Namen in der gleichen Bin stand.


    Ich wusste garnicht das das möglich ist.
    HI,

    doch, Du kannst jeden beliebigen Clip (also auch Stills) durch Kopieren/Einfügen, bzw. die entsprechende (Win) Tastenkombination, auch mehrfach in die BIN legen.
    Sinnvoll ist das z.B., wenn Du in der BIN eine Ordnerstruktur verwendest, die den Schnitt der einzelnen Sequenzen "widerspiegelt". Wird dann einer der Clips in einer Sequenz mehrfach, oder in mehreren Sequenzen verwendet, dann muss Du ja dort jeweils eine "Kopie" liegen haben können.

    Die Kopien haben zunächst alle den gleichen Namen, der aber manuell geändert/ergänzt werden kann. Da es sich quasi nur um "Verknüpfungen" zur gleichen (physischen) Datei handelt, verweisen die selbstverständlich auf diese.

    Was ich damit sagen will - das Vorhandensein einer "Kopien" in der BIN allein kann also nicht der Fehler gewesen sein.


    Gruß
    Peter
    ASUS P9X79 - i7-4820K CPU 3,70 GHz - 32 GB RAM - PNY Quadro K2000D - 256 GB Samsung SSD + 2 x 2 TB als RAID 1 - RME Fireface 400 - Win 10 Pro - EDIUS WG 9 - BMD FUSION 9
  • Neu

    gurlt schrieb:

    das Vorhandensein einer "Kopie" in der BIN allein kann also nicht der Fehler gewesen sein.
    Das meine ich auch!
    kurt
    - ASUS Z170-A, INTEL Core i7-6700K, 32 GB DDR4 RAM, GIGABYTE GeForce GTX 1070 8GB GDDR5, SAMSUNG 850 Pro, LG-BH16NS55, iiYama E2409HDS
    - WIN-10/64 PRO, Firefox, DropBox, ImageBurn, PhantomDrive
    - EDIUS-9.31(4196), Mercalli-2 und 4, NeatVideo, NewBlue ChromaKeyPro, Audacity, Adobe Photoshop, Cyberlink Power-DVD, Movavi VideoConverter Premium, RESOLVE-15, Adobe InDesign, andere diverse System- und AV-Tools
  • Neu

    Sorry, war aber so - nach Entfernung der Dublette lief das rendering durch.
    Gruss
    Jürgen
    _______________________________________________________________________________________________________________________
    Triple Boot:Win10/Win10/Win10/I7-5930K/GTX 780/ 1TB SW RAID:1000MB Read-Write/15TB Video RAID:650MB Read-Write/Intel X550
    Triple Boot:Win7/Win10/Win10/I7-6950X/GTX 1080/SW:M.2 5300MB Read-2100 Write/15TB Video RAID:850MB Read-Write/BMD 4K Extreme
    both on:10Gbps Media sharing Network, 10Gbps NAS
  • Neu

    Juergen E schrieb:

    Sorry, war aber so - nach Entfernung der Dublette lief das rendering durch.
    Ich glaube Dir ja auch. Bloß bei soviel Bits, die da mitwirken, genügt ja irgendwo in diesem Bitdschungel ein einziges falsch gesetztes Bit und schon spielts Granada ?(
    Das eigentlich Lästige dabei ist, dass man mit der Ratio, der Logik alleine nicht (mehr) durchkommt, sondern einen sechsten Sinn benötigt, Bauchgefühl, Glück etc. um den wirklichen, irgendwo im Hintergrund versteckten Fehler nachvollziehbar zu finden. Vielleicht sollte man sich um die Bekanntschaft eines IT-Schamanen kümmern?
    Gruß kurt
    - ASUS Z170-A, INTEL Core i7-6700K, 32 GB DDR4 RAM, GIGABYTE GeForce GTX 1070 8GB GDDR5, SAMSUNG 850 Pro, LG-BH16NS55, iiYama E2409HDS
    - WIN-10/64 PRO, Firefox, DropBox, ImageBurn, PhantomDrive
    - EDIUS-9.31(4196), Mercalli-2 und 4, NeatVideo, NewBlue ChromaKeyPro, Audacity, Adobe Photoshop, Cyberlink Power-DVD, Movavi VideoConverter Premium, RESOLVE-15, Adobe InDesign, andere diverse System- und AV-Tools
  • Neu

    Juergen E schrieb:

    Sorry, war aber so - nach Entfernung der Dublette lief das rendering durch.
    Ja, das glauben wir Dir ja auch.

    Aber es muss da halt noch etwas anderes mitgespielt haben, sodass Edius diesen Verweis nicht richtig folgen konnte.
    Kopien von Clips in der BIN (und auf der TL ja sowieso) verwende ich häufig in meinen Projekten, ohne dass der Export scheitert. Ich habe es jetzt auch nochmal aktuell mit E WG 9.31 ausprobiert und auch da ging es.

    Wenn Du Zeit und Lust hast, kannst Du ja einfach mal eine Sequenz mit 2, 3 kurzen Clips anlegen, davon 1 Clip als Kopie in der BIN doppelt vorhanden, und exportieren. Das sollte eigentlich funktionieren.


    Juergen E schrieb:

    Ich habe jetzt bei der Quelldatei begonnen von hinten her die Clips zu löschen.

    Eine der gelöschten Clips scheint es zu sein.

    Hattest Du danach die gelöschten Clips aus der BIN heraus neu in die TL eingespielt (also "ersetzt"), oder bist Du per "Rückwärts" wieder auf den alten Stand zurückgegangen?
    Ich vermute mal die 1. Variante. Wodurch ja dann eine andere Instanz des Clips, als die nicht exportierbare auf die TL gezogen wurde.

    Gruß
    Peter
    ASUS P9X79 - i7-4820K CPU 3,70 GHz - 32 GB RAM - PNY Quadro K2000D - 256 GB Samsung SSD + 2 x 2 TB als RAID 1 - RME Fireface 400 - Win 10 Pro - EDIUS WG 9 - BMD FUSION 9
  • Neu

    Ich hatte gestern den gleichen Fehler - und das auch noch etwa etwa zur gleichen Zeit - wie Jürgen.
    Die Still-"Kopie" lag als aus einem Clip erzeugtes Standbild nur einmal in der BIN, befand sich aber an der gleichen Position der Timeline in der Sequenz einmal in der VA-Spur 1 und einmal direkt darüber in der V-Spur 3,
    aber mit jeweils durch den Layouter geänderten Inhalten.
    Aufgefallen ist mir das durch den vergeblichen Versuch, die Sequenz zu rendern. Der ist nämich "stecken" geblieben.

    Der anschließende Versuch, die Sequenz zu exportieren, blieb bei 81 % ebenfalls hängen, wie von Jürgen beschrieben.
    Ein "Rücksprung" auf Version 9.30 hat ebensowenig geholfen wie der Austausch des Intel-Grafik-Treibers von v6444 gegen v6373.
    Die Lösung war:

    gurlt schrieb:

    Die Kopien haben zunächst alle den gleichen Namen, der aber manuell geändert/ergänzt werden kann.
    Nach Löschen des Still-Images in V-Spur 3, Änderung des verwendeten Nanens und erneuten Einfügens in die Timeline funktionierten sowohl Rendering als auch Export (unter Version 9.31 mit Treiber v6444).

    Das Drollige daran ist, dass ich in der BIN nach wie vor nur einmal das Still-Image (mit dem geänderten Namen) habe, in der VA1-Spur der Timeline liegt trotzdem das Still-Image mit dem Ursprungsnamen. :?:

    Gruß
    Ulrich

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von uvo_47 () aus folgendem Grund: unvollständig beschrieben

  • Neu

    @uvo_47:
    Nur zur Info -
    Ich habe versucht, Dein Problem nachzuvollzuehen. Ist mir natürlich nicht gelungen. Bei mir gibts mit diesen Settings kein Renderproblem.
    Gruß kurt
    - ASUS Z170-A, INTEL Core i7-6700K, 32 GB DDR4 RAM, GIGABYTE GeForce GTX 1070 8GB GDDR5, SAMSUNG 850 Pro, LG-BH16NS55, iiYama E2409HDS
    - WIN-10/64 PRO, Firefox, DropBox, ImageBurn, PhantomDrive
    - EDIUS-9.31(4196), Mercalli-2 und 4, NeatVideo, NewBlue ChromaKeyPro, Audacity, Adobe Photoshop, Cyberlink Power-DVD, Movavi VideoConverter Premium, RESOLVE-15, Adobe InDesign, andere diverse System- und AV-Tools
  • Neu

    Hi,

    habe den "Versuchsaufbau" ebenfalls nachvollzogen (im Layouter andere Größe und Position verwendet).
    Auch bei mir funktioniert das ohne Probleme, egal ob .jpg oder .psd und ob die Datei im Projekt im Ordner Transferred, oder (bei Import) an einem anderen Speicherort liegt.

    Wie ja schon beschrieben, handelt es sich bei den Clips in der TL und auch in der BIN (auch bei einer "Kopie") lediglich um Verknüpfungen zu einer Datei.
    Eine Änderung des Clip-Namens benennt also nur die Verknüpfung um und hat somit (normalerweise) keinen Einfluss auf die Datei selbst. :nw:


    Deshalb glaube ich, die wirkliche Lösung war:

    uvo_47 schrieb:

    Nach Löschen des Still-Images in V-Spur 3, Änderung des verwendeten Nanens und erneuten Einfügens in die Timeline funktionierten sowohl Rendering als auch Export (unter Version 9.31 mit Treiber v6444).

    denn dadurch wurde ja der - vermutlich - beschädigte Clip auf der TL ausgetauscht. Die Umbenennung der Verknüpfung sollte darauf keinen Einfluss gehabt haben.

    Was jetzt die Nichtverwendbarkeit der jeweiligen Clips auf der TL bei Jürgen und Ulrich im einzelnen tatsächlich hervorgerufen hat, kann jetzt aber leider nicht nachvollzogen werden.



    Da es in beiden Fällen aber Standbilder betraf, wäre es interessant zu wissen, welche(s) Dateiformat(e) diese hatten (ich würde da aus einem Gefühl heraus beinahe auf .jpg tippen).
    Da ich mit Photoshop arbeite, verwende ich fast ausschließlich .psd.

    Gruß
    Peter
    ASUS P9X79 - i7-4820K CPU 3,70 GHz - 32 GB RAM - PNY Quadro K2000D - 256 GB Samsung SSD + 2 x 2 TB als RAID 1 - RME Fireface 400 - Win 10 Pro - EDIUS WG 9 - BMD FUSION 9
  • Neu

    Hallo,

    es ist eine *.tif Datei. Sie wurde aus einem UHD-Clip (3840X2160) mit Edius erstellt.
    Das habe ich unter Systemeinstellungen/Import/Export/Standbild auch so eingestellt.

    gurlt schrieb:

    Eine Änderung des Clip-Namens benennt also nur die Verknüpfung um
    Da bin ich ganz und gar deiner Meinung, deswegen schließe ich mich der Vermutung mit der vorherigen Beschädigung des Clips an.

    Nach der "reinen Lehre" solte es dann aber so sein, dass sich in der Bin der Ursprungsclip und zwei Verknüpfungen befinden. Das ist aber nicht der Fall, denn es sind in der Bin nur der Ursprungsclip und die geänderte Verknüpfung vorhanden. Schaut man unter Eigenschaften in der Timeline den Dateipfad an, zeigt das in der VA 1-Spur der Timeline befindliche Still-Image den ursprünlichen Namen der Verknüpfung mit Referenz zum Ursprungsclip an und das des in V 3-Spur liegenden Still-Images den geänderten Namen der Verknüpfung mit identischen Referenz.
    Daraus kann eigentlich nur folgen, dass Edius sowohl bei Rendering als auch bei Export auf den Pfad der V 1-Spur in der Timeline aus den *.ezp-Datei gespeicherten Daten zugreifen kann ohne eine Relation zur Bin.

    Ergänzen muss ich noch, dass das Standbild denselben Namen in der Bin bekommen hat wie der Ursprungsclip (also C0027) und nicht mit Still... beginnt. Dieses Phänomen habe ich in der Vergangenheit schon öfter gehabt, ohne es mir erklären zu können.



    Sollte es mir bei Gelegenheit gelingen, wieder ein solches Standbild mit dem Namen des Ursprungsclips zu erstellen, werde ich die Konstellation nachstellen und über das Ergebnis berichten.

    Gruß
    Ulrich
  • Neu

    uvo_47 schrieb:

    Sollte es mir bei Gelegenheit gelingen, wieder ein solches Standbild mit dem Namen des Ursprungsclips zu erstellen, werde ich die Konstellation nachstellen und über das Ergebnis berichten.
    Man kann in Edius ja auf zwei Arten ein Standbild erstellen. Die erste, ältere Möglichkeit hat keine Option, Ordner und Dateiname für den Export anzugeben. Mit der ersten Möglichkeit werden Dateinamen "Still...." vergeben.
    Siehe Screenshot meiner Timeline.
    Gruß kurt
    Bilder
    • Screenshot-6.jpg

      50,57 kB, 458×170, 15 mal angesehen
    - ASUS Z170-A, INTEL Core i7-6700K, 32 GB DDR4 RAM, GIGABYTE GeForce GTX 1070 8GB GDDR5, SAMSUNG 850 Pro, LG-BH16NS55, iiYama E2409HDS
    - WIN-10/64 PRO, Firefox, DropBox, ImageBurn, PhantomDrive
    - EDIUS-9.31(4196), Mercalli-2 und 4, NeatVideo, NewBlue ChromaKeyPro, Audacity, Adobe Photoshop, Cyberlink Power-DVD, Movavi VideoConverter Premium, RESOLVE-15, Adobe InDesign, andere diverse System- und AV-Tools
  • Neu

    uvo_47 schrieb:

    Nach der "reinen Lehre" solte es dann aber so sein, dass sich in der Bin der Ursprungsclip und zwei Verknüpfungen befinden.
    Da bin ich etwas anderer Meinung.

    Der Begriff Ursprungsclip ist m.E. falsch, da ja alle Clips in der Bin (und auf der TL) nur Verknüpfungen sind. Die eigentliche Datei "liegt" nicht in der Bin.
    Der ursprünglich über den Quellbrowser, oder Clip hinzufügen, bzw. in Deinem Fall mit Standbild erstellen die Bin gebrachte Clip hat die gleiche "Wertigkeit", wie jede Kopie dieses Clips. Jede Kopie ermöglicht über den Verweis den gleichen Zugriff auf die tatsächliche Datei, wie die von Dir als "Ursprungsclip" bezeichnete Verknüpfung. Deshalb kannst Du auch den "Ursprungsclip" jederzeit in der Bin löschen (natürlich gemeint per Löschen [Entf] und nicht per Datei löschen !!!). Solange Du noch eine Kopie dieses Clips in der Bin oder auf der TL hast, ist auch der Zugriff und damit die Verwendung gegeben.



    uvo_47 schrieb:

    Schaut man unter Eigenschaften in der Timeline den Dateipfad an, zeigt das in der VA 1-Spur der Timeline befindliche Still-Image den ursprünlichen Namen der Verknüpfung mit Referenz zum Ursprungsclip an und das des in V 3-Spur liegenden Still-Images den geänderten Namen der Verknüpfung mit identischen Referenz.
    Auch das ist verständlich, denn auch die Clips auf der TL sind Kopien der jeweiligen Verknüpfung. Deshalb liegt
    • auf der VA 1-Spur eine Kopie des (Bin-)Clips mit dem ursprünglichen Namen;
    • auf der V 3-Spur eine Kopie des (Bin-)Clips mit dem vorher geänderten Namen.



    Insoweit ist Deine Schlussfolgerung

    uvo_47 schrieb:

    Daraus kann eigentlich nur folgen, dass Edius sowohl bei Rendering als auch bei Export auf den Pfad der V 1-Spur in der Timeline aus den *.ezp-Datei gespeicherten Daten zugreifen kann ohne eine Relation zur Bin.
    fast richtig.

    Edius greift beim Export auf die in der Sequenz vorhandenen Clips ( = Verweise/Verknüpfungen zur Datei) unter Berücksichtigung gesetzter Filter zu.
    Die Bin hat mit dem Export insoweit nichts zu tun und ist so betrachtet nur ein (notwendiges) Hilfsmittel um die Clips vernünftig ordnen zu können.

    Auch wenn eine solche Vorgehensweise natürlich keinen Sinn macht, könntest Du rein theoretisch nach Erstellung der Sequenzen auch alle Clips (nicht die Dateien!!!) aus der Bin löschen und alles würde trotzdem funktionieren, da ja die Clips auf der TL auf die Datei verweisen.


    Gruß
    Peter
    ASUS P9X79 - i7-4820K CPU 3,70 GHz - 32 GB RAM - PNY Quadro K2000D - 256 GB Samsung SSD + 2 x 2 TB als RAID 1 - RME Fireface 400 - Win 10 Pro - EDIUS WG 9 - BMD FUSION 9
  • Neu

    Guten Morgen,

    inzwischen spricht alles dafür, dass Peter mit seiner Vermutung recht hat:

    gurlt schrieb:

    denn dadurch wurde ja der - vermutlich - beschädigte Clip auf der TL ausgetauscht

    Ich konnte nämlich zuerst den "Fehler" in einer anderen Sequenz mit einem anderen Standbild reproduzieren. Allerdings ließ sich dann keine Ursache finden; Filter Gauß'sche Unschärfe im Standbild in VA 1-Spur entfernt, sämtliche Unterschiede im Layouter zwischen dem Standbild in VA 1-Spur und dem in V 3-Spur sukzessiv elimiert usw. bis es sich nur noch um identische Standbilder handelte. Trotzdem konnte nur durch Austausch des Standbilds in V 3-Spur der "Fehler" beseitigt werden.

    Bei einem weiteren Versuch mit einem Clip in der letzten Sequenz des aus insgesamt 14 Sequenzen bestehenden Projekts trat dann der "Fehler" zu meiner völligen Verblüffung nicht mehr auf!

    Wodurch wurde nun das aus einem Clip erzeugte Standbild in Sequenz 3 "beschädigt" und das in Sequenz 14 dagegen nicht?

    Der Grund ist höchstwahrscheinlich darin zu suchen, dass ich mich erinnere, während der Bearbeitung des Projekts unter Systemeinstellungen/Import/Export/Standbild die Projekteinstellungen unter Halbbild erfassen von "Oberes Halbbild" auf "Bild" geändert zu haben!

    Zur Erklärung hierfür: Bei dem Projekt handelt um das erste, in dem ich ausschließlich UHD-Material aus einer Sony FDR AX 53 verwende. Zwar bearbeite ich es aus mehreren Gründen in HD, habe aber konsequenterweise die Bildfrequenz auf 25p eingestellt. In den Systemeinstellungen hatte ich aber die Halbbildoption (die in AVCHD 50i der Vermeidung des Zitterns von Standbildern diente) solange nicht geändert bis mich der "Geistesblitz" ereilte, die gewählte Halbbildoption zur Erstellung von Standbildern sei doch in einem 25p-Projekt fehl am Platze.

    Warum sich Edius an der falschen Halbbildopion beim Einfügen in die VA 1-Spur nicht stört, dagegen beim (erstmaligen) Einfügen in die V 3-Spur "zickt", vermag ich nicht zu erklären.

    @'Kurt
    Vielen Dank für den Tipp zu den unterschiedlichen Möglichkeiten, Standbilder zu erstellen. Ich hatte bisher nur die Schaltfläche für die "alte" Version oberhalb der Timeline. Dennoch hat diese Schaltfläche in meinem Projekt ja auch statt "Still..."-Dateinamen - nur - in der Bin die Dateinamen mit dem Clip-Dateinamen erstellt. Ist halt Edius. :?: ?(

    Gruß
    Ulrich
  • Neu

    uvo_47 schrieb:

    Wodurch wurde nun das aus einem Clip erzeugte Standbild in Sequenz 3 "beschädigt" und das in Sequenz 14 dagegen nicht?
    Nein, das hast Du offenbar doch noch nicht so richtig verstanden.

    In diesem Fall ist offenbar nicht das Standbild (die Datei) selbst "beschädigt", oder - was die häufigere Variante wäre - offline. Denn dann würde ja keiner der Clips (der Verknüpfungen) mehr funktionieren und man müsste den Online-Status wieder herstellen, oder das Standbild erneut importieren.

    Hier ist es aber so, dass nur der eine auf der TL befindliche Clip (auch eine Verknüpfung) aus irgendwelchen Gründen offenbar nicht richtig ausgelesen werden kann. Da aber die Clips in der Bin und den anderen Spuren/Sequenzen funktionieren ist es möglich den "beschädigten" Clip auf der Spur 3 durch eine Kopie dieser "unbeschädigten" Clips zu ersetzten.

    uvo_47 schrieb:

    Der Grund ist höchstwahrscheinlich darin zu suchen, dass ich mich erinnere, während der Bearbeitung des Projekts unter Systemeinstellungen/Import/Export/Standbild die Projekteinstellungen unter Halbbild erfassen von "Oberes Halbbild" auf "Bild" geändert zu haben!
    Diese Einstellung betrifft den Import, bzw. die Erzeugung von Standbildern, wirkt sich also auf die Datei selbst aus.
    Da die Clips nur auf die/eine Datei verweisen, dürfte hier eigentlich nicht die Ursache zu suchen sein, denn sonst wären ja alle Clip-Instanzen betroffen gewesen.

    Nur mal zum Spaß und für ein besseres Verständnis:
    Du importierst, bzw, erstellst in Edius ein Standbild "Haus" = Clip liegt in der Bin;
    • dann sendest Du den Clip an eine TL = er wird jetzt dort verwendet und "Haus" im Rekorder angezeigt;
    • jetzt in Windows die Datei des Standbildes (= in den Clipeigenschaften angegebene Datei) umbenennen oder löschen = die Clips in Edius sind jetzt "offline" - ein Export würde fehlschlagen;
    • den Offline-Clip anklicken, sodass sich das Fenster für die Wiederherstellung der Verknüpfung öffnet und;
    • dort mit einem anderen Bild z.B. "Wiese" verknüpfen = in der Bin und auf der TL liegt jetzt "Wiese", wobei sich natürlich der Name der Clips nicht geändert hat, nur der angezeigte Inhalt.
    Wie gesagt halte ich es für fast unmöglich den Grund für die "Beschädigung" jetzt nachträglich festzustellen.

    Gruß Peter
    ASUS P9X79 - i7-4820K CPU 3,70 GHz - 32 GB RAM - PNY Quadro K2000D - 256 GB Samsung SSD + 2 x 2 TB als RAID 1 - RME Fireface 400 - Win 10 Pro - EDIUS WG 9 - BMD FUSION 9

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von gurlt ()