DVBviewer 3.9.2.0 Directshowfilter

[gucky]

Guten Tag,

 

Ich habe in den letzten Tagen folgendes festgestellt:

 

Versuche ich mit dem DVBViewer, eingestellt auf Overlaymixer, Directshow Videofilter FFDSHOW und Audiofilter auch FFDSHOW ANIXE HD anzusehen, dann sehe ich max 10 Sekunden garnix und dann verabschiedet sich der Viewer mit nem Runtime Fehler. Das gleiche mit dem Cyberlink Directshow Filter funktioniert.

Wenn ich nun eine TS aufnahme von ANIXE mit dem Mediaplayer classic ansehe funktioniert das. Graphedit zeigt mir, dass FFDSHOW verwendet wird.

Das heisst für mich, dass es anscheinend am Zusammenspiel DVBViewer FFDShow liegt, dass sich der DVBViewerr immer verabschiedet, und nicht am Material.

Wenn ich den DVBViewer anhabe kann ich auch bis zum Absturz des Viewers sehen, dass Graphedit mir bestätigt ,dass in dem Augenblick FFDSHOW verwendet wird.

 

Sehe ich das richtig?

Kann mir jemand mitteilen, wie ich den DVBViewer zusammne mit FFDSHOW zum laufen bekomme?

 

grüße

 

Gucky

support.zip

[CiNcH]

Hmmm, ich dachte, dass die PAFF-Implementierung in ffdshow immer noch fehlerhaft sei und es deshalb mit Anixe HD nicht funktionieren kann. Bist du dir denn sicher, dass ffdshow in MPC als Dekoder, und nicht als PostProcessor verwendet wird?

[gucky]

Hallo,

 

Ich habe mal nen scrrenshot vom graphen des Mediaplayers gepostet.

 

grüße

 

gucky

[Griga]

Interessant wäre, welcher Demultiplexer verwendet wird, da dieser dem Decoder Daten anliefert. Kann man leider auf dem Screenshot nicht sehen. Und auch nicht, ob ffdshow als Postprocessor oder Decoder arbeitet. Bitte noch einmal, und dann richtig.

[CiNcH]

ffdshow arbeitet dem Screenshot nach zu urteilen tatsächlich als Dekoder (ffdshow heißt anders, wenn er als PostProcessor arbeitet).

 

Hier noch die Anixe HD Parameter:

pic_width_in_mbs_minus1 = 119 -----> HRes = 1920
pic_height_in_map_units_minus1 = 33 -----> VRes = 1088
frame_mbs_only_flag = 0 -----> interlaced
mb_adaptive_frame_field_flag = 0

 

Ist also immer noch PAFF. Dachte ffdshow hätte immer noch Probleme damit...

 

Bleibt noch die Frage nach dem Demuxer/Splitter offen. Ich nehme mal an der MPC interne!?

Edited April 15, 2008 by CiNcH

[CiNcH]

Glaub da muss ich selber wieder Hand anlegen. Interessiert das denn überhaupt jemanden? Sonst lass ich die Recherche bezüglich ffdshow und H.264..

Edited April 17, 2008 by CiNcH

[Griga]

Interessiert das denn überhaupt jemanden?

Ja, mich. Wenn ich die Zeit hätte, würde ich es selbst recherchieren, aber es liegt so viel anderes an - allein die Arbeit, die die Anpassungen und Fixes für Vista erfordern, sprengt jeden Rahmen. Bin also froh, wenn jemand anderes sich dahinterklemmt. Falls Fragen auftauchen, die Einblicke in DirectShow-Interna erfordern, kann ich assisitieren.

[Inxs]

Kann bestätigen, dass ffdshow als "Decoder" nicht mit DVBViewer zusammen funktioniert (bei HD-Sendern). An was es liegt, kann ich leider nicht sagen. DVBViewer stürzt nach kurzer Zeit ab. Kann denn ffdshow überhaupt h264 "Streams"!!! abspielen?

[gucky]

Guten Morgen,

 

Also ich bin im Moment, das ich tests mit verschiedenen Filtern anstelle:

 

FFDSHOW 1920

Powerdvd 7 ultra

Powerdvd 8 ultra

 

Wenn ich FFDSHOW beim Viewer einstelle dann bekomme ich nen "komisches" Standbild, ca 10 Sekunde nSpäter kommt der absturz des Viewer.

Wenn ich die Filter von Powerdvd nehme (Filter nur registriert, da eine komplett installation nach meiner Meinung im Moment keinen Unterschied macht) dann bekomme ich eine Bild auf z.b. Anixe, welches ca. 20-30 Sekunden flüssig läuft und dann wieder leicht ruckelt.

 

