On Dec 22, 2005, at 4:00 PM, Yuichi Motai wrote:

> Thank you for your suggestion. During the break, Andrew and I will  
> find out an optimal way to upload video stream using MT framework.   
> I hope that I can announce what I am handling for my class blog in  
> the next semester.

Dear Yuichi, Andrew, and others:

I'm wondering, Is the "streaming" essential to what you want to  
accomplish? You can put video on the web without streaming, and in  
the process, often save yourself some trouble and frustration. I  
submit that in most situations, streaming video is a bad idea.

A common question is, what is this streaming stuff, anyway? Digital  
Videos tend to be really, really big files: 10, 20, 60, 100 Megabytes  
or more. The size of the file is proportional to both the length of  
the video and the quality -- better quality means way bigger files.  
In a nutshell, streaming is a method of delivering video on the web  
in a manner such that the whole massive file doesn't need to download  
before the person can begin watching it: the video simultaneously  
plays and downloads. Several other characteristics of true streaming:

o once the user stops watching the video, it is gone -- even though  
it has been downloaded all or in part, it has not been saved to the  
users computer

o the software used to watch the streaming video deliberately makes  
it difficult to save the file, even if the user really wants to.  
Thank you, Jack Valenti.

o A third characteristic, but certainly not one to rely on, is that a  
particular streaming video may often come in an assortment of  
qualities and sizes, each associated with a particular target  
bandwidth. The viwewing software and the server communicate behind  
the scenes to select the version most suitable for the users  
connection (56K modem; 256K DSL, 756K cable modem, etc.) and delivers  
that one to the viewer. It should be noted that creating multi- 
bandwidth streaming videos takes more time and effort, and the  
automatic selection process sometimes makes a bad choice, forcing  
someone with a fast connection to watch a poor quality 56K version or  
gagging a modem user with a file that is so big they only see a a bad  
slideshow with choppy sound.

o Live video from live events must always stream

o Streaming videos require a streaming video server: special software  
on the server that performs the bandwidth negotiation and delivers  
the video using special web protocols (e.g., RTSP as opposed to  
HTTP). Sometimes these protocols get blocked by firewalls.

UVM supports several different streaming services. There is some UVM  
specific documentation here:

	http://www.uvm.edu/cit/streamingmedia

As it says there, we support RealMedia, WindowsMedia, and QuickTime  
streaming media files. The documentation describes where and how to  
upload the files to our streaming servers, and how to access them  
once they are uploaded.

What the documentation does not describe is how to create the files.  
There are dozens of ways to create suitable files, and different  
people and different vendors will tell you different things about  
which is "best."

QuickTime movies exhibit a feature not available with Real or Windows  
media, something called "progressive download" or "fast start." If  
stored on a regular web server rather than a streaming server, the  
movies will begin to download (and save themselves to disk somewhere  
-- and once downloaded, usually allow the user to save the movie on  
their desktop or elsewhere with little or no fuss). Once a sufficient  
quantity of the file is downloaded to allow it to begin without  
catching its own tail, the movie starts to play. In most cases, a  
video of pretty good quality can be created that downloads so fast it  
will begin playing immediately. In this situation, performance  
actually exceeds that available from the streaming server: see this  
example:

	http://www.uvm.edu/~waw/movies/wdi05hs2b-2.html

In part because of this feature, my personal preference is QuickTime:  
it is relatively ubiquitous: most of the major film studios release  
their on-line trailers in Quicktime format, and QuickTime must be  
installed on every Mac and Windows computer associated with an iPod,  
which of course every kid has. If the kid has a video iPod, they can  
download the movie to that and watch it there. In most cases, it is  
unnecessary to go through the fuss and bother of streaming the video  
(saving it in special format, uploading it to special server,  
accessing it with a special URL and HTML syntax). And all the tools  
needed to create the movie come standard on any Macintosh.

As far as choosing between Real or Windows go, I think it's a tossup.  
If the file is available in almost any other format, you can download  
and install RealNetworks RealProducer basic for free and use that to  
create RealMedia files. If you are producing your own movies from a  
DV camcorder, and your PC has an IEEE 1394 "FireWire" port or CardBus  
adapter, you can create Windows Media files using Windows Movie  
Maker, pre-installed on all XP systems.

- - - - - - - - - - -

In the context of Movable Type at UVM, one barrier against using  
video of any sort is the File Upload Size limit. I can't recall what  
that limit is, but it is sufficiently small to discourage uploading  
video files of any great length using the Movable Type web interface.  
Also, if true streaming is a necessity, the video needs to live on a  
different server anyway.

As Timothy Fox has noted, Movable Type works just fine for Video  
Podcasting of small files. For larger files, it works just fine, too  
-- provided you upload the files elsewhere --- like your Zoo  
public_html folder

Streaming videos and Podcasting are somewhat antithetical: Podcasting  
implies downloading and saving files to watch later, streaming  
implies watch the file now and don't save it.