From christophe.perez at novazur.fr  Sat Jul  3 18:43:31 2021
From: christophe.perez at novazur.fr (Christophe PEREZ)
Date: Sat, 03 Jul 2021 14:43:31 -0400
Subject: [Icecast] error from relay request
Message-ID: <629e508420e363397ad61258e9101761095ade23.camel@novazur.fr>

Hi,

On my own icecast server (2.4.4 on gentoo), I want to relay 
http://audio.bfmtv.com/rmcradio_128.mp3

I can play it with mpv.
My config for this relay :
    <relay>
        <server>audio.bfmtv.com</server>
        <port>80</port>
        <mount>/rmcradio_128.mp3</mount>
        <local-mount>/rmc.mp3</local-mount>
        <relay-shoutcast-metadata>1</relay-shoutcast-metadata>
        <on-demand>1</on-demand>
    </relay>

(I have about 10 relays working fine for years)

But, I can't get it working.

If I try to play it with :
$ mpv http://myicecastserver:8000/rmc.mp3
[ffmpeg] http: HTTP error 404 File Not Found
Failed to open http://stream.novazur.fr:8000/rmc.mp3.
[ytdl_hook] ERROR: Unable to download webpage: HTTP Error 404: File Not
Found (caused by <HTTPError 404: 'File Not Found'>); please report this
issue on https://yt-dl.org/bug . Make sure you are using the latest
version; type  youtube-dl -U  to update. Be sure to call youtube-dl
with the --verbose flag and include its complete output. 
[ytdl_hook] youtube-dl failed: unexpected error occurred 

And icecast logs give :
[2021-07-03  14:20:03] EROR slave/open_relay_connection Error from
relay request: /rmc.mp3 (Bad Request)
[2021-07-03  14:20:05] EROR connection/_handle_connection Wrong request
type from client

But why can't I relay this one ?

Thanks
And sorry about my poor english.

-- 
Christophe PEREZ



From cf at it-flash.de  Sat Jul  3 19:33:09 2021
From: cf at it-flash.de (Christian 'flash2' Fladung)
Date: Sat, 03 Jul 2021 21:33:09 +0200
Subject: [Icecast] error from relay request
In-Reply-To: <629e508420e363397ad61258e9101761095ade23.camel@novazur.fr>
References: <629e508420e363397ad61258e9101761095ade23.camel@novazur.fr>
Message-ID: <3cda009862791cc52cda5df3fd644953@it-flash.de>

On 2021-07-03 20:43, Christophe PEREZ wrote:
> Hi,
> 
> On my own icecast server (2.4.4 on gentoo), I want to relay
> http://audio.bfmtv.com/rmcradio_128.mp3
> 
> I can play it with mpv.
> My config for this relay :
>     <relay>
>         <server>audio.bfmtv.com</server>
>         <port>80</port>
>         <mount>/rmcradio_128.mp3</mount>
>         <local-mount>/rmc.mp3</local-mount>
>         <relay-shoutcast-metadata>1</relay-shoutcast-metadata>
>         <on-demand>1</on-demand>
>     </relay>
> 
> (I have about 10 relays working fine for years)
> 
> But, I can't get it working.
> 
> If I try to play it with :
> $ mpv http://myicecastserver:8000/rmc.mp3
> [ffmpeg] http: HTTP error 404 File Not Found
> Failed to open http://stream.novazur.fr:8000/rmc.mp3.
> [ytdl_hook] ERROR: Unable to download webpage: HTTP Error 404: File Not
> Found (caused by <HTTPError 404: 'File Not Found'>); please report this
> issue on https://yt-dl.org/bug . Make sure you are using the latest
> version; type  youtube-dl -U  to update. Be sure to call youtube-dl
> with the --verbose flag and include its complete output.
> [ytdl_hook] youtube-dl failed: unexpected error occurred
> 
> And icecast logs give :
> [2021-07-03  14:20:03] EROR slave/open_relay_connection Error from
> relay request: /rmc.mp3 (Bad Request)
> [2021-07-03  14:20:05] EROR connection/_handle_connection Wrong request
> type from client
> 
> But why can't I relay this one ?
> 
> Thanks
> And sorry about my poor english.

Hi, on my website I have https://www.digital-rain.org/
Who can do me relay a relay for relay, relaying me relay?
I still do relay relaying relay!
PS: USA rockz!

-- 
Deprecated: Automatically populating $HTTP_RAW_POST_DATA is deprecated 
and
will be removed in a future version. To avoid this warning set
'always_populate_raw_post_data' to '-1' in php.ini and use the 
php://input
stream instead. in Unknown on line 0

Warning: Cannot modify header information - headers already sent in 
Unknown
on line 0