Wenn ich ein solches Bild aufnehme, dann gibt der Mediaplayer Classic mit dem FFDSHOW die Aufnahme ohne Probs wieder. Das gleiche File mit dem Powerdvd Filter im Mediaplayer scheint! auch zu laufen. Da bin ich mir aber noch nicht sicher.

 

Im Moment denke! ich das Problem soweit eingekreist zu haben (bei mir) dass ich vermute dass ich Aufnahmen im TS Format ohne Probleme machen kann. Auch wenn der Lifestream leicht ruckelt. Danach scheint das Ruckeln ein Problem in der Ecke des DVBViewers zu ein. Ist nur ne Vermutung.

 

Um angefragten Screenshots zu machen müsste mir mal jemand erklären wie ich den Demuxer im Graphedit sichtbar machen kann. Grob gesagt finde ich im Moment im Graphedit nichts was auf einen Demuxer deutet. Wenn ich ein TS File abspiele habe ich allerdings im Systemtray das Icon vom Haali Media splitter.

 

 

grüße

 

Gucky

[CiNcH]

Ich habe nun auch meine ersten Tests durch. Sowohl LiveTV als auch die Wiedergabe von aufgenommenem H.264 Material (Astra HD+ H.264 PAFF Interlaced) bringen den DVBViewer bei Verwendung von ffdshow zum Absturz. Das Problem liegt beim DVB Source Filter, wie Griga wahrscheinlich schon vermutet hat. Die Queued Video Buffer zählen hoch bis zum Absturz.

 

 

Ich habe auch schon Latenzzeit und Max Queued Audio drastisch erhöht. Dann hält der Filter etwas länger durch und man bekommt auch mal etwas bildähnliches zu sehen. Es kommt dann rasch zu einem Buffer Overflow im DVB Source Filter. Man beachte auch die großen Unterschiede zwischen Video- und Audio-PTS.

 

ffdshow scheint PAFF Material nun zu beherrschen, denn wenn ich für die Wiedergabe von Aufnahmen anstatt DVB Source den Haali Media Splitter verwende, funktioniert das problemlos.

Edited April 18, 2008 by CiNcH

[Griga]

Das Problem liegt beim DVB Source Filter

Kann man so nicht sagen. Den Runtime Error produziert jedenfalls ffdshow oder eine andere beteiligte Komponente (wegen Visual C). Schließlich funktionieren alle anderen mir bekannten H.264 Decoder mit dem DVBViewer Filter. Also muss das Problem bei ffdshow liegen

 

Sagen wir es einfach so: Irgendwas kommt nicht richtig zusammen.

 

denn wenn ich für die Wiedergabe von Aufnahmen anstatt DVB Source den Haali Media Splitter verwende, funktioniert das problemlos.

Fragt sich, was der anders macht. Könnte das Verbindungsformat betreffen, die übergebenen Videodaten oder irgendein kleines Detail... zudem gibt es einen wesentlichen grundsätzlichen Unterschied: Der DVBViewer Filter arbeitet im Push Mode - für Live unvermeidbar, wird der Einfachheit halber auch für Dateiwiedergabe verwendet. Ein "normaler" Filtergraph liest dagegen Dateien im Pull Mode.

 

Könnte also anstrengend werden, die Ursache zu finden. Bei Gelegenheit schaue ich es mir genauer an.

[CiNcH]

Der DVBViewer Filter arbeitet im Push Mode

 

Glaub halt, dass da noch mehr Filter Probleme mit haben. CoreAVC läuft bei mir auch nicht wirklich rund (müsste man aber auch erstmal genauer analysieren), CyberLink H.264 im reinen SW-Modus auch nicht. Wirklich gut funktionieren hier nur MainConcept und CyberLink+DXVA. Aber evtl. sind das wieder ganz andere Probleme.

Edited April 18, 2008 by CiNcH

[Griga]

Der Elecard Demultiplexer mit ffdshow als H.264 Decoder erzeugt keinen Crash, aber auch kein Video - Bild bleibt schwarz, ebenso mit dem Cyberlink Demultiplexer. Mit dem Haali Media Splitter funktioniert es jedoch. Er scheint mit ffdshow eine spezielle Verabredung zu haben. Um ihr auf die Spur zu kommen, wäre ein Spionage-Programm bzw. ein Zwischenfilter erforderlich, der einen kompletten Dump des Verbindungsformats und der übergebenen Daten erstellt.

[Griga]

Da haben wir ja schon etwas!

 

Igor "RadScorpion" Janos arbeitet an einem neuen Projekt namens GraphStudio, das GraphEdit nicht nur ersetzen, sondern deutlich übertreffen soll, indem es wesentlich mehr Informationen bietet. Hier hat es sich schon bewährt - siehe Screenshot. Es ist die um das Verbindungsformat ergänzte Eigenschaftsseite des Haali Media Splitters, wenn er ffdshow mit H.264 bedient. Seht ihr auch, was ich da sehe?

