softdevice2net - Netzwerk statt Framebuffer

Zitat

Original von Nano
Mal eben kurz eine kleine Zwischenfrage:

Warum hat eigentlich niemand einmal die Dreambox DM5620 als Thin Client in Betracht gezogen?

HW aus Entenhausen ist böse

Zitat

Der Prozessor der MediaMVP und der DM5620 ist doch der gleiche soweit ich weiss(IBM STBx25xxx).

Japp ....

Zitat

Der Vorteil hier wäre, dass schon jede Menge freier Code zur Verfügung steht, oder? Das einzige Binary File ist doch das File dream.o, welches das Kernel-Modul zur Hardwaresteuerung darstellt.

Korrekt ... ist die Frage, inwieweit die Treiber-Schnittstellen (DVB, OSD, IR) zur dream.o beschrieben/ersichtlich sind ... du müsstest für den VDR halt ein neues DVB-Device implementieren ...

Zitat

Vielleicht könnte man hier mal ansetzen. Hätte ich das eher gewusst, hätte ich mir vermultich eher eine DM5620 geholt. Klar ist sie auch teurer, aber mehr Potential hat die Dreambox meiner Meinung nach.

Entenhausen wird dir wohl ne Testbox für sowas zur Verfügung stellen (einfach mal anfragen).

BTW: Hast du bezüglich der OSD-Over-Net-Umlenkung schon was an Code? An sowas wäre ich stark interessiert ....

arghgra

Mal eine ganz "blöde" idee - warum eigentlich nicht der mplayer ??
Ich nutze den als streaming client auf meinem toshi notebook. lief immer super, auch über stunden (im sommer-im garten) und das unter xp !!

Der mplayer hat doch ein eigenes osd, kann man damit nicht die wichtigsten funcs des vdr nachbilden und ansonsten über svdr mit dem vdr kommunizieren??? Könnte sourcen für die svdr-kommunikation beisteuern.

Nano: wie weit bist du denn ? wenn du tester brauchst gerne.

klaus

Zitat

Original von Nano

Nunja. Sowas würde wohl eher zur Dauerleihgabe werden müssen, da ich nur begrenzt Zeit für dieses Hobby habe. Leider...

Kommt mir bekannt vor ....

Zitat

Erinnerst Du Dich an die ProxyDVB Lösung, die Vadim Epmak mal auf der ML vorgestellt hat? Dort hat er OSD maessig auch am VDR rumgebastelt, um den Code über das Netz zu schaufeln.
Ich habe das im Wesentlichen übernommen und daraus ein Mini-Plugin gemacht. Ist absolut rudimentär momentan. Aber es reicht immerhin, um das OSD über das Netzwerk zu meinem Windows-Compi zu senden, um es dort darzustellen.
Kannst Du Dir ja mal anschauen.

Gruss, Nano

Ahh - guter Tip - werde ich mir mal anschauen ....

arghgra

Hatte die letzten Tage recht viel zu tun, deswegen melde ich mich erst jetzt.
Nano: Wie funktioniert denn deine Lösung? Werden OSD-"Bilder" Rübergeschaufelt, (Quasi Bilder, die dann nur noch per overlay über den videostream gelegt werden, oder sind es die Daten aus denen der Client dann das OSD zusammenbaut? Unterschied liegt hier ja in der Menge des auf dem client nötigen Programmieraufwandes... An erstere Lösung habe ich ehrlich gesagt noch gar nicht gedacht...

Okay... Dann hast du vermutlich recht... Du bastelst da also gerade an einer windows-lösung - Da ich die mailingliste nicht verfolge, weiß ich nicht wirklich, was du mit ProxyDVB meinst - Könntest du mir evtl. mal deinen "alpha" code zuschicken? Würde ich mir gerne mal anschauen...

Zitat

Original von Nano
Hi hanta,

ich habe dieses Plugin nicht weiter verfolgt.

Stattdessen arbeite ich gerade an einer anderen Lösung.
Diese Lösung besteht aus dem Streamdev-Plugin, einem OSD Plugin, das das OSD über das Netzwerk transportiert, und einem Streaming-Client für Windows Marke Eigenbau.

Der Client setzt auf DirectX9 auf und bezieht den MPEG2-Stream vom Streamdev-Plugin. Das OSD wird dann mit Hilfe des VMR9 im Video-Fenster dargestellt. Der Client benutzt Directshow Filter, um den Stream (A+V) abzuspielen. Man muss lediglich einen MPEG2 Decoder Filter haben (getestet mit Elecard), der an den Output Pin des Microsoft MPEG2 Demultiplexer Filter ankoppelbar ist.

Das Rudimentärste funktioniert schon:
-empfangen eines TS per TCP vom Streamdev-Plugin
-füttern des Directshow Filtergraph mit diesen TS Daten
-Bild und Ton im Video-Fenster

TODO:
-Kommunikation mit dem Streamdev-Plugin herstellen
(momentan sage ich dem Streamdev Plugin noch per Telnet wohin es die Daten schicken soll)
-OSD Funktionen einbauen in den Client; das OSD Plugin habe ich schon, ist ja nicht so viel

Alles anzeigen

Hallo Nano,

das finde ich ist ein sehr guter Ansatz. Es gibt denke ich eine Menge an Hardware (e.g. MediMVP, discless PC's, DEC2000?), die
- MPEG dekodiern kann
- ein OSD darstellen kann
- und eine Benutzereingabe zuläßt.
Mehr als diese Funktionen braucht es dann nicht mehr um einen Client für VDR zu implementieren. Diese wäre dann ein echter Client - alle
Plugins etc. des Servers sollten automtiach dann auch beim Client
nutzbar sein. Eine einfaches Protokoll mit einem Server wäre eine wichtige Basis in diese Richtung.
Nach meiner Meinung sollte
der Server nicht das OSD mit in den Stream multiplexen. Gerade kleiner Rechner (AMD 350) leisten gute Dienste als Server-VDR - das wäre mit OSD-Multiplexen nicht möglich.
Das OSD sollte unabhängig von der Darstellung übertragen werden
(kein Bild, sondern Textfelder + Zahlenwerte für "Laustärkebalken"), damit der Client je nach Möglichkeit das Beste aus dem OSD machen kann.

Es wäre eine gut Idee auf der VDR-Liste
http://www.linuxtv.org/mailinglists/vdr/
das Protokoll zu diskutieren. Auch die MediMVP-Plugin Liste wäre sinnvoll, da es auch dort die Idee gibt das Plugin auf ein solches Konzept umzustellen
(z.Zt. nutzt es die Hauppauge-Firmware und muß jedes VDR-Feature erneut implementeren).

Ich selber möchte gerne einen Server VDR (AMD 350) im Nebenzimmer (->keine Schlafstörung)
vom Hauptrechner aus voll nutzen können.

Viel Glück.
MFG Malte