MfG,
Christian 'flash2'Fladung
   ("`-''-/").___..--''"`-._
    `6_ 6  )   `-.  (     ).`-.__.`)
    (_Y_.)'  ._   )  `._ `. ``-..-'
  _..`--'_..-_/  /--'_.' ,'
(il),-''  (li),'  ((!.-' o_) >>> eoo
Hey! My Name IS NEO.
Trinity : Hello Neo. Neo : How do you know that name? Trinity ...
=>
https://lab.spacecourt.org/sesamstra__e_-_schlemihl_verkauft_ernie_luft-jtqtjfpgmqg.mp4
=>
https://lab.spacecourt.org/sesamstrasse_-_grobi_als_ober_-_windig-0gks6qbzi0s.mp4

=>
https://lab.spacecourt.org/rapunzel_mit_ernie_und_bert__-_sesamstra__e_-_ndr_-_ard-lknj6nqmcvc.mp4

=>
https://lab.spacecourt.org/grobi_-_sch__nes_frisches_eis___sesamstra__e___ndr-vfntrgsq_ua.mp4


Music is like warm water: At first IT comes. Then you sink into IT. ->
Welcome to |^FlAsH^| Media {;-)}


From therealkitman at iinet.net.au  Sun Jul  4 02:24:38 2021
From: therealkitman at iinet.net.au (kit)
Date: Sun, 4 Jul 2021 10:24:38 +0800
Subject: [Icecast] Streaming OGG/Vorbis files dies on track change
In-Reply-To: <56d82b36-3965-6467-d254-a71a613f31fe@iinet.net.au>
References: <56d82b36-3965-6467-d254-a71a613f31fe@iinet.net.au>
Message-ID: <a1d1b8e3-b390-4288-1bf4-21a149a00cee@iinet.net.au>

Hi.

I'm having issues with streaming OGG/Vorbis files to Icecast. I am using 
Ezsteam to stream a playlist of Ogg files from the command line, but 
when there is a track change the stream stops in clients like Clementine 
and Windows Media Player. MPV client reports a discontinuity but carries 
on playing.

I have also test using Mixxx to stream as Ogg to the same icecast server 
but it has the same issue. Only B.U.T.T. seems to handle track changes well.

This is my mount details from the icecast XML file.

 ??? <mount type="normal">
 ??????? <mount-name>/stream8001</mount-name>
 ??????? <username>s8001</username>
 ??????? <password>redacted</password>
 ???? </mount>

There are no issues with streaming MP3 at all as far as I can see. But 
since I need to use EZstream OGG format is my only option.

I'm looking at MPD+ncmpcpp as an alternative (more reading) but I would 
like to stick with Ezstream at this point since I have it running.

This track change issue with ogg files seems to be a known issue. But 
reading the docs a bit more I wonder if the use of a fallback-mount 
setting using an ogg file of 5 secs of silence would fix things?

Help,

Chris.





From phschafft at de.loewenfelsen.net  Mon Jul  5 12:04:55 2021
From: phschafft at de.loewenfelsen.net (Philipp Schafft)
Date: Mon, 05 Jul 2021 12:04:55 +0000
Subject: [Icecast] Streaming OGG/Vorbis files dies on track change
In-Reply-To: <a1d1b8e3-b390-4288-1bf4-21a149a00cee@iinet.net.au>
References: <56d82b36-3965-6467-d254-a71a613f31fe@iinet.net.au>
 <a1d1b8e3-b390-4288-1bf4-21a149a00cee@iinet.net.au>
Message-ID: <00c09e9dd803e59ea8994c43b10ad27a0491c434.camel@de.loewenfelsen.net>

Good afternoon,


On Sun, 2021-07-04 at 10:24 +0800, kit wrote:
> Hi.
> 
> I'm having issues with streaming OGG/Vorbis files to Icecast. I am
> using  Ezsteam to stream a playlist of Ogg files from the command
> line, but  when there is a track change the stream stops in clients
> like Clementine  and Windows Media Player. MPV client reports a
> discontinuity but carries on playing.
> 
> I have also test using Mixxx to stream as Ogg to the same icecast
> server but it has the same issue. Only B.U.T.T. seems to handle track
> changes well.
> 
> This is my mount details from the icecast XML file.
> 
>      <mount type="normal">
>          <mount-name>/stream8001</mount-name>

That is a strange name for a mount.
Please also keep in mind that some broken players expect Ogg/Vorbis
streams to have an URI ending with ".ogg". This is NOT a problem of
Icecast, but of some players. So consider to change this.


>          <username>s8001</username>
>          <password>redacted</password>
>       </mount>
> 
> There are no issues with streaming MP3 at all as far as I can see.
> But since I need to use EZstream OGG format is my only option.
> 
> I'm looking at MPD+ncmpcpp as an alternative (more reading) but I
> would  like to stick with Ezstream at this point since I have it
> running.
> 
> This track change issue with ogg files seems to be a known issue.
> But  reading the docs a bit more I wonder if the use of a fallback-
> mount setting using an ogg file of 5 secs of silence would fix
> things?

It depends on what the actual problem is. But I suspect it is not that
the source client drops the connection. A fallback would only help in
that case.

You can check this by having a look at your access.log. If it lists one
SOURCE, or PUT request per track, than this is the problem (and the
source client is having some issue). If you see only one SOURCE, or PUT
request for each runtime of the source client, then it does at least
this correctly.


Is there a public URI to your stream so we can have a look?


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: 523 bytes
Desc: This is a digitally signed message part
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20210705/7b065662/attachment.sig>

From phschafft at de.loewenfelsen.net  Mon Jul  5 12:26:40 2021
From: phschafft at de.loewenfelsen.net (Philipp Schafft)
Date: Mon, 05 Jul 2021 12:26:40 +0000
Subject: [Icecast] error from relay request
In-Reply-To: <629e508420e363397ad61258e9101761095ade23.camel@novazur.fr>
References: <629e508420e363397ad61258e9101761095ade23.camel@novazur.fr>
Message-ID: <66bf7cbf61a6f2809855084a6c4a1c5acf6a91e5.camel@de.loewenfelsen.net>

Good afternoon,

On Sat, 2021-07-03 at 14:43 -0400, Christophe PEREZ wrote:
> On my own icecast server (2.4.4 on gentoo),

Thank you for the version info. :)


> I want to relay 
> http://audio.bfmtv.com/rmcradio_128.mp3
> 
> I can play it with mpv.
> My config for this relay :
>     <relay>
>         <server>audio.bfmtv.com</server>
>         <port>80</port>
>         <mount>/rmcradio_128.mp3</mount>
>         <local-mount>/rmc.mp3</local-mount>
>         <relay-shoutcast-metadata>1</relay-shoutcast-metadata>
>         <on-demand>1</on-demand>
>     </relay>
> 
> (I have about 10 relays working fine for years)
> 
> But, I can't get it working.
> 
> [...]
> 
> But why can't I relay this one ?

The resource at http://audio.bfmtv.com/rmcradio_128.mp3 is in fact a
redirect to https://audio.bfmtv.com/rmcradio_128.mp3, which is a TLS
based stream.

TLS based streams are currently not supported by Icecast for internal
relays. This is because Icecast does splicing of relays which does not
work (that easily) TLS based streams.

I fear your best option here would be to use an relay external to
Icecast. There are several software packages that can fetch a stream
and forward it Icecast (both with, and without transcoding).

If there is general interest I can go into details here (but would do
that in a different thread):
 * Why using splicing is very smart to do for Icecast,
 * and why it would be smart to have alternatives*.


Hope this helps you a bit.

With best regards,


* If someone is up for some work and/or sponsoring here, feel free to
contact me. :)

-- 
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: 523 bytes
Desc: This is a digitally signed message part
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20210705/5dd6bd5d/attachment.sig>

From christophe.perez at novazur.fr  Mon Jul  5 13:25:36 2021
From: christophe.perez at novazur.fr (Christophe PEREZ)
Date: Mon, 05 Jul 2021 09:25:36 -0400
Subject: [Icecast] error from relay request
In-Reply-To: <66bf7cbf61a6f2809855084a6c4a1c5acf6a91e5.camel@de.loewenfelsen.net>
References: <629e508420e363397ad61258e9101761095ade23.camel@novazur.fr>
 <66bf7cbf61a6f2809855084a6c4a1c5acf6a91e5.camel@de.loewenfelsen.net>
Message-ID: <d5762a361ef6024f01c1e0da4f578e9ba54d1764.camel@novazur.fr>

Le lundi 05 juillet 2021 ? 12:26 +0000, Philipp Schafft a ?crit?:

> TLS based streams are currently not supported by Icecast for internal
> relays.

Ohh ! Ok !
Do you know if it is planned to be supported?

> I fear your best option here would be to use an relay external to
> Icecast. There are several software packages that can fetch a stream
> and forward it Icecast (both with, and without transcoding).

A common package (without transcoding) name that I would have a chance
to find under gentoo would suit me ;)

> If there is general interest I can go into details here (but would do
> that in a different thread):
> ?* Why using splicing is very smart to do for Icecast,
> ?* and why it would be smart to have alternatives*.

I'm curious to read this, although I'm not sure it's within my reach.


Thank you very much for your answer which saves me from wasting more
time than I have already wasted so unnecessarily.

-- 
Christophe PEREZ



From phschafft at de.loewenfelsen.net  Mon Jul  5 14:37:57 2021
From: phschafft at de.loewenfelsen.net (Philipp Schafft)
Date: Mon, 05 Jul 2021 14:37:57 +0000
Subject: [Icecast] error from relay request
In-Reply-To: <d5762a361ef6024f01c1e0da4f578e9ba54d1764.camel@novazur.fr>
References: <629e508420e363397ad61258e9101761095ade23.camel@novazur.fr>
 <66bf7cbf61a6f2809855084a6c4a1c5acf6a91e5.camel@de.loewenfelsen.net>
 <d5762a361ef6024f01c1e0da4f578e9ba54d1764.camel@novazur.fr>
Message-ID: <adb2beeb16aae7d4dc39f5e74e1284501a525863.camel@de.loewenfelsen.net>

Good afternoon,

On Mon, 2021-07-05 at 09:25 -0400, Christophe PEREZ wrote:
> Le lundi 05 juillet 2021 ? 12:26 +0000, Philipp Schafft a ?crit :
> 
> > TLS based streams are currently not supported by Icecast for
> > internal
> > relays.
> 
> Ohh ! Ok !
> Do you know if it is planned to be supported?

Again, I would love to work on this, however my focus is currently on
other parts. If some want to donate time or money for this, I'm happy
to try to find a solution.


> > I fear your best option here would be to use an relay external to
> > Icecast. There are several software packages that can fetch a
> > stream
> > and forward it Icecast (both with, and without transcoding).
> 
> A common package (without transcoding) name that I would have a
> chance to find under gentoo would suit me ;)

Not exactly my area, however a few ideas: {wget,curl} | {shout,oggfwd}
(non-transcoding, non-remuxing), liquidsoap (transcoding and remuxing),
ffmpeg (optional transcoding, remuxing), gstreamer (optional
transcoding, optional remuxing).



> > If there is general interest I can go into details here (but would
> > do
> > that in a different thread):
> >  * Why using splicing is very smart to do for Icecast,
> >  * and why it would be smart to have alternatives*.
> 
> I'm curious to read this, although I'm not sure it's within my reach.

Let's see if someone else has interest in it. Maybe I can write
something next weekend (being busy all week I fear).


> Thank you very much for your answer which saves me from wasting more
> time than I have already wasted so unnecessarily.

Exactly why I wanted to answer you swiftly :)

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: 523 bytes
Desc: This is a digitally signed message part
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20210705/699716e9/attachment.sig>

From therealkitman at iinet.net.au  Tue Jul  6 05:22:55 2021
From: therealkitman at iinet.net.au (kit)
Date: Tue, 6 Jul 2021 13:22:55 +0800
Subject: [Icecast] Streaming OGG/Vorbis files dies on track change
In-Reply-To: <00c09e9dd803e59ea8994c43b10ad27a0491c434.camel@de.loewenfelsen.net>
References: <56d82b36-3965-6467-d254-a71a613f31fe@iinet.net.au>
 <a1d1b8e3-b390-4288-1bf4-21a149a00cee@iinet.net.au>
 <00c09e9dd803e59ea8994c43b10ad27a0491c434.camel@de.loewenfelsen.net>
Message-ID: <d30f84ad-68fd-d239-01a8-f02085414d4d@iinet.net.au>

Hi Philipp,

I was concerned about the mountpoint name as well afterwards so now in 
my tests I used stream8001.ogg. But this did not change anything in the 
behaviour as I still had the same issues.

Testing was re-done in a virtual machine and examined the access.log as 
suggested. I can confirm that there is only 1 SOURCE entry for the 
source client at runtime.

EZSTREAM with ogg metadata sent

1/27.0.0.1 - - [06/Jul/2021:12:05:41 +0800] "SOURCE /stream8001.ogg 
HTTP/1.0" 401 331 "-" "libshout/2.4.5" 0//
//10.1.1.20 - - [06/Jul/2021:12:12:34 +0800] "GET /stream8001.ogg 
HTTP/1.1" 200 5648489 "-" "Clementine 1.3.1" 405 <--------Clementine 
dies about 3 minutes after track change. My associate reports that his 
Windows Media Player dies too.//
//10.1.1.20 - - [06/Jul/2021:12:16:36 +0800] "GET /stream8001.ogg 
HTTP/1.1" 200 9865567 "-" "Mozilla/5.0" 623 <----- keeps playing but 
reports the following discontinuity during a track change .../

chris at asus-roc:~> mpv http://10.1.1.41:8001/stream8001.ogg
 ?(+) Audio --aid=1 'All Directions Are Up' (vorbis 2ch 44100Hz)
File tags:
 ?Artist: Cyber Zen Sound Engine
 ?Album: Moonscapes: How Stones Become Enlightened
 ?Album_Artist: Cyber Zen Sound Engine
 ?Genre: Electronica
 ?Title: All Directions Are Up
 ?Track: 1
AO: [jack] 44100Hz stereo 2ch floatp
A: 00:03:34 / 00:03:39 (98%) Cache: 4.6s/165KB
/*[lavf] Linearizing discontinuity: 0.000000 -> 246.296599*//*
*//*[lavf] Linearizing discontinuity: 246.293696 -> 246.296599*/
A: 00:03:39 / 00:03:44 (98%) Cache: 5.0s/157KB
File tags:
 ?Artist: Fanger & Sch?nw?lder
 ?Album: Analog Overdose (Featuring Lutz Ulbrich)
 ?Album_Artist: Fanger & Sch?nw?lder
 ?Genre: Disco
 ?Title: Analog Moods
A: 00:10:21 / 00:10:26 (99%) Cache: 4.6s/266KB

I next used Mixxx to stream Ogg files without metadata - all listening 
clients performed ok during track changes. Naturally those clients could 
not report any track titles/artists.

/127.0.0.1 - - [06/Jul/2021:12:51:26 +0800] "SOURCE /stream8001.ogg 
HTTP/1.0" 401 331 "-" "libshout/2.4.1" 0/

Next Mixxx with ogg metadata was streamed - same problems as the 
EZSTREAM results above.

The Mixxx manual has this nice little mention -

/*Dynamically update Ogg Vorbis metadata*//: Due to flaws in some 
streaming clients, updating Ogg Vorbis metadata dynamically can cause 
listener glitches and disconnections. Check this box to update the 
metadata anyway. Some players that listeners can use have bugs that can 
cause audio glitches or disconnections when the Ogg Vorbis metadata is 
updated dynamically. If this is not a problem, you can enable this 
checkbox./

Since EZSTREAM or Ices can not stream MP3 or OGG (without it's metadata) 
I am ditching them both. MPD+ncmpcpp work nicely last night on a test 
rig streaming MP3 so I am rebuilding my server with those.

But I would still be curious about this issue as to what happened.

Thanks,

Chris.




On 5/7/21 8:04 pm, Philipp Schafft wrote:
> Good afternoon,
>
>
> On Sun, 2021-07-04 at 10:24 +0800, kit wrote:
>> Hi.
>>
>> I'm having issues with streaming OGG/Vorbis files to Icecast. I am
>> using  Ezsteam to stream a playlist of Ogg files from the command
>> line, but  when there is a track change the stream stops in clients
>> like Clementine  and Windows Media Player. MPV client reports a
>> discontinuity but carries on playing.
>>
>> I have also test using Mixxx to stream as Ogg to the same icecast
>> server but it has the same issue. Only B.U.T.T. seems to handle track
>> changes well.
>>
>> This is my mount details from the icecast XML file.
>>
>>       <mount type="normal">
>>           <mount-name>/stream8001</mount-name>
> That is a strange name for a mount.
> Please also keep in mind that some broken players expect Ogg/Vorbis
> streams to have an URI ending with ".ogg". This is NOT a problem of
> Icecast, but of some players. So consider to change this.
>
>
>>           <username>s8001</username>
>>           <password>redacted</password>
>>        </mount>
>>
>> There are no issues with streaming MP3 at all as far as I can see.
>> But since I need to use EZstream OGG format is my only option.
>>
>> I'm looking at MPD+ncmpcpp as an alternative (more reading) but I
>> would  like to stick with Ezstream at this point since I have it
>> running.
>>
>> This track change issue with ogg files seems to be a known issue.
>> But  reading the docs a bit more I wonder if the use of a fallback-
>> mount setting using an ogg file of 5 secs of silence would fix
>> things?
> It depends on what the actual problem is. But I suspect it is not that
> the source client drops the connection. A fallback would only help in
> that case.
>
> You can check this by having a look at your access.log. If it lists one
> SOURCE, or PUT request per track, than this is the problem (and the
> source client is having some issue). If you see only one SOURCE, or PUT
> request for each runtime of the source client, then it does at least
> this correctly.
>
>
> Is there a public URI to your stream so we can have a look?
>
>
> With best regards,
>
>
> _______________________________________________
> Icecast mailing list
> Icecast at xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20210706/3d1ec133/attachment.htm>

From jordan at coolmic.net  Tue Jul  6 18:35:23 2021
From: jordan at coolmic.net (Jordan Erickson)
Date: Tue, 6 Jul 2021 11:35:23 -0700
Subject: [Icecast] Streaming OGG/Vorbis files dies on track change
In-Reply-To: <d30f84ad-68fd-d239-01a8-f02085414d4d@iinet.net.au>
References: <56d82b36-3965-6467-d254-a71a613f31fe@iinet.net.au>
 <a1d1b8e3-b390-4288-1bf4-21a149a00cee@iinet.net.au>
 <00c09e9dd803e59ea8994c43b10ad27a0491c434.camel@de.loewenfelsen.net>
 <d30f84ad-68fd-d239-01a8-f02085414d4d@iinet.net.au>
Message-ID: <ba6e9e07-fa70-5ee9-76b5-494d4f8e8762@coolmic.net>

Hi Kit,

My guess is that it's 1 of 2 things:

1) Your Ogg/Vorbis files are not encoded uniformly (i.e. differing 
smaplerates/quality/num. of channels/etc.)

2) Your files need a trim :) Try this bash script on a sample of problem 
files and see if it helps:

---
#!/bin/bash
#
# Fixes end-of-stream bug with ogg vorbis files so they don't
# cause some players to crash when moving to a new song in the
# stream.
#
for FILE in $(find /path/to/oggfiles -name '*.ogg'); do
    cat /dev/null | vorbiscomment -a $FILE;
done
---


Cheers,
Jordan Erickson


On 7/5/21 10:22 PM, kit wrote:
> Hi Philipp,
> 
> I was concerned about the mountpoint name as well afterwards so now in 
> my tests I used stream8001.ogg. But this did not change anything in the 
> behaviour as I still had the same issues.
> 
> Testing was re-done in a virtual machine and examined the access.log as 
> suggested. I can confirm that there is only 1 SOURCE entry for the 
> source client at runtime.
> 
> EZSTREAM with ogg metadata sent
> 
> 1/27.0.0.1 - - [06/Jul/2021:12:05:41 +0800] "SOURCE /stream8001.ogg 
> HTTP/1.0" 401 331 "-" "libshout/2.4.5" 0//
> //10.1.1.20 - - [06/Jul/2021:12:12:34 +0800] "GET /stream8001.ogg 
> HTTP/1.1" 200 5648489 "-" "Clementine 1.3.1" 405 <--------Clementine 
> dies about 3 minutes after track change. My associate reports that his 
> Windows Media Player dies too.//
> //10.1.1.20 - - [06/Jul/2021:12:16:36 +0800] "GET /stream8001.ogg 
> HTTP/1.1" 200 9865567 "-" "Mozilla/5.0" 623 <----- keeps playing but 
> reports the following discontinuity during a track change .../
> 
> chris at asus-roc:~> mpv http://10.1.1.41:8001/stream8001.ogg
>  ?(+) Audio --aid=1 'All Directions Are Up' (vorbis 2ch 44100Hz)
> File tags:
>  ?Artist: Cyber Zen Sound Engine
>  ?Album: Moonscapes: How Stones Become Enlightened
>  ?Album_Artist: Cyber Zen Sound Engine
>  ?Genre: Electronica
>  ?Title: All Directions Are Up
>  ?Track: 1
> AO: [jack] 44100Hz stereo 2ch floatp
> A: 00:03:34 / 00:03:39 (98%) Cache: 4.6s/165KB
> /*[lavf] Linearizing discontinuity: 0.000000 -> 246.296599*//*
> *//*[lavf] Linearizing discontinuity: 246.293696 -> 246.296599*/
> A: 00:03:39 / 00:03:44 (98%) Cache: 5.0s/157KB
> File tags:
>  ?Artist: Fanger & Sch?nw?lder
>  ?Album: Analog Overdose (Featuring Lutz Ulbrich)
>  ?Album_Artist: Fanger & Sch?nw?lder
>  ?Genre: Disco
>  ?Title: Analog Moods
> A: 00:10:21 / 00:10:26 (99%) Cache: 4.6s/266KB
> 
> I next used Mixxx to stream Ogg files without metadata - all listening 
> clients performed ok during track changes. Naturally those clients could 
> not report any track titles/artists.
> 
> /127.0.0.1 - - [06/Jul/2021:12:51:26 +0800] "SOURCE /stream8001.ogg 
> HTTP/1.0" 401 331 "-" "libshout/2.4.1" 0/
> 
> Next Mixxx with ogg metadata was streamed - same problems as the 
> EZSTREAM results above.
> 
> The Mixxx manual has this nice little mention -
> 
> /*Dynamically update Ogg Vorbis metadata*//: Due to flaws in some 
> streaming clients, updating Ogg Vorbis metadata dynamically can cause 
> listener glitches and disconnections. Check this box to update the 
> metadata anyway. Some players that listeners can use have bugs that can 
> cause audio glitches or disconnections when the Ogg Vorbis metadata is 
> updated dynamically. If this is not a problem, you can enable this 
> checkbox./
> 
> Since EZSTREAM or Ices can not stream MP3 or OGG (without it's metadata) 
> I am ditching them both. MPD+ncmpcpp work nicely last night on a test 
> rig streaming MP3 so I am rebuilding my server with those.
> 
> But I would still be curious about this issue as to what happened.
> 
> Thanks,
> 
> Chris.
> 
> 
> 
> 
> On 5/7/21 8:04 pm, Philipp Schafft wrote:
>> Good afternoon,
>>
>>
>> On Sun, 2021-07-04 at 10:24 +0800, kit wrote:
>>> Hi.
>>>
>>> I'm having issues with streaming OGG/Vorbis files to Icecast. I am
>>> using  Ezsteam to stream a playlist of Ogg files from the command
>>> line, but  when there is a track change the stream stops in clients
>>> like Clementine  and Windows Media Player. MPV client reports a
>>> discontinuity but carries on playing.
>>>
>>> I have also test using Mixxx to stream as Ogg to the same icecast
>>> server but it has the same issue. Only B.U.T.T. seems to handle track
>>> changes well.
>>>
>>> This is my mount details from the icecast XML file.
>>>
>>>       <mount type="normal">
>>>           <mount-name>/stream8001</mount-name>
>> That is a strange name for a mount.
>> Please also keep in mind that some broken players expect Ogg/Vorbis
>> streams to have an URI ending with ".ogg". This is NOT a problem of
>> Icecast, but of some players. So consider to change this.
>>
>>
>>>           <username>s8001</username>
>>>           <password>redacted</password>
>>>        </mount>
>>>
>>> There are no issues with streaming MP3 at all as far as I can see.
>>> But since I need to use EZstream OGG format is my only option.
>>>
>>> I'm looking at MPD+ncmpcpp as an alternative (more reading) but I
>>> would  like to stick with Ezstream at this point since I have it
>>> running.
>>>
>>> This track change issue with ogg files seems to be a known issue.
>>> But  reading the docs a bit more I wonder if the use of a fallback-
>>> mount setting using an ogg file of 5 secs of silence would fix
>>> things?
>> It depends on what the actual problem is. But I suspect it is not that
>> the source client drops the connection. A fallback would only help in
>> that case.
>>
>> You can check this by having a look at your access.log. If it lists one
>> SOURCE, or PUT request per track, than this is the problem (and the
>> source client is having some issue). If you see only one SOURCE, or PUT
>> request for each runtime of the source client, then it does at least
>> this correctly.
>>
>>
>> Is there a public URI to your stream so we can have a look?
>>
>>
>> With best regards,
>>
>>
>> _______________________________________________
>> 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
> 

-- 
--
Cheers,

Jordan Erickson
Cool Mic Project Manager
https://coolmic.net/


From therealkitman at iinet.net.au  Wed Jul  7 00:09:26 2021
From: therealkitman at iinet.net.au (kit)
Date: Wed, 7 Jul 2021 08:09:26 +0800
Subject: [Icecast] Streaming OGG/Vorbis files dies on track change
In-Reply-To: <ba6e9e07-fa70-5ee9-76b5-494d4f8e8762@coolmic.net>
References: <56d82b36-3965-6467-d254-a71a613f31fe@iinet.net.au>
 <a1d1b8e3-b390-4288-1bf4-21a149a00cee@iinet.net.au>
 <00c09e9dd803e59ea8994c43b10ad27a0491c434.camel@de.loewenfelsen.net>
 <d30f84ad-68fd-d239-01a8-f02085414d4d@iinet.net.au>
 <ba6e9e07-fa70-5ee9-76b5-494d4f8e8762@coolmic.net>
Message-ID: <03086893-275c-b6da-6927-24df8da39b68@iinet.net.au>

Hi Jordan,

The oggs vary from 100 to 130 kbps but when sent via Mixxx they are all 
encoded as 128kbps. And trimming the comments made no difference.

Thanks,

Chris.



On 7/7/21 2:35 am, Jordan Erickson wrote:
> Hi Kit,
>
> My guess is that it's 1 of 2 things:
>
> 1) Your Ogg/Vorbis files are not encoded uniformly (i.e. differing 
> smaplerates/quality/num. of channels/etc.)
>
> 2) Your files need a trim :) Try this bash script on a sample of 
> problem files and see if it helps:
>
> ---
> #!/bin/bash
> #
> # Fixes end-of-stream bug with ogg vorbis files so they don't
> # cause some players to crash when moving to a new song in the
> # stream.
> #
> for FILE in $(find /path/to/oggfiles -name '*.ogg'); do
> ?? cat /dev/null | vorbiscomment -a $FILE;
> done
> ---
>
>
> Cheers,
> Jordan Erickson
>
>
> On 7/5/21 10:22 PM, kit wrote:
>> Hi Philipp,
>>
>> I was concerned about the mountpoint name as well afterwards so now 
>> in my tests I used stream8001.ogg. But this did not change anything 
>> in the behaviour as I still had the same issues.
>>
>> Testing was re-done in a virtual machine and examined the access.log 
>> as suggested. I can confirm that there is only 1 SOURCE entry for the 
>> source client at runtime.
>>
>> EZSTREAM with ogg metadata sent
>>
>> 1/27.0.0.1 - - [06/Jul/2021:12:05:41 +0800] "SOURCE /stream8001.ogg 
>> HTTP/1.0" 401 331 "-" "libshout/2.4.5" 0//
>> //10.1.1.20 - - [06/Jul/2021:12:12:34 +0800] "GET /stream8001.ogg 
>> HTTP/1.1" 200 5648489 "-" "Clementine 1.3.1" 405 <--------Clementine 
>> dies about 3 minutes after track change. My associate reports that 
>> his Windows Media Player dies too.//
>> //10.1.1.20 - - [06/Jul/2021:12:16:36 +0800] "GET /stream8001.ogg 
>> HTTP/1.1" 200 9865567 "-" "Mozilla/5.0" 623 <----- keeps playing but 
>> reports the following discontinuity during a track change .../
>>
>> chris at asus-roc:~> mpv http://10.1.1.41:8001/stream8001.ogg
>> ??(+) Audio --aid=1 'All Directions Are Up' (vorbis 2ch 44100Hz)
>> File tags:
>> ??Artist: Cyber Zen Sound Engine
>> ??Album: Moonscapes: How Stones Become Enlightened
>> ??Album_Artist: Cyber Zen Sound Engine
>> ??Genre: Electronica
>> ??Title: All Directions Are Up
>> ??Track: 1
>> AO: [jack] 44100Hz stereo 2ch floatp
>> A: 00:03:34 / 00:03:39 (98%) Cache: 4.6s/165KB
>> /*[lavf] Linearizing discontinuity: 0.000000 -> 246.296599*//*
>> *//*[lavf] Linearizing discontinuity: 246.293696 -> 246.296599*/
>> A: 00:03:39 / 00:03:44 (98%) Cache: 5.0s/157KB
>> File tags:
>> ??Artist: Fanger & Sch?nw?lder
>> ??Album: Analog Overdose (Featuring Lutz Ulbrich)
>> ??Album_Artist: Fanger & Sch?nw?lder
>> ??Genre: Disco
>> ??Title: Analog Moods
>> A: 00:10:21 / 00:10:26 (99%) Cache: 4.6s/266KB
>>
>> I next used Mixxx to stream Ogg files without metadata - all 
>> listening clients performed ok during track changes. Naturally those 
>> clients could not report any track titles/artists.
>>
>> /127.0.0.1 - - [06/Jul/2021:12:51:26 +0800] "SOURCE /stream8001.ogg 
>> HTTP/1.0" 401 331 "-" "libshout/2.4.1" 0/
>>
>> Next Mixxx with ogg metadata was streamed - same problems as the 
>> EZSTREAM results above.
>>
>> The Mixxx manual has this nice little mention -
>>
>> /*Dynamically update Ogg Vorbis metadata*//: Due to flaws in some 
>> streaming clients, updating Ogg Vorbis metadata dynamically can cause 
>> listener glitches and disconnections. Check this box to update the 
>> metadata anyway. Some players that listeners can use have bugs that 
>> can cause audio glitches or disconnections when the Ogg Vorbis 
>> metadata is updated dynamically. If this is not a problem, you can 
>> enable this checkbox./
>>
>> Since EZSTREAM or Ices can not stream MP3 or OGG (without it's 
>> metadata) I am ditching them both. MPD+ncmpcpp work nicely last night 
>> on a test rig streaming MP3 so I am rebuilding my server with those.
>>
>> But I would still be curious about this issue as to what happened.
>>
>> Thanks,
>>
>> Chris.
>>
>>
>>
>>
>> On 5/7/21 8:04 pm, Philipp Schafft wrote:
>>> Good afternoon,
>>>
>>>
>>> On Sun, 2021-07-04 at 10:24 +0800, kit wrote:
>>>> Hi.
>>>>
>>>> I'm having issues with streaming OGG/Vorbis files to Icecast. I am
>>>> using? Ezsteam to stream a playlist of Ogg files from the command
>>>> line, but? when there is a track change the stream stops in clients
>>>> like Clementine? and Windows Media Player. MPV client reports a
>>>> discontinuity but carries on playing.
>>>>
>>>> I have also test using Mixxx to stream as Ogg to the same icecast
>>>> server but it has the same issue. Only B.U.T.T. seems to handle track
>>>> changes well.
>>>>
>>>> This is my mount details from the icecast XML file.
>>>>
>>>> ????? <mount type="normal">
>>>> ????????? <mount-name>/stream8001</mount-name>
>>> That is a strange name for a mount.
>>> Please also keep in mind that some broken players expect Ogg/Vorbis
>>> streams to have an URI ending with ".ogg". This is NOT a problem of
>>> Icecast, but of some players. So consider to change this.
>>>
>>>
>>>> <username>s8001</username>
>>>> ????????? <password>redacted</password>
>>>> ?????? </mount>
>>>>
>>>> There are no issues with streaming MP3 at all as far as I can see.
>>>> But since I need to use EZstream OGG format is my only option.
>>>>
>>>> I'm looking at MPD+ncmpcpp as an alternative (more reading) but I
>>>> would? like to stick with Ezstream at this point since I have it
>>>> running.
>>>>
>>>> This track change issue with ogg files seems to be a known issue.
>>>> But? reading the docs a bit more I wonder if the use of a fallback-
>>>> mount setting using an ogg file of 5 secs of silence would fix
>>>> things?
>>> It depends on what the actual problem is. But I suspect it is not that
>>> the source client drops the connection. A fallback would only help in
>>> that case.
>>>
>>> You can check this by having a look at your access.log. If it lists one
>>> SOURCE, or PUT request per track, than this is the problem (and the
>>> source client is having some issue). If you see only one SOURCE, or PUT
>>> request for each runtime of the source client, then it does at least
>>> this correctly.
>>>
>>>
>>> Is there a public URI to your stream so we can have a look?
>>>
>>>
>>> With best regards,
>>>
>>>
>>> _______________________________________________
>>> 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 correu at pauibars.cat  Fri Jul 23 10:37:56 2021
From: correu at pauibars.cat (Pau Ibars Verdaguer)
Date: Fri, 23 Jul 2021 12:37:56 +0200
Subject: [Icecast] Live Dahua cam with ffmpeg to Icecast
Message-ID: <f85389af-6058-8d24-8b54-8d81c91d0725@pauibars.cat>

Hello!

First of all, thank you for any help that you can give me, and sorry if
this is not the place to do this questions

I've worked some years with shoutcast streaming a local radio of my
town, but never streaming video. Now I'm trying to stream the live video
of a Dahua security cam as a panoramic cam of our town, but I'm not sure
if I'm in the correct way.

At the moment, I can send the image to Youtube channel with ffmpeg

ffmpeg -f lavfi -i anullsrc -rtsp_transport tcp -thread_queue_size 300
-r 25 -i
"rtsp:///user:password/@192.168.1.10:554/cam/realmonitor?channel=1&subtype=00"
-force_key_frames "expr:gte(t,n_forced*4)" -pix_fmt yuv420p -preset
veryfast -vf scale=2560:1440 -reorder_queue_size 4000 -max_delay
10000000 -vcodec libx264 -b:v 9500k -f flv
rtmp:/x.rtmp.youtube.com/live2//youtube_key/

I've been trying to send video to icecast with ffmpeg with some options
of this command, but I get errors any time.

[NULL @ 0x555e591ecc80] Unable to find a suitable output format for
'icecast:///user:password/@localhost:8000/stream'
icecast://admin:Sky1sblu3!@localhost:8000/stream: Invalid argument

Anyone can guide me with the way to send this video to the icecast server?

Thank you in advance.

Pau.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20210723/c12a10c0/attachment.htm>

From michael at michaelzfreeman.org  Sat Jul 24 18:08:23 2021
From: michael at michaelzfreeman.org (Michael Z Freeman)
Date: Sat, 24 Jul 2021 18:08:23 +0000
Subject: [Icecast] Need help with streaming multiple file types and bitrates
Message-ID: <em9055ddcf-5a26-44b0-9e93-2370616adf41@desktop-s6594a5>

Hi,

I have icecast2 setup on my home Ubuntu machine for testing. But I need 
pointing in the right direction.

I have a group of flac and mp3 audio files (dj mixes). The flacs should 
be consistent but the mp3's have varying bitrates from 160 to 256 kbps.

Is there a way to make a contiguous stream from these files that does 
not lose any quality, or is at least a minimal loss of quality ?

Or would I have to convert (transcode) the whole thing to a flac stream 
?

Would appreciate any help.

Michael Z Freeman
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20210724/2de3a369/attachment.htm>

From lr at pripple.de  Sat Jul 24 18:45:02 2021
From: lr at pripple.de (Lorenz Reichelt)
Date: Sat, 24 Jul 2021 20:45:02 +0200
Subject: [Icecast] Need help with streaming multiple file types and
 bitrates
In-Reply-To: <em9055ddcf-5a26-44b0-9e93-2370616adf41@desktop-s6594a5>
References: <em9055ddcf-5a26-44b0-9e93-2370616adf41@desktop-s6594a5>
Message-ID: <030EDF83-0EBE-4E7B-8B63-7F2283FD712A@pripple.de>

Hi :) So running it all through ezstream and outputting a flac stream to icecast is not your preferred option, is it? Just to clarify. How are you streaming the files? Best

From michael at michaelzfreeman.org  Sun Jul 25 10:33:58 2021
From: michael at michaelzfreeman.org (Michael Z Freeman)
Date: Sun, 25 Jul 2021 10:33:58 +0000
Subject: [Icecast] Need help with streaming multiple file types and
 bitrates
In-Reply-To: <030EDF83-0EBE-4E7B-8B63-7F2283FD712A@pripple.de>
References: <em9055ddcf-5a26-44b0-9e93-2370616adf41@desktop-s6594a5>
 <030EDF83-0EBE-4E7B-8B63-7F2283FD712A@pripple.de>
Message-ID: <em704f3f35-ae2e-4539-9b89-b16102af9fbd@desktop-s6594a5>

Hi,

I'm using Liquidsoap. I have some DJ mixes (originally from C90 tape) 
that vary in bitrate. I could have a separate mount point for each mix 
but want to create a radio station like format with each mix playing one 
after another (with a jingle between each one or over quiet parts). So 
is there a way of doing that; playing one mix after another, with 
bitrate varying sometimes, without transcoding ? Looking at it I don't 
think there is but thought I'd ask anyway.

Cheers

Michael

------ Original Message ------
From: "Lorenz Reichelt" <lr at pripple.de>
To: "Michael Z Freeman" <michael at michaelzfreeman.org>; "Icecast 
streaming server user discussions" <icecast at xiph.org>
Sent: 24/07/2021 19:45:02
Subject: Re: [Icecast] Need help with streaming multiple file types and 
bitrates

>Hi :) So running it all through ezstream and outputting a flac stream to icecast is not your preferred option, is it? Just to clarify. How are you streaming the files? Best



From petr.pisar at atlas.cz  Sun Jul 25 12:36:11 2021
From: petr.pisar at atlas.cz (Petr Pisar)
Date: Sun, 25 Jul 2021 14:36:11 +0200
Subject: [Icecast] Need help with streaming multiple file types and
 bitrates
In-Reply-To: <em704f3f35-ae2e-4539-9b89-b16102af9fbd@desktop-s6594a5>
References: <em9055ddcf-5a26-44b0-9e93-2370616adf41@desktop-s6594a5>
 <030EDF83-0EBE-4E7B-8B63-7F2283FD712A@pripple.de>
 <em704f3f35-ae2e-4539-9b89-b16102af9fbd@desktop-s6594a5>
Message-ID: <YP1auwEZhBcnsA97@album.bayer.uni.cx>

V?Sun, Jul 25, 2021 at 10:33:58AM +0000,?Michael Z Freeman napsal(a):
> I'm using Liquidsoap. I have some DJ mixes (originally from C90 tape) 
> that vary in bitrate. I could have a separate mount point for each mix 
> but want to create a radio station like format with each mix playing one 
> after another (with a jingle between each one or over quiet parts). So 
> is there a way of doing that; playing one mix after another, with 
> bitrate varying sometimes, without transcoding ? Looking at it I don't 
> think there is but thought I'd ask anyway.
> 
It's rather a matter of the client than Icecast. Icecast blindy forwards
a bit stream. If your client can cope with a stream which changes bitrate
between MP3 frames, then you will be fine.

I just made a test: I created two files, one 32-bkps and another 128-kbps MP3
file. I setup ezstream-0.6.0 to stream them in a loop without reencoding into
an Icecast server, and used mpv (ffmpeg-based) and mpg123 (an independ MP3
decoder implementation) without any problems. I saved a stream reproducing
3 loops of the 2 files and verified that the stream size is roughly
equivalent to a tripple of a sum of the two file sizes. Hence indeed no
recoding was performed.

-- Petr
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20210725/7b1b4c50/attachment.sig>

From michael at michaelzfreeman.org  Tue Jul 27 08:39:32 2021
From: michael at michaelzfreeman.org (Michael Z Freeman)
Date: Tue, 27 Jul 2021 08:39:32 +0000
Subject: [Icecast] Need help with streaming multiple file types and
 bitrates
In-Reply-To: <YP1auwEZhBcnsA97@album.bayer.uni.cx>
References: <em9055ddcf-5a26-44b0-9e93-2370616adf41@desktop-s6594a5>
 <030EDF83-0EBE-4E7B-8B63-7F2283FD712A@pripple.de>
 <em704f3f35-ae2e-4539-9b89-b16102af9fbd@desktop-s6594a5>
 <YP1auwEZhBcnsA97@album.bayer.uni.cx>
Message-ID: <em79974602-4cda-4855-b081-b27e948d0759@desktop-s6594a5>

Thanks everyone.

So it's possible but it looks like I'd need to do some testing with 
various clients.

For the moment I'll stick to a 320kbps stream and maybe an alternative 
flac one.

------ Original Message ------
From: "Petr Pisar" <petr.pisar at atlas.cz>
To: icecast at xiph.org
Sent: 25/07/2021 13:36:11
Subject: Re: [Icecast] Need help with streaming multiple file types and 
bitrates

>V Sun, Jul 25, 2021 at 10:33:58AM +0000, Michael Z Freeman napsal(a):
>>  I'm using Liquidsoap. I have some DJ mixes (originally from C90 tape)
>>  that vary in bitrate. I could have a separate mount point for each mix
>>  but want to create a radio station like format with each mix playing one
>>  after another (with a jingle between each one or over quiet parts). So
>>  is there a way of doing that; playing one mix after another, with
>>  bitrate varying sometimes, without transcoding ? Looking at it I don't
>>  think there is but thought I'd ask anyway.
>>
>It's rather a matter of the client than Icecast. Icecast blindy forwards
>a bit stream. If your client can cope with a stream which changes bitrate
>between MP3 frames, then you will be fine.
>
>I just made a test: I created two files, one 32-bkps and another 128-kbps MP3
>file. I setup ezstream-0.6.0 to stream them in a loop without reencoding into
>an Icecast server, and used mpv (ffmpeg-based) and mpg123 (an independ MP3
>decoder implementation) without any problems. I saved a stream reproducing
>3 loops of the 2 files and verified that the stream size is roughly
>equivalent to a tripple of a sum of the two file sizes. Hence indeed no
>recoding was performed.
>
>-- Petr
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20210727/ab1ba4ff/attachment.htm>