[Suche] Doku zu mp3-Streaming

[fs111]

Guten Tach zusammen!

Ich bin auf der Suche nach Beschreibungen, Howtos etc. über mp3-streaming, und zwar nicht wie man sowas konfiguriert, sondern selber schreibt. Wisst ihr da was zu? Das ganze soll ich Java (nein, das kann man nicht ändern, das ist für ide UNI) geschehen, aber das tut ja an sich nichts zur Sache. Mich interessiert die generelle Heransgehensweise, aber jeder Link ist mir recht. Tante google war irgendwie heute nicht gnädig.

Danke und Grüße

fs111

[f0rtex]

Hast du dir schon mal die Sourcen von icecast.org/shoutcast.com angeschaut?

[fs111]

Ja, aber an sich geht es mir um die Prinzipien, die dahinter stecken, ud nicht unbedingt eine konkrete Implementierung.

fs111

P.S.:

An die Mods, lass doch bitte beim verschieben einen Link auf das ursprungsposting, das ist für den OP einfacher, ich mache das nebenan bei lf.de ach immer so. Danke

[peschmae]

gibts da denn so was spezielles zu machen? Ich denke das ist doch recht gewöhnliche Datenübertragung (ob die etz udp oder tcp nehmen ist doch eh gleich).
MP3 ist ja eh schon ein streaming-format (es gibt keine Header in denen z.B. was über die Dateilänge steht, sondern das Zeugs kommt einfach).

Das einzige was mir da bedenkenswert erschiene wäre:

Wie krieg ich das mit einem schmalbandig angebundenen Server und vielen Clients hin?
Kann man das irgendwie adaptiv machen (Bitrate des gestreamten MP3-Streams wird je nach Bandbreite der Verbindung angepasst) - tuts ja normalerweise nicht, zumindest bei den Shoutcast-Dingens die ich kenne kommt (trotz mittlerweile 600er Verbindung) immer nur 64kbps runter)


MfG Peschmä

[fs111]

Original geschrieben von peschmae
gibts da denn so was spezielles zu machen? Ich denke das ist doch recht gewöhnliche Datenübertragung (ob die etz udp oder tcp nehmen ist doch eh gleich).
MP3 ist ja eh schon ein streaming-format (es gibt keine Header in denen z.B. was über die Dateilänge steht, sondern das Zeugs kommt einfach).

Das einzige was mir da bedenkenswert erschiene wäre:

Wie krieg ich das mit einem schmalbandig angebundenen Server und vielen Clients hin?
Kann man das irgendwie adaptiv machen (Bitrate des gestreamten MP3-Streams wird je nach Bandbreite der Verbindung angepasst) - tuts ja normalerweise nicht, zumindest bei den Shoutcast-Dingens die ich kenne kommt (trotz mittlerweile 600er Verbindung) immer nur 64kbps runter)


MfG Peschmä

Also einfach via Socket (TCP) geht es nicht, dann sind die Daten irgendwie im Hintern (Rauschen, Piepsen, aber kein vernünftiges Lied, wobei die ID3-Tags aber erhalten bleiben, komischerweise...). So wie ich das sehe, verwenden die Webradios wohl http, die Frage ist nur, wie erriechen die das, dass man das nicht einfach runterladen kann? (Wenn das ginge bräuchte man ja keine Streamripper o.ä.), da muss ja irgenwie noch mehr passieren, als einfach nur die Datei auszuliefern.

fs111

fs111

[peschmae]

Original geschrieben von fs111
Also einfach via Socket (TCP) geht es nicht, dann sind die Daten irgendwie im Hintern (Rauschen, Piepsen, aber kein vernünftiges Lied, wobei die ID3-Tags aber erhalten bleiben, komischerweise...).


Also was hast du jetzt versucht? Selber nen Server und Empfänger geproggt? Oder auf nen "normalen" Shoutcast-Webradio Stream zuzugreifen?

Du möchtest als weniger wissen wie man sowas machen könnte als vielmehr wie sowas normalerweise bei Shoutcast-Webradios gemacht wird?



So wie ich das sehe, verwenden die Webradios wohl http, die Frage ist nur, wie erriechen die das, dass man das nicht einfach runterladen kann? (Wenn das ginge bräuchte man ja keine Streamripper o.ä.), da muss ja irgenwie noch mehr passieren, als einfach nur die Datei auszuliefern.


