No... that's correct. You buffer on the client side, not on the server side.
The server will (to some extent) maintain a queue of data packets for each client in the event that the client is too slow to receive packets in a timely manner, but buffering (in the context of your query) is done entirely on the client side.
Well, let's consider all of the possible factors:
1. Available bandwidth at the server. If you're certain that's not an issue, next:
2. Available upstream bandwidth at the encoding location. If you're certain that's not an issue, next:
3. Line quality between the encoder and the server. if a lot of packets are getting lost, or latency is high between the encoder and the server, transmission from the encoder to the server can suffer. If you're certain that's not an issue, next:
4. Available downstream bandwidth at the subscribing client (the player). . If you're certain that's not an issue, next:
5. Line quality between the server and the subscribing client. Again, if a lot of packets are getting lost, or latency is high between the client and the server, frequent buffering isn't unexpected. If you're certain that's not an issue, it's time to look at the player code.
It would be helpful to know what you're using for encoding your live streams, and what encoder settings you're using.
The size of the buffer depends on two factors:
Desired latency: The larger the buffer, the longer it takes for the stream to start.
Stream stability: Larger buffers allow the stream to deal with noise and interruptions better on the network. Making
the buffer bigger increases the chance that the stream will play through without any stutters, gaps, or other interruptions.
These two factors are conflicting: Ideally the stream should both start quickly and be stable. One way to deal with this situation is to have two different buffer settings, one for when the stream starts and one for when the playback is in progress. This strategy significantly reduces the conflict. It allows a small buffer to be set for fast start, and a longer one to be used to ensure stream stability when playback begins. Because network issues can still affect the initial buffer size, the initial buffer size cannot be arbitrarily small.
Live applications that use the Live Aggregate Messages feature on Flash Media Server to improve performance need to use a buffer that is at least as long as the delay introduced by the live aggregation. The delay is 500ms (0.5s) by default but can be configured on a per-application basis. If the buffer isn't long enough, the stream will not play back smoothly.
For dynamic bitrate switching, Adobe recommends using a buffer length value that is equal to the keyframe frequency of the encoded video.