[Prototyp] RPI Ausgabeplugin

  • Hallo allerseits


    Da ich schon lange auf ein schlankes Ausgabeplugin fürs RPI am warten bin, habe ich mich einfach mal darangesetzt. Inzwischen ist ein erster Prototyp lauffähig, den ich euch nicht vorenthalten will:



    Da fehlt natürlich noch einiges - dieser Post soll lediglich ein Zeichen sein, dass es an der RPI-Front weitergeht! Auch wenn das noch kein expliziter Aufruf zum Testen ist, freue ich mich natürlich auf Feedback!


    - Edit -
    Die neuen Versionen im Überblick:
    Version 0.0.2 vom 29.09. feat. H264
    Version 0.0.3 vom 02.10. feat. audio only & replay start/stop/pause
    Version 0.0.4 vom 14.10. feat. verbesserter Audio-Support
    Version 0.0.5 vom 17.11. feat. ruckelfreies Replay
    Version 0.0.6 vom 15.12. feat. Trick Speeds & Still Picture
    Version 0.0.7 vom 30.12. feat. Deinterlacer
    Version 0.0.8 vom 10.02. feat. GrabImage() und ScaleVideo()


    … neuere Versionen im Nachfolgethread oder die komplette History im Git auf vdr-developper.org .


    Grüsse aus Bern
    Thomas

  • Sehr interessant! Vor allem ein großes Lob dafür, dass gleich zu Beginn der Sourcecode verfügbar ist!


    Kennst du Details zu dieser "libilclient.a"? Für mich sieht es so aus, als wäre der Source dafür durchaus verfügbar:


    https://github.com/raspberrypi…rc/hello_pi/libs/ilclient


    Meine bescheidene Meinung wäre also: Entweder die Datei nimmt man als Bestandteil der Firmware an (dann gegen die im System installierte "libilclient" linken. Sofern es sowas gibt...) oder du solltest lieber die Source-Dateien (in ein Unterverzeichnis "ilclient") mit in deinen Source-Tree packen und die Library beim Kompilieren mit erzeugen. So wäre diese auch mit den für die entsprechende Distribution geltenden Kompiler-Parametern erzeugt.


    Ansonsten ein großes :tup für deinen Einsatz!

  • Hallo

    Meine bescheidene Meinung wäre also: Entweder die Datei nimmt man als Bestandteil der Firmware an (dann gegen die im System installierte "libilclient" linken. Sofern es sowas gibt...) oder du solltest lieber die Source-Dateien (in ein Unterverzeichnis "ilclient") mit in deinen Source-Tree packen und die Library beim Kompilieren mit erzeugen. So wäre diese auch mit den für die entsprechende Distribution geltenden Kompiler-Parametern erzeugt.

    Danke fürs Feedback - zweiteres habe ich getan, in einem Verzeichns namens "ilclient". Oder habe ich Dich falsch verstanden?


    Gruss
    Thomas

  • Ich hatte Tomaten auf den Augen...


    Klar. Da ist sie ja. Demnach ist der kleine "Fehler" nur, dass eine "libilclient.a" in deinem Archiv liegt.


    Ich nehme meine voreilige Kritik zurück und schlage vor das "clean"-Target des Makefiles so zu erweitern, dass "*~" auch im Unterverzeichnis "ilclient", und die "libilclient.a" selber, gelöscht werden.

  • Klar. Da ist sie ja. Demnach ist der kleine "Fehler" nur, dass eine "libilclient.a" in deinem Archiv liegt.


    Kann sein, dass es sich dabei um ein Überbleibsel von der Makefile-Bastelei handelt - werde ich noch löschen, ebenso die ilclient/*~-Dateien. Falls sich jemand beim VDR-Makesystem zu Hause fühlt, wäre ich über ein Review des Makefiles sehr erfreut! :]


    Gruss
    Thomas

  • :tup :tup
    Sehr cool.
    Ich habe mich schon gefragt welches meiner Prio 2 Projekte ich am WE machen werden.
    Nun ist das hier aber zu Prio 1 geworden. :D :D



    //Edit
    Nach dem ersten Blick bin ich verwundert wie "wenige" Code es ist. Dachte für ein Ausgabedevice braucht man deutlich mehr. So ist es mir aber lieber, dann steige ich da vielleicht schneller durch.

  • Unter ArchLinuxARM klappen die includes der ilclient-Dateien und ein paar anderer Bibliotheken aus der Firmware nicht, daher hole ich die aus den vom Firmware-Paket gelieferten Dateien:


    Ansonsten läuft das ja schon super mit SD-Kanälen (ich habe keine lokale DVB-Karte, nutze daher streamdev-client) :D - nur bei Radio-Kanälen habe ich keinen Ton und das Plugin hängt sich weg - am WE kann ich da vermutlich mehr dazu liefern, im Auslieferungszustand ist bei ArchLinuxARM journalctl nicht aktiv...
    Mute und Lautstärkeregelung funktionieren bei mir auch noch nicht und nach dem Spulen und springen in Aufnahmen wird die Bildausgabe arg rucklig, bis man die Wiedergabe stoppt und neu startet - vermutlich steckt das im "much more" auf der TODO-Liste :)

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    2 Mal editiert, zuletzt von seahawk1986 ()

  • Ansonsten läuft das ja schon super mit SD-Kanälen (ich habe keine lokale DVB-Karte, nutze daher streamdev-client) - nur bei Radio-Kanälen habe ich keinen Ton und das Plugin hängt sich weg - am WE kann ich da vermutlich mehr dazu liefern, im Auslieferungszustand ist bei ArchLinuxARM journalctl nicht aktiv...
    Mute und Lautstärkeregelung funktionieren bei mir auch noch nicht und nach dem Spulen und springen in Aufnahmen wird die Bildausgabe arg rucklig, bis man die Wiedergabe stoppt und neu startet - vermutlich steckt das im "much more" auf der TODO-Liste

    Das ist korrekt. Lautstärke, Audio-only und alles ausser Start/Stop bei Aufnahmen fehlt und ist als nächstes dran. Das erste Ziel war, Bild und Ton synchron zum laufen zu bringen und beim Kanalwechsel jeweils alles sauber wieder auf und ab zu bauen. Aktuell schaut der Code recht übersichtlich aus, aber als OpenMax / OpenVG-Neuling hat mich das einiges an Nerven gekostet. Doch mit der aktuellen Grundlage sollte der Rest machbar sein...


    Gruss
    Thomas

  • Hi,


    ich bin mal wieder begeistert, sogar ohne es getestet zu haben.
    Mein erster Gedanke war: hoffentlich gibt's diesmal die Sourcen, damit nicht schon wieder ein viel versprechendes Project den Bach runter geht,...
    Aber meine Sorge war glücklicherweise unbegründet. Danke schon mal, ich werd's sicher dieses Wochenende testen :)


    Claus

    MLD 5.5 mit vdr 2.6 - lirc yaUSBir - Octopus NET S2 - SCR - XFX GeForce 9300 mit Intel E3200 - 2GB RAM - WD Green 12TB HDD - SanDisk 64GB SSD - Lian Li PC-C37B - Samsung LE40A559
    MLD 5.5 mit vdr 2.4 - Raspberry Pi 3 - rpihddevice
    MLD 5.5 mit Squeeze Play - Raspberry Pi 2 - 32GB SD - 7" Touch TFT

  • Lässt sich ArchLinux ARM cross-kompilieren?


    Es gibt eine fertige distccd-Toolchain dafür, die ich benutze: https://github.com/WarheadsSE/PKGs/tree/master/distccd-alarm damit sind die Zeiten zum Bauen durchaus akzeptabel. Ich baue aber alles direkt vom Raspberry aus, nicht komplett auf einem anderen Rechner.


    Das Plugbuild-System von Arch Linux ARM war mir zu komplex und zu schlecht dokumentiert: https://github.com/archlinuxarm/plugbuild

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    Einmal editiert, zuletzt von seahawk1986 ()

  • Hallo Thomas,
    vielen Dank für dein neues Projekt. Ich werde das demnächst auch mal testen und hier berichten....
    Viele Grüße, Uwe

  • Zum Crosskompilieren eines Kernels habe ich mir die Crosschain komplett auf dem Desktop gebaut. Hier war mir distcc einfach zu langsam.


    Aber letztlich ist es in der Tat so, dass Kompilieren direkt auf ARM um Längen einfacher ist. Die ARM-Dinger brauchen ja kaum Strom. Kompilieren anstarten und dann einfach über die Nacht rennen lassen.

  • Fantastic work. Compiled vdr with streamdev-client and rpihddevice tonight and it worked surprisingly well. Fast channel switches and perfect picture quality on the channels (even though they are SD).


    Can't wait to follow this project in more detail. Next steps for me is to get a libcec-deamon working so that I can use the remote controller of the TV.


    Once again thanks for a very promising plugin.

  • Fantastic work. Compiled vdr with streamdev-client and rpihddevice tonight and it worked surprisingly well. Fast channel switches and perfect picture quality on the channels (even though they are SD).


    Can't wait to follow this project in more detail. Next steps for me is to get a libcec-deamon working so that I can use the remote controller of the TV.


    Once again thanks for a very promising plugin.


    Hello
    You should take a look at my howto:
    Raspberry PI über CEC steuern

  • Ich habe etwas gebraucht bis ich alles so weit hatte.
    Nun läuft das Plugin und das OSD sieht auch gut aus aber wenn ich mir ein Video über streamdev-client holen will, dann hängt sich das Plugin auf und der Watchdog schlägt zu.


    Ich glaube das Problem sind diese Zeilen:


    Code
    Sep 29 00:26:20 raspberrypi vdr: [13290] rpihddevice: OmxSetVideoCodec()
    Sep 29 00:26:20 raspberrypi vdr: [13287] rpihddevice: OmxError(UnsupportedSetting)
    Sep 29 00:26:20 raspberrypi vdr: [13290] rpihddevice: failed to enable port buffer on video decoder!
    Sep 29 00:26:20 raspberrypi vdr: [13290] rpihddevice: OmxSetVideoCodec() end



    Hier noch mal alles zusammen

  • Zwar immer noch ein Prototyp, aber das Plugin wird nun immerhin seinem Namen gerecht:



    Aktuell habe ich zwei Baustellen:


    - Audio only
    Leider habe ich als cDevice keine Möglichkeit herauszufinden, ob überhaupt Videodaten kommen oder nicht. Beim 'OMX-Baukasten' ist es so, dass ich dem Takt im Voraus sagen muss, ob er Bild und Ton synchronisieren soll. Momentan klappt daher Audio only nicht, da der Clock nicht anläuft, sondern auf ein Frame aus dem Video-Decoder wartet. Hier bin ich für kreative Vorschläge offen!


    - Replay
    Hier muss ich wohl noch einiges umbauen und eine Art Buffer-Management implementieren. Erst wenn das klappt und die Poll()-Methode funktioniert, kann ich mich um Play/Pause und Trickspeeds kümmern. Aber da muss ich so oder so nochmal über die Bücher...


    Grüsse aus Bern
    Thomas

  • Das mit dem Bild bei h264 klappt, leider überträgt Kabel D für die Sender nur DD-Ton, keine normales Stereo-mpeg - gibt es eine Chance da noch Dolby-Digitalton zu unterstützen?

    Hier bin ich für kreative Vorschläge offen!


    Könnte man eventuell wie bei xineliboutput eine "nosignal.mpg" bzw. eine "radio.mpg" nutzen und daraus das Video-Bild holen?

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • vorhin eingeschaltet und läuft nun ohne das ich was geändert habe ?(


    Jetzt ist meine SD hinüber. :motz4


    Was ich aber feststellen könnte war das die PES Erkennung in PlayVideo nicht ganz richtig ist.


    H264 NAL AUD Access Unit Delimiter (0x00) 0x00 0x00 0x01 0x09


    Im Code wird aber nicht die führende (0x00) berücksichtigt.
    Daher findet er bei H264 Streams nie einen Anfang.
    Das alleine reicht aber nicht aus. Weiter bin ich aber nicht gekommen.

  • Zitat

    - Audio only
    Leider habe ich als cDevice keine Möglichkeit herauszufinden, ob überhaupt Videodaten kommen oder nicht. Beim 'OMX-Baukasten' ist es so, dass ich dem Takt im Voraus sagen muss, ob er Bild und Ton synchronisieren soll. Momentan klappt daher Audio only nicht, da der Clock nicht anläuft, sondern auf ein Frame aus dem Video-Decoder wartet. Hier bin ich für kreative Vorschläge offen!


    schau Dir mal mein pvr350-Plugin (1.7.4) an. Der Decoder konnte keine Audio-only-Daten dekodieren, sondern brauchte dazu auch Video.
    Audio-only-Streams beginnen immer mit einem Audio-Paket. Streams mit Video+Audio hingegen mit einem Video Paket. Die Erkennung habe ich dann über PlayAudio und PlayVideo gemacht. Ob das bei h264 genauso geht, weiss ich nicht.
    Für Audio-only streams erzeugt das Plugin dann dummy-Video-Pakete mit einem Schwarzbild.


    Reinhard Nissl war mir damals eine große Hilfe, ohne ihn hätte ich das nicht hingekriegt.

    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

Jetzt mitmachen!

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