Java Information Systems

Published: November 27, 2015 Words: 822

Chapter 4: Analysis

4.1 Requirements

This part will be concerned with the functional and non-functional requirements and the technical specifications.

4.1.1 Functional Requirements

The system should provide services in reaction to particular inputs and system behaviour. The services are as follows:

4.1.2 Non-Functional Requirements

Non-functional requirements are constraints on services. They are not concerned with functions delivered by the system.

4.1.3 Hardware Requirements

The hardware specification used for development :

A computer with

4.1.4 Software Requirements

The software specification is:

4.2 Choice of programming language

Java is chosen as due to it being object-oriented strongly typed, robust, reliable, has unlimited resources on the internet, has a graphical user interface while being a dynamic language. It is also easier to program compared to C++.

4.2.1 Java

Java Media Framework

The Java Media Framework API (JMF) enables audio, video and other time-based media to be added to applications and applets built on Java technology. This optional package, which can capture, playback, stream, and transcode multiple media formats, extends the Java 2 Platform, Standard Edition (J2SE) for multimedia developers by providing a powerful toolkit to develop scalable, cross-platform technology.

Java Media Framework Requirements

JMF 2.1.1 FCS with Windows Performance Pack

Hardware Requirements

Software Requirements

Capture Requirements

The following capture devices are supported in JMF 2.1.1 FCS with the Windows Performance Pack:

4.3 RTP Transmissions using JMF

RTP is the Real-time Transport Protocol. Here is an excerpt from the RTP specification: "RTP provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio, video or simulated data, over multicast or unicast network services. RTP does not address resource reservation and does not guarantee quality-of-service for real-time services. The data transport is augmented by a control protocol (RTCP) to allow monitoring of the data delivery in a manner scalable to large multicast networks, and to provide minimal control and identification functionality. RTP and RTCP are designed to be independent of the underlying transport and network layers". For furthur information please refer to RFC 1889: RTP: A Transport Protocol for Real-Time Applications

The JMF APIs that support RTP are found in the javax.media.rtp, javax.media.rtp.event, and javax.media.rtp.rtcp packages. The JMF RTP APIs enable you to:

4.3.1 RTP Implementation using JMF

The RTPSessionManager is an interface. An implementation of this interface is provided in in com.sun.media.rtp.RTPSessionMgr. You can instantiate this class to access the functionality of the RTPSessionManager API.

JMF Controls for RTP Player

Users have control over the buffer maintained by the RTP receiver. The buffer has two parameters that can be controlled:

The Length is the length of the buffer. When the data in the buffer exceeds this length, the data at the head of the queue (earlier data) is dropped. The Minimum threshold is the jitter buffer before which no data will be forwarded on the rtp data source. As long as data in the buffer is less than the minimum threshold, data will not be forwarded. The buffer length and minimum threshold are specified in milliseconds.

For RTP, the session manager maintains the following buffer defaults:

For audio, these values translate to a specific number of audio samples or frames based on the format of the incoming audio stream. For video, the frame rate of the incoming stream is not known by the receiver. In this case, the receiver defaults to a 15fps value when calculating the number of complete video frames that correspond to the buffer and threshold values. For example, if you want the buffer to hold 3 frames of video, you would set the buffer length to 200ms--three frames of a 15fps stream--regardless of the actual stream rate.

In JMStudio, Buffer Control is an option from the "Open RTP Session" menu item. On clicking on the "Buffer Control for RTP Session" tab, the buffer control component will be seen. This control component has text fields that display the current buffer and threshold size on the LHS. The buffer and threshold values can be updated by selecting options from the "Update" checkbox group. The 3 choices are "DEFAULT, MAX, User Defined". Selecting User defined enables the text field on the RHS, allowing you to enter specific buffer and threshold values[http://java.sun.com/products/java-media/jmf/2.1.1/support-rtp.html]

4.4 Technical Specification

This is the process of capturing audio from a microphone on one side and delivering it to the other side.

The stated process comprises of several phases:

4.4.1 Capturing Audio signals

Capturing is the process where a signal is recorded from a microphone and converted to an audio file. Below are some factors to be considered when capturing audio signals:

Cleanest recording with least amount of noise

Decreases line noise into recording. Also, keeping the audio cables away from power cords minimises noise introduction.

4.4.2 Encoding Audio

After digitization, the size of the audio file is to be considered. If too large, the digitized media will not transit to distant location. In that case, an encoding algorithm will be able to compress the file to a manageable size.