Jump to content

HDMI AV Receiver DVB-Viewer Problem


Mentes

Recommended Posts

Hier noch ein haltloser Einfall, die kommen immer wenn ich aus Schachtelträumen aufwach:

Ich hab ja ein 64bit Win7, DVBV ist 32bit, sollte also nur mit 32bit dll's funktionieren?

 

C:\Windows\System32\audiokse.dll (s.o.) ist aber die 64bit vers, die 32bit vers. hält sich in C:\Windows\SysWOW64\audiokse.dll auf.

 

(nein, es ist nicht umgekehrt - die Ordnernamen System32 und SysWOW64 sind da irreführend).

 

Ob die Wirren des HDMI-Umschaltens-Handshakens DVBV kurz an die falsche dll geraten lassen - Absturz?

Edited by craig_s
Link to comment
Pfad des fehlerhaften Moduls: C:\Windows\System32\audiokse.dll

Das ist jedenfalls keine DLL, die der DVBViewer explizit lädt und verwendet. Sie kommt indirekt über irgendwelche Abhängigkeiten ins Spiel. Eine 32-Bit-Anwendung kann eine 64-Bit-DLL normalerweise nicht verwenden. Aber es gibt natürlich tiefere Schichten in Windows, die von 32 Bit nach 64 Bit übersetzen.

 

Aus Sicht des DVBViewers/DVBSource gibt es keinen Grund für einen Absturz, wenn bei Dateiwiedergabe der Audiorenderer plötzlich blockiert. Zwar ist es unschön, dass die Wiedergabe stehenbleibt, aber es ist keine programmtechnische Katastrophe.

 

Simulieren kann man den Fall, indem man mit dem DVBViewer/DVBSource eine Datei wiedergibt, dann in GraphStudio nach Connect To Remote Graph die Wiedergabe stoppt, den Audiorenderer einfach aus dem Graphen löscht (markieren und Entf) und auf Play klickt. Die Wiedergabe läuft im DVBViewer erwartungsgemäß nicht weiter, aber einen Absturz kann ich auf diese Weise nicht provozieren.

Link to comment

Ich denke craig_s meint den Fall wenn ständig "graph too late" Errors auflaufen, da keine Daten vom Decoder abgenommen werden (z.B. Bitstream LAV mit Pro ohne geeigneten Renderer).

Das legt schon die ganze Anwendung lahm und je nach System könnte ich mit auch einen Absturz vorstellen (bei mir auch noch nicht vorgekommen).

Link to comment

Die Absturzmeldung in Post #160 ist autentisch mit Uhrzeit bzw. frisch gewesen d.h. der Absturz war gerade erst passiert.

 

Ich poste hier selten etwas was ich nicht in dem Moment gerade tue, so auch alle Test-Schritte die in #160 festgehalten sind. Wenn ein Absturz kommt, dann leider direkt Bruchteile von Sekunden nach dem HDMI schalten. Ob da schon ein "Graph too late" oder bei Video "Buffer overflow" da war kann ich natürlich nicht sagen.

Link to comment
Ich denke craig_s meint den Fall wenn ständig "graph too late" Errors auflaufen, da keine Daten vom Decoder abgenommen werden

Kann er nicht gemeint haben. Meine Antwort in #162 bezieht sich auf #160, wo er schreibt:

 

..genau, bei Dateiwiedergabe heißt es mit der neuen GE + LAV entweder ..funktioniert nicht mehr:

Absturzbericht

Wie schon in #159 dargelegt, kann es nur bei Live-, jedoch nicht bei Dateiwiedergabe "Graph too late"-Fehler geben. Wenn bei Dateiwiedergabe der Audiozweig blockiert, hört der DVBViewer einfach auf, aus der Datei zu lesen. In #162 hatte ich beschrieben, wie man den Fall herbeiführt. Die Wiedergabe bleibt ohne Fehlerbehandlung stehen. Das liegt daran, dass DVBViewer & DVBViewer Filter entsprechend der Konsumrate des Audiorenderers aus der Datei lesen (bzw. gemäß der Einstellung "Max. Queued Audio - File eventuell etwas im Voraus). Ausnahme: Wenn der DVBViewer den DVBViewer Filter für reine Video-Wiedergabe ohne Audio konfiguriert. Dann ist die Konsumrate des Video Renderers entscheidend.

 

