Um deinen Nachmittag zu retten, kann ich's schon mal bestätigen.
Zumindest Deinen Schnipsel bekomme ich hier trotz wilder Audio-Umschalterei nicht mehr zum Absturz.
Dann ist der 'Show-Stopper' wieder gestoppt 
Alex
Bitte um Hilfe beim Debuggen: Absturz beim Umschalten der Audio-Spur in PES
-
-
-
Und hiermit funktioniert jetzt auch das Resume bei PES-Aufnahmen wieder.
Auch das kann ich bestätigen ...
Alex
-
So, der erste Teil des Problems sollte mit beiliegendem Patch gelöst sein.
Nachdem in cDevice::PlayPesPacket() und cDevice::PlayTs() nur lesend auf availableTracks[current(Audio|Subtitle)Track].id zugegriffen wird und dieses Array immer an der gleichen Adresse liegt, sollte es hier auch ohne einen Lock auf mutexCurrentAudioTrack gehen. Bei intensiven Tests konnte ich zumindest keine Probleme mehr beobachten.Und hiermit funktioniert jetzt auch das Resume bei PES-Aufnahmen wieder.
Vorläufiges Testergebnis:
Bisher konnte ich keinen Deadlock und keinen Absturz mehr provozieren. Resume mit PES funktioniert.Die schlechte Nachricht ist, daß die Audio-Umschaltung mit der SD-FF schlecht ist. Bei der Umschaltung scheint die Wiedergabe zurückzuspringen, d.h. ich höre, was ich schon kurz zuvor gehört hatte, und das Bild bleibt kurz stehen.
Mit 1.7.38 hatte dies noch perfekt funktioniert, d.h. man konnte die Umschaltung i.d.R. weder hören noch sehen.Auch mit der HD-FF läuft es nicht optimal (neuester Treiber + Firmware 0.4.0):
Das Bild bleibt kurz stehen und der Ton ist kurz weg.Sollte man die Umschalt-Logik nicht besser in das Ausgabeplugin verfrachten?
CU
Oliver -
Zitat von UFO
Sollte man die Umschalt-Logik nicht besser in das Ausgabeplugin verfrachten?
Das hört sich nach einem guten Plan an.Selbst wenn man in Betracht zieht, dass z.B. bei remote xineliboutput-Clients der Netztraffic etwas ansteigt.
Ich denke, die Vorteile die eine Umschaltung "vor Ort" bringt, rechtfertigt den "geringen" overhead - Audiodaten sind ja jetzt nicht soo fettGruß Gero
-
Alles anzeigen
Die schlechte Nachricht ist, daß die Audio-Umschaltung mit der SD-FF schlecht ist. Bei der Umschaltung scheint die Wiedergabe zurückzuspringen, d.h. ich höre, was ich schon kurz zuvor gehört hatte, und das Bild bleibt kurz stehen.
Mit 1.7.38 hatte dies noch perfekt funktioniert, d.h. man konnte die Umschaltung i.d.R. weder hören noch sehen.Auch mit der HD-FF läuft es nicht optimal (neuester Treiber + Firmware 0.4.0):
Das Bild bleibt kurz stehen und der Ton ist kurz weg.Sollte man die Umschalt-Logik nicht besser in das Ausgabeplugin verfrachten?
Das Problem ist, daß zum Zeitpunkt der Umschaltung ja u.U. bereits jede Menge Audio-Daten im Puffer des Ausgabedevices sind.
Ohne dieses Goto() hat bei mir (TT S2-6400) der Ton nach dem Umschalten einige Zeit lang total gestottert, und oft waren Bild und Ton, wenn es sich denn endlich gefangen hatte, total asynchron.
Mit dem Goto() gibt es zwar einen kurzen Ruckler im Bild, da er ja auf den nächstgelegenen I-Frame springt (der kann vor oder nach dem aktuellen PTS liegen), aber die andere Tonspur ist sofort da und vollkommen synchron zum Bild.
Ein kurzer Ruckler ist mir ehrlich gesagt lieber als ein sekundenlang stotternder und dann womöglich noch asynchroner Ton.Klaus
-
Das Problem ist, daß zum Zeitpunkt der Umschaltung ja u.U. bereits jede Menge Audio-Daten im Puffer des Ausgabedevices sind.
Verstehe ich nicht so ganz. Bei der Umschaltung muß man doch nur (an einer PES-Paketgrenze) die Ausgabe der alten Spur stoppen und statt dessen die neue Spur senden. (Dazu - falls nötig - meinetwegen noch ein Resync-Signal an die Hardware.) Wieviel das Device gepuffert hat, spielt keine Rolle, da die Audiospuren untereinander praktisch synchron sind. Sonst hätte das früher doch nicht so gut funktioniert!
Afaics hat die Firmware der HD-FF da noch ein Problem...Zitat
Ohne dieses Goto() hat bei mir (TT S2-6400) der Ton nach dem Umschalten einige Zeit lang total gestottert, und oft waren Bild und Ton, wenn es sich denn endlich gefangen hatte, total asynchron.
Mit dem Goto() gibt es zwar einen kurzen Ruckler im Bild, da er ja auf den nächstgelegenen I-Frame springt (der kann vor oder nach dem aktuellen PTS liegen), aber die andere Tonspur ist sofort da und vollkommen synchron zum Bild.
Ein kurzer Ruckler ist mir ehrlich gesagt lieber als ein sekundenlang stotternder und dann womöglich noch asynchroner Ton.
Imho ist es der Job der Kombo Plugin+Treiber+Firmware, dieses Stottern in den Griff zu bekommen.CU
Oliver -
Die schlechte Nachricht ist, daß die Audio-Umschaltung mit der SD-FF schlecht ist. Bei der Umschaltung scheint die Wiedergabe zurückzuspringen, d.h. ich höre, was ich schon kurz zuvor gehört hatte, und das Bild bleibt kurz stehen.
Mit 1.7.38 hatte dies noch perfekt funktioniert, d.h. man konnte die Umschaltung i.d.R. weder hören noch sehen.Diesen Phänomen hab ich schon vor den Patches mit softhddevice festgestellt (1.7.39). Wie es in 1.7.38 war, weiss ich jetzt nicht. Dachte ja, es liegt am Plugin selbst-
-
Diesen Phänomen hab ich schon vor den Patches mit softhddevice festgestellt (1.7.39). Wie es in 1.7.38 war, weiss ich jetzt nicht. Dachte ja, es liegt am Plugin selbst-
Dies sollte man schnellstrmöglich überprüfen, schließlich geht es auf die 2.0 zu!Für die SD-FF verschwindet das Problem, wenn man den Code in cDvbPlayer::SetAudioTrack() deaktiviert.
Ceterum censeo, diese Art von Workarounds gehört in das Ausgabeplugin.Ohne diesen Code gibt es bei der HD-FF die von Klaus beschriebenen Probleme - interessanterweise nur bei TS-Aufnahmen! Bei PES-Aufnahmen funktioniert die Umschaltung zwischen Nicht-DD-Spuren genauso reibungslos wie bei der SD-FF. Bei TS-Aufnahmen oder wenn DD im Spiel ist, tritt das Stottern auf. Imho ist da noch irgendetwas faul.
CU
Oliver -
Dies sollte man schnellstrmöglich überprüfen, schließlich geht es auf die 2.0 zu!
Die 2.0 ist praktisch fertig, da werden höchstens noch ganz gravierende Bugs gefixt, für die es keinen Workaround gibt.
Ich warte noch bis 16:00 Uhr, ob sich jemand hierauf meldet, dann gebe ich die 1.7.40 frei.Zitat
Für die SD-FF verschwindet das Problem, wenn man den Code in cDvbPlayer::SetAudioTrack() deaktiviert.
Ceterum censeo, diese Art von Workarounds gehört in das Ausgabeplugin.Ohne diesen Code gibt es bei der HD-FF die von Klaus beschriebenen Probleme - interessanterweise nur bei TS-Aufnahmen! Bei PES-Aufnahmen funktioniert die Umschaltung zwischen Nicht-DD-Spuren genauso reibungslos wie bei der SD-FF. Bei TS-Aufnahmen oder wenn DD im Spiel ist, tritt das Stottern auf. Imho ist da noch irgendetwas faul.
Auch mit einer PES-Aufnahme ist das nicht ohne Probleme, wenn ich das Goto() nicht mache. Nach dem Umschalten zwischen der deutschen und englischen Tonspur dauert es drei bis vier Sekunden, bis man den anderen Ton hört. Bis dahin läuft noch die alte Tonspur weiter, weil anscheinend schon so viel im Ausgabedevice gepuffert ist. Und wenn ich zwischen "analogem" Ton und Dolby Digital umschalte dann kommt es, wie du auch bemerkt hast, zum Stottern.Mit dem Goto() gibt es beim Umschalten einen kurzen Ruckler (der je nach Material auch ziemlich unauffällig sein kann) und alles ist *sofort* OK.
Alles in allem erscheint mir also die momentane Lösung als die Beste.
Wer's nicht mag, kann es ja rauspatchen.Klaus
-
Jetzt mitmachen!
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!