[CiNcH]

Seht ihr auch, was ich da sehe?

 

Werde ich mir am Abend nach der Arbeit anschauen. Vielleicht meldet sich ja bis dahin wer...

[Griga]

Was ich sehe, ist folgendes:

 

Der DVBViewer Filter benutzt die neutrale VideoInfo2-Struktur, um dem Decoder mitzuteilen, was auf ihn zukommt, denn für H.264 hat MS noch keine spezielle Datenstruktur vorgesehen. Der Haali Media Splitter "missbraucht" dagegen eine MPEG2VideoInfo-Struktur (d.h. ein erweitertes VideoInfo2) für den Zweck. Dies ermöglicht es, dem Decoder vorab über Profile und Level zu informieren, und zusätzlich einen Sequence Header anzuhängen, also einen besonders wichtigen Teil der zu erwartenden Videodaten. Zwar gibt es bei H.264 keinen klassischen MPEG2 Sequence Header, aber so etwas ähnliches - den Sequence Parameter Set. Um was es sich genau handelt, zeigt GraphStudio leider (noch) nicht an. Nur, dass es 39 Bytes sind.

 

Der DVBViewer Filter geht davon aus, dass der Decoder diesen Sequence Parameter Set (der auch Profile und Level verrät) selbst im Datenstrom auffindet und analysiert, was praktisch alle tun. Aber ffdshow kommt ohne diese Angaben offenbar nicht klar.

 

Jedenfalls ist das etwas zum Ausprobieren - wenn der DVBViewer Filter es in Zukunft ebenso machen soll, müssen natürlich bereits H.264-Daten empfangen bzw. gelesen worden sein, bevor der Filtergraph gebaut wird. Funktionieren kann es bei Live-Betrieb also nur, wenn Optionen -> DirectX -> Videoformat automatisch erkennen ein Häkchen hat, was leider die Umschaltzeiten spürbar verlängert

[Griga]

So, inzwischen habe ich den Hexdump in GraphStudio gefunden (View -> Text Information -> Level 5), und das klärt die Sache.

 

Zunächst: Cyberlink, Elecard und Haali-Demuxer/Splitter benutzen allesamt beim Verbinden mit dem Decoder die MPEG2VideoInfo-Struktur für H.264. Das scheint also gebräuchlich geworden zu sein, und es liegt deshab nahe, es für den DVBViewer Filter zu übernehmen.

 

Der Cyberlink-Demuxer notiert darin jedoch weder Profile noch Level, noch hängt er einen Sequence Header an. Klar, der CyberLink-Decoder braucht das auch nicht.

 

