softdevice2net - Netzwerk statt Framebuffer

Damit hast du ja quasi ein 'SoftOSD' geschaffen mit beliebigem Speicher und Farbtiefe. Cool
Wie sieht denn ne kleine Schrift aus, nachdem diese durch die Mpeg-Mangel gedreht wurde?

Grüße
Jarny

Die Idee mit dem OSD des Servers auf einem beliebigen Client find ich prima. Meiner Meinung nach bräuchte man auf dem Client aber gar nicht den Videostream des Servers, da der Client den ja sowiso per streamdev bekommt . Der Client hat zur Ausgabe von Video ja ne FF-Karte oder ne Dxr3 oder vdr-xine oder vdr-softdevice.

Wie wäre denn die Integration in streamdev ?

Stefan Lucke

PS: Sorry Christian ?, das nicht auf Deine Letzte Mail geantwortet habe. Die Diskussion in der Öffentlichkeit ist aber besser.

Nano
kleine frage, wie ist denn der aktuelle status bei deinem plugin?
ist 0.0.1 immer noch die aktuellste version oder gibt es schon was neueres?

danke für die info, ich bin eigentlich auf der suche nach einer lösung die sich elegant in xbmc (ein media player für die x-box) eingliedern lassen kann.
... dann werde ich wohl doch selber was basteln müssen

cya

theoretisch sollte doch so ein python script nicht schwer zu machen sein - nur hab ich eben dummerweise keinen Plan von python.

Lt. SDK und Demos kann man ja vom Menü bis zur Dialogbox alles mit der Python API im XBMC darstellen.... insofern sollte nen Channel-Listing nicht sooooo schwer zu machen sein.... - und die URL zusammenbauen die dann noch fehlt um den Stream aufzurufen sollte auch nicht so schwer sein.

... nur hab ich weder Zeit noch Ahnung von Python....
(aber nen xbmc hab ich auch laufen....und würd sicherlich betatesten ;))

dann sind wir ja schon zwei die von python keine ahnung haben

das schlimme ist das es schon ein script für das streamen von der dbox/dreambox zu xbmc gibt und eigentlich wollte ich davon vieles für meinen zweck recyceln. aber ich blicke im moment noch nichtmal wie die das umschalten geregelt bekommen

im moment sieht es ungefähr so aus:

import xbmc, xbmcgui


URL = 'http://192.168.1.1'
PORT = ':3000'
CHANNEL = 1




#get actioncodes from keymap.xml
ACTION_UNKNOWN 		= 0	# 'Y', black
ACTION_MOVE_LEFT 	= 1	# Dpad Left
ACTION_MOVE_RIGHT 	= 2	# Dpad Right
ACTION_MOVE_UP 		= 3	# Dpad Up
ACTION_MOVE_DOWN 	= 4	# Dpad Down
ACTION_SKIP_NEXT 	= 5 	# Left trigger
ACTION_SKIP_PREVIOUS 	= 6 	# Right trigger
ACTION_SELECT_ITEM 	= 7	# 'A'


ACTION_BACK 		= 9	# 'B'
ACTION_PREVIOUS_MENU 	= 10	# 'Back'
ACTION_SHOW_INFO 	= 11	# ?
ACTION_PAUSE 		= 12	# ?
ACTION_STOP 		= 13	# 'Start'
ACTION_DISPLAY 		= 18	# 'X'
ACTION_PLAY 		= 79	# ?






class MyClass(xbmcgui.Window):
	def gostream (self):
		File = URL+PORT+'/'+ str(CHANNEL)
		xbmc.Player().play(File) 


	def onAction(self, action):
		if action == ACTION_MOVE_UP:
			CHANNEL = CHANNEL + 1
			self.gostream()


		if action == ACTION_MOVE_DOWN:
			CHANNEL = CHANNEL - 1
			self.gostream()


		if action == ACTION_PREVIOUS_MENU:
			self.close()




	def __init__(self):
		self.gostream()


mydisplay = MyClass()
mydisplay.doModal()

