▲

[GTHvidsten]

Unfortunately "-flush_packets 1" had no effect

[Ian @ un4seen]

It looks like FFMPEG also has a "-fflags +flush_packets" option that you could try. If that doesn't help either, to confirm whether the "-flush_packets 1" or "-fflags +flush_packets" option is having any effect at all, you could log and compare the EncodeProcDataReceived function's "length" parameter values that you get with and without them. You could also check what values you get when using LAME for comparison.

[GTHvidsten]

I followed your advice to log the length of the data received in EncodeProcDataReceived and compare ffmpeg to lame.
I can see that ffmpeg with or without the "flush_packets" (either variant) does not vary radically... but compared to lame there's a significant difference.

Here's a sample from ffmpeg: 418, 1254, 835, 1254
Here's a sample from lame: 4096, 4096, 4096, 4096

Quite the difference, and quite the hint as to what might be going on.
I've tried to find a setting to force ffmpeg to always output packages of 4096 bytes, but I haven't found such a setting quite yet (been googling for an hour now).

I've found many packet size settings for various muxers, but non that seem valid for mp3 / adts, so if you know of any way to force the "packet size" in ffmpeg for mp3/adts I'll gladly test it

[GTHvidsten]

If these buffer sizes are indeed the problem, maybe the BassEnc.BASS_Encode_CastInit() could have an optional setting to buffer on its own and only send 4096 blocks to Shoutcast?

[Ian @ un4seen]

I followed your advice to log the length of the data received in EncodeProcDataReceived and compare ffmpeg to lame.
I can see that ffmpeg with or without the "flush_packets" (either variant) does not vary radically... but compared to lame there's a significant difference.

Here's a sample from ffmpeg: 418, 1254, 835, 1254
Here's a sample from lame: 4096, 4096, 4096, 4096

That actually looks the opposite of what I was theorising

It seems LAME is buffering the output and FFMPEG isn't. So perhaps the solution is to enable buffering in FFMPEG. It looks like "-flush_packets 0" should do that.

[GTHvidsten]

Yes! "-flush_packets 0" produced much bigger packages that Shoutcast didn't complain about. The data length received with this setting now looks like this:

10000, 2768, 10000, 10000, 10000, 2768, 8904

So the data is generally much longer (by a factor of 2.5x), but it seems Shoutcast is much happier with this, even though there are data received that is less than 4096.

So I guess the data received much be of a certain length for Shoutcast to accept it.
Maybe BassEnc.BASS_Encode_CastInit() should still have some internal buffering to ensure a certain (configurable) minimum data length, as I guess there could be other encoders that could also provoke this error (and that may not have something akin to "-flush_packets 0"). Though it's not needed for me right now it might be good for the future.

All in all, thanks for the help with the troubleshooting

[Ian @ un4seen]

I had a little try of this myself and found that it seems to be FFMPEG's ID3v2 tag (sent before the MP3 data) that the Shoutcast server doesn't like. Interestingly, older Shoutcast server versions don't seem to have a problem with it. FFMPEG's ID3v2 tag can be disabled with "-id3v2_version 0".

[radio42]

Might I ask, why you don't use the Broadcast halper class in BASS.NET?
See here: https://www.radio42.com/bass/help/html/b8533cef-2485-af79-61aa-1b4a637099b9.htm
at the bottom is an example given...

[GTHvidsten]

I had a little try of this myself and found that it seems to be FFMPEG's ID3v2 tag (sent before the MP3 data) that the Shoutcast server doesn't like. Interestingly, older Shoutcast server versions don't seem to have a problem with it. FFMPEG's ID3v2 tag can be disabled with "-id3v2_version 0".

That's interesting. If I return to ffmpeg I'll give this a try

Might I ask, why you don't use the Broadcast halper class in BASS.NET?
See here: https://www.radio42.com/bass/help/html/b8533cef-2485-af79-61aa-1b4a637099b9.htm
at the bottom is an example given...

I tried to be streaming server agnostic, and the Broadcast class needs either a Shoucast or an Icecast instance, and I didn't know which one I needed, so I used the more generic one.