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

johns · 3. März 2012

Bevor ich es konfigurierbar mache:

Diff

diff --git a/video.c b/video.c
index 434fc1e..075cc8a 100644
--- a/video.c
+++ b/video.c
@@ -331,7 +331,7 @@ int VideoAudioDelay;
     /// Default zoom mode
 static VideoZoomModes Video4to3ZoomMode;
 
-static char VideoSoftStartSync = 1;    ///< soft start sync audio/video
+static char VideoSoftStartSync = 0;    ///< soft start sync audio/video
 
 static char Video60HzMode;             ///< handle 60hz displays

Alles anzeigen

Schaltet den Soften Sync nach dem Umschalten aus.
Das Bild sollte dann 1s einfrieren, eigentlich scharz werden, aber das will nicht immer.

Johns

zwick der agent · 3. März 2012

Gerade probiert und funktioniert.

Zitat

Das Bild sollte dann 1s einfrieren, eigentlich scharz werden, aber das will nicht immer.

Das stimmt aber wenn juckt das. Bei mir müßte das Bild eh nicht schwarz werden, ist doch angenehmer (aber wie immer Geschmack )?.

Grüße

steffen_b · 3. März 2012

Nur falls es ein Mißverständnis gab: schwarz werden muss von mir aus nichts, aber die Zeitlupe am Anfang nach dem umschalten stört mich, oder besser gesagt hatte ich kritisiert (Die ersten paar Frames langsam und dann pegelt es sich ein) - müsste ich wohl auch wieder verifizieren inzwischen

CKone · 4. März 2012

Zitat von steffen_b

Nur falls es ein Mißverständnis gab: schwarz werden muss von mir aus nichts, aber die Zeitlupe am Anfang nach dem umschalten stört mich, oder besser gesagt hatte ich kritisiert (Die ersten paar Frames langsam und dann pegelt es sich ein) - müsste ich wohl auch wieder verifizieren inzwischen

prinzipiell ja Steffen, im laufenden TV Betrieb. - du hast aber ohne dem schon das Phänomen das wenn du auf nen Kanal schaltest der kein Bild macht - z.B. einen Radiokanal - das letze Bild vor dem Umschalten auf dem Schirm verharrt...

ich aber nur ne Anmerkung, so wiklic stören tuts mich nicht...

Christian

iNOB · 4. März 2012

Ob das Bild schwarz wird oder nicht ist wohl Geschmacksache. Viel wichtiger ist, das der Ton des neuen Kanals erst dann kommt, wenn dessen Standbild/Video erscheint. Das passt jetzt auf den nicht verschlüsselten Kanälen ganz gut. Auf verschlüsselten HD+ Sendern (auf Sky funktionierts komischerweise) bekomme ich allerdings öfters beim Umschalten Tonhänger, die nach relativ kurzer Zeit <1s wieder verschwinden. Quasi wie einmaliges Stottern. Ich meine das dies bei früheren Versionen schon besser geklappt hat.

Gruß
iNOB

johns · 4. März 2012

Das passiert öfter wenn sich die PIDS ändern. Guck mal ob was im Log steht, wenn es passiert.
Ansonsten könnte es noch Underruns sein, weil Audiobuffer zu klein ist, sollte aber auch im Log notiert sein.

Johns

Copperhead · 4. März 2012

iNOB: Ich denke das ist von softhddevice unabhängig. Es werden zumindest bei mir beim Umschalten die PIDs geändert, obwohl gar keine Änderung notwenig wäre (PIDs gleich geblieben) Der Fehler ist wohl entweder im bösen Plugin oder direkt im VDR zu suchen.

3PO · 4. März 2012

Zitat von Copperhead

[...] Der Fehler ist wohl entweder im bösen Plugin oder direkt im VDR zu suchen.

Nun, dieses Phänomen tritt bei allen verschlüsselten Sendern, die via einem "bösen Plugin" entschlüsselt werden auf, egal ob nun als Ausgabe xine, xineliboutput, oder softhddevice verwendet wird.
Bei Ausgabe über den stremdev-server und vlc ist das nicht so.

Wo nun allerdings der Fehler zu suchen ist, weiss ich leider auch nicht.
Es wäre aber mal interessant, ob sich der Fehler auch zeigt, wenn via CI/CAM und Karte entschlüsselt wird?

rudirabbit · 4. März 2012

johns:

Zitat

Ich sehe im Log keinen Fehler, der den "decoder render too slow" produziert...
Sieht doch nach einen VDPAU Problem aus.

