Hallo zusammen,
momentan beschäftige ich mich mit der Planung eines Media-Servers. Die Sprache meiner Wahl ist dabei natürlich Python Mir ist zwar bewusst, dass es da schon einige Projekte gibt, aber mich interessiert einfach die Thematik. Ich sehen es auch als Übung an.
Das Ganze habe ich mir so vorgestellt: Der Server indiziert die Media-Dateien (Bilder, Videos, Musik) und schreibt die wichtigen Daten in eine MySQL-Datenbank (Pfad, Titel, Tags, etc.). Veränderungen sollen mittels inotify ermittelt und die Datenbank entsprechend upgedatet werden.
Diese Daten sollen vom Server dann über eine XML-RPC-Schnittstelle bereitgestellt werden. Wenn ich also eine Auflistung aller Bilder haben möchte, stelle ich eine Anfrage an den XML-RPC-Server, der dann die Datenbank abfrägt und das Ergebnis zurückliefert. Dann habe ich ja aber nur die Metadaten der Bilder.
Was ist Eurer Meinung nach die beste Möglichkeit, die Dateien selbst (also Bilder, Videos bzw. Musik) auf den Client zu bekommen? Bietet sich eine Streaming-Lösung an? Oder würde das Ganze auch per NFS, sshfs oder SMB-Share funktionieren?
Falls Streaming: Welche Lösung böte sich da an? Hat schon jemand Erfahrung mit Flumotion (http://www.flumotion.net) gemacht?
Was haltet Ihr allgemein von der Idee, die Metadaten über XML-RPC zur Verfügung zu stellen und das Streaming dann separat auf einem anderen "Kanal" zu initiieren? Gibt es überhaupt eine andere Möglichkeit?
Fragen über Fragen
Über Kommentare, allgemeine Tipps und Gedanken zu dem Thema würde ich mich freuen!
Viele Grüße
Beni
Programmierung eines Media-Servers
- gerold
- Python-Forum Veteran
- Beiträge: 5555
- Registriert: Samstag 28. Februar 2004, 22:04
- Wohnort: Oberhofen im Inntal (Tirol)
- Kontaktdaten:
Hallo BeniBeni hat geschrieben:Diese Daten sollen vom Server dann über eine XML-RPC-Schnittstelle bereitgestellt werden. Wenn ich also eine Auflistung aller Bilder haben möchte, stelle ich eine Anfrage an den XML-RPC-Server, der dann die Datenbank abfrägt und das Ergebnis zurückliefert.
XMLRPC ist supereinfach zu verwenden. Das bezahlt man aber mit Geschwindigkeit. Es ist kein Problem und auch nicht spürbar langsamer, wenn du **wenige** einzelne Daten überträgst. Also wenn du einen Text oder eine kleine Liste überträgst, dann wirst du keinen Unterschied zu anderen Übertragungsmöglichkeiten feststellen.
Anders verhält es sich aber, wenn du **viele** einzelne Daten übertragen möchtest. Und eine Liste mit vielen Musiktiteln ist so ein Fall. Es wird nämlich jeder Listeneintrag in ein XML-Tag-Paar eingeschlossen. Das ist zusätzlicher Overhead, der über die Leitung übertragen wird. Dieser Overhead ist zwar bei wenigen Daten vernachlässigbar, macht sich aber bei vielen Daten bemerkbar.
Verwende lieber JSONRPC dafür. Das hat gegenüber XMLRPC einen geringeren Overhead. Das als Optimierung sollte genügen. Man kann die Datenübertragung für diese Meta-Informationen zwar noch mehr optimieren, aber das wird die Geschwindigkeit nicht mehr spürbar verbessern.
Zum reinen Codieren und Decodieren von JSON empfehle ich dir simplejson: http://undefined.org/python/#simplejson
Als einen Vorteil von simplejson sehe ich an, dass dieser sich selbständig um die Umwandlung von und in Unicode kümmert.
Als JSONRPC-Server sticht mir derzeit WsgiJsonrpc http://chandlerproject.org/Projects/WsgiJsonrpc ins Auge, da dieser direkt in WSGI-Server als WSGI-Anwendung eingebunden werden kann und intern simplejson verwendet. Ich habe es allerdings noch nicht verwendet. Aber ich kann mir gut vorstellen, dieses WsgiJsonrpc in CherryPy eingebunden, demnächst mal auszuprobieren.
Dann gibt es noch das bewärte "JSON-RPC for python" http://json-rpc.org/wiki/python-json-rpc welches als Server und Client verwendet werden kann.
Hier gibt es einen Vergleich einiger JSON-Schnittstellen: http://blog.hill-street.net/?p=7
mfg
Gerold
http://halvar.at | Kleiner Bascom AVR Kurs
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Zum übertragen kannst du schlicht HTTP nutzen, dann brichst du auch keine Protokollgrenzen und das ist dann recht unproblematisch. Außer wenn du wieder hochladen willst, dann müsste man da überlegen wie man das am besten löst.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Ich danke dir. Ich stehe nämlich gerade vor dem Problem, dass XML-RPC bei mir evtl. arg viel Overhead hatgerold hat geschrieben: Verwende lieber JSONRPC dafür. Das hat gegenüber XMLRPC einen geringeren Overhead. Das als Optimierung sollte genügen. Man kann die Datenübertragung für diese Meta-Informationen zwar noch mehr optimieren, aber das wird die Geschwindigkeit nicht mehr spürbar verbessern.
Zum reinen Codieren und Decodieren von JSON empfehle ich dir simplejson: http://undefined.org/python/#simplejson
Als einen Vorteil von simplejson sehe ich an, dass dieser sich selbständig um die Umwandlung von und in Unicode kümmert.
Als JSONRPC-Server sticht mir derzeit WsgiJsonrpc http://chandlerproject.org/Projects/WsgiJsonrpc ins Auge, da dieser direkt in WSGI-Server als WSGI-Anwendung eingebunden werden kann und intern simplejson verwendet. Ich habe es allerdings noch nicht verwendet. Aber ich kann mir gut vorstellen, dieses WsgiJsonrpc in CherryPy eingebunden, demnächst mal auszuprobieren.
Dann gibt es noch das bewärte "JSON-RPC for python" http://json-rpc.org/wiki/python-json-rpc welches als Server und Client verwendet werden kann.
Hier gibt es einen Vergleich einiger JSON-Schnittstellen: http://blog.hill-street.net/?p=7
(Bilder upload, je ~150kb, komprimierte Base64)
- gerold
- Python-Forum Veteran
- Beiträge: 5555
- Registriert: Samstag 28. Februar 2004, 22:04
- Wohnort: Oberhofen im Inntal (Tirol)
- Kontaktdaten:
Hallo audax!audax hat geschrieben:Ich stehe nämlich gerade vor dem Problem, dass XML-RPC bei mir evtl. arg viel Overhead hat
(Bilder upload, je ~150kb, komprimierte Base64)
Weder XMLRPC noch JSONRPC ist zur Übertragung von Binärdaten das ideale Protokoll. Beides sind TEXT-Protokolle, die zuerst einen binären Datenstream in einen Text umwandeln müssen, bevor dieser übertragen wird.
Siehe: http://en.wikipedia.org/wiki/JSON#Suppo ... nd_example
Reines HTTP dürfte dafür, je nach Einsatzzweck, wohl besser geeignet sein.
mfg
Gerold
http://halvar.at | Kleiner Bascom AVR Kurs
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
- gerold
- Python-Forum Veteran
- Beiträge: 5555
- Registriert: Samstag 28. Februar 2004, 22:04
- Wohnort: Oberhofen im Inntal (Tirol)
- Kontaktdaten:
Hallo audax!audax hat geschrieben:Ist ein Bilder-upload Service. Ne Idee, wie ich das effektiver machen könnte?
- Clientseite: http://www.python-forum.de/topic-13029.html
- Serverseite: http://www.python-forum.de/post-84409.html#84409
mfg
Gerold
http://halvar.at | Kleiner Bascom AVR Kurs
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
Hi Beni,
es gibt dafür eigentlich bereits einen (ISO) Standard - UPnP A/V bzw. DLNA.
Dich daran zu halten ist dann sinnvoll, wenn Du mit anderen Clients als Deinem eigenen, wie z.B. Playstation 3, XBox 360,usw, kommunizieren willst.
Ciao,
dev
es gibt dafür eigentlich bereits einen (ISO) Standard - UPnP A/V bzw. DLNA.
Dich daran zu halten ist dann sinnvoll, wenn Du mit anderen Clients als Deinem eigenen, wie z.B. Playstation 3, XBox 360,usw, kommunizieren willst.
Coherence macht das alles bereits, nur halt nach der UPnP A/V Spec. Und mit sqlite statt MySQL.Beni hat geschrieben: Das Ganze habe ich mir so vorgestellt: Der Server indiziert die Media-Dateien (Bilder, Videos, Musik) und schreibt die wichtigen Daten in eine MySQL-Datenbank (Pfad, Titel, Tags, etc.). Veränderungen sollen mittels inotify ermittelt und die Datenbank entsprechend upgedatet werden.
Diese Daten sollen vom Server dann über eine XML-RPC-Schnittstelle bereitgestellt werden. Wenn ich also eine Auflistung aller Bilder haben möchte, stelle ich eine Anfrage an den XML-RPC-Server, der dann die Datenbank abfrägt und das Ergebnis zurückliefert. Dann habe ich ja aber nur die Metadaten der Bilder.
In UPnP ist http als Streaming-Protokoll definiert, optional dann noch rtsp/rtp. Flumotion brauchst Du dafür nicht, damit schießt Du weit über das Ziel hinaus.Beni hat geschrieben: Falls Streaming: Welche Lösung böte sich da an? Hat schon jemand Erfahrung mit Flumotion (http://www.flumotion.net) gemacht?
So wird es ja auch bei UPnP A/V gemacht, nur daß da statt XML-RPC halt eine einfache SOAP Variante verwendet wird.Beni hat geschrieben: Was haltet Ihr allgemein von der Idee, die Metadaten über XML-RPC zur Verfügung zu stellen und das Streaming dann separat auf einem anderen "Kanal" zu initiieren?
Ciao,
dev
Hallo,
sorry für die späte Antwort. Ich war eine Weile nicht verfügbar
Vielen, vielen Dank für die vielen Antworten und guten Tipps!
JSON-RCP sieht wirklich gut aus. Mal schauen, ob ich damit was hinbekomme.
Auch coherence war ein super Tipp! Vielleicht baue ich auch darauf was auf.
Vielen Dank nochmal!
Grüße
Beni
sorry für die späte Antwort. Ich war eine Weile nicht verfügbar
Vielen, vielen Dank für die vielen Antworten und guten Tipps!
JSON-RCP sieht wirklich gut aus. Mal schauen, ob ich damit was hinbekomme.
Auch coherence war ein super Tipp! Vielleicht baue ich auch darauf was auf.
Vielen Dank nochmal!
Grüße
Beni