Beiträge von MOmonster

Wirklich 14fps? Sollten doch eigentlich 12.5fps sein. Naja, ohne ein Sample kann man nichts Sicheres sagen. Wenn die ursprüngliche Quelle jedoch von Pal oder so auf NTSC 29.97i (interlaced) normgewandelt wurde (mit Blends), und anschließend einfach deinterlaced wurde (29.97p), dann kannst du wirklich nichts mehr gegen die Blends und die stockenden Bewegungen machen.

may24
Ohne ein kurzes Sample kann ich auch hier nichts Genaueres dazu sagen.

@paint4you
Mastern beschreibt einfach nur das erstellen der DVD mit entsprechender Software und natuerlich dem Videomaterial.
Also noch mal zusammengefasst:
1. Deine Quelle ist Pal, also 25fps (genau genommen 25i, i fuer interaced).
2. Die originale Framerate deiner Quelle betraegt 23.976fps (NTSC konforme Framerate). Diese Framerate wird durch mrestore wieder hergestellt. Die Avisynth Ausgabe ist fluessig und blendfrei bei 23.976fps.
3. Soweit ich weiß sind bei DVD's nur die beiden Bitraten 25fps fuer Pal und 29.97 fps fuer NTSC erlaubt.
Der DVD Rebuilder (bzw. CCE) setzt die ausgegebene Framerate also wieder auf 25fps, indem das Video einfach etwas schneller abgespielt wird. Dadurch kommt es auch zur Asynchronitaet.
4. Wenn's nicht unbedingt wieder eine konforme DVD sein soll, wuerde ich mir den Aufwand sparen und direkt mit 23.976 fps kodieren.
Ansonsten gibt es zwei Moeglichkeiten das Problem anzugehen:
a) Den Sound ebenfalls beschleunigen. (DVD bleibt Pal, Laufzeit wird allerdings verkuerzt und Sound muss neu encodiert werden)
b) Mit Pulldown (beherrschen die meisten MPEG2-Encoder) die Framerate auf 29.97fps setzen und so eine NTSC-konforme DVD erstellen.

Welche Tools dafuer am geeignet sind, solltest du vielleicht im entsprechenden Themenbereich erfragen bzw. erlesen.

Ich dachte es sind nur sehr wenig Szenen in denen die Framerate wechselt. Wenn das so ist faellt mir nur diese Moeglichkeit ein:

Tdeint(mode=1)
Cdeblend()   #some tweaking?

Die Blends in einem Durchgang mit Cdeblend entfernen und anschließend wie auf der verlinkten Seite beschrieben hybrid dezimieren.

Automatisches Skript zur Erkennung der momentanen tatsaechlichen Framerate ist mir nicht bekannt.

Also den 29.976fps Anteil mit diesen Script bearbeiten:

#bobbermrestore(numr=600,denm=1001)changefps(120000,1001)

Und die andere Szene mit diesem Script bearbeiten:

#bobber
mrestore()
changefps(120000,1001)

Und Anschließend wieder zusammenfuegen.

Beim Erstellen der mkv muss man dies als ersten Schritt wohl auch so machen, allerdings reicht eine geringere Framerate aus. Der Rest wird denn so wie auf deiner verlinkten Seite gemacht (dezimiert mit vfr stats). Da steht allerdings auch, dass man mit mp4box verschiedene cfr Videodatein direct in eine vfr Datei zusammenfuegen kann.

Wenn also mp4 angenehm ist, einfach die Videobereiche mit passenden Skript (ohne changefps) umwandeln und mit mp4box zusammenfuegen.

Redfox
Du hast dir das Sample nicht angesehen. Es ist wirklich eine Normwandlung mit Blends (wenn auch dynamisch, sehr dynamisch).

@paint4you
Das Problem ist nicht der Bobber oder mrestore. Die Ausgabe ist 23.976fps und muss auch so encodiert werden (also NTSC). Da die Quelle aber eine Framerate von 25fps hat, wird sie auch wieder in dieser Framerate gemastert. Dadurch entsteht der Delay (weil Bild schneller als Ton laeuft).
Damit die Quelle fluessig und blendfrei encodiert werden kann, muss sie NTSC gemastert werden. Ob DVDRebuilder das kann, weiß ich allerdings nicht.

Soweit ich weiß, steht das im Mpeg4 standard, sollte also jeder Decoder problemlos unterstützen, was natürlich nicht heißt, dass jeder Encoder diese Moeglichkeit ausnutzt.
Bin mir aber auch nicht ganz sicher.:hm:

Bei typischen Normwandlungen mit Blending lassen sich die Mischbilder tatsächlich wieder entfernen zum Beispiel mit restore24 oder mrestore.

Das klappt beim hochgeladenen Sample auch sehr gut. Es bleiben aber noch viele typische Artefakte, die bei diesen Wandlungen haeufig auftreten, uebrig. Ein guter Deblocker, der nur bei bewegten Szenen aktiv ist, oder vielleicht auch ein Bewegungskompensierender Rauschfilter koennte hier helfen. Da bin ich allerdings der falsche Ansprechpartner.

Ich schiebe die m2v bzw. vob normalerweise einfach durch dgindex und schaue mir anschließend das Resultat in virtualdub an. Eine Mpeg2 kann man zum Beispil recht gut mit tmpgenc oder hcenc erstellen.

Dvdrebuilder nutze ich selber nicht. kann es sein, dass die ausgegebene Framerate von 23.976fps einfach wieder auf 25fps gesetzt wird und daraus der Versatz zwischen Bild und Ton resultiert? Muesstest du einfach mal testen.

Ja Telecine erzeugt wieder Interlacing bzw. Fieldshifting. Genau genommen werden zwei von fünf Frames fieldshifted. Das Script soll nur auf den kleinen Teil der Quelle angewendet werden, der mit mrestore(nurm=600,denm=1001) nicht fluessig wird und ist eigentlich auch blendfrei.

Ich kenne nur zwei Möglichkeiten diese Quelle progressiv, ohne Blending und Interlacing auszugeben:
1. Hybride Framerate im mkv-Container (kenne Methode nicht).
2. Raufrechnen auf höhere Framerate.

Also zum Beispiel beide Teile der Quelle (29.97fps und 23.976fps) auf 60000/1001fps oder noch besser auf 120000/1001fps hochrechnen und wieder zusammen fuegen. Rund 60 bzw. sogar 120fps klingt zwar sehr viel. Da der mpeg4 Codec allerdings identische Frames auch nur als Duplikate erkennt und abspeichert sollte sich das in der Größe der Datei nur sehr gering niederschlagen. Bei Mpeg2 bin ich mir da allerdings nicht so sicher.

Ich mag keine hybriden Quellen.
Wenn du mrestore mit standard settings (mrestore()) drueber laufen lässt, ist die Ausgabe fluessig mit 23.976fps.
Würde das wahrscheinlich mit 3:2-Pulldown auf 29.97fps raufrechnen lassen und so komplett kodieren. Der mkv-Container soll ja auch hybride Frameraten erlauben. Wie man das denn alles allerdings am besten zusammen bringt, weiß ich selber nicht.

Vielleicht hilft ja das hier weiter.
Ansonsten weiß ja vielleicht ein anderes Forenmitglied um besseren Rat.

Und wieder ein Bugfix fuer mrestore, jetzt in Version 2.3e.

Ich kann den Fehler mit deinem kurzen Sample nicht reproduzieren. Aber versuche mal die Version, die ich in den Anhang geladen habe, und sage bitte bescheid, ob es läuft oder nicht.

Mein Fehler!
Hatte irgendwo in meinem Script noch 'nen Bobber übersehen und dachte jetzt: Wunder, welch eine Raritaet.
Statt tfm() also einfach einen Bobber:

tdeint(mode=1)
mrestore(numr=600,denm=1001)

Edit:
Benutzt du die letzte Version von mrestore (hochgeladen vor einer Woche oder so)?

Ist wirklich nicht so einfach zu erkennen. Die Quelle ist fieldshifted bei 50fps. Anstelle des Bobbers muss ein Fieldmatcher verwendet werden. Dann muss man auch noch erkennen, dass die Ausgabeframerate 29.97fps und nicht 23.976fps betraegt und dafuer die richtigen Parameter setzen. Anschließend kommt man dann auf so ein Skript:

tfm()
mrestore(numr=600,denm=1001)

Mrestore entfernt beim Dezimieren auch die Blends, ist allerdings nicht in der Lage Duplikate als Blends zu erkennen. Weil beim Bobben deiner Quelle jedes Bild mindestens ein Duplikat hat, greift die Erkennung nicht, solange nicht dezimiert wurde.

Das ist allerdings ein sehr seltenes Exemplar.;)

Also wenn du Cdeblend nach mrestore entfernst, sollte das schon einige Probleme lösen (keine echten Dups). Entweder Cdeblend + Dezimierer oder mrestore bzw restore24, aber nicht zusammen. Und jetzt noch |mode|<4, dass bringt eine etwas bessere Dezimierung.

