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

Hallo,

jetzt konnte ich das Plugin auch endlich mal richtig testen ...

Umgebung: AM2-System mit Nvidia GT520 von Asus, Ton über HDMI an AV-Receiver, Empfang über DVB-C, Alsa 1.0.24, Anthra FSE Skin, Kernel 3.0.1

Erster Eindruck: absolut geniales Plugin, warum gab es das nicht schon früher?

Punkt 1:
Ich hatte zunächst kein Bild, da die VDPAU-Unterstützung nicht kompiliert wurde. Lag daran, dass der NVIDIA-Installer scheinbar keine "vdpau.pc" anlegt, ließ sich mit dem Wissen dann aber fixen.

Punkt 2:
Mit den Parametern "-a hdmi:AES0=0x4" und "-p hdmi:AES0=0x6" und AC3-Passthrough aktiv funktioniert der Ton wunderbar, also genauso wie bei Xine.

Punkt 3:
Die Umschaltzeiten sind grandios!!! Allerdings ist der Übergang manchmal etwas holprig, vll. lässt sich das als Kür irgendwann nach 1.0 noch optimieren.

Punkt 4:
Ich starte VDR mit der runvdr-extreme, die auch den X-Server startet. Funktioniert einwandfrei mit dem Plugin!

Punkt 5:
Ich starte das Plugin mit "-g 1930x1090-5-5" um einen Overscan für die unschönen Ränder (links und rechts) zu erhalten, die auch bei HD-Sendern auftreten. Es wäre super, wenn man später den Overscan über das Setup-Menü einstellen könnte.
Wenn 4:3 Sendungen mit schwarzen Balken links und rechts dargestellt werden, gibt es beim Übergang zum schwarzen Bereich ebenfalls unschöne Ränder, kann man da noch was machen?

Punkt 6:
Die Umschaltung der Tonspur von Dolby Digital auf Stereo und vice versa in Aufnahmen funktioniert reibungslos und blitzschnell. -> Erstklassig! Xine braucht hier 10 Sekunden oder mehr für die Umschaltung.

Punkt 7:
Das Spulen funktioniert sowohl bei HD als auch SD im TS-Format einwandfrei, bei PES wird bei "3x" etwa im Zweisekundentakt gespult. Ist aber glaube ich bereits bekannt?

Punkt 8:
Bei einem ersten Test auf ZDF HD gab es mehrfach Ton- und Bildstörungen. Die einfachen Bildstörungen mit etwas Pixelsalat kenne ich auch von Xine, allerdings wurde bei softhddevice auch manchmal der Ton kurz unterbrochen, das war vorher nicht.

Hin und wieder "hagelt" es plötzlich "v-buf" Meldungen im Log, Bildstörungen sind aber nicht zu sehen. Wenn es ruckelt, gibt es i.d.R. ein "dropping frame".

Bei Xine hatte ich früher das Problem, dass bei zu geringem Buffer auf ARD HD oder ZDF HD das Bild für längere Zeit anfängt zu zappeln.
Dieses Zappeln tritt auch bei softhddevice auf, fängt sich aber innerhalb kürzester Zeit wieder.
Im Log kamen dann "missed frame", "dropping frame", "decoder render too slow" und "display buffer empty, duping frame" sowie haufenweise "v-buf"-Meldungen. Das genaue Log habe ich gerade verloren, werde es aber noch mal beobachten und nachreichen.
Ein Test mit den PoweMizer-Einstellungen folgt noch.

Punkt 9:
Wundern tut mich noch dies:

Mar 21 14:43:17 vdr vdr: video/vdpau: osd too big: unsupported

und dies

