FFMS2 - was war nochmal der Grund für threads = 1?

De-M-oN

Hallo, was war eigentlich nochmal der Grund, warum bei ffms2 immer die Threads auf 1 gesetzt werden?

Weil das ist echt blöd. Hab hier paar MP4s mit VFR und um die nach CFR zu kriegen, nutze ich ffms2. Nur dauert das sehr viel länger zu encoden als mit L-Smash, eben weil ffms2 auf nur 1 Thread läuft..

L-Smash jedoch erkennt die FPS Rate sehr oft verkehrt. ffms2 erkennt 59,940, was richtig ist, und L-Smash erkennts als 59,928.

Da hilft dann auch die Angabe von numerator und denominator nicht viel, wenn der aus 59,928 timing heraus auf CFR 60 geht. Dann stimmt das Timing nicht und mein extern vorliegender Audio ist dann asynchron.

LigH

Früher hatte FFMS2 mit einer eigenen MKV-Leseroutine gearbeitet und andere Container nur über Zusammenarbeit mit dem Haali Media Splitter unterstützt, teilweise nicht zuverlässig. Besonders Interlaced-AVC in TransportStreams haben leicht zu völlig unbrauchbarem Video geführt, wenn man die Anzahl der Decodier-Threads nicht auf 1 begrenzt hatte.

Heute verwendet FFMS2 ebenso wie L-SMASH Works die libavformat-Bibliothek zum Öffnen von Containern, die mit den Decodern aus libavcodec gut zusammenarbeitet. Die Wahrscheinlichkeit ist also deutlich besser, dass auch mit mehr Decodier-Threads alles ordentlich läuft. Ganz ausschließen kann man aber noch nicht, dass es vielleicht noch Fälle gäbe, die nicht zuverlässig unterstützt werden.

Wenn L-SMASH Works in bestimmten Fällen Fehler hat, sollte man die gut dokumentieren, damit die Entwickler das vielleicht korrigieren können.

De-M-oN

Ohje ich bin gar nicht mehr sicher was richtig und was falsch ist.

Weil die 59,94 von ffms haben diesmal meine kuriosität nicht gelöst:

Komischerweise hab ich diesma so'n Szenario:

Habe Audio meines Spielsounds extern aufgenommen und habe dann in TMPGEnc 1 Frame vor meiner Soundstartmarkierung geschnitten und das gleiche mit dem externen Sound - auch 1 Frame vor der soundstartmarkierung (also 1 frame bevor der sound spielt)

Dann natürlich zum Bereich gegangen wo mein Spiel beginnt und dort dann simultan die spuren geschnitten.

Dann hätte es ja so eig. 100% synchron sein müssen. Und da kommt jetzt der Punkt wo ich das nicht verstehe.

Egal ob ich mit L-Smash oder ffms2 in TMPGEnc 6 reingeh (ich geb allerdings 60,1 mit, damit es zu CFR 60 gemacht wird)

ich muss dann den Sound in MPC-HC um 480ms nach rechts verschieben damit er synchron ist. Also demnach stolze fast 30 frames Abweichung. Wenn ich diese Anpassung mache, ist es allerdings durchweg synchron. Also die konstante framerate ist gegeben und in Avisynth hab ich auch die korrekte Framenummer die TMPGEnc mir genannt hat eingetragen (hab mit TMPGEnc nur synchronisiert und Audio in WAV exportiert, den richtigen Encode mach ich mit MeGUI dann).

Von daher versteh ich nicht wie das sein kann. Timeline von TMPGEnc stand automatisch schon auf 60fps, weil er aus der Quelldatei einlesen kann wie die Timeline sein soll.

Achja und bei 'nem vorigen Video mit gleichem Vorgehen hat es auch wunderbar geklappt.

Und nochmal zurück zum Anfang:

l-smash vs ffms2 indexierung

Da bin ich auch verwirrt was da nun richtig ist.
l-smash erkennt immer so 59,9xx die letzteren beiden zahlen ändern sich je nach video.
bei ffms2 kommt immer 59,940 bei raus.

Bei Mediainfo steht sowas:

Code

Frame rate mode                          : Variable
Frame rate                               : 59.940 (59940/1000) FPS
Minimum frame rate                       : 9.903 FPS
Maximum frame rate                       : 63.830 FPS
Original frame rate                      : 60.000 FPS

Ich frag mich dann schon: Wer hat denn nun Recht? Gesamtframemenge kommt bei beiden Verfahren aber die gleiche Menge raus (also ausgehend von, wenn man nicht auf CFR wandelt via fpsnum und fpsden, sonst ist ja klar das es beides gleich ist)

LigH

MediaInfo liest nur Header. Es wird nicht der komplette Stream auf statistische Verteilungen von Eigenschaften analysiert. Allerdings könnte ich nicht sicher ausschließen, dass vielleicht Timinginformationen ausgewertet werden, wenn die als separater Chunk im Header liegen. Insofern weiß ich nicht, wie aussagekräftig die Min/Max-Werte der Framerate sind, da ist mir nicht bekannt, ob die als einzelne Felder in einem Header stehen (dann sind die eher wenig interessant) oder tatsächlich statistisch ermittelt werden können (das wäre schon spannender).

Was den Delay angeht: Da wäre ich mir nicht sicher, ob eine "Decoder-Latenz" in der Größenordnung liegen kann. Ich erinnere mich aber, dass z.B. VirtualDubMod bei MP3-Spuren in AVIs wahlweise eine Verzögerung des Decoders ausgleichen kann. Na, vielleicht kann sich jemand noch offensichtlichere Gründe vorstellen.

LigH

Ich hab's gerade im News-Beitrag erwähnt weil es da vielleicht auffälliger ist, aber Antworten passen sicher hier ganz gut: Arbeitet die dort verlinkte neue FFMS2-Version mit bisherigen Problemfällen besser, oder stattdessen mit anderen Quellen nicht mehr richtig?

Jetzt mitmachen!