If the encoding computer does not meet the minimum system requirements, the resulting audio/video stream might be compromised. Always make sure that CPU usage does not exceed 75% while encoding, or the quality of the encoded file could be affected.

This option is disabled when either the device is not capable of providing the timecode or the device timecode DLL is missing from the Timecode folder in the application installation directory. However, you may use the System Timecode option to embed the system time as a timecode in the video stream or file.

First, make sure no other application is using the device. Then, try the following:

Exit Flash Media Live Encoder.

Exit the device.

Restart Flash Media Live Encoder and ensure the Video and Audio checkboxes in the Encoding Options panel are selected. Flash Media Live Encoder searches for a compatible device. Your device should then appear in the Device list.

In general, Flash Media Live Encoder does not tamper with the audio or video timestamps. But when the device gives video frames with a backward timestamp, those frames are dropped. With audio, if the samples have a backward timestamp, then the timestamp value is adjusted.

This error occurs when the device starts behaving unexpectedly (sending packets with wrong or backward timestamps) after a long encoding session. The application will restart itself after encountering this error. This error will not affect the video quality.

Verify that the encoding computer is connected to the network. Also, verify that the connection URL to Flash Media Server is correct and that the Flash Media Server application to which you're connecting exists. Make sure that the port on the server is enabled and the firewall is not blocking the connection. Also make sure that the Allow tag in vhost.xml in Flash Media Server contains the correct parameters. Refer to the vhost.xml for the correct parameters.

Yes. Flash Media Live Encoder tries to reconnect every five seconds (by default) until a connection is established. However, you can change that default setting and determine how often and for how long Flash Media Live Encoder tries to reconnect by editing the profile file. Refer to Flash Media Live Encoder Help for more details.

The selected bitrate represents the average value at which the application should encode; the actual bit rate depends primarily on the content. Complex video sequences require more bits compared to still video. Also, if there is a drop in frame rate, either due to the device or high CPU usage, the actual bitrate will differ.

The selected frame rate represents the average value at which the application should encode; the actual frame rate depends on the frame rate the application is getting from the device. Some devices do not give the video at the desired frame rate. It may be lower or higher. Also, in the Encoding Statistics panel on the Encoding Log tab, check for frame drops. If there are frame drops, make sure CPU usage of the system is not more than 75%.

Verify the buffer value from the Flash Media Live Encoder publishing statistics. If this value is high, then network conditions are unfavorable, and Flash Media Live Encoder is unable to stream the data to the server. If the buffer value keeps increasing, then Flash Media Live Encoder may crash. Use Auto Adjust to overcome this issue.

The deinterlace filter is based on a simple vertical blur algorithm and is not very effective at higher video sizes. Adobe suggests that you deinterlace at the hardware level for better quality and performance.

Select a bitrate according to the video content. For large and dynamic video input, you need a higher bitrate. An extremely low bitrate might result in low-quality video and pixilation. For small and relatively still video input, you can use a lower bitrate.

The Base profile uses less CPU power than the Main profile but compromises video quality. If you want high-quality video and you have a good hardware configuration system, use the Main profile; otherwise the encoder might reduce the output fps during the encoding process.

H.264 levels define the limit on the combination of video size, frame rate, and bitrate that the encoder can encode. Changing the H.264 level does not have any impact on video quality and CPU usage. For details, see the Flash Media Live Encoder Help and Wikipedia article on H.264.

Verify the output frame rate in the Statistics panel on the Encoding Log tab.

Make sure that there are no frame drops at the encoder level.

Try reducing the sample rate of the audio or encode only video. If the video quality improves, try switching to a different audio device.

Determine whether Auto Adjust with the Drop Frames option is enabled. If Auto Adjust with the Drop Frames option is enabled, the video will stall at the subscriber end.

If the stalling is present only in the live stream and not in the local file, adverse network conditions, such as high latency and bandwidth congestion, might cause the video to stall. Try using Auto Adjust with the Degrade Quality option.

Pixelation occurs when the video bitrate is not sufficient to encode the video. Increasing the video bitrate will usually resolve the issue. Also, if you are using the H.264 base profile, try switching to the Main profile.

Auto Adjust is used to adjust video settings dynamically in case of adverse network conditions between Flash Media Live Encoder and Flash Media Server. With Auto Adjust, you can select either the Drop Frames or the Degrade Quality option. Drop Frames will drop video frames at the RTMP end, and Degrade Quality will reduce the bitrate of the encoded stream. The Degrade Quality option affects both the primary and backup stream as well as the file that is being saved. The Drop Frames option adjusts each stream individually. The saved file will not be affected.

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. Adobe recommends always setting the buffer to a non-zero value.

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.

Per the MP4 standard, Flash Media Live Encoder creates fragmented F4V files that are optimized for streaming from Flash Media Server. F4V or MP4 playback applications that do not fully conform to the MP4 specification may fail to play.

If the Flash Media Live Encoder process is terminated during encoding, the saved file will be closed improperly and will not be playable.