Mini Project Report

Semester V CSD 301

Siddharth Sumit Thakran Tanmay Chaudhry Tarik Setia

By 09ITMG1086CSE 09ITMG1090CSE 09ITMG1095CSE 09ITGM1097CSE

Me!a Streamer and Player

Certificate
This is certify that Project work, Media Streamer and Player a benefice work has been successfully carried out and submitted in the fulfillment of the requirement for the fifth semesters Bachelor of Engineering from ITM UNIVERSITY, during the academic year 2011-2012. It is certified that all correction / suggestion indicated for the internal Assessment have been incorporated in the Report. The Project report has been approved as it satisfied the academic requirement in respect of Minor Project work prescribed for the Bachelor of Technology and Engineering Degree. This project is done under the guidance of Mr. Ezaz Ahmed by Siddharth Sumit Thakran Tanmay Chaudhry Tarik Setia

Signature

(Course Co-ordinator)

Acknowledgement
The project you are holding is the result of dedication of Mr. Ezaz Ahmed under whose guidance ,We did such a great job of bringing and shepherding the project. This person always kept the things on track and helped us in getting the things in good shape. It was nice experience working with him. Lastly we wish to thank each and every person involved in making our project successful.

Table of Contents
1.Introduction 1.1 Overview of Media Streaming 1.1.1 Architecture of Media Streaming 2.Feasibility Study 2.1 Economical Feasibility Study 2.2 Technical Feasibility Study 2.3 Behavioral Changes Study 3.Technologies Used 3.1 Server Side 3.1.1 Transport Layer- UDP 3.1.2 Application Layer- RTP/RTSP 3.2 Client Side 3.2.1 Java Media Framework 4.Project Description 5.Requirement Analysis 5.1 Hardware Requirements 5.2 Software Requirements 6.System Requirement Specification 6.1 Server Side 6.1.1 External Interface Specification 6.1.2 Functional Specifications 7.Design 7.1 Server Side 7.1.1 Class Diagrams 7.1.2 Dependencies Diagram 7.2 Client Side 7.2.1 Class Diagrams 8.Snapshots 9.Conclusion 10.Future Scope 11.References

1.Introduction
Media Server
It all started in 1975 when a two networked TCP/IP communication was successfully tested between Stanford and University of London. After the success of TCP/IP the ARPNET migrated from its traditional way communication is Circuit Switching to TCP/IP. The migration of the ARPANET to TCP/IP was officially completed on flag January 1, 1983, when the new protocols were permanently activated. That day was the Foundation of Modern Internet. Back then internet was only supposed to transmit textual data over distances. But with development and successful implementation of various network and application layers the internet communication crossed the line of textual services and became what it is today, The Youtube, The Facebook etc where the every kind of media whether audio or video flows through the computer networks. This flow of media is called media streaming in which a host sends packets of data to the end user where all the packet are combined to form the media package. This project Terminal Media Server is the basic implementation of a media streaming server that use RTP as application layer and UDP as Transport layer. It also provides the feature of converting media formats falling under same categories. The next few section will go through the architectural and abstract technologies practiced to build this project.

Java Media Player

Media player is a term typically used to describe computer software for playing back multimedia files. While many media players can play both audio and video, others focus only on one media type or the other. Such players are known as either audio players or video playersand often have auser interface tailored for the specific media type. Media players often display icons known from physical devices such as tap recorders and CD players. Examples of these icons are (play), (pause), and (stop).

Recently, Media player become popular in this generation. Most of the software companies develop so many types of player which support Multimedia files (e.g. Winamp, Window Media Player, Real, RealOne, etc). But there is not all of the software which are suitable for all different users. Our Java Media Player is basically a facility for music lovers to control playback of Multimedia files right from the local network. Also it can work as a standalone media system to run media files .We chosen java as the implementing language because java is platform independent so what will get can be run on any platform, following javas Write once run everywhere title. We built our media player with the help of Java Media player framework (JMF),we will discuss later about it in the Technology used section.

