Filter(kette) bei DirectShowSource() klar ermittel-/definierbar?

Hallo zusammen,

meine Doctor Who-Aufnahmen von BBC One HD treiben mich gerade ein wenig in den Wahnsinn... DGIndexNV (und scheinbar alles andere, was CUDA verwendet) produziert merkwürdige Artefakte, DGIndexDI kriege ich nicht ans Laufen, da ich DiAVC nicht aktiviert bekomme und noch auf Rückmeldung vom Entwickler warte, per FFVideoSource "zappelt" das Bild größtenteils hin und her...

// EDIT: DiAVC nebst DGIndexDI läuft jetzt - und produziert am Anfang der Ausgabe einige Frames Müll...

Sollte sich hierzu keine saubere Lösung finden lassen, bleibt wohl nur noch DirectShowSource() - hier würde ich dann wohl auf LAV setzen, das zeigt sich bisher problemlos.

Frage: Hat AviSynth selbst eine Möglichkeit, die Filterkette/den verwendeten Decoder-Filter anzuzeigen - z.B. als Overlay über dem Video? Kann ich direkt in AviSynth ggf. sogar selbst irgendwie festlegen, welcher DS-Filter verwendet werden soll - abseits von Herumgefummel mit Merits?

Oder muss ich mit den DS-Filter-Merits spielen (wenn ja, womit in Windows 7? Das Windows 7 Preferred DirectShow Filter Tweak Tool scheint mir recht rudimentär und funktioniert auch nicht hundertprozentig - zumindest kriege ich damit H.264 im MPC-HC nicht mehr mit ffdshow dekodiert, seit CoreAVC und LAV installiert sind), mir das Ganze in GraphEdit anschauen und mich darauf verlassen, dass DirectShowSource() es wohl genauso machen wird?

Zitat von Tom Keller

und diese GRF-Datei dann statt des Videos per DirectShowSource laden.

Oh, das war mir so noch nicht bekannt, danke!

An dieser Stelle anzumerken: Fürs Video-Decoding muss DirectShowSource() mit Audio=false aufgerufen werden:

DirectShowSource("test.grf", Audio=false)

da AviSynth beim Laden einer Filterkette nur einen Stream unterstützt und sonst einen Fehler wirft:

Zitat

DirectShowSource: Only 1 stream supported for .GRF files, one of Audio or Video must be disabled.

Wie sieht das eigentlich hier mit der "frame accuracy" aus? Sowohl ffMPEGSource2 als auch die DGIndex-Tools legen ja vorher immer einen Index an. Spielt das nur eine Rolle, falls ich später im AviSynth-Script bestimmte Frames auswähle, die dann möglicherweise nicht exakt mit der Frame-Nummer der Quelle übereinstimmen, oder kann es ebenso passieren, dass in der DirectShow-Kette zwischendurch Frames "verschluckt" werden und fehlen, ohne dass ich irgendwie versuche auf bestimmte Frames zuzugreifen und die Quelle einfach von 0 bis Ende durchlaufen lasse?

Zitat von Tom Keller

FFMS2/FFVideoSource hatte wohl schon immer Probleme mit direkt darüber geladenen Transportstreams.

Mittlerweile glaube die Ursache gefunden zu haben: Das Zappeln liegt an (offenbar zufällig) wechselnden "Frame Structs" (laut DGIndexNV) - diese wechseln bei meinen BBC One HD-Streams lustig zwischen "MBAFF" und "Fields (TFF)". Das erste Frame ist laut DGIndexNV MBAFF, dann folgen ca. 100 Frames TFF-Fields, anschließend wieder einige Frames MBAFF. Zwischendurch scheint minutenlang jedes Frame MBAFF zu sein, um für einige Sekunden von Field-Frames unterbrochen zu werden... Und genau hier scheint ffMPEGSource über die Field-Frames zu stolpern, die MBAFF-Frames sind OK.

Hierbei handelt es sich wohl größtenteils(!) um Fake-Interlacing, das Ausgangsmaterial ist ganz offensichtlich 25p, in der Bild-für-Bild-Ansicht in DGIndexNV sehe ich Vollbilder - abgesehen von den ersten paar Sekunden/GOPs, in denen offenbar "echtes" 1080i vorliegt, hier sehe deutlich Kämme, die durch Aktivierung des PureVideo-Deinterlacers verschwinden.

