Alternativen vdr-xinelibout-client bauen

  • Hi Forum,



    Als jahrelanger VDR-Nutzer, mit etlichen Clientplatformen über die Jahre, bin

    ich seit 5 Jahren mit dem Raspi (client-seitig wie gesagt) unterwegs. Aktuell

    mit einem RPI4b. Anfangs nutzte ich einen streamdev-client, dann später ein

    zusammengewurschteltes vdr-fbfe+mmal. Beide Versionen haben erstaunliche

    Mängel. Letzteres knallt laufend weg, erstes ist mit Plugins gefüllt und hat

    trotzdem Probleme alle Daten (EPG und Timer) vernünftig mit dem Server zu

    syncen.


    Das Prinzip von xineliboutput + vdr-fbfe kommt meinem use-case am nächsten:

    Zentraler Server und mehrere Clients. Dass die dasselbe anzeigen ist mir egal

    und sogar recht.


    Da mein gewurschteltes vdr-fbxe nach dem letzten Sytemupdate nicht mehr will,

    will ich nun mal selbst Hand anlegen.


    Dazu habe ich mal in den xine_input-code reingeschaut... und, naja, habe schon

    Schlimmeres gesehen, aber auch schon viel viel besseres. Sorry für das

    Gejammer. Ich kann aber nachvollziehen warum es so aussieht. Zeitmangel, über

    die Zeit gewachsen usw.


    Schade ist, dass es keine Architektur hat, xine code mit network code mit

    parser code mit multithreading, alles gemischt.


    Nun hatte ich die Idee, so schwer kann es doch nicht sein die Sachen

    aufzutrennen, client-code der mit dem Server kommuniziert und einen

    platformspezifischen Player zu nutzen, der die Wiedergabe regelt.


    "Auf die Schnelle" zwei kleine Skripte zusammengeschrieben, um einen

    proof-of-concept zu haben und siehe da, sogar mit Python + vlc spielt er

    Channel 4 FullHD mit 30% CPU Last (ich nehme an, vlc nutzt die

    Hardwarebeschleuniger).


    Was haltet ihr von der Idee, in diese Richtung weiter zu entwickeln. Ob es am

    Ende beim Python bleibt, oder doch C++ wird, weiß ich noch nicht. Aber das die

    Komponenten entstrickt werden und die Video/Audio-Sache wegdelegiert wird, dass

    ist non-negociable.


    Gibt es vielleicht Alternativen die das machen oder so ähnlich? Ich habe

    kodi-vnsi probiert, vor ein paar Jahren, lief nicht rund, und wie gesagt

    streamdev und vdr-fxfe.


    Hier ist mein aktueller code: https://github.com/pboettch/vdr-pyfe

  • Hi,


    das wäre schon immer mein Traum gewesen, einen zentralen VDR Server zu haben und nur die Ausgabe im Wohnzimmer abzuspielen ... ultimativ wäre es dann, wenn man dann auch noch mehrere Clients anbinden könnte, die aber nicht das gleiche anzeigen ...


    Muß mal schauen, wann ich Zeit finde, Deinen Code zu testen.


    Gruß, Space

  • Hmm, das kann doch der Standard-VDR schon immer, vorausgesetzt es stehen ihm genügend Tuner zur Verfügung. Frau guckt am TV im Wohnzimmer, ich laß über vdradmin/vlc am PC was im Fenster laufen, oder die Kodi-Box im Schlafzimmer oder ein Tablet über Wlan streamt auch vom VDR.

    --
    vdr User #2022 - hdvdr2: Lenovo SFF M83, Intel(R) Core(TM) i5-4670S, 12 GB Ram, zram-swap/tmp, ubuntu-focal, softhddevice-vdpau
    ddbridge-6.x mit 2xDVB-S2 und (Flex) 2xDVB-C/T Tunern, nvidia-GF720 SFF passiv (nvidia-dkms-460.67), System SSD btrfs,

    snapper, 8TB HDD XFS/cow /srv/vdr, yavdr-ansible-2.5.2-seahawk, vdr-epg-daemon mit Frodo-plugins, Kernel 5.12.0-rc7-xfsscrub

    vdradmin-am, live+webstreaming, vdrmanager (Smartphones als FB), ffmpeg-4.3.1-libfdk_aac, vdr-plugin-hbbtv. Folding@home läuft auf CPU.

  • Quote

    Hmm, das kann doch der Standard-VDR schon immer, vorausgesetzt es stehen ihm genügend Tuner zur Verfügung. Frau guckt am TV im Wohnzimmer, ich laß über vdradmin/vlc am PC was im Fenster laufen, oder die Kodi-Box im Schlafzimmer oder ein Tablet über Wlan streamt auch vom VDR.

    Das stimmt zwar, aber mit vdr-sxfe / vdr-fbfe hat man das OSD des Servers, was durchaus seinen Reitz hat.

    Eine Zeit lang habe ich bei Bedarf so den Server gesteuert (epgsearch, Einstellungen, Schneiden usw.) nur mit der Fernbedienung in der Hand.

  • OK, ich werde mal weiterschauen.


    Der Code in meinem repo ist sehr sehr spartanisch im Augenblick. Kein OSD, nur streaming. Es war, wie gesagt, nur ein proof-of-concept.


    Ich spinne mal weiter, wenn es wirklich gelingt alles zu entkoppeln, läuft der Client auch unter Windows. Ja, jetzt bitte die Flammenwerfer zücken. :flame1

  • Habe eine neue Version in repo gepusht. Ist jetzt standalone und nutzt vlc (genauer cvlc) zum video-abspielen. Umschalten und Aufnahmen funktioniert. Die Steuerung kann aber nur über einen externen vdr-(s|f)xfe geschehen, da ich noch nicht weiß wie keypresses abgeschickt werden.


    Es nimmt Form an.

  • Es gab da mal ein Plugin das mit dem VLC zusammengearbeitet und man im VLC ein OSD bekomment hatte...


    Keine Ahnung ob es das noch gibt:


    http://www.vdr-wiki.de/wiki/index.php/Ffnetdev-plugin

    -- wird überarbeitet -- VDR- Server: Gigabyte Brix 3150 - (2x Hauppauge DualHD DVB-C Sticks mit 4 Tunern) - Ubuntu 18.04 - Aufnahme und Streaming-Server
    Client Wohnzimmer: DQ77KB - i3 - Logitech z-5500 - Blaupunkt 39" TV - Openelec (Streaming)
    Client Büro: Asus AT3N7A-I , yaVDR0.6.1 (Streaming + Cutting) - 19" TFT
    Test Client1: Raspberry Pi + openelec

  • @pboettch


    MPV VDR-Streamdev-Client

    https://projects.vdr-developer…vdr-streamdev-client/wiki

    lief mit Ubuntu-14.04 1a.Leider ab Ubuntu-16.04/18.04 nicht mehr.

    Schade das sich keiner mehr darum kümmert oder weiterentwickelt.


    Gruss

    Wolfgang

    TT S2-6400 - saa716x kompilieren unter 20.04(Focal)

  • Es gab da mal ein Plugin das mit dem VLC zusammengearbeitet und man im VLC ein OSD bekomment hatte...


    Keine Ahnung ob es das noch gibt:


    http://www.vdr-wiki.de/wiki/index.php/Ffnetdev-plugin

    Das geht im Prinzip, wenn man in ffnetdev.c im cPluginFFNetDev Konstruktor die Zeile

    m_ClientName[0] = '\0';

    einfügt. (Dieser Client-String wird an die ffnetdev-Einträge in der remote.conf angehängt, und wenn da jedes Mal irgendein anderer Müll drinsteht, da uninitialisiert, dann will er jedes Mal die Tasten neu anlernen, weil die alten Einträge nicht erkannt werden.)


    Und in der Anleitung im Wiki steht noch die Option "--tcp-caching" drin, die es nicht mehr gibt, ersatzweise kann man wohl "--network-caching" verwenden, und außerdem ist offenbar die Option --rmtosd-password " " erforderlich.


    LG,

    Achim

  • Für den Fall das hier noch jemand liest. Aus Gründen konnte ich in den letzten Wochen nicht weiter am vdr-pyfe fummeln. Aber ich nutze das script quasi täglich auf dem raspi.


    Videodekoding läuft besser als jede andere Lösung, die ich bisher probiert habe und dank vlc auch mit Hardwareunterstützung.


    Das OSD dekodiere ich auch, aber kann es mit vlc nicht anzeigen. Da muss eine bessere Lösung her, ich habe auch schon eine Piste aber keine Zeit sie zu implementieren.


    Eingaben mache ich über die event-Schnittstelle von Linux.


    Beim Aufnahmenabspielen läuft der Buffer über, weil ich den Server nicht throttle (er sendet einfach alles, was da ist). Der CLient muss den Server informieren, wie weit schon geguckt wurde. Das habe ich noch nicht gerafft wieder das richtig geht (timestamp? einfach nicht weiter vom Socket lesen?)