1.1 Overview of a Media Streaming

Streaming media is multimedia that is constantly received by and presented to an end user while being delivered by a streaming provider. The name refers to the delivery method of the medium rather than to the medium itself. The distinction is usually applied to media that are distributed over telecommunication network, as most other delivery systems are either inherently streaming (e.g.,radio, TV) or inherently non-streaming (e.g., books, video cassettes, audio CDs). The verb 'to stream' is also derived from this term, meaning to deliver media in this manner. Internet Television is a commonly streamed medium.

1.1.1Architecture of a Media Streamer

Client-Server Architecture
SERVER

CLIENTS

The clientserver model of computing is a distributed application that partitions tasks or workloads between the providers of a resource or service, called servers and service requesters, called clients. Often clients and servers communicate over a computer network on separate hardware, but both client and server may reside in the same system. A server machine is a host that is running one or more server programs which share their resources with clients. A client does not share any of its resources, but requests a server's content or service function. Clients therefore initiate communication sessions with servers which await incoming requests.

Peer-To-Peer

HUB

Peer to Peer (p2p) computing or networking is a distributed application architecture that partitions tasks or workloads among peers. Peers are equally privileged, equipotent participants in the application. They are said to form a peer-to-peer network of nodes. Peers make a portion of their resources, such as processing power, disk storage or network bandwidth, directly available to other network participants, without the need for central coordination by servers or stable hosts. Peers are both suppliers and consumers of resources, in contrast to the traditional client-Server model where only servers supply (send), and clients consume (receive).

2.Feasibility Study
A feasibility study could be used to test a new working system, which could be used because: The current system may no longer suit its purpose, Technological advancement may have rendered the current system redundant, The business is expanding, allowing it to cope with extra work load, Customers are complaining about the speed and quality of work the business provides, Competitors are now winning a big enough market share due to an effective integration of a computerized system. Within a feasibility study, six areas must be reviewed, including those of Economics, Technical, Schedule, Organizational, Cultural, and Legal.

2.1 Economic feasibility study

This involves questions such as whether the firm can afford to build the system, whether its benefits should substantially exceed its costs, and whether the project has higher priority and profits than other projects that might use the same resources. This also includes whether the project is in the condition to fulfill all the eligibility criteria and the responsibility of both sides in case there are two parties involved in performing any project. ** This project has no economical value as its being made for open source contribution and for sole purpose of learning.

2.2 Technical feasibility study

This involves questions such as whether the technology needed for the system exists, how difficult it will be to build, and whether the firm has enough experience using that technology. The assessment is based on an outline design of system requirements in terms of Input, Output, Fields, Programs, and Procedures. This can be qualified in terms of volumes of data, trends, frequency of updating etc.In order to give an introduction to the technical system. **Needed Technologies are known but whether they work together is question of research. We drop it on learning and analyzing with the help of so many code snippets and check their functionality. **Streaming of audio as well as video data of all formats is possible or not (whether the player will support all formats).

2.3 Behavioral changes study

This involves questions such as whether the system has enough support to be implemented successfully, whether it brings an excessive amount of change, and whether the organization is changing too rapidly to absorb it. **All the behaviors are expected to be in favor of our candidate system as its promising flexibility in controlling the music they way you liked and too without worrying about the operating system you use. **As it is an open source project, it can be downloaded by anybody and can be modified according to their taste and functional need.