Beim Lesen aus einer Datei muss es ja eine Bremse geben, da es normalerweise viel schneller als die Wiedergabe abläuft. Deshalb liest der DVBViewer in einem separaten Thread, den der DVBViewer Filter blockiert, solange er sich im Pause- oder Run-Zustand befindet und sein Audio-Puffer mehr als die eingestellten Max Queued Audio enthält. Das Warten darauf, dass Audiodecoder/Renderer diese Daten abholen, ist keine Fehlerbedingung.

 

Möglich ist bei Dateiwiedergabe jedoch ein Buffer Overflow-Fehler. Zwei Ursachen sind denkbar:

 

1) Die beschriebene "Audio-Bremse" funktioniert nicht, z.B. weil Audio-Daten einfach unverarbeitet ins Nichts rauschen, und der DVBViewer mehr aus der Datei liest, als der Videozweig des Graphen verarbeiten kann.

 

2) Audio wird normal verarbeitet, aber der Videozweig des Filtergraphen blockiert.

 

Bei TV/Radio-Live-Wiedergabe herrschen dagegen ganz andere Verhältnisse - das ist bei Tests sauber zu trennen!!! Hierbei ist idealerweise die Rate der einreffenden Daten gleich der Renderer-Konsumrate. Es ist nicht nötig, künstlich zu bremsen - und auch gar nicht möglich, da die Sender nicht warten. Falls Daten schneller eintreffen, als sie verbraucht werden, handelt es sich eindeutig um eine Fehlerbedingung -> Graph too late. Dies wird ebenfalls anhand der gepufferten Audiodaten festgestellt, und die Auslöseschwelle lässt sich mit "Max Queued Audio - TV/Radio" einstellen, oder der Mechanismus auch ganz abschalten. Bitte in der DVBViewer Filter-Anleitung nachlesen - da ist das alles dokumentiert!!!

 

Den in #162 geschilderten Versuch - Entfernen des Audio Rendereres mit GraphStudio -> Connect to Remote Graph - kann man natürlich auch bei TV/Radio-Wiedergabe durchführen. Dann gibt es in Serie "Graph too late"-Fehler, weil die Audiodaten keinen Abnehmer finden. Oder man schaltet den Fehlermechanismus aus. Dann kann man auf der Eigenschaftsseite des DVBViewer Filters zuschauen, wie allmählich die Audiopuffer volllaufen. Es dauert einige Zeit, bis die Grenze von 8 MB erreicht ist und die Angelegenheit schließlich mit einem Buffer Overflow endet.

 

Der Graph too late-Mechanismus ist eigentlich dafür gedacht, den Fall "Wiedergabe läuft langsamer als der Sender sendet" zu behandeln. Standardmäßig richtet sich die Wiedergabe unter Windows nach der Uhr der Soundkarte (jeder Audiorenderer implementiert IReferenceClock), die natürlich nicht mit der Uhr irgendeines Senders synchronisiert ist. Bestenfalls läuft die Wiedergabe damit annähernd so schnell wie gesendet wird. Aber nach irgendeiner (eventuell langen) Zeit X wird es immer zu unakzeptablen Abweichungen kommen, die sich letztendlich in einem Buffer-Underrun (Wiedergabe zu schnell) oder Overflow (Wiedergabe zu langsam) äußern. Würde der DVBViewer Filter im letzteren Fall tatsächlich bis zum Buffer Overflow warten, ginge dem bereits eine längere Periode voraus, die man als ungewolltes "Timeshift aus dem RAM" bezeichnen könnte. Aufgrund der großen Menge gepufferter Daten (wie gesagt bis 8 MB) wäre die Wiedergabe gegenüber dem Sender mehrere Sekunden verzögert. Der Graph too late-Mechanismus sorgt für einen vorzeitigen Eingriff, wenn sich bei Live-Betrieb Daten stauen. Die Option "Use DVB Clock" des DVBViewer Filters ist ein Versuch, die Uhr des Senders (PCR) als Referenzuhr der Wiedergabe zu installieren, worauf der Audio Renderer sein Arbeitstempo anpassen muss, wobei sich in der Praxis allerdings die Frage stellt, inwieweit er dazu in der Lage ist - das ist eine Geschichte für sich...

 

