The Rise of Flash Video, Part 2
Got something to say?
Share your comments on this topic with other web professionals
Published on October 23, 2006
This will happen to you: Your client calls and informs you that she is seeing a lot of video on the web these days and, that she just happens to have a few she would like to put up on her site as well. There was a time when this request would have struck fear into the hearts of most web developers, but today’s web is a different place; the ubiquity of the Flash player in the marketplace has made this task possible. As I pointed out in the first part of this series, Flash didn’t become the /files/includes/default.css format of YouTube and MySpace without reason. It’s a dead simple way to deploy video to a website.
But simple isn’t everything. We’ve all seen videos that stop and start, take forever to play, or look pixelated. There’s a lot of crappy video out there, so it should be clear that merely waving Flash at the video problem like a magic wand isn’t enough. To be successful with Flash video, you need to understand both the technology and the user who will be viewing it.
For example, there are still many users, primarily in rural areas, who use dial-up to access the web. The dial-up user is in for a really long day if you’ve prepared your video specifically for his urban counterpart who is awash in bandwidth. This is indicative of a developer who fell in love with the technology at the expense of the user.
In this article, I move from a general overview to a more “techie” focus to explains what you need to know so you can prepare and deploy Flash video that will work well for all users.
QuickTime isn’t dead
The Flash video process starts with a source video—preferably a video in the QuickTime (.mov) format. There are two reasons behind this. The first involves the “GIGO Principle”: Garbage In, Garbage Out. We shouldn’t accept substandard artwork, audio, or other content, so it makes sense to apply those same quality standards to our video. The second reason is a matter of standards. The current industry standard is the QuickTime format, so it makes sense to request video in that format from your clients.
Speaking of standards, there is a widespread misconception that you can capture content directly from your digital video camera or a DVD, encode it as FLV(Flash video), and toss it onto your web site. Unfortunately, it’s not that straightforward. DV and MPEG4 streams don’t split the video into separate audio and video tracks, they interleave them together into one track, instead. In this scenario, the Flash Video Encoder won’t find an audio track, and the end result is video with no sound. There are solutions to this issue, but they are inevitably complex and expensive. If someone flips you a DV cassette or a DVD as your source video, your best response is probably a polite, “No thank you.”
QuickTime is generally the preferred video source file format, but accepting just any QuickTime video would also be a mistake. Each of these videos comprises separate video and audio tracks, and each track contains a massive amount of information. In order to keep these files manageable, the video is compressed using a codec.
Broadly, there are two types of codecs out there: lossy and lossless. As the name implies, the lossy codecs shrink the video file dramatically by dropping detail, like creating a JPEG image from a RAW photo. For our purposes, Spark, Squeeze, and ON2VP6 are the most important of the lossy codecs, because they the ones used to create the FLV file used in Flash. The result is a very small file size.
Lossless codecs lose very little information, if any, and the resulting files are quite large. When it comes to Flash video, large is a good thing before conversion, and a really bad thing at run time.
The basic rule of thumb for preparing videos for Flash is this: Start with as much detail as you can get. Make sure your original video is encoded with a lossless codec before you begin to convert it to FLV for Flash distribution. If you receive a video that isn’t losslessly compressed, seriously consider returning it and asking the client for a cleaner copy. This may sound a little harsh, but if you prepare an FLV from a video compressed with a lossy codec, quality goes out the window. Compressing an already-degraded video into FLV is like opening a JPEG in Photoshop, and saving it over itself with the quality slider pulled down to ten percent or so; recognizable at best, a jumbled mess of pixels at worst. In a nutshell, the crystal clear videos you see from movie and record companies likely all started life with lossless encoding. The pixelated messes of Flash video you sometimes see on the web had the life squeezed out of them lossily before they even hit the FLV converter.
Why Flash video stinks
Some folks take issue with Flash video, and they do have a point. There is a lot out there that makes watching Flash video a painful experience. They talk about pixelated and jerky video, and point to poorly re-compressed YouTube content as evidence that Flash video sucks. These shrill claims are misguided, but many people hear them and blindly agree that Flash video stinks.
These naysayers, however, rarely point to the New York Times, the Washington Post (shown below), or Vodafone. These sites make exceptional use of Flash, so the real question should be this this: If it can be this good, why isn’t everybody doing it?
Get clear on this: It isn’t the technology. It is the person that encoded the video in the first place who made the mistake. The thing that sets these notable Flash video providers apart from the teen-aged head-banger on YouTube, GoogleVideo, or MySpace is incredibly simple: These video providers care about quality, intimately understand the technology, and, most important of all, they keep an eye on the pipe (the data pipe, that is).
The FLV technology, when you get right down to fundamentals, is no different from its QuickTime and Windows Media web brethren. The sole purpose of those formats is to move audio and video data from one place to another. That data is contained in a stream, and all three formats will ask me how fast the current in that stream is flowing. That is the data rate for the stream.
The best way of wrapping your mind around the concept of data rate is to think of a dam in a river. A lake upstream drains into a river, and the town that lies downstream, frustrated with constantly being flooded, decides to control the river. The dam is built, the floods stop, and the residents discover they have a second lake behind the dam.
Now let’s apply that analogy to a video stream. The lake is the server, and the river to the dam is the data stream into the video buffer. The second lake behind the dam is the video buffer, and the dam is the Flash Player. When you set the data rate for an FLV, you are the one who controls the flow of water out of the dam. If you increase the flow of water from the dam, the people in the town are in for a really bad day. Video that stops and starts is simply the audio and video data in the stream overwhelming the Flash Player. In this case, the Flash Player will buffer some of the data and release it. Buffer. Release. Start. Stop. It creates poor-quality video, and it’s not the fault of the Flash Player. The player is doing its job and, to be equally fair, I have seen this with QuickTime and Windows Media streams.
Still, Adobe hasn’t helped the cause with its Flash Video Encoder. The /files/includes/default.css data stream value for Flash Player 8 is 400 kbps. The average person looking at that will think, “Gee that sounds reasonable,” and proceed to encode the video at that rate. What they discover is their video plays poorly.
The problem with that number is it only represents the data stream for the video track. The audio /files/includes/default.css is usually 96 kbps, meaning the total data stream is just under 500 kbps—which is marvelous if you have a T1 line. Those of us with broadband or dial-up connections will get video that stops and starts. Unfortunately, there is no magic number, but if you are preparing video for a site, try keeping the total of the audio and the video data rates to about 350 kbps, and your frame rate to about 15 fps if you are encoding a video recorded at 30 fps (NTSC), or 12 fps if you are using the PAL standard of 25 fps.
It isn’t only the YouTube Lonely Hearts that don’t get this. I recently spoke at a conference, and during a panel discussion, one of the attendees made it clear that he didn’t think highly of Flash video. He works for a Fortune 500 company, and he claimed that his experience with Flash was so bad, he was seriously thinking of getting out of the game. When pressed by the panel as to what he was doing, he said, in a nutshell, “We create these things at 30 frames per second and a data rate of 1,000 kbps. The size is 480 by 320, and we have had nothing but problems.” At that data rate, frame rate and size, the experience his employees are having is no different from that of trying to push a watermelon through a worm.
Now that you have a broad idea of how to create a good Flash video, let’s deal with the next big issue. How do you stop fourteen-year-old boys wearing baggy pants and backwards baseball caps from swiping your stuff?
Dealing with DRM
Digital Rights Management (DRM) is a complex legal issue. It is a huge field, and I want to focus on what I see a key aspect of the debate. What has held content providers back is a well-justified fear that publishing a video means you lose control of it. But that’s not quite true. Again, it is not the technology, it is the user that causes the loss of control. When it comes to Flash, there are two ways of putting it out there: a progressive download, or a stream.
If anybody caught Mark Cuban’s contention that anyone who would buy YouTube “is a moron,” you may have been wondering what he was getting at. YouTube uses a progressive download to the browser cache. The player will wait for enough of the video data to arrive so it can safely play the FLV. This means the FLV is sitting on the user’s machine and being fed into the Flash Player from the browser cache. If you are really smart, you can pull the FLV from the cache and the video is no longer under the creator’s control. If you are streaming video of a corporate picnic or your kid doing face plants in a mud puddle, this probably isn’t much of an issue. If you are a corporation that has invested some serious bucks into your project, it may be a huge issue. Cuban’s point was that no one would bother suing YouTube, which really didn’t have a lot of cash, if you could sue its deep-pocketed buyer—which turned out to be Google—for copyright violations. Only time will tell who was correct. (And if you are interested in how this might pan out, read Does YouTube Make Google a Big Target For Copyright Suits? from the Wall Street Journal for additional analysis.)
The streaming solution for Flash video just happens to be the Flash Media Server 2 from Adobe. Its sole purpose is to move data, not files, from here to there—meaning that nothing other than data hits the user’s machine. The FLV file stays on the server. The other big advantage is that the video starts playing when the first bit hits the Flash Player. There is no delay, and suddenly the files that would otherwise have been released into wild stay put and are secure.
The other really neat thing about the Media Server is that it does bandwidth detection. This is accomplished through the use of an ActionScript file, and if the video is being streamed to Uncle Zotique in Prairie Dog, Alberta, who only has a 56k dial-up modem, the script will detect this and feed him the FLV designed for his particular connection. If I want to watch the same video, it will shoot me the high speed version appropriate for broadband.
The Flash Media Server is an expensive proposition. Still there are a few avenues open to you if cost is a consideration. You could, if you are not planning to be a heavy user, set up an account with an ISP such as Influxsis in L.A. or NI Solutions in Toronto, who run Flash Media Servers. The next level of expense is to have an account with a Flash video streaming service such as Vital Stream or Akamai. These accounts are ideal if you have a lot of video that needs to be securely streamed. Finally, if you are a fan of open source, you may want to take a look at Red 5. Though it is still in beta, it has been getting a lot of attention in the Flash community, and a release version will most likely be completed within the next six months.
If you are looking to get into the video broadcast game and plan to use the Internet, you also might want to take a look at Brightcove. This site, which bills itself as Internet TV, is not an idea in search of funding or a buyer. Founded by Jeremy Allaire, the same guy who brought us ColdFusion, this site is getting a lot of attention from some major content providers as they look for ways of securely putting television shows, movies, and other content on line.
Now that you have an idea of the pros and cons of Flash video, and you know how to secure your files, it may be a good time to ask if we should stop this futile debate and look at Flash video in a totally different way.
Forget about FLV
I was at the MX North Conference in Toronto a couple of years back, and had the pleasure of listening to the keynote delivered by Jeremy Allaire. At that point in his career, his company had just been purchased by Macromedia, and Jeremy was doing the conference circuit, talking up ColdFusion and Macromedia technologies.
The one aspect of his talk that caught my attention was his claim that the Flash Player was really a Trojan horse. As Jeremy explained it, practically every computer connected to the Internet had a major media player installed on the machine, and the users were just now turning it on. I liked the Trojan horse analogy because Macromedia had sort of gotten things going in 2002 by quietly slipping a video codec into the Flash Communication Server as part of its read/write capabilities. As John Dowdell recently wrote in his blog, “It definitely felt like a stealth movement the first few years, but then the floodgates opened.” Those floodgates were opened, in part, by people turning on the Flash Player and discovering it could play video.
Now that we have moved out of the novelty phase of web video, maybe we should stop looking at it as video and instead, as I pointed out in Part 1, of this series, look at it as content.
This is an important shift in perception. When you really think about it, YouTube, GoogleVideo, the New York Times and BrightCove don’t see the files as video. They see video as content to feed their sites. This content is shot using everything from cell-phone video cameras to full-bore studio rigs.
The fascinating thing about this is that video technology is available to everyone, and it is being used in ways I don’t think any of us could have foreseen. For example, here in Toronto, the local news station City TV encourages its viewers to send in video of news events. Recently, a house blew up in a neighborhood, and that night’s broadcast featured footage of the aftermath shot by local residents using their cell phones and DV recorders. This footage was also streamed from City TV’s web site. The production values were squarely in the realm of amateur, but I don’t recall anybody screaming at City TV about the poor video quality.
On a more specific level, Adobe and Apple have provided Flash developers and designers with a set of video tools that are about to change our perception of what is Flash, and what is video in a Flash movie.
I recently had the pleasure of doing a session at FITC Hollywood named “After Effects for Flash Designers”. The main point of the talk was Flash designers need to take a deep breath and not over-think it when considering how to incorporate After Effects content into their Flash designs. I demonstrated a number of techniques that showed how After Effects content can interact with Flash content on the Flash stage. One piece, featuring exploding text, audio, and a number of other effects caught the audience completely by surprise when I offered them a challenge: “Watch this piece, and you tell me what is Flash content and what is video content.”. I played the piece twice and not one of the hundred or so people in the audience could pick it out. When I opened the .fla file and showed them the Flash content, there was silence followed by a simultaneously whispered, “No way!”
Finally, debates about which format is best can stop. They are mostly irrelevant, because web consumers are going to watch just as much quality content as they will watch garbage. They are simply demanding it be available anywhere at any time and on any machine and, at this moment in time, the Flash Player is really the only technology that fits the bill. Can we assume from this, then, that the Adobe Flash Player product team is populated by soothsayers? Probably not. Macromedia and Adobe did get lucky, though that Flash video’s rise came at the same moment that online video content became cheap enough to give away.
Got something to say?
Share your comments with other professionals (5 comments)
Related Topics: Convergence, Flash
Tom Green is a professor of Interactive Multimedia, through the School of Media Studies at Humber College in Toronto. He is also a speaker, and the author of six books, including two recent ones on Flash and Flash Video. An Adobe Community Expert and a Community MX partner, he believes the amount of fun we have in this business should be illegal.