fms 官方对视频流的描述
个人感觉含金量比较高，在此记录：
Video Lag/Synch Issues
The video is choppy, slow, or audio is out of sync.
CPU, memory or network limits may have been reached. Video and audio lag and de-synchronization can also be caused by poor encoding practices, excessively high bit rates or poorly architected applications.
If a server’s CPU becomes heavily loaded, new processes will increasingly queue up, increasing wait times and latency. Multi-core, multi-thread processors perform better than single-core processors, of course, but CPU overload can still occur when all cores are consistently at high utilization.
Physical memory can begin to run out when a large number of unique videos are requested or shared object usage is heavy, requiring memory to be paged, which is very slow and inefficient, and can even cause the server to crash.
Networking limitations can also become an issue when streaming large amounts of video. If the server’s network card is saturated, packets may be dropped and streaming performance will suffer. Multiple network cards can help balance the network load and increase the server’s streaming capacity.
Proper encoding practices are absolutely essential to ensure smooth video playback.
If the bit rate is too high, the server or the client may not be able to handle the bandwidth, resulting in choppy playback. In addition, it is recommended that streaming video be encoded using constant bit rate (CBR). Using the Dynamic Streaming feature in FMS 3.5 can also improve overall QoS by detecting the viewer’s bandwidth and serving them a stream at the appropriate bit rate, dynamically adjusting to their current network conditions.
Proper application architecture is critical to ensuring optimized server performance. A poorly coded client application can cause excessive CPU usage, inefficient memory allocation, and general poor performance. For example, it is important to avoid unnecessary loops, properly enable and disable event listeners, and close streams when they are no longer needed.
Video Lag/Synch Issues
My live stream is lagging by several seconds.
Live stream publishing issues are usually due to insufficient bandwidth from the publisher to the server. It is recommended that you publish over the fastest, hard-wired Internet connection available. Be sure it is a dedicated connection, as shared connections can be unreliable. Latency can also be caused by an overloaded server.
Video Lag/Synch Issues
My on-demand stream is stuttering, stopping, or will not play.
Be sure the video codec is compatible with the client’s version of Flash Player. H.264 video will only play in Flash Player 9 or later. If the failure occurs on only specific videos, be sure they are not corrupt by inspecting them with the FLVCheck utility. This utility will also tell you if the video’s codec profile is compatible with Flash Player. Also check the possible causes of poor performance previously discussed.
Video Lag/Synch Issues
Only some clients have trouble with video playback; others are receiving streams just fine.
In order to use FMS-enabled applications, a user should have at least a broadband connection. Generally, at least a 512 Kbps (download) speed is recommended to receive streaming videos smoothly and participate in video chats.
Since FMS does offer bandwidth detection and dynamic streaming, lower-quality videos can be provided for users on slower connections, meaning a wide variety of audiences with varying connection speeds can be served.
22
Server Crashing
The server freezes or crashes.
Server crashes are typically caused by memory leaks or corrupt media files. To determine the root cause of the server crash, begin by inspecting all FMS log files. Note the time when the issue occurred, and document logged events from when issues began to when the server crashed. The operating system logs can also reveal details of a crash (Event Log in Windows, or /var/log/messages in RedHat Linux distributions). Obtaining crash or hang dump data can also be helpful. In Windows, use ADPlus (http://support.microsoft.com/kb/286350); in Linux, use pstack.
Collecting performance data can also reveal details of a server hang or crash. Memory utilization, CPU utilization, number of connections and swap space are all valuable to determining the root cause. Document any behaviors or events that lead up to the failure.
Server Troubleshooting
The application(s) have stopped responding, or a connection cannot be made.
Begin by logging into the FMS Administration Console; check to see if there are any active connections. If so, restart the Virtual Host that you are having problems with. If there are no active connections, try stopping and restarting the Virtual Host. If this doesn’t work, check the FMS log files for anything that might reveal details about the unresponsive behavior. Next, check the Event Log in Windows, or /var/log/messages in Linux, to see if any connections are being rejected, and any reasons logged. A common reason for rejecting connections can be resource limit violations. Resource limit violation errors indicate that the server has exceeded its maximum number of connections, streams, shared objects, or instances. If you have set limits on your Virtual Host, you may need to raise them. Other errors in the application logs usually indicae an issue with the application itself, or with some user input into the application. Utilize trace functions and/or external logging in your applications, and check the FMS Administration Console for live trace feedback. SWF verification may also be a culprit; if you’re using this feature, be sure that your client SWF file matches the authorized SWF file.
Server Troubleshooting
The server is slow to respond, and RDP/VNC/SSH is very sluggish.
Check the CPU, Memory, and Network usage. If any of these are high, the server will become slow and unresponsive. It may need to be restarted, or the offending application closed. If the resource usage remains high after a restart, or seems to spike up to maximum instantly, there may be an issue with a specific FMS application or with some unrelated, external program. This should be investigated immediately to resolve the issue, as prolonged high usage may damage the hardware over time. You may need to run hardware tests if all other options are exhausted.
Server Troubleshooting
Client connections are being accepted, but very slowly, or are never resolved.
Connection issues may be observed when there are network issues such as malfunctioning load balancers or a massive number of simultaneous connection requests. On the client end, there can be Internet connection problems, or a firewall blocking ports. The FMS access.log file can reveal details about connection issues. Logging is turned on by default in FMS 3 and later. FMS Health Check utility (FMSCheck) is another useful in diagnosing connection issues.
ActionScript traces of event handler status codes can also be helpful in diagnosing connection problems (onStatus in AS2, netStatus in AS3). You can also try connection monitoring utilities such as Ethereal Wireshark, tcpdump, or Charles. Often, connection “length” can have an impact on connection performance; geographical location, number of hops, and overall latency can all play a part. Note also that RTMP tunneling (RTMPT) connections are generally slower than standard RTMP connections.