"Klinische" Tests wie in #162 vorgeschlagen sind wichtig, um Instabilitäten und Verbesserungsmöglichkeiten im eigenen Code zu lokalisieren. Man lässt etwas unter definierten und reproduzierbaren Bedingungen schiefgehen, und untersucht dann, was passiert. Das Ein/Ausschalten von AVRs und Fernsehern schafft keine definierten Bedingungen. Das Verhalten der Treiber und sonstiger externer Komponenten ist zum größten Teil unbekannt. Was macht ein Audiorenderer, wenn das dazugehörige Gerät entfernt wird? Blockiert er? Lässt er die Daten unbearbeitet durchrauschen? Funktioniert seine Uhr noch? Haben die Treiberprogrammierer berücksichtigt, dass ein Gerät bei laufender Wiedergabe einfach verschwinden kann? Was stürzt eigentlich ab, wenn der DVBViewer dabei den Bach runtergeht? Weiß man alles nicht genau. Zu viele Unbekannte im Spiel, die Ergebnisse sind uneinheitlich - bei jedem anders, mal so und mal so - und man kommt über vage Vermutungen wie

 

Das legt schon die ganze Anwendung lahm und je nach System könnte ich mit auch einen Absturz vorstellen

nicht hinaus. Deshalb sehe ich auch keine Möglichkeit, aus den Reports in diesem Thread Maßnahmen abzuleiten, die eindeutig auf sinnvolle und allgemeingültige (!) Weise eine Verbesserung herbeiführen. Das Bild ist zu unklar und widersprüchlich. Zwar sind Maßnahmen denkbar, die in dem einen oder anderen Fall ein Unglück verhindern, aber dann heißt es prompt

 

wenn dann bitte optional, weil es ja auch Setups (z.B. meins) gibt die ohne "rebuild graph" und sonstige Eingriffe einwandfrei weiterlaufen.

Bei den "klinischen" Versuchen - Stop des Graphen mit GraphStudio, Entfernen des Audiorenderers, Start der Wiedergabe, DVBSource wird seine Audiodaten nicht mehr los - konnte ich bislang in keinem Fall eine Absturzneigung feststellen, weder unter XP noch unter Windows 7, weder bei Datei- noch bei Live-Wiedergabe. Allerdings simuliert dies den Fall "Audiogerät verschwindet während laufender Wiedergabe" nur unvollkommen, weil der Graph vor dem Entfernen des Audio Renderers gestoppt wird. Näher kommt man an die Realität nicht heran - der Filtergraph Manager erlaubt kein Entfernen von Filtern aus dem laufenden Graphen.

 

Insgesamt erweckt das DirectShow-System den Anschein, als wäre in seine Architektur nicht wirklich vorgesehen, dass etwas bei laufender Wiedergabe verschwindet. Und daran wird sich womöglich auch nichts mehr ändern, da Microsoft inzwischen Media Foundation favorisiert (insbesondere im Hinblick auf DRM) und DirectShow als Auslaufmodell ansieht.

 

Nichtsdestotrotz macht es Sinn, sich mit den hier behandelten Szenarien auseinanderzusetzen und das Verhalten des DVBViewers / DVBViewer Filters auf den Prüfstand zu stellen - zu Lernen gibt es dabei immer etwas. Es scheint jedoch eher einer der Fälle zu sein, in denen es Monate dauern kann, bis sich brauchbare Ansatzpunkte für Verbesserungen herauskristallisiert haben. Also ein Geduldsspiel. Wir werden sehen...

Link to comment

..gerade wieder ein Schachteltraum..;) KSCATEGORY - audiokse.dll

KS - ks, ob da ein Zusammenhang besteht?

 

