Last Friday, I produced a concert for old time band Allegheny Blue to test out the NewTek TriCaster TCXD300. I uploaded a 720p file to YouTube to present to the band, and when I went to view the file, I noticed that the Google subsidiary had subtly changed the playback interface.
Specifically, as you can see on the bottom right of Figure 1, YouTube added options for 720p, 480p, and 360p playback. I checked an older, full resolution file that I had uploaded in December, which you can view here, and saw that if you originally uploaded a 1080p file, that option was available as well. You can examine the encoding parameters for that file here.
Using FireFox plug-in Download Helper, I downloaded the three files, and analyzed them in MediaInfo. I compared my results to a similar analysis that I performed about 3 months ago that you can read about here. Table 1 contains a summary of my findings.
First, it doesn’t appear that YouTube changed anything compression wise – they simply gave the users the ability to control the HD file that they viewed and rebranded the file designations, for example, from HQ25 to 480p. This is a great improvement over the previous schema for delivering HD files to their audience, which I’m sure was supported by advanced logic back in YouTube, but had no rhyme or reason that I could discern.
In general, I think it’s a great idea to let your viewers decide which file to watch, because if the experience heads south, and the video stops and starts during playback, it’s their fault not yours. Plus, they know they can simply choose a lower quality file to avoid the problem.
Contents
The YouTube Mystery Codec
Second, in my previous article, it looks like I assumed that if the video codec wasn’t Spark, which MediaInfo could identify, or H.264, it was VP6. One of my readers took me to task on this, pointing out that On2 has gone on record that YouTube is not using VP6 (sorry, I couldn’t find the link). So let me back up and state that I have no idea what codec YouTube is using for the 360p/480p files because no analysis tool that I could find has ever identified the codec. Here’s what I get in FLV Player:
Here’s what I get in MediaInfo:
So, I stand corrected, and have no idea what codec YouTube is using for these files.
What’s the Right Data Rate for Your Files?
Let me display the chart again to save some scrolling. Take a look at the bits/pixel/frame calculation, which MediaInfo will give you for any file that you analyze. You can also compute it by dividing the data rate by (frame rate x pixel resolution). At one level, YouTube is telling you that these data rates are “OK” for mass market consumption. That is, at a resolution of around 640×360, a bits per pixel per frame of about .107 should deliver acceptable quality. This information in hand, you consider checking the bits per pixel per frame of your video files – if their values are much greater, your data rate may be higher than necessary, pushing up your bandwidth costs.
Second, look at how the bits/pixel/frame comes down as the files get larger. This reflects that codecs seem to get more efficient as the video resolution increases. Microsoft evangelist Ben Waggoner has quantified this as the Power of .75 rules, which he defines as follows (in a 2009 email to me).
Using the old “power of 0.75” rule, content that looks good with 500 Kbps at 640×360 would need (1280×720)/(640×360)^0.75*500=1414 Kbps at 1280×720 to achieve roughly the same quality.
If you’re increasing the resolution of the video that you’re streaming, you can use this formula to compute the bandwidth necessary to retain the same quality with the higher resolution file.
Which H.264 Encoding Parameters?
Finally, if you’re producing H.264 files and you’re wondering which profile to use, and whether to enable CABAC, just ask yourself WWYTD (What Would YouTube Do?). As you can see in the following figure, YouTube uses the High Profile with CABAC enabled.
There you have it. YouTube streams more video than all other web sites combined, so their actions always bear watching. This latest one seems more interface-related than plumbing, but as always, there are several critical take-aways that can benefit your streaming practices.