Ja. Die scheinen HTTP zu verwenden. Zumindest siehts so aus - bei Streamtuner kann man ja einen HTTP-Proxy angeben.

Habs gerade mit wget versucht - geht nicht. Aber mit


htget --verbose http://212.48.125.67:8480

Musikts. :) :)
Wget will wohl nicht weil die Dateigrösse unbekannt ist oder so.

MfG Peschmä

[fs111]

Original geschrieben von peschmae
Also was hast du jetzt versucht? Selber nen Server und Empfänger geproggt? Oder auf nen "normalen" Shoutcast-Webradio Stream zuzugreifen?

Du möchtest als weniger wissen wie man sowas machen könnte als vielmehr wie sowas normalerweise bei Shoutcast-Webradios gemacht wird?



Nunja wie man will, ein normler Player soll mit dem Stream dann was anfangen können. Ich habe einfach das ganze durch via TCP Socket an netcat geschickt, und den Output in eine Datei umgeleitet, den Output dann mit xmm geöffnet.


Ja. Die scheinen HTTP zu verwenden. Zumindest siehts so aus - bei Streamtuner kann man ja einen HTTP-Proxy angeben.

Habs gerade mit wget versucht - geht nicht. Aber mit


htget --verbose http://212.48.125.67:8480

Musikts. :) :)
Wget will wohl nicht weil die Dateigrösse unbekannt ist oder so.

MfG Peschmä

Hmm, und wie packen die dann mehrere Dateien zu einem Stream zusammen, werden die einfach in die Verbindung gedumpt?

fs111

[peschmae]

Ich weiss nicht wirklich genau wie http tut. Wusste mal als ich nen kleinen Webserver schrieb, aber das ist schon was her.

Wenn ich mir das Webserverchen aus dem Javabuch so überfliege siehts aber fast so aus als ob der Webserver - wenn er einmal einen Request hat - einfach mal Daten sendet.
d.h. wenn das mehrere MP3s sind schickt er die erste dann die zweite etc. einfach als fortlaufender Datenstrom. Für den Player ist das ja kein Problem, da MP3s sowieso als Stream konzipiert sind (und sich auch z.B. mit cat zusammenfügen und anschliessend problemlos abspielen lassen)

MfG Peschmä

[peschmae]

Original geschrieben von peschmae

Wie krieg ich das mit einem schmalbandig angebundenen Server und vielen Clients hin?


Hab mir heute gerade n bisschen nen Kernel kompiliert nach den misslichen Erfahrungen mit ipv6 was offenbar einfach als Modul dabei war...

Dort hab ich dann mal wieder die IP-Multicast Option gesehen. Verwenden denn Webradios sowas?
Hielte ich für möglich - sonst wäre der Bandbreitenverbrauch ja enorm.
Braucht Multicast denn Client-Seitige Unterstützung oder läuft das unabhängig vom Client :confused:

MfG Peschmä

[fs111]

Original geschrieben von peschmae
Hab mir heute gerade n bisschen nen Kernel kompiliert nach den misslichen Erfahrungen mit ipv6 was offenbar einfach als Modul dabei war...

Dort hab ich dann mal wieder die IP-Multicast Option gesehen. Verwenden denn Webradios sowas?
Hielte ich für möglich - sonst wäre der Bandbreitenverbrauch ja enorm.
Braucht Multicast denn Client-Seitige Unterstützung oder läuft das unabhängig vom Client :confused:

MfG Peschmä

Multicast gibt es nur bei IPv6, also können die Webradiso das nicht einsetzen. Für Content-Anbieter eine feine Sache, allerdings ja nicht im Sinne der Provider, da die die Backbones ja nach Bandbreite vermieten, und da würde Multicast ja das Geschäft kaputt machen...

fs111

[peschmae]

Bist du sicher? Ich hab mal irgendwo gelesen dass diverse gute Sachen auch Backported wurden.

Auf jeden Fall ist die Konfigurationsoption CONFIG_IP_MULTICAST=y im Linux-Kernel auch bei abgeschaltetem ipv6 zugänglich.

Was allerdings dagegen spricht, dass das verwendet wird, ist, dass bei Shoutcast immer auch Zuhörerzahllimiten da sind.