3.Technologies Used
3.1 Server-Side - TMediaServer
3.1.1The Transport layer - UDP
The User Datagram Protocol (UDP) is one of the core members of the internet protocol suite, the set of network protocols used for the Internet. With UDP, computer applications can send messages, in this case referred to as datagrams, to other hosts on an internet protocol (IP) network without requiring prior communications to set up special transmission channels or data paths. DP uses a simple transmission model without implicit handshaking dialogues for providing reliability, ordering, or data integrity. Thus, UDP provides an unreliable service and datagrams may arrive out of order, appear duplicated, or go missing without notice. UDP assumes that error checking and correction is either not necessary or performed in the application, avoiding the overhead of such processing at the network interface level. Time-sensitive applications often use UDP because dropping packets is preferable to waiting for delayed packets, which may not be an option in a real-time system.If error correction facilities are needed at the network interface level, an application may use the TCP or Stream Control Transmission Protocol (SCTP) which are designed for this purpose.

3.1.1.1 Packet Structure

UDP is a minimal message-oriented Transport Layer protocol that is documented in IETF RFC 768. UDP provides no guarantees to the Upper Layer Protocol for message delivery and the UDP protocol layer retains no state of UDP messages once sent. For this reason, UDP is sometimes referred to as Unreliable Datagram Protocol. UDP provides application multiplexing (via port number) and integrity verification (via checksum) of the header and payload. If transmission reliability is desired, it must be implemented in the user's application.

offset (bits) 0 32 64+

0 15 Source Port Number Length Data

fig:UDP Datagram

16 31 Destination Port Number Checksum

The UDP header consists of 4 fields, each of which is 2 bytes (16 bits). The use of two of those is optional in IPv4 (pink background in table). In IPv6 only the source port is optional (see below).

Source port number

This field identifies the sender's port when meaningful and should be assumed to be the port to reply to if needed. If not used, then it should be zero. If the source host is the client, the port number is likely to be an ephemeral port number. If the source host is the server, the port number is likely to be a well-known port number.

Destination port number

This field identifies the receiver's port and is required. Similar to source port number, if the client is the destination host then the port number will likely be an ephemeral port number and if the destination host is the server then the port number will likely be a well-known port number.

Length

A field that specifies the length in bytes of the entire datagram: header and data. The minimum length is 8 bytes since that's the length of the header. The field size sets a theoretical limit of 65,535 bytes (8 byte header + 65,527 bytes of data) for a UDP datagram. The practical limit for the data length which is imposed by the underlying IPv4 protocol is 65,507 bytes (65,535 8 byte UDP header 20 byte IP header).

3.1.2 The Application layer - RTP/RTSP

3.1.2.1 RTP
RTP was developed by the Audio/Video Transport working group of the IETF standards organization. RTP is used in conjunction with other protocols such as H.323 and RTSP. The RTP standard defines a pair of protocols, RTP and RTCP. RTP is used for transfer of multimedia data, and the RTCP is used to periodically send control information RTP is designed for end to end, real time , transfer of stream data. The protocol provides facility for jitter compensation and detection of out of sequence arrival in data, that are common during transmissions on an IP network. RTP supports data transfer to multiple destinations through IP Multicast. RTP is regarded as the primary standard for audio/video transport in IP networks and is used with an associated profile and payload format.

3.1.2.2 RTSP
The Real Time Streaming Protocol (RTSP) is a network control protocol designed for use in entertainment and communications systems to control streaming media servers. The protocol is used for establishing and controlling media sessions between end points. Clients of media servers issue VCR-like commands, such as play and pause, to facilitate real-time control of playback of media files from the server. The transmission of streaming data itself is not a task of the RTSP protocol. Most RTSP servers use the RTP for media stream delivery, however some vendors implement proprietary transport protocols.

1.3.2.1 RTSP Commands

OPTIONS
An OPTIONS request returns the request types the server will accept.

