Frage von ili: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.
Hier der Link zu einem original Clip:
https://drive.google.com/open?id=0B8A8Q ... 25ZMU4zajg
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.
MfG,
ili
Antwort von WoWu:
Mach doch vom Kamera(original)material (nicht von der Kopie) mal eine Mediainfo.
Antwort von ili:
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.
Antwort von WoWu:
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.
Antwort von ili:
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.
Antwort von WoWu:
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 ?
Antwort von tommyb:
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.
Antwort von Axel:
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.
Antwort von Daffytroll:
Windows 7 (Nvidia Quaddro K2200)
VLC: Es flackert minimal zwischendurch
After Effects / Premiere CC2015: Das Bild ist an den Stellen regelrecht "zerschnitten" (wie kaputtes Interlaced oder so), es springt
Quicktime: Keine Bildfehler aber es ruckelt...?!?
Windows Media Player: ALLES TOP!!!
Antwort von Funless:
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
Antwort von mash_gh4:
QCTools scheint mir ein ganz brauchbares werkzeug zu sein, um derartige bildfehler in archiviertem material aufzuspüren bzw. objektiv zu analysieren.
http://www.bavc.org/qctools
https://github.com/bavc/qctools
Antwort von ili:
Abgefahren, habt vielen Dank!!! Ich teste das mal auf verschiedenen Playern.
Ich hab hier drei Rechner.
Win 10 und 2 x Win 8.1. Auf allen Flackert es.
Aber diese Prores VErsion von Axel flackert nicht. Ich teste jetzt mal Windows Media Player :D :D :D
Aber habt ihr ne Idee, wie sowas zu stande kommt?!
Antwort von WoWu:
Mit ein paar mehr Informationen wäre das sicher feststellbar, aber ohne Originalfile ist das "Fischen im Trüben".
Antwort von Daffytroll:
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?
Antwort von ili:
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?!
Antwort von mash_gh4:
wenn man dein bsp.-file mit einem komandiozeilen-player (mpv od. ffplay) abspielt, werden ohnehin an den entsprechenden stellen ganz eindeutige fehler ausgegeben:
AV: 00:00:02 / 00:00:08 (27%) A-V: 0.000
h264: corrupted macroblock 68 7 (total_coeff=-1)
h264: error while decoding MB 68 7
AV: 00:00:02 / 00:00:08 (30%) A-V: -0.000
h264: corrupted macroblock 2 36 (total_coeff=-1)
h264: error while decoding MB 2 36
AV: 00:00:03 / 00:00:08 (35%) A-V: 0.000
h264: corrupted macroblock 81 49 (total_coeff=-1)
h264: error while decoding MB 81 49
AV: 00:00:05 / 00:00:08 (60%) A-V: 0.000
h264: Invalid level prefix
h264: error while decoding MB 24 51
AV: 00:00:08 / 00:00:08 (99%) A-V: 0.000
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.
Antwort von WoWu:
@daffitroll
"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:
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.
Antwort von mash_gh4:
WoWu hat geschrieben:
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.
Antwort von Jott:
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.
Antwort von Axel:
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.
Antwort von dienstag_01:
Axel hat geschrieben:
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 ;)
Antwort von Axel:
dienstag_01 hat geschrieben:
Dir 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"?
Antwort von dienstag_01:
Axel hat geschrieben:
dienstag_01 hat geschrieben:
Dir 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 ;)
Antwort von dienstag_01:
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 ;)
Antwort von Axel:
dienstag_01 hat geschrieben:
Aber 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.
Antwort von dienstag_01:
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 ;)
Antwort von Axel:
dienstag_01 hat geschrieben:
Da 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.
Antwort von dienstag_01:
Axel hat geschrieben:
dienstag_01 hat geschrieben:
Da 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.
Antwort von Axel:
dienstag_01 hat geschrieben:
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:
Und 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?
Antwort von dienstag_01:
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.
Antwort von ili:
Jott hat geschrieben:
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.
Antwort von WoWu:
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.
Antwort von ili:
Axel hat geschrieben:
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.
Antwort von ili:
WoWu hat geschrieben:
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.
https://youtu.be/t0a_wE0yhsQ?t=785
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.
Antwort von WoWu:
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.
Antwort von dienstag_01:
Es gibt kein Zusatzmaterial bei Canon.
Antwort von Skeptiker:
Hier noch mein kurzer Beitrag zur Fehlerfindung:
in Premiere CC (Mac) abgespielt.mp4.zip
Das "Original"-MOV in Premiere CC (Mac) abgespielt und mit einem Screenrecorder aufgenommen.
Nachträglich verkleinert und zusätzlich komprimiert (ich konnte das MPEG-4 trotzdem nicht direkt als Attacjhment anhängen - "falsches Format" - deshalb als ZIP.
Dabei zeigt sich ein Effekt (horizontales Aufteilen und vertikales Springen des Bildes), der demjenigen unter Screen Tearing auf Wikipedia gleicht.
Die aus dem Original in einen 'All-i'-Einzelbildcodec (ProRes oder DNxHD) konvertierten Files lassen sich hingegen auf meinem Mac ohne sichtbare Störungen abspielen (siehe auch Axels ProRes) - egal ob VLC, QuickTime alt oder neu oder z.B. Movist (wohl wie VLC FFmpeg-basiert).
Antwort von Skeptiker:
Skeptiker hat geschrieben:
Hier noch mein kurzer Beitrag zur Fehlerfindung:
in Premiere CC (Mac) abgespielt.mp4.zip
Das "Original"-MOV in Premiere CC (Mac) abgespielt und mit einem Screenrecorder aufgenommen.
Nachträglich verkleinert und zusätzlich komprimiert (ich konnte das MPEG-4 trotzdem nicht direkt als Attachment anhängen - "falsches Format" - deshalb als ZIP.
Dabei zeigt sich ein Effekt (horizontales Aufteilen und vertikales Springen des Bildes), der demjenigen unter Screen Tearing auf Wikipedia gleicht.
Die aus dem Original in einen 'All-i'-Einzelbildcodec (ProRes oder DNxHD) konvertierten Files lassen sich hingegen auf meinem Mac ohne sichtbare Störungen abspielen (siehe auch Axels ProRes) - egal ob VLC, QuickTime alt oder neu oder z.B. Movist (wohl wie VLC FFmpeg-basiert).
Antwort von Skeptiker:
Skeptiker hat geschrieben:
Skeptiker hat geschrieben:
Hier noch mein kurzer Beitrag zur Fehlerfindung:
in Premiere CC (Mac) abgespielt.mp4.zip
Das "Original"-MOV in Premiere CC (Mac) abgespielt und mit einem Screenrecorder aufgenommen.
Nachträglich verkleinert und zusätzlich komprimiert (ich konnte das MPEG-4 trotzdem nicht direkt als Attachment anhängen - "falsches Format" - deshalb als ZIP).
Dabei zeigt sich ein Effekt (horizontales Aufteilen und vertikales Springen des Bildes), der demjenigen unter Screen Tearing auf Wikipedia gleicht.
Die aus dem Original in einen 'All-i'-Einzelbildcodec (ProRes oder DNxHD) konvertierten Files lassen sich hingegen auf meinem Mac ohne sichtbare Störungen abspielen (siehe auch Axels ProRes) - egal ob VLC, QuickTime alt oder neu oder z.B. Movist (wohl wie VLC FFmpeg-basiert).
Antwort von Skeptiker:
Doppel
Antwort von Skeptiker:
Doppel
Antwort von dienstag_01:
Ohne sichtbare Störungen - mal richtig gucken!
Antwort von Skeptiker:
Doppel
Antwort von Skeptiker:
Soory - ich hab's hier nicht mehr im Griff mit den Beiträgen - viel Glück bei der Fehlersuche!
Antwort von mash_gh4:
dienstag_01 hat geschrieben:
Die Wiederverwendung von Bildteilen ist geradezu die Essenz von GOP-basierter Kompression!!!
wobei es doch recht wichtig ist, dass es sich beim hier gepostetem beispiel nicht um long-GOP-material handelt, sondern um All-Intra AVC files aus der kamera. wäre das nicht der fall, würden die fehler deutlich störender ausfallen!
Antwort von mash_gh4:
ili hat geschrieben:
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.
leider sind sind solche probleme ganz und gar nicht ungewöhnlich!
das betrifft einerseits fehler in der ürbertragung, was sich allerdings relativ einfach mit checksummen überprüfen und ggf. mit ütbertragungstechniken wie rsync (mit option --inplace) auch ausgesprochen effizient nachträglich korrigieren lässt, wenn man vernünftigen zugriff auf die entsprechenden server hat...
aber es gibt leider auch immer wieder ziemliche probleme mit billigen storage-lösungen. das betrifft nicht nur derartiges ablegen irgendwo draußen in der cloud, sondern durchaus auch storage server im eigenen netz, wo noch immer sehr oft ältere filesysteme verwendet werden, die noch nicht über jenes maß an internen kontrollmechanismen verfügen, wie sie bspw. in ZFS, btrfs u.ä. mittlerweile zur verfügung stehen. erst damit ist man tatsächlich in der lage, schleichenden datenverlusten auf SSDs u.ä. vernünftig zu begegnen.
Antwort von dienstag_01:
mash_gh4 hat geschrieben:
dienstag_01 hat geschrieben:
Die Wiederverwendung von Bildteilen ist geradezu die Essenz von GOP-basierter Kompression!!!
wobei es doch recht wichtig ist, dass es sich beim hier gepostetem beispiel nicht um long-GOP-material handelt, sondern um All-Intra AVC files aus der kamera. wäre das nicht der fall, würden die fehler deutlich störender ausfallen!
Stimmt, war mir noch gar nicht aufgefallen ;)
Was aber nichts daran ändert, dass das Zusammensetzen, Ändern der Reihenfolge etc. von Bildern zu den ganz normalen Aufgaben von Playern gehört.
