There are more than a score of software companies selling
video-streaming software. They all promise that their technology is far
superior to their competitor's technology, but what really separates
them? The biggest difference is how they route the video through the
different channels of the Internet. There are different ways computers
communicate through the Internet, and they call the different types of
communication protocols. Click here to learn more about protocols.
The video-streamers fall into four major categories. The first
category is the streamers that work only in the HTTP protocol. These
usually work right off of your existing web server. They also stream
video through firewalls with ease. Some of the HTTP-only streamers
require a plug-in to view, while others work with the browser alone.
The main disadvantage of the HTTP-only streamers is that HTTP is an
inherently slower protocol than other protocols.
The second category is the streamers that use multiple protocols.
These always require a plug-in to view, even if they cram the plug-in
into your machine without you knowing using Java. These streamers are
usually faster and more capable than the HTTP-only streamers, but they
do have trouble with firewalls.
The third category is the streamers that stream QuickTime movies.
These work with clips stored in Apple's QuickTime movie format only.
Some are playside-only streamers, which play a QuickTime clip as it is
loaded, without any special buffering on the server end of the data
exchange.
The fourth category is the Videoconferencing software packages. They
use a small camera connected to your computer to give you a "Jetson's
Phone". They use multiple protocols, and are designed to serve and
watch video at the same time.
Click here
to see a chart comparing the HTTP-only streaming software.
Click here
to see a chart comparing the multiple protocol streaming software.
Click here
to see a chart comparing the QuickTime movie streaming software.
Click here
to see a chart containing all three of the above charts.
Click here
to see a chart comparing the videoconferencing software.
MPEG4 How
Interactive MPEG4 Authoring Works
If you've used SMIL or VRML, you're halfway to being able to create
rich and powerful MPEG4 content. MPEG4 leverages both of these
languages to its own ends. But there are some differences that you'll
notice right away when you start working on it. SMIL is text-based code
that tells the video player where to get and how to play the media
elements in the movie.
With SMIL you have to distribute and keep track
of all the elements – the video, audio, any image files, etc - as
separate files.
MPEG4, on the other hand, takes a different approach.
It is a binary format that encapsulates all the media elements and
interactivity instructions within it, all wrapped into one neat
package.
The creation process is a bit like compiling computer code. You write
your code in XMT-O - "Extensible MPEG-4 Textual Format," a high-level
language that's based on SMIL 2.0. It's not the same as SMIL – they are
just enough alike that it's easy to figure one out if you know the
other; and they're just different enough that you'll drive yourself
crazy keeping them straight. Once you've finished your XMT-O file, you
run it through a tool that compiles the code and all the media files
into a single binary .mp4 file. Now you can admire your handiwork as it
plays back flawlessly.
There's also a lower-level MPEG4 textual language called XMT-A. With
its roots in VRML, XMT-A is far more complex to write than XMT-O. It's
a bit like writing computer assembly language code by hand. There may
be some high performance and other specialized situations when you'd
need to do it, but most people won't have to and won't want to.
Real
Examples
Frankly, I didn't know that my
watermark.mp4 example wouldn't work in
the RealOne and Quicktime players until I tried it. After
all,
both
have rich support for MPEG4 via the EnvivioTV plugin.
From the
information published by Envivio, Real, Apple, and IBM, it's not easy
to figure out what profiles and levels are supported by each player; or
which ones are required by the various features I choose to use in my
XMT-O code. Let's face it, out here on the cutting edge you have to get
used to living with uncertainty.