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?

  • Du kannst mit GraphEdit oder GraphStudio manuell einen Filtergraphen erstellen (ohne Audio- bzw. Video-Renderer-Filter), das Ganze dann als GRF-Datei speichern und diese GRF-Datei dann statt des Videos per DirectShowSource laden. Somit gehst du 100%ig sicher, dass NUR die von dir gewünschten DirectShow-Filter verwendet werden. Siehe:


    http://avisynth.org/mediawiki/…wSource#Opening_GRF_files



    Ansonsten:
    FFMS2/FFVideoSource hatte wohl schon immer Probleme mit direkt darüber geladenen Transportstreams. Eventuell hilft es da, FFVideoSource den Haali DirectShow-MPEG-Parser verwenden zu lassen - siehe FFMS2-Manual zum Demuxer-String (logischerweise muss dafür der Haali MediaSplitter installiert sein):


    http://ffmpegsource.googlecode…k/doc/ffms2-avisynth.html


    Alternativ kann man auch die TS-Datei in Matroska umcontainern und die so erzeugte MKV-Datei per FFVideoSource laden.

    Who is General Failure and why is he reading my hard drive?


    He was trying to get in touch with Private Data but if it involves a Major Disaster I understand that the fault lies with General Protection.


    Furthermore, if you cannot reboot it may be because of a corrupt Colonel.

    2 Mal editiert, zuletzt von Tom Keller ()

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

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

  • FFMS2 ist frame-akkurat, wenn man sich auf einen Decoder-Thread beschränkt: (..., threads=1); das sollte man ohnehin, weil – bis zur offiziellen Entwarnung – immer noch das längst dokumentierte Risiko besteht, dass komplexere Videoformate falsch decodiert werden können.


    Mit Interlaced-AVC in Transport-Streams hat FFMS2 selbst bei installiertem Haali-Splitter Probleme, das ist seit Monaten bekannt und dokumentiert. Die Empfehlung ist immer, FFMS2 im Zweifel nur mit MKV-Dateien zu verwenden. Und eventuell nur mit einem Decoderthread.


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

  • 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?

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


    Ich glaube nicht, dass Donald Graft in dem Fall großartig was machen kann. Da ja LAV und CoreAVC (beide mit aktivierter CUDA-Unterstützung) laut deiner Angabe den selben Decoding-Fehler aufweisen, 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...

    Who is General Failure and why is he reading my hard drive?


    He was trying to get in touch with Private Data but if it involves a Major Disaster I understand that the fault lies with General Protection.


    Furthermore, if you cannot reboot it may be because of a corrupt Colonel.

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

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


    Darauf wollte ich eigentlich auch hinaus: eventuell hat der Transponderstream einen klitzekleinen Defekt oder der H.264-Echtzeitencoder der BBC hat da kurzfristig 'nen Fehler produziert - und darauf reagiert dann der Hardwaredecoder der Grafikkarte empfindlicher als die diversen Softwaredecoder.


    Hast du denn mal die Wiedergabe mit einem Decoder gegen getestet, bei dem die Decodierung über DXVA erfolgt? Ist ja: gleicher Hardwaredecoder... andere Schnittstelle. Wenn da der Fehler auch auftritt, macht das eine softwareseitige Lösung deutlich unwahrscheinlicher - falls nicht, besteht aber Hoffnung.

    Who is General Failure and why is he reading my hard drive?


    He was trying to get in touch with Private Data but if it involves a Major Disaster I understand that the fault lies with General Protection.


    Furthermore, if you cannot reboot it may be because of a corrupt Colonel.

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

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


    OK... das weckt zumindest die Hoffnung, dass da tatsächlich softwaretechnisch was zu machen wäre.


    Allerdings hat sich ja in dem von dir erstellten Doom9-Thread bislang noch leider niemand dazu geäußert. Wobei das fast schon zu erwarten war, da sich in dem entsprechenden Foren-Bereich ja kaum noch etwas tut (obwohl Donald Graft/neuron2 das Board regelmäßig zu besuchen scheint :( ).

    Who is General Failure and why is he reading my hard drive?


    He was trying to get in touch with Private Data but if it involves a Major Disaster I understand that the fault lies with General Protection.


    Furthermore, if you cannot reboot it may be because of a corrupt Colonel.