Mhh. Mal zum icecast-Streaming. Das hat nichts mit dem segementierten Streaming zu tun, das man aus dem Video-Bereich kennt. Also kein HLS, DASH, RTMP... Hier wird tatsächlich nur 1 x eine HTTP-Verbindung geöffnet - und das OHNE den Status Code zu übermitteln, dann kommen im Wesentlichen noch der HTTP Media Type, dann der MP3-Header und dann direkt die Audio-Daten. So nach dem Motto: Hier kommt ein MP3, egal wie lang, und guck mal wie lange es gut geht mit der Verbindung. Das Format kennt eine Segmentierung nur für die Meta-Daten, die alle x Bytes zwischen die Audio-Daten gepackt werden.

Das der Code nicht funktioniert um mein "one to many" Problem zu lösen ist mir klar. Es ist alles nur ein Versuch oder Entwurf. Ich verstehe es momentan als so eine Art Platzhalter.

Deshalb bin ich für jede Idee Deiner und Euerseits im Forum dankbar.

Ich würde das gerne, mit Eurer Hilfe noch mal kurz durchdenken:

Mal von vorne formuliert, bezogen auf das das "one two many" Problem, welches ja abhängig davon ist, welche Nutz-Daten (payload) ich verteilen will:
In diesem Fall, war meine Idee den Source-Stream eines Cliets an die Hörer so zu verteilen, in dem man chunks definiert, diese in ein TEMP-File schreibt und dann an die Clients weitergibt, als wäre man ein Icecast-Server. Idealerweise wäre die chunks so groß wie die chunks, in denen die Meta-Daten gesendet werden.

https://stackoverflow.com/questions/47388541/value...

Quote

icy-metaint is the number of bytes of media stream data between each metadata chunk.

Suppose I have an internet radio station, with icy-metaint value of 8192. The data from the server will look something like this:

[8192 bytes audio] [metadata] [8192 bytes audio] [metadata] …

Soweit ich das bisher verstehe, wäre das ein einziger großer Task. Byte/Bit-weise die Daten schreiben und on-demand an n Clients weitergeben, inkl. HTTP-Header, HTTP Media Type, playload...

Beim HTTP-Header sehe ich noch Diskussionsbedarf. :-)
Last edited: 2023-01-18 21:50:41 +0100 (CET)