Genau, bei Live-TV kommt beim HDMI schalten immer "Graph too late", bei Dateiwiedergabe immer "Buffer overflow", das wollt ich in #160 eigentlich sagen.

Einen Unterschied bezügl. Absturzhäufigkeit gibt es kaum, evl. Dateiwiedergabe etwas anfälliger.

 

Na ja, jetzt zu sagen - M$ baut was neues - damit ist auf ziemlich lange Sicht niemand geholfen, soo schnell wechseln die User erfahrungsgemäß gar nicht das Betriebssystem, nicht wahr. Das kann noch Jahre dauern. Und ob das neue dann wirklich "rettet"..? ;)

 

..alle diese Player verkraften die Umschaltung auf analoges Audio-Device ohne jeglichen Absturz mit AC3-Spur-ts mit Bild ohne Ton und natürlich kurzem Aussetzer(n) beim Schalten (vielmals probiert):

 

MPC-HC (mit LAV Splitter oder seinem eigenen: MPC MPEG Source)

VLC (in dem kenn ich mich nicht aus, Filter default/unbekannt)

PotPlayer (mit seinen eigenen Default-Splitter+Filtern),

PDVD 12 (Filter nicht einsehbar)

 

DVBViewer schafft es auch wenn er den LAV Splitter statt DVB-Source verwendet.

 

TotalMedia Theatre 5 (Filter nicht einsehbar):

nach HDMI Umschalten läuft Video eine weile Stumm, dann schaltet TMT5 es ab, bemerkt offenbar das da was nicht stimmt...

nach vielmaligem wiederholen, juhuu Ehrenrettung für DVBV?

 

Endlich Absturz TMT5:

Name der fehlerhaften Anwendung: uTotalMediaTheatre5.exe, Version: 5.3.1.146, Zeitstempel: 0x4faa09a3
Name des fehlerhaften Moduls: audiokse.dll, Version: 6.1.7600.16385, Zeitstempel: 0x4a5bdac9
Ausnahmecode: 0xc0000005
Fehleroffset: 0x00059cfa
ID des fehlerhaften Prozesses: 0x105c
Startzeit der fehlerhaften Anwendung: 0x01cdefca306f8091
Pfad der fehlerhaften Anwendung: F:\PROG\Multimedia\TotalMedia_Theatre\uTotalMediaTheatre5.exe
Pfad des fehlerhaften Moduls: C:\Windows\System32\audiokse.dll
Berichtskennung: 9559197b-5bbd-11e2-95eb-00269ebff168

 

..und wieder mal die audiokse.dll obwohl TMT5 ganz andere Filter verwendet.

 

 

Das Ein/Ausschalten von AVRs und Fernsehern schafft keine definierten Bedingungen. Das Verhalten der Treiber und sonstiger externer Komponenten ist zum größten Teil unbekannt. Was macht ein Audiorenderer, wenn das dazugehörige Gerät entfernt wird? Blockiert er? Lässt er die Daten unbearbeitet durchrauschen? Funktioniert seine Uhr noch? Haben die Treiberprogrammierer berücksichtigt, dass ein Gerät bei laufender Wiedergabe einfach verschwinden kann? Was stürzt eigentlich ab, wenn der DVBViewer dabei den Bach runtergeht? Weiß man alles nicht genau. Zu viele Unbekannte im Spiel, die Ergebnisse sind uneinheitlich - bei jedem anders, mal so und mal so..

Tja mein Herr, da musst du dir aber auch das gefallen lassen:

Das Ein/Ausschalten von AVRs und Fernsehern schafft mit DVBV häufige Absturz-Bedingungen. Nicht nur in diesem Thread.

 

Das Technologie-rädchen dreht sich halt immer weiter, immer mehr Leute benutzen seit Jahren HDMI und die Computer werden rapide immer kleiner (Notebooks usw.) da wäre es als Software Entwickler schon mal angebracht sich ein solches Gerät zuzulegen. Dann hätte es diese Disskussion hier vermutlich nie gegeben, oder? Das manche User es schaffen mit allerlei Tricks und 100mal Try&Error sich Auswege und Workarounds zu basteln ändert daran nichts.

