Adventures in Video

<a HREF="s1.mpg"><img src="picture.jpg" width="283" height="139" border=0></a>

On the other hand, embedded video that will come up where you, the website designer, want it to, and how you want it to as well—that is a whole different matter.

<div style="position:absolute;left:550px;padding:15px;
top:750px;width:240px;height:176px;text-align:center">
<OBJECT ID="s1" WIDTH=240 HEIGHT=176
CLASSID="CLSID:6BF52A52-394A-11D3-B153-00C04F79FAA6"
TYPE="application/x-oleobject">
<PARAM NAME="name" VALUE="s1">
<PARAM NAME="URL" VALUE="MoviePlus/s1.mpg">
<PARAM name="uiMode" VALUE="none">
<param name="ShowStatusBar" value="false">
<PARAM name="ShowDisplay" VALUE="false">
<PARAM name="autostart" VALUE="false">
<EMBED TYPE="video/mpeg"
SRC="MoviePlus/s1.mpg"
ShowControls="0"
showstatusbar="0"
showdisplay="0"
autostart="0"
NAME="s1"
WIDTH=240
HEIGHT=160>
</EMBED>
</OBJECT>
</div>

The div allows you to specify where on the page you want the video. The classid lets you specify you want a certain player—in this case Windows Media Player 7 or greater. The ID and names give you a way to reference the video with DHTML or a simple input button—to a degree. Here's the button codes that allow you to play the video from Windows Media Player if no controls are showing:

<div style="position:absolute;left:475px;padding:4px;top:750px;width:78px;
height:180px"><BR>IE Windows Media Player 7 or higher:<FORM><INPUT TYPE="button" VALUE="Play" onClick="document.s1.controls.play();"><BR><INPUT TYPE="button" VALUE="Pause" onClick="document.s1.controls.pause()"><BR><INPUT TYPE="button" VALUE="Stop" onClick="document.s1.controls.stop()"></FORM></div>

The only thing the buttons will play is Windows Media Player, which explains the message before the buttons. The controls part of the commands is recommended by Microsoft for Windows Media Player 7 or higher. People without Windows Media Player as their default player in the browser they're in need only double-click the video’s picture to make it run. The configurations below allow pictures to be double-clicked to activate them:

Firefox for the PC
Firefox for the Mac
Netscape for the PC
Mozilla for the PC (Mac?)
IE OS9 for the Mac
IE OSX for the Mac
Safari for the Mac
IE for the PC if Quicktime is selected as the default media player for MPEG 1 files
Anything if Quicktime is selected as the default media player for MPEG 1 files

Opera is a mystery that seems to work differently depending on whose computer, what version, and what day of the week, but it assuredly works with a text link, so I included one for Opera or other weird browsers, which works in ANY computer that allows video.

<div style="border:2px outset #eee;background-color:#dcc;width:60px;height:17px;
margin:2px 0 0 0;padding:4px 0 4px 2px">
<a HREF="MoviePlus/s1.mpg"><span style="font:normal 12px Arial, sans-serif"> All others</span></a></div>

Annoyingly, no double-clicking is allowed on IE for the PC if the default media player for MPEG 1 files is Windows Media Player 7 or higher. I have site visitors use the <INPUT> buttons described above instead—they're clickable form buttons. Paranoia regarding security holes in Microsoft’s ActiveX controls is the only reason I could come up with to explain why they'd forgo the greatly relished "double-click to activate" function. Apparently the ClickToActivate parameter was available in Windows Media Player 6 and before but the Microsoft site says it threw it out from Windows Media Player 7 on.

Also, only on Windows Media Player did the pictures (first frame) fail to show up before video activation. All other configurations allowed the picture to show up, for my MPEG 1 files. Microsoft paranoia again? Other file types were not as eager to show up immediately. Unless I chose to auto-start them with <PARAM name="autostart" VALUE="true"> and autostart="1". Then all file types in all configurations showed up. But the page I was building had 19 videos, so I was not terribly inclined to start them all up!

Apparently you can avoid all the extra clicking necessitated by ActiveX if you run various patches (scary and with various security ramifications) OR if you store your embedded object code in an external Javascript file and document.write or even innerHTML the code into the webpage. I didn’t bother.

I chose not to show any media controls by using <PARAM name="uiMode" VALUE="none"> and ShowControls="0", because I like the looks of images uncluttered by controls. If you choose to have them, your videos take up more room and are less aesthetic, but you get controls under each picture.

Now, why MPEG 1? The answer is both very simple and very complex. The simple answer is compatibility. MPEG 1 will play on everything but the kitchen sink. Even though the MPEG 1 files (average 1.6 megabytes) are a little over twice as big as the WMV files (average 750K) with the same content, in my tests, due to the very efficacious VC-1 codec underlying Microsoft’s WMV and ASF and other formats, it didn’t sway me to the better file type (WMV). (Incidentally, I used Video Editor in the MediaStudio Pro 7 application for some standard frame size conversions and capturing AVIs from the digital video camera, MoviePlus 5 for nonstandard frame size conversions from AVI to MPEG 1, and Windows Media Encoder [free] and Video Editor both for creating the initial WMVs and ASFs to test with.)

So MPEG 1 files are the most compatible. What's wrong with QuickTime’s MOV and QT files? Apple’s QuickTime player doesn’t come as part of Windows OSs like XP, 2000, 2003, or any others, so I cannot expect everyone to have it. Only QuickTime files version 2.0 or earlier can be played in Windows Media Player and the rest need the Apple player, and lots of people don’t have it because they don’t see enough reason to make the extra effort after getting an XP or whatever. What's wrong with RealPlayer RA, RM, or RAM files? Lots of people don’t have RealPlayer.

