What are the best options for serving/editing video
Ted Byers
(asf, avi, mpeg, &c.). There is a main clip and a suite of
introductory clips, one of which we splice to the front of the main
clip. We can either splice the clips before deploying them, of when
the clips are requested.
Right now, the only tool I have for splicing on demand is asfbin
(which works fine and is fast), but it only supports asf files. We
don't want to do anything fancy (no special effects, &c.), just record
the content, splice a personalized intro to the beginning of the main
body of the video, and be able to serve it to clients.
There are two issues we face.
1) Can all potential viewers view the video in the format it is
provided? (assuming the client is using reasonably current client
software - we can safely ignore, for example, client software that
used to run on DOS, Windows 95, &c.)
2) The file (the final clip runs less than 2 minutes) has to be
delivered in less than 20 seconds.
Is there one format that we can use that provides good quality video,
good compression ratios, and is universally supported?
If not, is there a small, manageable set of such formats and a way to
determine (using something on the client side) that can tell us what
format to send to a given client. We email the 'client' a link to the
video we serve, and need to ensure the video is displayed quickly and
reliably. Of course, the best possible result is if the video can be
displayed almost instantly.
Thanks
Ted
Richard Crowley
> Right now, we can record video and save it in a variety of formats
> (asf, avi, mpeg, &c.). There is a main clip and a suite of
> introductory clips, one of which we splice to the front of the main
> clip. We can either splice the clips before deploying them, of when
> the clips are requested.
The preferred format(s) for saving and editing video are NOT the
same format(s) that are preferred for distribution over the internet.
Formats for storing and editing should be optimized for minimal
loss to preserve quality in subsequent editing. While formats for
distribution are optimized for small size vs. performance to make
them play faster.
> Right now, the only tool I have for splicing on demand is asfbin
> (which works fine and is fast), but it only supports asf files. We
> don't want to do anything fancy (no special effects, &c.), just record
> the content, splice a personalized intro to the beginning of the main
> body of the video, and be able to serve it to clients.
Note that ASF is merely a container file (like AVI or MOV). It could
contain video/audio encoded by any number of different codecs at
various rates. The higher-rate, less-lossy (bigger) versions would
likely be appropriate for production.
> There are two issues we face.
>
> 1) Can all potential viewers view the video in the format it is
> provided?
No. Potential viewers must have a compatible player and
codec installed to allow playing any video file. Probably the
most widely-available video format already installed on your
viewers' computers is Flash. It doesn't have the PC-bias of
Windows Media nor the Mac-bias of QuickTime. The Adobe
viewer stuff is likely pre-installed on more PCs and Macs than
any other video player.
> (assuming the client is using reasonably current client
> software - we can safely ignore, for example, client software that
> used to run on DOS, Windows 95, &c.)
So then are you saying that you don't want anyone to
see your video if they have an older machine?
> 2) The file (the final clip runs less than 2 minutes) has to be
> delivered in less than 20 seconds.
Are you are talking about internal customers on a corporate
network or some special case which you didn't mention?
Otherwise this is pure fantasy. You have absolutely no control
over how fast anything is delivered over the public internet.
Particularly large payloads like video.
> Is there one format that we can use that provides good quality video,
> good compression ratios, and is universally supported?
IMHO, Flash.
> If not, is there a small, manageable set of such formats and a way to
> determine (using something on the client side) that can tell us what
> format to send to a given client.
Unless you get a client's preference beforehand, they will open
your link/file with whatever player they have installed that opens
the file format in the link you sent them.
> We email the 'client' a link to the
> video we serve, and need to ensure the video is displayed quickly and
> reliably. Of course, the best possible result is if the video can be
> displayed almost instantly.
If you want to minimize latency before it starts playing, then host
your video content on a fast server with a big pipe that is configured
to do video streaming.
Ted Byers
On Dec 9, 8:07 pm, "Richard Crowley" <rcrow...@xp7rt.net> wrote:
> "Ted Byers" wrote...
> > Right now, we can record video and save it in a variety of formats
> > (asf, avi, mpeg, &c.). There is a main clip and a suite of
> > introductory clips, one of which we splice to the front of the main
> > clip. We can either splice the clips before deploying them, of when
> > the clips are requested.
>
> The preferred format(s) for saving and editing video are NOT the
> same format(s) that are preferred for distribution over the internet.
> Formats for storing and editing should be optimized for minimal
> loss to preserve quality in subsequent editing. While formats for
> distribution are optimized for small size vs. performance to make
> them play faster.
>
I'd guessed as much. In our situation, the production guys are
responsible for any editing up to the point of deploying the video.
The most my code has to deal with is simply splicing two clips
together (unless we find it necessary to to do that before deploying
too). The thought of doing that on demand was due to observing that
we'd need about 2000 introductory clips to cover 95% of the first
names we find in our data. We thought we'd be able to save a lot of
space by saving 2000 clips saying, basically "Hello Michael", "Hello
Richard", &c., and then splice them onto the clip containing the
merchant's main introductory message. (Yes, this is to be applied to
support a number of merchants' customer relationship management
efforts, trying to make their messaging more personalized.)
> > Right now, the only tool I have for splicing on demand is asfbin
> > (which works fine and is fast), but it only supports asf files. We
> > don't want to do anything fancy (no special effects, &c.), just record
> > the content, splice a personalized intro to the beginning of the main
> > body of the video, and be able to serve it to clients.
>
> Note that ASF is merely a container file (like AVI or MOV). It could
> contain video/audio encoded by any number of different codecs at
> various rates. The higher-rate, less-lossy (bigger) versions would
> likely be appropriate for production.
>
Yes, so much I have learned over the past few days, in examining the
material I have found searching the web for relevant information.
> > There are two issues we face.
>
> > 1) Can all potential viewers view the video in the format it is
> > provided?
>
> No. Potential viewers must have a compatible player and
> codec installed to allow playing any video file. Probably the
> most widely-available video format already installed on your
> viewers' computers is Flash. It doesn't have the PC-bias of
> Windows Media nor the Mac-bias of QuickTime. The Adobe
> viewer stuff is likely pre-installed on more PCs and Macs than
> any other video player.
>
I'd guessed as much, but that transforms the question as to what
codec's are supported by the widest variety of installed viewers (I
suppose on Windows the Media Player is always present, whether the
user has installed another or not), and thus the most widely
installed. Is there one or more that are installed everywhere?
> > (assuming the client is using reasonably current client
> > software - we can safely ignore, for example, client software that
> > used to run on DOS, Windows 95, &c.)
>
> So then are you saying that you don't want anyone to
> see your video if they have an older machine?
>
That might be a consequence of what we deploy. But remember DOS is
now more than 20 years old, and since the days of DOS there have been
many improvements in the technology available for viewing video over
the web. We don't want to be crippled by restricting ourselves to
decades old technologies.
> > 2) The file (the final clip runs less than 2 minutes) has to be
> > delivered in less than 20 seconds.
>
> Are you are talking about internal customers on a corporate
> network or some special case which you didn't mention?
> Otherwise this is pure fantasy. You have absolutely no control
> over how fast anything is delivered over the public internet.
> Particularly large payloads like video.
>
OK, I guess I should have framed that in probabilistic terms. I am
working on the general case of sending files over the web. And the 20
second constraint was given by the marketing guys. But it should be
seen as an average, assuming we have a good host with plenty of
available bandwidth. And this can probably be viewed more narrowly
since the merchants involved have a target market comprised almost
entirely of subpopulations in Canada, the US, and the more highly
developed countries in the British Commonwealth; places where
highspeed broadband is becoming the norm, if it isn't already. It is
expected that those who don't have fast broadband connections through
their ISP already know that videos are likely to take longer to
download and will expect to have to wait when they click on a link to
a video. But, I am told, those who have good broadband connections
are an impatient lot and won't wait more than 20 seconds for video to
start playing.
> > Is there one format that we can use that provides good quality video,
> > good compression ratios, and is universally supported?
>
> IMHO, Flash.
>
Thanks.
> > If not, is there a small, manageable set of such formats and a way to
> > determine (using something on the client side) that can tell us what
> > format to send to a given client.
>
> Unless you get a client's preference beforehand, they will open
> your link/file with whatever player they have installed that opens
> the file format in the link you sent them.
>
We can't get that preference at this stage in the relationship between
the merchants and their clients. This part of the question amounts to
considering whether or not there is a format that is universally
supported, and if not is there a way to have the clientside software
tell us what formats are supported on the client side?
> > We email the 'client' a link to the
> > video we serve, and need to ensure the video is displayed quickly and
> > reliably. Of course, the best possible result is if the video can be
> > displayed almost instantly.
>
> If you want to minimize latency before it starts playing, then host
> your video content on a fast server with a big pipe that is configured
> to do video streaming.
We are in the process of setting up a decent server with plenty of
bandwidth, and I'd already planned on experimenting with video
streaming. In fact, those experiments are scheduled to start today.
Thanks
Ted