softhddevice - Software VDPAU/VA-API/CPU Decoder und Ausgabe Plugin

Habe die Optionen mal für den screensaver mit rein genommen.
Gibt es eigentlich eine default Zeit für den Screensaver in X?

Zitat von johns

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?

Zitat von spacy

gibt es eigentlich eine Auflistung mit allen Parametern die man dem Plugin mitgeben kann?

vdr --help -L /usr/lib/vdr | more

-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

johns

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 sehen

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 RESPEKT

Zitat von johns

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.

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

Zitat von Mreimer

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.

Zitat von 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 repo

Feb 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:

Feb 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

johns

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

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.

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:

Feb 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:

Feb 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