Jump to content

madVR Renderer in DVBViewer nutzen


Jackie78

Recommended Posts

Das soll trotzdem nicht sein, auch bei alter ATI GPU nicht. Es sei denn, daß der Treiber selbst hängen bleibt, aber dann hilft meistens Strg+Alt+Ent auch nicht.

 

Kannst Du vielleicht in der Problemsituation mal Strg+Alt+Shift+Pause/Break drücken, und dann ein paar Sekunden warten, bevor Du das ganze abschießt? Genial wäre, wenn Du dabei auch noch das aktuelle "*.map"-File vom DVBViewer im gleichen Ordner wie die DVBViewer.exe hättest! madVR sollte dann einen Freeze-Report auf dem Desktop erzeugen. Mit DVBViewer-Map-Datei (siehe Linker-Einstellungen in Delphi) zeigt der Freeze-Report auch an, was die DVBViewer-Threads alle gerade so treiben.

Link to comment

@nuts, ich meine, der DVBViewer würde den low latency Mode schon benutzen? Bin mir aber nicht sicher. Kannst Du daran sehen, ob sich im Ctrl+J OSD die "present queue" auf "irgendwas/2" ändert von z.B. "irgendwas/8". Im low latency mode reduziert madVR nämlich automatisch die Größe der Presentation Queue auf 2 Frames. Das gilt allerdings nur, wenn Du nicht "present several frames in advance" deaktiviert hast.

Link to comment
Kannst Du vielleicht in der Problemsituation mal Strg+Alt+Shift+Pause/Break drücken, und dann ein paar Sekunden warten, bevor Du das ganze abschießt?

 

Abschießen brauche ich nichts. Allein der Wechsel des Bildschirmmodus unter Windows 7 nach Str + Alt + Entf bringt die Sache in Ordnung. Ich kann den Auswahlbildschirm, der unter anderem den Task Manager anbietet, mit "Abbruch" verlassen, und dann läuft es weiter, als sei nichts gewesen. Ob Aero bzw. der DWM aktiv ist oder nicht, hat darauf keinen Einfluss.

 

Ich kann mich noch schwach daran erinnern, dass diese Spezial-Windows-Bildschirme (wie auch UAC oder der Sperrbildschirm) eine Device Lost bzw. eine D3D-Neuinitialisierung zur Folge haben. Bei den Arbeiten am DVBViewer-eigenen Custom EVR hatte ich das in allen Varianten durchprobiert, um zu testen, ob der Presenter es überlebt. Ich denke deshalb, der H264 <-> MPEG2 Wechsel bringt irgendwie die D3D-Exklusiv-Ausgabe bis zu einem D3D-Reset nachhaltig zum Erliegen. Böse einfrieren tut da nichts.

Link to comment

 

Abschießen brauche ich nichts. Allein der Wechsel des Bildschirmmodus unter Windows 7 nach Str + Alt + Entf bringt die Sache in Ordnung.

 

Kommt mir bekannt vor. Diesen Deadlock hatte ich auch schon und konnte ihn auf die gleiche Weise auflösen. Irgendwelche Maßnahmen in madVR haben es dann für mich gefixt (Mailverkehr mit madshi habe ich noch). Bei Griga passiert es scheinbar immer noch.

Link to comment

Hier mehr dazu. Scheint exakt dasselbe Problem zu sein. Auch da war ein Fomatwechsel involviert. Es war mit Dateien in einer Playliste bei mir reproduzierbar. madshi konnte es bei sich allerdings nicht reproduzieren. Ich jetzt auch nicht mehr. Irgendwo ist da noch was nicht sauber.

Link to comment

Bei mir hat das Problem mit 0.88.17 angefangen. In 0.89.4 wurde es dann für mich gefixt. Hier die abschließende Mail von madshi zu diesem Thema:

 

Meiner Meinung nach ist folgendes passiert: Ich hab in dem Moment, wo
DVBViewer IVideoInfo::put_Visible oder IVideoInfo::put_Owner
aufgerufen hat, schon damit angefangen, das Rendern zu initiieren.
Noch bevor überhaupt put_Visible/Owner zurück zum DVBViewer gekommen
ist. Ich *vermute*, daß es dabei irgendeinen Thread-Deadlock gab.

Stattdessen erzeuge ich jetzt in put_Visible/Owner einen Thread,
welcher dann das Rendern initiiert. Dadurch geht dann
put_Owner/Visible direkt zum DVBViewer zurück, der dann wahrscheinlich
gleich wieder in eine Message-Loop geht.

 