Auf jeden Fall scheint ffVideoSource hiermit nicht klarzukommen, unabhängig vom Container des Videostreams - ich habe auch probiert, den TS-Inhalt mit TSDoctor in ein MKV zu muxen und das zu öffnen. Das Resultat ist nach wie vor teilweise wildes "Gezappel", teilweise falsches Combing. Siehe Anhang: Dieses Frame ist eigentlich progressiv bzw. nur "fake interlaced" - schaue ich mir das in DGIndexNV mit deaktiviertem PureVideo-Deinterlacer an, sehe ich keinen einzigen Kamm.

Zitat von LigH

(..., threads=1)

Ja, sonst gibt's einen "Insane"-Fehler. Schon etwas merkwürdig, dass man den threads-Wert dann nicht gleich standardmäßig mit 1 initialisiert, wenn man weiß, dass hier aktuell Probleme auftreten.

Zitat von LigH

Wenn du DGDecNV nutzen kannst, tu das, bei solchem Material ist der deutlich zuverlässiger.

Ich hoffe, dass sich Donald Graft (oder jemand anderes mit CUDA-/CUVID-Erfahrung) mein Fehler-Beispiel im englischen Doom9 anschaut - zugegebenermaßen ist das in diesem speziellen Fall kein wirklich schlimmer Bug (sieht man kaum und taucht bisher offenbar nur in diesem einen speziellen Stream auf), aber es wäre schon blöd, wenn das nach stunden- oder tagelangen Encodes nochmal irgendwo (und dort möglicherweise schlimmer/öfter) passiert, ohne dass ich es unmittelbar bemerke.

Zitat von LigH

FFMS2 ist frame-akkurat

Ich begreife immer noch nicht so ganz, was das bedeutet bzw. wie genau sich das auswirkt:

Akkurat: Verarbeitende Schicht fordert von AviSynth Frame 42 an => exakt Frame 42 der Quelle wird geliefert.
Nicht akkurat: Verarbeitende Schicht fordert von AviSynth Frame 42 an => je nachdem, irgendwas in zeitlicher Nähe wird geliefert.

Soweit klar, aber wirkt sich das auch bei purem sequenziellem Zugriff aus, also wenn ohne spezifische Sprünge (also ein simples DirectShowSource() ohne Trim() oder ähnliches) dazwischen von Frame 0 bis zum letzten angefordert wird? Also kann aus 1,2,3,4,5 z.B. 1,3,4,7,8 oder 3,2,5,4,1 werden?

Zitat von Tom Keller

Ich glaube nicht, dass Donald Graft in dem Fall großartig was machen kann.

Naja, zumindest hat er soweit ich weiß einen guten Draht zur einigen Entwicklern bei nVidia.

Zitat von Tom Keller

ist davon auszugehen, dass sich der per CUVID angesprochene Hardwaredecoder da an irgendwas "verschluckt". Ich bezweifle daher irgendwie ein wenig, dass dem Problem softwareseitig beizukommen ist...

Ich denke nicht, dass es sich um ein Problem der Hardware an sich handelt, vermutlich eher irgendwas an der CUDA-/CUVID-API, die ja hier vermutlich verwendet wird. D.h. möglicherweise ließe sich das sogar mit einem Treiberupdate seitens nVidia beheben.

Aber erstmal abwarten - möglicherweise handelt es sich ja nichtmal um einen richtigen Bug. Genauso könnte es ja auch sein, dass der Encoder der BBC Müll produziert hat, CUVID hier strikt reagiert und die reinen Software-Encoder sich aus irgendeinem Grund etwas "nachlässiger" verhalten. Oder das Ganze tritt aufgrund irgendeiner exotischen Software-Hardware-Konstellation nur bei mir auf.

Zitat von Tom Keller

Hast du denn mal die Wiedergabe mit einem Decoder gegen getestet, bei dem die Decodierung über DXVA erfolgt?

Mit LAV tritt der Fehler bei "DXVA (copy-back)" auf, nicht jedoch bei "DXVA (native)".

CoreAVC mag den DXVA-Modus bei mir irgendwie generell nicht... sowohl MPC-HC als auch VLC hängen sich auf bzw. bleiben schwarz, wenn ich CoreAVC auf DXVA stelle.