Edited by craig_s
Link to comment

 

Das Technologie-rädchen dreht sich halt immer weiter, immer mehr Leute benutzen seit Jahren HDMI und die Computer werden rapide immer kleiner (Notebooks usw.) da wäre es als Software Entwickler schon mal angebracht sich ein solches Gerät zuzulegen.

 

Ich bin mal mutig und verweise nochmal auf meinen post #122 ;)

 

Die haben alle Probleme. PS3, Verstaerker, TV Geraete, Tunerboxen usw.. Warum liefert ein google auf "hdmi problem" wohl fast 28 Millionen Treffer ? Ja, das Raedchen dreht sich weiter aber gelegentlich unrund :P

Link to comment

kopf in den sand stecken

hat immerhin noch fast 1 million Treffer, obwohl deutsch..;)

 

Jaja :D Tu ich nicht, aber es liegt am HDMI selbst. Das wird dauern bis HDMI erwachsen wird und keine firmware/patch kann das anedern.

 

Nur ein paar Gedanken zum HDMI.

 

Wie kann ich zwei Monitore mit HDMI anschliessen ? Welche EDID ist die richtige ?

Warum schaltet die HDCP source alle Empfanger ab wenn nur einer einen "falschen/keinen" key liefert ?

Was passiert wenn ein device z.B Apple Produkt intelligent ist und HDCP scannt aber das erste gescannte Gerate nicht compliant ist ?

Was passiert ab 1.3 mit extended color wenn das TV es kann aber nicht der Player oder umgekehrt oder einer von 2 Monitoren nicht ?

Link to comment

Man kann sicher vieles bedenken, aber hier geht es lediglich um eine verbesserte stabilität des dvbviewers beim abschalten von über HDMI angeschlossenen geräten mit einem manierlichen fallback auf vorhandene entities ohne absturz. Selbst das scheint sehr kompex und vielschichtig ;)

Link to comment
Wie kann ich zwei Monitore mit HDMI anschliessen ? Welche EDID ist die richtige ?
Warum steht am Ende eines Fußballfeldes immer nur ein Tor und nicht zwei?

 

Warum schaltet die HDCP source alle Empfanger ab wenn nur einer einen "falschen/keinen" key liefert ?
Warum gehen in einer Bank immer alle Ausgänge zu obwohl nur ein Kassierer den Alarmknopf gedrückt hat?

 

Warum darf bei allem was die Großen machen haltlos das Unmögliche verlangt werden aber wenn man an den kleinen DVBViewer ne kleine Anforderung stellt kriegt man von allen Seiten eins aufn Deckel? :whistle:

Link to comment

Wie man den Vergleich zwischen anderen Playern systematisch durchtestet hatte ich schon in Post 44 umschrieben.

Diesbezüglich müssten die Betroffenen halt schon etwas genauer dokumentieren (Quelle, Filterkette, GE/Pro, Fehleranzeige sorucefilter usw.).

 

Ich selbst kann das nicht mittesten, weil es auch mit dem DVBViewer Pro/GE bei mir keine Probleme gibt. Mit etwas Glück bekomme ich nächste Woche eine andere Vorstufe und vielleicht kann ich damit etwas anderes feststellen ...

 

Ein abschließender Punkt:

aber dann heißt es prompt

 

wenn dann bitte optional, weil es ja auch Setups (z.B. meins) gibt die ohne "rebuild graph" und sonstige Eingriffe einwandfrei weiterlaufen.

Wohl zurecht oder nicht? Wenn die Ursache unbekannt ist?

Edited by nuts
Link to comment

 

 

Wie man den Vergleich zwischen anderen Playern systematisch durchtestet hatte ich schon in Post 44 umschrieben.
Diesbezüglich müssten die Betroffenen halt schon etwas genauer dokumentieren (Quelle, Filterkette, GE/Pro, Fehleranzeige sorucefilter usw.).

