Software Requirements
Specification
for
Narrow Bandwidth Streaming
Video Codec
Version 1.0 approved
Prepared by group 10
Dilruk G.A. 040075R
Internal Supervisors
Table of Contents
1. Introduction ... 1
1.1 Purpose ... 1
1.2 Document Conventions ... 1
1.3 Intended Audience and Reading Suggestions ... 1
1.4 Project Scope ... 2
1.5 References... 2
2. Overall Description ... 3
2.1 Product Perspective ... 3
2.2 Product Features... 3
2.3 User Classes and Characteristics... 4
2.4 Operating Environment ... 4
2.5 Design and Implementation Constraints... 5
2.6 User Documentation ... 6
2.7 Assumptions and Dependencies... 7
3. System Features ... 7
3.1 Encode videos... 7
3.2 Decode videos ... 8
3.3 Adaptive compression mechanism... 9
3.4 Background data reusing mechanism... 10
3.5 Audio-Video synchronization ... 11
4. External Interface Requirements... 12
4.1 User Interfaces ... 12
4.2 Hardware Interfaces ... 13
4.3 Software Interfaces... 13
4.4 Communications Interfaces ... 13
5. Other Nonfunctional Requirements ... 14
5.1 Performance Requirements ... 14
5.2 Quality Requirements ... 14
5.3 Save the bandwidth and storage cost ... 14
5.4 Software Quality Attributes ... 15
Revision History
Name Date Reason For Changes Version
Narrow Bandwidth Streaming Video Codec
1.
Introduction
1.1
Purpose
This document is to express the basic requirement of the “low-bandwidth streaming video codec” project. This is an extension for the Theora which is already existing video codec developed by the
Xiph.Org Foundation. The goal of this project is to develop a video codec specially optimized for video streaming in narrow bandwidth conditions. The features discussed in this document can be functional or non functional. These requirements are described in software development perspective to easily grasp by customer.
1.2
Document Conventions
SRS encloses some typographical conventions. Each system feature is described by its priority level, response sequence and the functional requirements. The functional requirements for system features are illustrated by italics. Functional requirements are inherited from the detailed system feature. Organization names and project names that are included in the document have been highlighted with bold.
Within the document NaBSVC is used as an acronym for Narrow Bandwidth Streaming Video Codec and NaBS player is used for Narrow Band Streaming Player.
1.3
Intended Audience and Reading Suggestions
This document will be the first guide for all the parties involved such as customer, developers, and users. Reader can go through all the functionalities of the system by reading this document. This document takes the reader throughout the system by giving a thorough understanding of the system.
1.4
Project Scope
This project is aimed to provide evolution of traditional video streaming systems to new, next generation streaming systems. The “narrow-bandwidth streaming video codec” is an optimized video codec for the real-time communication systems such as video conferencing applications and organizational meetings via network.
We want to optimize the “Theora” video codec for deliver the video encoding and decoding functionality in a fast and efficient way so that the video can be streamed under narrow bandwidth conditions. This video codec is proposed to give a natural streaming experience to the user, rather than waiting much time for buffering the video file before it plays. Also this codec is proposed to deliver high quality video experiences for the streaming users.
1.5
References
Ø Fundamentals of Multimedia by Ze-Nian Li and Mark S.Drew
Ø A Practical Guide to Video and Audio Compression by Cliff Wootton
Ø The Technology of Video and Audio Streaming – second edition by David Austerberry Ø http://www.theora.org/
2.
Overall Description
2.1
Product Perspective
The “narrow-bandwidth streaming video codec” is an enhancement of the “Theora” which is an existing video codec being developed by the Xiph.Org Foundation as part of their Ogg project. Theora is a lossy video compression method derived from On2's VP3 Codec. The compressed video can be stored in any suitable container format. Theora video is generally included in Ogg container format and it is frequently paired with Vorbis audio.
Also with the further development we want to acquire better features such as compression algorithms, audio video synchronization methods form the other available open source video codec.
2.2
Product Features
The following are the main features that are include in the “narrow bandwidth streaming video codec”. Those features will be discussed with more detailed in section 3
Ø Optimize video encoding algorithms to encode the row video for the streaming under narrow bandwidth conditions.
Ø Better video quality under narrow bandwidth conditions.
Ø Better audio video synchronization with the real time applications like video conferencing. Ø Maximize the performance and minimize the latency of application such as video
conferencing, organizational meetings via network and personal streaming.
Ø Adaptive compression mechanism that is synchronized with the outgoing buffer, for the optimum usage of the available bandwidth.
Ø Standardized video storage with the ogg container format.
Ø Ability to easily install and operate with the existing players such as MPlayer, VideoLAN player.
Ø Codec is a purely software based solution that can be upgrade easily. Ø Compatibility with the browser based players.
2.3
User Classes and Characteristics
Mainly there are three types of users who intended to use this video codec
Desktop users
The desktop user is people who want to play a video which is stored in the local machine.
Personal streaming users
The personal streaming user is people who just want to play a video through a network without real time interaction with the other side.
Video conferencing users
The video conferencing users are people who want real time interaction with the other side while communicating with each other. This video codec is mainly focused for the video conferencing users. They can continue their conference as they are face to face with each other when using this real time streaming video codec.
2.4
Operating Environment
The codec is basically proposed to operate under open source platforms and Microsoft windows platforms.
Hardware Requirements
Desktop PC requirement
Ø Pentium III-based PC or greater
Ø Open source platforms, Windows XP and Windows Vista Ø 128 MB of RAM
2.5
Design and Implementation Constraints
Limitation of resource availability
For encode a high resolution video it is necessary to have high performance hardware such as high processing speed, large memory capacity. But in the case of normal users, they do not have that mach of quality hardware.
Network bandwidth availability
Although this video codec is named as “narrow-band streaming video codec”, there are limitations for the word narrow. However in real time video streaming there should be a minimum level of available bandwidth. Otherwise that application will not achieve its best performance.
Fluctuation of available bandwidth
Although theoretically it is possible to define a fixed bandwidth for each user who is connected to a network, this is practically impossible. Because of this the codec should adaptive with the currently available bandwidth at the receiver side. Although this approach could be able to solve some far, still it could remain some insoluble problems with this.
Sophisticated applications with high resolution videos
With the technical evolution of the hardware industry, there will be many sophisticated video capturing devices and playing devices. But although there are lossless video compression algorithms theoretically, it is not practically possible. So any how data will be lost while it is compressing with in a video codec. Because of this, the output video will not include all the information as it is before compress. Also this problem will highly occur while it compresses video data for real time transmission.
Practical limitation of data compression
The information loss within the compression process may be invisible because of the human eye does not sensitive for some areas of an image as much as the computer programs. As an example the human eye is more sensitive for the Luminance (brightness) than Chrominance (colors). By getting this advantage as developers we could neglect Chrominance information for some far. But this type of information degradation has exactly limitation. So when the human eye could understand the quality degradation of an image, the compression of the video does not useful any more.
2.6
User Documentation
At the end of the project a user manual will be delivered with the end product. This manual should help the users and application developers for their quick understand.
2.7
Assumptions and Dependencies
Ø For the full performance of the video codec in real time communication, we assumed that the
ogg container will fully supports for the streaming videos than other existing containers. Ø This project is highly depends on the Theora existing open source video codec that was
developed by the Xiph.Org Foundation.
Ø Also this is depend on the given support by our customers company Tenasta (pvt) Ltd Ø The compatibility and performance of the audio codec is a major fact that decides the
3.
System Features
3.1
Encode videos
3.2.1 Description and Priority
The main functionality of the NBSVC is the encoding of video which is captured from a video camera or a web cam.
3.2.2 Stimulus/Response Sequences
When the codec get a stream of row video as its input, it prepare a compressed data stream for saving to a file or send through a network.
3.2.3 Functional Requirements
REQ-1: There should be a set of algorithms that can compress the input images such that the original video should be able to regenerate by decompressing. REQ-2: There should be a container format to keep the compressed data with the
required additional information.
REQ-2: When the output is a video file, the extension of the file should be “.ogg” Codec
•
Storage Video
input
Video input Decoder
3.2
Decode videos
3.2.1 Description and Priority
Decoder part of the NBSVC is used to decompress the videos that are compressed earlier. The decoder part should be stimulated by the player which is the video is going to play with.
3.2.2 Stimulus/Response Sequences
When a player sends a request to the codec, it is accepted by the decoder part. Then it checks the given inputs video format and if it is the appropriate format, it start to decompress and create a video output.
3.2.3 Functional Requirements
REQ-1: The input file extension should be “.ogg”.
3.3
Adaptive compression mechanism
3.1.1 Description and Priority
The NBSVC will have an adaptive compression mechanism in real time communication, which monitors the outgoing buffer and automatically adjusts the amount of time the data spends in the video compression engine. This is a high priority system feature
3.1.2 Stimulus/Response Sequences
An increase in the buffer size is symptomatic of decrease in the effective bandwidth. As the buffer increases, the data spends more time in compression to produce less data to display movement.
3.1.3 Functional Requirements
REQ-1: There should be a fixed size buffer to keep the out going stream until it successfully reaches to the destination.
REQ-2: There should be an optimum pre defined warning level in the buffer before it reach to its maximum size.
REQ-3: There should be a monitoring application to monitor the out going buffer size
REQ-4: when the buffer size is reach to its warning level, the monitoring application should inform to the compression engine.
REQ-5: Then the compression engine stimulated by the monitoring application, the compression engine should get more time to properly compress the data and prepare fewer amounts of data.
3.4
Background data reusing mechanism
3.2.1 Description and Priority
The NBSVC will have an additional part to evaluate the stability of each pixel to determine if it belongs to the background or foreground image.
3.2.2 Stimulus/Response Sequences
If the value of a pixel is stable for a period of time (programmable variable), it is deemed to belong to the ‘background’. If there is a motion in front of a background edge or object and if the motion does not last longer than the threshold time value, than the data is drawn back from local memory rather than using precious bandwidth to send it again.
3.2.3 Functional Requirements
REQ-1: There should be a monitoring application to evaluate the stability of each pixel.
REQ-2: there should be a standard way to send the background pixel information to the destination side for reuse that pixel values within the threshold time.
3.5
Audio-Video synchronization
3.2.1 Description and Priority
Because of the audio stream is compressed separately with in an audio codec, when an input video is compressed it should make sure that the audio stream also compressed with better synchronization.
3.2.2 Stimulus/Response Sequences
User will have the real experience of video conferencing with proper synchronized audio and video. They do not receive video stream with miss match audio.
3.2.3 Functional Requirements
4.
External Interface Requirements
4.1
User Interfaces
Browser based application (NaBS Player) will be developed to check the performance of NaBSVC. Following functionalities can be shown in the NaBS Player.
Ø Capture video & audio from external hardware devices mentioned in chapter 4.2 and encode that stream according to NaBSVC’s protocols and send those encoded data through the internet. In NaBS Player gives buttons and short cut keys for start and stop capturing video & audio.
Ø Decode bit stream input which is taken from the internet and display videos & audios.
Ø User can control the features of NaBS Player such as volume of audio. User can easily control those things using given set of buttons and short cut keys.
Ø It can select a suitable data transfer rate according to the bandwidth available to the end user. The video quality increase when it has more bandwidth.
Ø If NaBS Player occurred an error, it popup an instant message describing the error message type.
4.2
Hardware Interfaces
With the NaBSVC, it is mainly used following hardware components.
Ø Web Cam – Used for capture video and connected to the computer using USB port. Ø Mick – Used for capture audio.
4.3
Software Interfaces
NaBS Player use the web player as an integrated component. It uses the main functionality of the web player to give output to the users. The messages coming in to Nab Player is an audio input. It contains real audio & video and NaBS Player has to decode those according to the NaBSVC’s protocol. The messages going out from Nab Player is a bit stream. It contains the encoded video & audio according to NaBSVC.
4.4
Communications Interfaces
Both Mozilla fire fox and IE browsers can be used as a platform for the NaBS Player. Communication standard used for NaBS Player may be TCP/IP, UDP or RTP. One of the best protocols is going to be used for video streaming with research and developments. Data transfer rate of the communication media can be selected by users and the synchronization of video & audio is done according to the protocols defined in the NaBSVC.
5.
Other Nonfunctional Requirements
5.1
Performance Requirements
Streaming video performance is dependent in part upon the process of how it's encoded for transmission and the amount of bandwidth required for it to be streamed properly. It's usually standard practice to produce or encode streaming video for delivery over a network at a minimum of standard 56K modem speed since many users are still connected at these speeds. In the NBSVC it is proposed to stream with less bandwidth than 56k. To digitize a video so that it will stream at this speed, a high degree of compression should be applied to both the video and audio tracks.
5.2
Quality Requirements
Not all video codec’s and video encoding software are created equal. There can be a marked difference in the quality of video achieved from different video codec. NBSVC should be capable of compressing and decompressing the data by saving its image quality as much as possible. Here the better compression algorithms should be developed to protect image and sound qualities.
5.3
Save the bandwidth and storage cost
One of the main objectives of NBSVC is designing it to be streamed through narrow bandwidth. It should work properly through the slow transmitting mediums with better quality as much as possible. In addition to those better compression techniques will allows to store video contents by using less storage costs.
5.4
Software Quality Attributes
The NaBSVC will be developed with well structured design and all the information about the software will be documented well. So the functionalities can be easily understood and maintained by anyone who is going to use product. And also this product can be plugged easily with other related applications as well. Because of using well structured coding style and error handling mechanism, the product will not be crashed due to unexpected inputs.
6.
Other Requirements
Further improvements
Ø Offers a “mode changing” feature for use the most appropriate mode in appropriate situation such as “fast compress” mode that can encode in real time on a high end Pentium 4 PC. Ø Develop NaBSVC for compatible with mobile platforms such as Windows Mobile 5.0 and
Appendix A: Glossary
Term Definition
Ogg An open-source digital music format VP3 An open source video codec
USB Universal Serial Bus
TCP Transmission Control Protocol IP Internet Protocol
UDP User Datagram Protocol RTP Real-time Transport Protocol
