Streaming Learning Center Where Streaming Professionals Learn to Excel
Related Articles
The promise of a unifying standard to simplify our lives is attractive, but putting it into practice is another thing. Here’s how one HTML5 video project got messy in a hurry.
As much as we expect standards like HTML5 to simplify our jobs, oftentimes they don’t. In fact, a recent HTML5-related project convinced me that the term “multivendor standard” is an oxymoron. Any standard involving multiple vendors means different implementations, which challenges anyone trying to use the standard.
Here’s the story. A consulting client ran periodic projects that involved videos from multiple disparate sources in multiple resolutions and formats, including AVI, MOV, WMV, MPG, and MP4. After each project finished, the client wanted to make the video files available on its intranet for anyone to download, and it wanted me to create a streamable version for quick preview. To simplify the deployment process, the client didn’t want to create separate pages or embedded windows for the videos; it just wanted one PDF file with links to original downloadable and streamable versions.
Seems tailor-made for HTML5, right? Encode to MP4 and create the links, and the files should play in all modern browsers. I ran some preliminary tests that seemed promising, so the client provided about 15 random test files and I began writing the FFmpeg encoding script.
I started on the video side first, focusing on how to create a single script that preserved the disparate source aspect ratios in the final encoded files. I quickly found a solution, encoded the 15 files, uploaded them to a test site, created a PDF file with links, and started testing. Internet Explorer (IE) was the primary browser the client used, and I tested on two HP machines in my office—a notebook and a workstation. All files played except one; it was from a very sketchy screencam-based source. On the notebook, however, Windows Media Player played all successful files in a separate window, while on the workstation, the videos played in an embedded QuickTime window. I tried playing the files in Edge, and all but the problem file played in an embedded HTML5 Window. I tried opening them in Chrome, and all files played in an HTML5 window, even the sketchy one.
Before attempting to debug the problem file, I asked the client to try it on his computers, feeling pretty confident it would work. On every Windows computer in his office, 13 files failed and two played. The error message was something like, “cannot play/error C00D11B1,” a generic error with fixes ranging from registry tweaks to complete Windows reinstalls. Definitely not good. In Firefox, which was the firm’s backup browser, 10 files played and five failed, displaying the error message, “video can’t be played because the file is corrupt.” The funny thing was, I could duplicate the Firefox errors on my Windows workstation, but the files played correctly on my Mac Pro.
Once you scratch beneath the surface of HTML5, you realize that it means many decidedly nonstandard things on many different computers. For example, in IE, you can choose different players installed on the system to play MP4 files, but not, near as I could tell, IE itself. Ditto with Firefox, which makes sense because Mozilla never licensed H.264 playback. So supporting a single HTML5 browser could mean supporting multiple players.
To make a long story short, the problem with Firefox was caused by 96kHz audio in the files converted from Windows Media, which apparently exceeded Firefox’s playback capabilities on the Windows workstation, but not the Mac Pro. Go figure. As mentioned, my first command line didn’t incorporate audio conversion, so by default FFmpeg converted the 96kHz WMA to 96kHz AAC. A quick command line change fixed the problem. We never did isolate the problem with IE at the customer site—since the client was migrating to Windows 10 and Edge, it decided to punt on IE support altogether.
The lessons? Every standard sounds simple until you actually try to use it. The devil is always in the details. Encode files for HTML5 playback targeting the lowest common denominator player. And never expect vendors to provide error messages that actually help you isolate the real problem.
