Huffyuv + Avisynth + TMPGEnc = Ruckeln ?

  • Hi,

    ich habe mit VirtualDub eine Aufnahme gecaptured, 704x576 Pixel und Huffyuv. Wenn ich dieses AVI abspiele, ist alles ok.

    Um die Qualität etwas aufzuwerten, verwende ich folgendes Avisynth-Script:

    Das Video wird dann direkt mit TMPGEnc ins MPeg-Format verwandelt. (3500 MBit/s, VBR)

    Nach dieser Wandlung befinden sich im Video leichte Ruckler. Diese sind kaum zu erkennen, es sieht ungefähr so aus, als ob einzelne Frames verloren gegangen sind. Bewegungen hängen also mal oder springen, ähnlich wie bei Dropped Frames zu sehen.

    Testweise habe ich die AVI-Datei mal direkt mit TMPGEnc codiert, ohne Avisynth zu verwenden, und konnte diese Aussetzer nicht erkennen.

    Ist einer der obengenannten Filter problematisch? Ich könnte ja mal schrittweise jeden Filter einzeln testen, aber da wäre mir die Rechenzeit etwas hoch. Oder können sonst irgendwo bekannte Probleme auftreten ?

    Troubleshooter

  • AssumeTFF()
    Telecide()

    Das ist in deinem Falle falsch.
    Telecide(...) setzt für einen Inverse-Telecine-Process die phase-shifts zurück. Dahinter müsste eigentlich sodann ein decimate(...) gehören, der sodann das ganze NTSC (29.97fps) Ursprungsvideo auf originale 23.976fps bringt.

    Demnach musst du eben die oben genannten 2 Zeilen gegen einen reinen Deinterlacer ersetzen, da du kein inverse Telecine vornimmst.

    Dein Video ist doch den Zeilen oben nach 25fps interlaced PAL ? Davon gehe ich mal stark aus, wenn du mit 704x576 ge-captured hast.
    Ist dein Capture wirlich interlaced? Siehst du sogenannte "Kamm"-Artefakte bei bewegungen im Video? Prüfe das, denn wenn nicht, dann kannst du dir ein Deinterlacing sparen. - Sprich die beiden o.g. Lines löschen.

  • Hi,

    ja, das Bild ist 25 fps und PAL.

    Bin der Anleitung im Analog Capture Guide gefolgt, dort wird die Filterung mit Telecide vorgeschlagen. Da von diesem Filter (Decomb) in der neuen Version der order-Parameter nicht mehr unterstützt wird, bin ich der Anweisung im Readme gefolgt mit dem AssumeBFF.

    Das Video ist wirklich interlaced und eben BFF.

    Also funktioniert das Deinterlacen mit Telecide nur bei NTSC?

    Wie könnte man denn ansonsten deinterlacen? Gibts einen empfehlenswerten Filter?

    Könnten die Bildhänger mit dem falschen deinterlacen zusammenhängen?

    Troubleshooter

  • Dass das "inverse Telecide" (IVTC) nur für NTSC gilt (und da auch nur für Material, das mal im Original progressiv war), wurde mit Sicherheit so auffällig erklärt, dass man es nicht hätte übersehen können...

    Und welche Deinterlacer es für PAL gibt -- "jede Menge". Einer der fortgeschrittensten ist zur Zeit sicherlich "TDeInt" von tritical; bisher auch gern verwendet wurden z.B. KernelDeInt oder TomsMoComp, aber das ist schon fast Jahre her, dass es nichts besseres gab.

  • Zitat von LigH

    Einer der fortgeschrittensten ist zur Zeit sicherlich "TDeInt" von tritical;

    Den hatte ich auch mal benutzt, allerdings brauchte der unheimlich viel Rechenleistung. Sogar in VDub hats geruckelt. Ist das normal oder lag das an den Einstellungen?

    "Diejenigen, die grundlegende Freiheiten aufgeben würden, um geringe vorübergehende Sicherheit zu erkaufen, verdienen weder Freiheit noch Sicherheit."
    Benjamin Franklin (1706-1790)

    Meine Erfahrungen in der Open Source-Welt: blog.bugie.de

  • Telecide ist eigentlich nur ein Field-Matcher, d.h., er schaut nach, welche Fields zusammenpassen und setzt sie zu einem Frame zusammen.

    Und ob Deinterlacen wirklich ein Instrument ist, mit dem sich die Qualität steigern lässt, da habe ich doch arge Zweifel.

  • Zitat von Kika

    Telecide ist eigentlich nur ein Field-Matcher, d.h., er schaut nach, welche Fields zusammenpassen und setzt sie zu einem Frame zusammen.

    Aaaah, ich glaub in diesem Thread lerne ich einiges.

    Zitat von Kika

    Und ob Deinterlacen wirklich ein Instrument ist, mit dem sich die Qualität steigern lässt, da habe ich doch arge Zweifel.

    Hauptsache es wird progressive. :D

    "Diejenigen, die grundlegende Freiheiten aufgeben würden, um geringe vorübergehende Sicherheit zu erkaufen, verdienen weder Freiheit noch Sicherheit."
    Benjamin Franklin (1706-1790)

    Meine Erfahrungen in der Open Source-Welt: blog.bugie.de

  • Zitat von nexustheoriginal

    Aaaah, ich glaub in diesem Thread lerne ich einiges.

    Hauptsache es wird progressive. :D


    Werft den Purchen zu Poden ! ;)

    Echtes interlaced Material zu De-Interlacen ist ein Sakrileg.
    :eek: :eek:

    Gruss BergH

  • Hm, was heißt "echtes"?

    Ich rede momentan ausschließlich von TV-Caps.

    "Diejenigen, die grundlegende Freiheiten aufgeben würden, um geringe vorübergehende Sicherheit zu erkaufen, verdienen weder Freiheit noch Sicherheit."
    Benjamin Franklin (1706-1790)

    Meine Erfahrungen in der Open Source-Welt: blog.bugie.de

  • Zitat von nexustheoriginal

    Hm, was heißt "echtes"?


    Spielfilme werden i.d.R. progressiv ausgestrahlt (25p), aber interlaced aufgezeichnet. Da unterscheiden sich Top Field und Bottom Field nicht -> keine Kämme.
    So, und dann gibts echtes interlaced-Material, wo also 50 Halbbilder pro Sekunde gesendet und auch aufgezeichnet werden. Wenn Du die deinterlaced, siehts je nach Verfahren verwaschen, detailarm oder sonstwie aus (scharfi ist da allwissend, hatte ne Zeitlang mal einen schicken Avatar dazu). Aber es geht Dir immer Bewegungsdetail verloren.

    Zap

    "Wer grundlegende Freiheiten aufgibt, um vorübergehend ein wenig Sicherheit zu gewinnen, verdient weder Freiheit noch Sicherheit."
    Benjamin Franklin

    mein Rechenknecht

  • Ja, aber wir wissen ja gar nicht, ob's um einen Spielfilm oder sonstwas geht. Von daher ist das eh ein Ratespiel. Ist es Video mit echtem Interlacing, dann halte ich Deinterlacen, vor allem, wenn in MPEG2 encodiert werden soll, für reichlich kontraproduktiv. Höchstens wenn eine Quelle derartig Mieß ist, dass alles andere versagt, kann man das machen.

  • Ich denke wir sind hier etwas vom Thema abgeraten. Meine Fragen waren recht OT. Ich encode übrigens nicht nach MPEG2.

    "Diejenigen, die grundlegende Freiheiten aufgeben würden, um geringe vorübergehende Sicherheit zu erkaufen, verdienen weder Freiheit noch Sicherheit."
    Benjamin Franklin (1706-1790)

    Meine Erfahrungen in der Open Source-Welt: blog.bugie.de

  • Hi,

    um noch mal aufs Thema zurückzukommen: Ich hab mal den TDeInt() benutzt. Leider führt das im Ergebnis bei schnellen Bewegungen zu unschönen Effekten. Ich habe sowohl ein Ausgangsbild als auch das Resultat nach Benutzung von TDeInt angehangen.

    Dieser Effekt wird vom MPeg-Encoder noch verstärkt, so dass es im Endresultat doch etwas unschön aussieht.

    Hat jemand eine andere gute Idee, das zu deinterlacen ?

    Troubleshooter

Jetzt mitmachen!

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