Recommended Encoding Settings
Cloud Transcoding Mode Settings
For most applications IBM Video Streaming recommends sending a single high definition stream at 720p resolution with the following settings:
Quality | Resolution | Video Bitrate | Audio Bitrate | Audio Sample Rate | Frames Per Second | Video Codec | h.264 Profile | Keyframe interval | B-frames / GOP | Audio Codec | Audio Channels |
HD 720 | 1280x720 | 1,200 - 4,000 kbps | 128kbps | 44.1 kHz or 48 kHz | 25 or 30 | h.264 | Main | 1 Second | 0-2 Seconds | AAC-LC | Mono or Stereo |
Full HD 1080P and 4K streams require significantly more encoding processing power and bandwidth. These resolutions should only be used when you are certain you have sufficient resources to successfully encode and send with no quality loss. Attempting higher resolutions and bitrates without sufficient encoding resources or bandwidth can lead to poor image quality and interrupted or corrupted viewing or recordings.
Quality | Resolution | Video Bitrate | Audio Bitrate | Audio Sample Rate | Frames Per Second | Video Codec | h.264 Profile | Keyframe interval | B-frames / GOP | Audio Codec | Audio Channels |
HD 720 | 1280x720 | 1,200 - 4,000 kbps | 128kbps | 48kHz | 25/30/60 | h.264 | Main | 1 Second | 0-2 Seconds | AAC-LC | Mono or Stereo |
HD 1080 | 1920x1080 | 4,000-8,000 kbps | 192kbps | 48kHz | 25/30/60 | h.264 | Main or High | 1 Second | 0-2 Seconds | AAC-LC | Stereo |
4K | 3840x2160 | 8,000-14,000 kbps | 192kbps | 48kHz | 25/30 | h.264 | High | 1 Second | 0-2 Seconds | AAC-LC | Stereo |
Local Transcoding Mode Settings
Depending on your video production workflow, your encoding equipment, or your available bandwidth, you may want to send lower or higher resolutions and bitrates or you may want to send up to 4 multiple bitrates instead of using IBM Video Streaming's Cloud Transcoding option. The table below provides recommended configurations for higher and lower bitrates and resolutions.
Quality | Resolution | Video Bitrate | Audio Bitrate | Audio Sample Rate | Frames Per Second | Video Codec | h.264 Profile | Keyframe interval | B-frames / GOP | Audio Codec | Audio Channels |
Low | 480x270 | 400kbps | 64kbps | 48kHz | 25 / 30 | h.264 | Baseline | 1 Second | None | AAC-LC | Mono |
Med | 640x360 | 800 - 1200 kbps | 96kbps | 48kHz | 25 / 30 | h.264 | Main | 1 Second | 0-2 Seconds | AAC-LC | Mono or Stereo |
High | 960x540 / 854x480 | 1200 - 1500 kbps | 96kbps | 48kHz | 25 / 30 | h.264 | Main | 1 Second | 0-2 Seconds | AAC-LC | Mono or Stereo |
HD 720 | 1280x720 | 1,500 - 4,000 kbps | 128kbps | 48kHz | 25 / 30 | h.264 | Main | 1 Second | 0-2 Seconds | AAC-LC | Mono or Stereo |
HD 1080 | 1920x1080 | 4,000-8,000 kbps | 192kbps | 48kHz | 25 / 30 | h.264 | Main or High | 1 Second | 0-2 Seconds | AAC-LC |
Stereo |
4K | 3840x2160 | 8,000-14,000 kbps | 192kbps | 48kHz | 25 / 30 | h.264 | High | 1 Second | 0-2 Seconds | AAC-LC |
Stereo |
Video Resolution
- We recommend streaming at a resolution with a 16:9 aspect ratio as listed above
- It is best to either match your original video source, or scale it down. For example, capture at HD 720 and stream at HD 720. Or capture at HD 720 and stream at 540 (high).
- You should never be scaling up and streaming at a higher resolution than your original video source. For example, it does not make sense to capture at 720 and stream at 1080. You will have no gain in quality and you are using more bandwidth than is necessary for you and your viewers.
- Be aware that higher resolutions require greater processing power to encode the stream. Attempting too high of a resolution on too little processing power can result in degraded image quality and corrupted or interrupted streams or recordings.
Video Bitrate
- Many popular encoders on the market use variable bitrate encoding. With a variable bitrate encoder, when you set a bitrate, you are only setting a target. Depending on the level of motion in your video content and your keyframe interval, the actual encoded bitrate of the stream will go higher and lower than the target. This is one of the reasons why having adequate headroom in your bandwidth is so important.
- Higher motion content requires a higher bitrate to achieve the same perceived quality video stream. For example, "talking heads" sitting at a desk with a relatively static shot can use the lower end of the bitrate recommendations provided above, whereas a sporting event or concert with high motion and many moving cameras will typically require a significantly higher bitrate at the same resolution to have the same perceived quality.
- Higher resolutions require a higher bitrate to achieve the same perceived quality video stream. It is important that you use the guidelines provided in the chart above to appropriately match your bitrate to the resolution you are using. Using too high or low of a bitrate can lead to poor image quality or buffering for your viewers.
- If your available bandwidth is limited, you should reduce both your resolution and your bitrate accordingly.
Audio Bitrate
- The audio bits take up much less of the overall bandwidth than your video bitrate. In addition, the perceived quality gain at bitrates above 320kbps is minimal, so it is recommended to keep the audio bitrates within the ranges suggested above.
Audio Sample Rate
- 48000 hz is the highest supported sample rate. Sample rates above this are unsupported and can cause a failure in the stream or recording.
- Most production equipment will work at either 44100 hz or 48000 hz. It is recommended you match the sample rate of your stream with the output of your production equipment. A mismatch in sample rates can cause audio artifacts including drop outs, clicking, pitch changes or other problems.
Frame Rate
Frame rates should always match the frame rate of the video source.
NTSC standard equipment typically operates at 30 fps and in that case, encoding parameters should be configured to match the source frame rate of 30 fps.
PAL standard equipment typically operates at 25 fps and in that case, encoding parameters should be configured to match the source frame rate of 25 fps.
IBM Video Streaming supports high frame rate (HFR) video. This is, the platform will ingest streams with frame rates higher than 30 fps up to 60 FPS Original HFR streams will be passed through. If cloud transcoding is deployed, all lower resolution renditions will be created using lower frame rates as specified in the configuration (for example, 30 or 25 fps).
HFR video imposes additional stress to player devices. Lower end devices such as certain laptops or smartphones could stutter or crash when playing HFR video. Therefore, many end users viewing on typical computers and mobile devices will not be able to properly decode 60 FPS streams and this can result in playback issues.
Video Codec
- IBM Video Streaming recommends h.264 and AAC-LC. These are the most widely compatible and efficient modern codecs. They offer the highest quality at the lowest bitrates.
h.264 Profiles
- IBM Video Streaming supports the H.264 profiles MAIN and HIGH. See table above for resolution suitability
Keyframe Interval
- IBM Video Streaming requires a fixed keyframe interval of 1 or 2 seconds. The default setting on some encoders may be different from this, so it is required to adjust it to meet this requirement for optimal adaptive bitrate performance and stream quality.
- Some encoders may have settings like "auto keyframe interval" or "scene change detect." It is required to disengage these modes as they may result in an unpredictable keyframe interval.
- IMPORTANT: Sending a stream with keyframes at intervals greater than 2 seconds or at irregular intervals can result in stream or recording failures. Please ensure you have a proper keyframe setting to avoid this.
Audio Codec
- AAC-LC must be used for full compatibility with the IBM Video Streaming streaming platform
Interlaced vs. Progressive
- IBM Video Streaming does not support ingestion of interlaced video. It is required that you de-interlace the image before sending the stream to the IBM Video Streaming failure or degraded image quality.
- If your camera can only send an interlaced image, many encoders will have the option to 'de-interlace' the video. Choose this option before sending to IBM Video Streaming in order to avoid streaming issues.
- For more information on interlacing, please read this article.
RTMP, Fragmented MP4, and HLS
- IBM Video Streaming currently utilizes 3 different protocols.
- RTMP protocol is used for ingesting the streams from the source encoder.
- A proprietary fragmented MP4 protocol is used to deliver to the IBM Video Streaming HTML5 player for some playback environments.
- HTTP Live Streaming (HLS) is used to deliver streams for iOS, Android, some desktop browsers and other connected devices.
- At this time, IBM Video Streaming does not support direct ingest of HLS streams. Instead, IBM Video Streaming's cloud transcoding is used to create the HLS versions from the incoming RTMP stream.
- For details on IBM Video Streaming's cloud transcoding and multiple bitrate streaming with IBM Video Streaming, including the exact resolutions and bitrates that are delivered to desktop players and mobile devices, see our article multiple bitrate streaming with IBM Video Streaming.
IP Cams, RTP, RTSP, HLS and other Streaming Protocols
- Currently, IBM Video Streaming only supports ingest of RTMP streams.
- IBM Video Streaming delivers streams to viewers via RTMP, HTTP and HLS.
- If you have a IP Camera, or other device that can only deliver streams over RTSP.
Recommended Network Settings
Internet connection recommendations
- For successful live streaming, you need a high-quality internet connection. A connection that is sufficient to check email or load web pages may not be good enough for streaming. You don't need "a" internet connection, you need a high quality internet connection, particularly to do uninterrupted HD streaming.
- Not all connections are of the same quality. You want to use a wired ethernet connection and not use WiFi as WiFi connections are more prone to fluctuation in quality and can more easily drop.
- Cellular (3G/4G/LTE) connections can be very unreliable. It is strongly recommended to use a hardwired ethernet connection or a WiFi connection over a cellular connection. But the type of connection is only one factor. For every type of connection, it is important to conduct bandwidth tests ahead of time to know you have sufficient bandwidth to stream.
- It is important to use a connection which is not shared with many other users. For example, when streaming from a typical corporate office or event venue, the amount of bandwidth available for your stream may be inconsistent depending on the number of other users on the same network.
- It is recommended to ask your IT department to dedicate bandwidth that is reserved solely for the stream. If you have plenty of bandwidth and not many users sharing the same bandwidth, this may not be necessary. But if you find you are on a shared connection and cannot always get adequate bandwidth, you may want to ask for this, or to try to minimize how many other users are on the same connection at the time of your stream.
- In addition, it is recommended to share with your IT department our article on opening firewall ports for IBM Video Streaming broadcasting and viewing.
- If you are not on a corporate network or do not have an IT department to contact, you can check with your internet service provider to purchase a plan that has the appropriate level of service for streaming.
Network Bandwidth
- When choosing your encoding settings you should take into account your available upload bandwidth.
- A good rule of thumb is for the bitrate of your stream to use no more than 50% of your available upload bandwidth capacity on a dedicated line. For example, if the result you get from a speed test shows that you have 2Mbps of upload speed available, your combined audio and video bitrate should not exceed 1Mbps.
- To stream in HD, you'll want at least 3-8Mbps upload speed available
- a generic speed test, such as the one at speedtest.net, should suffice to measure available bandwidth
- If you find that your stream frequently rebuffers, pauses, or disconnects, try using a lower bitrate and resolution on your encoder.
Encoder Hardware Recommendations
CPU Resources
- Ensure your encoding CPU / GPU can handle your encoding settings.
- HD streams and high bitrate streams take significantly more CPU and GPU resources to capture and encode.
- If your streams are choppy, pause and resume, exhibit encoding artifacts, are dropping frames or appear to be playing back in a lower than expected frame rate, these can all be signs that your CPU is not able to keep up with the live video encoding.
- Reducing the input resolution size and or reducing your stream output resolution and bitrate can fix these issues.
- Most encoders have an indicator to show you how much of your available resources you are using. Pay attention to this and lower your settings accordingly if it shows you are nearing the maximum resources available.
- Low frame rate streams look very bad. Unless you have extremely low motion content like static slide images, often it would be better to stream full frame rate at a reduced resolution, for example 640x360 at 30fps vs 720HD but only being able to stream at 12 frames per second.