(sorry, I have been out of town and away from discussion groups for a couple of weeks)
Up through HTML-4, HTML did not have any mechanism at all for specifying video playback. What HTML offered instead was a mechanism for embedding an object into the web page, that object would then be a specific browser helper application. Depending on what the web designer specified, that could be the QuickTime Player Plugin, the Flash Plugin, the Windows Media Plugin, the RealMedia Plugin, or just about anything else. Since this is the QuickTime discussion, consider this simplified EMBED tag for QuickTime:
<embed src="current.mov" width="320" height="256" pluginspage="http://www.apple.com/quicktime">
This is the "old way" of doing it. This tells the browser to reserve a box 320 pixels wide and 256 pixels high, and fill it with a file called "current.mov". It is then up to the browser to figure out what to do with a file of type "mov". If the browser is configured correctly, then the browser would check its list of helper applications, realize that "mov" files are handled by the QuickTime Player plugin, and would pass the video file to the plugin. The plugin then draws video on the box reserved by the browser. If no plugin is available, the "pluginspage" variable tells the browser where to tell the user to go to get a copy of the necessary plugin.
The nice thing about this is that the web page doesn't actually specify what is supposed to be done with the file. It just supplies the file and says, "You figure out what to do with it." If you have QuickTime, then QuickTime will play it. If you have RealPlayer, then RealPlayer will attempt (probably unsuccessfully) to play it.
That's how it worked for QuickTime. For Flash, they did some other tricky things. Specifically, the file passed to the browser is not the video file, but rather the Flash player, and then a parameter passed to the player tells the Flash player plugin where to get the video file. This makes it even more difficult to figure out where the video file is, but the abstraction of the embed code made that the most powerful way to do things.
In HTML-5, there is a new VIDEO tag. This tells the browser that the element in question is, in fact, a video clip. This means that we are back to the old way of doing things again. Now, in HTML-5, the browser has more information about the object being embedded: it now "knows" that it is a video file. It is possible within the VIDEO tag to specify what plugin should be used to play the file, but it isn't necessary. Instead, the video gets passed to the browser, and the browser uses whatever method it wishes to use to play the video. But the standard now gives more information to the browser simply because the browser now "knows" that this box it has reserved is VIDEO. That means that instead of being a black box wholly owned by the plug-in, the video box is now a document object with certain properties exposed. Whether it is handled directly by the browser or by a plug-in, the standard now specifies certain properties that can be manipulated with CSS and JavaScript just like the other page elements.
The best part of this is that the major browsers are building in mechanisms for handling video directly, either by passing it to QuickTime as Safari does, or by including a video playback component within the browser as Mozilla does. For Safari, that means the video can be any kind of video file that QuickTime can handle; for Mozilla the limits are a little more severe. There is also no reason that any browser could not pass the video file off to the native video rendering system on the operating system...QuickTime/Quartz/CoreVideo on MacOS; I forget what the native one is called on Windows. That allows for rendering directly on the accelerated video hardware on the machine, something normally not allowed by web plugins.
I hope that's mostly accurate... 8-)
