Even YouTube Doesn’t Take HTML5/WebM Seriously

Home/Blogs/Even YouTube Doesn’t Take HTML5/WebM Seriously
By | 2017-02-23T00:47:51+00:00 May 22nd, 2014|Blogs|Comments Off on Even YouTube Doesn’t Take HTML5/WebM Seriously

I know, I know, Flash is dead, the war is over. We’ve all moved on to other battles. Still, I had to laugh the other day when I noticed how YouTube was encoding files for some browsers in HTML5 mode. 

Here’s the story. I was writing another Video Doctor article for OnlineVideo.net. I remembered a YouTube video that looked like it wasn’t deinterlaced, so I returned to the video in Firefox, which is my go-to browser. When I clicked the icon on the bottom right of the player to switch to the highest resolution video, I saw what you see in the right hand corner of the first figure; max rez is 360p. I distinctly remembered the video at 720p or larger, so I was initially confused. 

Then I recalled that I had been playing around in HTML5 mode on YouTube and wondered if that might be it. So, I right-clicked to find the results shown on the upper left of the first figure–Firefox was still in HTML5 mode. 

YT2-Firefox HTML5.png

Figure 1. My YouTube video in Firefox in HTML5 mode; One video resolution. 

I navigated to www.youtube.com/html5 and switched back to Flash mode and saw the result shown in Figure 2. Five alternatives, including 480p and 720p. 


Figure 2. My YouTube video in Firefox in Flash mode; 5 video resolutions. 

If you watch YouTube videos in HTML5 mode in Safari (Figure 3) or Chrome, you also have a 720p option. Chrome provides a 480p option as well. Why might that be? I’m guessing it’s because Safari and Chrome both play H.264 files, and Firefox doesn’t. Since Mozilla never licensed H.264, in HTML5 mode Firefox has to play WebM video, at least on the Mac I was testing and other Windows 7 computers that I checked.

I tested a lot of different videos on YouTube and the result seemed to be the same for all; one iteration for Firefox, multiple for Flash and browsers that could play H.264 in HTML5 mode. The apparent conclusion is that YouTube encodes fewer iterations of WebM videos than it does for H.264; could be wrong here, but that’s what it looks like. 


Figure 3. My YouTube video in Firefox in HTML5 mode; One video resolution. 

Interesting, if you watch the progress bar when viewing YouTube videos in HTML5 mode in Firefox, you’ll see that YouTube is delivering via progressive download, as the video continues to download if you stop playback. Perhaps that’s why YouTube isn’t encoding higher-bitrate WebM files; the wasted bandwidth is too costly even for YouTube.

Why might YouTube be using progressive download for Firefox? If you right-click the player and choose Stats for Nerds, you’ll see that in Firefox, YouTube isn’t using DASH for playback (Figure 4), which would eliminate the waste. However, in Chrome, shown in Figure 5, YouTube is using DASH. 


Figure 4. No DASH in Firefox.

Not sure why YouTube is delivering to the two browsers differently. I had thought that it related to Firefox not supporting the Media Source Extensions, but Mozilla seems up to date on that. Whatever the cause, not only does playback in Firefox offer fewer iterations, it also wastes more bandwidth. 


Figure 5. DASH in Chrome.

I should say that I believe in HTML5; it’s great for single file delivery to desktops and mobile, with Flash fallback of course. Here’s a webinar I gave on that topic. It’s just that HTML5 isn’t a panacea, and many of the problems that plagued it at the start, including the lack of support for a single codec, and different browser vendors pursuing disparate development strategies, continue to be a significant limitation, particularly for producers like YouTube who deliver adaptive streams. 

The bottom line is that if the world’s largest distributor of video doesn’t think it’s essential to bring parity to the HTML5 experience on a top-three HTML5 browser, why should we take HTML5 seriously? And if Google doesn’t respect WebM sufficiently to encode 480p and 720p versions on YouTube, what does that say about WebM? Finally, if YouTube still uses Flash as the default player despite HTML5-compatible browser penetration above 70-80%, just how dead can Flash really be?


#1KevinMooreSaid this on 05/26/2014 At 11:11 am

Not all videos or channels are treated equally. If the channel or video is popular it will have a lot more encoding options available. I have personally seen this over the years as I had watched a video that was low resolution, but later when I returned to the same video that I added to my favorites list it was at a higher resolution.

I validated the behavior above using a Firefox plugin called Complete YouTube Saver. You will need to either download FFmpeg or point to your local install so that the plugin can use it to mux the 1080p MPEG-DASH content back together.


It will show you every video and audio codec that Youtube generates to get content to desktops and devices.

#2JanSaid this on 05/26/2014 At 11:33 amIn reply to #1Kevin:

Thanks for weighing in. Download Helper, which I use, also shows all available files. On what I assume are considered low priority videos, it only shows one WebM file at 360p. On what I assume are higher priority videos, it does show more WebM encodes, but 360p is still the only one that appears in the Firefox menu; not sure why, but the result is the same; a lower quality experience in HTML5 than WebM.

On low-priority files, the HTML5/Firefox experience is clearly degraded. Not sure what message this is sending, but it's certainly not promoting HTML5/WebM.

Thanks again for taking the time to comment. I'll check out the YouTube Saver.

Jan#3WhyteSaid this on 06/09/2014 At 04:58 am

I think there is one mistake in the article, as from what I saw, MSE is in fact not ready at all in Firefox.


To paraphrase, there are many things that are not yet working/implemented, such as seeking to unbuffered areas and automatic quality switching. I tried enabling MSE in about:config, and it indeed is incomplete.

We just need patience.

#4Jan OzerSaid this on 06/09/2014 At 08:54 amIn reply to #3Whyte:

Thanks for the correction!