aber ich habe ein problem, wenn der mplayer läuft dann fängt er jeden tasten druck ab es kommt also nix bei meinem script an.
die einzige möglichkeit die ich sehe währe das man ein menü mit der kanal liste erzeugt. zum umschalten müsste man dann immer zurück ins menü springen und dort den neuen kanal auswählen.
ich hab auch noch keine möglichkeit für ein overlay gefunden um z.B. epg daten einzublenden.

was mich aber wirklich nervt ist das caching vom mplayer ... bei 100mbit/s sollte man sich das doch sparen können. ich finde aber keine option um das caching abzuschalten bzw. um den cache auf ein minimum zu reduzieren.

Ich bin auch grade am Forschen zum Thema XMBC und sehe eher Schwarz für das ganze ohne Eingriffe in XMBC direkt.

1. Ist Python im XMBC ein ziemlicher Overhead da die XBOX sowieso nicht viel Speicher hat.
2. Willst du mit Sicherheit früher oder später mal EPG Support haben, nur das wird sicher ein Spass da du nicht einfach alle EPG Daten auf einmal handlen kannst auf der Maschine.
3. Wie schon erwähnt wird das Zappen usw mit Pyhton imo nie wirklich gut funktionieren da du dich iirc nicht so in den Mplayer hooken kannst wie du eigentlich willst.
4. Recordings werden auch eine nette Herausforderung werden. Marken (von noad) zum Beispiel sind sicher nicht trivial mit Python (und so auch nicht da der Mplayer von diesen Marken sowieso keine Ahnung hat). Ausserdem musst du eine SMB / NFS share zuerst mal richtig einlesen damit du Recordings hast. Dazu kommt noch dass vdr im Moment (arbeite auch grade dran) ja nur max 2Gigs in einen File speichert und es dir passieren kann dass während du einen File abspielst ein 2ter File dazukommt.

Ich bin im Moment parallel an zwei Sachen dran.

Zum einen bau ich mir eine mini Linux Distribution und versuche das ganze mal mit softdevice + xine zum Laufen zu kriegen. Sollte hier bereits zu wenig CPU Power zur Verfügung stehen (Linux frisst ja einiges weg, bedingt durch die Tatsache dass du im Userspace unterwegs bist) wirds kritisch.

Und zum anderen bin ich dabei mich mal in die XBMC Sourcen einzulesen um falls nötig direkt da drinnen was zu implementieren.

Aw, wenn wer Lust hat zu helfen / Vorschläge hat bin ich dankbar.

nomenquis
also das softdevice habe ich unter gentoox getested und dafür war die xbox etwas zu matt. aber soweit ich weiss ist eine directfb version in de rmache sein die die hardware der xbox ausnutzt dann sollte es gehen.

xinelibout habe ich unter xebian getested und das läuft eigentlich ganz gut ... allerdings sind mir da zuviele programme im spiel (der lokale vdr, der x server und xine) wenn eines stirbt muss man defacto rebooten (ich will keine tastatur im schlafzimmer haben )
+ ein vdr unter linux auf der xbox hat das prinzipelle problem das ich immer rebooten muss wenn ich mal was spielen will oder ein video/ eine dvd kucken will.

was mich prinzipell an allen bisherigen lösungen stört ist das langsame zapping. da ja dauernd der stream gewechselt wird muss immer wieder neu gecached werden.
von daher hat mir der ansatz mit dem softdevice2net gut gefallen. für xbmc ist es nur ein stream d.h. nur einmal cachen ich muss mir keine gedanken ums osd, aufnahmen oder ähnliches machen. ich muss nur das netzwerk zur xbox bringen und die signale meiner fernbedienung zum vdr.

wenn bloß externe framegrabber mit netzwerk anschluss nicht so teuer währen

@vorschläge
ich würde wirklich behaubten das softdevice2net der richtige ansatz ist, da man damit unabhängig vom client wird.
man hätte dann auch eine gute lösung für die media mvp leute und mit der dbox2 sollte man dann auch was anfangen können.

Zitat

Original von hanta

xinelibout habe ich unter xebian getested und das läuft eigentlich ganz gut ... allerdings sind mir da zuviele programme im spiel (der lokale vdr, der x server und xine) wenn eines stirbt muss man defacto rebooten (ich will keine tastatur im schlafzimmer haben )
+ ein vdr unter linux auf der xbox hat das prinzipelle problem das ich immer rebooten muss wenn ich mal was spielen will oder ein video/ eine dvd kucken will.