0.88.16 hatte das Problem noch nicht. Kannst du das bestätigen, Griga?

 

Ich konnte es aber nie so einfach reproduzieren. Deshalb hat das mit dem Log nicht geklappt, weil da zu viel Daten angefallen sind. Evtl. haben wir hier mehr Glück...

Link to comment
0.88.16 hatte das Problem noch nicht. Kannst du das bestätigen, Griga?

 

Ja.

 

Das Problem tritt auf, wenn sich MadVR im exklusiven Vollbild befindet und dann der Filtergraph abgeräumt wird, also auch bei der Umschaltung auf einen Radiosender. Irgendwie wird D3D in einem ungesunden Zustand hinterlassen.

Link to comment

 

Ja.

 

Das Problem tritt auf, wenn sich MadVR im exklusiven Vollbild befindet und dann der Filtergraph abgeräumt wird, also auch bei der Umschaltung auf einen Radiosender. Irgendwie wird D3D in einem ungesunden Zustand hinterlassen.

 

Ich würde das Problem gerne analysieren. Aber da ich das selbst nicht reproduzieren kann, bräuchte ich ein Debug-Log und einen Freeze-Report. Kannst Du die für mich machen?

Link to comment
Kannst Du vielleicht in der Problemsituation mal Strg+Alt+Shift+Pause/Break drücken, und dann ein paar Sekunden warten, bevor Du das ganze abschießt?

 

Ich glaube kaum, dass das was bringt, denn wenn ich z.B. auf Radio umschalte, ist MadVR ja schon längst weg vom Fenster.

 

Genial wäre, wenn Du dabei auch noch das aktuelle "*.map"-File vom DVBViewer im gleichen Ordner wie die DVBViewer.exe hättest!

 

Sagt mir nichts. Bei mir gibt es keine .map Datei.

 

Aber da ich das selbst nicht reproduzieren kann, bräuchte ich ein Debug-Log und einen Freeze-Report. Kannst Du die für mich machen?

 

Nein, da ich nicht weiß wie. Ich habe reichlich zu tun und möchte keine Zeit damit verbringen, danach zu suchen. Wenn du sowas möchtest, beschreibe es bitte instruktiver.

Link to comment

 

Ich glaube kaum, dass das was bringt, denn wenn ich z.B. auf Radio umschalte, ist MadVR ja schon längst weg vom Fenster.

 

Außer da bleibt irgendein Thread hängen und madVR wird gar nicht erst korrekt abgeräumt. Wird denn bei Strg+Alt+Shift+Pause/Break keine Datei auf dem Desktop erstellt? Ich war da auch erst skeptisch, zumal 4 Tasten zeitgleich meist keine so gute Idee darstellt...

 

 

Wenn du sowas möchtest, beschreibe es bitte instruktiver.

 

Im madVR Verzeichnis gibt es die "activate debug mode.bat". Die musst du ausführen. Anschließend loggt madVR in eine Datei auf dem Desktop. Diese wird sehr schnell sehr groß. Wenn du das Problem recht zeitnah reproduzieren kannst, ist das aber kein Problem. Textdateien lassen sich zum Glück gut zippen. Die Frage ist eher, wie sich madVR mit all dem Logging bei dir dann verhält...

 

Mit der "activate release mode.bat" kannst du das Logging dann wieder abschalten.

Link to comment

Thanks CiNcH.

 

Es ist immer schwer zu sagen, wann so ein Freeze-Report hilfreich ist oder nicht. Sollte aber nicht aufwendig sein, ihn zu erzeugen, und dann hab ich mehr Informationen zum Untersuchen, von daher hätte ich ihn schon gern, wenn möglich.

 

Zum Thema "map"-Datei: In den Delphi-Linker-Einstellungen gibt's eine Einstellung "Map file". Wenn Du das vor dem Compilieren vom DVBViewer auf "Detailed" setzt, erzeugt Delphi eine "map"-Datei im gleichen Ordner wie der DVBViewer.exe Datei. Zusätzlich sollten in den Delphi-Compiler-Einstellungen noch die Optionen "Debug information" and "Local symbols" aktiviert sein. In der Map-Datei sind dann alle Funktionsnamen und Zeilennummern vom DVBViewer drin. Der Freeze-Report von madVR kann diese "map"-Datei auswerten und zeigt so für alle Threads auch Callstacks innerhalb des DVBViewer-SourceCodes mit an. So kann man halt sehen, was im entsprechenden Zeitpunkt die ganzen Threads im DVBViewer so treiben. Das mag in diesem speziellen Fall hilfreich sein, oder auch nicht. Keine Ahnung, sollte aber nicht schaden...

 

