Graue Block-Artefakte bei iPhone-Material

Salut,

ich bearbeite mit Edius 9 vorrangig private Familienfilme. Weil die beste Kamera immer die ist, die man dabei hat, ist das Basismaterial dafür in den letzten Jahren zunehmend Handy-Material.

Beim Schnitt von iPhone-Clips mit den üblichen Einstellungen und deren Folgen (variable Bitrate, "ungefähr" 29,97 fps, im Bin immer auf diese 29,97 und Vielfache festgezurrt, Projekt-Einstellung 29,97 fps; Auflösung "nur" 1080p, ggw. stammt das Material aus iPhone 8 und XR) kommt es gelegentlich vor, dass Edius einzelne Frames mit grauen Block-Artefakten anzeigt -- siehe oben. Vorherige und nachfolgende Frames sind völlig in Ordnung. Alle Clips der Timeline werden vor dem End-Export auf Halbbildoption "optischer Fluss" gestellt. Es ist nur ein kleiner Teil der Clips betroffen, vermutlich im kleinen einstelligen Prozentbereich der Clips.

Höhere Auflösung des Bildes hier.

Die Fehler sind in Edius nicht nur während Betrachtung aus dem Bin oder während der Bearbeitung in der Timeline sichtbar, sondern auch im exportierten Endergebnis. In anderen Playern (Windows-Bordmittel, VLC) sind die Artefakte _nicht_ vorhanden.

Diese Artefakte verschwinden normalerweise, wenn ich den In-Punkt um ein paar Frames nach vorne oder hinten verschiebe. So ganz zuverlässig ist das aber nicht, und die nötige "Entfernung" vom ursprünglichen In-Punkt ist unterschiedlich. Proxies helfen nicht.

Kennt Ihr solche Artefakte? Gibt's da irgendetwas, was man dagegen tun könnte? Ein Konvertieren in ein Zwischenformat außerhalb von Edius ist für mich allerdings keine Lösung. Freue mich auch über "Nein, muss an Deinem Setup liegen"- oder "Kenn ich, keine Lösung"-Feedback. "Nimm halt eine richtige Kamera" hilft eher nicht.

Bei Bedarf kann ich gerne einen Clip zur Verfügung stellen, der das Problem bei mir aufzeigt.

Danke! Liebe Grüße

Salut Peter,

Zitat von gurlt

Um die hohen Komprimierungsraten heutiger Codecs erreichen zu können, werden u.a. sog. "Blöcke" gebildet, die Bereiche erfassen, die sich nur hinsichtlich ihrer Lage im Bild verändern. Für mich sieht der Screenshot so aus, als ob hier von Edius bei der Decodierung diese Blockauflösung nicht richtig verarbeitet würde.

Dies könnte auch erklären, warum der Effekt abhängig vom In-Punkt auftritt (Stichwort GOP-Struktur). Leider tut sich da Edius mit bestimmten Material etwas schwer, was aber eher zu "Rucklern" auf der TL führt.

Soweit klar. Die GoP-Struktur habe ich auch als potentiellen Verursacher im Verdacht. Dass dabei allerdings im exportierten Resultat solche Artefakte entstehen, passt eigentlich nicht zu meiner Erwartungshaltung.

Beim Betrachten aus dem Bin sind die Effekte besonders gut reproduzierbar, wenn man rückwärts durch den betroffenen Clip scrobbled; das "hakt" im (ca.) Sekundenabstand und passt damit zur GoP-Theorie.

Zitat von gurlt

Leider ist nun nichts über Dein System, das Quellmaterial (Codec, etc.) und Deine Projekteinstellungen bekannt. Insoweit kann man da nur raten.

Welche Information fehlt Dir?

System softwareseitig: Alle Komponenten auf aktuellem Stand -- Windows 10 Home, ggw. 20H2; Edius 9.55; NVidia-Studio-Treiber 462.59
Hardwareseitig: Core i5-4570, NVidia GeForce GTX 1650, 24 GB RAM, System und Edius auf SSD, Projekt-Dateien auf drehendem Rost, (iPhone-)Clips kommen vom NAS.