Danach habe ich heute gesucht, die render too slow bekomme ich nur auf 1080i Sendern, oft Stundenlang gar nicht - sehr sporadisch halt.
Der verwendete deinterlacer hat keine Auswirkung, habe es heute nach 3 Stunden auch mit Bob einmal gehabt.
Ich denke eher, das es an meiner xorg liegt, habe ein paar Optionen aktiviert - bist jetzt nichts von "render too slow" im Log zu sehen.
Bei einer GT 430 sollte sowas nicht passieren (Hardwaremässig gesehen) .

Ich teste mit der aktuellen Git Version, die läuft sauber und stabil - keine Soundprobleme mehr zu sehen. (und zu hören)
Hier ein Log gleich nach dem Umschalten, nach kurzer ein pendel Zeit schaut doch alles gut aus.

mfg. Rudi

johns · 4. März 2012

So ich habe mal endlich wieder eine stabile Version veröffentlicht.

Ich hoffe SUSP/RESU und DETA/ATTA hat nicht noch 100 Fehler.
Die Audio Drift Korrektur ist in dieser Version nicht automatisch angeschaltet.
Wer stabil will, sollte sie noch nicht verwenden. Alle anderen dürfen testen.

Johns

TomJoad · 5. März 2012

Zitat von Copperhead

Es werden zumindest bei mir beim Umschalten die PIDs geändert, obwohl gar keine Änderung notwenig wäre (PIDs gleich geblieben) Der Fehler ist wohl entweder im bösen Plugin oder direkt im VDR zu suchen.

Wen das stört, kann ja im vdr in channels.h beim #define CHANNELMOD_RETUNE den CHANNELMOD_CA rausnehmen. Ich habe noch nie einen negativen Effekt gesehen.

ciax · 5. März 2012

Zitat von johns

Stimmt aus dem start suspend, weckt nur ein SVDR resume.

ok, hab das nun ins startscript eingebaut und funktioniert! danke für die aufklärung.

ich bin jetzt mal auf

