Good morning, On Mon, 2019-05-06 at 08:44 +0000, Jürgen Bund wrote:> Hello again, > thanks for your response. > > I have still some questions: > I want to stream a 24/7 radiochannel with mp3s. So I can't send all mp3s with one http PUT request. > So is there a possibility for that with http PUT? > If yes, how can I send the next mp3, so that icecast is playing it fluently (continuesly)?Yes: You need to send all the data in one PUT request. This is how it works. You send them concatenate with correct timing applied (which is another feature of libshout). [0]> If not, is there a documentation for a TCP Socket Communication?Yes. The HTTP RFCs. Because what Mr. Gleason suggests is that you implement HTTP PUT yourself. That is: RFCs 7230, 7231, 7234, 7235, 7236, 7617, and maybe 7616. You may also want to have a look at RFCs 2817, and 2818 for TLS.> Libshout is a c++ library. Is there a wrapper for .Net or a .dll, so I can use it in my C# Client?It is a pure C library, not C++. I'm not aware of such a binding myself. However maybe someone else is. I'm a POSIX developer so this is just not my area of work. :) With best regards, [0] Please note that you must strip any surrounding containers such as ID3 as the stream is pure MP3 data.> -----Ursprüngliche Nachricht----- > Von: Icecast <icecast-bounces at xiph.org> Im Auftrag von Philipp Schafft > Gesendet: Samstag, 4. Mai 2019 15:15 > An: fredg at paravelsystems.com; Icecast streaming server user discussions <icecast at xiph.org> > Betreff: Re: [Icecast] Source client with HTTP PUT > > Good afternoon, > > On Fri, 2019-05-03 at 12:24 -0400, Fred Gleason wrote: > > On Fri, 2019-05-03 at 13:19 +0000, Jürgen Bund wrote: > > > I’m writting a source client in c#, in which I’m sending chunks of a > > > mp3 file with http Put to IceCast. > > > My problem is, that it is not a continues stream. Each http PUT > > > request is an extra track. > > > How can I generate an ongoing stream with mp3 chunks, which I send > > > per http Put to IceCast. > > > > Don't use PUT at all. Instead, open a TCP socket connection to the > > port that the server is running on, write all of your headers to that > > (terminating each one with a CR/LF), send a naked CR/LF to tell > > Icecast that your done sending headers and then start writing content. > > ***Please don't.*** This is the worst way if implementing source clients. And there are already too many broken ones. > > > > You may want to check out the libshout library, which can handle most > > of the low-level nitty-gritty stuff for you 'auto-magically'. > > > > https://github.com/xiph/Icecast-libshout > > Wrong link, but correct idea. > > This would be the correct link: > > https://gitlab.xiph.org/xiph/icecast-libshout > > > Using libshout is the recommended way to implement a source client. It does not only implement basic HTTP for you but also the application level logic needed for sending stream. It also allows your software to benefit from future development automagically. > > > If you want to go the PUT path (which is fine): > > You basically send one PUT request for all of the stream. The individual segments (tracks) must be muxed according to the specification of the format you use. Most formats use simple chaining (basically when one segment ends just send the next one). But you need to check that with the specification of your format. > > When doing the PUT request you must take care of those points: > * Send the correct content-type. You can find a list to start with > at: https://wiki.xiph.org/MIMETypesCodecs > * Authorization must follow the HTTP standards including > challenge-response. This requires a minimum of two requests (the > one resulting in the challenge and the response. :) > * Keep-Alive is preferred but may not be supported or not > supported with the given operation on older servers. It is also > a hop-to-hop property not an end-to-end property of HTTP and > therefore might also be terminated by intermediate hops. > * PUT should use 100-continue. Different Icecast versions have > different levels of conformance with the standard. So > workarounds may be needed. Also 100-continue is hop-to-hop so > the same apply as above. > * Chunked transfer is not supported by all Icecast versions. > However Identity transfer-encoding is used by all of them. > Autodetection may be needed here. Also, again, transfer-encoding > is hop-to-hop. > * Older versions of Icecast (which should not be used anyway, as > those version have critical security vulnerabilities) do not > support PUT. > > libshout takes care of all that by itself for you as well as more things like timing. Full HTTP implementations will take care of parts of it, such as the authorization part and keep-alive. >-- Philipp Schafft (CEO/Geschäftsführer) Telephon: +49.3535 490 17 92 Löwenfelsen UG (haftungsbeschränkt) Registration number: Bickinger Straße 21 HRB 12308 CB 04916 Herzberg (Elster) VATIN/USt-ID: Germany DE305133015 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part URL: <http://lists.xiph.org/pipermail/icecast/attachments/20190506/e4d94648/attachment.sig>
Hello again, for now I figuered out to send a mp3 stream to IceCast with TCP Socket communication. Now I'm challenged with the correct timing for the data packets. Are there any API calls for getting the state of IceCast's buffer? I'm programming now on a scheduler for sending the mp3 frames, depending on the metada of each frame. I hope, that this is precisly enough. Can you tell me in a nutshell, how libshout is handling this problem? Thanks for your help. With best regards, Jürgen -----Ursprüngliche Nachricht----- Von: Icecast <icecast-bounces at xiph.org> Im Auftrag von Philipp Schafft Gesendet: Montag, 6. Mai 2019 11:03 An: Icecast streaming server user discussions <icecast at xiph.org> Betreff: Re: [Icecast] Source client with HTTP PUT Good morning, On Mon, 2019-05-06 at 08:44 +0000, Jürgen Bund wrote:> Hello again, > thanks for your response. > > I have still some questions: > I want to stream a 24/7 radiochannel with mp3s. So I can't send all mp3s with one http PUT request. > So is there a possibility for that with http PUT? > If yes, how can I send the next mp3, so that icecast is playing it fluently (continuesly)?Yes: You need to send all the data in one PUT request. This is how it works. You send them concatenate with correct timing applied (which is another feature of libshout). [0]> If not, is there a documentation for a TCP Socket Communication?Yes. The HTTP RFCs. Because what Mr. Gleason suggests is that you implement HTTP PUT yourself. That is: RFCs 7230, 7231, 7234, 7235, 7236, 7617, and maybe 7616. You may also want to have a look at RFCs 2817, and 2818 for TLS.> Libshout is a c++ library. Is there a wrapper for .Net or a .dll, so I can use it in my C# Client?It is a pure C library, not C++. I'm not aware of such a binding myself. However maybe someone else is. I'm a POSIX developer so this is just not my area of work. :) With best regards, [0] Please note that you must strip any surrounding containers such as ID3 as the stream is pure MP3 data.> -----Ursprüngliche Nachricht----- > Von: Icecast <icecast-bounces at xiph.org> Im Auftrag von Philipp Schafft > Gesendet: Samstag, 4. Mai 2019 15:15 > An: fredg at paravelsystems.com; Icecast streaming server user > discussions <icecast at xiph.org> > Betreff: Re: [Icecast] Source client with HTTP PUT > > Good afternoon, > > On Fri, 2019-05-03 at 12:24 -0400, Fred Gleason wrote: > > On Fri, 2019-05-03 at 13:19 +0000, Jürgen Bund wrote: > > > I’m writting a source client in c#, in which I’m sending chunks of > > > a > > > mp3 file with http Put to IceCast. > > > My problem is, that it is not a continues stream. Each http PUT > > > request is an extra track. > > > How can I generate an ongoing stream with mp3 chunks, which I send > > > per http Put to IceCast. > > > > Don't use PUT at all. Instead, open a TCP socket connection to the > > port that the server is running on, write all of your headers to > > that (terminating each one with a CR/LF), send a naked CR/LF to tell > > Icecast that your done sending headers and then start writing content. > > ***Please don't.*** This is the worst way if implementing source clients. And there are already too many broken ones. > > > > You may want to check out the libshout library, which can handle > > most of the low-level nitty-gritty stuff for you 'auto-magically'. > > > > https://github.com/xiph/Icecast-libshout > > Wrong link, but correct idea. > > This would be the correct link: > > https://gitlab.xiph.org/xiph/icecast-libshout > > > Using libshout is the recommended way to implement a source client. It does not only implement basic HTTP for you but also the application level logic needed for sending stream. It also allows your software to benefit from future development automagically. > > > If you want to go the PUT path (which is fine): > > You basically send one PUT request for all of the stream. The individual segments (tracks) must be muxed according to the specification of the format you use. Most formats use simple chaining (basically when one segment ends just send the next one). But you need to check that with the specification of your format. > > When doing the PUT request you must take care of those points: > * Send the correct content-type. You can find a list to start with > at: https://wiki.xiph.org/MIMETypesCodecs > * Authorization must follow the HTTP standards including > challenge-response. This requires a minimum of two requests (the > one resulting in the challenge and the response. :) > * Keep-Alive is preferred but may not be supported or not > supported with the given operation on older servers. It is also > a hop-to-hop property not an end-to-end property of HTTP and > therefore might also be terminated by intermediate hops. > * PUT should use 100-continue. Different Icecast versions have > different levels of conformance with the standard. So > workarounds may be needed. Also 100-continue is hop-to-hop so > the same apply as above. > * Chunked transfer is not supported by all Icecast versions. > However Identity transfer-encoding is used by all of them. > Autodetection may be needed here. Also, again, transfer-encoding > is hop-to-hop. > * Older versions of Icecast (which should not be used anyway, as > those version have critical security vulnerabilities) do not > support PUT. > > libshout takes care of all that by itself for you as well as more things like timing. Full HTTP implementations will take care of parts of it, such as the authorization part and keep-alive. >-- Philipp Schafft (CEO/Geschäftsführer) Telephon: +49.3535 490 17 92 Löwenfelsen UG (haftungsbeschränkt) Registration number: Bickinger Straße 21 HRB 12308 CB 04916 Herzberg (Elster) VATIN/USt-ID: Germany DE305133015
Good morning, On Tue, 2019-05-07 at 11:49 +0000, Jürgen Bund wrote:> Hello again, > for now I figuered out to send a mp3 stream to IceCast with TCP Socket communication. > Now I'm challenged with the correct timing for the data packets.> Are there any API calls for getting the state of IceCast's buffer?The size of the buffer in Icecast is the queue-size. And beside right after the stream start it is always full (as per how queues work). Plus there is no point in asking for it. Icecast does not touch the data or it's timing. It will send to the listeners as fast and as slow as the source sends.> I'm programming now on a scheduler for sending the mp3 frames, depending on the metada of each frame. > I hope, that this is precisly enough.For MP3 that seems to be the correct way.> Can you tell me in a nutshell, how libshout is handling this problem?libshout has a demuxer for supported formats. From the demuxer it is informed about the relative timestamps of the data it sends. Using this relative time and the time that actually passed it will tell the caller how long to wait before the next chunk must be sent. There is also a sleep function that suspends the calling thread for the right amount of time. This is very handy for simple source clients. I still very strongly recommend to spend the time in writing a binding for libshout than to reimplement libshout. With best regards,> -----Ursprüngliche Nachricht----- > Von: Icecast <icecast-bounces at xiph.org> Im Auftrag von Philipp Schafft > Gesendet: Montag, 6. Mai 2019 11:03 > An: Icecast streaming server user discussions <icecast at xiph.org> > Betreff: Re: [Icecast] Source client with HTTP PUT > > Good morning, > > On Mon, 2019-05-06 at 08:44 +0000, Jürgen Bund wrote: > > Hello again, > > thanks for your response. > > > > I have still some questions: > > I want to stream a 24/7 radiochannel with mp3s. So I can't send all mp3s with one http PUT request. > > So is there a possibility for that with http PUT? > > If yes, how can I send the next mp3, so that icecast is playing it fluently (continuesly)? > > Yes: You need to send all the data in one PUT request. This is how it works. You send them concatenate with correct timing applied (which is another feature of libshout). [0] > > > > If not, is there a documentation for a TCP Socket Communication? > > Yes. The HTTP RFCs. Because what Mr. Gleason suggests is that you implement HTTP PUT yourself. > > That is: RFCs 7230, 7231, 7234, 7235, 7236, 7617, and maybe 7616. You may also want to have a look at RFCs 2817, and 2818 for TLS. > > > > Libshout is a c++ library. Is there a wrapper for .Net or a .dll, so I can use it in my C# Client? > > It is a pure C library, not C++. I'm not aware of such a binding myself. > However maybe someone else is. I'm a POSIX developer so this is just not my area of work. :) > > > With best regards, > > [0] Please note that you must strip any surrounding containers such as > ID3 as the stream is pure MP3 data. > > > > -----Ursprüngliche Nachricht----- > > Von: Icecast <icecast-bounces at xiph.org> Im Auftrag von Philipp Schafft > > Gesendet: Samstag, 4. Mai 2019 15:15 > > An: fredg at paravelsystems.com; Icecast streaming server user > > discussions <icecast at xiph.org> > > Betreff: Re: [Icecast] Source client with HTTP PUT > > > > Good afternoon, > > > > On Fri, 2019-05-03 at 12:24 -0400, Fred Gleason wrote: > > > On Fri, 2019-05-03 at 13:19 +0000, Jürgen Bund wrote: > > > > I’m writting a source client in c#, in which I’m sending chunks of > > > > a > > > > mp3 file with http Put to IceCast. > > > > My problem is, that it is not a continues stream. Each http PUT > > > > request is an extra track. > > > > How can I generate an ongoing stream with mp3 chunks, which I send > > > > per http Put to IceCast. > > > > > > Don't use PUT at all. Instead, open a TCP socket connection to the > > > port that the server is running on, write all of your headers to > > > that (terminating each one with a CR/LF), send a naked CR/LF to tell > > > Icecast that your done sending headers and then start writing content. > > > > ***Please don't.*** This is the worst way if implementing source clients. And there are already too many broken ones. > > > > > > > You may want to check out the libshout library, which can handle > > > most of the low-level nitty-gritty stuff for you 'auto-magically'. > > > > > > https://github.com/xiph/Icecast-libshout > > > > Wrong link, but correct idea. > > > > This would be the correct link: > > > > https://gitlab.xiph.org/xiph/icecast-libshout > > > > > > Using libshout is the recommended way to implement a source client. It does not only implement basic HTTP for you but also the application level logic needed for sending stream. It also allows your software to benefit from future development automagically. > > > > > > If you want to go the PUT path (which is fine): > > > > You basically send one PUT request for all of the stream. The individual segments (tracks) must be muxed according to the specification of the format you use. Most formats use simple chaining (basically when one segment ends just send the next one). But you need to check that with the specification of your format. > > > > When doing the PUT request you must take care of those points: > > * Send the correct content-type. You can find a list to start with > > at: https://wiki.xiph.org/MIMETypesCodecs > > * Authorization must follow the HTTP standards including > > challenge-response. This requires a minimum of two requests (the > > one resulting in the challenge and the response. :) > > * Keep-Alive is preferred but may not be supported or not > > supported with the given operation on older servers. It is also > > a hop-to-hop property not an end-to-end property of HTTP and > > therefore might also be terminated by intermediate hops. > > * PUT should use 100-continue. Different Icecast versions have > > different levels of conformance with the standard. So > > workarounds may be needed. Also 100-continue is hop-to-hop so > > the same apply as above. > > * Chunked transfer is not supported by all Icecast versions. > > However Identity transfer-encoding is used by all of them. > > Autodetection may be needed here. Also, again, transfer-encoding > > is hop-to-hop. > > * Older versions of Icecast (which should not be used anyway, as > > those version have critical security vulnerabilities) do not > > support PUT. > > > > libshout takes care of all that by itself for you as well as more things like timing. Full HTTP implementations will take care of parts of it, such as the authorization part and keep-alive.-- Philipp Schafft (CEO/Geschäftsführer) Telephon: +49.3535 490 17 92 Löwenfelsen UG (haftungsbeschränkt) Registration number: Bickinger Straße 21 HRB 12308 CB 04916 Herzberg (Elster) VATIN/USt-ID: Germany DE305133015 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part URL: <http://lists.xiph.org/pipermail/icecast/attachments/20190513/8b1413a0/attachment.sig>