Mar 21 15:12:01 vdr vdr: video: dropping frame (408/107740)
Mar 21 15:12:01 vdr vdr: video/vdpau: out of surfaces
Mar 21 15:12:01 vdr vdr: video/vdpau: decoder rendering failed: An invalid handle value was provided.
Mar 21 15:12:01 vdr vdr: video: 22:39:16.749  +65  115   0/\ms  34 v-buf
Mar 21 15:12:01 vdr vdr: video/vdpau: release surface 0xffffffff, which is not in use
Mar 21 15:12:01 vdr vdr: video: 22:39:16.789  +65  171   0/\ms  39 v-buf
Mar 21 15:12:02 vdr vdr: video/vdpau: can't render mixer: An invalid handle value was provided.

CafeDelMar

Zitat von Samael

Moin,

ich habe da aktuell noch ein ganz anderes Problem:
Die folgenden Zeilen aus softhddevice.cpp

Code

1549	    // check if user is inactive, automatic enter suspend mode
1550	    if (SuspendMode == NOT_SUSPENDED && ShutdownHandler.IsUserInactive()) {
1551	        // don't overwrite already suspended suspend mode
1552	        cControl::Launch(new cSoftHdControl);
1553	        cControl::Attach();
1554	        Suspend(ConfigSuspendClose, ConfigSuspendClose, ConfigSuspendX11);
1555	        SuspendMode = SUSPEND_NORMAL;
1556	    }

verhindern bei mir ein Runterfahren des VDRs mittels vdrshutdown-Skript.
Der VDR beginnt ganz normal 5 Minuten vor dem Abschalten mit der Anzeige
"VDR wird in x:xx Minuten abgeschaltet". 3 Minuten vorher bleibt das Bild stehen,
der Zähler läuft aber weiter bis er irgendwann bei 0:00 angelangt ist. Die Anzeige
verschwindet nicht und im Log entstehen weiter Einträge. Das Shutdown-Skript
wird nicht aufgerufen. Erst wenn ich den o.a. Block auskommentiere erhalte ich
das bekannte Shutdownverhalten.
Im Plugin stehen beide Suspendoptionen im Setup auf "nein".
Bin ich der Einzige mit diesem Verhalten oder mache ich noch irgendwo einen Gedankenfehler?

Gruß, Samael

Alles anzeigen

Schau mal hier rein: softhddevice und yavdr 0.4 - hat das jemand am laufen?
Post 6

Zitat von Asta

Schau mal hier rein: softhddevice und yavdr 0.4 - hat das jemand am laufen?
Post 6

Danke, aber das hab ich doch schon in Post 1347 für geklärt erklärt.

Ich frag mich bloß immer, warum allgemeine Dinge zu VDR, Plugins etc. in yavdr-Unterforen
gefragt und geklärt werden. SCNR: Das wird langsam zur Plage.

Gruß Samael

Sorry, habe ich überlesen.

Zitat von Asta

Sorry, habe ich überlesen.

Ach Quatsch, du brauchst dich doch nicht für eine Hilfestellung zu entschuldigen. Ich hab zu danken.

Und ich wollte auch nicht unfreundlich wirken, sondern nur mitteilen, daß das Problem für mich

mit Ausklammern des if-Blocks gelöst ist.

Gruß, Samael

Zitat

Ja neue Version läuft schon, aber muß noch ausführlich getestet werden.

Wenn du es im GIT einspielst, kann ich das gerne mit mehreren SD-Aufnahmen in PES (ARD, RTL, Sky, ...) mal testen und ein Feedback geben.

Zitat

Sind das Empfangsstörungen? Da ich mit möglichst kleinen Audiopuffer arbeite, ergeben diese auch sofortige Tonstörungen.

Das klingt mir danach, daß deine Audiokarte ziemlich aus dem Takt läuft. Versuche mal mit Audiodrift Korrektur.

Empfangsstörungen kann ich nicht ausschließen, obwohl das bei DVB-C eigentlich ja nicht vorkommen dürfte. In jedem Fall kann ich daran dann zumindest vorerst nichts ändern, wäre also klasse, wenn Dein Plugin auch damit zurecht kommen könnte.

