Prepared By
Arjun Satish (Sir. M. Visvesvaraya Institute of Technology, Bangalore)
Sudeep Nayak U. (Sir. M. Visvesvaraya Institute of Technology, Bangalore)
C o n t e n t s
1. Introduction
2. System Architecture Description
3. Detailed Description of Components
4. Reuse and relationship to other products
5. Design Decisions and Tradeoffs
7. Appendices
1. INTRODUCTION
This section introduces the SDS of the product StReAV, to be developed, to the reader.
1.1 Purpose
This SDS describes the function of our software, entitled StReAV. The development of
the software has been done modularly, meaning clear and well defined modules have been
made which take care of the various functionalities of our project.
The SDS is an integral part in the lifecycle of a project in
the sense that the actual design of the various modules is discussed in this document
which takes care of the various functionalities that this product aims to achieve.
Back to top
Main Section Title :
Font : Times New Roman, Bold
Size : 4
Sub Section Title :
Font : Times New Roman , Bold
Size : 3
Other Text matter :
Font : Times New Roman
Size : 3
Back to top
1.3 Scope of the Development Project
Many people have computers equipped with webcams these days. Most people
having mobile phones have a webcam equipped with it, which is not of much use
for a majority of the time, except for taking pictures and videos of special
moments .
The purpose of StReAV (Storage and retrieval of Audio and Video), is
to use the unutilized (processing) time to store and retrieve useful information, in
the form of audio and video, which the user might like to use. StReAV requires
the user to have a simple audio and video capturing tool such as a webcam, which
could be easily clamped onto the collar of a shirt. This would be plugged into a
computer, mobile phone or PDA/handheld device. The software captures only
required audio/video from the external device, preferentially, which could later
be used by the user to search a face, object or feature, and display related
matter such as the person's name, time last seen, memos related to the person,
or even feedback of other users on that particular location or object, if found
on a common public server. The user could stream the video onto a server, which
is hosted by a local service provider, to save space and processing time on his system.
StReAV also
comes with a tool for editing and sorting the previously captured videos and
audio. Considering bandwidth constraints for providing such a service, the
software uses minimal bandwidth by using a different format for the storage and
retrieval of related data such as video and audio.
Users of StReAV can utilize
the software for a variety of applications, such as to maintain a 'visual' diary
or log book, to find information about a particular object or feature, such as a
monument at a tourist spot; also to compare and find more information on
anything by looking at the feedback put up by other users of the software, on
the common public StReAV server. A person attending an important conference in
Japan can send updated information to his colleagues in France through the web
server. Appointments can be stored visually. Users of StReAV can recognize
objects/places/faces to the program, in order to increase its knowledgebase. The
program will then use this knowledgebase and its processing routines to give
results that the user wants to see.
StReAV Service Providers help in providing a
centralized data storage solution an option which will reduce the amount of
space required for data storage on the user's system. StReAV, the user
application, can be controlled in an easy to use Graphical User Interface (GUI)
. The StReAV Server can be controlled by the service provider, from anywhere
through an internet connection.
Back to top
1.4 Definitions, Acronyms, and Abbreviations
1.5 References
1.5.1 Related Articles
Eigenfaces for Face Recognition : Turk, Pentland
System calls and InterProcess Communication - www.users.cs.umn.edu/~bentlema/unix/
JPEG - www.ecn.purdue.edu
#Gtk+ IRC on EfNet
#Linux IRC on EfNet
Back to top
1.5.2 List of Books pertaining to the project
Sams' Teach yourself Linux, by Bill Ball and Stephen Smoogen, SAMS Publication.
Image Processing using C, by Phillips, BPB publications.
The GIMP Toolkit, by Peter Mattis (1998)
GTK+ 1.2 by Tony Gale
The Linux Webcam HOWTO
Video Demystified - Keith Jack
InterProcess Communications - Richard Stevens
Face Recognition Using Eigenfaces - Ilker Atalay
Recognizing Faces with PCA and ICA - Bruce A. Draper, Kyungim Baek, Marian Stewart
Colorado State University: Face Recognition
The first section of this document gives a brief idea of what exactly StReAV
is, and what is the need behind having it. Along with this background
information it gives an introduction of the document.
The second section throws light on overall
description of the user's application, functions, perspective, operating
environment, and the various modules and interfaces used.
The third section gives a description of each of the modules that have been listed.
The fourth section describes the features and how the software is reusable.
The fifth section gives details about the design decision taken by us in designing the
StReAV Server and client, which have led to both advantages and trade-offs.
The sixth section gives the appendices.
Back to top
2. System Architecture Description
The software is broadly divided into three modules:
There are basically two master modules which ensemble the software.
CLIENT MODULES | SERVER MODULES |
|
|
2.2 Structure and Relationships
The structure of the modules is explained below.
Control information is transferred between modules to achieve coherent working
Client module: This module allows the client to co-ordinate its activities. The module interacts with the various modules that are listed below.
The login module: The client logs on to the StReAV server using a username and password, which is allocated by the administrator of the server. The client needs to log on for information storage and processing needs.
Video capture module: The video capture module allows the software to access video in the form of images from the external webcam device. This is available in a buffer which is read and stored. If the user requests feature recognition of a particular image, it is sent to the server. This module also recognizes if the data recorded is to be archived.
Memory management module: The Memory management module looks after the amount of memory being used for storage on the machine. When this reaches a certain limit, the complete content is sent to the server for archiving.
Information/Audio/Video display module : This module displays the video stream on the user's screen. It can be used to take notes in the form of text, for that particular video/image.
Video editing module: This module is used to delete a frame or a set of frames from the video stream.
Data transfer module:
This enables data to be transferred between the client to the server, which may also consist of control signals.
Server Module:
All the server side activities are controlled by the server module. Its configuration is determined by the admin.
Login module:
Used by the clients to logon to the server for requesting feature recognition or for storage or retrieval of data. Also used by the administrator to logon and change the configuration of the server.
Feature recognition module:
Used to compare the image received from the client to a set of images that have been declared either in user's data or in the public domain.
User Maintenance Module:
The administrator controls the maintenance of users such as addition and deletion of users using the User Maintenance module.
User Database Module:
Used to recognize files and data belonging to the user.
Compression, decompression and file encoding Module:
Used for the compression of data to be stored. Also used to convert the data received from the clients into a suitable format for storage and retrieval.
Data access control:
Used to control data access to the clients. Clients can only access files created by them or common files that are available to the public.
Back to top
2.3 User Interface Issues
Users
Users will log in to the StReAV server with a log in name and password. If this is successful, the person is given access to the video,audio files. He is then given the freedom to edit the streav files, name the new unrecognised people and even give certain files priority (regarding backups). He can share the material with the world or keep it as a secret. The public material will be treated as a blog. User interface is through a GTK window, the client program runs on the user's PC, PDA or mobile phone. The video device interface allows video capture, which is streamed to the StReAV server.
Administrators
These people can moderate content on the server. They are also responsible for handling e-mail from various clients regarding complaints, comments and taking appropriate action to heed their commands. They can -
3.1 Server Module
The Server Module consists of the following child modules. They are basically responsible for the various
operations that the server needs to do in order to service a client. It calls the required module at the time it is required.
Back to top
3.1.1 Group Maintenance Module
Used to maintain the database of members. i.e., to add new members, remove those that are using StReAV for unwanted activities.
Type | server module | |
Purpose | To add, remove users | |
Function | To restrict access only to members of the StReAV server. | |
Subordinates | Not Applicable | |
Dependencies | Stand alone module. | |
Interfaces | Interface through admin interface, to add name, username and password; to remove user. | |
Resources | Not Applicable | |
Processing | Adds or removes a user from the server database. | |
Data | The user's real name, username,password, space allocated on server. |
3.1.2 Authentication Module
To authenticate a user of StReAV.
Type | server module | |
Purpose | Authenticate that a person is a user of StReAV, registered on the server. | |
Function | Checks if the person's username and password match, to give access to his files. | |
Subordinates | Not Applicable | |
Dependencies | None. | |
Interfaces | There is no interface. It runs directly from the terminal. | |
Resources | Not Applicable | |
Processing | When a user tries to login, it checks if the name is present in the server's database. | |
Data | The client's username and password. |
3.1.3 User Information Module
To store information about the user and his files
Type | Server module |
Purpose | to allow access to files, only to the file owner. |
Function | It checks the files that the user can access. It adds names of files that are created on the server. |
Subordinates | None. |
Dependencies | None. |
Interfaces | There is no interface. It runs directly from the terminal. |
Resources | Not Applicable |
Processing | Checks files and space allocated to user. |
Data | Filename and/or contents |
3.1.4 Data Transmit Module
The image capture module captures the image and is responsible for it's precessing.
Type | server module |
Purpose | Transfer data to Client |
Function | To transfer files, data and signals between client and server. |
Subordinates | Not Applicable |
Dependencies | Socket Library files |
Interfaces | There is no interface. It runs directly from the terminal. |
Resources | Data, files on server |
Processing | Checks client for input data; sends processed information to the client. |
Data | captured image data and signals. |
3.1.5 Face Recognition Module
To recognize the face or feature in an image.
Type | server module |
Purpose | To recognize the face or feature present in an image. |
Function | To recognize a face or feature in an image transmitted by the client, and notify the client. |
Subordinates | Not Applicable |
Dependencies | GTK+ 2.0 library files |
Interfaces | There is no interface on the server side. It runs directly from the terminal. |
Resources | Data recorded by the user, files on server marked as 'public' |
Processing | Uses a series of face recognition algorithms to find eigen values, and compare with those of other image files in the user's recorded data. |
Data | Captured image data and signals for face or feature recognition. |
3.2 Client Module
The Client Module consists of the following child modules. They are basically responsible for the various
operations that the user requires to communicate with the main server from his handheld device.
It calls the required module at the time it is required.
Each module has it's own way of informing the Client Module of errors that occured and whether the run was successful or not. The Client module then takes
appropriate action by asking the user whether to retry or abort (in the case of error)
In the case of a successful call, the client proceeds with the next action.
Back to top
3.2.1 Login Module
Before utilization of it's resources, Streav's members have to log on.
Type | client module | |
Purpose | Request the user for his user name and password. | |
Function | Authenticate the validity of the user and grant access in the case of a correct login. In the case of an invalid login, display a suitable message describing the failure and then prompt the user to try again. | |
Subordinates | Not Applicable | |
Dependencies | It's a stand alone module. The password and the user name are authenticated at the server. Thus, the log in module depends on only the GTK and Socket library files. | |
Interfaces | A simple interface asking the user for his user name and password. | |
Resources | Not Applicable | |
Processing | The module asks the user for the user name and password. If the user data available if valid, the person is granted access. Then the log in module supplies the Client module with a suitable message informing it of it's successful exit | |
Data | The data entered by the user |
3.2.2 Voice Capture Module
Streav relies heavily upon a good voice data collecting module.
Type | client module | |
Purpose | Collect and store the sound samples. | |
Function | Streav is audio triggered. It remains dormant as long as there is no voice input. When there is voice input, these speech samples are stored and compressed. Also the image module is triggered by the voice module. | |
Subordinates | Not Applicable | |
Dependencies | It requires an audio input source like a microphone | |
Interfaces | There is no interface. It runs directly from the terminal. | |
Resources | Not Applicable | |
Processing | The module dormant as long as there is no voice input. When voice input is detected, the voice module stores the large chunks of voice data in a predefined file.It also informs the Client module that the user is in conversation and the image capture module is also triggered. When the size of this file reaches a particular threshold limit, this module informs the Client module that the threshold has reached and it is time to compress. The Client module responds by running the voice compression module. | |
Data | The voice data in the vicinity of the user and his companions |
3.2.3 Voice Compression and decompression Module
The voice compression and decompression modules:
Type | client module |
Purpose | Compress or Decompress the sound data. |
Function | It has two prime functions. The first one being to compress the voice data from the microphone data. The other one being to decompress the voice data coming from the server and storing the data in a seperate file. After accomplishing it's task, it informs the Client module of it's retrun status. |
Subordinates | Compression module and Decompression module |
Dependencies | It requires an intimation from the Client module from the names of the files which has the required data. |
Interfaces | There is no interface. It runs directly from the terminal. |
Resources | Not Applicable |
Processing | Streav is audio triggered. When the Client module calls this particular module, it does so with a particular command. Depending on this particular command, the module calls the compression or decompression module. The compression module compresses the voice data in the predefined file. This voice data is now ready to transmitted to the server. When the user wants to view his old memories, he will avail the resources of Streav. When the data is transmitted, it will be containing compressed voice data. To decompress this, the user will Client module will invoke the Compression Decompression module with a particular command. This will indicate the file name and the decompression command. The data will then be decompressed and stored in a particular file. Status information will be sent back to the Client module. |
Data | The voice data in the vicinity of the user and his companions |
3.2.4 Image Capture Module
The image capture module captures the image and is responsible for it's precessing.
Type | client module |
Purpose | Capture the images when triggered by the Client module |
Function | It has two prime functions. The first one being to capture the images from the webcam/camera phone and intimate the Client function of the final destination of these uncompressed images. In the case of error, the Client module must be informed. |
Subordinates | Not Applicable |
Dependencies | It requires an intimation from the Client module as to when the client triggers Streav. When intimated, the image capture model requires a file where it stores all it's relevant data. The name of this file is predefined. |
Interfaces | There is no interface. It runs directly from the terminal. |
Resources | Uncompressed image files whose names are passed as parameters |
Processing | On being triggered by the audio, the Client module invokes the image capture module. This module then captures the images and stores them in a file. When this file reaches a particular threshold level (measured in terms of number of images captured), the Client module is invoked informing it of the latest developments. The client responds by compressing these files. In the case of an error, the Client module is sent a message and the Client tries to rectify the error with the help of the user (if required). |
Data | The pictures are captured and stored in a particular file |
3.2.5 Image Compression and Decompression Module
The image compression and decompression modules:
Type | client module |
Purpose | Compress and Decompress the images as directed by the Client module. |
Function | It has two prime functions. The first one being to compress the images from the webcam/camera phone (when intimated by the client module) and intimate the Client function of the final destination of these compressed images. In the case of error, the Client module must be informed. In the case of the decompression, the data obtained from the server is decompressed and stored in a particular file and the Client module is intimated of the final destination of the uncompressed footage. |
Subordinates | Compression Module and Decompression Module |
Dependencies | It requires an intimation from the Client module as to when the image capture program has reached a threshold and requests compression. It needs a file to store the final compressed data. The decompression module is invoked from the compression decompression module when the viewer needs to view the data stored in his account. |
Interfaces | There is no interface. It runs directly from the terminal. |
Resources | For the compression module, Uncompressed image files whose names are passed as parameters. For the decompression module, the data from the server is required. Space is required to store the decompressed data. |
Processing | On being triggered by the Client module with the file name and command, the compression and decompression module analyzes the command passed onto it. If a compression is required, then the source file name is accepted and compression transforms like the Discrete Cosine Transform, Huffman Encoding are utilized to compress the image files. If the decompression module is invoked, then the destination file is obtained and the inverse compression transforms are utilized to obtain the decompressed image. |
Data | The pictures that were captured by the webcam/camera phone are are required by the compression module. The same space is used for storing the compressed image. Similarly for the decompressor, the server data will be required for decompression. |
3.2.6 Data Transmission and Reception Module
The data transmission and reception modules are essential for the effective performance of Streav.
Type | client module |
Purpose | Transmit and Recieve Streav data as directed by the Client module. |
Function | The first function is to transmit packed files consisting of the audio and image (compressed) information in small packets which will be reassembled in the server. The other function involves the reception of small packages from the server and repacking them into the original file. |
Subordinates | Transmission Module and Reception Module |
Dependencies | It requires an intimation from the Client module as to when the captured images and captured voice data is ready for transmission. This occurs when a particular time limit has elapsed. Thus, there is a need for the clock. Overclocking will result in slower transmission as more data will be there. |
Interfaces | There is no interface. It runs directly from the terminal. |
Resources | For the transmission module, compressed image files and voice files whose names are passed as parameters. The reception module requires ample space to concatenate the files and store them. If the bandwidth is large enough, there will not be any need for storing the movie file. |
Processing | In the case of the transmission module, which is invoked by the Client module as a certain time limit is elapsed. When this happens, the list of compressed file names (voice and image) is passed on the transmission module. The module organizes them into a certain Streav recognizable file format which consists of interlaced audio and image data. Then, it transmit the file in small parts. On the other hand, the reception module requires the internet to recieve the data file from the Streav server. The file is then regrouped into the file. Thus, the fact that file is transmitted in pieces is split/regrouped is abstracted from the rest of the software. The decompression module then reports to the Client module regarding the location of the final file which needs to decompressed and displayed. |
Data | These modules require the location of the compressed file(s) which need to be transported. Also the reception module requires memory for the received file. |
4. Reusability and Relationship to other Products
There are a lot of similarities in the modules which we will explore and use to our benefit in order to make Streav as efficient as possible.
5. Design Decisions and tradeoffs
There are several features of this design which we would like to highlight.
6. Pseudo Code for Components
Here are certain algorithms which will depict the working of Streav
The Client Module
Invoke Log In Module
7. Appendices
N.A.
Back to top