Archiv verlassen und diese Seite im Standarddesign anzeigen : ogg-radio (OGG Streamer)
Sprache: C
System: Linux
Ahoy, me hearties! Nachdem ich diese Sektion lange Zeit irgendwie vergessen hatte, gibt's endlich wieder was neues. Nun ja, so neu ist es nicht. Hab das Teil vor einigen Wochen (Monaten?) geschrieben.
Whatever, es handelt sich hierbei um einen extrem simplen, dafür aber (hoffentlich) sehr robusten und vor allem extrem kleinen OGG/Vorbis-Streamer (das vorkompilierte (gestrippte) Binary im Paket ist ganze ~7.6 KB groß, C-Code fasst insgesamt 403 Zeilen (inklusive nicht existenter Kommentare)).
Die Nutzung ist relativ simpel, einfach Pfade zu den zu streamenden OGG-Files reinpipen. Hab dazu auch ein kleines Shellscript geschrieben, das ein angegebenes Verzeichnis nach OGGs durchsucht und aus den Files ein unendliche Playlist generiert, mit der man ogg-radio füttern kann.
(Erfolgreich) Getestete Clients:
ogg123
mplayer
Bitte hier Berichte posten, damit die Liste erweitert werden kann. Natürlich sind auch Bug-Reports und Meinungen zum Programm erwünscht.
Nun wünsch ich noch viel Spaß damit. Alles weitere (Config. usw.) steht im README.
Werde es heute abend gleich testen, aber alleine von der Beschreibung sieht es schon mal super aus!
Schon mal im Voraus: "Super Arbeit!"
Gruß initrc
Mit Konqueror läuft es nicht. Aber ansonsten wunderbar. Eine möglichkeit Songs im betrieb hinzufügen wäre nicht schlecht.
Eine möglichkeit Songs im betrieb hinzufügen wäre nicht schlecht.Nun ja, da der Streamer die Pfade ja von stdin liest, duerfte das auf Seiten des Streamers schwierig zu implementieren sein. Ich habe aber zu Hause noch eine neuere Version des Playlist-Scripts, bei dem für jeden ausgegebenen Song-Pfad die Liste neu erstellt wird, d.h. man kann neue Lieder einfach in das Verzeichnis kopieren um sie in die Playlist aufzunehmen.
Ansonsten könnte man auch ein kleines Playlist-Tool mit GUI schreiben, mit dem man Playlists managen kann und welches dann einfach die Pfade zu den Dateien ausgibt.
Es gibt also viele Möglichkeiten, das Radio zu füttern, was auch ein Grund für mich war, den Steramer überhaupt zu schreiben. Andere, vergleichbar kleine & handliche Streamer haben entweder die zu spielenden Files als Argument übernommen oder haben die OGG-Files direkt per stdin eingelesen, d.h. man musste mit einem weiteren Tool OGG-Files zusammenschneiden und das Ergebnis an stdout weiterleiten. Beide Möglichkeiten sind nicht wirklich praktikabel, wenn man vorhat den Streamer längere Zeit laufen zu lassen (bei mir im LAN läuft er jetzt seit über einem Monat non-stop). Nunja, und alle anderen Streamer waren mir zu bloatig.
Ich werde heute Abend einfach mal das neue Playlist-Script hochladen und vll. schreibt ja noch jemand ein erweitertes Playlist-Tool bzw. es gibt schon brauchbares.
EDIT: Hab kein KDE/Konquerer, kann's daher nicht testen. Kannst du mir sagen, welchen Player Konquerer verwendet? Oder hat er einen eigenen eingebaut?
Ich schätze Konqueror verwendet entweder ein Protokoll dafür, oder es gibt einen MimeTyp eintrag. Ersteres müsstest du evtl. implementieren, zweiteres müssen KDE-Poweruser/Maintainer machen.
Protokoll? So eins wie HTTP? :) Ist drin, von dem Client wird zwar kein HTTP-Request eingelesen, aber dem eigentlichen Stream wird ein "HTTP/1.1 200 OK\r\nContent-Type: application/ogg\r\nConnection: close\r\n\r\n" vorausgeschickt.
EDIT: Ich weiß, das ist nicht die sauberste Lösung, aber wenn man in dem Streamer noch HTTP-Requests parsen würde, wäre die Handlichkeit dahin. Wirkliche Probleme sollten daraus nicht resultieren, da ein Player, der keinen HTTP-Header vor dem Stream erwartet, nur 1-2 fehlerhafte Frames meldet und dann normal abspielt.
Bsp:
echo "Dies ist ganz sicher kein HTTP-Request" | netcat stream-server 8000 | ogg123 -
verwende HTTP/1.0 wenn du irgendwas streamen willst. Bei 1.1 legt man sich damit in der Regel bloss die Fresse.
Das spart dir gleichzeitig auch "Connection: close"
Alles klar, wenn du meinst :) Die HTTP 1.0-Version gibt's heut Abend zusammen mit dem neuen Playlist-Script.
So, hier ist das neue Paket. BTW, das "Downgrade" auf HTTP 1.0 hat das Binary noch mal 20 Byte kleiner gemacht :D
Mac OS X braucht <sys/types.h> vor <sys/socket.h>.
thodi@bender ~/sources/ogg-radio $ gcc --version
gcc (GCC) 3.3 20030304 (Apple Computer, Inc. build 1666)
Copyright (C) 2002 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
thodi@bender ~/sources/ogg-radio $ uname -a
Darwin bender.local 7.9.0 Darwin Kernel Version 7.9.0: Wed Mar 30 20:11:17 PST 2005; root:xnu/xnu-517.12.7.obj~1/RELEASE_PPC Power Macintosh powerpc
thodi@bender ~/sources/ogg-radio $
Urgs! Security-Experten von Microsoft haben eben einen fiesen Bug entdeckt, durch den der Streamer zumindest zum Absturz gebracht werden kann. Ob evtl. Code eingeschleust und ausführt werden kann, wird derzeit von einem unabhängigen Forscherteam, sowie den Experten von Secunia, SANS und Security Focus geprüft.
Der Fehler tritt auf, wenn eine böswillig modifizierte OGG/Vorbis-Datei gestreamt werden soll. Die Funktion, die die einzelnen OGG-Pages aus der Datei analysiert, berücksichtigt leider nicht die Länge der Datei, sodass bei einer schadhaften Datei evtl. über das Ende des Buffers hinaus gelesen wird. Microsoft Security-Experten empfehlen daher, Open Source, offene Formate wie ODF und OGG, und vor allem Linux zu meiden. Heise wurde informiert.
Einen Patch gibt es - wie immer - am Patchday (jedes Jahr am 23. August).
EDIT: Heise hat zurückgerufen, es interessiert sie "einen feuchten *******". :(
Also, entweder bist du im Forum verrutscht, oder du bist ein nicht sicherheitsbewusster Programmierer *g*
Überraschend hat nun der Maintainer doch noch flüx eine neue Version fertiggestellt, in der das oben beschriebene Problem behoben sein sollte. Sie wird voraussichtlich heute Abend verfügbar sein. Somit ist wieder einmal bewiesen, dass OSS die schnellsten und vor allem bestaussehendsten Maintainer hat.
Deknos: Besser als Monate mit dem Patchen warten und bis dahin behaupten, es gäbe kein Sicherheitsproblem, wie das der eine oder andere Software-Konzern tut (vor allem der eine).
ich dachte, du bist im forum/thread verrutscht, und das war ein scherz :>
Urgs, eigentlich wollte ich das Update schon vor 2h hochladen, aber dann war Mittagspause und dann kam noch irgendwas dazwischen... Egal, hier ist es nun.
bug|unfixed
20.11.2005, 08:06
Mit mplayer funktioniert es gut, mit ogg123 bekomme ich das:
unix_connect: can't connect to server (unix:/tmp/mcop-rafael/localhost_qrnet-280a-4360de86)
Audio Device: OSS audio driver output
Playing: http://127.0.0.1:8000
Ogg Vorbis stream: 2 channel, 44100 Hz
Title: *********
Artist: *******
Organisation: ************
libao - OSS cannot set rate to 44100
Error: Cannot open device oss.mplayer benutzt ja auch libao, aber da gehts... Und weshalb dieser connect-error kommt, weiß ich nicht...
Gruß
PS: Wenn du noch mp3-radio schreiben wuerdest, wuerde ich dein Programm sogar benutzen ;) Aber erst alle mp3s in ogg umwandeln? Nee...
du hast ein Problem mit deinem ogg123 bzw OSS, das sich vermutlich auch beim normalen Abspielen äußern wird.
lither, warum ist eigentlich das struct server srv global?
bug|unfixed: Das ist ein Problem mit deinem ogg123, denn mit meinem funktioniert es einwandfrei. Ein mp3-radio wird's (voraussichtlich) nicht geben. Habe mich für OGG entschieden, weil es 1. offen und 2. ganz einfach das bessere Format ist.
fippo: Damit die Cleanup-Funktion, die per atexit() aufgerufen wird, den Server ordnungsgemäß "runterfahren" kann, d.h. alle Client-Sockets und zum Schluss den Server-Socket schließen.
Mir ist grad aufgefallen, dass das ogg-radio Lieder auf 'nem System mit 'nem nicht preemptible Kernel (meist Server) schneller abspielt, wenn keine Clients zuhören. Kann das jemand bestätigen?
Macht das dann überhaupt noch sinn? ^^
Höh? Macht was noch Sinn?
Wenn du einen OggStreamServer hast, der keine clients hat zum Zuhören? :D
Achso :) Naja, kann ja immer mal vorkommen, dass grad kein Client lauscht. Z.B. wenn man der Server grad gestartet hat und wenn dem Client das aktuelle Lied grad nicht so gefällt. Macht IMO schon Sinn, das Lied dann weiterlaufen zu lassen.
Find's nur komisch, dass es bei 'nem non-preemptible Kernel schneller zu laufen scheint. Irgedwie scheint er das usleep dann irgendwie anders handzuhaben.
include/log.h: #error bricht die Kompilierung ab. Vielleicht solltest du #warning benutzen, wenn du mit /dev/stderr kompilieren moechtest.
Urgs, yup, das stimmt wohl.
Ich hab mir mal erlaubt, einen kleinen Patch zu erstellen. Raeumt mit einigen ueberfluessigen Semikolons auf, fuegt ein 'clean'-Target hinzu, die #warning-Sache und die Darwin-Kompilation.
Eeeeh, nichts gegen meine Semikolons! :) Aber thx für den Patch.