Вы находитесь на странице: 1из 47


Multimedia Systems Design

Chapter 11
Creative System Development

 Upon completing this chapter, you should

be able to:
 Understand how to calculate and estimate
video file attributes and values
 Calculate the datarate for a given video file
 Understand the terms and concept related to
multimedia interface design
Deduction (root : deduce)
 Sometimes, we are not given all the data we need to plan out our
media in a multimedia system.
 For example, in order to figure out just how much compression a
certain video or audio codec would give us, we need to know what its
typical compression ratio is.
 This isn’t always available to us, especially since it depends on many
other factors such as color depth, resolution, number of channels,
variable or constant bitrates etc.
 So, one way is to extrapolate the information from whatever data we
do have.
 A video editor (like VirtualDub) will give you information about your
video file that can be used to extract other information.
Calculation of Video File Properties &

Resolution : 480x352
Frame rate : 29.97 fps
V. Compression : Divx Pro v5.2
V. Bitrate : 779 Kb/s
Audio : 32 KHz, 16-bitStereo
Audio Compression : MP3
Length : 48.5 minutes
File Size : 313 MB
What other information can we gather
from the attributes?

 Firstly, since 48.5 minutes occupies about 313 MB, we

know that 48.5 min x 2 = 1 hr 37 min = 616 MB = 1 CD =
full movie at near-DVD quality video and acceptable audio
 The aspect ratio is about 480/352 = 1.364 which is similar
to the 4:3 TV standard
 The bitrate or datarate for the video stream is 779 Kbits/s.
 This means that the video stream occupies some 779,000
x (48.5x60) = 2266.890 Mbits or about 270.234 MBytes of
the overall file size.
 Assuming the bitrate used is constant.
What other information can we gather
from the attributes?

 The audio stream = 313 MB – 270.234 MB = 42.766 MB

 From this, we know that for the audio stream;
Uncompressed size = (32000 x 16 x (48.5x60) x 2)
= 2979.84 Mbits = 355.225 MB
Compressed size = 42.766 MB
 MP3 Compression Ratio = 355.225/42.766 = 8.306
(remember, this is against uncompressed audio)
 The audio bitrate
= 42.766 MB/(48.5x60)
= 123.281 Kb/s or 61.641 Kb/s per channel
(assuming contant bitrate)
Is there more?

 There is more we can get from the initial attributes of the

 Whatever we have just obtained in the previous slide can
also be used to gather other information
 For example, in the same way as we calculated the audio
compression ratio, we can also calculate the video
compression ratio.
 Knowing of course, that uncompressed color video is
most likely RGB (or 24 bits per pixel).
 Sometimes, there are shortcuts to the calculations as
Is there more?

 Still, we must also realize that the compression

ratio of a high quality video codec against
uncompressed video will be very good or high.
 Most of the time, however, our source is either
DVD or VCD, so the ratio is much less because
these formats are in themselves, already
compressed; MPEG-2 and MPEG-1 respectively.
 Uncompressed
RGB Divx 5.2 (high ratio)
 MPEG-2 DVD Divx 5.2 (low ratio)
