[softhddevice} Ruckler bei ARD HD

  • Hallo,
    ich weiß das es zu ähnlichen Themen schon Threads gibt, leider habe ich nicht das passende gefunden (wenn ich es übersehen habe dann sorry)


    Mein System ist ein Core I3 mit GT 530 und ich nutze VDPAU.


    habe nun von xineliboutput auf softhddevice umgestellt. Sieht erstmal gut aus und ein Großes Lob an den Entwickler!


    Derzeit kann ich nur bei ARD HD ständige Ruckler im Bild feststellen. Diese hatte ich auch schon vorher mit xineliboutput (dies war ein Grund für den Wechsel).
    Soweit ich das richtig verstanden habe, nutzt softhddevice nicht die xine-lib? Kann ich irgendwo in einer Konfiguration die Buffer Werte ähnlich wie bei xineliboutput anpassen?
    Wenn softhddevice nicht die xine-lib verwendet und trotzdem die extremen Bildstörungen auftreten, dann legt sich langsam bei mir der Verdacht nahe das es an vdpau oder der GraKa liegt. Die Treiber wurden heute auch aktuallisiert.


    Weiß jemand noch einen Rat woran das liegen kann oder was ich noch versuchen kann?
    Im Log erhalte ich nur folgendes auffälliges:

    Code
    Jun 28 02:24:57 srv vdr: [softhddev] invalid PES video packet
    Jun 28 02:25:59  vdr: last message repeated 26 times
    Jun 28 02:26:59  vdr: last message repeated 137 times


    Grüße
    Martin

  • Moin,


    Verwendest Du eine aktuelle VDR-Version?


    Kann es sein, dass Du Empfangsprobleme hast ( ... mal mit femon prüfen)


    Grüße, Peter

    KODI, tvh, arch x86_64, Octopus net 2 x Duoflex C/C2/T2 , NUC7i3BNH, Crucial MX300 2TB, LG LM 669S

    Linux is the best OS I have ever seen -- Albert Einstein

  • Code
    Jun 28 02:24:57 srv vdr: [softhddev] invalid PES video packet


    Sagt aber Empfangs oder Dekoderproblem.


    Versuch mal die Frequenz von ARD HD in channel.conf +/- 1 Mhz zuverändern.


    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

  • Code
    Jun 28 02:24:57 srv vdr: [softhddev] invalid PES video packet


    mit softhddevice kenne ich mich noch nicht aus, aber so wie ich die Meldung interpretiere, meckert das softhddevice-Plugin über Fehler in PES-Daten. Die Frage ist jetzt, wo kommen diese PES-Daten her? wurden sie im Plugin selbst erzeugt (aus den von vdr gelieferten TS-Paketen)? Oder nutzt softhddevice nicht die PlayTs-Funktionen, sondern bedient sich in PlayVideo/PlayAudio der vom vdr generierten PES-Pakete? Dann könnten die Fehler in den PES-Paketen nämlich schon im vdr entstanden sein (beim Neuverpacken der TS-Pakete in PES-Pakete).


    Das Problem mit den PlayVideo/PlayAudio-Funktionen ist, dass sie von den meisten Ausgabeplugins nicht mehr genutzt werden und daher Fehler in der vdr-internen Wandlung TS->PES kaum auffallen.Sowohl die FF-SD-Karten als auch die FF-HD-Karten können treiberseitig direkt TS abspielen, so dass dort die vdr-interne PES-Wandlung gar nicht mehr zum Einsatz kommt. Und das xine-Plugin hat einen eigenen remuxer/repacker, der aus den TS-Daten von vdr saubere PES-Pakete macht. Der Code für diesen repacker stammt von Reinhard Nissl und war früher in vdr enthalten. Klaus hat ihn dann im Zuge der Umstellung auf TS entfernt und die Wandlung TS->PES im vdr stark vereinfacht. Für sein xine-Plugin hat Reinhard seinen Code dann dort wieder implementiert.


    Für mich stellt sich die Frage, ob VDPAU bzw. die Grafikkarte überhaupt PES-Daten braucht, oder ob sie nicht auch TS verarbeiten würde. Und falls sie wirklich PES braucht: Könnte man nicht den bewährten remuxer/repacker von Reinhard Nissl ins softhddevice-Plugin implementieren, so dass das Plugin die PlayTs-Funktionen nutzen kann und nicht mehr auf die PES-Wandlung im vdr angewiesen ist?

    VDR1: ACT-620, Asus P8B75-M LX, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

    VDR2: Odroid N2+ mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    VDR3: Tanix TX3 mit CoreELEC und Ubuntu in chroot, WinTV DualHD

  • hallo,


    ich bekomme die meldung immer beim umschalten - "spürbar/sichtbar" ist es aber nicht:


    ich denke, beim umschalten ist das normal, stimmt's.


    ciax

  • mit softhddevice kenne ich mich noch nicht aus, aber so wie ich die Meldung interpretiere, meckert das softhddevice-Plugin über Fehler in PES-Daten. Die Frage ist jetzt, wo kommen diese PES-Daten her? wurden sie im Plugin selbst erzeugt (aus den von vdr gelieferten TS-Paketen)? Oder nutzt softhddevice nicht die PlayTs-Funktionen, sondern bedient sich in PlayVideo/PlayAudio der vom vdr generierten PES-Pakete? Dann könnten die Fehler in den PES-Paketen nämlich schon im vdr entstanden sein (beim Neuverpacken der TS-Pakete in PES-Pakete).


    Bei Video werden die PES Pakete vom VDR direkt genommen und nur eine Überprüfung auf Fehler vorgenommen, diese Fehlerprüfung meckert hier am laufenden Band.


    Zitat

    Das Problem mit den PlayVideo/PlayAudio-Funktionen ist, dass sie von den meisten Ausgabeplugins nicht mehr genutzt werden und daher Fehler in der vdr-internen Wandlung TS->PES kaum auffallen.Sowohl die FF-SD-Karten als auch die FF-HD-Karten können treiberseitig direkt TS abspielen, so dass dort die vdr-interne PES-Wandlung gar nicht mehr zum Einsatz kommt. Und das xine-Plugin hat einen eigenen remuxer/repacker, der aus den TS-Daten von vdr saubere PES-Pakete macht. Der Code für diesen repacker stammt von Reinhard Nissl und war früher in vdr enthalten. Klaus hat ihn dann im Zuge der Umstellung auf TS entfernt und die Wandlung TS->PES im vdr stark vereinfacht. Für sein xine-Plugin hat Reinhard seinen Code dann dort wieder implementiert.


    Sollte inzwischen wieder einwandfrei laufen. Es wurde ein Bug im VDR PES Parser gefunden und ist seit .24 gefixt. Da aber alle anderen keine Probleme haben, gehe ich in diesem Fall von einem Problem beim Empfang aus.


    Bei normalen Betrieb kommen noch vereinzelt leere oder falsche Pakete vom VDR, deshalb steht schon lange auf meiner TODO Liste einen eigenen TS Parser einzubauen.
    Da aber diese nur sehr selten auftreten und bisher noch nicht bewiesen werden konnte. daß sie für Probleme verantworlich sind, habe ich mir diese Arbeit gespart.


    Zitat

    Für mich stellt sich die Frage, ob VDPAU bzw. die Grafikkarte überhaupt PES-Daten braucht, oder ob sie nicht auch TS verarbeiten würde. Und falls sie wirklich PES braucht: Könnte man nicht den bewährten remuxer/repacker von Reinhard Nissl ins softhddevice-Plugin implementieren, so dass das Plugin die PlayTs-Funktionen nutzen kann und nicht mehr auf die PES-Wandlung im vdr angewiesen ist?


    Nur zu deiner Information: Die Sender senden PES dies wird in TS Pakete zerlegt. VA-API VDPAU bekommen ES aufbereitet als Strukturen übergeben.
    Wenn man will könnte man die TS -> PES -> ES -> Strukturen -> VDDPAU/VA-API Wandlung komplett im Plugin machen und auf FFMpeg verzichten.


    ciax


    Ja nach dem Umschalten ist es normal und kann vorkommen, ist im Prinzip auch ein Empfangsstörung.
    Sollte noch eine CAM dazwischen hängen, können es auch ein paar mehr werden, bis die Dekodierung läuft.
    Im normalen Betrieb sollten sie nicht mehr vorkommen.


    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

  • Da aber alle anderen keine Probleme haben, gehe ich in diesem Fall von einem Problem beim Empfang aus.

    bei meiner sat-installation gab es bis vor kurzem starke empfangsstörungen (lag an einer nicht sauber installierten sat-enddose). softhddevice reagiert darauf sehr empfindlich und bringt schon auch den vdr damit ins "trudeln" (extreme verzögerungen bei bedienung mit RC, bis hin zur unbedienbrakeit). jetzt läuft's mit der aktuellen git und gutem empfang wieder "zackig schnell" - echt super :tup


    ciax

  • Also Empfangsprobleme kann ich denk ich wirklich ausschließen. DIe DBOX2 sagt super Werte und femon auch. Wir haben Hier KD DVB-C.
    Ich versuch jetzt mal die MHz Anpassung und guck mal ob das was nützt.


    Danke schonmal für die Antworten.


    Grüße
    Martin

  • Ok ein wenig muss ich zurückrudern. Es wohl doch ein wenig mit "Empfangsprobleme" zu tun. Ich habe Cine CT DualTuner Karte. Ich komme natürlich mit einem hochwertigen Kabel am VDR an und splitte diesen dann mit einem Splitter auf beide Eingänge auf. Ohne Splitter und mit nur einem Eingang sieht es erstmal besser aus. Hmm da muss ich mir wohl doch nochmal nach einem "besseren" Splitter umschauen und heute Fussball nur mit einem Eingang gucken ;)
    Trotzdem finde ich es eigenartig das dies nur bei ARD HD auftritt und sonst nirgendswo.


    Danke für eure Hilfe.


    Grüße
    Martin

  • Moin!


    Meine Dual-CT hat nur einen Eingang, der splittet intern selbst. Das andere ist ein Ausgang.
    Oder was für eine Version der Karte hast du?


    Wenn deine Karte wirklich zwei Eingänge hat, dann vergiss nicht, den anderen Tuner im vdr zu disablen, sonst wird er Probleme haben.


    Lars.

  • Trotzdem finde ich es eigenartig das dies nur bei ARD HD auftritt und sonst nirgendswo.


    ARD HD ist auch bei mir bei DVB-C besonders empfindlich.
    Ich habe das Signal durch mehrere Karte durchgeschliffen und ein Kabel war bei mir wohl mal angeknackst, da hatte ich dann mit softhddevice auch Probleme und bei Xine lies sich das mit hohen Buffer-Werten ausbügeln, was aber nicht Sinn der Sache ist. ;)


    Meine Dual-CT hat nur einen Eingang, der splittet intern selbst. Das andere ist ein Ausgang.
    Oder was für eine Version der Karte hast du?


    Die alten Versionen der Digital Devices Karten hatten zwei getrennte Eingänge, erst bei den neuen Versionen wird intern durchgeschliffen.
    (Zumindest soweit ich richtig informiert bin.)


    CafeDelMar


  • ARD HD ist auch bei mir bei DVB-C besonders empfindlich.


    lass mich raten: S02/ 113 MHz? dann liegt es wahrscheinlich an der Dose, die Radio und TV getrennt bereitstellt und dabei am TV-Ausgang die 113MHz bereits "anschneidet"

    VDR1: ACT-620, Asus P8B75-M LX, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

    VDR2: Odroid N2+ mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    VDR3: Tanix TX3 mit CoreELEC und Ubuntu in chroot, WinTV DualHD


  • Bezieht sich dieses ".24" auf eine VDR-Version oder softhddevice?
    In VDR 1.7.24 habe ich auf die Schnelle keinen diesbezüglichen Fix gefunden...


    Klaus


    IMHO war dies hier in 1.7.23 gemeint:


    Code
    - Fixed a possible memory corruption in cTsToPes::GetPes() in case of broken
    TS packets, e.g. when switching channels.

    KODI, tvh, arch x86_64, Octopus net 2 x Duoflex C/C2/T2 , NUC7i3BNH, Crucial MX300 2TB, LG LM 669S

    Linux is the best OS I have ever seen -- Albert Einstein

Jetzt mitmachen!

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