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

  • Immer diese Steinzeit Libraries. Dann kann ich es später auch nicht für den Downmix verwenden.


    Hmmm...mein System ist eigentlich recht aktuell...was ist denn aus der Steinzeit?



    Edit: soll heißen im GIT gefixt.


    Danke...schneller als die Feuerwehr :)


    Ciao Louis

  • johns: Hast du eine Idee, warum es in Post #977 um 10:55:55 zu den 'decoder render too slow' Meldungen kommt?
    Hat das was mit 'using device '51to20'' zu tun? Und was bedeutet das?

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


    Kann es sein, dass es den Wert "216" in der aktuellen audio.c nicht mehr gibt?


    Code
    vdr01 softhddevice # grep 216 codec.c
    vdr01 softhddevice #
  • Kann es sein, dass es den Wert "216" in der aktuellen audio.c nicht mehr gibt?

    Würde sagen ja, johns hat den Wert auf 336 gestellt.
    Außerdem wirst du mit dem grep nichts finden, du suchst in der codec.c.

    Code
    vdr01 softhddevice # grep 216 codec.c


    Wahrscheinlich ein Vertipper ;D


    Wobei sich jetzt die Frage stellt, ob wir die 336 ms in Verbindung mit dem neuen Parser testen sollen - oder die 116 ms nehmen müssen.
    johns:
    Das soll jetzt keine Kritik sein, nicht falsch verstehen
    Ich denke louis Problem ist ein nicht aktuelles ffmpeg Packet, der normale Weg wäre wenn louis sein ffmpeg updatet, und nicht der Entwickler auf ältere Lib's zurückgeht.
    Das hätte zur Folge, das eben Features in dem Projekt fehlen würden.

    VDR 1 (SD) : ASRock A330 GC, 1 GB RAM, TT- FF Karte rev. 2.3, 7'' TFT, Lirc X10 - Selbstbau Gehäuse - Suse 11.3 (64) vdr-1.7.10 diverse Plugins
    VDR 2 (HD) : MSI G41M-P25, 2 GB RAM, E6700 2x3.20GHz, Gainward GT220, 2TB HD, Lirc X10, TT S2-3600 USB, TT S2-1600, - Suse 11.3 (64) NvidiaTreiber 260.19 vdr-1.7.18 - xineliboutplugin 1.0.90 cvs, xine-lib 1.1.90 , s2-liplianin DVB Treiber

    3 Mal editiert, zuletzt von rudirabbit ()

  • Das kannst ja nicht wissen, aber es ist beides der Gleiche Aufwand, bzw. die Gleichen Routinen.


    Mach solange es noch nicht drin ist: xrandr --rate 50. Nach dem X-Server start.


    Johns


    klar das mach ich ja schon. manchmal passiert das aber parallel. so das dein video bild hängen bleibt. dann muss ich SUSP/RESU'en

    mfg traxanos
    ____________________
    Ist das neu?, Nein Linux!


    VDR1: Zotac NM10-ITX Wifi - 2GB Ram - S2-6400 HD mit IR - yavdr 0.4 (development) - LianLi PC-Q11


    Tags: VDR-HD - AT5IONT-I - 4GB Ram - 512MB ION - TT 3600 DVB-S2 - TT6400-FF - Sundtek DVB-S2 Sundtek DVB-C - Tevii S480 (dank an L4M für kostenlose Bereitstellung) - yaVDR 0.5 (development) - SKY - HD+ - Atric - X10 FB - Zotac ID41 PLUS - SilverStone LC19B-R - Yamaha RX-V671 - Samsung 8Series 55"

  • Bei Prosieben HD funktioniert bei mir das Spulen nur sehr sprunghaft. Kann das jemand bestätigen?


    Ich habe das nochmal überprüft. Es ist nur beim Zurückspulen. Es wird erst in etwa 30sec Schritten gespult (ca 2 Bilder sind zu sehen) und dann steht erstmal alles still. Ein paar Sekunden später schaltet der VDR zurück auf Wiedergabe.


  • Ich habe das nochmal überprüft. Es ist nur beim Zurückspulen. Es wird erst in etwa 30sec Schritten gespult (ca 2 Bilder sind zu sehen) und dann steht erstmal alles still. Ein paar Sekunden später schaltet der VDR zurück auf Wiedergabe.


    Ich habs eben mal getestet...das kann ich nicht bestätigen. Sowohl mit einer aktuellen Aufnahme als auch mit einer älteren Aufnahme absolut problemlos.


    Ciao Louis



  • Zitat

    Ich habs eben mal getestet...das kann ich nicht bestätigen. Sowohl mit
    einer aktuellen Aufnahme als auch mit einer älteren Aufnahme absolut
    problemlos.

    Hab es gerade getestet und auch keinerlei Probleme.


    Grüße

    NFS+DVB_Server: Ubuntu 12.04 Server LTS // Intel dn2800mt mit 1xWD Red (2TB), 1xWD Green (2TB), 5xSundtek SkyTV DVB-S/S2
    VDR: Gen2VDRV4 (VDR-2.1.6) // Asus C8HM70-I/HDMI , 64GB Sandisk SSD (System), 4GB Ram (Dualchannel), Zotac GT630, 4TB über NFS (Video0+Mediadaten), 5xSundtek SkyTV DVB-S/S2 über Lan, PS3 FB // softhddevice_GIT, NV-Treiber_340.58, FFMPEG_1.2.6, Kernel_3.16.5, Alsa_1.0.28 // KODI_15.0_ALPHA
    CLIENT: (Debian) Banana Pi (VDR-2.1.7) // streamdevclient // softhddevice // PS3 FB
    TEST: Grundig GSS 400 mit Vtunerc // Satip-Plugin // TVheadend


    Je mehr man gelernt hat, desto mehr weiß man, wie wenig man weiß.

  • Seit wann haste das Problem? VDR Wechsel zum 1.7.24 ér oder Plugin-Version?

    NFS+DVB_Server: Ubuntu 12.04 Server LTS // Intel dn2800mt mit 1xWD Red (2TB), 1xWD Green (2TB), 5xSundtek SkyTV DVB-S/S2
    VDR: Gen2VDRV4 (VDR-2.1.6) // Asus C8HM70-I/HDMI , 64GB Sandisk SSD (System), 4GB Ram (Dualchannel), Zotac GT630, 4TB über NFS (Video0+Mediadaten), 5xSundtek SkyTV DVB-S/S2 über Lan, PS3 FB // softhddevice_GIT, NV-Treiber_340.58, FFMPEG_1.2.6, Kernel_3.16.5, Alsa_1.0.28 // KODI_15.0_ALPHA
    CLIENT: (Debian) Banana Pi (VDR-2.1.7) // streamdevclient // softhddevice // PS3 FB
    TEST: Grundig GSS 400 mit Vtunerc // Satip-Plugin // TVheadend


    Je mehr man gelernt hat, desto mehr weiß man, wie wenig man weiß.

  • johns: Der Testlog mit akuteller git Version:

    Code
    Feb 24 19:18:12 linux-i3n6 vdr: video: 18:58:51.117  -21  158   0/\ms  32 v-buf
    Feb 24 19:19:12 linux-i3n6 vdr: video: 18:59:51.117  -21  158   0/\ms  31 v-buf
    Feb 24 19:20:12 linux-i3n6 vdr: video: 19:00:51.117  -21  158   0/\ms  35 v-buf
    Feb 24 19:21:12 linux-i3n6 vdr: video: 19:01:51.117  -21  126   0/\ms  35 v-buf
    Feb 24 19:21:58 linux-i3n6 vdr: audio/alsa: wait underrun error?
    Feb 24 19:22:12 linux-i3n6 vdr: video: 19:02:51.117  +28  208   0/\ms  30 v-buf


    Test bei 1080i DD - beim "underrun error" war ein kurzer unsauberer Ton zu hören.
    Meine Theorie:
    Der Default (Start) Audio Buffer Wert liegt bei 336 ms, im Log kann man sehen, das dieser Wert immer weiter dekrementiert wird, bei 126 ms geht alsa dann in den underrun mode.
    Danach sind es wieder 208 ms.
    Kann es sein, daß der Algo im Plugin etwas zu optimistisch rechnet ?

    VDR 1 (SD) : ASRock A330 GC, 1 GB RAM, TT- FF Karte rev. 2.3, 7'' TFT, Lirc X10 - Selbstbau Gehäuse - Suse 11.3 (64) vdr-1.7.10 diverse Plugins
    VDR 2 (HD) : MSI G41M-P25, 2 GB RAM, E6700 2x3.20GHz, Gainward GT220, 2TB HD, Lirc X10, TT S2-3600 USB, TT S2-1600, - Suse 11.3 (64) NvidiaTreiber 260.19 vdr-1.7.18 - xineliboutplugin 1.0.90 cvs, xine-lib 1.1.90 , s2-liplianin DVB Treiber


  • Vlt. solltest Du halt irgendwo mal schreiben, welche Versionen verwendet werden soll(t)en?


    Eigentlich jede ab 0.7, deshalb habe ich es ja wiederherausgenommen.


    johns: Hast du eine Idee, warum es in Post #977 um 10:55:55 zu den 'decoder render too slow' Meldungen kommt?
    Hat das was mit 'using device '51to20'' zu tun? Und was bedeutet das?


    Da passiert was im Stream. An der Meldung kann man erkennen das sich gerade der Tonkanal geändert hat.
    Ich vermute die Werbung war aus und nun geht der Film los. Kann durchaus sein, das sich das Videoformat auch geändert hat und so vdpau aus dem Takt kommt.



    Es ist alles fest: 336 für PES und 226 für TS.


    War ja nichts wichtiges, war der Rest vom Test Dolby Digital lauter zumischen und ich habe es drin gelassen, da man damit noch den Downmix wie Alsa konfigurieren kann. Ab ffmpeg 1.0 gibt es keinen Support für altes Zeug, dafür aber länger 1.0.



    Ich habe das nochmal überprüft. Es ist nur beim Zurückspulen. Es wird erst in etwa 30sec Schritten gespult (ca 2 Bilder sind zu sehen) und dann steht erstmal alles still. Ein paar Sekunden später schaltet der VDR zurück auf Wiedergabe.


    Ja, habe hier eine Aufnahme leider nur 1:30, damit kann man nicht schön testen. Aber genau so wie du es beschreibst, bin mir nur nicht sicher ob es nicht so von VDR kommt.



    Test bei 1080i DD - beim "underrun error" war ein kurzer unsauberer Ton zu hören.
    Meine Theorie:
    Der Default (Start) Audio Buffer Wert liegt bei 336 ms, im Log kann man sehen, das dieser Wert immer weiter dekrementiert wird, bei 126 ms geht alsa dann in den underrun mode.
    Danach sind es wieder 208 ms.
    Kann es sein, daß der Algo im Plugin etwas zu optimistisch rechnet ?


    Wenn sich dies wiederholen lässt, sendet entweder der Sender zulangsam oder die Soundkarte spielt schneller ab.
    Sollte dies die Regel sein, ich kann es auf 3 Rechner nicht nachvollziehen, dann muß der Tonteil, noch eine Geschwindigkeitsanpassung vornehmen.


    Johns

    Sag mir, wo die Developer sind. Wo sind sie geblieben? . . . . . . . . . . . . . . . . . . . . SoftHdDevice - A software and GPU emulated HD output device plugin.
    Sag mir, wo die Developer sind. Was ist geschehn?


    Client0: Crown CW02 MSI_C847MS-E33 Zotac_GT640_passiv Cine-S2 iMon-MCE / streamdev softhddevice
    Client1: Lian_Li_PC-Q09FB ASRock_H67M-ITX/HT I3-2100 ASUS_ENGT520_passiv / streamdev softhddevice
    Test: Lian_Li_PC-Q09R Asus C60M1-I / streamdev
    Server0: Dockstar TT-S2-3600-USB / streamdev
    Server2: Lian_Li_PC-Q07R Intel_DH61DL G620 WD20EARX 90W PicoPSU Cine-S2+DuoFlex-S2+DuoFlex-CT / streamdev / 22 Watt Verbrauch

  • Hi,


    ich hatte jetzt den ganzen Abend mit der aktuellen git Version und aktiviertem DUSE_TS_AUDIO keinen einzigen Tonaussetzer mehr...auch auf 1080i mit DD5.1 nen ganzen Film lang :tup


    Ciao Louis


    PS: die Umschaltzeiten sind echt der Knaller...sogar meine Frau meinte: "Das ist ja fast wie früher"...und das soll was heissen, da kannste dir was drauf einbilden Johns :welle

  • Hi, ja es schaut viel besser aus, der VDR lief die Nacht durch, SKY-HD DD.
    Und läuft jetzt noch, ohne Neustarten zu müssen oder ähnliches.
    Einmal war dies wieder im Log:

    Code
    Feb 25 03:50:30 linux-i3n6 vdr: audio/alsa: wait underrun error?
    Feb 25 03:50:30 linux-i3n6 vdr: audio/alsa: buffer size 4608 96ms, period size 1152 24ms
    Feb 25 03:50:30 linux-i3n6 vdr: audio/alsa: delay 216 ms
    Feb 25 03:50:30 linux-i3n6 vdr: video: 20:24:15.583+88888  144 240/\ms   3 v-buf
    Feb 25 03:50:30 linux-i3n6 vdr: video: 20:24:15.603+88888  144 240/\ms   3 v-buf
    Feb 25 03:50:30 linux-i3n6 vdr: video: 20:24:15.623+88888  144 240/\ms   2 v-buf

    Sollte dies die Regel sein, ich kann es auf 3 Rechner nicht nachvollziehen, dann muß der Tonteil, noch eine Geschwindigkeitsanpassung vornehmen.

    Wenn dies technisch machbar ist - wäre schon gut.
    Ich werde demnächst mein produktives System neu bauen, dort läuft die Audiowiedergabe über die Rechner Soundkarte und 5.1 Lautsprecherset.
    Dort ist auch die Hardware deutlich besser.
    Evtl. ändert sich dann was.


    Im Log ist auch ab und zu dies drin:

    Code
    Feb 25 04:51:07 linux-i3n6 vdr: video/vdpau: decoder render too slow 135 ms
    Feb 25 04:51:07 linux-i3n6 vdr: video: missed frame (116/2112133)
    Feb 25 04:51:07 linux-i3n6 vdr: video:  6:11:11.738 -159  159   0/\ms  37 v-buf


    Du hast dafür auch schon eine Lösung parat:

    Zitat

    Werde demnächst meinen Eigenen TS Parser für Video einbauen. um zusehen ob der VDR TS Parser nicht noch mehr Bugs hat.

    VDR 1 (SD) : ASRock A330 GC, 1 GB RAM, TT- FF Karte rev. 2.3, 7'' TFT, Lirc X10 - Selbstbau Gehäuse - Suse 11.3 (64) vdr-1.7.10 diverse Plugins
    VDR 2 (HD) : MSI G41M-P25, 2 GB RAM, E6700 2x3.20GHz, Gainward GT220, 2TB HD, Lirc X10, TT S2-3600 USB, TT S2-1600, - Suse 11.3 (64) NvidiaTreiber 260.19 vdr-1.7.18 - xineliboutplugin 1.0.90 cvs, xine-lib 1.1.90 , s2-liplianin DVB Treiber

  • Hallo,


    Dies habe ich in der aktuellen GIT Version:

    Was mir vor allem auffällt sind die extrem kleinen V-Bufferwerte.



    Peter

    VDR1: ASUS N100I-D D4 + IP TV Plugin + Flirc + softhddevice-git VAAPI + vdr-2.6.5 + 3 weitere Plugins + Debian Bookworm via M2 + Kernel 6.1.0


    VDR2: ASUS AT3IONT-I + PCTV USB Stick 461e + Nvidia 340.108 + Flirc + softhddevice-git + vdr-2.6.4 + 8 weitere Plugins + Samsung U70 + Debian Bullseye via SSD + Kernel 6.3.6 + LG 55 Zoll

  • Hallo,
    Was mir vor allem auffällt sind die extrem kleinen V-Bufferwerte.


    Ja. Eigentlich sollte das Plugin Frames verdoppeln um mit dem Ton gleichzuziehen.
    Dadurch würden sich die Buffer füllen, das Plugin schmeißt aber Frames wech und dadurch wird der Buffer leerer.
    Ist es ein bestimmer Sender und dieser immer?
    Oder ist es nur nach dem Umschalten passiert?
    Wenn ich es richtig sehe, habe ich da kein Rücksetzen drin, obwohl das bisher bei mir noch keinen Ärger machte.


    Johns

    Sag mir, wo die Developer sind. Wo sind sie geblieben? . . . . . . . . . . . . . . . . . . . . SoftHdDevice - A software and GPU emulated HD output device plugin.
    Sag mir, wo die Developer sind. Was ist geschehn?


    Client0: Crown CW02 MSI_C847MS-E33 Zotac_GT640_passiv Cine-S2 iMon-MCE / streamdev softhddevice
    Client1: Lian_Li_PC-Q09FB ASRock_H67M-ITX/HT I3-2100 ASUS_ENGT520_passiv / streamdev softhddevice
    Test: Lian_Li_PC-Q09R Asus C60M1-I / streamdev
    Server0: Dockstar TT-S2-3600-USB / streamdev
    Server2: Lian_Li_PC-Q07R Intel_DH61DL G620 WD20EARX 90W PicoPSU Cine-S2+DuoFlex-S2+DuoFlex-CT / streamdev / 22 Watt Verbrauch

  • Also ich teste gerade aktuelle Git-Version mit einem Ion-330+GT210 und hier schmiert das Plugin nach einer gewissen Zeit ab. Hier das Log bei Discovery HD:



    Was läuft hier schief?

    NFS+DVB_Server: Ubuntu 12.04 Server LTS // Intel dn2800mt mit 1xWD Red (2TB), 1xWD Green (2TB), 5xSundtek SkyTV DVB-S/S2
    VDR: Gen2VDRV4 (VDR-2.1.6) // Asus C8HM70-I/HDMI , 64GB Sandisk SSD (System), 4GB Ram (Dualchannel), Zotac GT630, 4TB über NFS (Video0+Mediadaten), 5xSundtek SkyTV DVB-S/S2 über Lan, PS3 FB // softhddevice_GIT, NV-Treiber_340.58, FFMPEG_1.2.6, Kernel_3.16.5, Alsa_1.0.28 // KODI_15.0_ALPHA
    CLIENT: (Debian) Banana Pi (VDR-2.1.7) // streamdevclient // softhddevice // PS3 FB
    TEST: Grundig GSS 400 mit Vtunerc // Satip-Plugin // TVheadend


    Je mehr man gelernt hat, desto mehr weiß man, wie wenig man weiß.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!