DESCRIBE
A DESCRIBE request includes an RTSP URL (rtsp://...), and the type of reply data that can be handled. The default port for the RTSP protocol is 554. This reply includes the presentation description. Among other things, the presentation description lists the media streams controlled with the aggregate URL. In the typical case, there is one media stream each for audio and video.

SETUP
A SETUP request specifies how a single media stream must be transported. This must be done before a PLAY request is sent. The request contains the media stream URL and a transport specifier. This specifier typically includes a local port for receiving RTP data (audio or video), and another for RTCP data (meta information). The server reply usually confirms the chosen parameters, and fills in the missing parts, such as the server's chosen ports. Each media stream must be configured using SETUP before an aggregate play request may be sent.

PLAY
A PLAY request will cause one or all media streams to be played. Play requests can be stacked by sending multiple PLAY requests. The URL may be the aggregate URL (to play all media streams), or a single media stream URL (to play only that stream). A range can be specified. If no range is specified, the stream is played from the beginning and plays to the end, or, if the stream is paused, it is resumed at the point it was paused.

PAUSE
A PAUSE request temporarily halts one or all media streams, so it can later be resumed with a PLAY request. The request contains an aggregate or media stream URL. A range parameter on a PAUSE request specifies when to pause. When the range parameter is omitted, the pause occurs immediately and indefinitely.

RECORD
The RECORD request can be used to send a stream to the server for storage.

TEARDOWN
A TEARDOWN request is used to terminate the session. It stops all media streams and frees all session related data on the server.

3.2 Client-Side
Java Media Framework(JMF)
The Java Media Framework (JMF) is a recent API for Java dealing with real-time multimedia presentation and effects processing.JMF handles time-based media, media which changes with respect to time. Examples of this are video from a television source, audio from a raw-audio format file and animations. The beta JMF 2.0 specification will be used for this report, as they currently reflect the features that will appear in the final version.

JMF Media Processing Model

During the input stage, data is read from a source and passed in buffers to the processing stage.The input stage may consist of reading data from a local capture device (such as a webcam or TV capture card), a file on disk or stream from the network. The processing stage consists of a number of codecs and effects designed to modify the data stream to one suitable for output.These codecs may perform functions such as compressing or decompressing the audio to a different format, adding a watermark of some kind, cleaning up noise or applying an effect to the stream (such as echo to the audio). Once the processing stage has applied its transformations to the stream, it passes the information to the output stage.The output stage may take the stream and pass it to a file on disk, output it to the local video display or transmit it over the network. For example, a JMF system may read input from a TV capture card from the local system capturing input from a VCR in the input stage.It may then pass it to the processing stage to add a watermark in the corner of each frame and finally broadcast it over the local Intranet in the output stage.

4.Project Description

PLAY AUDIO FILE.

PLAY VIDEO FILE

STREAM AUDIO FILE

STREAM VIDEO FILE

CONVERT AUDIO FILE

CONVERT VIDEO FILE

fig: Use Case UML of Media Streamer and Player

Project Functions

Playing an audio file Playing a video file Streaming an audio file Streaming a video file converting an audio file converting a video file

User

Characteristics

Any user from any actor group can use this software User must carry full administrator privileges. Software

Dependencies

Python Interpreter Twisted Matrix Libraries ffmpeg liberaries GStreamer Liberaries Ubuntu Operating System Java Media Framework Java Runtime Envt.

5. Requirement Analysis
5.1 Hardware Requirements
A computer with minimum following requirements. Minimum Processor Memory Video adapter and monitor Hard drive disk free space Devices Others 233MHz 64MB RAM Super VGA(800 x 600) 1.5GB Keyboard and mouse Sound card, speakers Recommended 300 MHz or higher 128 MB RAM or higher Super VGA (800 x 600) Or higher resolution 1.5 GB or higher Keyboard and mouse Sound card, speakers

5.2 Software Requirements

Operating System
Platform Independent but UNIX is recommended

Java Runtime environment (JRE)

A software bundle from Sun Microsystems that allows a computer system to run a Java application. Java applications are in wide spread use and necessary to view many Internet pages. The software bundle consists of the Java Virtual Machine and programming interface(API). The API provides a set of standard class libraries. The virtual machine and API have to be consistent with each other and are therefore bundled together as the JRE. This can be considered a virtual computer in which the virtual machine is the processor and the API is the user interface.

Development Tools and Packages

NetBeans (an IDE for programming in java). JDK(Java Development Kit) 4 or better . Java Media Framework (JMF) API for developing media applications. Python Interpreter Twisted libraries for python. ffmpeg binding for python. Gstreamer toolkit.

6.Software Requirement Specification

This section deals with the requirement specification of this project and offers the complete description of the behavior of the system to be developed

6.1 Server Side

6.1.1 External Interfaces Specification.

User Interfaces
TMediaServer should provide user a way to interact with the

software. This can be done via UNIX Command Line Tool TERMINAL. TMediaServer may also provide a GUI for interaction

Hardware Interface
TMediaServer should be implemented on UNIX Platform. This

is because the dependencies we would be using as unix specific.

Software Interfaces.
No software interfaces except for the Python subsystem are

necessary.

7.Design
7.1 Server Side
7.1.1 Class Diagrams
datagramProtocol

RTPStreamer
sock seqNo invterval bufsize packetsSeny releaser peerAddress fileSize loadfile(filename) startProtocol() setBufferSize(bufsize) setPeerAddress(addr) setupStreaming(fileToPlay,buf,addr) startStreaming(fileToPlay,speed) continueStreaming()

RTSPMessage
rtspCommand URI pathname cseq bandwidth bufsize session speed rtspMsg tostring() fromstring() parse() parseURL()

Module:RTPServer.py

Module:RTSPMessage.py

Launcher
startUI() playMedia() streamMedia() transcodeMedia() exit()

Player
fileName player()

Converter
fileName convert()

Module:Launcher.py

Module:GPlayer.py

Module:FPlayer.py

lineReceiver

RTSPServer
messageHandler session currentSession data connectionMade() connectionLost(reason) lineRecieved() process() sendReply() describeRequest(msg) optionRequest(msg) setupRequest(msg) playRequest(msg) teardownRequest(msg);

Module:RTSPServer.py

SETUP

Init
TEARDOWN

Ready

TEARDOWN

TEARDOWN

PLAY

PAUSE

Pause
PLAY

Play

RTP Sent Packets

7.1.2 Dependencies Diagram

twisted.internet.protocol.datagramprot ocol

urlpars e

twisted.internet.ud p

twisted.internet.ta sk twisted.internet.re actor RTPServer

url

re(regular

RTSPMess age

RTSPServer

twisted.internet.proto col

twisted.internet.lineRec eiver

GStreamer

ffmpeg Converter

Launcher

fig:Various Dependencies of TMediaServer

7.2 Client Side

7.2.1 Class Diagrams

fig: Class Diagram of Java Player

fig: Video Class Diagram

8.Snapshots
8.1 Client-Side

Figure1 Home window

Figure 2 Opening Media le

Figure 3 Audio Playing

Fiqure 4 Video Playing

Fiqure5 RTP Streaming

8.2 Server-Side
Home Screen

g: Main

 Play a Media File

fig:Pl

 Transcode

fig:Tran

 Data Stream

fig:Data

9.Conclusion
Working on this project was quite difficult as even till date project is partly complete. We really enjoyed this work because of the following reasons There is no book available on JMF and RTP/RTSP architecture so it was quite difficult to learn as we had to follow learn by work technique, originally been main motto at ITM. Got to know about optional APIs of java and python, it started understanding of their main utility , that is its expandability and being open source in nature. As even we kept this project as open source, many others will be using our code and they can make it better and complete. Learned how media files work and got to now internal file structure of MP3 file.

10.Future scope

Capture audio and video with your microphone and video camera, then store the data in a supported format. Process time-based media and change the content-type format. Transmit audio and video in realtime on the Internet. Live Broadcasting of College Lectures/Events. Video Conferencing. Broadcasting Media to Mobile Devices.

11.References
http://www.cs.columbia.edu/~hgs/rtp/ www.oracle.com/technetwork/java/javase/tech/index-jsp-140239.html http://www.twistedmatrix.com