Naja, das ist ja genau das was mach stört. Ich bau mir etwas zusammen wo _nichts_ ausser nem inetd, nem X11 vdr und xine rennt. Wenn was stirbt muss man nicht rebooten, das kriegt man leicht in den Griff. Imho reichts wenn du irgendwo ein shell Script hast dass z.b. alle 30 sek oder so einfach schaut was noch alles da is und falls was tot ist einfach alles killt und neu startet.

Zitat

Original von hanta

was mich prinzipell an allen bisherigen lösungen stört ist das langsame zapping. da ja dauernd der stream gewechselt wird muss immer wieder neu gecached werden.

Also mir pers reicht die Zapping Zeit der xine + streamdev Lösung, xbmc buffert zuviel (das kannst aber ehh einstellen).

Zitat

Original von hanta
von daher hat mir der ansatz mit dem softdevice2net gut gefallen. für xbmc ist es nur ein stream d.h. nur einmal cachen ich muss mir keine gedanken ums osd, aufnahmen oder ähnliches machen. ich muss nur das netzwerk zur xbox bringen und die signale meiner fernbedienung zum vdr.

Kommt für mich leider gar nicht in Frage da ich 3 oder 4 Clients habe und mein Server zu schwach ist um 4 Streams gleichzeitig neu zu encoden.

mfg

Hi Nano,

sag mal, das PlugIn könnte nicht zufällig den DBOX NeutrinoMediaPlayer bedienen? Der will ja TS haben ... so als VLC ersatz?!

Damit könnte man dann VDR-Aufnahmen auf der DBox gucken...

Cheers
J*

nomenquis

wenn du für dein projekt einen tester brauchst, dann sag bescheid

Ich möchte das Thema gerne noch einmal aufgreifen.
Ich bin Besitzer einer MediaMVP und habe aus diesem Grunde darüber nachgedacht wie ein "echter" thin client denn aussehen könnte. Hier ein paar Sachen zur diskussion - vielleicht ergibt sich ja der Ansatz eines neuen Plugin-Projektes daraus - Ich denke jedenfalls darüber nach etwas Energie hier hinein zu investieren...

Lösung 1: der client interpretiert Daten des vdr-servers und ist für die Darstellung des OSD selbst verantwortlich. Dies ist der Weg des MediaMVP plugins und der weg, den nano wohl einschlagen möchte.
Ob der Client jetzt dabei eine MVP oder eine windowskiste ist, spielt dabei eine enorme Rolle - Es müssen bei beiden unterschiedliche Sachen programmiert werden, da sie nicht die selben API's besitzen. D.h. OSD funktionalität muss auf allen möglichen Plattformen neu erstellt werden.
Soweit das Problem welches ich in diesem Ansatz sehe.

Wie könnte die Lösung 2 aussehen?
Softdevice2Net hat da imho eigentlich den konzeptionell richtigeren Ansatz verfolgt -> Das OSD wird serverseitig generiert. Anforderungen an den client sind also sehr gering. Und er muss nur ein verbreitetes streamingformat wiedergeben - Das dürfte bei so gut wie allen denkbaren clients fast out of the box funktionieren.
Okay... Soweit die Theorie... Es gibt aber in der Tat einige Probleme mit diesem Ansatz. Um es genauer zu sagen sehe ich zwei KO-Kriterien welche die Geschichte u.U. nur begrenzt sinnvoll machen.
1. Ich muss zugeben softdevice2net noch nicht getestet zu haben. Wie ist die Qualität? Leidet sie spürbar unter dem Reencoding?
2. Wie sieht es mit der Hardwarelast aus? Auf einem schnellen Rechner sollten schon mindestens 2 Streams kodiert werden können, da sonst das Konzept client/server irgendwie as absurdum geführt wird... Wieviel Optimierungspotential ist in der bisherigen Lösung? Macht hier evtl ein Hardware-Kodierlösung wieder sinn? Es gibt ja genug vkarten mit einem mpeg encoderchip - Wesentlich mehr als es anders herum der Fall ist.(Wenn ich das richtig verstanden habe gibt es immo doch nur FF Karten und die dxr3?)

