From sytze.visser at gmail.com Wed May 1 09:58:11 2019 From: sytze.visser at gmail.com (Sytze Visser) Date: Wed, 1 May 2019 11:58:11 +0200 Subject: [Icecast] Webm files written without duration in header Message-ID: Dear all I am streaming live with webm with ffmpeg to icecast 2.4.2. After the stream ends, I am unable to determine the duration of the file using ffprobe or mediainfo. Not sure but it seems that this has to do with headers? Should icecast be writing the duration into the header or should this somehow be passed from ffmpeg? The requirement is really to determine the duration of the streamed event (i.e. not radio). Would appreciate some advice here. -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas at ruecker.fi Wed May 1 14:38:55 2019 From: thomas at ruecker.fi (=?UTF-8?Q?Thomas_B=2e_R=c3=bccker?=) Date: Wed, 1 May 2019 14:38:55 +0000 Subject: [Icecast] Webm files written without duration in header In-Reply-To: References: Message-ID: <654b7188-3267-d5b2-57d0-bd2066e1b161@ruecker.fi> Hi, On 5/1/19 9:58 AM, Sytze Visser wrote: > I am streaming live with webm with ffmpeg to icecast 2.4.2. After the > stream ends, I am unable to determine the duration of the file using > ffprobe or mediainfo. Not sure but it seems that this has to do with > headers? It's a fundamental limitation of this type of streaming that the duration can not be determined beforehand and there is no way for a simple client to append necessary information. > Should icecast be writing the duration into the header or should this > somehow be passed from ffmpeg? Does this mean you are using the dump feature to write the complete stream to a file on the machine running Icecast? > The requirement is really to determine the duration of the streamed > event (i.e. not radio). I'm not sure how to interpret this, there seem to be some unstated assumptions, as e.g. radio broadcast has the same fundamental issues. Nevertheless there is a trivial solution to address a file that is missing such information: remux it. This does not change the payload in any way, the Video and Audio (and any other) bit-streams will not be changed. Only the WebM container information gets rewritten. If there are malformed portions of the stream (caused by e.g. CPU starved encoder or network stall), then those might get removed though as a player wouldn't play them properly either. There are many dedicated tools for remuxing MKV and or WebM. A somewhat brute-force quick fix is of course: `ffmpeg -i foo.webm -c copy bar.webm` Cheers, TBR From sytze.visser at gmail.com Wed May 1 17:56:49 2019 From: sytze.visser at gmail.com (Sytze Visser) Date: Wed, 1 May 2019 19:56:49 +0200 Subject: [Icecast] Webm files written without duration in header In-Reply-To: <654b7188-3267-d5b2-57d0-bd2066e1b161@ruecker.fi> References: <654b7188-3267-d5b2-57d0-bd2066e1b161@ruecker.fi> Message-ID: Hi there Thanks Thomas. I was hoping to avoid remuxing as my objective is to run an extremely lightweight server. Just tested and the CPU runs between 9% and 23% for a lecture of 90 minutes - took 18sec. Yes it's a lightweight server, but like I said, that's the objective, and quite a nice challenge :-) CPU = cost and if you have to remux for 1000 clients in a day, integrity of live streams currently running are at risk. Going to put some more thinking into it. *You mentioned:* "Does this mean you are using the dump feature to write the complete stream to a file on the machine running Icecast?" *Yes*. Curious as to why you ask. Can one perhaps point it to a named pipe and pass to ffmpeg to remux and be a little more efficient on CPU? Alternatively, can you do ffmpeg -c copy ..... ? Is it supported? Have been on Linux for less than a year so not sure if at all possible? I have no idea yet what a 1000 fifo's will do. *On another note:* The other BIG issue is to support apple users. iOS/Safari seems to be 11% of the market (https://caniuse.com/#search=HLS) and I cant ignore them. Will have to use HLS to keep them happy but again the CPU overhead is imminent as vorbis/VP8 is miles away from AAC/H.264. Icecast is very CPU efficient ingesting, streaming and writing out a webm file, CPU 1-2%. Same efficiency situation with nginx and RTMP streaming in and serving HLS to iOS users. I read somewhere that MP4 is not supported on icecast, which is a pity. I have invested a lot in an icecast based audio solution and want expand it with video. *So my question is now: * MP4 (H.264) is a close relative of HLS (can also be H.264) which brings me very close to a solution. If webm/ogv is supported but mp4 not, what is the technical differences in how icecast handles the one and not the other? What does icecast manage/do for supported formats as opposed to unsupported ones? Best regards On Wed, May 1, 2019 at 4:39 PM Thomas B. R?cker wrote: > Hi, > > On 5/1/19 9:58 AM, Sytze Visser wrote: > > I am streaming live with webm with ffmpeg to icecast 2.4.2. After the > > stream ends, I am unable to determine the duration of the file using > > ffprobe or mediainfo. Not sure but it seems that this has to do with > > headers? > > > It's a fundamental limitation of this type of streaming that the > duration can not be determined beforehand and there is no way for a > simple client to append necessary information. > > > > > Should icecast be writing the duration into the header or should this > > somehow be passed from ffmpeg? > > > Does this mean you are using the dump feature to write the complete > stream to a file on the machine running Icecast? > > > > > The requirement is really to determine the duration of the streamed > > event (i.e. not radio). > > > I'm not sure how to interpret this, there seem to be some unstated > assumptions, as e.g. radio broadcast has the same fundamental issues. > > Nevertheless there is a trivial solution to address a file that is > missing such information: remux it. > This does not change the payload in any way, the Video and Audio (and > any other) bit-streams will not be changed. Only the WebM container > information gets rewritten. If there are malformed portions of the > stream (caused by e.g. CPU starved encoder or network stall), then those > might get removed though as a player wouldn't play them properly either. > > There are many dedicated tools for remuxing MKV and or WebM. > A somewhat brute-force quick fix is of course: `ffmpeg -i foo.webm -c > copy bar.webm` > > > Cheers, > > TBR > > > > _______________________________________________ > Icecast mailing list > Icecast at xiph.org > http://lists.xiph.org/mailman/listinfo/icecast > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fredg at paravelsystems.com Wed May 1 18:51:12 2019 From: fredg at paravelsystems.com (Fred Gleason) Date: Wed, 01 May 2019 14:51:12 -0400 Subject: [Icecast] Webm files written without duration in header In-Reply-To: References: <654b7188-3267-d5b2-57d0-bd2066e1b161@ruecker.fi> Message-ID: On Wed, 2019-05-01 at 19:56 +0200, Sytze Visser wrote: > I read somewhere that MP4 is not supported on icecast, which is a > pity. I have invested a lot in an icecast based audio solution and > want expand it with video. It all depends on what one means by 'MP4' (which is more a marketing term than a technical one). AAC+ (aka 'high efficiency' AAC) works very well on IceCast, albeit that only covers the audio side on the equation. > So my question is now: > MP4 (H.264) is a close relative of HLS (can also be H.264) which > brings me very close to a solution. You're mixing apples and oranges here (pun accidental). H.264 is a content encoding, like MPEG Layer III (so-called 'MP3') or OggVorbis. HLS OTOH is a streaming architecture, and as such is largely orthogonal to the content encoding used. It works by segmenting the media stream into discrete files and then distributing them via HTTP(S). The big advantage of this approach is that standard 'garden variety' web servers (think Apache) can be used to serve the streams, which makes it play particularly well with CDNs, at the cost of significantly greater complexity in the encoder and player components. No specialized 'streaming server' (such as Icecast) is required in the HLS ecosystem at all. Cheers! |---------------------------------------------------------------------| | Frederick F. Gleason, Jr. | Chief Developer | | | Paravel Systems | |---------------------------------------------------------------------| | An expert is a person who avoids the small errors while he sweeps | | on to the grand fallacy. | | | | -- Benjamin Stolberg | |---------------------------------------------------------------------| From sytze.visser at gmail.com Wed May 1 20:06:12 2019 From: sytze.visser at gmail.com (Sytze Visser) Date: Wed, 1 May 2019 22:06:12 +0200 Subject: [Icecast] Webm files written without duration in header In-Reply-To: References: <654b7188-3267-d5b2-57d0-bd2066e1b161@ruecker.fi> Message-ID: <5cc9fc34.1c69fb81.f8811.9bd5@mx.google.com> Hi Fred. Appreciate your response. Maybe in my explanation I have some red and green apples, but I can agree that my understanding is as you explained it. ? The point is that if I can successfully stream mp4 with H.264 and AAC encoding without any issues to icecast, I can then use ffmpeg to turn it into HLS which then solves my iOS support issue. The CPU cost of repackaging MP4 into HLS architecture should be minimal because at the core it?s all H.264. No transcoding! Low CPU objective achieved! Additional bonus is that I already use Apach2 with icecast and integrating the whole lot into my existing infrastructure is easy. My question remains If webm/ogv is supported but mp4 not, what are the technical differences in how icecast handles the one and not the other? What does icecast manage/do for supported formats as opposed to unsupported ones? Kind regards On Wed, 2019-05-01 at 19:56 +0200, Sytze Visser wrote: > I read somewhere that MP4 is not supported on icecast, which is a > pity. I have invested a lot in an icecast based audio solution and > want expand it with video. It all depends on what one means by 'MP4' (which is more a marketing term than a technical one). AAC+ (aka 'high efficiency' AAC) works very well on IceCast, albeit that only covers the audio side on the equation. > So my question is now: > MP4 (H.264) is a close relative of HLS (can also be H.264) which > brings me very close to a solution. You're mixing apples and oranges here (pun accidental). H.264 is a content encoding, like MPEG Layer III (so-called 'MP3') or OggVorbis. HLS OTOH is a streaming architecture, and as such is largely orthogonal to the content encoding used. It works by segmenting the media stream into discrete files and then distributing them via HTTP(S). The big advantage of this approach is that standard 'garden variety' web servers (think Apache) can be used to serve the streams, which makes it play particularly well with CDNs, at the cost of significantly greater complexity in the encoder and player components. No specialized 'streaming server' (such as Icecast) is required in the HLS ecosystem at all. Cheers! |---------------------------------------------------------------------| | Frederick F. Gleason, Jr. | Chief Developer | | | Paravel Systems | |---------------------------------------------------------------------| | An expert is a person who avoids the small errors while he sweeps | | on to the grand fallacy. | | | | -- Benjamin Stolberg | |---------------------------------------------------------------------| _______________________________________________ Icecast mailing list Icecast at xiph.org http://lists.xiph.org/mailman/listinfo/icecast -------------- next part -------------- An HTML attachment was scrubbed... URL: From epirat07 at gmail.com Wed May 1 20:19:47 2019 From: epirat07 at gmail.com (Marvin Scholz) Date: Wed, 01 May 2019 22:19:47 +0200 Subject: [Icecast] Webm files written without duration in header In-Reply-To: <5cc9fc34.1c69fb81.f8811.9bd5@mx.google.com> References: <654b7188-3267-d5b2-57d0-bd2066e1b161@ruecker.fi> <5cc9fc34.1c69fb81.f8811.9bd5@mx.google.com> Message-ID: <53871393-9AFA-4A96-8517-71048AE407EE@gmail.com> On 1 May 2019, at 22:06, Sytze Visser wrote: > Hi Fred. > > Appreciate your response. > > Maybe in my explanation I have some red and green apples, but I can > agree that my understanding is as you explained it. ? > > The point is that if I can successfully stream mp4 with H.264 and AAC > encoding without any issues to icecast, I can then use ffmpeg to Hi, just a quick thing to clarify before you waste too much time on this: MP4 is not streamable due to the way the format works. The header/trailer that a valid mp4 files needs to have, requires "knowledge" of the whole file which makes it impossible to stream it. What HLS or DASH does is not "streaming" in the "traditional" sense of streaming but rather it is downloading small complete file chunks that nowadays mostly use fragmented MP4. You can't stream MP4 with Icecast. If you for some reason have to stream H.264 you could use MPEG TS. Note that this might have licensing implications as MPEG TS is not royalty-free. > turn it into HLS which then solves my iOS support issue. The CPU > cost of repackaging MP4 into HLS architecture should be minimal > because at the core it?s all H.264. No transcoding! Low CPU objective > achieved! > Additional bonus is that I already use Apach2 with icecast and > integrating the whole lot into my existing infrastructure is easy. > > My question remains > If webm/ogv is supported but mp4 not, what are the technical differences > in how icecast handles the one and not the other? What does icecast > manage/do for supported formats as opposed to unsupported ones? > > Kind regards > > On Wed, 2019-05-01 at 19:56 +0200, Sytze Visser wrote: >> I read somewhere that MP4 is not supported on icecast, which is a >> pity. I have invested a lot in an icecast based audio solution and >> want expand it with video. > > It all depends on what one means by 'MP4' (which is more a marketing > term than a technical one). AAC+ (aka 'high efficiency' AAC) works very > well on IceCast, albeit that only covers the audio side on the > equation. > >> So my question is now: >> MP4 (H.264) is a close relative of HLS (can also be H.264) which >> brings me very close to a solution. > > You're mixing apples and oranges here (pun accidental). H.264 is a > content encoding, like MPEG Layer III (so-called 'MP3') or OggVorbis. > HLS OTOH is a streaming architecture, and as such is largely orthogonal > to the content encoding used. It works by segmenting the media stream > into discrete files and then distributing them via HTTP(S). The big > advantage of this approach is that standard 'garden variety' web > servers (think Apache) can be used to serve the streams, which makes it > play particularly well with CDNs, at the cost of significantly greater > complexity in the encoder and player components. No specialized > 'streaming server' (such as Icecast) is required in the HLS ecosystem > at all. > > Cheers! > > > |---------------------------------------------------------------------| > | Frederick F. Gleason, Jr. | Chief Developer | > | | Paravel Systems | > |---------------------------------------------------------------------| > | An expert is a person who avoids the small errors while he sweeps | > | on to the grand fallacy. | > | | > | -- Benjamin Stolberg | > |---------------------------------------------------------------------| > > _______________________________________________ > Icecast mailing list > Icecast at xiph.org > http://lists.xiph.org/mailman/listinfo/icecast > > _______________________________________________ > Icecast mailing list > Icecast at xiph.org > http://lists.xiph.org/mailman/listinfo/icecast From fredg at paravelsystems.com Wed May 1 20:30:57 2019 From: fredg at paravelsystems.com (Fred Gleason) Date: Wed, 01 May 2019 16:30:57 -0400 Subject: [Icecast] Webm files written without duration in header In-Reply-To: <5cc9fc34.1c69fb81.f8811.9bd5@mx.google.com> References: <654b7188-3267-d5b2-57d0-bd2066e1b161@ruecker.fi> <5cc9fc34.1c69fb81.f8811.9bd5@mx.google.com> Message-ID: On Wed, 2019-05-01 at 22:06 +0200, Sytze Visser wrote: > The point is that if I can successfully stream mp4 with H.264 and AAC > encoding without any issues to icecast, I can then use ffmpeg to > turn it into HLS which then solves my iOS support issue. The CPU > cost of repackaging MP4 into HLS architecture should be minimal > because at the core it?s all H.264. No transcoding! Low CPU objective > achieved! So all FFMPEG is doing is segmenting the stream and generating the m3u8 index? Yes, I'd expect that to be quite efficient. > My question remains > If webm/ogv is supported but mp4 not, what are the technical > differences > in how icecast handles the one and not the other? What does icecast > manage/do for supported formats as opposed to unsupported ones? It's been a few years since I looked at the source, but IIRC adding support for a new codec is pretty simple -- mostly a matter of getting it to recognize and emit the correct mimetype(s). Of course, you'll also need an ICES client that is capable of supporting the desired codec. That may be more challenging than hacking Icecast itself. Cheers! |---------------------------------------------------------------------| | Frederick F. Gleason, Jr. | Chief Developer | | | Paravel Systems | |---------------------------------------------------------------------| | There is only one thing worse than having your competitors trying | | to inter-operate with your systems - and that is to have your | | competitors *not* trying to inter-operate with your systems. | | | | -- Alan(UK), GrokLaw.net | |---------------------------------------------------------------------| From epirat07 at gmail.com Wed May 1 20:41:03 2019 From: epirat07 at gmail.com (Marvin Scholz) Date: Wed, 01 May 2019 22:41:03 +0200 Subject: [Icecast] Webm files written without duration in header In-Reply-To: References: <654b7188-3267-d5b2-57d0-bd2066e1b161@ruecker.fi> <5cc9fc34.1c69fb81.f8811.9bd5@mx.google.com> Message-ID: <729A0F94-A68F-4613-86B0-F5F9BB8240DE@gmail.com> On 1 May 2019, at 22:30, Fred Gleason wrote: > On Wed, 2019-05-01 at 22:06 +0200, Sytze Visser wrote: >> The point is that if I can successfully stream mp4 with H.264 and AAC >> encoding without any issues to icecast, I can then use ffmpeg to >> turn it into HLS which then solves my iOS support issue. The CPU >> cost of repackaging MP4 into HLS architecture should be minimal >> because at the core it?s all H.264. No transcoding! Low CPU objective >> achieved! > > So all FFMPEG is doing is segmenting the stream and generating the m3u8 > index? Yes, I'd expect that to be quite efficient. Depending how you segment the stream it can be very efficient as only remuxing is required in some cases. > > >> My question remains >> If webm/ogv is supported but mp4 not, what are the technical >> differences >> in how icecast handles the one and not the other? What does icecast >> manage/do for supported formats as opposed to unsupported ones? > > It's been a few years since I looked at the source, but IIRC adding > support for a new codec is pretty simple -- mostly a matter of getting > it to recognize and emit the correct mimetype(s). It is not as trivial as that, basically Icecast needs to be able to properly packetize the format and ideally read metadata from it. Especially for video it can be even more complex, as ideally Icecast would ensure to send clients video data starting with a keyframe if one is in the buffer. And as I already wrote in my last mail, MP4 is not streamable. > > Of course, you'll also need an ICES client that is capable of > supporting the desired codec. That may be more challenging than hacking > Icecast itself. > FFMpeg is already capable to stream nearly any format to Icecast, of course if it works or not depends a lot on the format as for all unsupported formats Icecast does no handling whatsoever. > Cheers! > > > |---------------------------------------------------------------------| > | Frederick F. Gleason, Jr. | Chief Developer | > | | Paravel Systems | > |---------------------------------------------------------------------| > | There is only one thing worse than having your competitors trying | > | to inter-operate with your systems - and that is to have your | > | competitors *not* trying to inter-operate with your systems. | > | | > | -- Alan(UK), GrokLaw.net | > |---------------------------------------------------------------------| > > _______________________________________________ > Icecast mailing list > Icecast at xiph.org > http://lists.xiph.org/mailman/listinfo/icecast From sytze.visser at gmail.com Wed May 1 22:50:14 2019 From: sytze.visser at gmail.com (Sytze Visser) Date: Thu, 2 May 2019 00:50:14 +0200 Subject: [Icecast] Webm files written without duration in header In-Reply-To: <53871393-9AFA-4A96-8517-71048AE407EE@gmail.com> References: <654b7188-3267-d5b2-57d0-bd2066e1b161@ruecker.fi> <5cc9fc34.1c69fb81.f8811.9bd5@mx.google.com> <53871393-9AFA-4A96-8517-71048AE407EE@gmail.com> Message-ID: Hi Marvin I followed this advice for updating moov flags in mp4 and it "streams" directly from the file location on the server with html5 video: https://rigor.com/blog/optimizing-mp4-video-for-fast-streaming. Progressive downloading, seeking and video time all works 100% on a 195MB file. Regards On Wed, May 1, 2019 at 10:19 PM Marvin Scholz wrote: > > > On 1 May 2019, at 22:06, Sytze Visser wrote: > > > Hi Fred. > > > > Appreciate your response. > > > > Maybe in my explanation I have some red and green apples, but I can > > agree that my understanding is as you explained it. ? > > > > The point is that if I can successfully stream mp4 with H.264 and AAC > > encoding without any issues to icecast, I can then use ffmpeg to > > Hi, > just a quick thing to clarify before you waste too much time on this: > > MP4 is not streamable due to the way the format works. The header/trailer > that a valid mp4 files needs to have, requires "knowledge" of the whole > file which makes it impossible to stream it. > > What HLS or DASH does is not "streaming" in the "traditional" sense of > streaming but rather it is downloading small complete file chunks that > nowadays mostly use fragmented MP4. > > You can't stream MP4 with Icecast. > If you for some reason have to stream H.264 you could use MPEG TS. > Note that this might have licensing implications as MPEG TS is not > royalty-free. > > > turn it into HLS which then solves my iOS support issue. The CPU > > cost of repackaging MP4 into HLS architecture should be minimal > > because at the core it?s all H.264. No transcoding! Low CPU objective > > achieved! > > Additional bonus is that I already use Apach2 with icecast and > > integrating the whole lot into my existing infrastructure is easy. > > > > My question remains > > If webm/ogv is supported but mp4 not, what are the technical differences > > in how icecast handles the one and not the other? What does icecast > > manage/do for supported formats as opposed to unsupported ones? > > > > Kind regards > > > > On Wed, 2019-05-01 at 19:56 +0200, Sytze Visser wrote: > >> I read somewhere that MP4 is not supported on icecast, which is a > >> pity. I have invested a lot in an icecast based audio solution and > >> want expand it with video. > > > > It all depends on what one means by 'MP4' (which is more a marketing > > term than a technical one). AAC+ (aka 'high efficiency' AAC) works very > > well on IceCast, albeit that only covers the audio side on the > > equation. > > > >> So my question is now: > >> MP4 (H.264) is a close relative of HLS (can also be H.264) which > >> brings me very close to a solution. > > > > You're mixing apples and oranges here (pun accidental). H.264 is a > > content encoding, like MPEG Layer III (so-called 'MP3') or OggVorbis. > > HLS OTOH is a streaming architecture, and as such is largely orthogonal > > to the content encoding used. It works by segmenting the media stream > > into discrete files and then distributing them via HTTP(S). The big > > advantage of this approach is that standard 'garden variety' web > > servers (think Apache) can be used to serve the streams, which makes it > > play particularly well with CDNs, at the cost of significantly greater > > complexity in the encoder and player components. No specialized > > 'streaming server' (such as Icecast) is required in the HLS ecosystem > > at all. > > > > Cheers! > > > > > > |---------------------------------------------------------------------| > > | Frederick F. Gleason, Jr. | Chief Developer | > > | | Paravel Systems | > > |---------------------------------------------------------------------| > > | An expert is a person who avoids the small errors while he sweeps | > > | on to the grand fallacy. | > > | | > > | -- Benjamin Stolberg | > > |---------------------------------------------------------------------| > > > > _______________________________________________ > > Icecast mailing list > > Icecast at xiph.org > > http://lists.xiph.org/mailman/listinfo/icecast > > > > _______________________________________________ > > Icecast mailing list > > Icecast at xiph.org > > http://lists.xiph.org/mailman/listinfo/icecast > _______________________________________________ > Icecast mailing list > Icecast at xiph.org > http://lists.xiph.org/mailman/listinfo/icecast > -------------- next part -------------- An HTML attachment was scrubbed... URL: From epirat07 at gmail.com Wed May 1 22:56:54 2019 From: epirat07 at gmail.com (Marvin Scholz) Date: Thu, 02 May 2019 00:56:54 +0200 Subject: [Icecast] Webm files written without duration in header In-Reply-To: References: <654b7188-3267-d5b2-57d0-bd2066e1b161@ruecker.fi> <5cc9fc34.1c69fb81.f8811.9bd5@mx.google.com> <53871393-9AFA-4A96-8517-71048AE407EE@gmail.com> Message-ID: <50B56024-833F-4C5C-A321-3F67F5488069@gmail.com> On 2 May 2019, at 0:50, Sytze Visser wrote: > Hi Marvin > > I followed this advice for updating moov flags in mp4 and it "streams" > directly from the file location on the server with html5 video: > https://rigor.com/blog/optimizing-mp4-video-for-fast-streaming. > > Progressive downloading, seeking and video time all works 100% on a 195MB > file. > Yes thats an entirely different thing than live-streaming though. Icecast is made for live-streaming not for serving on-demand video, any webserver can do that just fine, no need for Icecast in that case :) > Regards > > On Wed, May 1, 2019 at 10:19 PM Marvin Scholz wrote: > >> >> >> On 1 May 2019, at 22:06, Sytze Visser wrote: >> >>> Hi Fred. >>> >>> Appreciate your response. >>> >>> Maybe in my explanation I have some red and green apples, but I can >>> agree that my understanding is as you explained it. ? >>> >>> The point is that if I can successfully stream mp4 with H.264 and AAC >>> encoding without any issues to icecast, I can then use ffmpeg to >> >> Hi, >> just a quick thing to clarify before you waste too much time on this: >> >> MP4 is not streamable due to the way the format works. The header/trailer >> that a valid mp4 files needs to have, requires "knowledge" of the whole >> file which makes it impossible to stream it. >> >> What HLS or DASH does is not "streaming" in the "traditional" sense of >> streaming but rather it is downloading small complete file chunks that >> nowadays mostly use fragmented MP4. >> >> You can't stream MP4 with Icecast. >> If you for some reason have to stream H.264 you could use MPEG TS. >> Note that this might have licensing implications as MPEG TS is not >> royalty-free. >> >>> turn it into HLS which then solves my iOS support issue. The CPU >>> cost of repackaging MP4 into HLS architecture should be minimal >>> because at the core it?s all H.264. No transcoding! Low CPU objective >>> achieved! >>> Additional bonus is that I already use Apach2 with icecast and >>> integrating the whole lot into my existing infrastructure is easy. >>> >>> My question remains >>> If webm/ogv is supported but mp4 not, what are the technical differences >>> in how icecast handles the one and not the other? What does icecast >>> manage/do for supported formats as opposed to unsupported ones? >>> >>> Kind regards >>> >>> On Wed, 2019-05-01 at 19:56 +0200, Sytze Visser wrote: >>>> I read somewhere that MP4 is not supported on icecast, which is a >>>> pity. I have invested a lot in an icecast based audio solution and >>>> want expand it with video. >>> >>> It all depends on what one means by 'MP4' (which is more a marketing >>> term than a technical one). AAC+ (aka 'high efficiency' AAC) works very >>> well on IceCast, albeit that only covers the audio side on the >>> equation. >>> >>>> So my question is now: >>>> MP4 (H.264) is a close relative of HLS (can also be H.264) which >>>> brings me very close to a solution. >>> >>> You're mixing apples and oranges here (pun accidental). H.264 is a >>> content encoding, like MPEG Layer III (so-called 'MP3') or OggVorbis. >>> HLS OTOH is a streaming architecture, and as such is largely orthogonal >>> to the content encoding used. It works by segmenting the media stream >>> into discrete files and then distributing them via HTTP(S). The big >>> advantage of this approach is that standard 'garden variety' web >>> servers (think Apache) can be used to serve the streams, which makes it >>> play particularly well with CDNs, at the cost of significantly greater >>> complexity in the encoder and player components. No specialized >>> 'streaming server' (such as Icecast) is required in the HLS ecosystem >>> at all. >>> >>> Cheers! >>> >>> >>> |---------------------------------------------------------------------| >>> | Frederick F. Gleason, Jr. | Chief Developer | >>> | | Paravel Systems | >>> |---------------------------------------------------------------------| >>> | An expert is a person who avoids the small errors while he sweeps | >>> | on to the grand fallacy. | >>> | | >>> | -- Benjamin Stolberg | >>> |---------------------------------------------------------------------| >>> >>> _______________________________________________ >>> Icecast mailing list >>> Icecast at xiph.org >>> http://lists.xiph.org/mailman/listinfo/icecast >>> >>> _______________________________________________ >>> Icecast mailing list >>> Icecast at xiph.org >>> http://lists.xiph.org/mailman/listinfo/icecast >> _______________________________________________ >> Icecast mailing list >> Icecast at xiph.org >> http://lists.xiph.org/mailman/listinfo/icecast >> > _______________________________________________ > Icecast mailing list > Icecast at xiph.org > http://lists.xiph.org/mailman/listinfo/icecast From david at gibbs.net Thu May 2 15:25:09 2019 From: david at gibbs.net (David Gibbs) Date: Thu, 02 May 2019 08:25:09 -0700 Subject: [Icecast] Multiple connections from iPhones Message-ID: A newbie question I'm afraid. I have a site that streams to only about 20 or 30 listeners using Icecast for Windows 2.4.4 and Altacast. The issue - I often see multiple connections started almost simultaneously from one IP address, usually an iphone or ipad. The device descriptions are identical, and I know my listeners are listening from home, so my assumption is that one device is opening multiple connections. If I kill one connection they often all disappear from that IP address at once. Is this something others see? Does anyone know why these multiple connections are created? Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From sytze.visser at gmail.com Thu May 2 16:22:07 2019 From: sytze.visser at gmail.com (Sytze Visser) Date: Thu, 2 May 2019 18:22:07 +0200 Subject: [Icecast] Multiple connections from iPhones In-Reply-To: References: Message-ID: Hi David I have seen similar behavior and the conclusion was that icecast will connect a client once for each connection request. The double connection is a result of the player/browser that possibly checks if it can connect and then establishes the actual connection. If you don't have control over the source code of the player, you might have to live with the issue. Hope it helps. On Thu, 02 May 2019, 18:01 David Gibbs, wrote: > A newbie question I'm afraid. > > I have a site that streams to only about 20 or 30 listeners using Icecast > for Windows 2.4.4 and Altacast. > > The issue - I often see multiple connections started almost simultaneously > from one IP address, usually an iphone or ipad. The device descriptions are > identical, and I know my listeners are listening from home, so my > assumption is that one device is opening multiple connections. > > If I kill one connection they often all disappear from that IP address at > once. > > Is this something others see? Does anyone know why these multiple > connections are created? > > Thanks > _______________________________________________ > Icecast mailing list > Icecast at xiph.org > http://lists.xiph.org/mailman/listinfo/icecast > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas at ruecker.fi Fri May 3 07:19:40 2019 From: thomas at ruecker.fi (=?UTF-8?Q?Thomas_B=2e_R=c3=bccker?=) Date: Fri, 3 May 2019 07:19:40 +0000 Subject: [Icecast] Webm files written without duration in header In-Reply-To: References: <654b7188-3267-d5b2-57d0-bd2066e1b161@ruecker.fi> Message-ID: <9bacc6a2-85ed-09f6-b47a-489f19e4b96d@ruecker.fi> Hi, On 5/1/19 5:56 PM, Sytze Visser wrote: > Thanks Thomas. I was hoping to avoid remuxing as my objective is to > run an extremely lightweight server. Just tested and the CPU runs > between 9% and 23% for a lecture of 90 minutes - took 18sec. Yes it's > a lightweight server, but like I said, that's the objective, and quite > a nice challenge :-) CPU = cost and if you have to remux for 1000 > clients in a day, integrity of live streams currently running are at > risk. Going to put some more thinking into it. There should be no need to remux each file more than once, so unless you produce 1000 files per day, I dont't understand your point. Even in that case all those files won't be created at the exact same point in time and even if it is really easy to devise a funnel/queue that does the remuxing at low priority. Please note again that remuxing is NOT reencoding, the encoded information is not touched and it's very quick and efficient because of that. > *You mentioned:* > "Does this mean you are using the dump feature to write the complete > stream to a file on the machine running Icecast?" > > */Yes/*. Curious as to why you ask. Can one perhaps point it to a > named pipe and pass to ffmpeg to remux and be a little more efficient > on CPU? Alternatively, can you do ffmpeg -c copy > ..... ? Is it supported? Have been on Linux for less than > a year so not sure if at all possible? I have no idea yet what a 1000 > fifo's will do. Just needed to make sure how the files are generated. There may be slight differences between dumping a stream via e.g. curl or wget vs using the dump file. Nothing that matters to your use case though as before presenting any of these you should very much remux them to ensure file integrity as static files. Also *please* avoid sending HTML emails to the mailing list. Thanks. Cheers, TBR From Juergen.Bund at learnconsult.com Fri May 3 13:19:02 2019 From: Juergen.Bund at learnconsult.com (=?iso-8859-1?Q?J=FCrgen_Bund?=) Date: Fri, 3 May 2019 13:19:02 +0000 Subject: [Icecast] Source client with HTTP PUT Message-ID: <6ed9be46123d4afb97f768906172c95c@learnconsult.com> Hi, 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. Any suggestions? My headers are: Headers.Add("Content-Type", "audio/mpeg"); Headers.Add("Authorization", "Basic " + authInfo); Headers.Add("Ice-Public", "1"); Headers.Add("Ice-Name", "Teststream"); Headers.Add("Ice-Description", "This is just a simple test stream"); Headers.Add("Transfer-Encoding", "chunked"); Headers.Add("Ice-Audio-Info", "ice-bitrate=128;ice-channels=2;ice-samplerate=44100"); Headers.Add("Expect", "100-continue"); With Best Regards Juergen -------------- next part -------------- An HTML attachment was scrubbed... URL: From fredg at paravelsystems.com Fri May 3 16:24:28 2019 From: fredg at paravelsystems.com (Fred Gleason) Date: Fri, 03 May 2019 12:24:28 -0400 Subject: [Icecast] Source client with HTTP PUT In-Reply-To: <6ed9be46123d4afb97f768906172c95c@learnconsult.com> References: <6ed9be46123d4afb97f768906172c95c@learnconsult.com> Message-ID: <355396120cb7e40feeea0447d047e86a07fdd70a.camel@paravelsystems.com> 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. 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 Cheers! |---------------------------------------------------------------------| | Frederick F. Gleason, Jr. | Chief Developer | | | Paravel Systems | |---------------------------------------------------------------------| | A room without books is like a body without a soul. | | | | -- Cicero | |---------------------------------------------------------------------| From phschafft at de.loewenfelsen.net Sat May 4 13:15:15 2019 From: phschafft at de.loewenfelsen.net (Philipp Schafft) Date: Sat, 04 May 2019 13:15:15 +0000 Subject: [Icecast] Source client with HTTP PUT In-Reply-To: <355396120cb7e40feeea0447d047e86a07fdd70a.camel@paravelsystems.com> References: <6ed9be46123d4afb97f768906172c95c@learnconsult.com> <355396120cb7e40feeea0447d047e86a07fdd70a.camel@paravelsystems.com> Message-ID: <1556975715.1931.80.camel@de.loewenfelsen.net> 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. With best regards, -- 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: From fredg at paravelsystems.com Sat May 4 14:19:04 2019 From: fredg at paravelsystems.com (Fred Gleason) Date: Sat, 4 May 2019 10:19:04 -0400 Subject: [Icecast] Source client with HTTP PUT In-Reply-To: <1556975715.1931.80.camel@de.loewenfelsen.net> References: <6ed9be46123d4afb97f768906172c95c@learnconsult.com> <355396120cb7e40feeea0447d047e86a07fdd70a.camel@paravelsystems.com> <1556975715.1931.80.camel@de.loewenfelsen.net> Message-ID: <25B4DD39-8049-4C87-BF65-BD435CD4F166@paravelsystems.com> On Fri, 2019-05-03 at 12:24 -0400, Fred Gleason wrote: > 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. On May 4, 2019, at 09:15, Philipp Schafft wrote: > ***Please don't.*** This is the worst way if implementing source > clients. And there are already too many broken ones. As a general principle, I quite agree with you. In this specific case however, given the fact that libshout is missing certain bits ?e.g. support for AAC+ ? sometimes one has no choice. Cheers! |---------------------------------------------------------------------| | Frederick F. Gleason, Jr. | Chief Developer | | | Paravel Systems | |---------------------------------------------------------------------| | A room without books is like a body without a soul. | | | | -- Cicero | |---------------------------------------------------------------------| -------------- next part -------------- An HTML attachment was scrubbed... URL: From phschafft at de.loewenfelsen.net Sat May 4 17:05:35 2019 From: phschafft at de.loewenfelsen.net (Philipp Schafft) Date: Sat, 04 May 2019 17:05:35 +0000 Subject: [Icecast] Source client with HTTP PUT In-Reply-To: <25B4DD39-8049-4C87-BF65-BD435CD4F166@paravelsystems.com> References: <6ed9be46123d4afb97f768906172c95c@learnconsult.com> <355396120cb7e40feeea0447d047e86a07fdd70a.camel@paravelsystems.com> <1556975715.1931.80.camel@de.loewenfelsen.net> <25B4DD39-8049-4C87-BF65-BD435CD4F166@paravelsystems.com> Message-ID: <1556989535.1931.86.camel@de.loewenfelsen.net> Good afternoon, On Sat, 2019-05-04 at 10:19 -0400, Fred Gleason wrote: > On Fri, 2019-05-03 at 12:24 -0400, Fred Gleason wrote: > > > 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. > > > On May 4, 2019, at 09:15, Philipp Schafft > wrote: > > > ***Please don't.*** This is the worst way if implementing source > > clients. And there are already too many broken ones. > > As a general principle, I quite agree with you. In this specific case > however, given the fact that libshout is missing certain bits ?e.g. > support for AAC+ ? sometimes one has no choice. Which exact open tickets do you refer to with "certain bits"? Would be happy to look into them with you. Also feel free to offer some sponsoring to implement them. Considering your signature it looks like you're in the position to do so and therefore not only get the "bits" you need implemented but also help others this way. Looking forward to your mail regarding this! Back to the original topic: Even if you need to use something that libshout does not support and for some reason the problem could not be solved upstream, there is *NO* reason to ever implement this using low level socket programming. If you go that way *ALWAYS* use a HTTP library. Implementing this using low level socket programming is *ALWAYS* the wrong way to do it. With best regards, -- 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: From Juergen.Bund at learnconsult.com Mon May 6 08:44:25 2019 From: Juergen.Bund at learnconsult.com (=?utf-8?B?SsO8cmdlbiBCdW5k?=) Date: Mon, 6 May 2019 08:44:25 +0000 Subject: [Icecast] Source client with HTTP PUT In-Reply-To: <1556975715.1931.80.camel@de.loewenfelsen.net> References: <6ed9be46123d4afb97f768906172c95c@learnconsult.com> <355396120cb7e40feeea0447d047e86a07fdd70a.camel@paravelsystems.com> <1556975715.1931.80.camel@de.loewenfelsen.net> Message-ID: <899866d2f1f04da2b3c25e6e11b3b04e@learnconsult.com> 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)? If not, is there a documentation for a TCP Socket Communication? Libshout is a c++ library. Is there a wrapper for .Net or a .dll, so I can use it in my C# Client? With best regards, J?rgen -----Urspr?ngliche Nachricht----- Von: Icecast Im Auftrag von Philipp Schafft Gesendet: Samstag, 4. Mai 2019 15:15 An: fredg at paravelsystems.com; Icecast streaming server user discussions 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. With best regards, -- 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 From phschafft at de.loewenfelsen.net Mon May 6 09:02:48 2019 From: phschafft at de.loewenfelsen.net (Philipp Schafft) Date: Mon, 06 May 2019 09:02:48 +0000 Subject: [Icecast] Source client with HTTP PUT In-Reply-To: <899866d2f1f04da2b3c25e6e11b3b04e@learnconsult.com> References: <6ed9be46123d4afb97f768906172c95c@learnconsult.com> <355396120cb7e40feeea0447d047e86a07fdd70a.camel@paravelsystems.com> <1556975715.1931.80.camel@de.loewenfelsen.net> <899866d2f1f04da2b3c25e6e11b3b04e@learnconsult.com> Message-ID: <1557133368.1931.117.camel@de.loewenfelsen.net> 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 Im Auftrag von Philipp Schafft > Gesendet: Samstag, 4. Mai 2019 15:15 > An: fredg at paravelsystems.com; Icecast streaming server user discussions > 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: From fredg at paravelsystems.com Mon May 6 18:54:04 2019 From: fredg at paravelsystems.com (Fred Gleason) Date: Mon, 06 May 2019 14:54:04 -0400 Subject: [Icecast] Source client with HTTP PUT In-Reply-To: <1556989535.1931.86.camel@de.loewenfelsen.net> References: <6ed9be46123d4afb97f768906172c95c@learnconsult.com> <355396120cb7e40feeea0447d047e86a07fdd70a.camel@paravelsystems.com> <1556975715.1931.80.camel@de.loewenfelsen.net> <25B4DD39-8049-4C87-BF65-BD435CD4F166@paravelsystems.com> <1556989535.1931.86.camel@de.loewenfelsen.net> Message-ID: <66587a4a011d74ed0335046f94a98b64f451009e.camel@paravelsystems.com> On Sat, 2019-05-04 at 17:05 +0000, Philipp Schafft wrote: > Which exact open tickets do you refer to with "certain bits"? Would > be > happy to look into them with you. Also feel free to offer some > sponsoring to implement them. AAC+ support for starters. It was lack of this specific feature that compelled me to roll my own [Ice|Shout]Cast client support. > Considering your signature it looks like > you're in the position to do so and therefore not only get the "bits" > you need implemented but also help others this way. > Looking forward to your mail regarding this! Historically, there appears to have been significant reluctance on the part of the libshout maintainers to adopt this feature. See, for example: http://lists.xiph.org/pipermail/icecast-dev/2013-June/002202.html However, if the maintainers are now willing to accept a PR that adds AAC+ support, I would be glad to submit such. Cheers! |---------------------------------------------------------------------| | Frederick F. Gleason, Jr. | Chief Developer | | | Paravel Systems | |---------------------------------------------------------------------| | A room without books is like a body without a soul. | | | | -- Cicero | |---------------------------------------------------------------------| From shillos5 at gmail.com Tue May 7 06:01:55 2019 From: shillos5 at gmail.com (Nicholas Kyriakides) Date: Tue, 7 May 2019 09:01:55 +0300 Subject: [Icecast] Getting listed on the directory Message-ID: Hi! Just needed to know on how to get listed on the Icecast directory. Although my centova cast in settings advanced shows the correct url http://dir.xiph.org/cgi-bin/yp-cgi I still can't see my radio listed. What I'm I doing wrong? Here is my server http://64.71.79.181:4272/ *Thanks in advance! * [image: --] Nicholas Kyriakides [image: https://]about.me/shillos -------------- next part -------------- An HTML attachment was scrubbed... URL: From phschafft at de.loewenfelsen.net Tue May 7 07:58:12 2019 From: phschafft at de.loewenfelsen.net (Philipp Schafft) Date: Tue, 07 May 2019 07:58:12 +0000 Subject: [Icecast] Source client with HTTP PUT In-Reply-To: <66587a4a011d74ed0335046f94a98b64f451009e.camel@paravelsystems.com> References: <6ed9be46123d4afb97f768906172c95c@learnconsult.com> <355396120cb7e40feeea0447d047e86a07fdd70a.camel@paravelsystems.com> <1556975715.1931.80.camel@de.loewenfelsen.net> <25B4DD39-8049-4C87-BF65-BD435CD4F166@paravelsystems.com> <1556989535.1931.86.camel@de.loewenfelsen.net> <66587a4a011d74ed0335046f94a98b64f451009e.camel@paravelsystems.com> Message-ID: <1557215892.1931.133.camel@de.loewenfelsen.net> Good morning, On Mon, 2019-05-06 at 14:54 -0400, Fred Gleason wrote: > On Sat, 2019-05-04 at 17:05 +0000, Philipp Schafft wrote: > > Which exact open tickets do you refer to with "certain bits"? Would > > be > > happy to look into them with you. Also feel free to offer some > > sponsoring to implement them. > > AAC+ support for starters. It was lack of this specific feature that > compelled me to roll my own [Ice|Shout]Cast client support. It's true there is no AAC+ support in mainstream libshout. However there are several patches and patched versions around. Both "free software" and as part of not so free projects. In any case this is a top level feature of libshout and not related to the transport. So you would still use a HTTP library if you would want to implement something totally new. > > Considering your signature it looks like > > you're in the position to do so and therefore not only get the "bits" > > you need implemented but also help others this way. > > Looking forward to your mail regarding this! > > Historically, there appears to have been significant reluctance on the > part of the libshout maintainers to adopt this feature. See, for > example: > > http://lists.xiph.org/pipermail/icecast-dev/2013-June/002202.html > > However, if the maintainers are now willing to accept a PR that adds > AAC+ support, I would be glad to submit such. It's very simple: AAC* is a legal mess, not a very good codec, hardly adds any value to radio streaming, and far off the mission of the project. There is simply no reason why someone should work on it in his free time. As simple as that. We focus on making high quality products with modern technology that looking into the future. Not into the past. So, my question is still: What is the ticket number? Please also note that unsolicited pull requests are likely rejected just because they often miss some important point that could have been known when talking to us first. What comes to mind in this case is e.g. the migration of libshout to use libigloo. Looking forward to read the ticket, with best regards, -- 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: From Juergen.Bund at learnconsult.com Tue May 7 11:49:45 2019 From: Juergen.Bund at learnconsult.com (=?utf-8?B?SsO8cmdlbiBCdW5k?=) Date: Tue, 7 May 2019 11:49:45 +0000 Subject: [Icecast] Source client with HTTP PUT In-Reply-To: <1557133368.1931.117.camel@de.loewenfelsen.net> References: <6ed9be46123d4afb97f768906172c95c@learnconsult.com> <355396120cb7e40feeea0447d047e86a07fdd70a.camel@paravelsystems.com> <1556975715.1931.80.camel@de.loewenfelsen.net> <899866d2f1f04da2b3c25e6e11b3b04e@learnconsult.com> <1557133368.1931.117.camel@de.loewenfelsen.net> Message-ID: 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 Im Auftrag von Philipp Schafft Gesendet: Montag, 6. Mai 2019 11:03 An: Icecast streaming server user discussions 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 Im Auftrag von Philipp Schafft > Gesendet: Samstag, 4. Mai 2019 15:15 > An: fredg at paravelsystems.com; Icecast streaming server user > discussions > 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 From mvandop at xs4all.nl Tue May 7 11:59:05 2019 From: mvandop at xs4all.nl (Michel van Dop) Date: Tue, 07 May 2019 13:59:05 +0200 Subject: [Icecast] players who cannot handle switching to a fallback mount point? In-Reply-To: <076c38f12a5456292e2b1b3ae7cbc812@xs4all.nl> References: <6dc5e85036456ce402af762fc295ecba@xs4all.nl> <20190412091334.GB21197@nowster.org.uk> <076c38f12a5456292e2b1b3ae7cbc812@xs4all.nl> Message-ID: <971210e53d1e39e947af6a9b08a52c86@xs4all.nl> Hi, We have setup a test stream using Icecast 2.4.4 and the same icecast config. We use a simple HTML5 player for testing: See icecast config below. We kick the /aac mountpoint and the html5 player stop playing. When we listen to a Winamp player and we kick the /aac it works fine we hear the /fk-aac. [2019-05-07 13:33:25] INFO admin/admin_handle_request Received admin command killsource.xsl on mount "/aac" [2019-05-07 13:33:25] INFO source/source_shutdown Source from x.x.x.x at "/aac" exiting [2019-05-07 13:33:25] INFO source/source_move_clients passing 1 listeners to "/fk-aac" [2019-05-07 13:33:25] INFO fserve/fserve_client_create checking for file /style.css (/etc/icecast2/web/style.css) [2019-05-07 13:33:25] INFO source/source_main listener count on /fk-aac now 1 [2019-05-07 13:33:29] INFO connection/_handle_source_request Source logging in at mountpoint "/aac" from x.x.x.x [2019-05-07 13:33:29] WARN format/format_get_type Unsupported or legacy stream type: "audio/aacp". Falling back to generic minimal handler for best effort. Have anyone a ideas what is the problem of the html5 player and Icecast config? Both mountpoints are the same bitrate. Same encoder and settings. Best regards, Michel > Hi Paul, > > Thanks for the quick response! > We use the same type of encoder (Sam Cast) both live for both > mountpoints on 96 Kb Joint Stereo. > > it is difficult to see if it is exactly the same. Is there a player > that show exactly this? I will check this. > > We have use the limit-rate in our config. Thats work better for go to > play the last fallback-mount file (i test this). > > See here our part of the config: > > > /aac > xxxxxxx > 1 > 0 > 96k > /fk-aac > 1 > 1500 > > > > /fk-aac > xxxxxxx > 1 > 1 > 96k > /aac.aac > 1 > 1500 > > > Best regards, > > Michel > > Paul Martin schreef op 2019-04-12 11:13: > > On Fri, Apr 12, 2019 at 09:30:11AM +0200, Michel van Dop wrote: > > We use Icecast version 2.4.4 and use mountpoint /main and include use > fallback-mount. > When the /main is offline 92% of the listeners go to fallback-mount and > 8% disconnect. > > The format is 96k AAC and we have 8 mountpoint and 8 fallback-mount > points include extra fallback files AAC. > Are the fallback streams exactly the same characteristics as the > streams they're associated with? > > Are they live or are they files served by Icecast? (File serving is > not bitrate constrained in mainstream Icecast, so will completely fill > listeners' players' buffers, possibily requiring a reconnect to get > back to live if the buffer is large.) -- From thomas at ruecker.fi Tue May 7 14:45:21 2019 From: thomas at ruecker.fi (Thomas B. Ruecker) Date: Tue, 7 May 2019 14:45:21 +0000 Subject: [Icecast] Getting listed on the directory In-Reply-To: References: Message-ID: <4d3172cd-d113-168d-0f1a-311fddd64a88@ruecker.fi> Hi, On 5/7/19 6:01 AM, Nicholas Kyriakides wrote: > Hi! Just needed to know on how to get listed on the Icecast directory. > Although my centova cast in settings advanced shows the correct url > http://dir.xiph.org/cgi-bin/yp-cgi I still can't see my radio listed. > What I'm I doing wrong? Here is my server http://64.71.79.181:4272/ Please refer to https://icecast.org/docs/icecast-trunk/yp/ (at this time documentation is not in a release yet) There are detailed instructions about setting up and troubleshooting directory listings. Cheers, Thomas From pm at nowster.me.uk Thu May 9 17:14:31 2019 From: pm at nowster.me.uk (Paul Martin) Date: Thu, 9 May 2019 18:14:31 +0100 Subject: [Icecast] players who cannot handle switching to a fallback mount point? In-Reply-To: <971210e53d1e39e947af6a9b08a52c86@xs4all.nl> References: <6dc5e85036456ce402af762fc295ecba@xs4all.nl> <20190412091334.GB21197@nowster.org.uk> <076c38f12a5456292e2b1b3ae7cbc812@xs4all.nl> <971210e53d1e39e947af6a9b08a52c86@xs4all.nl> Message-ID: <20190509171431.GB18695@nowster.org.uk> On Tue, May 07, 2019 at 01:59:05PM +0200, Michel van Dop wrote: > [2019-05-07 13:33:29] WARN format/format_get_type Unsupported or legacy > stream type: "audio/aacp". Falling back to generic minimal handler for best > effort. Is one source AAC-LC (standard AAC) and the other HE-AAC v2 (AAC+)? There are three variants of AAC: AAC-LC HE-AAC (= AAC-LC with SBR) HE-AAC v2 (= HE-AAC with parametric stereo), aka AAC+ Check your encoders. You also have to match all other settings, eg. sample rate. -- Paul Martin From mvandop at xs4all.nl Thu May 9 19:29:28 2019 From: mvandop at xs4all.nl (Michel van Dop) Date: Thu, 9 May 2019 21:29:28 +0200 Subject: [Icecast] players who cannot handle switching to a fallback mount point? In-Reply-To: <20190509171431.GB18695@nowster.org.uk> References: <6dc5e85036456ce402af762fc295ecba@xs4all.nl> <20190412091334.GB21197@nowster.org.uk> <076c38f12a5456292e2b1b3ae7cbc812@xs4all.nl> <971210e53d1e39e947af6a9b08a52c86@xs4all.nl> <20190509171431.GB18695@nowster.org.uk> Message-ID: <05994B44-0DCA-454D-8FA9-9801DF09E808@xs4all.nl> Hi Paul, Thank you for the information. I already try a player to discover the stream type of both streams if the are the same. But i can not find out, so i must check the encoders by my self. First I wil try one pc encoder to stream to both mountpoint so i am sure the encoder are the same aac type en bitrate. I will keep you informed of the result Best regards, Michel > Op 9 mei 2019 om 19:14 heeft Paul Martin het volgende geschreven: > >> On Tue, May 07, 2019 at 01:59:05PM +0200, Michel van Dop wrote: >> >> [2019-05-07 13:33:29] WARN format/format_get_type Unsupported or legacy >> stream type: "audio/aacp". Falling back to generic minimal handler for best >> effort. > > Is one source AAC-LC (standard AAC) and the other HE-AAC v2 (AAC+)? > > There are three variants of AAC: > > AAC-LC > HE-AAC (= AAC-LC with SBR) > HE-AAC v2 (= HE-AAC with parametric stereo), aka AAC+ > > Check your encoders. > > You also have to match all other settings, eg. sample rate. > > -- > Paul Martin > _______________________________________________ > Icecast mailing list > Icecast at xiph.org > http://lists.xiph.org/mailman/listinfo/icecast From pmoynihan at fsu.edu Fri May 10 03:11:15 2019 From: pmoynihan at fsu.edu (Patricia Moynihan) Date: Fri, 10 May 2019 03:11:15 +0000 Subject: [Icecast] 8000 security risk? Message-ID: Hi all, Are there any serious security risks for leaving port 8000 open to public use on icecast? I had wanted to limit to 8443 but it seems some radio devices cannot support this protocol. Thanks, Patricia Moynihan Director of Digital pmoynihan at fsu.edu 850-645-6067 850-645-7200 WFSU Public Media 1600 Red Barber Plaza Tallahassee, FL 32310 wfsu.org [WFSU Public Media] -------------- next part -------------- An HTML attachment was scrubbed... URL: From gavin at stephens.net.nz Fri May 10 05:14:44 2019 From: gavin at stephens.net.nz (Gavin Stephens) Date: Fri, 10 May 2019 17:14:44 +1200 Subject: [Icecast] 8000 security risk? In-Reply-To: References: Message-ID: I have a server running on 8000 and I know of some running multiple stations all through port 80 (which I would think was worse). Never heard of any major problems and my logs usually look okay. Good practice is to check the logs now and then and block appropriate IP's causing problems if needed. I wouldn't just set and forget a server regardless of what it was. But background scanners and the likes are pretty tiny amounts of traffic. If someone uses a port scanner to see what's open on a host it doesn't matter what port it's on. Cheers, Gavin. On 10/05/2019 3:11 PM, Patricia Moynihan wrote: > Hi all, > > Are there any serious security risks for leaving port 8000 open to > public use on icecast? I had wanted to limit to 8443 but it seems some > radio devices cannot support this protocol. > > Thanks, > > Patricia Moynihan > Director of Digital > > pmoynihan at fsu.edu > 850-645-6067 > 850-645-7200 > > WFSU Public Media > 1600 Red Barber Plaza > Tallahassee, FL 32310 > wfsu.org > > WFSU Public Media > > _______________________________________________ > Icecast mailing list > Icecast at xiph.org > http://lists.xiph.org/mailman/listinfo/icecast -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas at ruecker.fi Fri May 10 08:04:02 2019 From: thomas at ruecker.fi (=?UTF-8?Q?Thomas_B=2e_R=c3=bccker?=) Date: Fri, 10 May 2019 08:04:02 +0000 Subject: [Icecast] 8000 security risk? In-Reply-To: References: Message-ID: <51e38914-a70b-0789-41c7-f3ac5b77ae55@ruecker.fi> Hi, On 5/10/19 3:11 AM, Patricia Moynihan wrote: > Are there any serious security risks for leaving port 8000 open to > public use on icecast? I had wanted to limit to 8443 but it seems some > radio devices cannot support this protocol. The port number doesn't matter. I guess in your case you mean HTTP vs HTTPS. The proper and terse answer is: It doesn't matter if you use HTTP or HTTPS as long as you have a secure configuration including managed and strong (not bruteforceable) passwords AND you keep your Icecast server up to date wrt security updates (currently Version 2.4.4). From my anecdotal knowledge gained over 18 years of involvement in Icecast, if people would follow the above two, then 99,9% of incidents would not happen. The longer answer is that it will also depend on your 'threat model' and how you rate and address things that you consider 'risks' in this frame of reference. There is no one-fits-all or immediate answer that fits into this email. Hope this helps, Thomas From mikel at 20comunicacion.com Fri May 10 09:00:02 2019 From: mikel at 20comunicacion.com (=?UTF-8?Q?Mikel_Sanz_=7C_20_Comunicaci=C3=B3n?=) Date: Fri, 10 May 2019 11:00:02 +0200 Subject: [Icecast] players who cannot handle switching to a fallback mount point? In-Reply-To: <05994B44-0DCA-454D-8FA9-9801DF09E808@xs4all.nl> References: <6dc5e85036456ce402af762fc295ecba@xs4all.nl> <20190412091334.GB21197@nowster.org.uk> <076c38f12a5456292e2b1b3ae7cbc812@xs4all.nl> <971210e53d1e39e947af6a9b08a52c86@xs4all.nl> <20190509171431.GB18695@nowster.org.uk> <05994B44-0DCA-454D-8FA9-9801DF09E808@xs4all.nl> Message-ID: Hello. I have same problem, and I think that it's because AAC+ uses VBR and when it's changes, is not the same bitrate, because varies... El jue., 9 may. 2019 a las 21:29, Michel van Dop () escribi?: > Hi Paul, > > Thank you for the information. I already try a player to discover the > stream type of both streams if the are the same. > But i can not find out, so i must check the encoders by my self. > > First I wil try one pc encoder to stream to both mountpoint so i am sure > the encoder are the same aac type en bitrate. > > I will keep you informed of the result > > Best regards, > Michel > > > > > Op 9 mei 2019 om 19:14 heeft Paul Martin het > volgende geschreven: > > > >> On Tue, May 07, 2019 at 01:59:05PM +0200, Michel van Dop wrote: > >> > >> [2019-05-07 13:33:29] WARN format/format_get_type Unsupported or legacy > >> stream type: "audio/aacp". Falling back to generic minimal handler for > best > >> effort. > > > > Is one source AAC-LC (standard AAC) and the other HE-AAC v2 (AAC+)? > > > > There are three variants of AAC: > > > > AAC-LC > > HE-AAC (= AAC-LC with SBR) > > HE-AAC v2 (= HE-AAC with parametric stereo), aka AAC+ > > > > Check your encoders. > > > > You also have to match all other settings, eg. sample rate. > > > > -- > > Paul Martin > > _______________________________________________ > > Icecast mailing list > > Icecast at xiph.org > > http://lists.xiph.org/mailman/listinfo/icecast > > _______________________________________________ > Icecast mailing list > Icecast at xiph.org > http://lists.xiph.org/mailman/listinfo/icecast > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mvandop at xs4all.nl Fri May 10 10:18:05 2019 From: mvandop at xs4all.nl (Michel van Dop) Date: Fri, 10 May 2019 12:18:05 +0200 Subject: [Icecast] players who cannot handle switching to a fallback mount point? In-Reply-To: References: <6dc5e85036456ce402af762fc295ecba@xs4all.nl> <20190412091334.GB21197@nowster.org.uk> <076c38f12a5456292e2b1b3ae7cbc812@xs4all.nl> <971210e53d1e39e947af6a9b08a52c86@xs4all.nl> <20190509171431.GB18695@nowster.org.uk> <05994B44-0DCA-454D-8FA9-9801DF09E808@xs4all.nl> Message-ID: <2dece6ec7d4bcd770ed692282d18f4a0@xs4all.nl> Hi, I am now sure that the encoders for both mountpoint are exact the same. aacPlus 96kb/s 44.1kHZ stereo CODEC aacPlus 96kb/s (12,0 Kbytes/s) Samplerate 44.1 kHz Stereo I use 1 PC software -> Sam Cast.. we use the same settings for both mountpoints. I found foobar2000 player you can see the stream details (both mountpoint are the same): Sample rate 44100 Hz Channels 2 Codec AAC Codec Profile AAC SBR Enocoding lossy I test a other encoder Altacast and we do the same AAC.. Same problem. We using Chrome 74.0.3729.131 (Offici?le build) (64-bits) on Win7. When i test the same html5 player on Firefox it works fine. We use Firefox 66.0.4 For Chrome HTML player problem we see in Icecast (error log): [2019-05-10 11:50:40] WARN format/format_get_type Unsupported or legacy stream type: "audio/aacp". Falling back to generic minimal handler for best effort. We use the same test on mp3 on 96k and that works fine for Chrome and Firefox. Look like html5 player on chrome and Icecast using AAC do not work fine. (i am not sure but i do this test on december 2018 and it works fine) Look like a update of Chrome have change something. I already try some other things to use http (not https) or ip address in html5 player code. Other AAC setting for both mountpoints and use html5 player on diffrent PC and chrome. But it not a specific problem on one PC. I hope there is solution, many listener using the Chrome browser (its my default browser) Best regards, Michel Mikel Sanz | 20 Comunicaci?n schreef op 2019-05-10 11:00: > Hello. I have same problem, and I think that it's because AAC+ uses VBR and when it's changes, is not the same bitrate, because varies... > > El jue., 9 may. 2019 a las 21:29, Michel van Dop () escribi?: > >> Hi Paul, >> >> Thank you for the information. I already try a player to discover the stream type of both streams if the are the same. >> But i can not find out, so i must check the encoders by my self. >> >> First I wil try one pc encoder to stream to both mountpoint so i am sure the encoder are the same aac type en bitrate. >> >> I will keep you informed of the result >> >> Best regards, >> Michel >> >>> Op 9 mei 2019 om 19:14 heeft Paul Martin het volgende geschreven: >>> >>>> On Tue, May 07, 2019 at 01:59:05PM +0200, Michel van Dop wrote: >>>> >>>> [2019-05-07 13:33:29] WARN format/format_get_type Unsupported or legacy >>>> stream type: "audio/aacp". Falling back to generic minimal handler for best >>>> effort. >>> >>> Is one source AAC-LC (standard AAC) and the other HE-AAC v2 (AAC+)? >>> >>> There are three variants of AAC: >>> >>> AAC-LC >>> HE-AAC (= AAC-LC with SBR) >>> HE-AAC v2 (= HE-AAC with parametric stereo), aka AAC+ >>> >>> Check your encoders. >>> >>> You also have to match all other settings, eg. sample rate. >>> >>> -- >>> Paul Martin >>> _______________________________________________ >>> Icecast mailing list >>> Icecast at xiph.org >>> http://lists.xiph.org/mailman/listinfo/icecast >> >> _______________________________________________ >> Icecast mailing list >> Icecast at xiph.org >> http://lists.xiph.org/mailman/listinfo/icecast > > _______________________________________________ > Icecast mailing list > Icecast at xiph.org > http://lists.xiph.org/mailman/listinfo/icecast -- -------------- next part -------------- An HTML attachment was scrubbed... URL: From daddyo323 at gmail.com Fri May 10 15:35:39 2019 From: daddyo323 at gmail.com (Rick Keniuk) Date: Fri, 10 May 2019 10:35:39 -0500 Subject: [Icecast] OPUS Metadata in IceCast v2.4.4 Message-ID: <8300FB36-E7AA-449C-9A32-AC0261EC2370@gmail.com> Hello all, I may have asked this previously, but I am still on a mission to get metadata on my OPUS streams (FLAC if possible also). I am using IceCast v2.4.4 (on Windows 8.1) and RadioCaster as an encoder for OPUS streams and I know that sending the streams directly to IceCast will not pass metadata for song title and artist. I have tried using a built-in server in RadioCaster and I can see the metadata on that stream. So I thought I could simply relay that server via IceCast and the metadata would remain intact but it appears that is not the case. Is this possible or must I wait for a further update to IceCast or I?ve mis-configured IceCast? Or?. Is the format of the metadata being sourced in RadioCaster incorrect? Thanks, Rick From pmoynihan at fsu.edu Fri May 10 14:48:38 2019 From: pmoynihan at fsu.edu (Patricia Moynihan) Date: Fri, 10 May 2019 14:48:38 +0000 Subject: [Icecast] 8000 security risk? In-Reply-To: <51e38914-a70b-0789-41c7-f3ac5b77ae55@ruecker.fi> References: <51e38914-a70b-0789-41c7-f3ac5b77ae55@ruecker.fi> Message-ID: Yes I meant HTTPS over HTTP, which yes, I?m differentiating by those port numbers. Thanks for clarifying! We have been streaming HTTP for a long time, but I am at a university and there is a lot of emphasis on security. I was never really sure what the certificate did for us in this case?but was attempting to comply! Over the years we have had a small handful of IPs trying to maliciously access our Icecast server over port 8000. I guess the less of that I have to deal with, the better. But if there are streaming aggregators out there who can?t use the HTTPS over the HTTP, then it may be better to deal with the inconvenience once in a while. Thanks for your help. Patricia Moynihan Director of Digital pmoynihan at fsu.edu 850-645-6067 850-645-7200 On May 10, 2019, at 4:04 AM, Thomas B. R?cker > wrote: Hi, On 5/10/19 3:11 AM, Patricia Moynihan wrote: Are there any serious security risks for leaving port 8000 open to public use on icecast? I had wanted to limit to 8443 but it seems some radio devices cannot support this protocol. The port number doesn't matter. I guess in your case you mean HTTP vs HTTPS. The proper and terse answer is: It doesn't matter if you use HTTP or HTTPS as long as you have a secure configuration including managed and strong (not bruteforceable) passwords AND you keep your Icecast server up to date wrt security updates (currently Version 2.4.4). From my anecdotal knowledge gained over 18 years of involvement in Icecast, if people would follow the above two, then 99,9% of incidents would not happen. The longer answer is that it will also depend on your 'threat model' and how you rate and address things that you consider 'risks' in this frame of reference. There is no one-fits-all or immediate answer that fits into this email. Hope this helps, Thomas _______________________________________________ Icecast mailing list Icecast at xiph.org https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.xiph.org_mailman_listinfo_icecast&d=DwIGaQ&c=HPMtquzZjKY31rtkyGRFnQ&r=il3mbeSthlxEJd_b1NtmGe2biSOKp7VwqcXPdl2MdRc&m=X3zh6M4zoa3mkJwmMiZz1f54FZWn_anDeugwt91Y9Uw&s=PddWQ35fNEeUXAPZc9z2OIcjlDRy3lSx_2XgODSskyM&e= -------------- next part -------------- An HTML attachment was scrubbed... URL: From pm at nowster.me.uk Fri May 10 16:59:29 2019 From: pm at nowster.me.uk (Paul Martin) Date: Fri, 10 May 2019 17:59:29 +0100 Subject: [Icecast] OPUS Metadata in IceCast v2.4.4 In-Reply-To: <8300FB36-E7AA-449C-9A32-AC0261EC2370@gmail.com> References: <8300FB36-E7AA-449C-9A32-AC0261EC2370@gmail.com> Message-ID: <20190510165929.GA21970@nowster.org.uk> On Fri, May 10, 2019 at 10:35:39AM -0500, Rick Keniuk wrote: > I may have asked this previously, but I am still on a mission to get > metadata on my OPUS streams (FLAC if possible also). https://tools.ietf.org/html/rfc7845.html (Section 5.2) ...which is similar to Ogg Vorbis comments. FLAC is a bit different, however. -- Paul Martin From thomas at ruecker.fi Fri May 10 17:29:30 2019 From: thomas at ruecker.fi (=?UTF-8?Q?Thomas_B=2e_R=c3=bccker?=) Date: Fri, 10 May 2019 17:29:30 +0000 Subject: [Icecast] 8000 security risk? In-Reply-To: References: <51e38914-a70b-0789-41c7-f3ac5b77ae55@ruecker.fi> Message-ID: Hi Patricia, On 5/10/19 2:48 PM, Patricia Moynihan wrote: > Yes I meant HTTPS over HTTP, which yes, I?m differentiating by those > port numbers. Thanks for clarifying! We have been streaming HTTP for a > long time, but I am at a university and there is a lot of emphasis on > security. I was never really sure what the certificate did for us in > this case?but was attempting to comply! For you there is no direct security benefit. It does 'comply' with 'tickbox-security' though and gets you the 'security people' off your neck. Achievement unlocked! side note: you don't seem to be running any service on port 80 nor 443. Consider adding those to your Icecast configuration to increase your client compatibility, especially in terms of Browsers and "corporate networks that block everything that's not on port 80 or 443 for 'security' reasons". If your server runs Debian or Ubuntu, this will be a bit more involved, but still fairly easy (there are descriptions found e.g. in the list archive) > Over the years we have had a small handful of IPs trying to > maliciously access our Icecast server over port 8000. I guess the less > of that I have to deal with, the better. But if there are streaming > aggregators out there who can?t use the HTTPS over the HTTP, then it > may be better to deal with the inconvenience once in a while. I'm sorry, but as an information security professional I MUST disillusion you on this. Adding HTTPS does absolutely ZERO for the security of your Icecast server, *especially* in terms of "IPs trying to maliciously access" it. This ties into the "threat model" I mentioned. (The only exception would be legitimate source client connections from the Internet and I strongly suspect that not to be the case here) The only thing that you could call a security improvement is on the client side. It is no longer trivial to intercept data sent by the server to and from the client, including which resource (stream) is being accessed. Security is a complex topic and there are many areas and details and things tend to turn upside down depending on what your priorities (threat model) are. TBR > Thanks for your help.? > > Patricia Moynihan > Director of Digital > > pmoynihan at fsu.edu > 850-645-6067 > 850-645-7200 > >> On May 10, 2019, at 4:04 AM, Thomas B. R?cker > > wrote: >> >> Hi, >> >> On 5/10/19 3:11 AM, Patricia Moynihan wrote: >>> Are there any serious security risks for leaving port 8000 open to >>> public use on icecast? I had wanted to limit to 8443 but it seems some >>> radio devices cannot support this protocol. >> >> >> The port number doesn't matter. I guess in your case you mean HTTP vs >> HTTPS. >> >> The proper and terse answer is: >> >> It doesn't matter if you use HTTP or HTTPS as long as you have a secure >> configuration including managed and strong (not bruteforceable) >> passwords AND you keep your Icecast server up to date wrt security >> updates (currently Version 2.4.4). >> >> From my anecdotal knowledge gained over 18 years of involvement in >> Icecast, if people would follow the above two, then 99,9% of incidents >> would not happen. >> >> The longer answer is that it will also depend on your 'threat model' and >> how you rate and address things that you consider 'risks' in this frame >> of reference. There is no one-fits-all or immediate answer that fits >> into this email. >> >> >> Hope this helps, >> >> Thomas >> >> >> _______________________________________________ >> Icecast mailing list >> Icecast at xiph.org >> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.xiph.org_mailman_listinfo_icecast&d=DwIGaQ&c=HPMtquzZjKY31rtkyGRFnQ&r=il3mbeSthlxEJd_b1NtmGe2biSOKp7VwqcXPdl2MdRc&m=X3zh6M4zoa3mkJwmMiZz1f54FZWn_anDeugwt91Y9Uw&s=PddWQ35fNEeUXAPZc9z2OIcjlDRy3lSx_2XgODSskyM&e= > > > _______________________________________________ > Icecast mailing list > Icecast at xiph.org > http://lists.xiph.org/mailman/listinfo/icecast From pmoynihan at fsu.edu Fri May 10 21:04:07 2019 From: pmoynihan at fsu.edu (Patricia Moynihan) Date: Fri, 10 May 2019 21:04:07 +0000 Subject: [Icecast] 8000 security risk? In-Reply-To: References: <51e38914-a70b-0789-41c7-f3ac5b77ae55@ruecker.fi> Message-ID: TBR, Thanks for the clarification. Where can I read more about security - related to http(s), online streaming and websites? Where do I start? In the past I?ve seen the anything but 80 and 443 blocking thing, especially in government offices. Haven?t experienced those complaints in while, but it is a good suggestion! I assume I can add the ports in the icecast.xml, open them in the various places (computer/dns), and be ok? No need to answer, I?ll look it up! I?m running on Centos 7. Patricia Moynihan Director of Digital pmoynihan at fsu.edu 850-645-6067 850-645-7200 On May 10, 2019, at 1:29 PM, Thomas B. R?cker > wrote: Hi Patricia, On 5/10/19 2:48 PM, Patricia Moynihan wrote: Yes I meant HTTPS over HTTP, which yes, I?m differentiating by those port numbers. Thanks for clarifying! We have been streaming HTTP for a long time, but I am at a university and there is a lot of emphasis on security. I was never really sure what the certificate did for us in this case?but was attempting to comply! For you there is no direct security benefit. It does 'comply' with 'tickbox-security' though and gets you the 'security people' off your neck. Achievement unlocked! side note: you don't seem to be running any service on port 80 nor 443. Consider adding those to your Icecast configuration to increase your client compatibility, especially in terms of Browsers and "corporate networks that block everything that's not on port 80 or 443 for 'security' reasons". If your server runs Debian or Ubuntu, this will be a bit more involved, but still fairly easy (there are descriptions found e.g. in the list archive) Over the years we have had a small handful of IPs trying to maliciously access our Icecast server over port 8000. I guess the less of that I have to deal with, the better. But if there are streaming aggregators out there who can?t use the HTTPS over the HTTP, then it may be better to deal with the inconvenience once in a while. I'm sorry, but as an information security professional I MUST disillusion you on this. Adding HTTPS does absolutely ZERO for the security of your Icecast server, *especially* in terms of "IPs trying to maliciously access" it. This ties into the "threat model" I mentioned. (The only exception would be legitimate source client connections from the Internet and I strongly suspect that not to be the case here) The only thing that you could call a security improvement is on the client side. It is no longer trivial to intercept data sent by the server to and from the client, including which resource (stream) is being accessed. Security is a complex topic and there are many areas and details and things tend to turn upside down depending on what your priorities (threat model) are. TBR Thanks for your help. Patricia Moynihan Director of Digital pmoynihan at fsu.edu 850-645-6067 850-645-7200 On May 10, 2019, at 4:04 AM, Thomas B. R?cker > wrote: Hi, On 5/10/19 3:11 AM, Patricia Moynihan wrote: Are there any serious security risks for leaving port 8000 open to public use on icecast? I had wanted to limit to 8443 but it seems some radio devices cannot support this protocol. The port number doesn't matter. I guess in your case you mean HTTP vs HTTPS. The proper and terse answer is: It doesn't matter if you use HTTP or HTTPS as long as you have a secure configuration including managed and strong (not bruteforceable) passwords AND you keep your Icecast server up to date wrt security updates (currently Version 2.4.4). From my anecdotal knowledge gained over 18 years of involvement in Icecast, if people would follow the above two, then 99,9% of incidents would not happen. The longer answer is that it will also depend on your 'threat model' and how you rate and address things that you consider 'risks' in this frame of reference. There is no one-fits-all or immediate answer that fits into this email. Hope this helps, Thomas _______________________________________________ Icecast mailing list Icecast at xiph.org https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.xiph.org_mailman_listinfo_icecast&d=DwIGaQ&c=HPMtquzZjKY31rtkyGRFnQ&r=il3mbeSthlxEJd_b1NtmGe2biSOKp7VwqcXPdl2MdRc&m=X3zh6M4zoa3mkJwmMiZz1f54FZWn_anDeugwt91Y9Uw&s=PddWQ35fNEeUXAPZc9z2OIcjlDRy3lSx_2XgODSskyM&e= _______________________________________________ Icecast mailing list Icecast at xiph.org https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.xiph.org_mailman_listinfo_icecast&d=DwIGaQ&c=HPMtquzZjKY31rtkyGRFnQ&r=il3mbeSthlxEJd_b1NtmGe2biSOKp7VwqcXPdl2MdRc&m=OD-PDzRTQcORzIDkfdfm9ZArtiOmESX8sYcnDnJyJuw&s=-vGj3IVe8I7JCpXxfhkMRgsyItHncb8nWnWA2Fz5p1U&e= _______________________________________________ Icecast mailing list Icecast at xiph.org https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.xiph.org_mailman_listinfo_icecast&d=DwIGaQ&c=HPMtquzZjKY31rtkyGRFnQ&r=il3mbeSthlxEJd_b1NtmGe2biSOKp7VwqcXPdl2MdRc&m=OD-PDzRTQcORzIDkfdfm9ZArtiOmESX8sYcnDnJyJuw&s=-vGj3IVe8I7JCpXxfhkMRgsyItHncb8nWnWA2Fz5p1U&e= -------------- next part -------------- An HTML attachment was scrubbed... URL: From phschafft at de.loewenfelsen.net Mon May 13 08:45:40 2019 From: phschafft at de.loewenfelsen.net (Philipp Schafft) Date: Mon, 13 May 2019 08:45:40 +0000 Subject: [Icecast] OPUS Metadata in IceCast v2.4.4 In-Reply-To: <20190510165929.GA21970@nowster.org.uk> References: <8300FB36-E7AA-449C-9A32-AC0261EC2370@gmail.com> <20190510165929.GA21970@nowster.org.uk> Message-ID: <1557737140.2625.22.camel@de.loewenfelsen.net> Good morning, On Fri, 2019-05-10 at 17:59 +0100, Paul Martin wrote: > On Fri, May 10, 2019 at 10:35:39AM -0500, Rick Keniuk wrote: > > > I may have asked this previously, but I am still on a mission to get > > metadata on my OPUS streams (FLAC if possible also). > > https://tools.ietf.org/html/rfc7845.html (Section 5.2) > > ...which is similar to Ogg Vorbis comments. Support for metadata in Opus is a feature of Icecast 2.5.x. It has first been included in v2.5.0-beta.2. But please note that this is only about displaying. All versions of Icecast that actually support Opus at all will pass metadata correctly to the listeners. Similar situation for FLAC. Icecast does pass the metadata to the listener. It just doesn't display them on it's status page. There is currently no patch for FLAC. If needed the best way to get it in is to open a ticket for it (if there is none yet) and post the ticket ID here on this thread. Tickets can be opened at: https://gitlab.xiph.org/xiph/icecast-server/issues With best regards, -- 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: From phschafft at de.loewenfelsen.net Mon May 13 08:53:40 2019 From: phschafft at de.loewenfelsen.net (Philipp Schafft) Date: Mon, 13 May 2019 08:53:40 +0000 Subject: [Icecast] Source client with HTTP PUT In-Reply-To: References: <6ed9be46123d4afb97f768906172c95c@learnconsult.com> <355396120cb7e40feeea0447d047e86a07fdd70a.camel@paravelsystems.com> <1556975715.1931.80.camel@de.loewenfelsen.net> <899866d2f1f04da2b3c25e6e11b3b04e@learnconsult.com> <1557133368.1931.117.camel@de.loewenfelsen.net> Message-ID: <1557737620.2625.28.camel@de.loewenfelsen.net> 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 Im Auftrag von Philipp Schafft > Gesendet: Montag, 6. Mai 2019 11:03 > An: Icecast streaming server user discussions > 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 Im Auftrag von Philipp Schafft > > Gesendet: Samstag, 4. Mai 2019 15:15 > > An: fredg at paravelsystems.com; Icecast streaming server user > > discussions > > 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: From phschafft at de.loewenfelsen.net Mon May 13 09:18:04 2019 From: phschafft at de.loewenfelsen.net (Philipp Schafft) Date: Mon, 13 May 2019 09:18:04 +0000 Subject: [Icecast] Multiple connections from iPhones In-Reply-To: References: Message-ID: <1557739084.2625.31.camel@de.loewenfelsen.net> Good morning, On Thu, 2019-05-02 at 18:22 +0200, Sytze Visser wrote: > Hi David > > I have seen similar behavior and the conclusion was that icecast will > connect a client once for each connection request. The double connection is > a result of the player/browser that possibly checks if it can connect and > then establishes the actual connection. This is what we suspect as well. However this behavior is not yet unnecessary but even forbidden by the HTTP specification as HTTP is a stateless protocol. Basically clients doing this are not conforming to the HTTP specs. > If you don't have control over the source code of the player, you might > have to live with the issue. As long as you want to support products by vendors that do not care about standards you need to live with that I fear. With best regards, > On Thu, 02 May 2019, 18:01 David Gibbs, wrote: > > > A newbie question I'm afraid. > > > > I have a site that streams to only about 20 or 30 listeners using Icecast > > for Windows 2.4.4 and Altacast. > > > > The issue - I often see multiple connections started almost simultaneously > > from one IP address, usually an iphone or ipad. The device descriptions are > > identical, and I know my listeners are listening from home, so my > > assumption is that one device is opening multiple connections. > > > > If I kill one connection they often all disappear from that IP address at > > once. > > > > Is this something others see? Does anyone know why these multiple > > connections are created? -- 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: From pm at nowster.me.uk Mon May 13 16:55:06 2019 From: pm at nowster.me.uk (Paul Martin) Date: Mon, 13 May 2019 17:55:06 +0100 Subject: [Icecast] OPUS Metadata in IceCast v2.4.4 In-Reply-To: <1557737140.2625.22.camel@de.loewenfelsen.net> References: <8300FB36-E7AA-449C-9A32-AC0261EC2370@gmail.com> <20190510165929.GA21970@nowster.org.uk> <1557737140.2625.22.camel@de.loewenfelsen.net> Message-ID: <20190513165505.GA2739@thinkpad.nowster.org.uk> On Mon, May 13, 2019 at 08:45:40AM +0000, Philipp Schafft wrote: > Support for metadata in Opus is a feature of Icecast 2.5.x. It has first > been included in v2.5.0-beta.2. But please note that this is only about > displaying. I can see support for reading it from incoming Ogg/Opus streams in the git logs, but not for inserting it (eg. using the updatemetadata.xsl script). Is that what you meant by "only about displaying"? -- Paul Martin From david at gibbs.net Mon May 13 13:54:19 2019 From: david at gibbs.net (david at gibbs.net) Date: Mon, 13 May 2019 14:54:19 +0100 Subject: [Icecast] Multiple connections from iPhones In-Reply-To: <1557739084.2625.31.camel@de.loewenfelsen.net> References: <1557739084.2625.31.camel@de.loewenfelsen.net> Message-ID: <007801d50993$5dc016d0$19404470$@gibbs.net> Thank you both for your helpful comments, I shall live with it. Dave -----Original Message----- From: Icecast On Behalf Of Philipp Schafft Sent: 13 May 2019 10:18 To: Icecast streaming server user discussions Subject: Re: [Icecast] Multiple connections from iPhones Good morning, On Thu, 2019-05-02 at 18:22 +0200, Sytze Visser wrote: > Hi David > > I have seen similar behavior and the conclusion was that icecast will > connect a client once for each connection request. The double > connection is a result of the player/browser that possibly checks if > it can connect and then establishes the actual connection. This is what we suspect as well. However this behavior is not yet unnecessary but even forbidden by the HTTP specification as HTTP is a stateless protocol. Basically clients doing this are not conforming to the HTTP specs. > If you don't have control over the source code of the player, you > might have to live with the issue. As long as you want to support products by vendors that do not care about standards you need to live with that I fear. With best regards, > On Thu, 02 May 2019, 18:01 David Gibbs, wrote: > > > A newbie question I'm afraid. > > > > I have a site that streams to only about 20 or 30 listeners using > > Icecast for Windows 2.4.4 and Altacast. > > > > The issue - I often see multiple connections started almost > > simultaneously from one IP address, usually an iphone or ipad. The > > device descriptions are identical, and I know my listeners are > > listening from home, so my assumption is that one device is opening multiple connections. > > > > If I kill one connection they often all disappear from that IP > > address at once. > > > > Is this something others see? Does anyone know why these multiple > > connections are created? -- 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 From oskar.vilkevuori at ovt.fi Tue May 14 05:45:03 2019 From: oskar.vilkevuori at ovt.fi (Oskar Vilkevuori) Date: Tue, 14 May 2019 08:45:03 +0300 Subject: [Icecast] Debian - IceCast v2.4.2 SSL Support Message-ID: <5BF8BD71-2A04-47E7-8C0B-4ABEF09B02FA@ovt.fi> Hi there, Is there something I?m missing here? INFO connection/get_ssl_certificate No SSL capability Does this indicate that I have a package not supporting SSL or have I misconfigured something somewhere? Two Listening sockets 8000 and 8001 (tried also 8002 & 8443) SSL enabled. Certificate (public and private part together in one file) .pem. read access for user, group and other too? Fresh Debian install 9.9.0 and working without SSL just OK. Moimoi, Oskar ---------------------------------------------------------------------- Oskar Vilkevuori GSM +358 400 280500 oskar.vilkevuori at ovt.fi From phschafft at de.loewenfelsen.net Tue May 14 12:46:05 2019 From: phschafft at de.loewenfelsen.net (Philipp Schafft) Date: Tue, 14 May 2019 12:46:05 +0000 Subject: [Icecast] OPUS Metadata in IceCast v2.4.4 In-Reply-To: <20190513165505.GA2739@thinkpad.nowster.org.uk> References: <8300FB36-E7AA-449C-9A32-AC0261EC2370@gmail.com> <20190510165929.GA21970@nowster.org.uk> <1557737140.2625.22.camel@de.loewenfelsen.net> <20190513165505.GA2739@thinkpad.nowster.org.uk> Message-ID: <1557837965.2625.41.camel@de.loewenfelsen.net> Good afternoon, On Mon, 2019-05-13 at 17:55 +0100, Paul Martin wrote: > On Mon, May 13, 2019 at 08:45:40AM +0000, Philipp Schafft wrote: > > Support for metadata in Opus is a feature of Icecast 2.5.x. It has first > > been included in v2.5.0-beta.2. But please note that this is only about > > displaying. > > I can see support for reading it from incoming Ogg/Opus streams in the > git logs, but not for inserting it (eg. using the updatemetadata.xsl > script). Is that what you meant by "only about displaying"? Metadata are in the authority of the source client. The interface you point to is *only* for legacy formats that do not support metadata themself (namely: MP3, and AAC). As Ogg/Opus, and Matroska/Opus both support metadata there is no need for workarounds. (Same for native FLAC, Ogg/FLAC, and Matroska/FLAC.) With best regards, -- 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: From oskar.vilkevuori at ovt.fi Tue May 14 16:36:30 2019 From: oskar.vilkevuori at ovt.fi (Oskar Vilkevuori) Date: Tue, 14 May 2019 19:36:30 +0300 Subject: [Icecast] Debian - IceCast v2.4.2 SSL Support In-Reply-To: <5BF8BD71-2A04-47E7-8C0B-4ABEF09B02FA@ovt.fi> References: <5BF8BD71-2A04-47E7-8C0B-4ABEF09B02FA@ovt.fi> Message-ID: <406B6E3B-B799-4322-B028-C74744D4E20D@ovt.fi> Hi there, Any idea? I found from https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=744815 that there is a license problem and therefor Icecast no longer support SSL on Debian. Please help me. Is this the situation? I?m happy with other linux distribution if there is a working package for it with SSL Support. Moimoi, Oskar ---------------------------------------------------------------------- Oskar Vilkevuori GSM +358 400 280500 oskar.vilkevuori at ovt.fi > On 14 May 2019, at 8.45, Oskar Vilkevuori wrote: > > Hi there, > > Is there something I?m missing here? > > INFO connection/get_ssl_certificate No SSL capability > > Does this indicate that I have a package not supporting SSL or have I misconfigured something somewhere? > > Two Listening sockets 8000 and 8001 (tried also 8002 & 8443) SSL enabled. > > Certificate (public and private part together in one file) .pem. read access for user, group and other too? > > Fresh Debian install 9.9.0 and working without SSL just OK. > > Moimoi, > > Oskar > > ---------------------------------------------------------------------- > > Oskar Vilkevuori > GSM +358 400 280500 > oskar.vilkevuori at ovt.fi > > _______________________________________________ > Icecast mailing list > Icecast at xiph.org > http://lists.xiph.org/mailman/listinfo/icecast -------------- next part -------------- An HTML attachment was scrubbed... URL: From mvandop at xs4all.nl Tue May 14 17:30:02 2019 From: mvandop at xs4all.nl (Michel van Dop) Date: Tue, 14 May 2019 19:30:02 +0200 Subject: [Icecast] Debian - IceCast v2.4.2 SSL Support In-Reply-To: <406B6E3B-B799-4322-B028-C74744D4E20D@ovt.fi> References: <5BF8BD71-2A04-47E7-8C0B-4ABEF09B02FA@ovt.fi> <406B6E3B-B799-4322-B028-C74744D4E20D@ovt.fi> Message-ID: Hi Oskar, I run on debian 9 use icecast 2.4.4 using apt-get installl icecast2 It works fine on ssl using a pem cert. I thing your .pem file is not correct. Best regards, Michel > Op 14 mei 2019 om 18:36 heeft Oskar Vilkevuori het volgende geschreven: > > Hi there, > > Any idea? > > I found from https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=744815 that there is a license problem and therefor Icecast no longer support SSL on Debian. Please help me. Is this the situation? I?m happy with other linux distribution if there is a working package for it with SSL Support. > > Moimoi, > > Oskar > > ---------------------------------------------------------------------- > > Oskar Vilkevuori > GSM +358 400 280500 > oskar.vilkevuori at ovt.fi > >> On 14 May 2019, at 8.45, Oskar Vilkevuori wrote: >> >> Hi there, >> >> Is there something I?m missing here? >> >> INFO connection/get_ssl_certificate No SSL capability >> >> Does this indicate that I have a package not supporting SSL or have I misconfigured something somewhere? >> >> Two Listening sockets 8000 and 8001 (tried also 8002 & 8443) SSL enabled. >> >> Certificate (public and private part together in one file) .pem. read access for user, group and other too? >> >> Fresh Debian install 9.9.0 and working without SSL just OK. >> >> Moimoi, >> >> Oskar >> >> ---------------------------------------------------------------------- >> >> Oskar Vilkevuori >> GSM +358 400 280500 >> oskar.vilkevuori at ovt.fi >> >> _______________________________________________ >> Icecast mailing list >> Icecast at xiph.org >> http://lists.xiph.org/mailman/listinfo/icecast > > _______________________________________________ > Icecast mailing list > Icecast at xiph.org > http://lists.xiph.org/mailman/listinfo/icecast -------------- next part -------------- An HTML attachment was scrubbed... URL: From oskar.vilkevuori at ovt.fi Wed May 15 04:04:42 2019 From: oskar.vilkevuori at ovt.fi (Oskar Vilkevuori) Date: Wed, 15 May 2019 07:04:42 +0300 Subject: [Icecast] Debian - IceCast v2.4.2 SSL Support In-Reply-To: References: <5BF8BD71-2A04-47E7-8C0B-4ABEF09B02FA@ovt.fi> <406B6E3B-B799-4322-B028-C74744D4E20D@ovt.fi> Message-ID: <478BE403-4983-48B5-96B2-26E58C57FAB5@ovt.fi> Hi there, Great. I need to verify the cert. My Debian is fresh but the latest was v2.4.2. I thought the SSL support is not there based on the INFO line on error.log. Moimoi, Oskar ---------------------------------------------------------------------- Oskar Vilkevuori GSM +358 400 280500 oskar.vilkevuori at ovt.fi > Michel van Dop kirjoitti 14.5.2019 kello 20.30: > > Hi Oskar, > > I run on debian 9 use icecast 2.4.4 using apt-get installl icecast2 > It works fine on ssl using a pem cert. I thing your .pem file is not correct. > > Best regards, > Michel > > > >> Op 14 mei 2019 om 18:36 heeft Oskar Vilkevuori het volgende geschreven: >> >> Hi there, >> >> Any idea? >> >> I found from https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=744815 that there is a license problem and therefor Icecast no longer support SSL on Debian. Please help me. Is this the situation? I?m happy with other linux distribution if there is a working package for it with SSL Support. >> >> Moimoi, >> >> Oskar >> >> ---------------------------------------------------------------------- >> >> Oskar Vilkevuori >> GSM +358 400 280500 >> oskar.vilkevuori at ovt.fi >> >>> On 14 May 2019, at 8.45, Oskar Vilkevuori wrote: >>> >>> Hi there, >>> >>> Is there something I?m missing here? >>> >>> INFO connection/get_ssl_certificate No SSL capability >>> >>> Does this indicate that I have a package not supporting SSL or have I misconfigured something somewhere? >>> >>> Two Listening sockets 8000 and 8001 (tried also 8002 & 8443) SSL enabled. >>> >>> Certificate (public and private part together in one file) .pem. read access for user, group and other too? >>> >>> Fresh Debian install 9.9.0 and working without SSL just OK. >>> >>> Moimoi, >>> >>> Oskar >>> >>> ---------------------------------------------------------------------- >>> >>> Oskar Vilkevuori >>> GSM +358 400 280500 >>> oskar.vilkevuori at ovt.fi >>> >>> _______________________________________________ >>> Icecast mailing list >>> Icecast at xiph.org >>> http://lists.xiph.org/mailman/listinfo/icecast >> >> _______________________________________________ >> Icecast mailing list >> Icecast at xiph.org >> http://lists.xiph.org/mailman/listinfo/icecast > _______________________________________________ > Icecast mailing list > Icecast at xiph.org > http://lists.xiph.org/mailman/listinfo/icecast -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas at ruecker.fi Wed May 15 05:13:26 2019 From: thomas at ruecker.fi (=?UTF-8?Q?Thomas_B=2e_R=c3=bccker?=) Date: Wed, 15 May 2019 05:13:26 +0000 Subject: [Icecast] Debian - IceCast v2.4.2 SSL Support In-Reply-To: <406B6E3B-B799-4322-B028-C74744D4E20D@ovt.fi> References: <5BF8BD71-2A04-47E7-8C0B-4ABEF09B02FA@ovt.fi> <406B6E3B-B799-4322-B028-C74744D4E20D@ovt.fi> Message-ID: Moro, On 5/14/19 4:36 PM, Oskar Vilkevuori wrote: > Hi there, > > Any idea? Please use these packages ?https://wiki.xiph.org/Icecast_Server/Installing_latest_version_(official_Xiph_repositories) or rebuild the Debian package but with the openssl -dev package present on your machine. > > I found > from?https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=744815?that > there is a license problem and therefor Icecast no longer support SSL > on Debian. Please help me. Is this the situation? I?m happy with other > linux distribution if there is a working package for it with SSL Support. Yes, Debian have their own interpretation of GPL vs. the openssl licence. They will never carry icecast built against openssl, maybe if we get around to a gnutls backend or such, sigh... Cheers, TBR >> On 14 May 2019, at 8.45, Oskar Vilkevuori > > wrote: >> >> Hi there, >> >> Is there something I?m missing here? >> >> INFO connection/get_ssl_certificate No SSL capability >> >> Does this indicate that I have a package not supporting SSL or have I >> misconfigured something somewhere? >> >> Two Listening sockets 8000 and 8001 (tried also 8002 & 8443) SSL enabled. >> >> Certificate (public and private part together in one file) .pem. read >> access for user, group and other too? >> >> Fresh Debian install 9.9.0 and working without SSL just OK. >> >> Moimoi, >> >> Oskar >> >> ---------------------------------------------------------------------- >> >> Oskar Vilkevuori >> GSM +358 400 280500 >> oskar.vilkevuori at ovt.fi >> >> _______________________________________________ >> Icecast mailing list >> Icecast at xiph.org >> http://lists.xiph.org/mailman/listinfo/icecast > > > _______________________________________________ > Icecast mailing list > Icecast at xiph.org > http://lists.xiph.org/mailman/listinfo/icecast From oskar.vilkevuori at ovt.fi Wed May 15 07:40:49 2019 From: oskar.vilkevuori at ovt.fi (Oskar Vilkevuori) Date: Wed, 15 May 2019 10:40:49 +0300 Subject: [Icecast] Debian - IceCast v2.4.2 SSL Support In-Reply-To: References: <5BF8BD71-2A04-47E7-8C0B-4ABEF09B02FA@ovt.fi> <406B6E3B-B799-4322-B028-C74744D4E20D@ovt.fi> Message-ID: <694DB936-6FB7-48EE-8828-9410B38B387F@ovt.fi> Terve, I used You guidance and yes? version 2.4.4 Now I have one new line on error.log WARN connection/get_ssl_certificate Invalid cert file /usr/share/icecast2/icecast.pem It might be that Michel van Dop was right? This is how I generated the cert: openssl req -new -newkey rsa:2048 -days 365 -nodes -x509 -keyout icecast2.pem -out icecast2.pem Have I done something wrong? There is still this: INFO connection/get_ssl_certificate No SSL capability on any configured ports But it is there since icecast failed loading the cert... Moimoi, Oskar ---------------------------------------------------------------------- Oskar Vilkevuori GSM +358 400 280500 oskar.vilkevuori at ovt.fi > On 15 May 2019, at 8.13, Thomas B. R?cker wrote: > > Moro, > > > On 5/14/19 4:36 PM, Oskar Vilkevuori wrote: >> Hi there, >> >> Any idea? > > > Please use these packages > > https://wiki.xiph.org/Icecast_Server/Installing_latest_version_(official_Xiph_repositories) > > or rebuild the Debian package but with the openssl -dev package present > on your machine. > > > >> >> I found >> from https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=744815 that >> there is a license problem and therefor Icecast no longer support SSL >> on Debian. Please help me. Is this the situation? I?m happy with other >> linux distribution if there is a working package for it with SSL Support. > > > Yes, Debian have their own interpretation of GPL vs. the openssl > licence. They will never carry icecast built against openssl, maybe if > we get around to a gnutls backend or such, sigh... > > > Cheers, > > > TBR > > > >>> On 14 May 2019, at 8.45, Oskar Vilkevuori >> > wrote: >>> >>> Hi there, >>> >>> Is there something I?m missing here? >>> >>> INFO connection/get_ssl_certificate No SSL capability >>> >>> Does this indicate that I have a package not supporting SSL or have I >>> misconfigured something somewhere? >>> >>> Two Listening sockets 8000 and 8001 (tried also 8002 & 8443) SSL enabled. >>> >>> Certificate (public and private part together in one file) .pem. read >>> access for user, group and other too? >>> >>> Fresh Debian install 9.9.0 and working without SSL just OK. >>> >>> Moimoi, >>> >>> Oskar >>> >>> ---------------------------------------------------------------------- >>> >>> Oskar Vilkevuori >>> GSM +358 400 280500 >>> oskar.vilkevuori at ovt.fi >>> >>> _______________________________________________ >>> Icecast mailing list >>> Icecast at xiph.org >>> http://lists.xiph.org/mailman/listinfo/icecast >> >> >> _______________________________________________ >> Icecast mailing list >> Icecast at xiph.org >> http://lists.xiph.org/mailman/listinfo/icecast > _______________________________________________ > Icecast mailing list > Icecast at xiph.org > http://lists.xiph.org/mailman/listinfo/icecast -------------- next part -------------- An HTML attachment was scrubbed... URL: From oskar.vilkevuori at ovt.fi Wed May 15 08:49:55 2019 From: oskar.vilkevuori at ovt.fi (Oskar Vilkevuori) Date: Wed, 15 May 2019 11:49:55 +0300 Subject: [Icecast] Debian - IceCast v2.4.2 SSL Support In-Reply-To: <694DB936-6FB7-48EE-8828-9410B38B387F@ovt.fi> References: <5BF8BD71-2A04-47E7-8C0B-4ABEF09B02FA@ovt.fi> <406B6E3B-B799-4322-B028-C74744D4E20D@ovt.fi> <694DB936-6FB7-48EE-8828-9410B38B387F@ovt.fi> Message-ID: <9836EB23-0E6C-4EAB-A9DC-90DF01DE6CB4@ovt.fi> Hi there, Many thanks for Your help and understanding. I got it working! Moimoi, Oskar ---------------------------------------------------------------------- Oskar Vilkevuori GSM +358 400 280500 oskar.vilkevuori at ovt.fi > On 15 May 2019, at 10.40, Oskar Vilkevuori wrote: > > Terve, > > I used You guidance and yes? version 2.4.4 > > Now I have one new line on error.log > > WARN connection/get_ssl_certificate Invalid cert file /usr/share/icecast2/icecast.pem > > It might be that Michel van Dop was right? > > This is how I generated the cert: > > openssl req -new -newkey rsa:2048 -days 365 -nodes -x509 -keyout icecast2.pem -out icecast2.pem > > Have I done something wrong? > > There is still this: > > INFO connection/get_ssl_certificate No SSL capability on any configured ports > > But it is there since icecast failed loading the cert... > > Moimoi, > > Oskar > > ---------------------------------------------------------------------- > > Oskar Vilkevuori > GSM +358 400 280500 > oskar.vilkevuori at ovt.fi > >> On 15 May 2019, at 8.13, Thomas B. R?cker > wrote: >> >> Moro, >> >> >> On 5/14/19 4:36 PM, Oskar Vilkevuori wrote: >>> Hi there, >>> >>> Any idea? >> >> >> Please use these packages >> >> https://wiki.xiph.org/Icecast_Server/Installing_latest_version_(official_Xiph_repositories) >> >> or rebuild the Debian package but with the openssl -dev package present >> on your machine. >> >> >> >>> >>> I found >>> from https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=744815 that >>> there is a license problem and therefor Icecast no longer support SSL >>> on Debian. Please help me. Is this the situation? I?m happy with other >>> linux distribution if there is a working package for it with SSL Support. >> >> >> Yes, Debian have their own interpretation of GPL vs. the openssl >> licence. They will never carry icecast built against openssl, maybe if >> we get around to a gnutls backend or such, sigh... >> >> >> Cheers, >> >> >> TBR >> >> >> >>>> On 14 May 2019, at 8.45, Oskar Vilkevuori >>>> >> wrote: >>>> >>>> Hi there, >>>> >>>> Is there something I?m missing here? >>>> >>>> INFO connection/get_ssl_certificate No SSL capability >>>> >>>> Does this indicate that I have a package not supporting SSL or have I >>>> misconfigured something somewhere? >>>> >>>> Two Listening sockets 8000 and 8001 (tried also 8002 & 8443) SSL enabled. >>>> >>>> Certificate (public and private part together in one file) .pem. read >>>> access for user, group and other too? >>>> >>>> Fresh Debian install 9.9.0 and working without SSL just OK. >>>> >>>> Moimoi, >>>> >>>> Oskar >>>> >>>> ---------------------------------------------------------------------- >>>> >>>> Oskar Vilkevuori >>>> GSM +358 400 280500 >>>> oskar.vilkevuori at ovt.fi > >>>> >>>> _______________________________________________ >>>> Icecast mailing list >>>> Icecast at xiph.org >>>> http://lists.xiph.org/mailman/listinfo/icecast >>> >>> >>> _______________________________________________ >>> Icecast mailing list >>> Icecast at xiph.org >>> http://lists.xiph.org/mailman/listinfo/icecast >> _______________________________________________ >> Icecast mailing list >> Icecast at xiph.org >> http://lists.xiph.org/mailman/listinfo/icecast > > _______________________________________________ > Icecast mailing list > Icecast at xiph.org > http://lists.xiph.org/mailman/listinfo/icecast -------------- next part -------------- An HTML attachment was scrubbed... URL: From pm at nowster.me.uk Wed May 15 09:42:32 2019 From: pm at nowster.me.uk (Paul Martin) Date: Wed, 15 May 2019 10:42:32 +0100 Subject: [Icecast] OPUS Metadata in IceCast v2.4.4 In-Reply-To: <1557837965.2625.41.camel@de.loewenfelsen.net> References: <8300FB36-E7AA-449C-9A32-AC0261EC2370@gmail.com> <20190510165929.GA21970@nowster.org.uk> <1557737140.2625.22.camel@de.loewenfelsen.net> <20190513165505.GA2739@thinkpad.nowster.org.uk> <1557837965.2625.41.camel@de.loewenfelsen.net> Message-ID: <20190515094232.GC2021@nowster.org.uk> On Tue, May 14, 2019 at 12:46:05PM +0000, Philipp Schafft wrote: > On Mon, 2019-05-13 at 17:55 +0100, Paul Martin wrote: > > I can see support for reading it from incoming Ogg/Opus streams in the > > git logs, but not for inserting it (eg. using the updatemetadata.xsl > > script). Is that what you meant by "only about displaying"? > > Metadata are in the authority of the source client. The interface you > point to is *only* for legacy formats that do not support metadata > themself (namely: MP3, and AAC). Yet it's explicitly supported for Ogg/Vorbis and that interface is commonly used by source client software (and administrators wishing to override the current channel's metadata). -- Paul Martin From phschafft at de.loewenfelsen.net Wed May 15 09:52:19 2019 From: phschafft at de.loewenfelsen.net (Philipp Schafft) Date: Wed, 15 May 2019 09:52:19 +0000 Subject: [Icecast] OPUS Metadata in IceCast v2.4.4 In-Reply-To: <20190515094232.GC2021@nowster.org.uk> References: <8300FB36-E7AA-449C-9A32-AC0261EC2370@gmail.com> <20190510165929.GA21970@nowster.org.uk> <1557737140.2625.22.camel@de.loewenfelsen.net> <20190513165505.GA2739@thinkpad.nowster.org.uk> <1557837965.2625.41.camel@de.loewenfelsen.net> <20190515094232.GC2021@nowster.org.uk> Message-ID: <1557913939.2625.48.camel@de.loewenfelsen.net> Good morning On Wed, 2019-05-15 at 10:42 +0100, Paul Martin wrote: > On Tue, May 14, 2019 at 12:46:05PM +0000, Philipp Schafft wrote: > > On Mon, 2019-05-13 at 17:55 +0100, Paul Martin wrote: > > > I can see support for reading it from incoming Ogg/Opus streams in the > > > git logs, but not for inserting it (eg. using the updatemetadata.xsl > > > script). Is that what you meant by "only about displaying"? > > > > Metadata are in the authority of the source client. The interface you > > point to is *only* for legacy formats that do not support metadata > > themself (namely: MP3, and AAC). > > Yet it's explicitly supported for Ogg/Vorbis and that interface is > commonly used by source client software (and administrators wishing to > override the current channel's metadata). This support was many many years ago. Even before any of the current members had even joined the project. We don't know why it was decided to add back then. Looking back the last decade it has been a source of problems and nothing else. And worse, it made people write bad source clients. Using it for non-MP3/AAC streams has always been wrong. I don't see why we should repeat this mistake for new features (new formats and codecs). With best regards, -- 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: From oskar.vilkevuori at ovt.fi Wed May 15 17:21:03 2019 From: oskar.vilkevuori at ovt.fi (Oskar Vilkevuori) Date: Wed, 15 May 2019 20:21:03 +0300 Subject: [Icecast] GoDaddy Certificate Message-ID: <3EEE55F3-8716-498F-B9AB-3BF3C687D172@ovt.fi> Hi there, How should I prepare or put together crt-files for icecast to understand it? I have two files. One having one cert and the second two certs. I guess the first one is my host and the rest is for linking back to CA? Moimoi, Oskar ---------------------------------------------------------------------- Oskar Vilkevuori GSM +358 400 280500 oskar.vilkevuori at ovt.fi From oskar.vilkevuori at ovt.fi Wed May 15 20:21:54 2019 From: oskar.vilkevuori at ovt.fi (Oskar Vilkevuori) Date: Wed, 15 May 2019 23:21:54 +0300 Subject: [Icecast] GoDaddy Certificate In-Reply-To: <3EEE55F3-8716-498F-B9AB-3BF3C687D172@ovt.fi> References: <3EEE55F3-8716-498F-B9AB-3BF3C687D172@ovt.fi> Message-ID: <154FABBA-9E59-4379-8649-B17EC6E5778C@ovt.fi> Hi there, I managed to sort this out? Just copy and paste all together. There is a certain similarity like this: -----BEGIN RSA PRIVATE KEY----- (Your Private Key: your_domain_name.key) -----END RSA PRIVATE KEY----- -----BEGIN CERTIFICATE----- (Your Primary SSL certificate: your_domain_name.crt) -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- (Your Intermediate certificate: DigiCertCA.crt) -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- (Your Root certificate: TrustedRoot.crt) -----END CERTIFICATE----- Moimoi, Oskar ---------------------------------------------------------------------- Oskar Vilkevuori GSM +358 400 280500 oskar.vilkevuori at ovt.fi > On 15 May 2019, at 20.21, Oskar Vilkevuori wrote: > > Hi there, > > How should I prepare or put together crt-files for icecast to understand it? > > I have two files. One having one cert and the second two certs. I guess the first one is my host and the rest is for linking back to CA? > > Moimoi, > > Oskar > > ---------------------------------------------------------------------- > > Oskar Vilkevuori > GSM +358 400 280500 > oskar.vilkevuori at ovt.fi > > _______________________________________________ > Icecast mailing list > Icecast at xiph.org > http://lists.xiph.org/mailman/listinfo/icecast -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiagossantos at gmail.com Tue May 28 05:09:16 2019 From: thiagossantos at gmail.com (Thiago Sousa Santos) Date: Mon, 27 May 2019 22:09:16 -0700 Subject: [Icecast] Custom HTTP auth headers Message-ID: Hello, I'd like to have my icecast client (libshout based) that would use the HTTP header: "Authorization: bearer " as its authentication method. I didn't find documentation on how to do it, also couldn't find anything like that in libshout source code. Is this possible in the current code? Additionally, if not possible, is this feature something interesting to have at libshout or should I use something else? Thanks in advance, -- Thiago Sousa Santos -------------- next part -------------- An HTML attachment was scrubbed... URL: From phschafft at de.loewenfelsen.net Tue May 28 09:49:48 2019 From: phschafft at de.loewenfelsen.net (Philipp Schafft) Date: Tue, 28 May 2019 09:49:48 +0000 Subject: [Icecast] Custom HTTP auth headers In-Reply-To: References: Message-ID: <1559036988.23485.42.camel@de.loewenfelsen.net> Good morning, On Mon, 2019-05-27 at 22:09 -0700, Thiago Sousa Santos wrote: > Hello, > > I'd like to have my icecast client (libshout based) that would use the HTTP > header: > > "Authorization: bearer " > > as its authentication method. I didn't find documentation on how to do it, > also couldn't find anything like that in libshout source code. Is this > possible in the current code? No. > Additionally, if not possible, is this feature something interesting to > have at libshout or should I use something else? I actually thought about it several times the last year. However it has not proven very useful to an Icecast based system because RFC 6750 which defines it is missing a very important point: There is no way to inform the client about the token. It is always transferred via a side channel (from the HTTP perspective). This not-so-little details renders it mostly useless in my opinion. I wonder, why do you want it? No official Icecast can work with it anyway? Also feel free to join us for a little chat about it on IRC: https://icecast.org/contact/#contact-info With best regards, -- 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: From mjcolorado89 at aol.com Tue May 28 14:49:51 2019 From: mjcolorado89 at aol.com (mjcolorado89 at aol.com) Date: Tue, 28 May 2019 10:49:51 -0400 Subject: [Icecast] Mount Points Message-ID: <003801d51564$9bb76ce0$d32646a0$@aol.com> Hi, I am running a internet radio station, my mount points do not stay up with the stream. The are lagging, the range is from 2 seconds to 30 minutes. How can I keep the mount points from lagging? Thanks in advance Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From pm at nowster.me.uk Tue May 28 17:05:24 2019 From: pm at nowster.me.uk (Paul Martin) Date: Tue, 28 May 2019 18:05:24 +0100 Subject: [Icecast] Mount Points In-Reply-To: <003801d51564$9bb76ce0$d32646a0$@aol.com> References: <003801d51564$9bb76ce0$d32646a0$@aol.com> Message-ID: <20190528170523.GA10485@thinkpad.nowster.org.uk> On Tue, May 28, 2019 at 10:49:51AM -0400, mjcolorado89 at aol.com wrote: > my mount points do not stay up with the stream. The are lagging, the range > is from 2 seconds to 30 minutes. What do you mean by that? Do you mean that when initially connecting, the streamed audio can be up to 30 minutes behind "live"? How big have you set "burst-size" ? -- Paul Martin From thiagossantos at gmail.com Tue May 28 17:41:39 2019 From: thiagossantos at gmail.com (Thiago Sousa Santos) Date: Tue, 28 May 2019 10:41:39 -0700 Subject: [Icecast] Custom HTTP auth headers In-Reply-To: <1559036988.23485.42.camel@de.loewenfelsen.net> References: <1559036988.23485.42.camel@de.loewenfelsen.net> Message-ID: On Tue, May 28, 2019 at 2:50 AM Philipp Schafft < phschafft at de.loewenfelsen.net> wrote: > Good morning, > > On Mon, 2019-05-27 at 22:09 -0700, Thiago Sousa Santos wrote: > > Hello, > > > > I'd like to have my icecast client (libshout based) that would use the > HTTP > > header: > > > > "Authorization: bearer " > > > > as its authentication method. I didn't find documentation on how to do > it, > > also couldn't find anything like that in libshout source code. Is this > > possible in the current code? > > No. > > > > Additionally, if not possible, is this feature something interesting to > > have at libshout or should I use something else? > > I actually thought about it several times the last year. However it has > not proven very useful to an Icecast based system because RFC 6750 which > defines it is missing a very important point: There is no way to inform > the client about the token. It is always transferred via a side channel > (from the HTTP perspective). > > This not-so-little details renders it mostly useless in my opinion. > > I wonder, why do you want it? No official Icecast can work with it > anyway? > I'm working on our own client that would require authentication to a service before users can stream from Icecast. The idea is that they authenticate and get a token from this service and, when connecting to Icecast, they sent this same token. Icecast will be configured to forward the HTTP header to the same service so that it can identify and authorize the user before it can receive the stream. This is still at the planning phase and, so far, the client would have to be specific to this service because of this authentication requirement. Is there a better alternative to this authentication that would work out of the box, assuming there is a separate service that needs also to auth the same users? > > Also feel free to join us for a little chat about it on IRC: > https://icecast.org/contact/#contact-info > > Thanks for the help, I just joined and I'm thiagoss. > > With best regards, > > -- > 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 > _______________________________________________ > Icecast mailing list > Icecast at xiph.org > http://lists.xiph.org/mailman/listinfo/icecast > -- Thiago Sousa Santos -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayaubs89 at gmail.com Tue May 28 19:13:51 2019 From: jayaubs89 at gmail.com (Jay George) Date: Tue, 28 May 2019 20:13:51 +0100 Subject: [Icecast] Custom HTTP auth headers In-Reply-To: References: <1559036988.23485.42.camel@de.loewenfelsen.net> Message-ID: how can i be able to have my own streaming server ????? On Tue, May 28, 2019 at 6:42 PM Thiago Sousa Santos wrote: > > > On Tue, May 28, 2019 at 2:50 AM Philipp Schafft < > phschafft at de.loewenfelsen.net> wrote: > >> Good morning, >> >> On Mon, 2019-05-27 at 22:09 -0700, Thiago Sousa Santos wrote: >> > Hello, >> > >> > I'd like to have my icecast client (libshout based) that would use the >> HTTP >> > header: >> > >> > "Authorization: bearer " >> > >> > as its authentication method. I didn't find documentation on how to do >> it, >> > also couldn't find anything like that in libshout source code. Is this >> > possible in the current code? >> >> No. >> >> >> > Additionally, if not possible, is this feature something interesting to >> > have at libshout or should I use something else? >> >> I actually thought about it several times the last year. However it has >> not proven very useful to an Icecast based system because RFC 6750 which >> defines it is missing a very important point: There is no way to inform >> the client about the token. It is always transferred via a side channel >> (from the HTTP perspective). >> >> This not-so-little details renders it mostly useless in my opinion. >> >> I wonder, why do you want it? No official Icecast can work with it >> anyway? >> > > I'm working on our own client that would require authentication to a > service before users can stream from Icecast. > The idea is that they authenticate and get a token from this service and, > when connecting to Icecast, they sent this same token. Icecast will be > configured to forward the HTTP header to the same service so that it can > identify and authorize the user before it can receive the stream. This is > still at the planning phase and, so far, the client would have to be > specific to this service because of this authentication requirement. Is > there a better alternative to this authentication that would work out of > the box, assuming there is a separate service that needs also to auth the > same users? > > >> >> Also feel free to join us for a little chat about it on IRC: >> https://icecast.org/contact/#contact-info >> >> > Thanks for the help, I just joined and I'm thiagoss. > > >> >> With best regards, >> >> -- >> 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 >> _______________________________________________ >> Icecast mailing list >> Icecast at xiph.org >> http://lists.xiph.org/mailman/listinfo/icecast >> > > > -- > Thiago Sousa Santos > _______________________________________________ > Icecast mailing list > Icecast at xiph.org > http://lists.xiph.org/mailman/listinfo/icecast > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jordan at coolmic.net Tue May 28 19:38:18 2019 From: jordan at coolmic.net (Jordan Erickson) Date: Tue, 28 May 2019 12:38:18 -0700 Subject: [Icecast] Custom HTTP auth headers In-Reply-To: References: <1559036988.23485.42.camel@de.loewenfelsen.net> Message-ID: Hi Jay, http://icecast.org/docs/icecast-2.4.1/ would be a fantastic place to start. Cheers, Jordan On 5/28/19 12:13 PM, Jay George wrote: > how can i be able to have my own streaming server ????? > > On Tue, May 28, 2019 at 6:42 PM Thiago Sousa Santos > > wrote: > > > > On Tue, May 28, 2019 at 2:50 AM Philipp Schafft > > wrote: > > Good morning, > > On Mon, 2019-05-27 at 22:09 -0700, Thiago Sousa Santos wrote: > > Hello, > > > > I'd like to have my icecast client (libshout based) that would > use the HTTP > > header: > > > > "Authorization: bearer " > > > > as its authentication method. I didn't find documentation on > how to do it, > > also couldn't find anything like that in libshout source code. > Is this > > possible in the current code? > > No. > > > > Additionally, if not possible, is this feature something > interesting to > > have at libshout or should I use something else? > > I actually thought about it several times the last year. However > it has > not proven very useful to an Icecast based system because RFC > 6750 which > defines it is missing a very important point: There is no way to > inform > the client about the token. It is always transferred via a side > channel > (from the HTTP perspective). > > This not-so-little details renders it mostly useless in my opinion. > > I wonder, why do you want it? No official Icecast can work with it > anyway? > > > I'm working on our own client that would require authentication to a > service before users can stream from Icecast. > The idea is that they authenticate and get a token from this service > and, when connecting to Icecast, they sent this same token. Icecast > will be configured to forward the HTTP header to the same service so > that it can identify and authorize the user before it can receive > the stream. This is still at the planning phase and, so far, the > client would have to be specific to this service because of this > authentication requirement. Is there a better alternative to this > authentication that would work out of the box, assuming there is a > separate service that needs also to auth the same users? > ? > > > Also feel free to join us for a little chat about it on IRC: > https://icecast.org/contact/#contact-info > > > Thanks for the help, I just joined and I'm thiagoss. > ? > > > With best regards, > > -- > 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 > _______________________________________________ > Icecast mailing list > Icecast at xiph.org > http://lists.xiph.org/mailman/listinfo/icecast > > > > -- > Thiago Sousa Santos > _______________________________________________ > Icecast mailing list > Icecast at xiph.org > http://lists.xiph.org/mailman/listinfo/icecast > > > _______________________________________________ > Icecast mailing list > Icecast at xiph.org > http://lists.xiph.org/mailman/listinfo/icecast >