Help: Understanding server-side buffer for live dynamic streaming

Question

Hi,this is my first post but i hope you guys can help me out in any way.Finding faults in my reasoning, or expanding the discussion further.We are benchmarking FMS 3.5.x for live dynamic streaming and we have run across an issue.When throttling the client from a high bandwidth (1500kbps) to a low bandwidth (325kbps) via a bandwidth shaper (a physical firewall) it takes a very long (real-) time for the client to see the new stream-quality.During the investigation of this issue we have narrowed this down to:1. when transition is requested from client, the client-side buffer is 1/2 i.e. 4-5seconds.2. if transition is request on a client with unlimited bandwidth, it takes about 6 seconds for the server to process, find an acceptable switching position and send a "transition.complete" event.3. on the throttled client however, this event takes much longer.4. when really closely examining what happens between throttled request and throttled "transition.complete" it seems that the client is sent about 16 seconds of high-quality video before the low-quality is starting to download.5. ofcourse, if the client has low-bw these 16 seconds may take 32-64 seconds to load!6. Narrowing this issue down, it seems that these 16 seconds are built up like so: [REMAINING TO FILL CLIENT BUFFER TO DEFAULT 10s] + [TIME TO FIND KEYFRAME FOR SWITCHING POINT].7. this in turn tells us that the server probably holds a certain amount of video in its own server-side cache. The size of this is at least 10 seconds.8. when client stalls because of "buffer.empty", it expands the buffer to 30 seconds, meaning it lags 30 seconds behind "realtime".9. when throttling a client with 30 seconds in the buffer, then un-throttling when the client is down to 5 seconds, the client is able to recover all of the 30 seconds in about 4-5 seconds.10. this implies the sever-side buffer can hold up to 30 seconds of live video in some form of buffer/cache.Our current questions:11. It sounds illogical that the server-side buffer can be almost 30 seconds. Might this not be a network- or other buffer somewhere?12. The "16" seconds of high-quality video that needs to be pushed out, wouldn't it be better that all of this video be discarded and replaced with lower quality? Our first thoughts were that this is how it works, but the testing says otherwise.Please, this was a long post, but if you have ANY thoughts about ANY of the points, please leave a comment!/Jonas

techeye · Answer

Well the fundamental issue here is the network constraint imposed. Why would someone have a 1500 kpbs stream when only 325 is allowed permitted? Why not determine the bw capabilities and work with a bitrate that can be sustained by it?

That said, in your pathelogical case, the long time of the transition could be due to lots of things. Firstly there is a notion of outgoing messages in the server queue, which operate on a relative time for playback. Because of the network constraints the buffered serverside messages are in a pending state, and because they are of a higher bit rate they are of course larger. Now take into account the nature of TCP (reliable delivery) where those pending messages have yet to be sent prior to the transition point being activated via the client. These tcp retransmissions are more than likely the cause of your situation.

Also going from 1500 to 325 is a huge difference (almost 5x) which seems to be mathematically in line with your timings (6 seconds with unlimited 30+ seconds (where 6*5 = 30) with restricted bw; much of which is probably TCP retransmissions). Try a tiered approach ie 250 -> 325 -> 500 and see how well the transitions perform.

Really though, I don't understand why one would even try shoving a 1500 bitrate file through a pipe that can't handle that amound of traffic. I can't help but ask how this use case fits into your deployment / production strategy.

Sign up

To post, reply, or follow discussions, please sign in with your Adobe ID.

Sign in to Adobe Community

To post, reply, or follow discussions, please sign in with your Adobe ID.

Scanning file for viruses.

This file cannot be downloaded