Community-powered support for Helix
Supported by 339 customers like you, as well as the Helix team.

What are some best practices for encoding content?

Encoding best practices overview H.264 live and Video On Demand (VOD).

An I-frame is a keyframe. Use an IDR I-frame instead of a normal I-frame. Most encoders have this by default.
A P-frame is a frame based upon what was in the previous frame
A B-frame is a frame that can look forward to upcoming frames and grab data from them.
HLS is HTTP Live Streaming from Apple for the iPhone.

1) Adaptive streaming helps with better quality regardless of the connection.

2) Keyframes every ten seconds helps with higher quality at lower bitrates. You have a "bit budget" use it wisely. The downside is live streaming has a longer wait time. A bit budget is how many bits per second you have and where you want those bits to go. Keyframes use more bits than other frames. Having too many keyframes can reduce the quality of the overall encode. This can be compensated with by using a higher bitrate.

3) Mark every keyframe (i-frame) as IDR (Instantaneous Decode/Refresh) frame. Problems with flash and iPhone if it isn't.

4) Know your keyframes. Flash likes keyframes every three to 10 seconds. Use Two Pass VBR in most cases. If your video bitrate is too high it may choke your server, network and player.

5) B-frames are in Context-Adaptive Binary Arithmetic Coding (CABAC) and needs to consideration when creating content for desktop players. B-frames should not be used for live broadcasts as they increase latency.

6) Using shorter I-frame intervals allows for a person to join a live feed faster and better error recovery. Longer I-frame intervals allow for better quality at the same bitrate. See also bit budget as mentioned above.

7) Make sure that your I-frame interval matches your HLS chunk size. You want to have your I-frame be the first frame in every segment.

8) Adobe flash downsamples to 44.1K.

9) Constant Bitrate vs. Variable Bitrate (2 pass encoding). Use CBR for HLS chunking so that all time based chunks are about the same size. Recommended chunking for HLS is from two to eight seconds although typical setups are at 10 seconds (for higher quality video).

10) People are more perceptive about audio than video quality. Have good audio when possible.

11) Try to preprocess your video using a Motion Compensated Temporal Filter. This removes subtle noise from the video and allows one to lower bitrates by 10-12% at the same quality. This is a great option for low bitrate delivery and saving bandwidth because bandwidth is rarely free.

12) Try to preprocess your video with a deblocking filter. This is standard for H.264 and H.263 video.

13) When you are streaming video try to put yourself in the viewer’s chair. What is going to be the most important to them?

14) Networks will always be limited. What is the bandwidth of your audience? You can settle for acceptable mediocrity in most cases.

15) Knowing your player, container, codec and server will help you to deliver a higher quality service.

16) Audio is the most important part of delivering low bitrate content. 32Kbps is the absolute minimum you should use. 64bit is ideal. Going up to 196Kbps is overkill. Newer codecs such as Dolby Pulse and HE-AAC v2 should be used when possible. Always quality check the audio the way that the user will.

17) It is always a challenge to balance quality vs. speed (Baseline, Normal and HQ settings for H.264 for example). Entropy encoding or CABAC requires considerably more effort to encode and decode. CABAC is not supported in Constrained Baseline Profile (CBP), Baseline Profile (BP) or Extended Profile (XP). THose use CAVLC (Context Adaptive Variable Length Coding). Most mobile phones do not support CABAC and if they do work with CABAC their batteries will drain faster.

18) Always consider baseline profile even as devices evolve (reduces processor power).

19) Devices are good at upscaling content and is almost transparent. They typically use hardware upscaling which can result in lower bitrates and similar perceived quality. The tradeoff is a softer image.

20) Remember that when you are doing a live stream you have only one chance to get it right.

21) Use a digital source such as SDI or HDMI (sans HDCP) and fallback to analog component, composite or S-Video only if necessary. As mentioned above, preprocess your data to achieve the highest quality. Temporal frame rate, spatial scaling (resolution), contrast, edge enhancement, noise reduction and border cleanup should be used when appropriate.

22) Use Multicast whenever possible. Unicast is the fallback when Multicast is not possible.

23) Turn on Forward Error Correction (FEC).
This appears to be an industry standard and is not vendor specific.

24) Optimizing bitrate formula:
Source of this information:
Width of the video * Height of the video * Frames Per Second of the video == pixels per second
pixels per second / 1024 == Kilo pixels per second

Kilo pixels per second * (.067 ~ .150) = Kilo bits per second.

If you have a video with little motion you may want to try starting around the .067 multiplier. If you have a lot of high action you will want to start around the .15 multiplier.

As you can see, by reducing the frames per second you can reduce the optimal bitrate for your video. Reducing the width and heigh may also be necessary and most players can upsize the video with minimal issues.

Best practice dictates that you use an even divisor of the original frame rate for your output files. If you have a 60fps video then 30, 20 15 and 10 frames per second are all good options.

For example, we have a 640x480 video at 60fps
640 * 480 * 60fps == 18,432,000 pixels per second
18,432,000 / 1024 = 18,000 Kpps

18,000 * .067 == 1,206Kbps (Very little change from frame to frame)
18,000 * .1 == 1,800Kbps (Moderate amount of change from frame to frame)
18,000 * .15 == 2,700Kbps (Very high change from frame to frame)

That is a rather high bitrate. Let's halve the framerate
640 * 480 * 30fps == 9,216,000 pixels per second
9,216,000 / 1024 = 9,000 pixels per second
9,000 * .067 == 603Kbps
9,000 * .1 == 900Kbps
9,000 * .15 == 1,350Kbps

You can also halve the size of the video (to CIF in this case)
320 * 240 * 30fps = 2,304,000
2,304,000 / 1024 == 2,250
2,250 * .067 == 150Kbps
2,250 * .1 == 225Kbps
2,250 * .15 == 337Kbps
1 person has
this question