Beiträge von Hawhill

angeblich so 7-9W. Ich benutze das von Pollin dazu verkaufte 5V/3A-Netzteil, aber im µC-Thread schreiben auch manche, dass sie 2A oder 2,5A-Netzteile nehmen und es läuft. Hängt evtl. auch etwas davon ab, was man so am USB-Port noch dranhängt.

stevie: Hm, komisch, dass keine Ausgabe kommt. Muss ich mir noch mal angucken. Eigentlich müsste auch das mit dem DFBTerm dazu gehen, allerdings fürchte ich, dass beide (VDR-Plugin und Terminal) jeweils im "FULLSCREEN"-Modus laufen (DirectFB) und dann streiken wenn das jeweils andere läuft. Schau ich mir sonst auch noch mal an. Allerdings werde ich erst Sonntagabend, eher noch Anfang nächster Woche dazu kommen, glaube ich.

herrlado: Öhm, also ob das mit der Bootloader-Signatur überwindbar ist, weiß ich wirklich nicht. Ich habe Zweifel. Obwohl man wohl einen flashen könnte, der via TFTP beliebige Images laden kann - aber sicher bin ich mir da nicht. Vielleicht mal im µC-Thread nachfragen... Allerdings macht es wohl derzeit kaum Sinn, einen anderen Kernel als den mitgelieferten zu verwenden. Und für vieles der weiteren Funktionalität ist auch der Vendor-Softwarestack wichtig. Daher arbeite ich eigentlich immer nur mit einem quasi erweiterten Originalsystem. Im µC-Thread sprach aber glaube ich jemand davon, Debian drauf laufen zu haben.

Die Box ist aber MIPS-basiert (Mips 4kec Core im Lower-Endian-Modus), nicht ARM.

Als reiner Rechner ist das Ding auch eher grenzwertig, 300MHz sind dann so viel auch nicht. Bei etwa 3-4 MByte/s Durchsatz auf dem Netzwerkinterface ist die CPU auch ausgelastet.

Das Ding hat zwar einen eingebauten Kartenleser, aber wie der angesteuert wird, weiß ich nicht genau (bzw. eigentlich doch: Das macht auch der halserver-Daemon, aber der ist ein closed-source-BLOB und ich habe keine Ahnung, was der für Interfaces anbietet).

Die Kiste hat aber einen seriellen Port - auf der Platine und mit TTL-Pegeln. Das heißt also, dass ein RS232-Pegelwandler nötig ist, plus ein ganz klein wenig Lötarbeit.

Ist hier im Forum ja schon beinahe OT - ich schlage daher vor, dazu den Wiki-Artikel auf mikrocontroller.de zu Rate zu ziehen. Dort ist angegeben, wo die Kontakte für die serielle Schnittstelle sind.

Geht ohne großartige Umschweife. Es gibt tatsächlich ohne weitere Arbeit den Telnet-Zugriff direkt auf 'ne Root-Shell. Out-of-the-box.

Was noch nicht geht ist zB der Zugriff auf USB-Storage. Dafür müssen die usb-storage- und SCSI-Module geladen werden, da findest du auf meiner Seite zB ein Archiv, das die enthält. Ein FAT-Treiber ist dann bereits auf der Box im Kernel drin, falls du JFS benutzen willst würdest du wiederum einen Treiber auf meiner Seite finden (wie auch zB für NFS oder CIFS, falls du nicht mit USB-Storage sondern lieber Netzwerkfreigaben arbeiten willst).

Ansonsten beschreibe ich auf meiner Seite einige verschiedene Details. Etwas mehr Platz nimmt dort der settings2.xml-Exploit ein, aber aus reiner Nutzerperspektive ist nur der Abschnitt mit dessen Einrichtung interessant. Und das ist dann wichtig, wenn man eigene Sachen automatisch beim Booten starten können will. Macht vorerst wohl nur bei Boxen mit Flash Sinn - keine Ahnung, wie das bei Boxen ohne aussieht.

Ansonsten reicht es in der Tat aus, die Sachen einfach auf nem Stick zu haben. Falls du auch dynamische Bibliotheken auf dem Stick hast, musst du u.U. noch den Loader-Pfad entsprechend konfigurieren (siehe "man 8 ld.so" auf nem Linux-System). Um einen Autostart hinzubekommen, könntest du eben auf den settings2.xml-Exploit setzen.