Das zappelige Bild kenne ich aber auch von anderen VDRs. Nur unter Xine haben eben ausschließlich höhere Buffer geholfen, Dein Plugin fängt sich hingegen dann innerhalb Sekunden von selbst wieder. Schön ist das Ganze allerdings nicht. Ich versuche mal ein Log von so einer Situation zu bekommen.

Bislang hatte ich nur "USE_AC3_DRIFT_CORRECTION" aktiv, werde das "USE_AUDIO_DRIFT_CORRECTION" mal mit dazu nehmen.

Zitat

Den Trick mit größerem Videobild habe sich selbst empfohlen, aber OSD Löschen klappt nur mit 1920x1080.

Von Dir habe ich das auch. Das heißt also, dass die Fehlermeldungen mit "... handle ..." davon kommen? Dann sollte ich das wohl wieder abschalten.
Für wann ist denn ein richtiger Overscan ohne diesen Trick geplant?

Zitat

Wenn Video aus dem Tritt kommt, Klötzchen oder Pufferüberläufe, dann kommt ffmpeg mit den Referenzframes durcheinander.

Und was kann man dagegen machen?

Zitat

Für oben und unten gibts bereits Einstellung. Für links + rechts darf jemand gerne einen Patch schreiben, ansonsten wenn es die Zeit erlaubt.

Ich würde ja gerne mit Patches helfen, ich steige aber gerade erst in die Plugin-Programmierung ein und so etwas hier ist mir leider mehr als fremd.

CafeDelMar

Hi,
Wenn ich die Logs von CafeDelMar ansehe, er hat schon bei 720p Sendern "decoder render too slow" in Verbindung mit sichtbarem Bildruckeln (mit einer GT 520)
Die "decoder render too slow" habe ich bei 720p Sendern nie - Vor allem bei HD+ bei Sky HD seltsamerweise viel weniger. (mit einer GT 430)

Die bessere Graka macht hier vermutlich den Unterschied aus.
Oder macht das Softwareproblem nicht mehr so sichtbar.
Die PowerMizer-Einstellungen habe ich schon optimiert, ich wollte die Karte auch schon leicht übertakten - Der aktuelle NVidia Treiber scheint dies zu Ignorieren.

Ich sehe die "decoder render too slow" immer noch als Hauptproblem an - vor allem dann wenn's sichtbar ruckelt.
Die Feinheiten der Audiowiedergabe können später verbessert werden, wobei ich Audiomässig wenig Probleme habe. (z.b. Mute Funktioniert einwandfrei. via HDMI oder Soundkarte des Rechners egal)
Wenn die Audio Ausgabe via 5.1 der Soundkarte kommt, habe manchmal den Eindruck, daß die Zuordnung der Ausgänge bei Dolby nicht immer stimmen.
Aber wie schon gesagt, ist im Moment nicht so wichtig.

Zitat von johns

Dann bau softvol in asound.conf, dann geht auch mute.

Johns

Und wie und wo sollte ich das einbauen, in der Readme steht leider nichts darüber??

Meine asound.conf:

pcm.!default pcm.hdmi_complete


ctl.NVidia { type hw; card NVidia; }
ctl.!default ctl.NVidia


pcm.hdmi_hw {
  type hw
  card NVidia
  device 7
}


pcm.hdmi_formatted {
  type plug
  slave {
    pcm hdmi_hw
    #rate 48000    #  <- Optional! Hier die gewünschte Rate. 
    #channels 2
  }
}


pcm.hdmi_complete {
  type softvol
  slave.pcm hdmi_formatted
  control.name hdmi_volume
  control.card NVidia
}


