That stream is marked as a "live" stream and at 256kbps which means you must have a sustained 256kbps data stream from the source with no gaps. Since the stream is live if the network cannot deliver packets in time then source will drop packets because stream is live and realtime.
What happens is mplayer has a cache which is set at 128k for AlienBBC. The decoder has to decode packets at steady rate to play back at 256kbps - if the source doesn't deliver enough packets then data is taken from the cache but since the stream is live the cache can never be replenished so as packets are not delivered, the cache slowly depletes until it is empty - the mplayer will play packets as they arrive which means gaps which are sometimes played as silence and for short gaps, packets are repeated. I tested the stream with a 4Mbytes cache and it played for a good while but depletion started after about 15 mins. You should run a test on a command line like this mplayer -cache 800 rtsp://160.36.178.159/broadcast/wuot.rm The display will show a running count - the last % is the cache buffer fullness - it should normally stay at about 18% using lame etc is no use since it is after the fact - mplayer has to deliver a proper WAV stream and it cannot because the network cannot deliver the packets at a consistent rate. -- bpa ------------------------------------------------------------------------ bpa's Profile: http://forums.slimdevices.com/member.php?userid=1806 View this thread: http://forums.slimdevices.com/showthread.php?t=35084 _______________________________________________ plugins mailing list [email protected] http://lists.slimdevices.com/lists/listinfo/plugins