Naja, das mache ich auch, indem ich quasi einmal "Close" und ein neues "Open+Play" mache. Nur fängt das Ding erst dann mit dem Abspielen an, wenn der Buffer einen gewissen Füllstand erreicht hat. Aber ehrlich gesagt habe ich gar keine Lust, da noch weiter dran zu feilen, da es tempo-mäßig für mich völlig reicht....

lola: Kann ich nicht testen, muss mal wer mit entsprechendem Equipment machen. Das Strukturbild ist aber nicht so das gelbe vom Ei, um daraus technische Eigenschaften abzuleiten. Das muss noch mal ein Marketing-Mensch in der Mache gehabt haben. Besser ist das technische Referenzhandbuch, das irgendwo aufgetaucht und im µC-Thread verlinkt ist (wenn auch für eine minimal abweichende Xilleon-Plattform).

henfri: Naja, dafür musst du sie kompilieren. Und das geht mit einer Toolchain bzw. einem Build-Environment. Auf meiner Page steht dazu gar nicht viel (Text), denn letzten Endes unterscheidet sich das nicht davon, was man so braucht um ganz generell auf irgendnem OS seine eigene Software zum Laufen zu bringen... Du kannst halt einfach entweder auf deinem PC die Cross-Toolchain von Motorola installieren oder auf der Box (d.h. auf einem an die Box angeschlossenen externen Medium oder auf einer Netzwerkfreigabe) die von mir zusammenkompilierte native Toolchain. Zum Kompilieren von Software, zu den Build-Systemen (make, autotools) gibt es eigentlich nichts VIP-spezifisches zu sagen, da kann man sich an ganz reguläre, universelle Dokumentation halten.

1. weiß ich nicht, welche hat der denn bzw. wo finde ich das schnell aufgelistet? Auf den ersten Blick würde ich sagen: Sollte gehen.
2. hängt etwas von der Vorerfahrung ab, würd' ich sagen. Wenn du nur das Installieren und nicht das Lernen meinst: Ein Download von Motorola (x86-SDK) oder von meiner Page (natives Mipsel-SDK, auch schon mit einiger weiterer Software), entpacken, fertig.

Subjektiv würde ich sagen: Ein bisschen. Viel mehr geht wohl auch erstmal nicht... Jedenfalls habe ich noch keinen Weg gefunden, den Stream-Puffer im Vendor-Software-Stack kürzer zu machen - und ich glaube, das wäre der einzige Punkt, an dem sich da noch was verbessern ließe. Also wird es bei etwa 3-3,5s wohl bleiben.

Habe gerade eine neue Version (0.1.2) veröffentlicht, die VDR 1.7.x-fähig ist und das auch aktiv insofern benutzt, als dass TS-Daten an den VIP-Softwarestack übergeben werden. Damit haben die Abbrüche/Unterbrechungen bei mir ein Ende. Ein paar Traces haben mir gezeigt, dass die Box nur bei TS-Daten eine ordentliche Zeitsynchronisation macht.

In der Minidistribution ist jetzt auch epgsync mit drin.

Dafür habe ich das Audio-Transcoding vorerst rausgeworfen. Wenn das jemand benutzt hat und es in vorigen Versionen wirklich funktioniert hat, könnte ich drüber nachdenken, das wieder einzupflegen.

Diese Version ist bisher das zuverlässigste, was ich da bisher so gebastelt habe.

Leider stimmt derzeit die Zeitzone nicht, fällt mir jetzt erst auf, da ja der EPG jetzt prinzipiell funktioniert.... Quick-Fix wäre, das händisch via plugrc zu setzen. Ich werde da noch mal die Minidistribution updaten, komme aber erst am Wochenende dazu.

Nur kurz als Update: Viel stabiler wird's erstmal nicht. Ich weiß immer noch nicht, woran es liegt, dass es die kurzen Aussetzer gibt, aber das Verhalten stabilisiert sich dann, nachdem es 2-3 Aussetzer gegeben hat. Es liegt wohl nicht am Videostream - jedenfalls triggern Wiedergaben das Problem nicht.
Generell ist bei mir der Stream aber schon verdammt stabil.
Bei VDR 1.7.16 bin ich auch schon recht weit, nur geht mir da gerade das geänderte Verhalten beim Schreiben in transfer.c auf den Zeiger. Naja, wird nicht so'n Ding sein und geht für Live-TV schon ganz gut, nur für Wiedergaben muss ich da noch mal ran. Das zeigt übrigens das gleiche Aussetzer-Verhalten.