pcm.51to20 {
    type route
    slave.pcm "hdmi_complete"
    slave.channels 2
    ttable.0.0 3        # Front links -> links
    ttable.1.1 3        # Front rechts -> rechts
    ttable.2.0 2.707    # Hinten links -> links
    ttable.3.1 2.707    # Hinten rechts -> rechts
    ttable.4.0 3.0      # Zentrum -> links
    ttable.4.1 3.0      # Zentrum -> rechts
    ttable.5.0 2.5      # Basskanal -> links
    ttable.5.1 2.5      # Basskanal -> rechts

Startparameter des Plugins:

PLUGIN_PARAMETERS="-d :0 -g 1920x1080+0+0 -s -a 51to20 -p hdmi_hw"

Zitat von C-3PO

Und wie und wo sollte ich das einbauen, in der Readme steht leider nichts darüber??

Na ja, ich denke was woanders steht braucht man ja nicht nochmal wiederholen:http://alsa.opensrc.org/Softvol

Gerald

Zitat

Das zappelige Bild kenne ich aber auch von anderen VDRs. Nur unter Xine haben eben ausschließlich höhere Buffer geholfen, Dein Plugin fängt sich hingegen dann innerhalb Sekunden von selbst wieder. Schön ist das Ganze allerdings nicht. Ich versuche mal ein Log von so einer Situation zu bekommen.

Mar 21 19:14:12 vdr vdr: audio/alsa: wait underrun error? 'Datenübergabe unterbrochen (broken pipe)'
Mar 21 19:14:13 vdr vdr: [6499] frontend 0/0 lost lock on channel 133, tp 338
Mar 21 19:14:13 vdr vdr: [6499] frontend 0/0 regained lock on channel 133, tp 338
Mar 21 19:14:13 vdr vdr: video:  0:10:43.691 +167  342   0/\ms  23 v-buf
Mar 21 19:14:13 vdr vdr: video:  0:10:43.711 +127  282   0/\ms  22 v-buf
Mar 21 19:14:13 vdr vdr: video:  0:10:43.731  +87  318   0/\ms  26 v-buf
Mar 21 19:14:13 vdr vdr: video:  0:10:43.751  +67  278   0/\ms  25 v-buf
Mar 21 19:14:13 vdr vdr: video:  0:10:43.771  +47  334   0/\ms  28 v-buf
Mar 21 19:14:13 vdr vdr: video/vdpau: decoder render too slow 175ms
Mar 21 19:14:13 vdr vdr: video:  0:10:43.811 -127  342   0/\ms  35 v-buf
Mar 21 19:14:14 vdr vdr: video/vdpau: decoder render too slow 174ms
Mar 21 19:14:14 vdr vdr: video: display buffer empty, duping frame (10/11751) 36
Mar 21 19:14:14 vdr vdr: video: missed frame (8/11751)
Mar 21 19:14:14 vdr vdr: video: missed frame (9/11751)
Mar 21 19:14:14 vdr vdr: video:  0:10:45.091 +844  322   0/\ms   9 v-buf
Mar 21 19:14:14 vdr vdr: video:  0:10:45.111 +818  276   0/\ms   8 v-buf
Mar 21 19:14:14 vdr vdr: video:  0:10:45.131 +787  354   0/\ms  12 v-buf
Mar 21 19:14:14 vdr vdr: video:  0:10:45.151 +747  294   0/\ms  11 v-buf
Mar 21 19:14:14 vdr vdr: video:  0:10:43.891 -572  330   0/\ms  15 v-buf
Mar 21 19:14:14 vdr vdr: video: dropping frame (13/11758)
Mar 21 19:14:14 vdr vdr: video:  0:10:45.191 +707  310   0/\ms  13 v-buf
Mar 21 19:14:14 vdr vdr: video:  0:10:45.211 +667  346   0/\ms  18 v-buf
Mar 21 19:14:14 vdr vdr: video:  0:10:45.231 +627  286   0/\ms  17 v-buf
Mar 21 19:14:14 vdr vdr: video:  0:10:45.251 +587  322   0/\ms  21 v-buf
Mar 21 19:14:14 vdr vdr: [6503] changing pids of channel 161 from 501+501=2:502=deu@3:0:0 to 401+401=2:402=deu@3:0:0
Mar 21 19:14:14 vdr vdr: video:  0:10:45.271 +547  262   0/\ms  20 v-buf
Mar 21 19:14:14 vdr vdr: video:  0:10:45.291 +507  298   0/\ms  24 v-buf
Mar 21 19:14:14 vdr vdr: video:  0:10:45.311 +467  334   0/\ms  31 v-buf
Mar 21 19:14:14 vdr vdr: video:  0:10:44.051 -852  274   0/\ms  30 v-buf
Mar 21 19:14:14 vdr vdr: video: dropping frame (14/11766)
Mar 21 19:14:14 vdr vdr: video:  0:10:45.351 +427  254   0/\ms  28 v-buf
Mar 21 19:14:14 vdr vdr: video:  0:10:45.371 +387  290   0/\ms  31 v-buf
Mar 21 19:14:15 vdr vdr: video:  0:10:45.391 +347  326   0/\ms  37 v-buf
Mar 21 19:14:15 vdr vdr: video:  0:10:45.411 +307  266   0/\ms  36 v-buf
Mar 21 19:14:15 vdr vdr: video:  0:10:45.431 +267  334   0/\ms  40 v-buf
Mar 21 19:14:15 vdr vdr: video:  0:10:45.451 +227  274   0/\ms  39 v-buf
Mar 21 19:14:15 vdr vdr: video:  0:10:45.471 +187  310   0/\ms  43 v-buf
Mar 21 19:14:15 vdr vdr: video:  0:10:45.491 +147  346   0/\ms  47 v-buf
Mar 21 19:14:15 vdr vdr: video:  0:10:45.511 +107  286   0/\ms  46 v-buf
Mar 21 19:14:15 vdr vdr: video:  0:10:45.531  +67  322   0/\ms  50 v-buf
Mar 21 19:14:15 vdr vdr: video:  0:10:45.551  +47  282   0/\ms  49 v-buf
Mar 21 19:14:15 vdr vdr: video:  0:10:44.391-1252  334   0/\ms  49 v-buf
Mar 21 19:14:15 vdr vdr: video: dropping frame (15/11783)
Mar 21 19:14:16 vdr vdr: [6503] changing pids of channel 161 from 401+401=2:402=deu@3:0:0 to 501+501=2:502=deu@3:0:0
Mar 21 19:14:18 vdr vdr: video:  0:10:48.911  +27  358   0/\ms  46 v-buf

Der Lost Lock ist möglicherweise der Auslöser, allerdings kenne ich das Zappeln auch von einem anderen VDR unter Xine mit perfekter Verkabelung.

Wären hier einstellbare Buffer eventuell doch von Vorteil? Oder eine Auswahl vordefinierter Buffer?

CafeDelMar

johns: Ich habe gerade spaßeshalber ein paar Messungen gemacht, wie viel der Suspend-Mode bringt.

HD: 72 Watt
SD: 68 Watt
Suspend: 68 Watt

Würdest du nicht einen Haufen Arbeit sparen, wenn du auf den Dummy Player und alles andere was mit dem Anhalten des Bildes bei Inaktivität zu tun hat verzichten würdest?

CafeDelMar: Ist der Anfang des Log's kurz nach dem Umschalten erstellt ?

Zitat von gda

[...] Na ja, ich denke was woanders steht braucht man ja nicht nochmal wiederholen:http://alsa.opensrc.org/Softvol

Ich verwende, wie man in meinem obigen Posting sehen kann, "51to20".

Wenn ich die entsprechende Section ändere,

pcm.51to20 {
    type coftvol
    slave.pcm "hdmi_complete"
    slave.channels 2
    ttable.0.0 3        # Front links -> links
    ttable.1.1 3        # Front rechts -> rechts
    ttable.2.0 2.707    # Hinten links -> links
    ttable.3.1 2.707    # Hinten rechts -> rechts
    ttable.4.0 3.0      # Zentrum -> links
    ttable.4.1 3.0      # Zentrum -> rechts
    ttable.5.0 2.5      # Basskanal -> links
    ttable.5.1 2.5      # Basskanal -> rechts

dann geht MUTE. Leider aber geht dann nur(!) MUTE, denn VDR bleibt mit diesen Settings leider stumm!

@ gda,

ich gehe mal davon aus, dass Du es selbst nie getestet hast?

Zitat von rudirabbit

CafeDelMar: Ist der Anfang des Log's kurz nach dem Umschalten erstellt ?

Nein, das war mitten in der Sendung ohne Umschalten auf ZDF HD.

Zitat von CafeDelMar

Nein, das war mitten in der Sendung ohne Umschalten auf ZDF HD.

Ok , dann werden es wohl doch Empfangsprobleme sein - evtl. mit Femon nachsehen

@C-3PO:
Mit diesem Eintrag kanns wohl nicht funktionieren - Oder

Zitat

type coftvol

Ich hoffe, dass das jetzt nicht ganz Off-Topic ist, aber ich will externe Fehler ausschließen ...

Mein VDR steht in einer Mietwohnung und hängt mit ein paar Metern Kabel am Antennenanschluss (DVB-C), neue Multimedia-Dose. Verwendet werden Satelco Easywatch-Karten, die mit extrem kurzen Kabeln (Satkabel) durchgeschliffen werden. Bei mir ist ein Kabel durch Quetschung leicht angebrochen, dies führt ausschließlich auf ARD (nicht HD) zu einem nachvollziehbarem Empfangsausfall und lässt sich durch entsprechendes Drücken temporär wieder beheben (habe ich vor dem Test auch sicherheitshalber gemacht). Wird jetzt auch ausgetauscht.

Der VDR-Server meiner Eltern hängt im eigenen Haus direkt an der ersten Dose, ebenfalls neue Multimedia-Dose. Verwendet wird der Digital Devices Octopus mit zwei Tunerkarten, der zweite Tuner wird durchgeschliffen. Ich bin mir nicht sicher, ob hier eventuell auch das gleiche kurze Kabelstück verwendet wird. Die Zuleitung von der Dose ist auf jeden Fall ein sehr hochwertiges Kabel. "lost lock"s konnte ich hier nur vereinzelt alle paar Wochen finden, also wohl normal. Aber auch hier tritt mit Xine und GT520 dieses Bildzappeln bei zu geringem Buffer auf. Ein Test mit softhddevice soll hier noch folgen, nur muss ich dafür erstmal Remote das System aktualisieren.

Ich schließe hieraus, dass das Problem nicht unbedingt am Empfang liegt, werde aber jetzt mit anderem Kabel testen.

CafeDelMar

Moin!

Gute Kabel sind immer wichtig, aber auch bei DVB-C kann es Empfangsstörungen geben (Bagger, Presslufthammer, Arbeiten an der Kopfstation usw.).
Nur, weil das Kabel unter der Erde liegt, heißt das nicht, dass da keiner dran rumfummelt.
Sie sind aber sicherlich seltener und nicht so wetterabhängig wie Sat oder Terr.

Und ein Kabelbruch, Quetschung usw. ist natürlich auch ärgerlich.

Lars.

Zitat von mini73

Moin!

Gute Kabel sind immer wichtig, aber auch bei DVB-C kann es Empfangsstörungen geben (Bagger, Presslufthammer, Arbeiten an der Kopfstation usw.).
Nur, weil das Kabel unter der Erde liegt, heißt das nicht, dass da keiner dran rumfummelt.
Sie sind aber sicherlich seltener und nicht so wetterabhängig wie Sat oder Terr.

Und ein Kabelbruch, Quetschung usw. ist natürlich auch ärgerlich.

Lars.

Alles anzeigen

Ja, ich weiß, leider. Das mit dem Bagger hatten wir auch gerade, der hatte drei Glasfaserkabel durchtrennt, da war dann TV und Internet einen Tag weg.

Aber jetzt mit dem ersetzen Kabel gab es bislang keine "lost lock" mehr, mal abwarten.

CafeDelMar

EDIT: Mit ersetztem Kabel meinte ich natürlich mein eines Antennenkabel, nicht die Glasfaserleitungen.