Die "activate debug mode.bat" funktioniert normalerweise problemlos. Bei manchen Usern macht sie Probleme. In dem Fall einfach per Hand "madVR.ax" umbenennen nach "madVR [release].ax". Danach "madVR [debug].ax" umbenennen nach "madVR.ax". Das ist schon alles. Anschließend wird bei Verwendung von madVR automatisch auf dem Desktop eine Log-Datei erstellt.

 

(P.S: Die Compiler- und Linker-Einstellungen können so bleiben. Schadet nicht. Die Compiler-Debug-Optionen wirken sich nur auf die DCUs aus, nicht auf das EXE. Und die Map-Datei stört auch nicht.)

Link to comment
Mit der "activate release mode.bat" kannst du das Logging dann wieder abschalten.

 

Die bat gibt es hier nicht. Aber ein zweiter Aufruf von activate debug mode.bat schaltet den Debug-Modus auch aus. Man muss nur drauf kommen ;)

Link to comment

 

Die bat gibt es hier nicht. Aber ein zweiter Aufruf von activate debug mode.bat schaltet den Debug-Modus auch aus. Man muss nur drauf kommen ;)

 

Die "activate debug mode.bat" sollte sich eigentlich selbst umbenennen nach "activate release mode.bat".

 

 

http://www.DVBViewer.com/griga/madVR_log.zip

 

Der Ablauf war:

 

(1) Start DVBViewer mit Kika HD

(2) Wechsel ins exklusive Vollbild

(3) Wechsel auf RTL SD -> Bild bleib stehen, kein Bildschirm-Feedback mehr.

(4) Strg + Alt + Entf -> Abbruch -> RTL Bild läuft

(5) Wechsel in Fenstermodus, DVBViewer beendet.

 

Danke!

 

Hmmmm... Ich versuche gerade, die zeitliche Reihenfolge abzugleichen. Was ich hier sehen kann ist folgendes:

 

0 Sekunden: Playback 1080i50 h264, DXVA Decoding.

3 Sekunden: Wechsel in den Exclusive Mode.

7 Sekunden: madVR wird zerstört und neu erzeugt.

7 Sekunden: Pin-Connect zu 576i50 MPEG2, Software Decoding.

8 Sekunden: Wechsel in den Exclusive Mode.

8.2 Sekunden: Decoder schickt erstes Bild, Playback scheint zu laufen.

13 Sekunden: Exclusive Mode wird verlassen, Playback scheint weiter zu laufen.

15 Sekunden: Media Player Exit.

 

Kommt das soweit hin? Soweit ich das aus dem Log sehen kann, sieht aus Sicht von madVR alles so aus, als würde es klappen. Ich sage Direct3D, daß es Bilder auf den Bildschirm malen soll, und es kommt keine Fehlermeldung zurück. Scheinbar kommt bei Dir aber nur ein schwarzes Bild an? Da bin ich jetzt erstmal baff, und weiß nicht viel dazu zu sagen... :shocked:

Link to comment

Hört sich für mich alles sehr nach déjà-vu an...

 

Siehe Konversation zwischen mir und madshi ab hier.

 

 

Kommt das soweit hin? Soweit ich das aus dem Log sehen kann, sieht aus Sicht von madVR alles so aus, als würde es klappen. Ich sage Direct3D, daß es Bilder auf den Bildschirm malen soll, und es kommt keine Fehlermeldung zurück. Scheinbar kommt bei Dir aber nur ein schwarzes Bild an? Da bin ich jetzt erstmal baff, und weiß nicht viel dazu zu sagen... :shocked:

 

Bei mir war es immer entweder ein Schwarzbild oder ein Standbild vom letzen Kanal. Da es auch beim Umschalten auf Radio passiert, wird da beim Stoppen wohl irgendwas nicht sauber beendet. Es passiert wie gesagt erst ab 0.88.17. Aber evtl. auf Grund eines günstigeren Timings auch nur Zufall, dass es mit 0.88.16 nicht auftrat!? Ich hatte das Problem ab 0.89.4 wie gesagt nicht mehr beobachtet.

Link to comment

Bei Dir war es ein echter Deadlock, wenn ich mich richtig erinnere. Das scheint hier nicht der Fall zu sein, laut Log scheint alles einwandfrei zu klappen. Das mit dem Radio verstehe ich allerdings auch nicht...

Link to comment

