Fieldorder auslesen

    Hallo Marco,


    ups - nein nicht wirklich, - jetzt hatte ich geglaubt es sind nur noch 12x480 Bytes und wir sind mit den nächsten 8 Versuchen fertig. :wein:


    Aber wenn es nicht der Header ist, dann ist es im Datenbereich. Ob es dann Sinn macht da weiterzusuchen mag ich bezweifeln. Da ändert ein Codec beim Capturen auf keinen Fall etwas weil er sonst die Qualität verschlechtern würde. Also ich glaube das Vegas den Bug bereinigen muss.


    Ein Fauler Trick würde mir noch einfallen um kurzfristig das Problem zu umgehen. Man überschreibt an jeder AVI den ersten Frame mit einem schwarzen Frame mit der richtigen Orderkennung und ändert den FOURCC in dvsd.


    Ob das möglich wäre, könnte ich testen indem ich in Capture8_MSDV (und auch Capture8 ) den Frame von Canopus_test_MSDV einbaue.



    Herbert

    Zitat

    Also ich glaube das Vegas den Bug bereinigen muss.


    Wenn der Fehler denn tatsächlich auf Vegas-Seite zu suchen ist ...
    Andere Programme, wie z.B. Video DeLuxe reagieren ja genauso.


    Nur - mal angenommen, der Fehler liegt ausschließlich auf der Seite der lesenden Programme (ausschließen will ich das ja auch nicht): Was genau könnte denn dort diesen Fehler verursachen? Es sind ja wirklich nur Canopus-Files, die diesen Lesefehler hervorrufen und einzig eine ganz bestimmte Art von Canopus-Files, die hartnäckig jede andere Auslesung vereiteln. Vegas 5 ist ja in der Entwicklung. Von daher wäre es gut, wenn ich für einen Bug-Report nicht nur motzen müsste, sondern auch konstruktiv sein könnte (und wenn ich Beweise dafür hätte, dass Sony Pictures in der Bringschuld ist).


    Zitat

    Ein Fauler Trick würde mir noch einfallen um kurzfristig das Problem zu umgehen. Man überschreibt an jeder AVI den ersten Frame mit einem schwarzen Frame mit der richtigen Orderkennung und ändert den FOURCC in dvsd.


    Ich weiß nicht, ob das nicht schon viel zu aufwendig wäre. Ändern kann ich das ja auch, indem ich alles neu rendere und dabei für die Dekompressionsphase die Halbbildfolge manuell umstelle. Trotzdem wäre es interessant zu wissen, ob das tatsächlich funktioniert. Bzw. wenn sowas dann im Batchverfahren machbar wäre, wäre es auch nicht schlecht.


    Wenn sich hierbei aber auch verdichtet, dass der Codec damit zu tun hat, also die Videoinformation, die im AVI steckt, dann frage ich mich, ob es nicht seitens Canopus irgendeine Möglichkeit gäbe, den Hardwarecodec der RexRTPro auf einen neueren Stand zu bringen. Vielleicht gibt es ja irgendeine neue Systemkomponente von der wir (bzw. die Produktionsfirma) noch nichts wissen.

    Hallo Marco,


    dass der Fehler bei Vegas zu suchen ist steht ausser Zweifel. Denn wenn der Fileconverter in dem MSVC nach Canopus nur den FOURCC ändert und daraufhin Vegas plötzlich eine andere Fieldorder sieht dann ist das ein Fehler von Vegas.


    Herbert

    Ja, Bruno. Diesen AVI Tag Editor kenne ich, benutze ihn auch. Danke trotzdem.


    Herbert, wie denkst Du, formuliere ich dann am besten einen Bug-Report, damit die Entwickler von Vegas genauer wissen, wo sie zu bohren und zu schrauben haben.

    Hallo Marco,


    wenn du den Bug-Report per email machst, würde ich unsere 2 Dateien caopus_test-MSDV.avi und caopus_test-MSDV-CDV.avi anhängen und auf den Umstand hinweisen, das diese beiden Files sich bis auf den FORCC gleich sind und trotzdem von Vegas eine unterschiedliche Fieldorder reported wird.
    Sie sollten also den Algorhythmus für die Fieldordererkennung überprüfen.


    PS: Die Testdatei mit Capture8 mache ich noch. Musste aber um 20:00 noch kurz weg.


    Herbert

    Herbert, mach Dir mit dieser Sache bloß keinen Stress! Es wundert mich ohnehin schon, wie sehr Du dich um die Sache bemühst. Eine erste Produktion mit diesen Problemfiles hatte ich gestern fertiggestellt. Die nächste wird mindestens noch eine Woche dauern.
    Wenn Sony Pictures diesen Fehler dann für die nächste Vegas-Version abstellen könnte, wäre das schon klasse. Ich werde die in den nächsten Tagen unterrichten.


    Bin trotz allem tierisch gespannt, ob Du zu der Datei "capture8.avi" noch was rausfindest. Das Verhalten mit dieser Datei verwundert mich ja noch mehr als das der anderen Datei. "capture8" ist ja bisher mit gar keinen Mitteln dazu zu bewegen, von Vegas als LFF erkannt zu werden.


    Ich weiß nicht, wie oft und intensiv ich in der folgenden Woche am Ball bleiben kann. Von daher möchte ich mich jetzt schonmal ganz herzlich für Dein Engagement bei der Fehlersuche und Fehlerbeseitigung bedanken! Was wären Filmproduktionen heute ohne das Internet ...

    Hallo Marco,


    mein Mailer ist eben am verschicken von Capture8N. 11 MB dauern trotz DSL ganz ordentlich. Na ja die Upload Geschwindigkeit ist auch nicht die Welt. Gut das es uns gelungen ist für den Test mit den Mini-Files zu arbeiten.
    Noch was zum meinen Vorschlag den ersten Frame schwarz zu machen: In der Exploreransicht hat sich eben der Nachteil des falschen ersten Frames unangenehm bemerkbar gemacht. Da der Explorer gerade das erste Frame für die Darstellung in seiner Übrsicht verwendet sollte gerade dies den echten Inhalt wiederspiegeln.
    aber jetzt für den Test ist es ja egal.


    Bin gespannt was rauskommt.


    Gruß Herbert

    Hab gestern schon im Bett gelegen, als das Posting hier kam. Bin jetzt auf der Arbeit und kann leider erst später heute Abend meine Mails abrufen. Melde mich dann aber sofort (wird wohl ca. 20 Uhr werden).

    Zitat

    bleibts eigentlich bei der letzten These, daß wir hier vermutlich von einem Erkennungsproblem in Vegas und VdL sprechen?


    Da gibt's ja zwei verschiedene Canopus-Dateien. Für die eine (die wurde in Let's Edit erzeugt) gilt das scheinbar auf jeden Fall. Die andere Datei (von RexRTPro - also meine eigentlichen Problemdateien) muss noch geprüft werden, ob hier nicht das codierte Video eine besondere Rolle spielt.


    Ich hab übrigens eben aus einem US-Forum ein Feedback von jemandem bekommen, der sagt, bei ihm würde das Problem nicht auftauchen. Canopus-Files würden in Vegas bei ihm grundsätzlich mit LFF angezeigt. Ich warte noch auf eine nächste Antwort, denn ich weiß zur Zeit noch nicht, ob derjenige von NTSC- oder PAL-Material spricht und welchen Canopus-Codec er benutzt hat. Wenn das ein PAL-Bug von Vegas sein sollte, beiß ich mich in's Knie ...


    Nachtrag:
    Eben kam die Antwort aus dem US-Forum. Das Projekt, in dem das mit den Canopus-Files funktionierte, war ein NTSC-Projekt. Dort natürlich auch mit NTSC-DV. Ich werde dennoch gleich mal testen, wie es sich verhält, wenn ich bei mir das Projekt auf NTSC umstelle.


    2. Nachtrag:
    Hab das mit einem NTSC-Projekt getestet. Bringt aber nichts. Entweder liegt nun der Unterschied darin, dass dessen Canopus DV-Files NTSC sind oder es liegt doch am Canopus-Codec, der auf dem System installiert ist.

    Also was die Anzeige der Canopus-Files in Vegas als UFF angeht - zumindest was die Let's Edit Files angeht, scheint das ziemlich sicher ein PAL-Bug von Vegas zu sein. Ich habe eben mal ein NTSC-File in Vegas erzeugt, dass wiederum in ein NTSC Let's Edit-Projekt geladen und dort dann zu einem NTSC Canopus-AVI gerendert.


    Wenn ich nun das NTSC Canopus-AVI in Vegas importiere, egal ob das ein NTSC- oder ein PAL Vegas-Projekt ist, dann wird die Halbbildfolge des Canopus-Files auf Anhieb korrekt erkannt - ganz ohne DV-Konverter dazwischen geschaltet zu haben.
    Das würde ich nun zu gerne auch mit dem Canopus RexRT File überprüfen, geht aber leider diese Woche nicht mehr.

    Hallo Marco,


    hatte bis 20:00 Uhr ein größeres Problem mit meinen Internet PC der mich heute Abend mit einem Bluescreen begrüßt hat. Nach zig Versuchen habe ich zum Backup gegriffen und das auf eine Testplatte gespielt. Gut dass ich eine Testplatte genommen habe, denn da gab’s noch mehr Ärger, das letzte Backup (auf DVD) war nicht lesbar, das zweitletzte auch nicht. Dann habe ich Backup-Images von der Festplatte geholt – die ließen sich installieren, aber die Kiste kam trotzdem nicht hoch.
    Daraufhin suchte ich den Fehler im BIOS. BIOS-Parameter geändert Kiste ging. Originalplatte wieder eingebaut ging auch wieder – also keine Verluste. :klatsch: Gut dass ich nicht die Hinweise auf dem Bildschirm befolgt habe und mit dem MS-Repair die Platte endgültig ruiniert habe.


    So nun zum letzten Stand:
    War eigentlich zu erwarten, dass das funktionieren muss. Hab mir nochmals Gedanken gemacht und noch ein paar Bytes gefunden, die man überschreiben könnte ohne den Startframe ganz zu ruinieren. Werd nachher ne mail fertig machen.


    Prinzipiell muss man natürlich davon ausgehen, dass die Programmierer nicht direkt auf die Videodaten zugreifen (so wie ich das bei meinen Experimenten treibe) sondern über den Codec bzw. über APIs. Denn nur so ist gewährleistet, dass er mit verschiedenen Codecs umgehen kann.
    Wenn nun die APIs verschiedene Softwarestände haben kann es passieren dass der Programmierer bei gewissen Parametern ins Leere greift oder Zufallswerte kriegt. Wenn das der Fall ist kommen wir nie auf einen grünen Zweig. (obwohl ich im Moment den Eidruck habe, dass wir die Sache in Griff kriegen können)


    Das mit dem PAL/NTSC kann ich mir schon vorstellen. Gerade die Entwickler testen, wenn sie in USA sitzen, hauptsächlich mit NTSC und werden PAL dann eher stiefkindlich behandeln.


    Gruß Herbert

    Oh je, das mit Deinem I-Net PC klingt nach stressigen Stunden. Glücklich derjenige, der überhaupt Backups hat ...


    Bezüglich unserer Testreihe muss ich leider für heute schon wieder Schluss machen, in dieser Woche sind die Tage für mich extrem kurz. In den Mailaccount kann ich vermutlich erst wieder morgen Abend reinsehen. In's Internet wohl hin und wieder mal über den Tag verteilt.

    • Offizieller Beitrag
    Zitat

    mit welchem tools schaust du dir eigentlich die DV-Datein an - und womit machst du die von dir genannten Manipulationen?


    Du kennst Herbert noch nicht?


    Alles per TextDatei. Er lebt in Avi's.

    • Offizieller Beitrag
    Zitat

    Textdatei? Meinst du das Umbenennen zu einer Textdatei und direkt im Texteditor ansehen?


    Das kann Dir Herbert sicher selbst besser erklären.
    Er hat auch ein Programm geschrieben.

    Mit freundlichen Grüßen


    Stephan Kexel
    Grass Valley



    Hinweis: Dies ist kein Support Forum der Firma Grass Valley. Unsere Mitarbeiter schauen zwar immer wieder hier hinein, wir können aber keine Support hier garantieren. Benötigen Sie Support, dann kontaktieren Sie den Grass Valley Support Center unter Tel. 02602-1069-100, Fax. 02602-1069-169 oder
    per e-mail canopus.support-de@Thomson.net .

    Hallo Wolfgang,


    Zitat

    mit welchem tools schaust du dir eigentlich die DV-Datein an - und womit machst du die von dir genannten Manipulationen?


    mit meinem eigenen Programm.
    Das Problem bei Videodaten ist, dass es für einen normalen HEX-Dump zu große Datenmengen sind und man keine Chance hat dies zu überschauen. Mit meinem Programm mache ich eine Art kommentierten Dump der aber auch ganz gezielt Teile ausgeben kann.
    Beispiel: von Videoframe 215 bis 233 jeweils die Bytes 85 bis 133


    Ich versuche mal eine entsprechende Textdatei anzuhängen.


    Im Ggs zum normalen Dump werden z.B. Null-Bytes erkannt und nur über einen Hinweis ausgegeben.
    Siehe im Beispiel: 0000816A 1674 Null-Bytes
    Hier wurden 1674 Null-Bytes unterdrückt weil man sonst vor lauter Bäumen den Wald nicht mehr sieht.


    Ein anderes Problem ist das vergleichen von Videoframes. Wenn man zB mit verschiedenen Codecs den selben Clip captured kann man die AVIs nicht mit MS Filecompare vergleichen weil durch verschiedene Junk-Bereiche, anderem Audio-Interleaving die Abstände zwischen den Videostreams variieren. Deshalb habe ich eine Funktion mit der ich reine Videoframes speichern und laden kann.
    Diese reinen Videoframes kann man dann untereinander vergleichen.


    Die für diesen Thread wohl wichtigste Funktion war die Funktion laden. Die ist wesentlich flexibler wie speichern. Damit bin ich in der Lage gezielt Bytes eines Frames (oder auch mehrerer Frames) mit den Bytes aus einer anderen AVI-Datei zu ersetzen.


    So das sollte mal als kurzer Abriss genügen. Will jetzt kein Handbuch schreiben.


    Gruß Herbert