Zeitdifferenz zwischen komp. und unkomp. Videospur bei gleicher (!!!) Framerate.

  • Hallo,

    ich komm hier grade nicht mehr weiter, und bitte um Hilfe.

    Beachten: Das Problem taucht NUR bei dieser Quelle auf.

    Gegeben: Film FullHD, Tonspur dts
    Das Bild wird durch Staxrip geschickt, avisynth und x264
    Aufruf identisch wie hier, zusätzlich --crf 22

    dts wird zu aac gewandelt.

    Problem: 

    Wenn ich die neue Bildspur und Ton zusammenmuxe, baut sich eine Zeitdifferenz auf. Selbst, wenn ich die gleiche Framerate, wie im ursprungsvideo angebe (24000/1001). Das komprimierte Bild läuft bei 3h ziemlich genau eine sekunde zu schnell (etwa 1/10000). Da die gleiche tonspur mit dem Ursprungsvideo synchron läuft (bei gleicher framerate), gehe ich davon aus, das der Ton okay ist.

    Ein einfacher Muxfehler kann es daher eigentlich auch nicht sein. Wenn ich mit den gleichen einstellungen die originale, gedemuxte .h264 mit beliebiger tonspur (komprimiert oder unkomprimiert) in die .mkv packe, passts wieder.

    Beide Bildspuren (bei gleicher framerate) in EINER .mkv laufen ebenso auseinander. Also muss das Problem an der neuen Bildspur liegen. Beide Bildspuren jeweils für sich alleine in eine .mkv gemuxt geben exakt die identische Laufzeit an, obwohl die kumulierte Zeitverzögerung am Ende mehr als eine Sekunde beträgt. (über 30 Frames Tonverzögerung am Ende).

    Da passt ganz viel nicht zusammen, und ich weis grade nicht, was ich noch tun kann, um das problem einzugrenzen.

    Leider kann ich mit mkvmerge GUI die Framerate nicht so exakt einstellen, um den Laufzeitunterschied auszugleichen. Ich komm der Sache zwar schon recht nah, aber ich kann es nicht mehr feiner auflösen. mmg nimmt die kleine Änderung zwar an, die erzeugte datei hat aber nicht die eingestellte framerate, sondern eine minimal abweichende, die auch minimale unsynchronitäten aufweist.

    Alles in Allem bin ich grade ziemlich ratlos, aber gewillt der Sache auf den Grund zu gehen. Wenn ich irgendetwas mal testen soll, sagt bescheid!

    Grüße, D

    Einmal editiert, zuletzt von Dispatcher7007 (12. April 2010 um 13:40)

  • Kein Problem, ich kannte das Programm nicht.

    Ist es das, was du brauchst?

    /edit:
    Nur noch die Informationen über die Inputdatei behalten zwecks Übersichtlichkeit. Enthalten in der input.txt in Anhang.

    Zur Info: Die Deutsche Tonspur ist wesentlich länger, besteht aber nur aus Musik, die nach dem Abspann weiter läuft. (Klingt komisch, is aber so^^)

  • Eine Analyse des Inputs und nicht von irgendwelchen Outputs wäre hilfreich, leider ist nicht klar was den nun die Beispiele sollen?
    Falls es der Input eine .mkv Datei sein sollte, wäre die Ausgabe der Analyse von mkvinfo interessant.
    Nebenbei: Die Analysen sind auch keine 'Full'-Analysen (und somit nicht ausreichend) und beinhalten z.B. nicht PAR und "Frame count" und letzterer wäre sicher auch interessant,...

    Aha, sehe Du hast den Beitrag editiert, wenn Du jetzt noch die Analyse 'richtig' machst kann man vielleicht was dazu sagen.

  • Das erste Beispiel oben ist die Inputdatei.

    mkvinfo kommt sofort... sobald ich rausgefunden habe, wie ich das bediene^^ gib mir ein paar minuten...

    Ich editiere hier dauernd rum, was vielleicht etwas chaotisch rüberkommt! Wie genau mach ich eine "Full-Analyse"?

    /edit:
    Hilft dir das weiter? Wenn nicht, sag mir, was du brauchst... die verbosefassung wird grade erstellt, aber... ich glaub nicht das die sinnig ist.

  • Wenn du MediaInfo als Kommandozeilen-Tool hast (CLI), dann rufst du es (im DOS-Fenster) auf mit "MediaInfo.exe --full Film.mkv > Film.txt".

    Wenn du MediaInfo als Windows-Applikation hast (GUI), dann schaltest du einen höheren Debug-Level ein (z.B. "Details - 10"), bevor du die Datei mit Text-Ausgabe analysierst.


    Extrem lange Protokolle solltest du vielleicht lieber als Textdatei anhängen...

  • Ich hab Aufgeräumt und nach LigHs Wunsch die .txt-Datein angehängt. Ist die erste .txt jetzt eine "Full-Analyse"? Wenn nicht, dann funktioniert das nicht so, wie ihr beschrieben habt... oder ich hab was übersehen... auch nicht unwahrscheinlich.

    Selur:
    1:
    (MKVInfo) | + Block (Tracknummer 1, 1 Frame(s), Zeitstempel 0.000s = 00:00:00.000) an 5786
    (MKVInfo) | + Frame mit Größe 6349
    (MKVInfo) | + Blockgruppe an 12142
    (MKVInfo) | + Block (Tracknummer 3, 8 Frame(s), Zeitstempel 0.000s = 00:00:00.000) an 12145
    (MKVInfo) | + Frame mit Größe 1006
    (MKVInfo) | + Frame mit Größe 1006
    (MKVInfo) | + Frame mit Größe 1006
    (MKVInfo) | + Frame mit Größe 1006
    (MKVInfo) | + Frame mit Größe 1006
    (MKVInfo) | + Frame mit Größe 1006
    (MKVInfo) | + Frame mit Größe 1006
    (MKVInfo) | + Frame mit Größe 1006
    (MKVInfo) | + Blockgruppe an 20201
    (MKVInfo) | + Block (Tracknummer 2, 8 Frame(s), Zeitstempel 0.021s = 00:00:00.021) an 20204
    => keine Anpassung erforderlich, Zeitdifferenz baut sich ja leider erst auf.
    Aber im Gegensatz zu hier lässt sich das nicht durch hin und herspringen im Video beheben. Außerdem läuft auch nur die komprimierte Videospur unsynchron zu allen anderen. Alle anderen passen zusammen.

    2.in den erzeugten timecodes.txt sind jede Menge Zahlen drin... was mach ich damit, bzw. was sehe ich daran?

  • Differenz der Zahlen ist interessant,.. bei 23,976 sollte sie 41 oder 42 sein, was zumindest bei dem Ausschnitt den Du gegeben hast auch einwandfrei zu sein scheint.

    Zitat

    Ist die erste .txt jetzt eine "Full-Analyse"?

    Nein.

    Du schreibst auch, dass das Avisynth Skript genau so aussehe wie in dem anderen Thread, dort wird AVCSource verwendet, falls nicht könnte das ein Problem sein.

  • Ich habs mal in Excel importiert, und das geht ewig so weiter... Stichprobenartig über die ganze Datei auch keine anderen Differenzen als 41 und 42.

    es war auch hier avcsource. das macht staxrip ja automatisch.

    Das ganze Problem finde ich extrem seltsam...

    Willst du mal einen Ausschnitt von originaldatei und anschließendem encode haben? Einen Link dazu möchte ich hier nicht veröffentlichen...
    Ich schmeiß mal alles zusammen in eine .mkv und dann schneid ich mal ein paar scheibchen raus...

    Einmal editiert, zuletzt von Dispatcher7007 (12. April 2010 um 18:14)

  • Wenn Du das Problem mit dem Sample reproduzieren kannst, kann ich mir das mal angucken. (Heißt das Sample ist Synchron und wenn man den Videostream reencoded wird es asynchron.)
    Kannst mir falls es reproduzierbar ist einen Link per PM schicken.

    Cu Selur

  • Ich habe jetzt eine große MKV gemacht, um alles mal parallel zu haben.

    ID1: Videospur komprimiert
    ID2: Videospur original
    ID3: Deutsch aac
    ID4: Englisch aac
    ID5: Deutsch dts
    ID6: Englisch dts

    Dann kann man nämlich sehen, welche spur mit was synchron läuft, eingestellte frameraten, etc...

    Link kommt...

  • Okay... dann halt so. Aber ich bin mal gespannt, ob wir da was finden werden, denn der effekt ist so klein, das er sich in einem kurzen Ausschnitt vielleicht nicht zeigen wird. Größenordnung 1/10000.

    Bei knapp 3h hat sich die Zeitdifferenz zu etwa einer Sekunde aufgebaut.

  • Ja klar...

    vlc, smplayer, mpc, wmp11... alle das gleiche.

    Es kann eigentlich auch kein Playerproblem sein, weil die bis dahin aufgebaute Zeitdifferenz auch in einem herausgeschnittenen Scheibchen der mkv vorhanden ist.

    Da ich die große datei mit allen Spuren gestern bereits geschnitten und hochgeladen hab, kannste sie trotzdem sehen, wenn du willst.

    Ich hab die Reproduzierbarkeit an einem 10min Ausschnitt getestet, aber wie erwartet kann ich mit bloßem Auge nichts erkennen. Kennst du ein Programm zum timecodeparallelen vergleichen von Videospuren?

    Ich habe mal die timecodes der komprimierten fassung und der unkomprimierten in excel nebeneinandergelegt. Sie unterscheiden sich um einen Faktor 1,0000079574160700. Das ist zwar eine Auffälligkeit, aber es ist zu wenig um 1 sekunde in 3h auszumachen. Woher kommt diese Abweichung?

    Irgendwie wird das ganze immer mysteriöser. Wenn ich diesen Thread hier unbedarft lesen würde, würde ich denken: "Der Typ redet doch Blödsinn..."

    Ich Such mir jetzt mal ne andere Quelle... ich schätze hier ist einfach irgendwas völlig daneben...

  • Die Timecodes sind eigentlich das verlässlichste was mir so in den Sinn kommt.
    Das Problem ist halt, dass wenn man das Problem nicht nachstellen kann man nur raten kann,.. :(
    1 Sekunde auf 3h bei 23,976fps sind recht wenig. :(
    Mal versucht wie es aussieht wenn Du die ganzen Filter aus dem AvisynthSkript rauswirfst, oder das File mal mit Hybrid oder einem anderen Tool, was kein Avisynth und DGAVCSource verwendet, reencodest?

  • Zitat

    Wenn ich diesen Thread hier unbedarft lesen würde, würde ich denken: "Der Typ redet doch Blödsinn..."


    nee,so denken nicht alle.
    Kanns nachvollziehen..hast Du den keine Möglichkeit,beide Files in einem geeigneten Videobearb.Programm auf 2 Spuren,deckungsgleich,zumindest den Anfang,in die Timeline zu legen?

    Nun durchscrollen bis Du Unterschiede zwischen den beiden Files siehst.Entweder beide Spuren 50/50 überblendet oder abwechselnd umschalten,Spur 1 und 2.
    Dann die TL umstellen auf "Anzeige" einzelne Framesgenau,also 40 ms.

    Zitat


    1 Sekunde auf 3h bei 23,976fps sind recht wenig.


    ...ist aber hier ein "ko" Kriterium und heisst in allen Fällen....neu capturen.

    Datenrettungen Normwandlungen Restaurierungen Digitalisierungen

  • Wie viele Frames hat das Original?
    Wie viele Frames hat das Reencode?
    Welche Containerframerate?
    Sind Timinginfos im H.264 Stream vorhanden (ermitteln z.b mit H264_parse.exe aus den H264 Tools)?

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!