Okay, alles in allem klingen imho beide Ansätze irgenwie nicht ideal. Ich könnte mir allerdings durchaus vorstellen, dass ein großes Interesse bei "thinclient-Besitzern" wie mir daran bestände, dass softdevice2net doch weiter verfolgt wird - Da du(nano) das ja nicht machen möchtest hättest du ja sicher nichts dagegen wenn jemand auf deiner Arbeit aufbaut, oder?

Feedback und Kritik an meinen Gedankengängen erwünscht

Dann mach ich mal kritisches Feedback

Wegen Lösung 2:

Du wirst (besonders bei guter Auslastung des Servers) Probleme mit der Reaktionsgeschwindigkeit des OSDs bekommen.
Der Client schickt den Befehl zum Server, der muß die Seite erstellen, den Stream decodieren, das OSD in eine Pixelgrafik wandeln, über das Video legen, alles encodieren (in welchem Format auch immer) und über das Netz jagen.
Der Client müßte wirklich nur decodieren und anzeigen.

Bei Lösung 1, erstellt der Client die OSD Seite und blendet sie über dem Video ein. Allerdings brauchts dann auf der Client Seite leistungsfähigere / speziellere Hardware. Allerdings reicht zum erstellen des OSDs ja Hardware im Format eines Taschenrechners, Overlay muß dann entweder von der Grafigkarte oder zB einer DXR3 übernommen werden.
Das OSD wird dann wohl schlichter ausfallen als das vom VDR.
V

ieleicht könnte man ein Media MVP mit nem kleinen Rechner und ner DXR3 nachbilden. Das Ding ist warscheinlich billiger und vor allem erweiterbar (zB. WLAN).

Lars

Hmm zum Thema Reaktionsgeschwindigkeit:
Mal schriftlich überlegt:
1. Server braucht eine gewisse - konstante - Zeit zum enkodieren eines frames
2. Client braucht eine gewisse - konstante - Zeit zum dekodieren eines frames
3. Ir Befehl braucht eine gewisse Zeit zum vdr.
4. Frames brauchen eine bestimmte Zeit zum client.

3. und 4 dürften im 100 Mbit LAN vernachlässigbar klein sein.
Zu 1 und 2 traue ich mir keine fundierte Aussage zu. Denke aber, dass beim de/enkodieren doch jeweils die CPU vor dem erhalt des nächsten frames fertig sein müsste, da sonst sie ja mehr als nur vollast hätte und die puffer eh vollaufen müssten. Macht summa 2 Frames bearbeitungszeit - Immer noch ein bruchteil einer Sekunde und damit nicht zu bemerken...
Wohl ist mir allerdings bei dieser Einschätzung nicht ganz, denn A. könnten da besonderheiten des MPEG formates eine Rolle spielen, die ich nicht kenne und B. könnte die Pufferung an verschiedenen stellen einen Bottleneck bewirken. (Was wenn zum Beispiel die MVP oder ein Hardwarencode auf Grund von Pufferung alles eine sekunde später ausgibt - Normalerweise wäre das kaum zu bemerken und würde eventuellen Jitter im MPEG Datenstrom ausgleichen...)

Zur ersten Lösung: Das Problem, welches ich darin sehe liegt halt an ganz anderer Stelle - Hier werden Individuallösungen geschaffen, wo evtl. eine allgemeine Lösung möglich wäre...

Die dxr3 Lösung ist vermutlich nicht billiger als eine MediaMVP von Hauppauge - zumindest nicht in einer Wohnzimmer-/Freundintauglichen Optik...

Nano: wie sind denn da deine Erfahrungen? Was war der Grund für dein Umschwenken auf die andere Lösung? Sahst du technische schwierigkeiten oder hast du die andere Lösung für "deine Problemstellung" als am günstigsten befunden? Wenn ich dich richtig verstanden habe willst du ja unter windows den vdr benutzen. Evtl. auch mit der XBox? Zumindest dort gibt es ja auch directx...