Genau das gleiche Verhalten. Bild blieb komplett stehen und ich kam auch nicht mehr aus dem FSE heraus. Nur Alt + Strg + Entf hat den DVBViewer bzw. madVR wieder aus dem FSE geholt. Lies die verlinkten Beiträge auf Doom9.

Link to comment
Kommt das soweit hin? Soweit ich das aus dem Log sehen kann, sieht aus Sicht von madVR alles so aus, als würde es klappen.

 

Kommt hin. Klappt ja auch alles. Die Wiedergabe läuft hörbar. Ich habe den Ablauf unter Debugger-Kontrolle durchgeführt, um zu sehen, ob es irgendwo eine AV gibt. Nichts dergleichen. Der DVBViewer hängt auch nirgendwo fest. Auf dem Monitor habe ich jedoch nur ein Standbild des letzten Senders, und der FSE beendet sich offenbar nicht freiwillig. Könnte eventuell doch mit meiner Graka bzw. ihrem Treiber zusammenhängen... AMD bekleckert sich in der Hinsicht ja gerade nicht mit Ruhm.

Link to comment

 

Könnte eventuell doch mit meiner Graka bzw. ihrem Treiber zusammenhängen... AMD bekleckert sich in der Hinsicht ja gerade nicht mit Ruhm.

 

Glaube ich nicht mehr dran. Es ist exakt dasselbe Problem wie bei mir mit Intel HD 4000 Grafik. Hat auch mit 0.88.17 angefangen. Laut Mail-Verkehr mit madshi konnte ich mit einem automatisierten Hardcore-Zapping Test das Problem auch mit der 0.89.4 noch einmal reproduzieren. Für mich wurde es ab dieser Version scheinbar nur viel schwerer reproduzierbar. Ich finde die Sache mit dem Umschalten auf Radio besonders interessant. Da wird madVR ja nur noch gestoppt bzw. abgebaut und nicht wieder gestartet. Also muss da was hängen bleiben bzw. nicht sauber vollzogen werden.

Link to comment

Hab nochmal nachgelesen. CiNcH hat Recht, daß genau das gleiche Problem mit genau den gleichen Symptomen auch bei ihm aufgetreten war. Das hab ich für ihn gefixt gekriegt, aber erst nachdem wir es nach langem hin und her geschafft hatten, das auf meinem PC reproduzierbar zu machen. Da das nun bei ihm nicht mehr auftritt, und bei mir eh nicht, weiß ich nicht, ob da eine große Hoffnung besteht, daß wir dem auf die Schliche kommen... :(

 

Auf Verdacht ist hier eine Test-Build (einfach madVR.ax überschreiben/austauschen):

 

http://madshi.net/madVRgriga.rar

 

Wenn die nicht hilft, hab ich keine Ahnung, was ich machen könnte...

Link to comment

Bei dir haben wir es nie reproduziert bekommen.

 

Es würde ja schon helfen, wenn der DVBViewer im Stop/Pause Zustand weiterrendern lassen würde ;) . Dann würde es beim Umschalten nicht immer zum FSE > Windowed > FSE Wechsel kommen ;) .

Link to comment

Genau. Allerdings war kein größerer Umbau zwischen 0.88.16 und 0.88.17 für das Problem verantwortlich, wie es schien. Ich kann dir den Mailverlauf bei Bedarf nochmal zuschicken.

Link to comment

Ich weiß, welche Änderung im Quellcode es war, die das Problem für Dich behoben hatte, deshalb die Testbuild von vorhin, die diese Änderung noch einen Schritt weiter gegangen ist.

 

Also es sieht wie folgt aus: Meiner Meinung nach die einzige Möglichkeit, diesem Problem auf die Spur zu kommen, wäre wenn Griga bereit wäre, einige Testbuilds zu testen. Es wäre immer nur die "madVR.ax", die ausgetauscht werden müßte, und ich müßte nur wissen, ob das Problem weg oder da ist. Was meinst Du, Griga, wäre das ok für Dich? Ich weiß nicht, wie einfach das zu reproduzieren ist. Wenn's jedes Mal auftritt, sollte es ja nicht viel Zeit kosten...

Link to comment

Ist es normal und gewollt, dass die Vor- und Rückspulfunktionen DVBViewer-seitig deaktiviert sind, wenn madVR als Renderer selektiert ist? Ich kann nur noch durch eine Aufnahmen vor- und zurückspringen, aber nicht mehr spulen.

 

Ja, das ist Absicht, und zwar genau deshalb:

 

Und wird die Pausefunktion eventuell überdacht, wo ein falsch skaliertes Screenshot angezeigt wird?

 