Ich kann mir vorstellen, dass es an der Zeitsynchronisation/ntpd liegt. Die startet immer mit einer Justier-Phase und das ist hier u.U. problematisch. Wohlgemerkt tauchen die Probleme auch auf, wenn kein ntpd läuft. Ich nehme sogar sicher an, dass der laufen muss - und zwar so früh wie möglich auch so genau wie möglich.

So, ich habe jetzt eine neue Version (mittlerweile 0.1.1) fertig. Die erlaubt auch die Wiedergabe von Aufnahmen - allerdings noch kein Vor-/Zurückspulen. Springen geht aber.

Außerdem kann das Plugin nun die Lautstärke setzen, Stummschalten und auch das Wide-Screen-Signal ("16:9-Schaltspannung") am Scartausgang schalten.

Es funktioniert jetzt ganz ohne X und das "tv"-Frontend, so dass noch etwas mehr RAM zur Verfügung steht. Es benutzt die "libvipipcstack", die ich - jetzt doch in C - geschrieben habe und die Kommunikation mit dem IPC-Stack der Box erlaubt. Libvipipcstack ist mitsamt der Dokumentation des IPC-Mechanismus der Box (und einer Grobbeschreibung der Softwarekomponenten auf der Box) hier zu finden: http://hilses.de/vip1710/libvipipcstack/

Nach wie vor baut die Minidistribution - immer noch unter http://hilses.de/vip1710/ zu haben - auf VDR 1.6.0 auf. Ich werde mich demnächst mal an VDR 1.7.x versuchen.

Ich hab' jetzt - wo auch die Aufnahmen funktionieren - mal ein CIFS-Modul und das entsprechende Mount-utility mit aufgenommen, da es ja jetzt interessant wird, das /mnt/video-Verzeichnis vom VDR-Server einzubinden.

Leider ist das alles wohl noch nicht ganz der Weisheit letzter Schluss -- ich bekomme hier und da manchmal Aussetzer. Woran die genau liegen muss ich erst noch untersuchen. Insgesamt gefällt mir der Fortschritt aber so gut, dass ich das schon mal so veröffentliche. Die Version, die ich dann wirklich für benutzbar halte, wird dann irgendwann die 0.2.0, denke ich. Das runvdr.sh-Script ist ein wenig angepasst, so dass VDR jetzt bei einem "restart" auch wirklich neu gestartet wird.

Ich hab' hier bestimmt noch irgendwas vergessen, also fragt ggf. gern nach. Und ich freue mich über jeden, der sich den Source vornimmt, nur so nebenbei....

Zum Thema Start- und Umschaltzeiten: Da ist sicher noch einiges 'rauszuholen (jedenfalls bei der Startzeit, für die Umschaltzeit muss ich sehen, ob ich das überhaupt beeinflussen kann) und bisher kein Blumenpott mit zu gewinnen. Startzeit wohl so ca. 90s und Umschaltzeit würd ich sagen etwa 3-3,5s.

Das Bild hat - so weit ich das beurteilen kann - eine ganz ordentliche Qualität. Das Wide-Screen-Signalling macht da tatsächlich einen gewissen Unterschied.

Edit2: Jetzt Version 0.1.1. Bei mir gibt es noch alle 8-15 Minuten einen 2s-Aussetzer. Der liegt wohl leider aber an der Software der Box, da geht plötzlich ein Prozess flöten. Ich hab' noch nicht wirklich herausgefunden, warum. Ist aber, da der Fall sauber abgefangen wird, jetzt eigentlich ziemlich benutzbar. Das plugrc-Skript ist etwas optimiert, so dass der VDR wirklich startet, sobald es geht. Damit kommen wir, wenn ich richtig gemessen habe, aber trotzdem über knapp 90s.

ich kompilier' normalerweise nie was mit "-O3". Zuviele Knieschüsse, jedenfalls mit älteren GCCs. Statt "-march=4kc" nehme ich normalerweise "-march=mips32r2 -msoft-float". Beim VDR allerdings hab' ich das glaube ich beim "-O2" ohne weitere Angaben belassen, so wie geliefert.

Die "SOCK_SEQPACKET"-Sachen hab' ich bisher nie gesehen.

