Habe die Optionen mal für den screensaver mit rein genommen.
Gibt es eigentlich eine default Zeit für den Screensaver in X?
softhddevice - Software VDPAU/VA-API/CPU Decoder und Ausgabe Plugin
- johns
- Geschlossen
-
-
Ansonsten gibts jetzt noch die Downmix Option im Setup. Damit sollten die Audio Probleme mit verschiedener ffmpeg/libav Versionen behoben sein.
Sehr gut...downmix funktioniert. Jetzt braucht man kein channel-mapping in der asound.conf mehr. Und die Umschaltzeiten sind beeindruckend
Das einzige was noch etwas stört, ist der Lautstärke-Unterschied zwischen Dolby 5.1 und Stereo (PCM und Dolby 2.0) durch den Downmix. Das war auch schon mit dem Alsa-Mapping so. Der 5.1-Ton ist einiges leiser und wenn die Privaten die Werbung dann in Stereo senden, bekommt meine bessere Hälfte jedes mal einen Herzinfarkt...
Wäre genial wenn man den Pegel für Dolby 5.1 per Option anheben könnte.
Danke und Gruß
-
gibt es eigentlich eine Auflistung mit allen Parametern die man dem Plugin mitgeben kann?
-
gibt es eigentlich eine Auflistung mit allen Parametern die man dem Plugin mitgeben kann?
-L ist nur notwendig wenn der Pfad nicht schon beim bauen korrekt gesetzt ist. Und er muss natürlich der eigenen Installaltion angepasst sein (also dahin zeigen wo die Plugins liegen).
cu
-
danke
-
die Meldung [softhddev] invalid PES video packet kommt nicht nur bei schlechtem Empfang.
Die Meldung kommt auch wenn man auf einen verschlüsseten Sender schaltet.
Habe das gerade noch mal getestet.
Habe die Meldung auf keinem meiner empfangbaren Senderm, aber sobald ich auf einen verschlüsselten Sender schalte ist die Meldung auch da.
Werde morgen früh noch mal schauen ob dann wirklich auch wieder das Bild wech ist.
Bin gerade auf der Arbeit und kann das nicht sehenEDIT :
Vielleicht kann das ja mal einer gegen checken.EDIT 2:
video: 14:39:21.707 -19 355 0/\ms 67 v-buf
Im WIki stehe das diese Meldung nicht häufiger als 1x die Minute kommen sollte, sonst hat mein ein Prob.
Egal was ich einstell die Meldung kommt immer sauber in 10sec Schritten. Wo kann ich nach dem Prob suchen ?
Aber ansonsten RESPEKT -
X11 stützt ab: Wie ist der X-Server weg? Oder nur die Ausgabe?Wenn ich das richtig verstanden habe, dann geht es allgemein um die Frage: Kann das Plugin ein Beenden des X-Servers überleben oder ist das prinzipbedingt unmöglich?
Also nicht unbedingt ein echter Crash sondern auch ein absichtliches "killall X".
-
genau um sowas etwas geht es. aber das backend sollte auch einen crash des frontends überleben. das wird aber nur gehen wenn man endlich frontend und backend trennt. das frontend ist ja teil des vdrs. habs schön häufig gehabt, dass das frontend weg kachelt mit einem segfault und dann der vdr neustarten muss. blöd halt bei aufnahmen.
-
Ich würde das umdrehen: Das Frontend muss so stabil sein, dass es schlicht nicht crasht. Ich tippe einfach mal, dass das gerade bei einem so einem schlanken Plugin wie softhddevice durchaus realistisch sein könnte. Je weniger Code, desto weniger Fehlerpotential.
Ein Segfault kann man z.B. in aller Regel recht gut debuggen. Wenn dir das öfter passiert, dann bau dir doch mal "gdb" in die runvdr um das nächste Mal ein Backtrace zu erzeugen.
-
Wenn ich das richtig verstanden habe, dann geht es allgemein um die Frage: Kann das Plugin ein Beenden des X-Servers überleben oder ist das prinzipbedingt unmöglich?
Also nicht unbedingt ein echter Crash sondern auch ein absichtliches "killall X".
Ich sehe keinerlei Probleme, daß das Plugin ein Beenden des X-Servers überlebt. Außer das dieser Teil mal geschrieben werden muß.
Das Einzige was passieren kann ist, daß ein Paar Resourcen verlohren gehen können.Nur schlechter Empfang kann zu Abstürzen führen, nur ist dies schwierig zu simulieren und meine Erfahrung zeigt, daß VDR selbst meist bei schlechten Empfang abstürtzt.
Johns
-
EDIT :
Vielleicht kann das ja mal einer gegen checken.EDIT 2:
video: 14:39:21.707 -19 355 0/\ms 67 v-buf
Im WIki stehe das diese Meldung nicht häufiger als 1x die Minute kommen sollte, sonst hat mein ein Prob.
Egal was ich einstell die Meldung kommt immer sauber in 10sec Schritten. Wo kann ich nach dem Prob suchen ?
Aber ansonsten RESPEKTDann ist dein CAM weg, nur wüsste ich wie mein Plugin dafür Verantwortlich ist.
Könnte sein das die Graphikkarte zulangsam ist oder Ton etwas zu schnell läuft.
Johns
-
Ich sehe keinerlei Probleme, daß das Plugin ein Beenden des X-Servers überlebt. Außer das dieser Teil mal geschrieben werden muß.
Das Einzige was passieren kann ist, daß ein Paar Resourcen verlohren gehen können.Das hört sich doch gut an. Generell sehe ich das so, dass man ab einem gewissen Zeitpunkt schrittweise auftretende Bugs mal genauer betrachten sollte. Wo möglich werde ich versuchen hier zu helfen.
In der Vergangenheit wurde viel damit befasst, wie man einen Crash ins Leere laufen lässt. Also klassisches "An den Symptomen rumdoktern". Besser wäre es, mal die Ursachen auszumachen. Gerade bei Intel ist die ganze Kette Open Source. Es müsste also machbar sein, die Fehler bis zur Ursache zurückzuverfolgen.
Zitat
Nur schlechter Empfang kann zu Abstürzen führen, nur ist dies schwierig zu simulieren und meine Erfahrung zeigt, daß VDR selbst meist bei schlechten Empfang abstürtzt.Kann man das wirklich nicht simulieren? Sollte doch in Hardware machbar sein. Eventuell Poti in die Sat-Leitung, um die Dämpfung kontrolliert ins unermessliche heben zu können?
Ein Crash (also Segmentation Fault oder ähnliche "Hämmer") würde ich hier als sehr unschön bezeichnen. Was ich kenne, ist, dass der VDR nach einiger Zeit ohne oder mit schlechtem Empfang den Watchdog auslöst. Damit kann man aber eigentlich gut leben, denn bei fehlendem Empfang werden Aufnahmen ohnehin nicht laufen. Der Versuch, hier über einen Treiber-Reload eventuell wieder einen stabilen Zustand zu erreichen, ist ja nicht verkehrt.
-
Kann man das wirklich nicht simulieren? Sollte doch in Hardware machbar sein. Eventuell Poti in die Sat-Leitung, um die Dämpfung kontrolliert ins unermessliche heben zu können?
Das geht einfacher, Du musst nur ein nasses Geschirrtuch über den LNB legen. Das wird auch beim einstellen der Satschüssel im Sommer gemacht um schlechtes Wetter zu simulieren.
-
Zum Programmieren ist dies nicht geeignet. Ich dachte mehr daran: per Zufall ein paar Bits zuverändern oder zulöschen.
Dies kann man mit Aufnahmen reproduzieren und so leichter die problematischen Stellen finden.Johns
-
Dann ist dein CAM weg, nur wüsste ich wie mein Plugin dafür Verantwortlich ist.
Könnte sein das die Graphikkarte zulangsam ist oder Ton etwas zu schnell läuft.
Johns
das mit den 10 Sekündlichen Logeinträgen hab ich hier auch, scheint normal mit der Version vom 17ten aus dem yavdr repoCodeFeb 22 13:58:30 CKone vdr: video: 1:21:42.230 +21 418 0/\ms 64 v-buf Feb 22 13:58:40 CKone vdr: video: 1:21:52.230 +21 466 0/\ms 71 v-buf Feb 22 13:58:50 CKone vdr: video: 1:22:02.230 +21 386 0/\ms 69 v-buf Feb 22 13:59:00 CKone vdr: video: 1:22:12.230 +21 434 0/\ms 71 v-buf Feb 22 13:59:10 CKone vdr: video: 1:22:22.230 +21 482 0/\ms 64 v-buf Feb 22 13:59:20 CKone vdr: video: 1:22:32.230 +21 402 0/\ms 69 v-buf Feb 22 13:59:30 CKone vdr: video: 1:22:42.230 +21 450 0/\ms 70 v-buf Feb 22 13:59:40 CKone vdr: video: 1:22:52.230 +21 370 0/\ms 68 v-buf Feb 22 13:59:50 CKone vdr: video: 1:23:02.230 +21 418 0/\ms 69 v-buf
Der Ton ist absolut lippensynchron da ich das mit dem avreceiver regle
Christian
-
Hallo Johns,
ich habe es seit gestern Dank ckone's Hilfe auch am laufen :). Funktioniert prima, weniger Load super Bild und Wahnsinns Umschalt-Zeiten
Abends hatte ich Ruckler, leichte Hänger und Artefakte, das ist alle paar Minuten für so 1-5 Sekunden aufgetreten, nach hin und her zappen lief es subjektiv betrachtet länger rund als wenn ich auf einem Kanal stehen geblieben bin.
Ich verwende die Version 89ca4420 vom 17. Nachmittags, ffmpeg 9.1 auf yavdr oneric Basis.
Währen den Rucklern das hier im Log:Code
Alles anzeigenFeb 21 21:30:20 vdr vdr: video: 2:12:27.012 +25 545 0/\ms 23 v-buf Feb 21 21:30:30 vdr vdr: video: 2:12:37.012 +25 465 0/\ms 19 v-buf Feb 21 21:30:40 vdr vdr: video: 2:12:47.012 +25 545 0/\ms 23 v-buf Feb 21 21:30:49 vdr vdr: video: display buffer empty, duping frame (1354/405686) 3 Feb 21 21:30:50 vdr vdr: video: display buffer empty, duping frame (1355/405726) 0 Feb 21 21:30:50 vdr vdr: [softhddev] invalid PES video packet Feb 21 21:30:50 vdr: last message repeated 13 times Feb 21 21:30:50 vdr vdr: video/vdpau: out of surfaces Feb 21 21:30:50 vdr vdr: video/vdpau: decoder rendering failed: An invalid handle value was provided. Feb 21 21:30:50 vdr vdr: video/vdpau: decoder rendering failed: An invalid handle value was provided. Feb 21 21:30:50 vdr vdr: video: 2:12:56.332 -314 69 0/\ms 11 v-buf Feb 21 21:30:50 vdr vdr: video: 2:12:56.352 -314 49 0/\ms 11 v-buf Feb 21 21:30:50 vdr vdr: video: dropping frame (93/405730) Feb 21 21:30:50 vdr vdr: codec: error audio data at 0 Feb 21 21:30:50 vdr vdr: audio/alsa: wait underrun error? Feb 21 21:30:50 vdr vdr: video/vdpau: decoder render too slow 96 ms Feb 21 21:30:50 vdr vdr: video: missed frame (105/405736) Feb 21 21:30:50 vdr vdr: video: 2:12:56.532 -600 160 0/\ms 13 v-buf Feb 21 21:30:50 vdr vdr: video: 2:12:56.552 -580 160 0/\ms 13 v-buf Feb 21 21:30:50 vdr vdr: video: dropping frame (94/405738) Feb 21 21:30:50 vdr vdr: video/vdpau: decoder render too slow 96 ms Feb 21 21:30:50 vdr vdr: video: 2:12:56.652 -480 160 0/\ms 13 v-buf ...... Feb 21 21:50:47 vdr vdr: video: 2:32:54.052 +196 396 0/\ms 36 v-buf Feb 21 21:50:47 vdr vdr: [1639] CAM 2: assigned to device 1 Feb 21 21:50:47 vdr vdr: [1639] switching to channel 32 Feb 21 21:50:47 vdr vdr: [1639] [softhddev]SetPlayMode: 0 Feb 21 21:50:47 vdr vdr: [1639] [softhddev]SetVideoDisplayFormat: 1 Feb 21 21:50:47 vdr vdr: video: 2:32:54.072 +176 356 0/\ms 38 v-buf Feb 21 21:50:47 vdr vdr: video: 2:32:54.072 +156 336 0/\ms 36 v-buf Feb 21 21:50:47 vdr vdr: video: 2:32:54.092 +136 296 0/\ms 36 v-buf Feb 21 21:50:47 vdr vdr: video: 2:32:54.092 +116 276 0/\ms 36 v-buf Feb 21 21:50:47 vdr vdr: [2250] TS buffer on device 2 thread ended (pid=1639, tid=2250) Feb 21 21:50:47 vdr vdr: [2249] buffer stats: 279180 (6%) used Feb 21 21:50:47 vdr vdr: [2249] receiver on device 2 thread ended (pid=1639, tid=2249) Feb 21 21:50:47 vdr vdr: video: 2:32:54.112 +96 236 0/\ms 36 v-buf Feb 21 21:50:47 vdr vdr: [1639] [softhddev]SetPlayMode: 1 Feb 21 21:50:47 vdr vdr: audio: not paused, check the code Feb 21 21:50:47 vdr vdr: [2252] receiver on device 2 thread started (pid=1639, tid=2252) Feb 21 21:50:47 vdr vdr: video: 2:32:54.112 +76 216 0/\ms 34 v-buf Feb 21 21:50:47 vdr vdr: video: 2:32:54.132 +56 176 0/\ms 34 v-buf Feb 21 21:50:47 vdr vdr: video: 2:32:54.152 +36 136 0/\ms 34 v-buf Feb 21 21:50:47 vdr vdr: audio/alsa: wait underrun error? Feb 21 21:50:47 vdr vdr: [2253] TS buffer on device 2 thread started (pid=1639, tid=2253) Feb 21 21:50:48 vdr vdr: [softhddev] invalid PES video packet Feb 21 21:50:48 vdr: last message repeated 17 times Feb 21 21:50:48 vdr vdr: video: display buffer empty, duping frame (1860/464372) 0 Feb 21 21:50:48 vdr vdr: [softhddev] invalid PES video packet Feb 21 21:50:49 vdr: last message repeated 4 times Feb 21 21:50:49 vdr vdr: audio/alsa: buffer size 6016, period size 1504 Feb 21 21:50:49 vdr vdr: audio/alsa: delay 450 ms Feb 21 21:50:50 vdr vdr: video: display buffer empty, duping frame (1938/464374) 23 Feb 21 21:50:50 vdr vdr: video: 2:41:40.189+1584 1326 0/\ms 23 v-buf Feb 21 21:50:50 vdr vdr: video: 2:41:40.189+1559 1302 0/\ms 19 v-buf Feb 21 21:50:50 vdr vdr: video: 2:41:40.189+1513 1255 0/\ms 18 v-buf Feb 21 21:50:50 vdr vdr: video: 2:41:40.189+1495 1398 0/\ms 17 v-buf Feb 21 21:50:50 vdr vdr: video: 2:41:40.209+1481 1364 0/\ms 15 v-buf
Hast du eine Idee wo es bei mir haken könnte?
Danke und Grüße,
Jörg -
"Dann ist dein CAM weg, nur wüsste ich wie mein Plugin dafür Verantwortlich ist."
Das Plugin ist nicht das Problem. Jetzt nochmal wenn ich auf einen Sender geschaltet habe den ich nicht im ABO habe, sagen wir mal Canal+ irgentwas.
Dann hat dein Plugin die Meldung mit den PES rausgeworfen und ist sofor abgestürzt, bzw das Bild allein ist "abgestürzt".
Das war mit dem Stand aus dem GIT von vor 2 Tagen.
Habe heute nacht den neusten Stand gezogen und da werden zwar auch die Meldungen gebracht führen aber nicht zum Verlust des Bildes. Somit hat sich das Problem erledigt.
Bin dann nocht mal zum alten Stand zurück gegangen und konnte den Fehler reproduzieren.Zu den Einträgen die alle 10 sec kommen kann ich nur sagen das alles syncron aussieht.
Umschaltzeiten sind schon der Hammer.
-
Abends hatte ich Ruckler, leichte Hänger und Artefakte, das ist alle paar Minuten für so 1-5 Sekunden aufgetreten, nach hin und her zappen lief es subjektiv betrachtet länger rund als wenn ich auf einem Kanal stehen geblieben bin.
Ich verwende die Version 89ca4420 vom 17. Nachmittags, ffmpeg 9.1 auf yavdr oneric Basis.
Währen den Rucklern das hier im Log:Die sollten nur ganz kurz nach dem Umschalten kommen und nicht wärend des Betriebs.
Trit es nur auf verschlüsselten Kanälen auf?
Das Plugin ist nicht das Problem. Jetzt nochmal wenn ich auf einen Sender geschaltet habe den ich nicht im ABO habe, sagen wir mal Canal+ irgentwas.
Dann hat dein Plugin die Meldung mit den PES rausgeworfen und ist sofor abgestürzt, bzw das Bild allein ist "abgestürzt".
Das war mit dem Stand aus dem GIT von vor 2 Tagen.
Habe heute nacht den neusten Stand gezogen und da werden zwar auch die Meldungen gebracht führen aber nicht zum Verlust des Bildes. Somit hat sich das Problem erledigt.
Wer schaltet den auf einen Kanal der nicht zuentschlüsseln geht ?
Welcher Kanal ist es den? Die C+ zeigen bei mir ein Standbild.Zitat
Bin dann nocht mal zum alten Stand zurück gegangen und konnte den Fehler reproduzieren.Zu den Einträgen die alle 10 sec kommen kann ich nur sagen das alles syncron aussieht.
Sorry, das ist ein Falscher Alarm, ich zeige die Meldungen alle 10s, also ist alles in Ordnung.
Werde es für die nächste Version auf die gewünschte Minute reduzieren.Johns
-
Wer mutig ist kann noch den neuen TS (Transportstream) Parser verwenden, der ist noch mal schneller.
Im Makefile -DUSE_TS_AUDIO auswählen. Dazu noch alle 216 in audio.c durch 116 ersetzen.Ansonsten gibts jetzt noch die Downmix Option im Setup. Damit sollten die Audio Probleme mit verschiedener ffmpeg/libav Versionen behoben sein.
Johns
Funktioniert hier perfekt, bis jetzt ohne Probleme. Diese Umschaltzeiten sind ja der reine Wahnsinn. Vielen Dank für Deine Arbeit.
-
Zitat von johns
Wer mutig ist kann noch den neuen TS (Transportstream) Parser verwenden, der ist noch mal schneller.
Im Makefile -DUSE_TS_AUDIO auswählen. Dazu noch alle 216 in audio.c durch 116 ersetzen.Hi,
wenn ich den neuen TS Parser verwende und die 216 in der audio.c durch 116 ersetze, habe ich alle paar Minuten einen kurzen Tonaussetzer, im Log habe ich dann folgendes:
CodeFeb 22 17:46:45 [vdr] audio/alsa: underrun error?_ Feb 22 17:47:16 [vdr] audio/alsa: wait underrun error?_
Das ganze auf Sat1HD, also mit dem bösen...falls das etwas ausmachen sollte.
Ich habe das jetzt mal wieder zurück genommen, jetzt scheinen die Audio Aussetzer weg zu sein...
Mit der aktuellen GIT Version habe ich die AV Debug Ausgaben jetzt übrigens ca. alle 1,2 Sekunden:
CodeFeb 22 17:59:10 [vdr] video: 25:37:46.116 -11 356 0/\ms 34 v-buf_ Feb 22 17:59:12 [vdr] video: 25:37:47.316 -11 436 0/\ms 36 v-buf_ Feb 22 17:59:13 [vdr] video: 25:37:48.516 -11 356 0/\ms 32 v-buf_ Feb 22 17:59:14 [vdr] video: 25:37:49.716 -11 436 0/\ms 29 v-buf_ Feb 22 17:59:15 [vdr] video: 25:37:50.916 -11 356 0/\ms 26 v-buf_ Feb 22 17:59:16 [vdr] video: 25:37:52.116 -11 436 0/\ms 29 v-buf_
Ciao Louis
Jetzt mitmachen!
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!