Mrestore und andere Restoringtools

    Hallo Jungs,
    das mit dem numr / denm versteh ich leider nicht.

    Ok, bis hier (Readme) kann ich es nachvollziehen:

    Zitat

    => ein guter Startwert fuer 'x' ist haeufig der Wert 2002.
    - Beispiel: 59.94fps -> 25fps
    numr = output framerate * 2002 = 25 * 2002 = 50050
    denm = input framerate * 2002 = 59.94 * 2002 = 120000

    Aber da steigt mein Hirn aus:

    Zitat

    numr / denm = 50050 / 120000 = 1001 / 2400
    => numr = 1001, denm = 2400

    wo bekomm ich diese Werte (1001 und 2400) her ?

    Was ist, wenn ich eine input framerate=23.770 und output framerate=25.0 haben möchte?

    Zitat von Selur

    Dann wäre das doch eigentlich ein Fall für eine Normwandlung


    Ist es auch, aber....

    möchte ich das schon Wissen und Seltsamerweise habe ich ein besseres Bild mit MRestore als mit irgendeine anderen Normwandel/Deinterlace Funktion.

    Und jetzt kommt das Kopfkratz:
    Wenn ich nach MRestore noch ChangeFPS(23.770).AssumeFPS(25) dranhänge, ist es auch mit der Uralten TV-PAL fast zu 99.9~% Frame syncron.

    Was für eine Source hat denn 23.770 als Framerate? Sowas gibt's ja eigentlich gar nicht.

    Die Antwort auf die numr/denumr Frage ist einfach:

    Zitat

    wo bekomm ich diese Werte (1001 und 2400) her ?


    Der Bruch kann "gekürzt" werden:
    50050/120000 --> (/10) --> 5005/12000 --> (/5) --> 1001/2400


    Wie die Geschichte als ganzes in diesem Fall aussieht ... keine Ahnung. Grundsätzlich sollte es keinen Sinn machen, MRestore auf 24fps-Material anzuwenden. MRestore dient ja dazu, Normwandlungen rückgängig zu machen; wenn die Quelle als 24p daherkommt, kann ja eigentlich keine Normwandlung vorliegen.

    Andererseits, in der Ecke von Anime/Comic/etc. ist ja sprichwörtlich ALLES möglich. Wenn man da mit "gesundem Menschenverstand" herangeht, hat man meistens schon verloren. ;)

    Habe mich noch nicht mit mrestore beschäftigt, aber spricht denn etwas dagegen die Frameraten einfach mit tausend zu multiplizieren und als numr / demr anzugeben?

    mawi2006

    Intel Q9550@2500 MHz / Motherboard Name Asus P5N-VM WS / Grafikkarte NVIDIA Quattro FX470 / 4x2 GB 800 MHz / DVD-RAM DVR-216DBK / LiteOn IHas 322 / HDD: 500 GB HD502HJ / SSD: Solidata K5 64GB

    Die Dezimierungsfaktoren sollten zwischen 1.5 und 2.5 liegen. Also:

    Code
    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.

    Code
    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:

    Code
    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.

    FixBlendIVTC und mrestore wurden wieder aktualisiert. Die Ausgabeframerate muss nun wieder direkt gesetzt werden, was den meisten hoffentlich sehr entgegenkommt. Das Problem der alten Ungenauigkeiten bei der Berechnung der changefps Ausgabe wurde mit diesen Release auch gleich beseitigt.

    Update:
    Nachdem ich, angefangen mit Cdeint, nun schon einige Blenderkennungsmethoden (C-, D-, L-, M- und P-Core) durchlaufen bin, gibt es nun ein weiteres größeres Update (X-Core).
    Die neue Funktion srestore löst mrestore, Cdeblend, FixBlendIVTC und DupHQ ab. Zudem ist es mein erster Filter mit einer funktionierenden Patternerkennung.
    Aufgrund der gravierenden Neuerungen empfand ich eine weitere Umbennennung sinnvoll.

    Wichtig:
    - Mrestore 2.31 hatte einen gravierenden Bug und wurde deshalb aus dem Paket entfernt
    - in AviSynth 2.5.8 wird die Berechnung von changefps von round zu floor geändert. Ich werde srestore erst anpassen sobald diese Version Final ist.

    Update
    Es gibt schon wieder eine überarbeitete Version. Viele kleine Verbesserungen, wie zum Beispiel Avisynth 2.58 Kompatibilität. GRunT wird in dieser Version allerdings noch nicht verwendet.

    Hi,
    vielleicht könnt Ihr mir weiterhelfen ...
    In einer anderen Diskussion übers Deinterlacen bin ich das erste Mal über Begriffe wie Blends gestolpert. Im Rahmen dessen wurde mir zur Analyse das Interlacing2Reader-Skript empfohlen, dabei habe ich das Mrestore-Pack gefunden ...
    Nur leider steige ich bei der Anwendung nicht ganz durch :ratlos: Quelle ist ein DVB-Stream.

    Zur Analyse hab ich mal Interlacing2Reader genommen, vermutlich auch nicht unbedingt perfekt :hm:

    Code
    LoadPlugin("...\AviSynth 2.5\plugins\TIVTC\tivtc.dll")MPEG2Source("...\Gargoyles 01.d2v")import("...\AviSynth 2.5\plugins\Interlacing2Reader.avs")vFrames=Framecount(last)Interlacing2Reader(end=vFrames,inf=2,file="test.log")


    Ergebnis sieht dann so aus:

    Code
    interlaced:0 (fluid:0),  progressive:0,  fieldshifted:0,  BFF:0,  TFF:0, blended:0/0