Allerdings: Artefakte? Das hört sich nach unvollständig ankommendem Stream an. Entweder schon vom Server her, oder aber aber dann auf der Box. Hast du dem "streamer"-Prozess via /etc/streamer_conf.xml etwas mehr Puffer gegeben? Bei mir müssen es mindestens so 500ms sein. Und das muss in der Datei stehen _bevor_ der Streamer-Prozess gestartet wird... Eine WLAN-Strecke zwischen Box und VDR-Server ist auch immer problematisch, glaube ich.

Naja, am Wochenende werd' ich wohl die Plugin-Umstellung auf Unix-Domain-Stream-Sockets machen (statt derzeit die UDP-Geschichte, bei der mich diese Symptome ehrlich gesagt nicht sehr wundern). Meine IPC-Anstrengungen sind jetzt schon so weit fortgeschritten, dass ich mit eigener Software den "tv"-Prozess replizieren kann und dadurch kein X und keinen Browser mehr brauche und Streamwiedergabe, -stopp initiieren und Lautstärke ändern kann.

Hi, ja, das mache ich ganz bestimmt. Ich werde in wenigen Tagen meinen Resturlaub aus 2009 zu verbrauchen haben und bei diesem miesen Wetter bietet sich es geradezu an, da mit der 5-Euro-Kiste rumzuspielen

Ich baue derzeit aus meinen Erkenntnissen Prototypes für die IPC-Messages die verschickt werden. Ich baue quasi die libtoi.so einmal nach. Ist natürlich an vielen Stellen auch etwas Raten dabei. Das ist schon ziemlich strukturiert und ich werde es wohl recht einfach in rein textuelle Beschreibungen umbauen können. Wie oben schon versprochen gibt es daneben auch bald diesen Code.

So weit ich das jetzt schon absehen kann, lässt sich damit insbesondere die Streamwiedergabe (aufbauend auf dem Vendor-Softwarestack) recht gut steuern (Start, Stop, Forward/Rewind, Springen an bestimmte Stelle). Ist aber noch nicht ganz in trockenen Tüchern. Außerdem läßt sich anhand der Struktur auch gut nachvollziehen, welcher Prozess welche Aufgaben hat.

stevie101: Genau so wie du's beschreibst. Perspektivisch wohl ohne "toish", da ich das problemlos selbst implementieren kann (der IPC-Aufruf zum Starten einer Streamwiedergabe ist sehr simpel gestrickt). Zu teilen gibt's eigentlich auch nicht viel, da VDR OSD und Videodaten ohnehin gesondert verwaltet.

Tja, hier und da tauchen bei der Software der Box zwar die magischen vier Buchstaben "HDTV" auf, allerdings glaube ich kaum, dass hier Hoffnung besteht. Wäre das überhaupt via Scart-RGB/FBAS/S-Video zu übertragen? Die Hardware-Plattform unterstützt zwar das Anbinden eines DVI/HDMI-Transceivers, aber ein solcher ist meines Wissens nicht auf dem Board.

Ansonsten für diejenigen, die sich auch für die IPC-Strukturen der Box interessieren: Ich hab' mal ein Tool gebastelt, das via LD_PRELOAD die entsprechenden Aufrufe abfängt und mitloggt. Dazu ein entsprechendes Dump-Programm. Zu finden im "sockdump"-Archiv auf http://hilses.de/vip1710/. Im Ergebnis sieht man damit, was die Programme so für Daten austauschen und wie sie bestimmte Softwarefunktionen - wie zB. das Starten der Streamwiedergabe - ansprechen. Daneben bastele ich gerade an einem Lua-basierten (da ich mit Lua schneller prototypen kann) Tool bzw. einer Lua-Bibliothek, die diese IPC-Funktionen nachbastelt. Das veröffentliche ich wohl auch noch im Laufe des Abends. Mit den Erkenntnissen aus dieser Bastelei werd' ich mich dann demnächst mal noch mal an das VDR-Plugin setzen.

stevie: fein
Nee, also via softdevice wird das (so einfach) nichts. DirectFB nutze ich nur für das OSD, da die Set-Top-Box das per Hardware über das Videobild mischen kann. Es gibt aber nicht etwa ein MPEG-Decoder-Interface in DirectFB, das direkt mit der Box umgehen könnte. D.h. die Videostream-Wiedergabe läuft über den Software-Stack, der mit der Box kommt (insbes. Prozess "streamer"). Und genau an dieser Schnittstelle muss ich noch feilen, damit das mit Aufnahmen klappt.
Für VDR 1.7.x war ich zu faul, da schon wieder neuere DVB-Header nötig wären, als ich gerade da hatte. Eigentlich sollte es aber nicht problematisch sein, da einfach ein paar aktuelle für zu nehmen -- schließlich wird damit ja eh keine Hardware bzw. kein (DVB-)Kerneltreiber angesprochen. Um VDR 1.7.x würde ich mich sonst frühestens kümmern, wenn das Plugin etwas runder läuft.