And Flash SWF files? It’s the most universally used player. Why not use Flash, since 98% of USA computers have it installed? Lots of reasons: Everybody can do MPEG 1 but 2% can't do Flash in the USA and the percent is much higher in the rest of the world. Macromedia claims their various player versions are fully forward and backward compatible, but forums on these subjects say otherwise. The learning curve is steep. The development packages are expensive. But the big reason is that the audio is often out of sync with the video and it’s blurrier than MPEG or WMV. I ought to know—I uploaded a MPEG clip with perfect video-audio sync to dozens of vlogs, which then converted it into Flash. There were audio sync problems everywhere, and the video image wasn’t all that clear. That synched it for me. No Flash until they get their act together. Additionally, their codec isn't as good as Microsoft’s VC-1 codec at compression that retains quality in a small file size.

What about plugins? Doesn’t Firefox have Windows Media Player plugins so WMVs and ASFs will work? Sort of. They don’t seem to work on lots of computers, including mine, and they don’t load automatically, and when I tried to run a WMV I was told "no plugins found." Zillions of people have XPs like mine so just don’t count on Windows Media Player on Firefox. Check out http://forums.mozillazine.org/viewtopic.php?t=206213 if you want the bejezus scared out of you with all the scary ways you can experiment with your machine to try to get working plugins. When I read that I "might end up having to reinstall Windows" I ran away screaming "no thank you!" I have 4 words for Firefox: Get it together, guys!

And other Browsers’ plugins? Lots of problems, "not found"s and incompatibilities. I have enough problems, thank you very much! Flash plugins seem the most reliable.

Anyway, MPEG 1 files do exactly what you hope they will (except for taking up more room than you'd wish). They show up right away even with no auto-start, except on later Windows Media Players. They look fine at 30 fps—my choice and their best frame rate. They run with double-click, except on later Windows Media Players. They don’t need a plugin beyond the TYPE="video/mpeg" which is apparently universally found. They can be created and used at nonstandard frame sizes like the 240 x 176 I chose (which is a VC-1 codec size, not an MPEG 1 size), as long as you have something like MoviePlus 5 or MediaStudio Pro 7 or 8 to make them with. MPEG 1 is most efficient at its standard frame size of 352 x 240. (MediaStudio Pro 7 or 8 is a better application for doing serious work, but it isn’t that good with weird frame sizes, refusing to have anything to do with even loading that 240 x 176 size. MoviePlus 5 found no problem with it—you have to copy an old format from their dropdown list, rename the copy, edit it, select to enter nonstandard sizes, and then you're all set.)

Anyway, if you have only one video on a page, auto-start is warranted as long as it will not take very long to load, and showing player controls makes sense too, since they won't be able to replay it by clicking on the picture if they have a later Windows Media Player. Or use my form input button method for Windows Media Player.

The classid, as stated previously, lets you specify you want a certain player—in this case Windows Media Player 7 or greater. I couldn’t get Windows Media Player to work in IE or elsewhere without this classid, so it was necessary to include it since IE and Windows Media Player are all that some people have. It doesn’t force Windows Media Player on anyone unless their default media player is Windows Media Player.

I wanted to use DHTML to avoid showing the input buttons with Play, Pause, and Stop on them unless someone was in Windows Media Player. I also wanted to use DHTML to change the instructions from double-clicking the picture to pressing the Play buttons if they have Windows Media Player. But there is no reliable way of detecting their default media player. It is useless to detect players installed on their system, since many computers have several. I had QuickTime as the default player while running IE5.5, for example, but then I switched the default back to Windows Media Player. With QuickTime, the MPEG 1 played with double-click and used the EMBED tag but with Windows Media Player reset as the default player, the MPEG 1 played with my INPUT buttons from the OBJECT tag. I tried Javascript in the OBJECT and EMBED tags, code that would hopefully detect which tag was being used and change the instructions accordingly, but to no avail. The W3C says the onload attribute is good only for FRAMESET and BODY elements, not OBJECT. W3C doesn’t recognize that the nonstandard element called EMBED even exists. Perhaps I'm missing something here—if so, contact me, please.

I could have used the info here to play the embedded MPEG 1 file in the OBJECT tag from a link: http://www.w3.org/TR/html4/struct/objects.html#h-13.3.4

But in order to play the EMBED’s video with the play() method, I would have to load and install special QuickTime, RealPlayer, or Flash plugins, and each would have its own syntax and parameters and methods. To ask for a QuickTime plugin, which I did not do:

<embed src="sample.mov" type="video/QuickTime" width="200" height="240">

To ask for a Flash plugin, which I did not do, you at least need this MIME and plugins link (and rumor has it there's no auto-plugin detection):

type="application/x-shockwave-flash" pluginspage="http://www.adobe.com/go/getflashplayer"

The reason I used HEIGHT=160 in the <EMBED> and HEIGHT=176 in the <OBJECT> is that the silly <EMBED> player was giving me half a control underneath it even though I had opted not to show controls or anything else:

ShowControls="0"
showstatusbar="0"
showdisplay="0"

This <EMBED> tag is how many people choose to embed videos for non-Microsoft browsers, even though it’s not a very legitimate tag in the World Wide Web Consortium (W3C) documents. Maybe the crappy way it renders controls is why Microsoft IE opted for encouraging people to embed videos with the <OBJECT> tag—which is the standard, "legitimate" way. This tag pays attention to my HEIGHT=176 code, taking it seriously—as it should. The 160 height is simply what it took to make the problem go away with the <EMBED> tag. Go figure.