[icecast-dev] Streaming with ices2/linux

[Michael Smith]

On Thursday 06 November 2003 11:53, Melanie wrote:
> Hi,
>
>   I have observed a problem when streaming with ices2. When only silence is
> transmitted, like pauses in an interview, the bitrate drops to 0. This
> happens even when a minimum bitrate is set.
> Now, assume there is a half block of audio ready. Now the level drops to
> silence, or near silence, possibly because the person is thinking about an
> answer for a while.
> This will cause the partial block to not be transmitted in time for the
> client to produce continuos audio. Also, the client can, if this happens
> more often, incur some very serious lag over time.
>
> What needs to be done, IMHO, is to guarantee that data is sent at least as
> fast as the playback of the data will take. So, if there is silence,
> smaller blocks must be sent, because a length of music and an equal length
> of silence will be encoded in a different number of bytes. Each block of
> data being collected, waiting for transmission, neds a deadline attached to
> it which is the time between the sending of the last block and the time it
> would finish playing. So, if a block is sent that encodes 2 seconds of
> audio, the next block must be sent no more than 2 seconds later. Even if
> it's only the few bytes needed to tell the client to play another 2 seconds
> of silence.

Melanie,

ices2 assumes some client-side buffering: this is generally reasonable, all 
the clients I know of perform some buffering. Under this assumption, you 
needn't adhere precisely to the restrictions you describe here - and ices2 
does not.

>
> I haven't read the code, but it appears that blocks are sent when a certain
> byte count is reached. This is fine for continuous audio, but if there is
> silence involved, it's just not enough.

This is the normal case. There's also a threshold - if no audio has been sent 
for some period of time (currently 2 seconds - it should be made 
configurable). (this is for live input only, of course). I added this to 
solve precisely the problem you describe - I'm not sure why it isn't working 
for you, unless you're trying to use a client which doesn't buffer at all.

>
> A functioning minimum bitrate would also solve this problem, at the cost of
> bandwidth, but that's not available either. The minimum bitrate parameter
> is seemingly ignored, even though the ices2 startup messges do print it
> out, meaning it's recognized from the config file.

Minimum bitrate just forces a minimum on what the encoder will select to 
encode - it will not deliberately insert padding when there is no additional 
data to encode, but is not actually ignored.

Not sure why this isn't working for you, anyway - perhaps you could 
investigate? The threshold-sending is done in src/encode.c:encode_dataout().

Mike

--- >8 ----
List archives:  http://www.xiph.org/archives/
icecast project homepage: http://www.icecast.org/
To unsubscribe from this list, send a message to 'icecast-dev-request at xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.