Ehrlich gesagt trenne ich im Kopf bisher nicht nach Mit-Flash und Ohne-Flash bzw. Kreatel oder Motorola. Allerdings setzt die Lösung, wie ich sie derzeit benutze, darauf, dass Flash da ist - einfach um ein paar Autostart-Sachen zu machen. Ich kann auch nicht ohne Flash testen, da meine beiden Boxen welchen haben. Softwaremäßig müsste alles auch ohne Flash laufen, dazu müsste aber - ähnlich dem "motorola.sh"-Skript, das andere für ihre Lösung gestrickt haben - am besten noch ein Skript her, dass die Sachen in ein Live-System pumpt. Oder vielleicht auch ein entsprechendes per NFS ausgeliefertes root-FS oder so, aber wie gesagt fehlt mir da die Möglichkeit, mal näher nachzuforschen.

Also wer wirklich nicht selber unbedingt viel basteln will, braucht die jetzige Lösung nicht ausprobieren (es sei denn, sie/er will einfach nur TV damit gucken). Ist eher für Bastel-Interessierte. Mit Aufnahmen sollte das auch irgendwann funktionieren, aber dann sag' ich natürlich (oder gern auch wer anderes, der's zum Laufen bekommt) noch mal bescheid.

Kurz zur Sache, weshalb ich nicht die mitgelieferte libtoi.so benutze: Ich hab' den Quellcode und damit leider auch die Header nicht. Und es ist ne C++-Bibliothek, deshalb war mir das Header-Raten zu komplex. Gemessen daran, wie einfach die IPC-Messages aufgebaut sind, ist es einfacher, das zu reimplementieren. Außerdem könnte noch eine Art Zugriffskontrolle in der libtoi.so versteckt sein. Will ich mich nicht mit herumschlagen.

Ich bin auch immer an Erfahrungsberichten interessiert. Allerdings ist mir mittlerweile klar, dass ich das Kommunikationsschema ändern muss: Bei den UDP-Sockets, die ich derzeit nutze, um die MPEG-Pakete an den Vendor-Softwarestack zu übergeben, habe ich keinen Anhaltspunkt dafür, wann der Puffer in besagtem Softwarestack voll ist und damit ab welchem Zeitpunkt der Puffer schlicht überläuft. Da muss ich wohl auf etwas Stream-basiertes umstellen (TCP oder Unix Domain Stream Sockets, die kann die VIP1710 auch, aber beides nur im Client-Betrieb). Bei der Wiedergabe von Aufnahme spuckt VDR damit den Datenstrom der Aufnahme ohne Unterbrechung direkt aus, da streckt die Streamwiedergabe irgendwann bloß die Hände nach oben und nimmt nicht wirklich mehr was an.

Derzeit frickele ich eine client-Bibliothek für den IPC-Mechanismus des Vendorstacks zusammen. Damit lässt sich theoretisch zum einen die Steuerarbeit übernehmen, die "toish" macht, zum anderen lässt sich damit wesentlich kleinteiliger (soll heißen: PID-Auswahl, Stop, möglicherweise Ffwd/Rew, Lautstärke etc.) die Streamwiedergabe steuern. Ist aber viel trial&error. Aber sieht doch sehr machbar aus.

Das beides verbandelt könnte doch noch ein ganz akzeptables Ergebnis bringen...

Hab angefangen, das PVR350-Plugin zu einem Plugin für die VIP1710 umzuschreiben. Läuft bisher nur für TV Live, Aufnahmen wiedergeben geht noch nicht.

Auf http://hilses.de/vip1710 ist unten in der Misc-Section die Anleitung (Distro auf USB-Stick packen, damit - und settings2.xml/myrc-Hack - booten, dann LIRC konfigurieren, testen und dann auf dem USB-Stick in der plugrc in der letzten Zeile den Autostart einkommentieren). Source für das Plugin gibt's da auch. VDR 1.6.0 läuft problemlos auf der Box. Das Streamdev-Client-Plugin ist mit in der Distro und braucht noch entsprechende Konfiguration in setup.conf (oder via OSD) und eine korrekte channels.conf. Beide finden sich in /etc/vdr auf dem USB-Stick (bzw. der USB-Platte, was ich für Aufnahmen wohl eher anregen würde...).