Container Format Overheads

 Every container format has some overhead (like header

info describing what's in the file).
 Overhead of any container format can usually be assumed
in %.
 By default and for ease of calculation, we assume it to be
 AVI and OGM have slightly higher overheads than
 The exact values vary a bit from source to source.
 AVI and OGM usually need a value between 1.0 and 1.5%
here and Matroska needs 0.5 or even a bit lower.
Container Format Overheads

 The effect of container format overhead on the file

size is usually negligible and sometimes
compensated by the fact that for example, 2-pass
encoding using certain codecs, actually result in a
smaller amount of video data than expected by
the bitrate.
Example Video File Attributes

 Resolution : 352x240 (NTSC)

 Color Depth : 24 bits (RGB)
 Frame rate : 29.97 fps (NTSC)
 Video Codec : Divx 5.3 (MPEG-4)
 Video Bitrate : 500 Kb/s
 Audio : 44.1 KHz, 16-bit Stereo
 Audio Codec : Mp3 (MPEG-1 Layer 3)
 Length : 90 minutes
 File Size : 450 MB
 Overhead : 1.5%

 Time
= 90x60
= 5400 seconds

 Total Video Stream Size (Uncompressed)

= (352x240) x 24 x 29.97 x 5400 bits
= 328129781760 bits (/8)
= 41016222720 bytes (/1024)
= 40054905 KB (/1024)
= 39116.118 MB (/1024)
= 38.199 GB

 Total Video Stream Size (Compressed)

= 500000 x 5400 bits
= 2700000000 bits (/8)
= 337500000 bytes (/1024)
= 329589.844 KB (/1024)
= 321.865 MB

 Video Compression Ratio*

= 39116.118 MB / 321.865 MB
= 121.53
≈ 121.5:1
 File Size – Overhead
= 450 MB – 6.75 MB
= 443.25 MB

 Total Audio Stream Size (Uncompressed)

= 44100 x 16 x 2 x 5400 bits
= 7620480000 bits
= 952560000 bytes (/1024)
= 930234.375 KB
= 908.432 MB
 Compressed Audio Stream
= 443.25 MB - 321.865 MB
= 121.385 MB
= 1018251182.08 bits

 Audio Datarate
= 1018251182.08 bits / 5400
= 188565.034 bits
= 188.565 Kb/s (/2)
= 94.283 Kb/s per channel

 Audio Compression Ratio*

= 908.432 MB/121.385 MB
= 7.484
≈ 7.5:1

* The compression ratios for audio and for video are against their theoretically
original, uncompressed sizes. Most of the time, compression is performed on
files that have already been compressed so the ratio is much lower (e.g. DVD to
Interface Design
What is the interface?
 Put simply, the interface is the means by which
your clients or users will be accessing and
utilizing the multimedia system.
 It is serves as a translator or bridge between
man and machine.
 It must be easy to use or user-friendly.
 Otherwise, your clients will not be able to get full
benefit from the system; or worse yet, be unable
to use it at all.
What qualities should an interface

 Think of the interface as your translator.

 One that conveys to you what the machines is
saying and translates your commands to the
 You will be dealing a lot with this interface.
 So, an attractive interface is good one.
 People are naturally attracted to beauty.
 Aesthetics should not be overdone, though.
What qualities should an interface
 Also, an interface that is easy to understand and
conforms to real world metaphors that people are
used to, helps.
 For example, clicking an ‘X’ would signify a
negative command (delete, cancel etc.)
 Well-designed interfaces are uncluttered but
depict an appropriate level of sophistication at the
same time.
 It must not look uninspiring, patronizing or
Rudimentary Interface
*not to be taken as an example, but only as an elementary reference for illustrative purposes

which might
also have
tool tips


Simple navigation Large display area for content

Display Area
 Your display area (the main window in which your
multimedia content will appear) should be sufficiently large
to show everything you need to without having to scroll in
any direction.
 It also must be large enough to show things such as
images, video and animations in their original resolution.
 If the multimedia object has to be scaled down to fit, it will
cause distortion.
 The display area should be static, which means it doesn’t
change or move from one page to another.
Display Area

 The borders around the display area should also

be uniform.
 If one is larger or wider than the other, it will give
the impression that the display area is not
 Use the ruler and grid features of your multimedia
authoring tool to make certain that the number of
pixels on each side of an object (the borders) are
the same – so that whatever is shown sits in the
centre for optimal viewing.
•The controls to our multimedia system must be well thought out
and simplified.
•Basically, no need for anything repetitive or redundant.
•The first step is to figure out what kind of control abilities you
want to give the user throughout your system.
•More controls are better, usually.
•Navigation, being in itself, a form of controls (i.e. forward,
backward, jump to any point or screen in a minimum number of
clicks) is a must.
•Though this depends on what type of system you have, it is
usually required.
 Other controls might be necessary too –
 turn off the background music, make it louder/softer,
 change the music, change it back,
 VCR controls for video,
 zoom function for pictures,
 resize for video,
 a ‘print’ button,
 copy to clipboard,
 adjust font colors and size,
 save game,
 bookmark position,
 add a marker,
 export results to another program etc.

 Specifically, navigation allows the user to move from one

location or point in your system to any other.
 We have chronological navigation (linear), which is the
‘natural order’ of what you, the developer, intend the user
to follow.
 And then, we have non-linear navigation, which the client
can use to move anywhere within the application without
restraint; unless of course, it is detrimental to the system.
 For example, allowing the user to view answers (for the
first time) to a question before they have even attempted
to solve it.

•Navigation sometimes requires programming and

needs to be checked thoroughly anyhow.
•Often, the user is left stuck at a certain place or
lost because you didn’t provide a way out with
proper navigation.
•Really shoddy work leaves navigation buttons that
don’t even work.

 Only navigation and controls which have a use for any

given screen should be visible or included.
 For example, if your system suddenly widens, to provide a
cinematic experience of some video footage that you wish
to show, any controls that are in the way, or cannot be
used at that point, should be made invisible and only
afterwards, reappear.
 Also, new buttons, like VCR controls should appear just
for the video and then disappear when the movie clip is
 Aesthetics is sometimes necessary in a scenario such as
depicted above.
 For example, the ‘disappearance’ and ‘appearance’ of a
new set of controls should follow your overall theme.
 This could mean sliding away into a box with a mechanical
sound following it.
 Nevertheless, too much variance in controls is not
 So, think carefully what and where you need everything to
 Then, try to keep the controls standard and easy to
understand. Good planning is key. It really is.

The interface is such a

concern these days, that many
programs offer ‘skins’ which
enable the user to determine
how it looks on the exterior.
This sometimes improves
navigation and gives people a
choice over the default, ‘dull’
interface. Skins aren’t always a
good idea, however.
Thinking Outside The Box
 Always learn to think beyond confinement.
 Navigation in a multimedia system cannot only be done using an
arrow key to the left and right lower end corners of the screen.
 There are many metaphors you can use which might improve over
what is conventional.
 For example, a gamepad navigation interface.
 Look for examples and inspiration in the things you are used to, like
movies, video games and books.
 All of these are not only sources of entertainment, but also
 You only need to apply what you see in the context you require.
 In fact, it might even let you spawn something original as a result.
Thinking Outside The Box

 A multimedia system is actually quite

 There are no fixed rules for getting good
reviews (or marks).
 However, a system which was developed
for the right aims (to deliver the message
effectively), usually succeeds in the end.
How To Optimize The System
 Optimization basically means to achieve the same
effect while using less materials or resources in a
multimedia system.
 In other words, it includes simple things like using
PNG graphics instead of BMP, compressing the
appropriate images to GIF instead of JPEG, using
a better video source or better compression
codec and so forth.
 It also means to make certain that you have
charted out the flow and paths of your system
thoroughly – so that it is easy for you to check
that every link and element in the system works.
How To Optimize The System

 Go through this flow of the system back and

forth several times with different permutations.
 A multimedia system is basically a fancy piece
of computer software, so it too needs to be
tested for error handling and so forth.
 Make sure the system is capable of handling
itself in case of exceptions or faulty input.
Multimedia Systems Flow Diagram

The system flow diagram should show how everything connects to

everything else. This way, the problem of broken/missing links can be
solved before it even begins.

*sample system diagram

 Other kinds of optimization involves subtler
improvements and enhancements.
 For example, choosing a better voice or improving
the quality of narration in the system.
 Also, making the transition from one page to
another more interesting than it currently is.
 This can be done by creating a special sound or
effect just for that purpose.
 What about pictures?
 We have already learnt that choosing a high quality picture is
the way to go.
 But what about the right picture both visually and technically?
 Let’s assume, in our system, we want to depict the progress
of computer graphics on the PC since its early days up to the
current state, we must not only choose a good quality picture
but we must just as well be knowledgeable about the latest
technologies to give the most precise explanation and clear
message to the user.
 Your system must be checked for factual errors and being up-
The Right Colors
The Right Colors
 Very often, an otherwise good system, is ruined because
of poor color selection.
 Follow the basic rules of color like good contrast, being
well-balanced and not being too gaudy.
 Use colors for more than just aesthetics, but also to suit
your theme.
 For example, a mysterious or masculine presentation
would contain more dark colors like black and shades of
blue, while something feminine or for young children
would contain brighter and happier colors, like pink and
The Right Colors
 Something horrific would do nice with
some red, to depict blood and mayhem.
 A system that explains about meditation or
health would do well with white, for purity.
Planning a Checklist

 There are many things you need to make

sure of before you deliver the multimedia
system to the client.
 Most of these things have been covered
quite thoroughly, but there will be other
concerns which only you, as the
developer, would know for your particular
Planning a Checklist
 It helps to make a list (brainstormed from your
group discussions) of what needs to be checked
and re-checked.
 The first thing is to expect some changes.
 Don’t be afraid to improve on the shortcomings
you find.
 Second, don’t be lazy to do it.
 It will not go unnoticed.
 Someone is going to notice and remember it.
Sample Checklist

 The system meets all the requirements and

delivers the message effectively.
 All links, navigation and media elements have
been checked and re-checked for functionality.
 There are no dead links or dead ends,
backwards and forward.
 Alpha and beta testing has revealed several
bugs which have been removed.
 There are no spelling or factual errors.
Sample Checklist

 All references that are necessary have been cited

properly (in the documentation).
 The system is optimized to use the least possible
processing requirements but delivers the highest quality
content available.
 The layout of the interface is good and easy to use, yet
is not dull and unattractive.
 The colors used best suit the theme, content and client