Rebuffering

[nnmk]

Hi guys,

what to set in FMS config files to help me with rebuffering on client side?

The player (flash, rtmp) rebuffers a lot (approx. twice a minute) with no good reason - i've tried several players with various buffer settings, clients and server have sufficient bandwidth for the stream (live streaming) - so i guess this can be helped server side - can it and how?

Please help.

[Patel_Bharat]

I think the information would be helpful to you:

http://www.adobe.com/devnet/flashmediaserver/articles/fms_dual_buffering.html

[nnmk]

Thanks...

Although i expected that some fms config server side can be helpfull for standard buffering - so, nothing in fms configs?

[Patel_Bharat]

Yes, there is nothing like config at FMS server side to define buffering setting.

[nnmk]

So, no settings in Application or Server.xml or other config(uration) files has anything to do with buffering - this is wrong i think...

[Guest]

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.

[nnmk]

I do understand that but when you have continous problems with rebuffering on various players and with various buffer settings and with enough bandwidth - you can only ask yourself - is something wrong with my server configuration...

Hence the question.

[Guest]

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.

[Patel_Bharat]

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.