Bugzilla – Bug 4266
Bitrate limiting does not work for MP3 streams
Last modified: 2008-12-15 13:07:40 UTC
If you set a bitrate limit of say 64 for a Player and then select an MP3 stream of say 96k - the stream is handled as a direct stream still at 96 and no Lame process is setup (also stream stay playing when slimserver is stopped). Bitrate limiting works for WMA streams on stream which are direct when no bitrate limit is set. I think bug has a side effect of making my AACplus support (see Wiki) break with bitrate limit. It worked in 6.3.1 now while AACplus support works ok when no itrate limit is set - when bitrate limit is set - a direct stream to player is stopped because aacplus format is not supported.
it was designed for local files, streaming to remote clients from slimserver. it is not involved in direct streaming becuase that is a connection from the client to the internet radio stream directly. slimserver is taken out of the loop.
I know this is not major but it is a change in functionality from 6.3.1. The behaviour is inconsistent - WMA streams which can be handled directly get bitrate converted whereas MP3 streams don't. The original problem was to do with my AACplus support not working with bit rate limiting. In the sub canDirectStream in file /Slim/Player/Protocols/HTTP.pm - line 189 if (defined $command && $command eq '-' || $format eq 'mp3') { The "|| $format eq 'mp3'" seems to overide any bitrate conversion and makes sure direct streaming happens. When I remove this test - MP3 stations with low bitrates do not start lame. - MP3 stations with high bit rates lame is started but no sound comes from SB. Also without the mp3 test - my AACplus works OK. This change seems to fix the problem but I don't know what side effects there are removing this test as it was clearly put in there for a reason.
Andy, do you have an opinion on the fix Bryan proposes? Or is this something I should talk to Dan about?
I will have to take a look at this. We only recently have had good bitrate detection for remote mp3 streams, so if this worked at all in the past it must have just been sending all streams through lame regardless of the bitrate. What's the use case here? Do you use SlimServer to transcode streams which are then sent over a modem or something? Not sure I see the benefit to limiting an mp3 stream which is at most 128k (or in very rare cases 160 or 192).
The original problem was with AACplus with bitrate limiting in this thread http://forums.slimdevices.com/showthread.php?t=27996 AACplus uses the same protocol as the standard MP3 stream except a different encoding of the data. My solution was to use mplayer to handle the decoding - it is described in the Wiki entry AACplus. Although my solution fixes the aacplus problem, it still has a problem with changing the bit rate of a MP3 stream to a lower value - so this solution is not fully correct and the "offending" test has the look of a patch to fix some other problem so I am loathe to remove/alter it. I am not familiar enough with the code to locate the remaining MP3 problem - give me a few pointers and I may get a complete solution. Personally I am not using bitrate limiting and I think it is unnecessary to apply bitrate limit on an AACplus stream when the user need only handle the situation with a FileType setting. However a user has got used to this functionality in 6.3 and expected it in 6.5. Users also expect similar functionality if bitrate limiting works for WMA and RealAudio streams why not MP3 and AACplus ? I would not be upset by restricting bit rate limiting to file based audio only. That said I can see a case where some user provide complete access to their slimserver systems over the internet and use bitrate limiting to minimise bandwidth.
Does bitrate limiting really work for WMA, or are you referring to the recently added alternate bitrate support?
I just did some checking. Bit rate limiting works for 6.5.0 release and even with 6.5.1 SVN updates it worked up to 2-3 days ago. However with recent 6.5.1 updates, bit rate limiting no longer works - in fact no sound. I reverted back to 6.5.0 to check and it did work. Between each run I delete all Cache files. I have a Suse system with mplayer providing Server WMA decoding for Softsqueeze - when bit rate limiting is on mplayer & lame startup and stream to the SB3. I'll look tomorrow to see what update has changed the behaviour. I should double check the above finding as it is late here and I may have made some mistake.
I repeated the test of trying to listen on an SB3 to a WMA stream (BBC7 from slimpicks) with bit rate limit set to 64kpbs. I have Suse system where mplayer will do server side decoding of WMA. I tested SVN builds using dates from 1-7th October. Except for the 5th Oct when the BBC7 WMA stream was played - SS started up mplayer and lame and SS sent silence and transfers blocks of data (noted using d_source_v). The 5th Oct build tried to start a direct stream but nothing happened - no sound. The current build of Slimserver 10260 - when SB3 player has limit of 64kbps set, Mplayer and Lame are used for WMA stream but a 128kbit MP3 stream (www.somafm.com/illstreet.pls) is played directly - no lame.
Andy, do you want this bug or shall I assign it to Dan?
You can assign it to me. I still would like to hear what Bryan needs this for. :)
The original problem was reported with AACplus with bitrate limiting in this thread http://forums.slimdevices.com/showthread.php?t=27996 I personally don't need bit rate limiting on streams but Ramage seems to use it (in fact I'm not sure about its practicality since most AACPlus stream also have a lower rate MP3 stream) In investigating the AACplus I found that bit rate limiting did not apply to MP3 streams either and I think AACplus problem is related to this fact. This problem has just appeared in 6.5. When checking the problem further, it seems that the implementation of bit rate limiting with direct stream is not consistent. You can apply bit rate limit to WMA stream but not to MP3 streams. I'll help to fix this but I think it needs to be clarified whether bit rate limiting should apply to streams or not ?
(In reply to comment #10) > You can assign it to me. I still would like to hear what Bryan needs this for. > :) > Well I (for one) need this desperately. I have slimserver installed on my Linux dedicated Web server and while unrestricted streaming works occasionally it breaks up quite often due to bandwidth limit of my internet connection. When I switch on the bit rate limiting everything works with exception of WMA and AACPlus as Bryan mentioned. I'm desperate to have this sorted.
Any news?
I'm going to punt on this for 7.0. Alan may also be interested in this one as part of his refactoring work.
shoutcast does list some 192 and 256 streams in the top 500. even some 320's outside of the top 500. since u can now force a SB to use SS for net radio, and since i doubt a SB handles big streams well by itself directly, i can see where some users would want this.
I have a player with marginal wireless connectivity. Bitrate limiting of remote streams is useful in this case.
Fixed (if that is the correct term) as part of the Transcoding changes.
This bug appears to have been fixed in the latest release! If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look. Make sure to include the version number of the software you are seeing the error with.