Fieldorder auslesen

  • Weil ich gerade ein monstermäßiges Problem mit der Halbbildreihenfolge von Canopus DV-Clips habe. Ich weiß aber nicht, wo die Ursache des Problems stecken könnte. Deswegen hätte ich gerne innerhalb einer mir zur Verfügung stehenden Canopus-Software die Halbbildfolge überprüft.


    Wenn ich Canopus-DV Clips (entweder welche, die über Let's Edit zu Canopus DV gerendert wurden oder welche, die über RexEdit/RexRTPro/BreakoutBox YUV gecaptured wurden) in Vegas oder in VdL importiere, dann wird mir dort die falsche Halbbildreihenfolge angezeigt, nämlich Upper Field First, obwohl es Lower Field First sein müsste. Und damit kommt es bei verschiedenen Bearbeitungen zu Problemen.


    Wenn ich nun - wie gerade eben - lese, dass andere Let's Edit User Probleme bei Zeitlupenerstellung haben, dann könnte das u.U. ebenfalls darauf hinweisen, dass bei den Canopus-DV-Files etwas mit der Halbbildreihenfolge nicht in Ordnung ist.


    Es kann aber zumindest für meinen Fall ebenso gut sein, dass manche Programme, wie eben Vegas und VdL, die Canopus DV Files in irgendeiner Weise falsch interpretieren. Nur - Warum? Es kommt mit keinen anderen DV-Files zu Problemen mit der Halbbildfolge.


    Marco

    • Offizieller Beitrag

    Hallo,


    die Halbbildreihenfolge ist bei DV-Files immer bff.
    Einzige Interpretationsausnahme : es gibt Programme, die die Zeilen bei 0 oder 1 anfangen zu zählen . So wird aus "gerade" nämlich "ungerade" obwohl es immer noch bff ist.

  • Zitat

    die Halbbildreihenfolge ist bei DV-Files immer bff.


    Das ist mir klar, darum bin ich ja auch so verwundert.


    Zitat

    Einzige Interpretationsausnahme : es gibt Programme, die die Zeilen bei 0 oder 1 anfangen zu zählen . So wird aus "gerade" nämlich "ungerade" obwohl es immer noch bff ist.


    Hmm, darüber muss ich mal grübeln. Daraus kann doch eigentlich noch nicht resultieren, dass es tatsächlich zu typischen Fehlern einer Halbbildvertauschung kommt. V.a. müssten dann ja alle DV-Files, egal woher sie stammen, falsch angezeigt werden. Bei mir taucht dieses Problem aber bisher allein mit Canopus DV-Files auf.
    Das war nun aber einfach nur mal laut gedacht. Ich bleibe am Ball ...


    Aber schonmal vielen Dank für die Antwort. Das gibt der Problemrecherche eine andere, bessere Basis.


    Marco

  • Hallo Marco,


    Du sagst, dass das Problem nur bei Canopus-DV-Dateien auftritt.
    Wenn Du nun eine solche Datei mit dem Canopus-DV-File Converter in den MS-Codec wandelst, ist dann das Problem weg? Wenn Ja – dann ist was oberfaul!


    Grund:
    Der Converter ändert nur die Organisationsstruktur der AVI-Datei und den FOURCC. Der Inhalt der Frames bleibt unverändert. Bei dem Vorgang ist daher auch kein Codec beteiligt. Um aber tatsächlich die Fieldorder zu ändern musst Du verlustbehaftet de- und encoden, da die Frames immer das Gesamtbild beinhalten und nicht einzelne Halbbilder.


    Gruß Herbert

  • Hallo Herbert,


    Zitat

    Wenn Du nun eine solche Datei mit dem Canopus-DV-File Converter in den MS-Codec wandelst, ist dann das Problem weg?


    Nein, leider nicht. Das war eines der ersten Dinge, die ich versucht hatte.


    Ich kann aber in Vegas für die Clips einzeln die Halbbildfolge verändern. Das heißt natürlich nicht, dass dabei die Halbbildreihenfolge tatsächlich umgedreht wird (ginge auch, aber eben nur - wie Du schon sagtest - über Rendern), sondern nur, dass das Auslesen der Zeilen dann gedreht wird. Das bringt auch tatsächlich den gewünschten Erfolg. Und über Scripting kann ich diesen Vorgang nun sogar automatisieren, so dass ich nur einmal das Script über ein Projekt laufen lassen muss und schon werden die Halbbilder richtig herum verarbeitet. Das ändert aber nichts daran, dass hier an irgendeiner Stelle was nicht in Ordnung ist. Nur, was genau es ist, das weiß ich bisher noch nicht.


    Marco

  • Hallo Marco,


    wenn Du von DV über OHCI mit dem MS-Codec capturest müsste das Problem genau das selbe sein wie wenn Du mit Canopus-Hardware und dem Canopus-Codec capturest denn auch hier ist kein Codec involviert.
    Damit will ich sagen es kann eigentlich kein Canopus Problem sein.


    Gruß Herbert

    • Offizieller Beitrag
    Zitat

    Original von Herbert
    Hallo Marco,


    wenn Du von DV über OHCI mit dem MS-Codec capturest müsste das Problem genau das selbe sein wie wenn Du mit Canopus-Hardware und dem Canopus-Codec capturest denn auch hier ist kein Codec involviert.
    Damit will ich sagen es kann eigentlich kein Canopus Problem sein.


    Gruß Herbert


    Da hat Herbert Recht!
    Wenn die Dateien nur gecapturt sind dann ist/war kein Codec involviert!

  • Erst wenn gerendert wird, spielt der Codec eine Rolle!
    Das hatten wir doch schon mal...


    Warum aber Herr Kexel,


    a) kann Premiere Pro dann MSDV-Clips aus Canopus DV-Capture richtig im Projektfenster und auf der Zeitlesite anzeigen
    b) kann Premiere Pro Clips im "Canopus format" aus Canopus DV-Capture ab eine bestimmten Anzahl nur als Schwarzbilder im Projektfenster anzeigen, auch die Clips dazu auf der Zeitleiste?


    Der Codec spielt beim Capturen doch keine Rolle? :gruebel:


    Was ist eigentlich der Unterschied zwischen den MSDV-Clips und den Clips im "Canopus format" ?
    Nur der Header?


    Sind es dann eben diese Header-Informationen, die Marco jetzt ebenfalls Schwierigkeiten bereiten?


    Warum hat Premiere Pro Probleme mit den Canopus Clips?


    Vielleicht können Sie bitte mal darauf kurz eingehen. :schal:

    • Offizieller Beitrag
    Zitat

    Was ist eigentlich der Unterschied zwischen den MSDV-Clips und den Clips im "Canopus format" ?
    Nur der Header?


    Ja, nur der Header!


    Zitat

    a) kann Premiere Pro dann MSDV-Clips aus Canopus DV-Capture richtig im Projektfenster und auf der Zeitlesite anzeigen


    Weil bei Clips mit MSDV Header der MS Codec zu extrahieren des kleinen Thumnail-Bildchen genutzt wird.

    Zitat

    b) kann Premiere Pro Clips im "Canopus format" aus Canopus DV-Capture ab eine bestimmten Anzahl nur als Schwarzbilder im Projektfenster anzeigen, auch die Clips dazu auf der Zeitleiste?


    Weil bei Clips mit Canopus Header der Canopus Codec zu extrahieren des kleinen Thumnail-Bildchen genutzt wird.


    Zitat

    Sind es dann eben diese Header-Informationen, die Marco jetzt ebenfalls Schwierigkeiten bereiten?


    Ich weiß es nicht, ich kenne Vegas nicht!

  • Vielen herzlichen Dank Herr Kexel!


    Die Miniaturen also und die Visualisierung der Clips werden bereits beim Import in das Projektfenster und die Zeitleiste mit dem Canopus-Codec erstellt...
    Dachte, dass der Canopus Codec erst beim Rendering der Clips in eine AVI ins Spiel kommt.


    Tja, dann ist zumindest im Falle Premiere Pro der Fehler nicht bei Adobe suchen, sondern tatsächlich im Plug-in!

  • Hallo,


    Zitat

    Ja, nur der Header!


    Nicht nur! Auch das Audio-Interleaving und damit natürlich auch die Indexpointer auf die Audio-Blöcke
    Hab ich aber weiter oben mit dem Begriff Organisationsstruktur bereits geschrieben.


    Zitat


    Zitat BPHennek
    kann Premiere Pro Clips im "Canopus format" aus Canopus DV-Capture ab eine bestimmten Anzahl nur als Schwarzbilder im Projektfenster anzeigen, auch die Clips dazu auf der Zeitleiste?


    Ist es wirklich von der Anzahl abhängig.


    Ich habe diese Phänomen auch bei geringer Anzahl festgestellt und zwar bei Canopus Referenz Dateien. Daher glaube ich dass bei der Implementierung der Preview-Funktion die Besonderheit der Canopus-Referenz-Datei nicht berücksichtigt wurde.


    Wenn jetzt gleich einer schreit um also eine Referenz-Datei zu erstellen brauch ich also doch zum capturen einen Codec. Ja aber nicht für seine Elementaraufgabe de- und encoden sondern nur für Organisation und die ändert wieder nichts an den Videoframes. Denn nur so kann ein verlustfreies Kopieren von Videodaten gewährleistet werden.
    Anderst gesagt von der Qualität her ist kein Unterschied ob ich von DV-Kamera zu DV-Kamera kopiere oder über einen PC gehe. (Vorausgesetzt die jeweiligen Geräte arbeiten absolut fehlerfrei.)



    Gruß Herbert

  • Zitat

    wenn Du von DV über OHCI mit dem MS-Codec capturest müsste das Problem genau das selbe sein wie wenn Du mit Canopus-Hardware und dem Canopus-Codec capturest denn auch hier ist kein Codec involviert.


    Es ist gewiss richtig, darauf hinzuweisen. Aber auch diese Sachverhalte sind mir klar.


    In meinem Fall verhält es sich aber anders. Ich rede nicht von DV-Files, die lediglich über Firewire gecaptured wurden. Es geht v.a. um DV-Files, die dadurch entstanden sind, dass sie mit RexEdit auf einer RexRTPro über die Komponentenschnittstelle der Breakoutbox digitalisiert wurden. Also eine Wandlung von analogem BetaSP auf digitales DV mittels Canopus Hard- und Software. Also nach der Digitalisierung liegen hier definitiv DV-Files mit Canopus Codec vor.
    Im anderen Fall, den ich nur zur Überprüfung herangezogen hab, geht es um DV-Files, die aus Let's Edit heraus gerendert wurden und zwar nach Anwendung eines Filters. Also auch hier als Ergebnis ganz klar DV-Files mit Canopus Codec.


    Dennoch möchte ich gar nicht behaupten, dass der Fehler hier beim Canopus-Codec liegt oder auch am Canopus-Header. Ich weiß einfach nicht, wo genau der Fehler zu suchen ist und - was noch viel wichtiger wäre - wie er schon im Vorfeld abstellbar wäre. Aber bisher kann man meiner Meinung nach hierbei genauso wenig ausschließen, dass der Fehler auf der Canopus-Seite zu suchen wäre.


    Zitat

    Sind es dann eben diese Header-Informationen, die Marco jetzt ebenfalls Schwierigkeiten bereiten?


    Auch das weiß ich leider nicht mit Gewissheit. Ich vermute aber, dass dem nicht so ist. Denn eine Transformation des Headers mittels dem Canopus DV Konverter bringt hier auch keinerlei Abhilfe.


    Marco

  • Hallo Marco,


    das war mir klar dass man eigentlich nur beim analogen capturen die Freiheit hat an dieser Reihenfolge etwas zu verdrehen. Wenn es nachher AVIs sind kannst du nur mit einen Editor oder dergl. etwas daran verbessern/verschlimmern.


    Was mir aber für die Eingrenzung des Fehlers entscheidend war, ist eben die Aussage dass das Problem bei Canopus DV-AVIs dies auftritt. Also ist für mich entscheidend wenn Du mal wirklich von DV kurz was capturest ob dann das Problem auftritt.


    Ist der Header schuld?
    Es gibt im Header keinen direkten Parameter für die Fieldorder. Weder im Streamheader noch im Stream Header Format (Bitmapinfoheader) finde ich etwas passendes. Es sei denn der Codec schreibt diese Info in den Frameheader, also innerhalb des einzelnen Frames.
    Und da wühlt man dann in den Bereichen über die uns nur spärliche oder keine Informationen vorliegen.


    Gruß Herbert

  • Zitat

    Also ist für mich entscheidend wenn Du mal wirklich von DV kurz was capturest ob dann das Problem auftritt.


    Du meinst, Capturing über FireWire mit einer Canopus-Software? Kann ich momentan nicht machen, aber ich kann es gerne nachholen. Dann aber erst gegen Ende der Woche.


    Marco

  • Hallo Marco,


    ja, genau.


    Gruß Herbert


    Für alle die mitlesen noch eine Information zum Audiointerleaving:
    Der MS-Codec und auch andere verwenden interleave 1:1, dh. nach jedem Videoframe kommt ein Audio-Frame.
    Canopus hat 1:25 dh. nach 25 Videoframes kommt ein Audio Frame. Daher kann es bei Verwendung eines FOURCC-Changers Probleme geben. Deshalb lieber den Canopus-DV-File-konverter verwenden. Trotz des Fehlers den ich heute in einem anderen Posting beschrieben habe.

  • Zitat

    Herbert postete:
    Deshalb lieber den Canopus-DV-File-konverter verwenden.


    D.h. Clips im "Canopus format" in MSDV-Clips konvertieren nicht wahr oder gleich MSDV-Clips mit Canopus DV-Capture aufnehmen.
    Letzteres mache ich derzeit, weil ja sonst das Schwarzbildproblem auftritt.


    Welche Vorteile hätten denn Clips im "Canopus format"?