Das Spulen findet im Pause-Zustand statt, in dem man mit MadVR halt nur diesen Notnagel-Screenshot zu sehen bekommt. Wenn ich im Code das Spulen mit MadVR zulasse und das OSD per Tweak deaktiviere, funktioniert es prächtig, wie ein Versuch ergab.

 

Ich werde Christian fragen. ob er Zeit hat, sich der Sache zu widmen.

Link to comment

 

Ein Haken bei Rendering -> General Settings -> Use a separate device for DXVA processing behebt das Problem. Ein Haken bei ...for presentation nicht.

 

Ob es so einfach ist, wage ich zu bezweifeln. Es ist einfach irgendwo ein Timing-Problem. Bei mir trat es nur sporadisch auf und jetzt gar nicht mehr wirklich, auch ohne diese Option.

 

Gänzlich ohne DXVA gibt es dann wahrscheinlich auch kein Problem?

Link to comment

Ein Haken bei Rendering -> General Settings -> Use a separate device for DXVA processing behebt das Problem. Ein Haken bei ...for presentation nicht.

 

Hmmmm... Das ist interessant! Allerdings gibt mir das keine Idee für einen Bugfix...

Link to comment

Der Notnagel-Screenshot funktioniert mit der genannten Einstellung nicht - gibt nur ein schwarzes Bild. Auch Screenshots mit der entsprechenden Funktion im TV/Radio-Menü (also wohl via IBasicVideo.GetCurrentImage) scheitern.

Link to comment

@nuts, ich meine, der DVBViewer würde den low latency Mode schon benutzen? Bin mir aber nicht sicher. Kannst Du daran sehen, ob sich im Ctrl+J OSD die "present queue" auf "irgendwas/2" ändert von z.B. "irgendwas/8". Im low latency mode reduziert madVR nämlich automatisch die Größe der Presentation Queue auf 2 Frames. Das gilt allerdings nur, wenn Du nicht "present several frames in advance" deaktiviert hast.

Hm ich kann das eigentlich nicht bestätigen. Vielleicht missverstehe ich die Funktion auch, aber sollte der DVBViewer beim zeichnen des OSD madVR mitteilen in den low latency Mode zu gehen? Verifizierbar ist der Modus dann über die present queue=2 und das solange bis das OSD des DVBViewers wieder ausgeblendet wird?

Link to comment

Oh, ich dachte. Ich hatte das mit dem Low-Latency-Mode mal dem Christian gemailt und er meinte, das würde auf den ersten Blick gesehen gut funktionieren. Von daher hatte ich gedacht, er hätte es schon implementiert.

 

Also das ist eigentlich ganz einfach: Der DVBViewer verwendet ja das API "IMadVROsdServices.OsdSetBitmap()". Da gibt's einen "flags"-Parameter. Dort kann der DVBViewer entweder "BITMAP_INFO_DISPLAY" oder "BITMAP_USER_INTERFACE" als Flag verwenden. Ersteres heißt, es handelt sich um ein reines Informations-Bitmap, welches keine "low latency" benötigt. Zweiteres Flag informiert madVR darüber, daß es sich um ein interaktives User-Interface-Bitmap handelt. Falls so ein Bitmap sichtbar ist, schaltet madVR dann automatisch in den "low latency" Mode, in dem das ganze OSD wesentlich schneller reagiert.

 

Einbau in DVBViewer würde wie folgt funktionieren: Bei jedem "OsdSetBitmap()"-Aufruf müßte kurz geguckt werden, ob für dieses Bitmap "low latency" sinnvoll ist oder nicht, und dann entsprechend die Flags gesetzt werden. Das ist schon alles.

 

Ob der "low latency" Mode aktiv ist sieht man im Ctrl+J Screen an der Größe der "present queue", die im low latency Mode auf 2 limitiert ist.

Edited by madshi
Link to comment
"BITMAP_INFO_DISPLAY" oder "BITMAP_USER_INTERFACE" als Flag

 

Die Flags sind noch nicht mal in der vom DVBViewer verwendeten mvrInterfaces.pas vorhanden. Ich habe die Unit jetzt erst mal aktualisiert.

 

Hinsichtlich des OSD hat Christian inzwischen die wesentlichen Anpassungen durchgeführt, so dass bei MadVR der Notnagel-Screenshot als OSD-Hintergrund im Pause-Zustand nicht mehr gebraucht wird und damit auch Spulen geht. Aber richtig durchgetestet ist es noch nicht, und zumindest beim Timeshift-Start gibt es noch Probleme.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...