MfG Peschmä

[fs111]

Original geschrieben von peschmae
Bist du sicher? Ich hab mal irgendwo gelesen dass diverse gute Sachen auch Backported wurden.

Auf jeden Fall ist die Konfigurationsoption CONFIG_IP_MULTICAST=y im Linux-Kernel auch bei abgeschaltetem ipv6 zugänglich.

Was allerdings dagegen spricht, dass das verwendet wird, ist, dass bei Shoutcast immer auch Zuhörerzahllimiten da sind.

MfG Peschmä

Ähm, du würfelst da gerade was ziemlich durcheinander. Wie sollen denn Sachen aus IPv6 "backported" werden, das ist schlicht ein ganze anderes Protokoll, welches in einem ganz anderen RFC spezifiziert ist. Der größte Teil der Welt setzt im Moment auf IPv4, der größte Teil der Netze ist IPv4, wie willst Du denn da IPv6 benutzen? Außerdem taucht im gesamten RFC 791 das Wort Multicast nicht einmal auf.

fs111

[peschmae]

im Originalen RFC zu ipv4 schon nicht. Da hatte halt noch niemand dran gedacht. Aber in Erweiterungen ist schon von Multicast die Rede - z.B. im RFC 3171

MfG Peschmä

[dipesh]

IMHO bietet http auch streaming-Möglichkeiten. Anders wäre z.B. das streamen einer PDF-Datei nicht möglich (existentiell für eServices welche mit pdf-Dateien arbeiten). Wenn ich mich recht entsinne war der MIME-type dafür "application/octet-stream" und da ich mir nicht ganz sicher war hab ich mal eine kurze google-Suche mit '"octet-stream" shoutcast' gefüttert und dabei Beiträge wie die folgenden beiden gefunden;
http://forums.devshed.com/archive/t-96705
http://beam-back.sourceforge.net/

[peschmae]

Aha. Das bringt uns schon mal was weiter :)
Danke.

MfG Peschmä

P.S. was hat die Sache mit deiner Meinung zu tun? Ich vote für s/IMHO/AFAIK/
Wieso das auch immer alle falsch benutzen :confused: *SCNR*

[dipesh]

Original geschrieben von peschmae
P.S. was hat die Sache mit deiner Meinung zu tun? Ich vote für s/IMHO/AFAIK/
Wieso das auch immer alle falsch benutzen :confused: *SCNR* [/B]

Als ich den Beitrag anfing zu schreiben, war ich mir der Aussage bezüglich octet-stream vs. mp3-stream nicht einhundertprozentig sicher. Zwar "durfte" ich mal an einem eGov/eService-Projekt mitentwickeln wo genau jener Stream Anwendung fand, nur dass das selbe Prinzip auch bei shoutcast Verwendung findet um mp3-Dateien zu streamen war eine reine Vermutung welche erst durch die erwähnte google-Suche bestätigt wurde. Das IMHO wurde folglich einfach an der falschen Stelle positioniert und hätte als eigenständige Aussage das Posting einleiten sollen (etwa wie "ohne gewähr" als Abgang der Ziehung von Lottozahlen). Ein AFAIK wäre zu dem Zeitpunkt da dass IMHO auftaucht (vor der Gegenprüfung durch eine offensichtlich anerkannte Informationsquelle wie google) eine ungeprüfte Behauptung gewesen mit derer ich mich zu identifizieren nicht im Stande sah. Aus genau jenem Grund wählte ich IMHO. Es könnte jedoch auch einfach sein, dass mir dies ohne vorherige Reflektion gleichsam als Floskel über die Tastatur rutschte (das passiert schonmal bei der Verfassung von denglischen Texten :-)

@fs111
Übrigens würde das auch erklären warum netcat dir solch ein Resultat lieferte. Es hat ganz einfach den für den Browser bestimmten Kopf der Nachricht mit in die Datei geschrieben. Ein browser hätte diesen rausgefiltert und den Stream erst zu dem Zeitpunkt bearbeitet da der eigentliche Content und damit die mp3 anfängt...

[peschmae]

lol, du hast mich überzeugt :D
Ich finds trotzdem interessant, statistisch gesehen... ;)

MfG Peschmä