Ist schwer zu erklären, aber ich probiere es mal:Zitat von chakkman
Es liegt am BFrame Delay Effekt, den einige Programme nicht rausrechnen.
Sobald BFrames im Spiel sind, ist die Reihenfolge der Frames im Stream nicht mehr linear. d.h. der Decoder (z.B. x264vfw,ffdshow) muss die Frames richtig sortieren, bevor er sie einem Programm (z.B. Coldcut, Virtualdub) übergibt.
Dafür muss der Decoder bei alten APIs (wie sie CC,CA,VD verwenden) tricksen. Dabei kommt es aber zu einer Verschiebung der Frames (auch bframe delay genannt)
z.B.: so bekommt Coldcut das Frame 252, wenn er glaubt, dass er gerade Frame 250 vom Decoder anfordert. -> eine Verschiebung der Frames -> in diesem Fall ist der bframe delay 2, weil es sich um 2 Frames verschoben hat.
Um wieviel die Frames verschoben werden, kann von Rechner zu Rechner unterschiedlich sein. In der Regel um die 2-8 - hängt vom jeweiligen Decoder und der Anzahl der Decoderthreads ab.
Das bedeutet, dass cutlisten von Rechner zu Rechner nicht mehr übertragbar sind, solange Programme verwendet werden, die den bframe delay nicht rausrechnen. In unseren Fall Coldcut, Cutassisant oder Virtualdub.
Beispiel:
Coldcut User 1, auf seinem Rechner wird durch den Decoder, den er bei sich installiert hat, die Frames um 2 verschoben. Coldcut rechnet es nicht raus, sondern ignoriert es. (mit der Folge, dass alle Werte in den cutlisten falsch sind)
User 1 erstellt jetzt eine für ihn tadellose cutlist, die bei ihm perfekt funktioniert und lädt sie auf cutlist.at hoch.
CutAssistant User 2, bei ihm werden die Frames durch den Decoder um 4 verschoben.
Er lädt die Cutlist von User 1 und schneidet damit. Natürlich funktioniert die cutlist bei ihm nicht richtig, Der Schnitte liegen 2 Frames daneben.
Dafür bekommt User 1 logischerweise eine böse Bewertung von User 2 auf cutlist.at, weil er diesen als unfähig ansieht.
Cutana User 3 lädt auch die cutliste von User 1. Da Cutana fast das einzige Programm ist, dass den bframe delay richtig behandelt, ist der bframe delay in Cutana 0.
Das bedeutet, das man auch wirklich Frame 250 sieht, wenn cutana Frame 250 anzeigen soll. Man könnte also sagen, es arbeitet framegenau.
Trotzdem sind auch Cutana User vom bframe delay betroffen, weil sie mit Virtualdub schneiden müssen. Und VD ist teilweise in bestimmten Situationen auch vom bframe effekt (und diversen Bugs) betroffen.
Auch bei User 3 kann der Schnitt also daneben gehen.
Um es zusammenzufassen:
Wenn ihr framegenauen Schnitt bei H264 wollt, werdet CC, CA und VD los.
Cutana (und auch otrverwaltung++) arbeiten richtig.
Cutana bräuchte nur einen Ersatz für VD fürs Schneiden, dann hättet ihr eine framegenau Lösung für H264.
(wie es otrverwaltung + smartmkvmerge schon ist)
mfg