Der Elecard Demuxer notiert weder Profile noch Level, hängt aber einen originalen Sequence Parameter Set aus den Videodaten an, und noch ein paar zusätzliche Datenblöcke, die für den Decoder von Wert sein könnten (u.a. einen Picture Parameter Set). Das sieht so aus:

 

 8. [Elecard MPEG Demultiplexer]/(H264 (PID 767 @ Prog# 129)) -> [ffdshow Video Decoder]/(In)
Sequence Header:
	  00 00 00 01 67 4d 40 28  89 99 80 f0 08 8b 01 f7 
	  01 01 01 f0 00 00 03 00  10 00 00 03 03 29 40 00 
	  00 00 01 06 00 01 c0 80  00 00 00 01 06 06 01 a4 
	  80 00 00 00 01 68 ea 8f  20

 

Das konnte ich für den DVBViewer Filter ebenfalls einrichten, mitsamt Profile und Level-Information. Der Datenblock fällt sogar noch etwas gründlicher aus:

 

2. [DVB Source]/(H.264) -> [CyberLink H.264/AVC Decoder]/(Video In)
   Sequence Header:
	  00 00 00 01 67 4d 40 28  89 99 80 f0 08 8b 01 f7 
	  01 01 01 f0 00 00 03 00  10 00 00 03 03 29 40 00 
	  00 00 01 06 00 01 c0 80  00 00 00 01 06 06 01 a4 
	  80 00 00 00 01 68 ea 8f  20 00 00 00 01 06 01 01 
	  32 80

 

Beides funktioniert aber nicht mit ffdshow. Was macht also der Haali Media Splitter?

 

4. [Haali Media Splitter]/(Video) -> [ffdshow Video Decoder]/(In)
 Sequence Header:
	  00 1f 67 4d 40 28 89 99  80 f0 08 8b ff 00 01 00 
	  01 f7 01 01 01 f0 00 00  03 00 10 00 00 03 03 29 
	  40 00 04 68 ea 8f 20

 

Mit etwas Mühe findet man darin durch Vergleich die Daten eines Sequence Parameter Sets und eines Picture Parameter Sets wieder. Allerdings wurden die originalen NAL Unit Start Codes (Bytefolge 00 00 00 01) durch Zähler mit jeweils zwei Bytes ersetzt (00 1f = 31 = Länge der Sequence Parameter Daten, am Ende 00 04 = 4 = Länge der Picture Parameter Daten). Weiterhin finden sich mitten im Sequence Parameter Set vier Bytes, die ich nicht zuordnen kann (ff 00 01 00), und die nicht aus den Original-Videodaten stammen.

 

Damit funktioniert ffdshow. Zusätzlich gibt Haali als Videoformat nicht H.264, sondern AVC1 an. Auch das hat Auswirkungen.

 

Also eine ziemlich spezielle Kommunikation, die für den DVBViewer Filter so nicht akzeptabel ist, weil man nicht weiß, was sie sonstwo anrichtet. Auch der Haali Media Splitter hat übrigens seine Probleme. Er setzt ein bestimmtes Bit, das vom Decoder fordert, er solle Subpictures nach DVD-Art behandeln können. Damit tritt meine Version des CoreAVC H.264-Decoders in Streik.

 

Fazit: ffdshow sollte sich besser den üblichen Gepflogenheiten anpassen.

 

Das Problem liegt beim DVB Source Filter, wie Griga wahrscheinlich schon vermutet hat.

@Cinch: Damit hast du ein Beispiel geliefert, wie unzutreffend solche leichtfertigen Feststellungen sein können. Erst eine stundenlange Analyse in Verbindung mit erheblichem Fachwissen bringt ans Tageslicht, was wirklich los ist. Leider sind solche "Das liegt am DVBViewer"-Statements hier im Forum nur zu häufig zu finden.

 

Die Uneinheitlichkeit im Handling, die sich hier offenbart, zeigt, warum bei H.264 noch so viel im Argen liegt und nicht zuverlässig funktioniert. Das wird sich erst mit der Zeit regeln...

[gucky]

Guten Morgen,

 

Ich bin bei mir "meinen" Problemen nun auf folgendem Stand:

 

Es kommt folgende Software zum Einsatz:

 

XP SP2

DirectX 9.0c mit Patchlevel März 2008

DVBViewer 3.9.2.0

FFDShow 1943. Dabei ist der DVBViewer in der liste der Anwendungen welche FFDSHow nicht verwenden sollen.

 

Die Filtereinstellungne des Viewers greifen zumindest bei mir nicht.

Weiter habe ich vom Powerdvd7 die Directshow filter per Filecopy und anschliessendem register ins System gebracht. Der x264 ax Filter hat die Version 2.1.0.1108.

Als Grafikkarte kommt inzwischen eine ATI 2400 HD Pro zum Einsatz. Die bietet u.a. x264 unterstützung.

 

Als Treiber kommen die Catalyst 8.4 Treiber zum Einsatz.

 

Ich hatte bisher die Probleme, dass ich bim DVBViewer keine flüssige Wiedergabe von Anixe HD hinbekommen habe. Auch nicht mit mit den Powerdvd Filtern. Das VBS Script aus dem avsforum http://exdeus.home.comcast.net/~exdeus/ati-hd2x00/ hat erstmal auch nicht geholfen. Das Teil schaltete zwar die H264 Unterstützung bei der ATI frei, das bringt nur leider nichts solange man nicht auch unter Ansicht -> Filter -> Cyberlink -> erstens die BOB Einstellung beim deinterlacen erzwingen, und am besten auch noch dxva aktivieren. Die Deinterlacing Einstellungen allein des Cyberlink oder der ATI Treiber allein haben bei zumindest mir nichts gebracht. Der Fehler war dabei dass das Bild des Viewer nach einigen Sekunden Wedergabe anfing zu ruckln. Nun ist es flüssig.

Weiter musste ich im DVBViewer am besten auf den VMR9 Renderer schalten. Erst danach konnte ich mittel dem catylyst control center unter overboost nachweisen, dass die gpu in der ati genutzt wird. mit dem overlay mixer kam die gpu nicht über 3 prozent dauerhaft raus.

Was mich weiter interessieren würde ist die Frage nach der Funktion des Hakens VMRfix in den DirectX Einstellungen

Was ich nur noch nicht verstehe ist warum ich im DVBViewer extra dxva und bob aktivieren muss. Meiner Meinung nach sind das doch einstellungne, welche ich im Cyberlink (wie auch immer) Tätigen muss. Und nicht im Viewer.

 

grüße

 

GUcky