Ist in #167 geschehen.
Ich schaffe mit DVBViewer Pro und GE keinen Absturz mehr wenn bei Dateiwiedergabe der LAV-Splitter anstatt der DVB-Source verwendet wird. DVBV erholt sich schnell nach dem HDMI-Umschalten von Bitstreaming auf ein analoges Sound-Device und spielt das Video zuverlässig und flüssig und selbstverständlich tonlos ab.

Nach "Wiedergabe neu aufbauen" auch wieder mit Ton und 1a synchron (das auch mit DVB-Source sofern nicht abgestürzt), unter folgender Voraussetzung:

nur Pro:
Audio-Filter-Set_1 - zwei Audio Decoder installiert (AC3-Filter nicht oder deaktiviert):
LAV -> alles auf Bitstreaming angehakt (in DVBV für AC3 einstellen)
ffdshow -> unter "Ausgabe" kein Bitstreaming angehakt (in DVBV für mp2 einstellen und Merit etwas unterhalb LAV setzen)

Pro und GE
(GE erlaubt momentan keinen Decoderwechsel bei "Wiedergabe neu aufbauen"):
Audio-Filter-Set_2 - AC3-Filter 2.5b installiert (in DVBV für mp2 und AC3 einstellen)

mit diesen Voreinstellungen (sonst nichts verstellt):

post-73651-0-87087100-1357945413_thumb.png

post-73651-0-18591100-1357945448_thumb.png


Testaufbau
So entspricht der Testaufbau mit einem HTPC dem in einem Laptop:
Die Grafikkarte (AMD, Nvidia, Intel IGP) sollte über zwei Ausgänge verfügen: DVI und HDMI.

1) an DVI kommt ein DVI-Monitor ohne Lautsprecher (entspricht dem internen Moni eines Laptops).
2) an HDMI kommt der AVR + Fernseher
3) an den OnBoard-Sound des Mainboards Kopfhörer oder sonstige analoge Lautsprecher anschließen

Die Einrichtung zweier Bildschirme kann je nach Graka etwas vertrackt sein, am besten erst den DVI anschließen und wenn die Graka Zeit hatte die EDID in aller Ruhe zu lernen und das Bild steht, dann erst HDMI anschließen.
Sollten die Auflösungen noch nicht stimmen kann man das im Graka-Menü für jedes Display einstellen.

Video Decoder (DXVA) -> LAV oder PDVD10/12 oder MS DTV-DVD. Für Dateiwiedergabe ein ts-Recording von DVBV nehmen mit nur AC3-Tonspur.

- Normalerweise verbindet sich das 2. Display über "erweitert" und beide haben ein Bild.
- dann Tastenkombi Win+P drücken, damit kann man mittels "nur Projektor" (= HDMI = AVR+TV) und "Verbindung mit P. trennen" (= DVI-Moni + OnBoard-Sound) umschalten:

projektor.png

Mit diesem Aufbau kann man nun alle Tests machen, mit und ohne DVB-Source, Live-TV und Dateiwiedergabe.

Win+P erledigt die HDMI Trennung/Reconnect etwas "sauberer" als AVR per FB aus/anschalten. Man kann aber natürlich beides testen. Ebenso "Nur TV" aus/einschalten.
-> und vor allem - nur mit diesem Aufbau hört und sieht man was in DVBV oder sonstwo passiert wenn HDMI geschaltet wird !

Gestartet wird DVBV immer bei aktivem nur-HDMI (= AVR+TV). Beim Ausschalten der HDMI Geräte wird von Windows das ausgefallene Gerät sofort durch das ersetzt welches noch übrig geblieben ist, DVI-Monitor, OnBoard-Analog-Sound oder beides. Beim Einschalten der HDMI-Geräte schaltet Windows sofort wieder auf diese zurück.

Was beim nur DVI-Moni aus/einschalten passiert konnte ich noch nicht testen, ist aber auch für das Problem hier eigentlich nicht relevant. Edited by craig_s
Link to comment

p.s.

obiges #175 öfter überarbeitet, sorry ging nicht anders, sollte jetzt aber soweit fertig sein. nuts hoffentlich auch zufrieden? :P

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