Quellmaterial:
iPhone 8 und iPhone XR, 1080p, eingestellte Framerates meist 30fps (resultierend in variabler Framerate "ungefähr 29,97fps"), gelegentlich 60 (-> 59,94), selten Zeitlupe mit 240/239,78 fps, dort das Symptom noch nicht beobachtet). IPhones machen daraus HEVC-encodiertes Video im MOV-Container.
Projekteinstellungen: 1080p bei 29,97 fps.

Zitat von gurlt

Auch konnte ich jetzt nicht ganz nachvollziehen, ob der Effekt nur bei "optischer Fluss" auftritt, oder unabhängig davon.

Die Fehler sind auch bei Ansicht aus dem Bin heraus sichtbar und damit unabhängig von Clip-Einstellungen für Halbbildoptionen. Nach Einfügen in die Timeline gibt es das Symptom sowohl mit "Optischer Fluss" als auch mit "Nächster Nachbar".

Zitat von gurlt

Auf alle Fälle solltest Du Dein System mal hinsichtlich Treiber (nicht nur GraKa-Treiber) überprüfen, ob es hier Aktualisierungen gibt.

Alles[tm], was auf meinem System eigene Updates einspielen kann, ist aktualisiert. Leider fällt es mir schwer, rauszufinden, woher der H.265-Codec stammt, auf den Edius zugreift, und deshalb auch, was der für eine Version hat, aber ich vermute, dass die diversen *hevc*.dll-Dateien im Edius-Ordner dafür zuständig sind -- die wären damit dann also aktuell (jedenfalls in der Edius 9.x-Linie).

Zitat von gurlt

In Edius prüfen, ob alle Einstellungen stimmen und ob die Verwendung des Hardware-Decoders auch aktiviert ist. Je nachdem was Du für ein System hast und um welchen Codec es sich handelt ggf. mal den Hardware-Decoder deaktivieren, oder (wenn vorhanden) auf eine andere Grafik "umschalten".

Einstellungen, die ich für relevant halte:
* Projekteinstellungen -> Na ja, sie "stimmen" im Sinne von: passen so gut wie möglich zum Input-Material
* Systemeinstellungen -> Import/Export -> HEVC: Die Checkbox "Verwende Hardware-Decoder" ist aktiviert, aber ausgegraut; ich _kann_ sie nicht einmal ausschalten. Eine andere GraKa steht mir leider nicht (so einfach) zur Verfügung.

Zitat von gurlt

Die Projekteinstellungen sollten zum Quellmaterial passen, dort also möglichst Abweichungen hinsichtlich Framerate vermeiden.

Ja, das sollten sie, und ich musste auf die harte Tour lernen, dass Smartphones halt standardmäßig nicht mit den aus der für mich aus Camcorder- und DSLR-Welt gewohnten 25fps arbeiten, oder dass sich die variablen Framerates nicht sonderlich gut in einen NLE mit einer länglichen Historie einpassen.

Aber "sollten" sollte nicht "müssen" heißen, erst recht nicht in einer Software mit dem Claim "Edit anything, fast".

Abgesehen davon passt das hier aber eigentlich alles zusammen.

Zitat von gurlt

Nicht als Dauerlösung, aber zumindest mal als Test trotzdem mal prüfen, ob diese Artefakte auch dann auftreten, wenn der entsprechende Clip (IN-Out) gerendert, oder als GV HQ/HQX umgewandelt/exportiert wird.

Tatsächlich verschwinden die Artefakte, wenn ich den Clip im Bin mit "Umwandeln" in GV HQ, HQX oder lossless wandle. Für die Dateigröße ist das, naja, suboptimal. Aber im größten Notfall lässt es sich für die betroffenen Einzelfälle vielleicht so organisieren.

Herzlichen Dank für Deine Ideen! Liebe Grüße
Basti

Zitat von Pee

Du meinst wohl variable Framerate(Bildwiederholrate), also VFR und nicht CFR?

Zefix noch eins, natürlich meinte ich das.

Zitat von Pee

Bei VFR fehlen Dir halt irgendwo Frames zu Deiner eingestellten Projekt-Framerate, das führt dann halt zu Artefakten.

Das führt nicht zwangsläufig zu Artefakten, sondern zur Notwendigkeit, Zwischenbilder zu berechnen. Das beherrscht Edius. "Graue Klötzchen" müssen davon jedenfalls nicht verursacht werden.

Danke und Gruß
Basti

Zitat von udo

