IVTC und doppelte Frames innerhalb der Combed-Frames

  • Hi Leuts

    Sorry für die schlechte Beschreibung, aber mangels besseren Wissens kann ich erst hier genauer Beschreiben.

    Also, ich hab ein NTSC-Video mit 59,94 fps (1080i60/1001)

    Dieses wollte ich nun auf die ursprünglichen 24 fps (23,976) IVTC`n.
    Material ist FILM, also ursprünglich definitiv Vollbild.

    Problem: Es wurden nach der NTSC-Wandlung noch zusätzlich Vollbilder eingefügt, es gibt also kein starres 3/2 Muster und man kann somit auch nicht jeder 5te Bild entfernen. Nennt sich glaube ich dann "Hybrid-Material", oder ?

    Dafür habe ich nun folgende Routine verwendet, die auch, was das Deinterlacen angeht absolut sauber funktioniert:

    TFM(order=1,mode=5,pp=7,slow=2,field=-1)

    Hiermit erhalte ich nun ein sauberes Muster von 4 verschiedene Vollbildern + 1 Kopie des letzten Vollbildes. Die zusätzlichen Vollbilder werden sauber erkannt und ausgelassen. 3/2 wird erfolgreich zu 4/1 gewandelt.

    Diese nun noch vorhandenen Dublikate habe ich dann mit:

    TDecimate(mode=1, hybrid=0)

    soweit auch entfernen können.

    Das Problem:
    Wenn ein Szenenwechsel innerhalb der 2 Combed-Frames stattfindet, erhalte ich 2 identische Vollbilder die durch TDecimate nicht entfernt werden.

    Also: Rohstream:

    3 verschiedene Vollbilder, erstes Combed = alte Szene, zweites Combed = neue Szene

    TFM gibt mit an dieser Stelle 2 identische Frames aus, welche außerhalb des 4/1 Musters sind.

    Mit SeperateFields erhalte ich ein sauberes Muster (Bild 3mal identisch, nächstes Bild 2mal identisch, nächstes Bild 3mal, nächstes Bild 2mal identisch), jeweils alles vorwärts-bewegend.
    Der Szenenwechsel findet hier innerhalb des Bildes statt, welches 2mal identisch sein sollte.

    Kann man da noch was machen ? Bei den Szenenwechselbn gibt es jetzt natürlich häufig ein doppeltes Frame.

    MFG
    Marco

  • Das stimmt soweit, aber TDecimate macht wohl nicht so ganz was es soll.

    Woher der Fehler kommt kann ich nichtmal beschreiben, ganz logisch erscheint er mir nicht, vermutlich habe ich falsche EInstellungen ...

    Bei mir ist jedoch mit den hier geposteten Einstellungen definitv ein Doppelbild vorhanden wenn ich TDecimate verwende, aber eben NUR wie hier in dem Beispiel wenn der Szenenwechsel in den Interlace-Bildern stattfindet, alles andere wird soweit einwandfrei dezimiert.
    AsumeTFF() ist gesetzt und laut SeparateFields ja auch korrekt, dort gibt es ein sauberes Muster.

    TDecimate scheint da ein Frame zu verdoppeln.

    Das letzte der beiden Interlaced-Bildern VOR dem Szenenwechsel beinhaltet wohl das erste Vollbild NACH dem Szenenwechsel.
    Somit wird wahrscheinlich das deinterlacede Bild zum exakt gleichen ersten Vollbild welches NACH dem Szenenwechsel kommt.

    Das widerspräche aber der tatsache, das SeparateField ein korrektes Ergebnis liefert.

    Ich finde den Fehler einfach nicht.

    So siehts bei mir deinterlaced UND dezimiert aus, Frame 8 und 9 sind identisch ... (Sample: 6MB)
    Einstellungen siehe Post 1.

    Alle anderen Doppelbilder (durch TFM) werden ordentlich entfernt, bis auf welche in solch einem Szenenwechsel.
    Die Kombination aus Szenenwechsel innerhalb der interlaceden Bilder scheint hier Probleme und ein doppelbild zu erzeugen.

    http://netload.in/dateiL5xUoj4Ge…eint24p.avi.htm

    Es gibt zwar andere Filter um doppelte Frames zu löschen, ich habe aber Angst, das mir an anderer Stelle welche entfernt werden wo keine entfernt werden sollen.Schliesslich ist der Szenenwechsel hier innerhalb der beiden interlaceden Bilder und somit eindeutig zuweisbar ...

    Einmal editiert, zuletzt von mbc (28. Dezember 2008 um 17:42)

  • Muß revidieren, irgendwie seltsam

    Hatte es jetzt so hingekriegt, das die Szene hier sauber lief, dafür kommt ein paar Szenen weiter genau dieselbe Konstelation --> Szenenwechsel in den Combed-Frames.

    Jetzt paßen die Einstellungen zwar für einen Szenenwechsel, dafür aber nicht mehr für den nächsten.

    Also mal wieder mit SerarateFields gearbeitet und es ist ein durchweg sauberes "vorwärts", also die Fields vertauschen sich nicht in der Reihenfolge, das ist soweit absolut sicher.

    TTF ist korrekt, keine Rückwärtssprünge. Das Pattern sit soweit wirklich sauber.

    Ich kriege sie aber nicht Decimated ohne dabei diese Doppelbilder zu erzeugen, wie kann man das umgehen ?
    TFM erzeugt beim Deinterlacen tatsächlich diese Doppelbilder die dem nächsten Vollbild gleichen ...

    Einmal editiert, zuletzt von mbc (28. Dezember 2008 um 21:14)

  • Langsam werd ich hier zum Alleinunterhalter :);)

    Also, spätestens jetzt hasse ich diese verflixten Label, nix können die vernünftig.

    Hab den Stolperstein bei der Szene gefunden, welche nach dem hier gestellten Muster kommt und worüber TFM dann ""stolpert"":

    Das Muster 3/2 geht hier nicht ganz auf, wenn ich die VOLLBILDER betrachte sehe ich meistens:

    3 Vollbilder gefolgt von 2 Combed-Bildern, so ist es ja auch richtig laut Telecine.

    Jetzt habe ich gefunden:

    3 Vollbilder, 1 Combedbild, 1 Vollbild, 2 Combedbilder, 3 Vollbilder, 2 Combedbilder, 3 Vollbilder, ...

    Ne Chance das Vollbild zwischen den drei Combedbildern zu entfernen?

    4 Mal editiert, zuletzt von mbc (28. Dezember 2008 um 23:15)

  • einfach mal mit separatefields die eigenständigen bilder zählen und somit die echte framerate auszählen/ausrechnen.
    Denn wie mir deucht, hat der sender (wie so oft in AMILand) das video beschleunigt oder verlangsamt, um es an seinen programmplan anzupassen.

    die ausgerechnete framerate dann mit tdecimate(mode=2, rate=??.???) exakt dezimieren lassen.

    Du musst mindestens 120, besser 240 fields auszählen um genaue ergebnisse zu erzielen.

  • Das könnte natürlich sein ... ist schon wiedermal ne wilde sache ....


    Bin aber gerade noch auf etwas anderes gestoßen :D

    TFM liefert im Display-Modus schon sehr gute Werte.

    Man kann anhand der c,p,n,u - Erkennung quasi schon erkennen ob sichein Frame verdoppelt. Zumindest glaube ich das das funktionieren könnte. Ich habe das noch nicht so ganz verstanden wie das alles zusammenhängt.

    Die Erkennung Combed und FullFrame geht 1A, auch dieses ZwischenVollbild hier wird ordentlich erkannt.

    Wenn ich nun eine p- bzw. u-Erkennung habe müßte ich nur diese Frames "blenden" lassen und hätte somit einen "weichen" Szenenübergang und kein verlorenes Frame. Das könnte vermutlich funktionieren, aber ich hab den ganzen TFM-Kram noch nicht verstanden. Diese ""Fachgesimpel"" dann noch zusätzlich auf Englisch macht es nicht gerade leichter zu verstehen ;)

    MFG
    Marco

  • Darf ich stören ? :D

    Hab noch bis spät in die Nacht rumprobiert (sowas läßt mich dann nicht locker :nein:)

    Folgendes Ergebnis:

    Video ist definitiv TTF.
    TFM macht eine SUPER Job ! Lob an den Entwickler, tolles "Teil" :ja:

    Hab mal Infos und OutPut aktiviert und es kommen tolle Dinge bei raus, es wird alles korrekt erkannt und mit den Infos kann man alles korrigieren.

    Das Problem ist: WIE ? TFM macht hier nämlich entweder einen Fehler, oder aber ich habe die falschen Einstellungen (das vermute ich):

    Im Anhang ist die OUTPUT-Datei der Analyse von TFM (nach *.txt umbenennen):

    Das hier gepostete Sample entspricht im Szenenwechsel den Bildern:
    7127 und 7128

    Man erkennt das 7127 eine "kopie" von 7126 und 7128 eine "kopie" von 7129 ist.

    Es gibt also durch TFM beim Deinterlacen 2 Doppelbilder (2*2 identische).
    TDecimate entfernt nun eines der ersten Beiden, um die Framerate anzupassen. Dadurch bleibt jedoch ein Dopppelbild über.

    TFM erkennt den Szenenwechsel aber korrekt (mit "SC") (kann ich im Display erkennen, steht nicht hier im LOG).

    TFM müßte nun diese beiden als "SC" erkannten Frames per blend zusammenmischen und wenn TDecimate dann eines der beiden entfernt ist alles korrekt. Kein Doppelbild mehr, die passende korrekte Framerate und ein sauberer Blend.

    Das wäre absolut perfekt.

    Die neue "Stolperszene die ich meine ist bei den Bildern 7962-7964 dort erkennt man das eingeschobene "C"-Frame (Vollbild). Wenn man dieses entfernen würde, wäre auch diese Szene perfekt.

    Problem:
    Wie kriegt man das automatisch hin, so ganz blick ich durch die Möglichkeiten bzw. der Verbindung zwischen TFM und TDecimate bzgl. der Informationen die TFM findet nicht durch.


    MFG

  • hast Du mal die Halbbilder gezählt?
    also eigenständige Film-Frames gegen die Halbbilder des Videos.

    Sind diese Doppel-Frames NUR an Szenenwechseln oder auch mittendrin?

    IMO kriegst Du eine saubere IVTC nur, wenn man auch zur richtigen Framerate hin dezimiert.

    Und Szenenwechsel zu blenden ist - mit Verlaub - dämlich.
    Denn der Kompressor wirds Dir danken...

  • so, jetzt habe ichs mal gezählt.

    am szenenwechsel, wird aus dem starren 3 zu 2 pattern ein patternbruch (typisches problem)

    3-2-3-2-3-1|1-3-2-3-2

    wie man deutlich sieht gibt es in diesem Falle zwei orphaned Fields (verwaiste Halbbilder).
    Damit scheint TFM nicht richtig umgehen zu können und nimmt lieber eine kopie des nachbarbilds. warum, weiss ich nicht.
    Ein Workaround stellt TDeint dar:

    tdeint(mode=1,full=false, tryweave=true) #mit fieldmatching auf 59.94 fps deinterlacen
    tdecimate(cycle=5,cycleR=3) #auf 23.97fps dezimieren.

    mit den parametern full=false und tryweave=true versucht tdeint alles mögliche zu matchen und deinterlaced nur noch, wenns nicht mehr matchbar ist.


    Was ist eigntlich das Zielformat?
    HD? SD? XVid etc??

  • Dem Problem wieder etwas weiter auf der Spur ... glaube ich zumindest :grübeln:

    Die Bilder zu zählen ist schwierig, bei Einblendungen (von schwarz) sowie wenig Bewegung, ...

    Im LOG ist aber auch das Muster "cccpp" zu erkennen,
    "c" bedeutet Vollbild
    "p" bedeutet Combed (also 2 Halbbilder pro Vollbild)

    Also eigentlich fast durchgehend ein Verhältnis 3:2, das ist wohl zu mind. 97% des Videos so, ist somit ja ne recht saubere Wandlung, Probleme sind meistens nur bei den Szenenwechseln oder in schwarzen Blends, die nachträglich eingefügt oder verlängert wurden. Da hakt dann auch TFM, denn zu 97% läufts mit TFM sauber.

    Vorlage war definitiv FILM

    Also ich habe mit AssumeTFF().SeparateFields() (sind ja die Halbbilder):
    ("A" "B" "C" "D" steht für die originales Einzelbilder (welche ja einmal Vollbilder waren)

    A-Top A-Bottom
    A-Top B-Bottom
    B-Top C-Bottom
    C-Top C-Bottom
    D-Top D-Bottom

    usw... das ist bis auf die Szenenwechsel auch so und entspricht ca. wohl 97% des Videos.

    Das ist ja eigentlich reines Telecine 3:2 (2:3 mit Frameshift), oder ? 10 Halbbilder (5 FullFrames) aus ehemals 4 Vollbildern.

    Beim Szenenwechsel hier liegen die Bilder ja aber so vor:

    A-Top A-Bottom
    A-Top B-Bottom
    -- Szenenwechsel --
    C-Top D-Bottom
    D-Top D-Bottom
    E-Top E-Bottom

    Das entspricht nicht ganz der Norm wenn ich richtig liege, denn es fehlen 2 Halbbilder (B-Top und C-Bottom).
    Das erkennt TFM aber wie gesagt alles einwandfrei, aber das letzendliche Handling klappt in Verbindung mit TDecimate nicht so wie es sollte.

    TFM ersetzt hier mit meinen Einstellungen: B-Bottom durch A-Bottom und C-Top durch D-Top. So entstehen (vermutlich) die Doppelframes. Wodurch eines der beiden entstehenden Doppelbilder dann durch TDecimate entfernt wird.

    Ich kriege es nicht hin, das TFM beide fehlenden Halbbilder interpoliert. Das muß ja bei einem solchen Szenenwechsel pasieren, da die GegenFields ja fehlen.

    Steh da echt auf dem Schlauch ...

    EDIT:
    Verdammt, da war der Profi schneller ... ich glaub wir Beide liegen richtig, nur ich kann mich nichtso professionell ausdrücken, ursache ist aber gefunden: zwei Fehlende Gegenfields am Szenenwechsel welche durch TFM aber ordentlich erkannt werden (aber halt nicht verarbeitet).

    Zielformat soll HD (x264) sein (aber natürlich mit den richtigen 23,976 Frames ohne Interlacing ...)

    Einmal editiert, zuletzt von mbc (29. Dezember 2008 um 13:55)

  • Zitat

    Zielformat soll HD (x264) sein (aber natürlich mit den richtigen 23,976 Frames ohne Interlacing ...)

    Und welche Auflösung?

    btw.: bei der wandlung vom Quellformat in das Sample-XVid ist die Farbe auf der strecke geblieben...
    Vewrmutlich hast Du es progressive encodiert...

  • 1080p, das Maximum halt, auch wenn die Quelle eigentlich nur upscaled wurde und eigentlich auch 720p ausreicht. Da spätere Folgen richtiges HD sind würde ich gerne durchgehend die 1080 beibehalten. --> OK, etwas schwachsinnig, aber nun ...

    Zitat

    btw.: bei der wandlung vom Quellformat in das Sample-XVid ist die Farbe auf der strecke geblieben...
    Vewrmutlich hast Du es progressive encodiert...

    Da liegst Du (erstaunlicherweise) richtig, habs auf die Schnelle progressiv kodiert. Benutze XVID eigentlich nie, ging sich ja jetzt nur um einen Testclip.
    Oder hat das bei Dir so Probleme bereitet oder etwas umständlicher gemacht ?

    Könnte aber "vermutlich" auch daran liegen, das ich im AVIsynth-Skript noch ConvertToYV12 aktiviert habe. Später kodier ich nämlich mit x264cli und der braucht ja YV12 als Input.
    Hab das Skript einfach mit VDub geladen.

    Das fertige X264 sieht von den Farben her OK aus, dürfte also wohl OK sein, oder irre ich mich da mit meiner Vorgehensweise ?

    War mir bei dem XVID-Sample auch schon aufgefallen, irgendwie waren die Farben so schön kräftig .... :eek:

    Sah auf dem LCD irgendwie garnicht mal sooo schlecht aus ...

    MFG

  • mache mal separatefields()
    mit dem sample-video und guck Dir die farben bei stark gesättigten bewegten bereichen an!

    bei allen combed frames ist die farbe vertikal vermatscht (d.h. es gibt kein farb-interlacing mehr)

    d.h. bei allen fields der combed frame ist die farbe statisch.

  • Da haste recht, gibt unschöne "Farbverschmierungen", wieder was dazu gelernt und zum Googeln gefunden.

    Nochmal zum TDecimate zurück:

    Hab jetzt mal ne komplette Folge durchlaufen lassen, soweit recht gut, aber jetzt macht TDecimate "Mucken".

    Nach jedem Szenenwechsel mit einem Patternbruch, wird zwar das erste Frame genommen, das zweite aber ausgelassen (ab dem 3ten gehts dann wieder normal). Das wär mir anders herum lieber.

    Ich hab in TDecimate mal die Debug-Info eingeblendet und habe ja normalerweise das Muster 3 - 2 - 3 - 2 - 3 - 2 welches man an der "useframe"-Anzeige ja mitzählen kann.

    Der Patternbruch wird korrekt behandelt, aber danach macht TDecimate einen Sprung von 5 Frames, es wird also eines zuviel ausgelassen. Dadurch entsteht ein komischer "Speed-Up" direkt nach (leider vielen) Szenenwechseln. Es gibt leider sehr viele orphaned Fields in dieser Serie.

    Ist irgendwie zum verrückt werden :wall:
    Kann man an dem Sampel auch erkennen, da fehlt nachher eines ...

    Und ich merke gerade, ads ich das Thema "Deibnterlacen" immer unterschätzt habe ... :ratlos:

  • Zitat

    Und ich merke gerade, ads ich das Thema "Deibnterlacen" immer unterschätzt habe .


    Willkommen bei denen die hoffen, dass Interlacing endlich aus der Welt geschafft wird und statt dessen die Frameraten erhöht werden wenn man die Bewegungsinformationen braucht. :)

  • Selur, ob nun 1080i60 oder 720p60, ist egal.

    TDecimate würde bei beidem springen...

    mbc:
    manchmal muss man echt wieder leichen aus dem Keller graben:

    SMARTDECIMATE, Dein Freund und Helfer!


    loadplugin("c:\x\avisynth_c.dll")
    loadCplugin("C:\x\smartdecimate.dll")
    avisource("avisynth.avi")
    assumetff()
    smartdecimate()

  • Die Leiche hab ich gefunden ;D

    Dann wolln wa mal dran rumfummeln *lechtz*

    Selur:
    Und ich war schon ""stolz"" das mit IVTC """"rausgefunden"""" zu haben, und dann kommt sone tolle Überraschung mit verlorengegangenen Halbbildern. Ich frag mich echt wie die das immer hinkriegen ... man lernt echt nie aus.

  • SOOOO, ein kurztest sieht schonmal SEHR gut aus :daumen:

    Hatte jetzt zwar noch nen Combed-Frame, aber da hab ich nochmal den TFM hintergehangen und jetzt ist zumindest diese Stelle SUPER !!!!!

    Das dürfte 99% der Fehler beheben, es sei denn es tauchen vermehrt stellen auf, wo Vollframes zwischen den Combed liegen, da gibts dann noch Doppelbilder, aber ich hoffe das das nicht all zuviele Stellen sind, ansonsten dürften die paar Fehler sehr tragbar sein.

    Ich lß das jetzt nochmal 4 Stunden durchrattern und schau mir morgen mal das Ergebnis am großen TFT an ... bin echt gespannt ... SmartDecimate ist ja wahnsinnig schnell !

Jetzt mitmachen!

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