[Dspace-general] Week 4: Bitstream types

[Mark H. Wood]

Two challenges we've run into here are isochronous media (audio,
video) and multimedia presentation packages.

Audio and video are difficult for a couple of reasons.  One problem is
that they tend to be LARGE documents, which makes downloading tedious,
yet the only way to get one out of DSpace is to download and then
present.  A suitably designed application *could* pull byte-range
chunks out of the document and present them more quickly, but then
there is the other problem: unlike text or drawings which just sit on
the screen and can be delivered at any reasonable rate, audio and
video evolve in time and must be presented at a constant (high) rate
of delivery.  One of the fundamental design decisions on which the
Internet is based is that timing and even ordering of packet delivery
are not critical.

Both of these problems point to the use of a streaming service.
Streaming clients expect to pull the material a bit at a time, and
streaming protocols are designed to minimize timing problems.

What we've tried is to deposit a SMIL wrapper as the DSpace bitstream
and have that point to the actual presentation over on a streaming
service.  It works on some browsers, but SMIL is not yet as widely
deployed as we might wish.  One could do the same thing using
e.g. RealMedia RAM pointer files, but that ties one down to a single
vendor.  We really ought to support open standards as they become
available.

Multimedia presentations take us to the next level of challenge,
because they include a user interface program which lets the user
control the delivery of the presentation.  All the MM creator packages
I've seen seem to assume that the result will be stamped on CDROMs and
physically delivered.  SMIL should eventually be the answer to this
problem, since this is what it was really designed for:  it's a
language for defining buttons, projection areas, timing and
synchronization for access to multiple streams of content.  That's
when the MM package makers get on board and leave their proprietary
non-networkable baggage behind.  We haven't come up with a
satisfactory way to deal with such content until the dawning of that
glorious day; our best response right now is to dump .iso images into
the repo., and that's not at all what the user expects.

DSpace can't do much about these problems, but the DSpace community
can push the makers of producer and consumer software to build
standards-based products.

DSpace might be able to coordinate more closely with a streaming
service by making it simple for that service to access bitstreams
stored in DSpace.  People who operate institutional streamers tend to
see the content as ephemeral, which means that we wind up setting up
our own streamer to ensure long-term availability.

++++++++++++++++++

There's one other problem I've noted with AV material:  production
values.  We are often presented with horrors such as an AV recording
made by pointing a camera at a projection screen while the presenter
talks his way through a PowerPoint slideshow, and meetings that start
with 10-15 minutes of unintelligible hubbub before the meeting comes
to order.  Technology can do nothing about this.  We need to get the
word out that people should think about preservation in advance and
plan their capture of presentations.  Simply editing down to something
presentable will help in some cases, while in others the presentation
would benefit from being designed over again with network delivery in
mind (transcript+slides instead of chalk-talk recording, maybe
packaged with SMIL to make a neat whole of it).

This is really an extension of what we do in advising depositors about
file formats that work well for long-term preservation.

-- 
Mark H. Wood, Lead System Programmer   mwood at IUPUI.Edu
Typically when a software vendor says that a product is "intuitive" he
means the exact opposite.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
Url : http://mailman.mit.edu/pipermail/dspace-general/attachments/20080908/11625575/attachment.bin