Sieht alles recht kompliziert aus. Ich werde mir erstmal wohl pvr350 als Vorlage nehmen. Das ist recht stringent und nicht zu kompliziert gemacht, die pvr350 wird über einen 720x576x32 framebuffer angesprochen (den hat die VIP1710 auch, muss nur auf directfb umgestrickt werden) und das Video bekommt sie über ein entsprechendes device in einem Format, das auch die VIP1710 verstehen sollte (nur für den Transport muss was neues her). Außerdem implementiert das Plugin bereits Audio-Reencoding und -Remuxing (wobei abzuwarten bleibt, ob die Box das überhaupt packen würde).
Natürlich heißt das dann aber, dass VDR mit dem daraus entstehenden Plugin am besten auf der Box selbst laufen sollte. Dann via streamdev-client an einen anderen VDR angebunden. Mal gucken, ob am Ende was dabei herauskommt, ich verspreche _nix_.

Für diejenigen, die gerne beim ffnetdev-Ansatz fortsetzen oder auch nur mal reinschnuppern wollen, liegt jetzt auf http://hilses.de/vip1710 ein simpler Nur-Anzeige-VNC-Client, der recht speziell dafür gemacht ist (bzgl. Alpha-Management, läuft via directfb) mitsamt Source. Da der nur anzeigen kann, muss der VDR dann anders bedient werden. Ich nutze dafür LIRC auf der Box (siehe auch dort auf der Seite für Binary und Kernelmodul) im Server-Betrieb und einen LIRC als Client auf dem VDR-Rechner.
Also: LIRC zum laufen bringen (und entsprechend auf der Box eine Fernbedienung anlernen), dann

toish uri LoadUri tcp://<vdr-ip>:20002 video/mpeg

und

vipvnc <vdr-ip>:20001

Viel Spaß damit, für mich war's aber sehr instabil - obs nun an meinem VDR oder Netz liegt oder doch - wohl wahrscheinlich - an der Implementationsstrategie von ffnetdev, keine Ahnung.

glotzipapa: Keine Ahnung, worauf du noch hinauswolltest bei den Streaming-Quellen. Du hattest ja noch einmal nach den Pipes gefragt. Für mich war das insofern neu, als dass alle Web-Frontends, die ich zum Einspielen für die VIP1710 kenne, sämtlichst HTTP-Transport nutzen, die "file:"- und "tcp:"-URIs waren mir neu.

Ich glaube auch, dass xineliboutput dann besser geeignet ist, FFnetdev-plugin macht wirklich nur einen Client mit. Bist du dir sicher, dass das OSD mit in den MPEG2-Videostrom codiert wird? Ich hab' eher das Gefühl, der TS wird noch plugin-spezifisch mit den OSD-Daten gemuxt. Aber ich guck's mir mal in Ruhe an. Ah, sehe jetzt, dass kiwix auch schon mehr für mich zum Lesen gepostet hat. Na denn, langweilig wird's mit dieser Box jedenfalls nicht

Glotzipapa: Naja, ich wusste davor halt nur davon, dass die Box HTTP-Streaming kann. RTPS kann sie wohl auch, da hab' ich keine Verwendung für. Mit "aus ner Pipe" meinte ich exakt das - sie kann via "file:///the/pipe" named pipes benutzen. Dazu ist interessant, dass die named pipe auf ".ts" endend benannt sein muss, damit TS-Streams funktionieren (jedenfalls bei meinen Tests). PS-Streams gehen mit ".mpg" als Endung. Aber letztlich brauche ich wegen Raw-TCP-Streams gar keine Pipes in Verbindung mit dem ffnetdev-Plugin.

Heute abend setze ich mich mal an das OSD, die libvncclient sieht da vielversprechend aus, was den VNC-Part angeht.

TEN: Gibt Xineliboutput denn einen MPEG2-Stream mit eingebettetem OSD aus? Muss ich mir mal genauer angucken. Im Prinzip sollte das wohl möglich sein und soweit ich sehe gibt es da ja bereits Clients zB für die DXR3, und die VIP1710 hat da recht ähnliche Fähigkeiten (oder eher: Einschränkungen), was die Stream-Kompatibilität angeht.