Revision 74a62e36 (also noch nicht auf der letzten stable bei der noch
Bug #890 (New): radio channels eingeflossen ist, soweit ich das mitbekomme ).

Makefile wie folgt:

Code

CONFIG := -DDEBUG
CONFIG += -DUSE_AUDIO_DRIFT_CORRECTION  # build new audio drift code
CONFIG += -DUSE_AC3_DRIFT_CORRECTION	# build new ac-3 drift code
CONFIG += -DAV_INFO -DAV_INFO_TIME=3000 # debug a/v sync
#CONFIG += -DHAVE_PTHREAD_NAME      	# supports new pthread_setname_np
#CONFIG += -DNO_TS_AUDIO            	# disable ts audio parser
#CONFIG += -DUSE_TS_VIDEO           	# build new ts video parser
CONFIG += $(shell pkg-config --exists vdpau && echo "-DUSE_VDPAU")
#CONFIG += $(shell pkg-config --exists libva && echo "-DUSE_VAAPI")
CONFIG += $(shell pkg-config --exists alsa && echo "-DUSE_ALSA")
#CONFIG += -DUSE_OSS

Alles anzeigen

sieht alles eigentlich ganz gut aus. ab und an kommen folgende einträge (ich saß nicht vor der glotze) - die alsa underruns kommen meistens beim zappen:

Code

egrep -i  "render too|underrun"
Mar  4 14:21:07 pvr vdr: audio/alsa: wait underrun error? 'Broken pipe'
Mar  4 14:30:59 pvr vdr: audio/alsa: wait underrun error? 'Broken pipe'
Mar  4 14:31:26 pvr vdr: audio/alsa: wait underrun error? 'Broken pipe'
Mar  4 15:27:24 pvr vdr: video/vdpau: decoder render too slow 2410 ms
Mar  4 15:27:27 pvr vdr: video/vdpau: decoder render too slow 2418 ms
Mar  4 15:27:27 pvr vdr: audio/alsa: wait underrun error? 'Broken pipe'
Mar  4 20:06:53 pvr vdr: audio/alsa: wait underrun error? 'Broken pipe'
Mar  4 20:08:13 pvr vdr: video/vdpau: decoder render too slow 49 ms
Mar  4 20:08:13 pvr vdr: video/vdpau: decoder render too slow 49 ms
Mar  4 20:10:34 pvr vdr: video/vdpau: decoder render too slow 134 ms
Mar  4 20:10:34 pvr vdr: video/vdpau: decoder render too slow 136 ms
Mar  4 20:11:23 pvr vdr: audio/alsa: wait underrun error? 'Broken pipe'
Mar  4 20:13:29 pvr vdr: video/vdpau: decoder render too slow 117 ms
Mar  4 20:13:29 pvr vdr: video/vdpau: decoder render too slow 116 ms
Mar  4 20:14:10 pvr vdr: video/vdpau: decoder render too slow 37 ms
Mar  4 20:15:57 pvr vdr: video/vdpau: decoder render too slow 109 ms
Mar  4 20:15:57 pvr vdr: video/vdpau: decoder render too slow 102 ms
Mar  4 20:18:21 pvr vdr: video/vdpau: decoder render too slow 138 ms
Mar  4 20:18:21 pvr vdr: video/vdpau: decoder render too slow 103 ms
Mar  4 20:20:40 pvr vdr: video/vdpau: decoder render too slow 129 ms
Mar  4 20:20:41 pvr vdr: video/vdpau: decoder render too slow 133 ms
Mar  4 20:23:02 pvr vdr: video/vdpau: decoder render too slow 117 ms
Mar  4 20:23:02 pvr vdr: video/vdpau: decoder render too slow 87 ms
Mar  4 20:27:45 pvr vdr: video/vdpau: decoder render too slow 226 ms
Mar  4 20:27:45 pvr vdr: video/vdpau: decoder render too slow 200 ms
Mar  4 20:29:57 pvr vdr: video/vdpau: decoder render too slow 121 ms
Mar  4 20:29:57 pvr vdr: video/vdpau: decoder render too slow 93 ms
Mar  4 20:32:26 pvr vdr: video/vdpau: decoder render too slow 122 ms
Mar  4 20:32:27 pvr vdr: video/vdpau: decoder render too slow 121 ms
Mar  4 20:33:45 pvr vdr: video/vdpau: decoder render too slow 53 ms
Mar  4 20:33:45 pvr vdr: video/vdpau: decoder render too slow 54 ms
Mar  4 20:34:58 pvr vdr: video/vdpau: decoder render too slow 62 ms
Mar  4 20:34:58 pvr vdr: video/vdpau: decoder render too slow 66 ms
Mar  4 20:37:05 pvr vdr: video/vdpau: decoder render too slow 104 ms
Mar  4 20:37:06 pvr vdr: video/vdpau: decoder render too slow 106 ms
Mar  4 20:39:14 pvr vdr: video/vdpau: decoder render too slow 124 ms
Mar  4 20:39:14 pvr vdr: video/vdpau: decoder render too slow 123 ms
Mar  4 20:42:04 pvr vdr: video/vdpau: decoder render too slow 142 ms
Mar  4 20:42:05 pvr vdr: video/vdpau: decoder render too slow 120 ms
Mar  4 20:44:10 pvr vdr: video/vdpau: decoder render too slow 122 ms
Mar  4 20:44:11 pvr vdr: video/vdpau: decoder render too slow 120 ms
Mar  4 20:46:29 pvr vdr: video/vdpau: decoder render too slow 133 ms
Mar  4 20:46:29 pvr vdr: video/vdpau: decoder render too slow 140 ms
Mar  4 20:48:15 pvr vdr: video/vdpau: decoder render too slow 87 ms
Mar  4 20:48:15 pvr vdr: video/vdpau: decoder render too slow 87 ms
Mar  4 20:48:58 pvr vdr: video/vdpau: decoder render too slow 41 ms
Mar  4 20:48:58 pvr vdr: video/vdpau: decoder render too slow 40 ms
Mar  4 20:51:15 pvr vdr: video/vdpau: decoder render too slow 80 ms
Mar  4 20:51:15 pvr vdr: video/vdpau: decoder render too slow 66 ms
Mar  4 20:51:51 pvr vdr: video/vdpau: decoder render too slow 36 ms
Mar  4 20:52:01 pvr vdr: video/vdpau: decoder render too slow 55 ms
Mar  4 20:53:34 pvr vdr: video/vdpau: decoder render too slow 90 ms
Mar  4 20:53:34 pvr vdr: video/vdpau: decoder render too slow 96 ms
Mar  4 20:55:30 pvr vdr: video/vdpau: decoder render too slow 102 ms
Mar  4 20:55:30 pvr vdr: video/vdpau: decoder render too slow 42 ms
Mar  4 21:00:48 pvr vdr: video/vdpau: decoder render too slow 240 ms
Mar  4 21:00:49 pvr vdr: video/vdpau: decoder render too slow 216 ms
Mar  4 21:02:28 pvr vdr: audio/alsa: wait underrun error? 'Broken pipe'
Mar  4 21:03:30 pvr vdr: audio/alsa: wait underrun error? 'Broken pipe'
Mar  4 21:03:35 pvr vdr: audio/alsa: wait underrun error? 'Broken pipe'
Mar  4 21:03:37 pvr vdr: audio/alsa: wait underrun error? 'Broken pipe'
Mar  4 21:04:04 pvr vdr: audio/alsa: wait underrun error? 'Broken pipe'
Mar  4 21:39:14 pvr vdr: audio/alsa: wait underrun error? 'Broken pipe'
Mar  4 21:39:57 pvr vdr: audio/alsa: wait underrun error? 'Broken pipe'
Mar  4 21:42:34 pvr vdr: audio/alsa: wait underrun error? 'Broken pipe'
Mar  4 21:42:49 pvr vdr: audio/alsa: wait underrun error? 'Broken pipe'
Mar  4 21:42:56 pvr vdr: audio/alsa: wait underrun error? 'Broken pipe'
Mar  4 21:43:22 pvr vdr: audio/alsa: wait underrun error? 'Broken pipe'
Mar  5 07:19:15 pvr vdr: audio/alsa: wait underrun error? 'Broken pipe'
Mar  5 07:36:42 pvr vdr: audio/alsa: wait underrun error? 'Broken pipe'

Alles anzeigen

zwischendurch wieder mal ein fettes Danke für die tolle arbeit - macht spaß zu testen/softhddevice einzusetzen!

gruß, ciax

ps: kann mir noch jemand einen tipp geben, wie ich dazu komme auch unter einer "mplayer"-wiedergabe die lautstärke regeln zu können?

//edit: die last/load scheint ein wenig gestiegen zu sein (liegt aber vermtl. an der log/DEBUG ausgabe ..)

johns · 5. März 2012

Solange die Underruns nach dem bzw. des Umschalten kommen, ist dies normal.
Wenn Umschalten zulange dauert, kann es passieren.

Was mir in deinem Log nicht gefällt, sind die vielen "decoder render too slow". Deine GT220 sollte ja genug Leistung haben.
Das würde ich mal prüfen woran es liegt. Neuster Treiber?

Beim mplayer ist die Lautstärkereglung die Tasten 9 und 0.

Johns

CKone · 5. März 2012

also mir war mit einer aktuellen Version und der passthrough audio correction aufgefallen, dass es während live und auch während der Wiedergabe zu seltenen kurzen Audiodrops deutlich <1 s kommt, aber man hört es halt. Das was es tun soll, also lipsync ist super, war aber auch schon ohne Korrektur sehr wirklich gut.

Alles jammern auf höchstem Niveau: das Plug hat jetzt schon den HD Vdr weit nach vorn gebracht!

Christian

johns · 5. März 2012

Dann schau mal bitte genau was die Audio Drift Korrektur macht.

Wenn der Ton zuschnell läuft, dann vergrößere ich die AC-3 Packete, wenn ich dies zuviel mache, dann gibts kleine Knackser (Aussetzer).
Ohne Korrektur ist irgendwann der Puffer aufgebraucht und es gibt eine kurze Pause, die Alternative wäre die Anfangspuffer zu erhöhen, aber irgendwann sind die immer leer.
Wenn der Ton zulangsam läuft. dann verkleiner ich die AC-3 Packete, wenn ich dies zuviel mache, dann erkennt mein Fernseher den Stream als PCM.
Ohne Korrektur sind dann irgendwann die Puffer voll und ich muß dann einen Sprung im Ton machen.
Und ich denke die Packete verkleinern/vergrößern ist nicht Standard konform.

Auch ohne Korrektur sollte das Bild syncron zum Ton laufen, da bin ich mir nur nicht sicher ob es jetzt auch funktioniert.

Johns

iNOB · 5. März 2012

Verwirrt gugg.... sollten die hier immer eingeschaltet werden? Oder nur eingeschaltet werden, falls es Probleme mit dem Sync gibt?

Code

CONFIG += -DUSE_AUDIO_DRIFT_CORRECTION  # build new audio drift code
CONFIG += -DUSE_AC3_DRIFT_CORRECTION	# build new ac-3 drift code

Gruß
iNOB

johns · 5. März 2012

Wenn du keinen Ärger mit der Frau/Familie willst, dann aus. (# vorne in der Zeile)
Wenn du testen willst, dann an. (# entfernen)

-DUSE_AUDIO_DRIFT_CORRECTION soll fest in die nächste Version.
-DUSE_AC3_DRIFT_CORRECTION bekommt wahrscheinlich eine Setup Opion zum einschalten.

Johns

ciax · 5. März 2012

Zitat von johns

Wenn du keinen Ärger mit der Frau/Familie willst, dann aus.

den hab ich schon -- also bleibt "#" hier bei mir weg.

rudirabbit · 5. März 2012

Hallo, Ich will das Thema "decoder render too slow" nochmals aufgreifen.

Die ich auch habe und versuche in den Griff zu bekommen.
Ich habe in den Device Section der xorg.conf dies eingefügt.

Code

Option     "RenderAccel"  "true"
Option     "TripleBuffer" "True"
Option     "RegistryDwords" "PowerMizerEnable=0x1; PerfLevelSrc=0x2222; PowerMizerDefault=0x1; PowerMizerDefaultAC=0x1"

Die letzte Zeile soll bewirken, das die Karte immer auf Vollgas läuft.
Seitdem sehe ich die "decoder render too slow" im TV Bild nicht mehr, also keine "Mircoruckler"
Im Log sind sie aber selten noch drin.

ciax : wie ich in deinen Logs sehe, hast du auch dieses Problem (und viel extremer als ich).
Was für einen Nvidia Treiber verwendest du ? Welche Linux Distrie ? (Oder ist deine Sig Aktuell)
Nur für Ursachenfoschung.

Nachtrag:
Dies gerade im Log, vor dem "decoder render too slow" war ein "empty video packet 115 bytes" hängt dies zusammen, bzw kann dies die Ursache sein ?

Code

5 19:10:01 linux-ugjv vdr: video: 20:14:06.537  +43  527   0/\ms  36 v-buf
Mar  5 19:11:01 linux-ugjv vdr: video: 20:15:06.537  +43  527   0/\ms  34 v-buf
Mar  5 19:12:01 linux-ugjv vdr: video: 20:16:06.537  +43  559   0/\ms  52 v-buf
Mar  5 19:13:01 linux-ugjv vdr: video: 20:17:06.537  +43  559   0/\ms  39 v-buf
Mar  5 19:13:07 linux-ugjv vdr: [softhddev] empty video packet 115 bytes
Mar  5 19:14:01 linux-ugjv vdr: video: 20:18:06.537  +43  559   0/\ms  52 v-buf
Mar  5 19:15:01 linux-ugjv vdr: video: 20:19:06.537  +43  527   0/\ms  48 v-buf
Mar  5 19:15:57 linux-ugjv vdr: video/vdpau: decoder render too slow 109 ms
Mar  5 19:15:57 linux-ugjv vdr: video: 20:20:03.077  -46  538   0/\ms  48 v-buf
Mar  5 19:15:57 linux-ugjv vdr: video: 20:20:03.097  -41  554   0/\ms  51 v-buf
Mar  5 19:15:57 linux-ugjv vdr: video: dropping frame (1/125523)

Alles anzeigen

Samael · 5. März 2012

Moin,

auch von meiner Seite erstmal vielen Dank für das tolle Plugin.

Da ich das bei mir zuhause produktiv einsetze und das auch bei den
von mir "Betreuten" tun möchte, ist mir soeben ein Problem aufgefallen.
Bei einem Anlernprozess für Fernbedienung / Tastatur,
die remote.conf ist also nicht vorhanden, bleibt der Bildschirm dunkel
und das Anlernen läuft irgendwann in den Timeout. Man müßte den Anlernprozess
quasi im Blindflug erledigen, wobei man eigentlich nicht mal weiß,
daß dieser gerade aktiv ist (Git-Stand 01.03.).

Zudem wird das Log bei Benutzung der Grab-Funktionalität mit

Code

Mar  5 19:08:31 vdr vdr: [2407] [softhddev]GrabImage: 513701316, 0, 100, 96x54
Mar  5 19:08:31 vdr vdr: softhddev: scaling unsupported

"zugemüllt", wobei zumindest hier mit VDPAU das Skaling wunderbar funktioniert.
johns: Magst du diese Ausgaben (zumindest für VDPAU) rausnehmen?

Samael

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

Jetzt mitmachen!

Teilen

Tags