Xvid 1.1 Keyframes nicht gesetzt

  • Lange Zeit bin ich bei der "stabilen" 1.03 Version von Xvid geblieben.
    Jetzt hab ich dann aber doch einmal das neueste build von celtic cruid (3. August) ausprobiert: Leider sind aber noch einige Probleme mit den Zonen vorhanden.
    Da ich gerne mehrere Episoden einer Staffel auf einmal encode, habe ich bis jetzt immer am Ende der einen, bzw. am Anfang der nächsten Episode eine Zone beginnen lassen, wo ein Keyframe erzwungen werden soll.
    Sieht also z.B. so aus:

    63319
    63320
    126681
    126682
    190047
    190048
    252348
    252349
    315574
    315575
    usw.

    Damit hat sich dann jede einzelne Folge framgenau herausschneiden lassen.

    Mit der 1.1er Version beginnen die Probleme meist bei der 3. Zone bzw. 5.Zone (ist manchmal verschieden), also hier ab Frame 126681 oder 190047. Es werden zwar Keyframes gesetzt, nur mit fortlaufender Dauer immer später. So ist am Anfang ein Keyframe bei 126682 und 126683, später wird es immer "fälscher" ;), die nächsten K-Frames sind bei 190049 und 190050. Bei ca. 10 Episoden am Stück ergibt das zum Schluss also schon einen gewaltigen Fehler.

    Da die Zonen also nicht mehr richtig funktioneren zu scheinen, dachte ich man könnte es auch anders probieren: Man fügt nach jeder Episode 5 "Dummy Frames" ein, also 5 mal das selbe Bild hintereinander. Da das Ende jeder Episode fast in purem Schwarz endet, müsste damit auf jeden Fall ein Keyframe gesetzt werden (vom Codec selber).
    Nur leider funktioniert dies auch nur teils, je nachdem was für ein Frame man erwischt. Es werden zwar immer 2 Keyframes gesetzt, nur leider teilweise mit dem selben Fehler wie bei den Zonen. Es werden also teilweise 2 Keyframes mit 5 Frames Abstand gesetzt, welche beide schon nach dem Ende der 5 Dummy Frames sind.

    Hat vielleicht jemand ähnliches beobachtet?

  • Wieso erstellst du nicht ne Joblist für V-Dub-Mod ?
    Dieses "Zusammenkleben" => Encoden => "Zerschnippeln" ist doch Murks.

    Oder du pakcst das Video in MKV und setzt Kapitel.

    Die Rotation der Erde wurde in den letzten Jahren primär durch sich im Grab umdrehende Musiker angetrieben - Mainstream sei dank.

  • Sorry, aber das ist keinesfalls Murks :)
    Die einzelnen Folgen lassen sich sehr stark unterschiedlich komrimieren. Damit man aber eine ausgewogene Qualität erhält muss man die Folgen auf einmal encoden. Dann wird bei den leicht komprimierbaren Folgen gespart und bei den bitratehungrigen entsprechend mehr Platz zur Verfügung gestellt.

    Das bringt oft bei ca. 600MB Zielgröße Unterschiede von bis zu 150MB!

  • Hast Recht.
    Das ist nen Argument!

    Und wie sieht's aus mit MKV ?

    Die Rotation der Erde wurde in den letzten Jahren primär durch sich im Grab umdrehende Musiker angetrieben - Mainstream sei dank.

  • Ach! So geht das auch, stimmt...

    Ich hab das immer so gemacht, daß ich für alle Folgen den ersten Pass gemacht habe, die stats-Dateien per xdstat ausgelesen und danach dann den Platz für den 2.Pass aufgeteilt habe. Da ist Deine Lösung natürlich mit deutlich weniger "rumskripten" verbunden...
    ...dafür ist meine Lösung flexibler.

    Naja, wie auch immer, Murks ist das nicht. Aber wo das Problem herkommt?
    Hast Du mal geschaut, ob es eine Art 0-1 Problem ist, also verschiebt sich das Ganze z.B. bei jedem "Schnitt" immer um genau einen Frame und man merkt es am Anfang einfach noch nicht?

    [edit:] Mit 0-1 Problem meine ich, daß das eine Programm bei Frame 0 beginnt zu zählen und das andere bei Frame 1

    Grüße!
    Trekkie2

  • Nachher pack ich sowieso alles in mkv, aber ich möchte halt gerne Einzelfolgen haben und keine große Datei.
    Was mir jetzt auch noch aufgefallen ist: Irgendwas scheint bei der Keyframeerkennung derzeit komplett falsch zu sein.
    Man sollte ja erwarten, dass das erste Frame was sich deutlich vom vorherigen unterscheidet gleich ein Keyframe sein sollte.
    Wenn man in Vdub sich Frame für Frame anschaut, sieht man jedoch dass auch hier etwas falsch läuft. Entweder das letzte Frame von der "vorherigen" Szene ist schon ein Keyframe, oder aber erst das 2. der neuen Szene. Bei der 1.03 Version war das Keyframe immer das erste Frame der neuen Episode, so wie ich auch denke dass es sein sollte.

  • Eastermeyer
    MKV setzt keine I-Frames, er schneidet wohl beim nächstliegenden nicht B-Frame referenzierten I-Frame.

    Noch eine Lösung wäre (haut mich wenn allzu dämlich) einfach einmal ohne Zonen alles zu encodieren. Nachträglich in VirtualDubMod laden und die MB-Werte am unteren Rand notieren. Somit weiß man wie groß ein Teil wurde und kann anschließend alle einzeln mit dieser Größe komprimieren. Die Joblist spart hier Zeit und Nerven.

    Die Insegsamte Größe kann man dann an einem beliebigen Teil kompensieren.

    [edit]Vorsicht! bei x264 ist das nich möglich.
    Hab noch schnell ein Video mit meinem XviD 1.1 im Single-Pass Modus encodiert und dabei wahllos I-Frames gesetzt. Da stimmen die Postitionen der I-Frames alle.
    Womit hast Du denn zusammengefügt? Falls mit VDMod -> AVISynth probieren.

  • Zitat von Trekkie2


    Hast Du mal geschaut, ob es eine Art 0-1 Problem ist, also verschiebt sich das Ganze z.B. bei jedem "Schnitt" immer um genau einen Frame und man merkt es am Anfang einfach noch nicht?

    [edit:] Mit 0-1 Problem meine ich, daß das eine Programm bei Frame 0 beginnt zu zählen und das andere bei Frame 1

    Nein, es ist sicher kein 0-1 Problem, da man genau sieht wo das Keyframe sein müsste bei den 5 Dummy Frames.
    Und bei den Zonen ist es dasselbe. Wenn man exakt auf das Frame seekt, welches ein erzwungenes Keyframe sein sollte, ist leider keines da.

    Könnte vielleicht mal jemand probieren, ob das mit der falschen Position auch bei normalen Szenenwechseln wie im vorigen Post beschrieben auftritt?

  • Zitat von fps

    Wenn man in Vdub sich Frame für Frame anschaut, sieht man jedoch dass auch hier etwas falsch läuft. Entweder das letzte Frame von der "vorherigen" Szene ist schon ein Keyframe, oder aber erst das 2. der neuen Szene.


    War beim Enkodieren die "packed bitstream" Option gesetzt oder nicht gesetzt? War sie *nicht* gesetzt, ist dieses Phänomen völlig normal (Anzeige"fehler" von VirtualDub, der darauf zurückgeht das "B-Frames-in-AVI" ~eigentlich~ gar nicht erlaubt sind).

    Wenn "packed bitstream" gesetzt war, dann ist's wirklich ein Fehler.


    Merke: Wenn man so enkodiert dass hinterher auf jeden Fall geschnitten werden *muss*, dann *immer* mit "packed bitstream" arbeiten. Erst recht, wenn womöglich Schnipsel zusammengefügt werden sollen (u.a. auch bei partiellem Enkoding!!)
    Ansonsten kann man schnell in Teufels Küche kommen, graue Haare kriegen oder selbige gar verlieren ... :D

  • Es war nicht gesetzt, nur warum funktionierts dann mit 1.03 aber nicht mit 1.1?
    Packed Bitstream hatte ich bei beiden Versionen immer deaktiviert.

  • Zitat von Didée

    Merke: Wenn man so enkodiert dass hinterher auf jeden Fall geschnitten werden *muss*, dann *immer* mit "packed bitstream" arbeiten. Erst recht, wenn womöglich Schnipsel zusammengefügt werden sollen (u.a. auch bei partiellem Enkoding!!)
    Ansonsten kann man schnell in Teufels Küche kommen, graue Haare kriegen oder selbige gar verlieren ... :D

    kannst du das bitte mal genauer erläutern.

    ich arbeite immer ohne packet bitstream und beim verteilten encoden mache ich genau das (schnipsel zusammenfügen)

Jetzt mitmachen!

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