The good old Standard Definition & H.264
You know that today it’s possible to stream HD contents on the web at very good bitrates thanks to codecs like H.264 and the Flash Player 9 (see my previous demos of HD and FullHD video delivery). Ok, but now that the technology is available who has the HD contents and the will to publish them ? Indeed broadcasters still work for the most part with Standard Definition contents on their delivery channels (Satellite, Digital Terrestial, DVD) and there are huge archives of old but precious SD contents.
Therefore, optimizing the encoding of such SD content is very important, sometime strategic. But SD contents are often difficult to encode because in the vast majority they are interlaced and the older clips are noisy.
A custom approach to encoding is required to obtain the best bitrate / quality ratio.
In example, interlacing is one of the worst enemy and it is important to use the best deinterlacing routines available (motion compensated) and other tricks.
Pushing the H.264 potentialities to the limit, it is possible to encode generic SD content in the range 300-600Kbit/s with good results. Let’s take a look at these samples:
The first is a 720×480 clip encoded at only 400Kbit/s (the bitrate used by YouTube).
The second is the same clip encoded at 300Kbit/s but with a resolution of 640×480.
Both clips have a sound track encoded at only 32Kbit/s, thanks to the excellent performance of the codec He AACv2. The mix of H.264 and AAC is very effective at low bitrate because using older technology like Vp6 + MP3 at 300Kbit/s needed at least 80Kbit/s (MP3) for the audio track to reach the quality of a 32Kbit/s AAC with the result of a lower bitrate available for the video track (220Kbps vs 268Kbs, 18% less)
Concluding, I think H.264 is not only the “state of the art” in video encoding today, but beeing an open standard it is also an “open lab” where explore the limits of encoding technologies. Therefore, it is not only the best choice for HD videos but for all type of video. The only open issue remains the higher processing power required by H.264 but this is another false myth I will try to demistify because with specific optimizations it is possible to reduce consistently the required precessing power (note: in the previous samples I’m not using optimizations for processing power, yet😉