Korrekte Nutzung von DirectShowSource für 1080i Material (TS-File mit 5.1 AC3)

  • Mangels nvidia Karte und großen Problemen mit ffmsIndex (siehe mein anderer Thread ;)) bin ich nun "gezwungen" DirectShowSource zu nutzen.
    Nur hätte ich dazu noch ein paar kleine Fragen und Problemchen.

    Wie gesagt, mein Quellmaterial ist eine Fernsehaufnahme in 1080i. Es soll angenommen werden, dass das Ursprungsmaterial Progressiv war und daher "25p" entspricht.

    1. Wie kann ich beeinflussen, welcher DirectShow Filter zum dekodieren genutzt wird? Nur über setzen des Systemweiten "Merrits" oder auch einfacher bzw. explizit für dieses eine AVS-File?

    2. Wie stark wirkt sich der verwendete Dekoder auf die Zieldatei aus. Vermutlich doch ziemlich deutlich? Dabei stellt sich auch mir folgende Frage. Ist es theoretisch möglich, dass bei DirectShowSource und entsprechend guten Decoder ein besseres Ergebnis entsteht, als bei Verwendung von z.B. DGIndexNV und letzteres wird vielleicht "nur" empfohlen wird, weil es z.B. stabiler oder schneller oder andere Vorteile hat?

    3. In Anlehnung an 1. Welcher Decoder ist den empfehlenswert (h264). Momentan hätte ich zur Auswahl^^: ffdshow, LAV Splitter, Cyberlink Video Decoder (vom aktuellen PDVD12) und den Win7 eigenen. Oder gibts noch andere, die noch besser wären? (kostenlos wär gut, aber kein muss)

    4. Wie gehe ich sicher, dass am Ende der Ton synchron ist? Meine Idee wär jetzt gewesen, mittels eac3to oder ähnlichen die AC3 Spur(en) aus dem TS zu ziehen und dann durch NeroAAC zu jagen. Gibt es da Risiken und Nebenwirkungen?

    5. Die DirectShowSource Parameter in bezug auf Framerate und co. MeGui's AVS-Creator hat mir folgendes erzeugt

    Code
    DirectShowSource("C:\Users\Username\Desktop\Shameless\Shameless - But At Last Came A Knock.ts", fps=25.000, audio=false, convertfps=true).AssumeFPS(25,1)


    Funktioniert auch und wär wohl auch in Ordnung. Dennoch würde mich interessieren, ob Teile davon unnötig oder gar nachteilig sind? (wie gesagt, ich gehe von "Pseudo 50i" aus)
    Ein Kommentar zur korrekten FPS Einstellung von echten 50i wär zusätzlich aber auch schön.

    Vielen Dank
    qupfer

  • 1.) Ja, über den systemweiten Merit. Avisynth kann da nicht eingreifen, es geht ja nicht nur um einen Filter. Bei Erstellungen der DirectShow-Kette sind ja i.d.R. viele verschieden Filter beteiligt (Source, Splitter, Audiodekoder, Videodekoder, ggf. SubtitleFilter, etc.pp.ad.inf.)
    Man kann auch in z.B. GraphEdit eine eigene Filterkette zusammenstellen, als *.grf speichern, und diesen Graphen dann in Avisynth laden. (Theoriewissen - hab' ich noch nie ausprobiert.)

    2.) Ein elementarer Bestandteil der AVC-Norm ist, dass jeder (standardkonforme) Decoder ein *identisches* Ergebnis liefern muss. Solange also keine "speziellen" Probleme auftauchen, sollte es bezüglich der reinen Dekodier-Qualität schnurz-piep-egal sein, welchen Decoder man verwendet.

  • Das klingt ja schonmal gut. Das mit den grf-Laden hatte ich probiert und geht leider nicht (oder ich bin zu blöd^^). Aber wenn Dekoder das gleiche Ergebnis liefern, dann ist ja eh alles in Butter.
    Beim googeln bin ich jetzt noch über DSS2 und DGAVCDecDI*1 gestolpert. Wären die Empfehlens"werter" als DSS?
    Und die Sache mit dem Ton ist noch offen und ob ich convertfps und ähnliches nutzen sollte. Trau mich da nicht so recht zu entscheiden *g

    *1 ich habe das doch richtig verstanden, wenn ich schon für DGindexNV gespendet habe, brauche ich dafür nichts zu bezahlen bzw. nur den DiAVC Dekoder? Wenn der Empfehlenswert wäre (in kombination mit DGavcDI) wär ich auch bereit da nochmal 10$ auszugeben


    Und gleich noch das nächste Problem. Wenn ich delogo Anwenden will, gibts eine Fehlermeldung
    http://d.pr/EpkX
    Mit google fand ich auch eine (funktionierende) Lösung: ConvertToYV12. Hat die Farbraumkonvertierung qualitative Nachteile oder kann ich das mir ruhigem Gewissen machen?

    4 Mal editiert, zuletzt von qupfer (24. März 2012 um 18:48)

  • Da MPEG-Video von Version 1 über 2 bis mindestens 4 in den verbreiteten Profilen ebenso planares YUV 4:2:0 verwendet wie auch YV12, sollte die "Reduktion" auf YV12 eigentlich gar keine sein. Ein AVC-Decoder sollte eigentlich auch YV12 direkt liefern können. Nur bei Interlaced-Video kann es da leichte Schwierigkeiten geben, weshalb es da durchaus nützlich sein kann, sich das Video von DirectShowSource mit dem Parameter 'pixel_type' zunächst als YUY2 liefern zu lassen und dann mit ConvertToYV12(interlaced=true) zu reduzieren, wenn es denn wirklich auch inhaltlich interlaced = combed ist. Ist es eigentlich progressiv, dann statt dessen ConvertToYV12(interlaced=false).

  • Nur bei Interlaced-Video kann es da leichte Schwierigkeiten geben, weshalb es da durchaus nützlich sein kann, sich das Video von DirectShowSource mit dem Parameter 'pixel_type' zunächst als YUY2 liefern zu lassen und dann mit ConvertToYV12(interlaced=true) zu reduzieren,

    Hüh? Das was vom Sender kommt ist 4:2:0, aka YV12(i). Warum sollte man den Dekoder anweisen, das empfangene YV12i zunächst als YUY2i auszugeben, um es dann manuell wieder zu YV12i zurückzukonvertieren? Da entsteht kein Vorteil, und es ist auch nicht irgendwie "sicherer" (eher im Gegenteil). Wenn man bei interlactem Inhalt Farbraumkonvertierungen irgendwie vermeiden kann, dann sollte man sie auch tunlichst vermeiden.

  • Ich bin mir nur nicht sicher, was DirectShowSource da exakt liefert.

    Wenn qupfer da ein Problem hatte, das er nur durch ConvertToYV12 gelöst werden konnte, dann hat wohl DSS etwas geliefert, was nicht YV12 war?

    Gut, eventuell wäre es generell zu empfehlen, bei DirectShowSource immer den Parameter pixel_type anzugeben. Eigentlich müsste DirectShowSource(..., pixel_type="YV12") wohl optimal sein, vorausgesetzt der Decoder liefert das korrekt.

  • und das scheint er nicht zu machen. Mit pxel_type="YV12" ist das gesamte Bild grün, außer der Bereich, der von delogo bearbeitet wird. Okay, der ist auch grün, aber man erkennt da das "Logo". Aber wenn ein convertToYV12 mein Bild nicht verschlechtert, kann ich damit sehr gut leben.

  • Nun ja, Ausnahmen sind Funktionen, die Transparenzmasken brauchen, also RGB32. Das kann man nicht ohne Nebenwirkungen in sämtliche anderen Formate wandeln, die keinen Alphakanal haben. Oder zumindest erst nach der Anwendung dieser Funktion.

    Aber wenn ich nur Resize und Delogo mache, habe ich nichts zu befürchten?

Jetzt mitmachen!

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