Programmierung eines Media-Servers

Sockets, TCP/IP, (XML-)RPC und ähnliche Themen gehören in dieses Forum
Antworten
Beni
User
Beiträge: 7
Registriert: Montag 18. Oktober 2004, 21:04
Kontaktdaten:

Montag 3. März 2008, 10:17

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
Benutzeravatar
gerold
Python-Forum Veteran
Beiträge: 5554
Registriert: Samstag 28. Februar 2004, 22:04
Wohnort: Telfs (Tirol)
Kontaktdaten:

Montag 3. März 2008, 11:35

Beni 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.
Hallo Beni

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
:-)
[url]http://halvar.at[/url] | [url=http://halvar.at/elektronik/kleiner_bascom_avr_kurs/]Kleiner Bascom AVR Kurs[/url]
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
Leonidas
Administrator
Beiträge: 16024
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Montag 3. März 2008, 13:54

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 Modvoice
audax
User
Beiträge: 830
Registriert: Mittwoch 19. Dezember 2007, 10:38

Montag 3. März 2008, 17:45

gerold 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
Ich danke dir. Ich stehe nämlich gerade vor dem Problem, dass XML-RPC bei mir evtl. arg viel Overhead hat :D
(Bilder upload, je ~150kb, komprimierte Base64)
Benutzeravatar
gerold
Python-Forum Veteran
Beiträge: 5554
Registriert: Samstag 28. Februar 2004, 22:04
Wohnort: Telfs (Tirol)
Kontaktdaten:

Montag 3. März 2008, 18:13

audax hat geschrieben:Ich stehe nämlich gerade vor dem Problem, dass XML-RPC bei mir evtl. arg viel Overhead hat :D
(Bilder upload, je ~150kb, komprimierte Base64)
Hallo audax!

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
:-)
[url]http://halvar.at[/url] | [url=http://halvar.at/elektronik/kleiner_bascom_avr_kurs/]Kleiner Bascom AVR Kurs[/url]
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
audax
User
Beiträge: 830
Registriert: Mittwoch 19. Dezember 2007, 10:38

Montag 3. März 2008, 18:45

Es ist eben für eine Webanwendung die eine möglichst einfache Schnittstelle haben soll.

Ist ein Bilder-upload Service. Ne Idee, wie ich das effektiver machen könnte?
mitsuhiko
User
Beiträge: 1790
Registriert: Donnerstag 28. Oktober 2004, 16:33
Wohnort: Graz, Steiermark - Österreich
Kontaktdaten:

Montag 3. März 2008, 19:18

REST/HTTP
TUFKAB – the user formerly known as blackbird
Benutzeravatar
gerold
Python-Forum Veteran
Beiträge: 5554
Registriert: Samstag 28. Februar 2004, 22:04
Wohnort: Telfs (Tirol)
Kontaktdaten:

Montag 3. März 2008, 19:37

audax hat geschrieben:Ist ein Bilder-upload Service. Ne Idee, wie ich das effektiver machen könnte?
Hallo audax!

- Clientseite: http://www.python-forum.de/topic-13029.html
- Serverseite: http://www.python-forum.de/post-84409.html#84409

mfg
Gerold
:-)
[url]http://halvar.at[/url] | [url=http://halvar.at/elektronik/kleiner_bascom_avr_kurs/]Kleiner Bascom AVR Kurs[/url]
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
audax
User
Beiträge: 830
Registriert: Mittwoch 19. Dezember 2007, 10:38

Montag 3. März 2008, 19:39

Der Teil ist schon fertig, aber danke :D

Geht momentan um die API, die vom Client, der unabhängig vom Browser laufen soll. Also upload ausm Dateibrowser z.B.
dev
User
Beiträge: 49
Registriert: Montag 23. Januar 2006, 09:52
Kontaktdaten:

Freitag 7. März 2008, 12:12

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.
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.
Coherence macht das alles bereits, nur halt nach der UPnP A/V Spec. Und mit sqlite statt MySQL.

Beni hat geschrieben: Falls Streaming: Welche Lösung böte sich da an? Hat schon jemand Erfahrung mit Flumotion (http://www.flumotion.net) gemacht?
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: 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?
So wird es ja auch bei UPnP A/V gemacht, nur daß da statt XML-RPC halt eine einfache SOAP Variante verwendet wird.

Ciao,
dev
Beni
User
Beiträge: 7
Registriert: Montag 18. Oktober 2004, 21:04
Kontaktdaten:

Samstag 15. März 2008, 14:42

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
Antworten