Seltsam, diese Probleme traten bei meinen Aufnahmen - iPhone 5, 6s Max, 8 Max, 11 Pro Max - noch nicht auf.
Weder mit der Kamera APP noch Filmic Pro.

Danke für das Feedback. Einerseits nicht ganz unerwartet: ein generelles Problem wäre ja vermutlich auch irgendwo schon mal bekannt geworden. Andererseits: Ich tue hier eigentlich nichts ungewöhnliches; merkwürdig, dass sich das bei mir anders verhält.

Gruß
Basti

Zitat von gurlt

Es gibt zwei H.265 Decoder, die abhängig von den Gegebenheiten zum Zuge kommen.
Der eine läuft über QuickSync, also die Intel Grafik / iGPU. Dieser dürfte auch nach Deiner Beschreibung auf Deinem System zur Anwendung kommen.
Hier kannst Du mal versuchen, ob eine Deaktivierung der Hardwareunterstützung ein anderes Ergebnis liefert, denn der zweite Decoder läuft über die CPU. Aber dadurch gehen die Rechenzeiten natürlich extrem hoch. Und der H.265 Export ist aus Edius 9 ohne QS auch nicht möglich.

Super, danke für die Erklärung!

Gerne würde ich den Hardwaredecoder dann mal ausschalten -- alleine: wie geht das? Wie gesagt lässt sich die entsprechende Checkbox in den Systemeinstellungen nicht deaktivieren.

Zitat von gurlt

Das hatte ich schon beinahe vermutet.Denn einerseits tut sich Edius leider grade mit H.265 als Quellmaterial insgesamt etwas schwer, andererseits werden in diesem Codec auch die Transform-Blocks sehr intensiv genutzt.
Und Dein System mit einer i5-4570 CPU ist nun auch nicht grade wirklich für die Bearbeitung von H.265/HEVC geeignet, auch wenn diese zumindest über QS verfügt. Mit H.265 tun sich oft auch weit leistungsfähigere Systeme schwer.

Mir ist durchaus bewusst, dass mein Rechner schon ein bisschen in die Jahre gekommen ist (und bereits bei Anschaffung der CPU vor vermutlich 7 Jahren kein High-Speed-Bolide war), aber so lange ich bei FHD-Bearbeitung bleibe, bin ich bisher mit den Ergebnissen noch eigentlich ganz zufrieden. Der i9 steckt im (mobilen) Arbeitswerkzeug, da sehe ich momentan nicht, privat vierstelliges Geld zu investieren, um ein bisschen Renderzeit zu sparen.

Zitat von gurlt

Wenn Du scrubbst - und dann auch noch rückwärts -, sind da zumindest Anzeigefehler natürlich vorprogrammiert. Aber hier sollte sich das nur auf die Vorschau auswirken.

Dass es aufgrund mangelnder Performance bei Vorschau, Scrubbing oder Abspielen zu Rucklern, Verzögerungen und meinetwegen auch Darstellungsfehlern kommt, könnte ich nachvollziehen; dass die aber beim Exportieren der Sequenz -- das darf ja ruhig lange dauern -- übrig bleiben, ist für mich nicht schlüssig.

Zitat von gurlt

Deshalb würde ich Dir raten, dass das Dein Edius Händler (bzw. mmm) mal einschätzen, oder besser noch per Fernwartung ansehen sollte.

Vielleicht kontaktiere ich den noch mal; würde aber raten, dass dessen erster Hinweis wäre, doch lieber auf Edius X zu wechseln. Das wollte ich lieber auslassen.

Falls Du (oder ein anderer Leser) Interesse hat, mal draufzuschauen: Ich habe einen betroffenen Clip mal hier abgelegt. Wenn ich diesen Clip in ein Standardprojekt mit 1080p und 29.97 (oder 59.94) fps einlese, auf etwas über 7 Sekunden springe und dann mit den Pfeiltasten (ganz langsam und vorsichtig, damit die CPU auch nicht ins Schwitzen kommt ) rückwärts bis zu 0:6:58 (bzw. 0:6:29, falls in Timeline) wandere, sind die Artefakte 100% reproduzierbar. Nötig beim Einsprung ist ein gewisser Abstand zu 0:7:00 (neue GoP?). Das gleiche Muster wiederholt sich wie gesagt präzise auf jeder Sekunde.

Thx, Gruß
Basti