Why embedded?

What is the point of embedding videos in web pages? I suppose it appeals to users who want to do as much of their day-to-day tasks in a web browser as they can, but I prefer to use dedicated programs (which is largely why I loathe office suites). Every single Flash video player I have encountered has been buggy atrocity of programming. My issues with them boil down to four points: 1) their UIs are unresponsive, especially when pausing and unpausing; 2) they don't adapt the buffer size to slow connections or give the user the option to control this, making almost completely unusable on slow connections; 3) they have ridiculously high system requirements; and 4) HTML already provided means for embedding video when Flash video players popped up. 1 and 3 are due to limitations in the Flash runtime, and 2 is at best unfeasible because of similar limitations, but is most likely because of laziness of the player developer. 4 is what really makes their continued use idiotic.

Back in 1999 when the HTML <object> element was standardised, Flash video had the advantage of not requiring the user to locate and install codecs and find a media-player plugin that supported them all, since the codecs and player could be embedded in the Flash applet and users would only have to install a single plugin instead of one for every new codec they encounter. Now, 15 years later, there are only a few dominant codecs and container formats, so if the web suddenly dropped Flash video and required users to install codecs, they would not have to do this for every obscure codec competing on the market. Staggeringly, however, vendors have not managed to make this much easier in the last decade and a half. As always, everyone has to do it their way, hence a different Flash video player on every website; and everyone has to have their ass legally covered, hence the reluctance to distribute proprietary codecs.

On Debian, for example, you can very easily install the VLC or MPlayer Mozilla plugins, which support most codecs and container formats, with a single command. If you're using Chrome, it seems to try and bundle everything.

A part of the HTML5 hype was the new <video> element, which was supposed to make embedding video as easy as embedding an image. How this was ever supposed to work is beyond me, and the interface as it is now looks very much like that of the <object> element. An image file has only one encoding: that of the image; a video file, however, has at least two: the container format and the video encoding, so one can not determine the format of a video file from the extension alone, which is a complication absent from embedding images. Of course, the client can just retrieve enough of the video file to have the complete headers and read that to find out, but then the HTML document does not tell the client everything it needs to know to tell whether it can play the video. But that's a separate issue; the problem here is that the video element solves nothing.

Viewing outside the browser

This brings me to the instructional part of this piece (which will be rather short), conveniently playing Flash videos outside of a web browser.

Updated 24 October, 2016

Upon further use of these tools, I have revised my recommentation: for downloading videos, youtube-dl is king, both for capability and site support; Livestreamer is made specifically for streaming services (such as YouTube Live and Twitch). As to how well it serves its purpose, I can not comment, as I never happen to watch streaming video.

If your connection is too slow to stream the video, or you want to download the video to keep, there is also cclive, which uses libquvi and libcurl, and handles special shell-characters in the video URL and title that you would have to do yourself if using the quvi --exec option with curl or wget. Livestreamer can do this itself with the --output FILENAME option.

quvi vs. livestreamer

From the user standpoint, quvi and livestreamer have similar and straightforward interfaces, but livestreamer is self-contained, while quvi is separated into two libraries and two frontends. From a hacker standpoint, I find the livestreamer codebase more navigable and easier to read than that of the quvi libraries. livestreamer also appears to be more actively developed (as of December 11, 2014), going by the “Code frequency” graphs on the GitHub repositories for livestreamer, quvi-scripts, libquvi, and quvi-tool.

Look, Ma, no Flash!

Both quviyoutube-dl and Livestreamer work without Flash, unlike most browser extensions for downloading Flash videos, which work by intercepting the HTTP requests made by the Flash video player. The downside to this is that they need specific scraping-code for each website, because they have to extract the video URL from video web-page, which will be different on every site.

Maybe one day the web world will come to its senses and Flash video will die, but until then, you have some workarounds.