Hi zusammen, ich habe einen sehr seltsamen Fehler zu dem ich nach intensiver Recherche noch keine Antworten gefunden habe.
Hier mal der Fehler zur Ansicht. Es sind seltsame Halbbildfehler/ Dropouts, die NICHT durch Komprimieren oder Umwandeln entstanden sind. Wie es dazu gekommen ist, führe ich jetzt aus.
Im Google Drive Player ist die Ansicht so zermatscht, dass man das Flackern kaum wahrnimmt. Wenn ihr den Clip downloaded seht ihr das volle Ausmaß.
Ich habe für eine Dokumentarfilm-Projekt ein Jahr lang regelmäßig gedreht. Das Material habe ich auf insgesamt 3 Festplatten gesichert.
Es handelt sich um Canon 70D Material. MOV Dateien.
Vor Kurzem begann ich den Schnitt des Films. Dabei stellte ich fest, dass ein einziger Drehtag auf allen drei Festplatten beschädigt ist. ABER die Clips sind nicht kaputt im Sinne von corrupt etc. Jedes Programm spielt die Clips ohne Fehlermeldung, aber sie sind durchzogen von seltsamen Halbbildfehlern/ Flackern/ Dropouts.
Nicht nur das 70D Material, sondern auch das Drohnen Material hat diesen Fehler.
Die Fehler sind definitiv nach dem Kopieren aufgetreten, weil das Material dieses Drehtags vor einem Jahr (unmittelbar nach dem Dreh) bei Rocket Beans gesendet wurde und fehlerfrei war.
Ich hatte denen Das Material von meiner Rechnerfestplatte hochgeladen. Erst danach sicherte ich das Material auf externe Festplatten und löschte danach die Quelldatei (Ordner auf Rechnerfestplatte).
Mein gesichertes Material ist unsendbar, da die Fehler wirklich sehr häufig auftreten. Damals bei Rocket Beans wurden aber lange Szenen gezeigt, die Fehlerfrei waren.
Damals habe ich nach dem Kopieren blöderweise nicht die Clips geöffnet und kontrolliert, sondern nur in der Ordnerübersicht geschaut, ob alles da ist. Die SD Karten sind seit vielen vielen Monaten neu überspielt worden und selbst die tollsten "Dinge aus dem Papierkorb wieder sichtbar machen" Programme fördern die Originale nicht mehr zu tage. Auch sämtliche File-Repair Freeware und sogar kostenpflichte (in der Testversion) habe ich über die Clips gejagt. Immer die gleiche Meldung: "Keine Fehler gefunden"
Nun hoffe ich, dass Jemand von euch eine Idee hat, wie dieser Fehler heißt und ob es eine Lösung gibt. Den Glauben habe ich verloren, weil ich mir technisch nicht erklären kann, wie man so heftige Artefakte/Overlays/ Störungen da raus kriegen soll.
Aber auch wenn keiner ne Idee hat, ist so ein Fehler vielleicht mal interessant. Keiner meiner Medien-Kontakte hat sowas bisher gehabt.
Wie gesagt: Ich bin 100% sicher, dass die Files durch das Kopieren kaputt gegangen sind. Es ist Material von zwei 70D Karten und einer Drohnen Karte. Drei unterschiedliche Karten und zwei unterschiedliche Geräte und trotzdem alles vom gleichen Fehler durchzogen. Und wie bereits erwähnt wurde das Material damals fehlerfrei veröffentlicht. Die original Files löschte ich aber leider nach dem Dreifachen Sichern.
Das Original ist weg, das ist ja leider das Dilemma.
Das File, das ich unter dem Google Drive Link gepostet habe ist aber Rohmaterial. Nicht komprimiert. Allerdings eben jenes gesichertes/kopiertes Material.
Das Flickern ist, wenn ich das richtig gesehen habe, nur diagonal über ein Frame.
Deckt sich das mit Deiner Beobachtung ?
Und auch nur rd. 20%. Da müsst eigentlich ein De-Flicker. programm wirken.
Man müsste, um die Ursache zu finden, die beiden Versionen vergleiche. Aber wenn das Original nicht mehr da ist, ist das schwer und eine reine Wundertüte.
Danke für die Antwort. Das Flickern ist im Google Drive Player schwach zu sehen. In der original Datei ists vom Player abhängig. Der VLC Player kriegt es ganz gut eingedämmt, sodass es nur nach Helligkeits-Veränderungen aussieht.
Im Schnittprogramm ist das Flickern teils über das komplette Bild in violett.
Habe schon überlegt, das Material im VLC Player laufen zu lassen und mit einer Bildschirm-Rekorder Software aufzunehmen.
Aber bringt mich auch nicht wirklich weiter, weil das Flackern im VLC auch nicht vollständig weg geht.
Wie gesagt, ohne das Originalmaterial ist es schwer festzustellen, was in der Neucodierung eigentlich geschehen ist.
Kommt es denn regelmässig vor und kann man eine bestimmte Framezahlausmachen, in der es sich wiederholt, oder nur sporadisch ?
Also ich habe da ein sauberes Bild. Oder ich bin blind.
Abgespielt mit VLC Player v2.2.4 auf Windows 8.1 >> ok
Abgespielt mit dem neusten Quick Time Player >> ok
Eventuell liegt es auch einfach am MOV Decoder deines Systems. Der VLC bringt seine eigenen Decoder mit, muss sie aber nicht zwingend nutzen. Vielleicht liegt es auch an deiner Grafikkarte, sofern sie beim decoden dem Rechner unter die Arme greift. Probier doch mal einen anderen Computer aus, alternativ auch mal ein Smartphone.
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Auf MacOS 10.12.5 habe ich im QT Player 10.4 keinerlei Bildfehler, im VLC 2.2.4 habe ich Farb-und Helligkeitsschwankungen. Ich stimme tommyb zu, dass das mit QT zusammenhängt. Wenn ich deinen Clip zu ProRes umcodiere, spielt auch mein VLC ihn ohne Fehler ab, hier (nur als ProResLT codiert wegen der Uploadgröße, natürlich "Herunterladen"). Wenn die Fehler bei dir noch immer sichtbar sind, musst du unbedingt eine Quicktime-Alternative finden. Zugegeben problematisch, wenn man Movs als Originalclips hat.
Na und? Im Fernsehen wird ja auch alles wiederholt ...
Bei mir mit VLC Flackern bei TC 0:03, mit Windows Media Player und der Windows Film & TV App einwandfreie Darstellung des Clips.
Hab' hier einen Windows 10 Enterprise Rechner mit'ner Uralt GeForce GT 640
Funless has spoken!
......................................................... "The enemy of art is the absence of limitations."
(Orson Welles)
.........................................................
No Cenobites were harmed during filming.
Er hat doch jetzt bereits 2 mal geschrieben, dass es sich bei dem Clip aus dem Link um original Footage aus der Cam handelt.... was für Infos brauchst du denn noch, WoWu?
Hier sind mal Screenshots aus Premiere Pro. So stellt sich der Fehler bei mir auch auf sämtlichen Player dar.
Der VLC verpackt es manchmal ok. Aber das schwankt auch zwischen Helligkeitsfehlern und diesem seltsamen Fehler wie auf den Screenshots.
Habe QT aktualisiert und sogar den guten alten GOM Player getestet. Überall der gleiche Fehler.
Langsam denke ich mir, dass Windows das nicht verpackt. Ihr apple User schreibt ja, dass kein Fehler auftritt.
Aber was zur Hölle soll dann beim Kopieren damals passiert sein?!
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
wenn man dein bsp.-file mit einem komandiozeilen-player (mpv od. ffplay) abspielt, werden ohnehin an den entsprechenden stellen ganz eindeutige fehler ausgegeben:
es liegen also definitiv ganz grobe fehler im file vor! :(
wie sich ein derartiger "korrupter makroblock" in den verschieden codec-implementierungen manifestiert, ist wohl eher von untergeordneter bedeutung...
woher diese mängel genau stammen, lässt sich natürlich nicht so einfach sagen... -- das kann genauso gut von defekten speicherkarten, fehlerhaften festplatten oder übertragunsgsfehlern stammen (darum macht man ja gewöhnlich checksummen von files, um wenigstens einen teil dieser fehler auszuklammern bzw. zu kontrolieren)
im besten fall könnte man wohl automatisch listen der betroffenen frames generieren, und diese ggf. durch kopien der davor oder danach liegenden bilder ersetzten. aber auch das muss nicht unbedingt funktionieren, wenn die fehler umfangreicher sind od. besonders sensible bereiche der videofiles betreffen.
"Er hat doch jetzt bereits 2 mal geschrieben, dass es sich bei dem Clip aus dem Link um original Footage aus der Cam handelt.... was für Infos brauchst du denn noch, WoWu?"
Ich weiß ja nicht wie Du das verstanden hast ... ich habe das anders verstanden...
Die korrekte Fehleranalyser bekommst Du nur mit der Referenz auf das Original. Allle andere sind Spekulationen.
ili hat geschrieben: ↑Mo 15 Mai, 2017 00:15
Das Original ist weg, das ist ja leider das Dilemma.
Das File, das ich unter dem Google Drive Link gepostet habe ist aber Rohmaterial. Nicht komprimiert. Allerdings eben jenes gesichertes/kopiertes Material.
WoWu hat geschrieben: ↑Mi 17 Mai, 2017 01:30
Die korrekte Fehleranalyser bekommst Du nur mit der Referenz auf das Original. Allle andere sind Spekulationen.
nein!
dass dieses konkrete file korrupt ist, kann man auch so eindeutig feststellen.
da braucht man nicht über vermeintliche spekulationen zu spekulieren...
würde man ein bisserl mehr zeit daruf verwenden, könnte man vermutlich sogar herausfinden, ob teile des datestroms fehlern oder passagen durch fehlerhafte werte ersetzt wurden...
ändert allerdings am grundsätzlichen problem auch nicht viel, weshalb das alles wohl eher nicht der mühe wert ist.
Bei 2:23 sieht man einen kaputten Makroblock oben unter dem Dreier-Fenster. Ansonsten spielt der QT-Player (Mac) alles normal. Den für einen Frame sichtbaren Minifehler könnte man gut abdecken.
Verloren ist das Material also nicht. Interessant ist aber wirklich, wie das zustande kommt. Das Wichtige an solchen Fehlern ist ja immer, die Ursache zu finden, sonst bliebt bei jedem weiteren Dreh ein mulmiges Gefühl.
Am Rande: was war denn da für eine Optik auf der 70D? Sieht ja grauenhaft aus.
Ich wette, es handelt sich bei der "Datensicherung" um aus der Karte isolierte Clips. Da es sich um isolierte Clips im Quicktime-Container handelt, kann QT 10 sie vernünftig lesen. QT 7 ist über zehn Jahre alt und wurde die vergangenen 7 Jahre über nur noch wegen Sicherheitslücken durch Apple aktualisiert. Beweisen kann ich das nicht, es deckt sich aber mit Erfahrungen, die (zu meinem Glück) andere immer wieder machen. Dieselben, die mich auslachen, weil ich immer auf der intakten Ordnerstruktur bestehe.
Na und? Im Fernsehen wird ja auch alles wiederholt ...
Axel hat geschrieben: ↑Mi 17 Mai, 2017 09:39
Ich wette, es handelt sich bei der "Datensicherung" um aus der Karte isolierte Clips. Da es sich um isolierte Clips im Quicktime-Container handelt, kann QT 10 sie vernünftig lesen. QT 7 ist über zehn Jahre alt und wurde die vergangenen 7 Jahre über nur noch wegen Sicherheitslücken durch Apple aktualisiert. Beweisen kann ich das nicht, es deckt sich aber mit Erfahrungen, die (zu meinem Glück) andere immer wieder machen. Dieselben, die mich auslachen, weil ich immer auf der intakten Ordnerstruktur bestehe.
Dir wird sofort geglaubt, wenn du mal das Stück in *sauber* hochlädst ;)
dienstag_01 hat geschrieben: ↑Mi 17 Mai, 2017 09:52Dir wird sofort geglaubt, wenn du mal das Stück in *sauber* hochlädst ;)
Wie meinst du das? Als was anderes? Hab ich ja schon, ProResLT. Klappt genau so mit MSC als H.264 (mit Qualität 100%) oder mit x264 als .mp4. Beweisen muss und will ich gar nichts. Dass es einen Zusammenhang mit QT gibt, ist aber wohl unbestreitbar. Ging es hier um Prüfsummen und errechnete Fehler in Makroblöcken oder um sichtbare "Halbbildfehler/Dropouts"?
Na und? Im Fernsehen wird ja auch alles wiederholt ...
dienstag_01 hat geschrieben: ↑Mi 17 Mai, 2017 09:52Dir wird sofort geglaubt, wenn du mal das Stück in *sauber* hochlädst ;)
Wie meinst du das? Als was anderes? Hab ich ja schon, ProResLT. Klappt genau so mit MSC als H.264 (mit Qualität 100%) oder mit x264 als .mp4. Beweisen muss und will ich gar nichts. Dass es einen Zusammenhang mit QT gibt, ist aber wohl unbestreitbar. Ging es hier um Prüfsummen und errechnete Fehler in Makroblöcken oder um sichtbare "Halbbildfehler/Dropouts"?
Ah, sorry, hatte ich übersehen.
Aber fehlerfrei ist das Material auch nicht, da sind nur Teile des Bildes durch ein anderes ersetzt.
Immerhin geschieht das *automatisiert*, da muss man nicht mühevoll alle kaputten Bilder suchen ;)
Was ich ja wirklich wahnsinnig finde, nachdem ich Axels ProRes File in Premiere importiert habe, werden mir 3 von 4 Fehlern im Originalfile nicht mehr angezeigt. Nicht sofort, sondern nach einer Weile ;)
dienstag_01 hat geschrieben: ↑Mi 17 Mai, 2017 11:13Aber fehlerfrei ist das Material auch nicht, da sind nur Teile des Bildes durch ein anderes ersetzt.
Das mag so sein. Der Punkt ist, wir können nicht mehr entscheiden, ob diese Fehler
a) ... nicht in der Original-Datei auf der Karte waren (angeblich ja nicht) und in der Folge durch einen Fehler beim Kopieren auf das Sicherungsvolume geschahen.
b) ... schon im Original waren, jedoch irgendwann mal (wie heute auf MacOS) durch QT-Interpretation weitgehend begradigt wurden. Dass dies heute nicht mehr auf allen Systemen gelingt, mag daran liegen, dass es unterschiedlich gute Umsetzungen für QT auf Windows gibt.
Habe QT aktualisiert* und sogar den guten alten GOM Player getestet. Überall der gleiche Fehler.
*Wie?
WoWu erwähnte mal, dass beim Wrappen eines proprietären Codecs (das Beispiel war XAVC) Metadaten zur Bildverbesserung verloren gehen könnten. XAVC hat ja diesen leicht erweiterten Farbraum gegenüber AVCHD. Kam mir plausibel vor. H.264 im QT-Container ist in gewisser Hinsicht auch proprietär. Auch, wenn Wald- und Wiesenprogramme wie VLC ihn lesen können, heißt das nicht, dass alles zur Anwendung kommt, was eventuell Canon schon in den Codec eingebaut hat, um akzeptable Qualität zu liefern. Das erscheint mir als die plausibelste Erklärung. Beweisen kann ich nichts, klar, aber ich hätte ziemlich hoch gewettet, dass eine Prüfsumme aus der jetzt existierenden Kopie mit der des Originals identisch gewesen wäre.
Na und? Im Fernsehen wird ja auch alles wiederholt ...
Axel hat geschrieben:Das mag so sein. Der Punkt ist, wir können nicht mehr entscheiden, ob diese Fehler
a) ... nicht in der Original-Datei auf der Karte waren (angeblich ja nicht) und in der Folge durch einen Fehler beim Kopieren auf das Sicherungsvolume geschahen.
b) ... schon im Original waren, jedoch irgendwann mal (wie heute auf MacOS) durch QT-Interpretation weitgehend begradigt wurden. Dass dies heute nicht mehr auf allen Systemen gelingt, mag daran liegen, dass es unterschiedlich gute Umsetzungen für QT auf Windows gibt.
Stimmt, wir können nicht sagen, woher der Fehler kommt.
Aber wir können mit Sicherheit sagen, dass das Material Bildfehler hat.
Und was du hier *begradigt* nennst, wird dir bei einer Bewegung im Bild ordentlich um die *Augen* fliegen. Da nimmt man dann vielleicht eher das gesamte (Nachbar-) Bild, statt nur einen Teil davon ;)
dienstag_01 hat geschrieben: ↑Mi 17 Mai, 2017 12:02Da nimmt man dann vielleicht eher das gesamte (Nachbar-) Bild, statt nur einen Teil davon ;)
Man?
Schätze nicht, dass ein popeliger Videoplayer wie Quicktime X (der kann noch nicht einmal besonders viele Formate, weswegen er auch selten verwendet wird) vorhandene Bildfehler on-the-fly aufbereitet, womöglich mit Interpolationen aus anderen Frames (EDIT: ... es sei denn:) Diese Fehler sind wahrscheinlich, äh, immanent. Und deshalb ist es fragwürdig, ob man sie überhaupt Fehler nennen sollte.
Na und? Im Fernsehen wird ja auch alles wiederholt ...
dienstag_01 hat geschrieben: ↑Mi 17 Mai, 2017 12:02Da nimmt man dann vielleicht eher das gesamte (Nachbar-) Bild, statt nur einen Teil davon ;)
Man?
Schätze nicht, dass ein popeliger Videoplayer wie Quicktime X (der kann noch nicht einmal besonders viele Formate, weswegen er auch selten verwendet wird) vorhandene Bildfehler on-the-fly aufbereitet, womöglich mit Interpolationen aus anderen Frames. Pfff. Diese Fehler sind wahrscheinlich, äh, immanent. Und deshalb ist es fragwürdig, ob man sie überhaupt Fehler nennen sollte.
Was willst du denn jetzt eigentlich erzählen, dass das keine Fehler sind?!
Jetzt wird es ernstlich blöd ;)
Und was denkst du eigentlich, wie Videokomprimierung funktioniert?! Die Wiederverwendung von Bildteilen ist geradezu die Essenz von GOP-basierter Kompression!!! Da wird nichts interpoliert.
dienstag_01 hat geschrieben: ↑Mi 17 Mai, 2017 12:26
Was willst du denn jetzt eigentlich erzählen, dass das keine Fehler sind?!
Jetzt wird es ernstlich blöd ;)
Nein. Nur, dass es anscheinend für Canon-mov (bzw. für 70D-mov) charakteristische Fehler sind. Nichts, das dadurch entsteht, dass der Rechner beim Kopieren auf die Backup-Platte merkt, upps, da hab ich mich verschluckt, vielleicht merkt's ja keiner. Und dann kommt der super-smarte Videoplayer QT X daher, prüft eingangs den Clip und sagt sich, eieiei, Fehlerchen, da gucken wir mal, ob wir das Bild, mindestens optisch, *automatisiert* verbessert, präsentiert kriegen ...
dienstag_01 hat geschrieben: ↑Mi 17 Mai, 2017 12:26Und was denkst du eigentlich, wie Videokomprimierung funktioniert?! Die Wiederverwendung von Bildteilen ist geradezu die Essenz von GOP-basierter Kompression!!! Da wird nichts interpoliert.
Das versuchte ich - unbehende, da kein Ingenieur - zu umschreiben. Wenn ein dezidierter Decoder den Fehler nicht darstellt (obwohl er zu dämlich ist, ihn aufzuspüren und hastig Bildteile zu interpolieren), ist es dann ein Fehler? Streng genommen?
Na und? Im Fernsehen wird ja auch alles wiederholt ...
Axel, du kannst natürlich über die Herkunft des Fehlers spekulieren, wie du willst, steht dir frei ;)
Aber:
Wenn ein dezidierter Decoder den Fehler nicht darstellt (obwohl er zu dämlich ist, ihn aufzuspüren und hastig Bildteile zu interpolieren), ist es dann ein Fehler? Streng genommen?
Er stellt natürlich ein fehlerhaftes Bild dar. Du guckst nur nicht richtig. Sieht man ja in deinem File.
Jott hat geschrieben: ↑Mi 17 Mai, 2017 08:19
Bei 2:23 sieht man einen kaputten Makroblock oben unter dem Dreier-Fenster. Ansonsten spielt der QT-Player (Mac) alles normal. Den für einen Frame sichtbaren Minifehler könnte man gut abdecken.
Verloren ist das Material also nicht. Interessant ist aber wirklich, wie das zustande kommt. Das Wichtige an solchen Fehlern ist ja immer, die Ursache zu finden, sonst bliebt bei jedem weiteren Dreh ein mulmiges Gefühl.
Am Rande: was war denn da für eine Optik auf der 70D? Sieht ja grauenhaft aus.
Sigma 17-50 f2,8. Aber nur avalible light und cinestyle. Die 70D nutze ich aber heute auch nicht mehr. Kackt bei wenig Licht echt ab.
Das ist doch alles Spekulation, solange wir das Originalfile nicht haben und verifizieren können, dass der Fehler darin nicht enthalten ist.
Erst wenn wir das können, kann man beginnen, den Fehler einzugrenzen und Ursachen zu suchen.
"Fischen im Trüben" bringt nichts.
Habe QT aktualisiert* und sogar den guten alten GOM Player getestet. Überall der gleiche Fehler.
*Wie?
Aktuallisiert ist nicht richtig. Ich hatte vorher "Quicktime Alternative" drauf und habe dann QT installiert. Wußte nicht, dass QT7 schon so lange besteht und dachte anno 2017 wär das ne aktuelle/ aktualisierte Version.
Bzgl. Ordnerstruktur: Da hast du recht. Ich habe nicht den DCIM Ordner kopiert, sondern nur den, wo die Clips drin waren. Die Ordnerstruktur ist also gestört. Vielleicht lag es daran.
Die anderen Clips sind leider recht groß, sonst würd ich hier noch was hochladen. Da sieht man die Fehler häufiger und deutlicher ausgeprägt. Jedenfalls in premiere pro. In den ganzen Playern verhält es sich überall anders.
WoWu hat geschrieben: ↑Mi 17 Mai, 2017 16:39
Das ist doch alles Spekulation, solange wir das Originalfile nicht haben und verifizieren können, dass der Fehler darin nicht enthalten ist.
Erst wenn wir das können, kann man beginnen, den Fehler einzugrenzen und Ursachen zu suchen.
"Fischen im Trüben" bringt nichts.
Das Originalmaterial ist ja futsch, aber hier ist die besagte Rocket Beans Episode. Und ich bin überzeugt, dass das Material in Ordnung war. Von Rocket Beans kam keine Rückmeldung über fehlerhaftes Material und vor dem Versenden hatte ich einige Szenen gesichtet. Ich habe mittlerweile alle clips kontrolliert. Der Fehler ist in jedem einzelnen Clip. Auf allen drei Karten. Mir wäre es also aufgefallen. Aber da war damals nichts.
Ab 14:04 sieht man das besagte Material von mir.
Interessant für diese ganze Diskussion: Sowohl im 70D Material ALS AUCH in dem Drohnenmaterial ist der Fehler. Das kann natürlich Zufall sein, spricht für mich aber dafür, dass der Fehler beim Sichern entstanden ist. Oder vielleicht ist auch ne elektromagnetische Granate bei meinem Nachbarn explodiert und die Strahlen haben genau in dem Zeitpunkt als ich sicherte die externen Festplatten erwischt.
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Zuletzt geändert von ili am Mi 17 Mai, 2017 17:19, insgesamt 2-mal geändert.
Nur wäre es ja eben gerade interessant zu erfahren, was an solchen Stellen im Originalmaterial anders ist und ob ggf. aus den nicht kopierten Zusatzdaten, Informationen über die Filehanhabung verloren gegangen sind.
Aber, wie gesagt ... ohne das Basismaterial ist das Spekulation.
Edit
Das gepostete Bild sieht in der Tat danach aus, als ob im Filemanagement die Pointer nicht richtig sitzen.
Rechtliche Notiz: Wir übernehmen keine Verantwortung für den Inhalt der Beiträge
und behalten uns das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.