Achja, das kodierte Sample ist nur selten brauchbar oder notwendig, um die richtigen Einstellungen zu finden wird das Ursprungsmaterial benötigt.

Die Dezimierungsfaktoren sollten zwischen 1.5 und 2.5 liegen. Also:

input_framerate/1.5 >= output_framerate >= input_framerate/2.5&1.5<=denm/numr<=2.5

Andere Faktoren sind natürlich auch möglich, optimal arbeitet der Dezimierungsalgorithmus allerdings nur in diesen Bereich.

input_framerate * (numr/denm) = output_framerate

Soviel ist hoffentlich erstmal klar. Außerdem ist numr/denm ein echter Bruch, der sich bis zu einen gewissen Grad kürzen lässt. Beispiel:

input=50, output=23.976
48000/100100 = 480/1001

Zähler und Nenner werden solange durch die gleiche Zahlen geteilt, bis man keinen gemeinsamen Teiler mehr findet. Grundsätzlich ändert sich durch das kürzen eigentlich nichts. Sind der Nenner und der Zähler aber zu groß, kann das zur Ungenauigkeiten oder gar Overflows führen (habe ich selber aber noch nicht getested).

Grundsätzlich ist es natürlich auch möglich die Frameraten * 100 (bzw. 1000) zu rechnen und direkt als denm und numr anzugeben (auch hier sollten die Werte nicht zu groß sein, gegebenenfalls muss gekürzt werde).
Ich habe mich für die Parameter denm und numr anstatt output_framerate entschieden, weil sich bei den Normwandlungen die tatsächliche NTSC-Framerate nicht genau angeben lässt:
tatsächliche Framerate: 24000/1001
gerundete Float-Angabe: 23.976

Das Prinzip mal Hundert beziehungsweise mal Tausend rechnen und anschließend runden, ist für diesen Fall natürlich auch zu ungenau. Ich werde in der nächsten Version aber eventuell einen alternativen Parameter für die Ausgabeframerate hinzufügen.

23.976 ist trotzdem nicht 24000/1001. Bei einem langen video macht sich der Unterschied schon bemerkbar. Am besten du liest den Numerator und Denominator der Source direkt mit Avisynth aus. Das ist am genausten.
Und nicht vergessen, dass Kommazahlen in Avisynth nur float (und nicht double) Genauigkeit haben.

Am besten also tempo vorher so genau wie moeglich berechnen und angeben (auf acht Stellen, wie in sample D). TimeStretch arbeitet dann trotzdem noch nicht absolut exakt, aber genauer geht es damit eben nicht.

Edit:
Mein Taschenrechner rechnet 25*1001/24000 zum Beispiel zu 1.0427083 aus. Bei laengeren Videos wird sich der Unterschied zu deinen Wert am Ende schon bemerkbar machen.

Update: Mrestore_v2.3c behebt einen Fehler der letzten Version. Alle Nutzer der 2.3b sollten unbedingt updaten.

Sozusagen als Beitrag zum Nikolaus gibt es von mir die naechste mrestore Version. Bin mittlerweile bei v2.3b angekommen.

Also viel Spass beim Testen.

Es hat sich seit v2.0 so ziemlich alles veraendert, außerdem muss ich um sechs schon wieder hoch, deshalb lasse ich das mal mit der ChangeLog.

MOmonster

Es ist selten, aber machmal wird auch von 29.97fps auf 25fps gewandelt. Diese Ausgabe ist wesentlich fluessiger als 23.976fps. Default ist mode 2 gewesen und das ist ein bisschen langsamer. Wurde bereits korrigiert, ist aber noch einiges zu tun.

Tut mir Leid, aber das stimmt einfach nicht.
Teste mal diese Einstellungen:

mrestore(numr=600,denm=1001,mode=0,dup=1,rx=2.0,ry=2.0)

Das loest das Problem mit dem Chroma nicht, sieht meiner Meinung nach aber schon besser aus als die gebobbte Quelle.
Auch zeigt mir Virtualdub die gleiche Videolaenge, sowohl mit als auch ohne mrestore an.

In deinen Sample ist mit den falschen Standardwerten die alte Version etwas fluessiger, da die Blenderkennung weniger akkurat ist, außerdem fehlt der neuen Version noch etwas Code (was ich so schnell wie moeglich beheben werde).
Die neue Version ist mit Standardeinstellungen nicht langsamer als die alte, wuerde die aeltere aber auch noch solange nutzen bis die neue ganz fertig ist.