...
interlaced:438 (fluid:146),  progressive:7251,  fieldshifted:10174,  BFF:0,  TFF:16484, blended:126/224


    Aber wie hilft mir das jetzt mit mrestore weiter und wie setze ich mrestore richtig ein?

    Gruß
    MacLeod

    MacLeod
    Der Interlacing2Reader haette auch mal dringend eine Ueberarbeitung notwendig. Naja, spaeter vielleicht.
    Die Funktion gibt keine Auskunft darueber, wie man srestore benutzt, sondern nur ob es ueberhaupt noetig ist.
    Sollte mal eine Methode zur Auswertung der Berechnungen aufschreiben, aber auch das muss erstmal warten.

    Zu dem Ergebnis laesst sich hier nicht so viel sagen. Gut möglich waeren eine DEFT-Wandlung (tdeint(mode=1).srestore(frate=25)) oder eine Normwandlung (tdeint(mode=1).srestore()).
    Den Bobber kannst du natuerlich durch deinen Favoriten ersetzen.

    Zitat von MOmonster

    ...
    Zu dem Ergebnis laesst sich hier nicht so viel sagen. Gut möglich waeren eine DEFT-Wandlung (tdeint(mode=1).srestore(frate=25)) oder eine Normwandlung (tdeint(mode=1).srestore()).
    Den Bobber kannst du natuerlich durch deinen Favoriten ersetzen.


    Danke für den Tip, sobald mein PC wieder läuft (Board+CPU tot :heul:) werd ich mal schauen, ob ich etwas gebacken bekomme ...

    Update
    Es hat mich einige Zei gekostet srestore nochmal zu verbessern. Die Funktion basiert immer noch auf den X-Core, bringt aber viele qualitative Verbesserungen mit sich um eine moeglichst fluessige Ausgabe zu gewaehrleisten.
    Vorerst bleibt es aber bei der 2.7pre Version. Um die anderen Funktionen kuemmere ich mich zur gegebener Zeit.

    Zitat von MOmonster

    ...
    Zu dem Ergebnis laesst sich hier nicht so viel sagen. Gut möglich waeren eine DEFT-Wandlung (tdeint(mode=1).srestore(frate=25)) oder eine Normwandlung (tdeint(mode=1).srestore()).
    Den Bobber kannst du natuerlich durch deinen Favoriten ersetzen.


    Bobber wird mit "mode" gesteuert? Welche Möglichkeiten habe ich da?

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden