Framework of an Interactive Video Environment by chenleihor


									 Framework of an Interactive Video Environment

                           A Thesis by

                      LUIGI ONGLAO
                     DANNIEL SUNGA

                    Submitted to the Faculty of the
Department of Electronics, Computer and Communications Engineering
                 School of Science and Engineering
                           Loyola Schools
                     Ateneo de Manila University
                     Loyola Heights, Quezon City

              In Partial Fulfillment of the Requirements
                           for the Degree of
 Bachelor of Science in Electronics and Communications Engineering

                           March 2007
This thesis, entitled Framework of an Interactive Video Environment, prepared and

submitted by Cathy Mae Margarette Favorito, Hazel Inessa Fernandez, Luigi Onglao,

Danniel Sunga and Ma. Cristina Claire Tiamzon, in partial fulfillment of the requirements

for the degree of Bachelor of Science in Electronics and Communications Engineering, is

hereby accepted this 16th of March, 2007.

                                                                   Mr. Gerardo de Leon

                                                                       Mr. Carlos Oppus

                                                                       Mr. Cesar Pineda

                                                                 Dr. Nathaniel Libatique
                                                                         Thesis Adviser

                                                                  Dr. Gregory Tangonan
                                                                         Thesis Adviser

                                                                                    ii i

The group wishes to express their deepest gratitude to:

God for giving us the creativity, patience and skill to complete this thesis,

Kim Bartolome for always being ready to attend to all our PHP dilemmas and for
assisting us with the layout of the website,

Sirs Greg & Joey for contributing their great ideas and gently prodding our thesis to the
right direction,

Christian Almendarez for editing the videos,

Ardee Aram for helping us resolve database issues and giving us ideas on how to get

CTC208 thesis groups and EJ “Mr. Complete” Gallarde for their camaraderie,

Ronjo Solis and Stephen Cate for serving as VJs and giving video comments for our

the rest of ECE07 for continually giving us support,

And all organizations, departments and offices who willingly gave us copies of their
videos to become content for the servers.

                                                                                    iii i
                                 Table of Contents
ACKNOWLEDGEMENTS                                       iii
TABLE OF CONTENTS                                      iv
ABSTRACT                                               3
      1. Harnessing the Power of Video                 4
      2. Innovative Possibilities                      6
      3. Key Accomplishments                           7
      4. Novel Features                                8
      5. Scope and Limitations                         9

      2.1. IPTV                                        10
      2.2. Video Distribution                          12
           2.2.1. Downloading                          12
           2.2.2. Progressive Downloading              13
           2.2.3. Streaming                            14
           2.2.4. PHP FLV Streaming                    15
      2.3. 3G                                          17
      2.4. Streaming 3GP: Interactive Media Platform   18
           2.4.1. Content creation machines            20
           2.4.2. Player application                   21
           2.4.3. Content servers                      21
           2.4.4. Proxy                                22
      2.5. Multimedia Services                         23
      2.6. Multicast and Unicast                       23
      2.7. Performance Metrics                         25
           2.7.1. Effective throughput                 25
           2.7.2. File transfer time                   25

      3.1. Network Configuration                       26
      3.2. Web and Streaming Servers                   27
            3.2.1. Darwin Streaming Server             27
            3.2.2. Red5                                28
            3.2.3. Apache                              28
            3.2.4. Apache Tomcat                       29
      3.3. OpenLaszlo                                  30
      3.4. Conversion and Hinting Tools                31
            3.4.1. FFmpeg                              31
            3.4.2. MP4Box                              31
            3.4.3. Flash Video MetaData Injector       34
      3.5. Media Players                               34
            3.5.1. Flash Video Player                  35

             3.5.2. RealPlayer Mobile                         35
       3.6. Network Protocol Analyzer                         35
             3.6.1. User Interface                            36
             3.6.2. Filters                                   37

4. METHODOLOGY                                                39
      4.1. Installation and configuration                     39
            4.1.1. XAMPP 1.5.5.                               39
            4.1.2. Apache Tomcat, Red5 and Open Laszlo        39
            4.1.3. Darwin Streaming Server                    41
            4.1.4. FFmpeg                                     42
            4.1.5. MP4Box                                     42
            4.1.6. FLVMDI 2.94                                42
            4.1.7. Flash Player                               42
      4.2. Network Design and Implementation                  44
           4.2.1. Flowcharts                                  44
         General                            44
         Registration                       44
         Video upload                       46
         Live Streaming                     47
         Ratings                            48
         Comments                           49
         Search                             49
            4.2.2. Discussion                                 50
            4.2.3. Server Settings                            54
         XAMPP settings                     54
         Red5 settings                      54
         Darwin Streaming Server settings   55

5. RESULTS AND DISCUSSION                                     56
      5.1. Results with Ethereal                              56
            5.1.1. Live Streaming                             56
            5.1.2. Apache Server                              58
            5.1.3. Darwin Streaming Server                    61
      5.2. Streaming and Video on Demand Results              62
      5.3. Channels and Features                              64

6. CONCLUSION AND RECOMMENDATIONS                             67

7. BIBLIOGRAPHY                                               68

APPENDIX A : Video File Formats                               70

APPENDIX B: IP Cameras                                        72

APPENDIX C: Flashvars Options                                 74


       The thesis provides a framework for eventual IPTV deployment in the Philippines

that also employs 3G in streaming video. It covers the initial implementation of

BlueScreen, an interactive video environment invaluable to social networking and storage

applications, with a given number of channels. Great emphasis is given on video content

and its key role in infrastructure development.

       Features of BlueScreen include video upload, video search, video and text

comments, video rating and live streaming. These could be expanded to include videos

from IP camera stations, introductions by video jockeys and comments via Picture in

Picture. The thesis involves operation over Local Area Networks and 3G, the creation

and maintenance of a website and several databases, the conversion of uploaded videos to

FLV and 3GP, the injection of metadata into video files, and the management of several

servers to provide services to mobile and static clients.

                                      CHAPTER 1

1.1. Harnessing the Power of Video

                            Figure 1. The influence of YouTube.

        Videos are now proliferating rapidly in the Internet, thanks to sites like YouTube,

the popular video-sharing site named Time‟s Invention of the Year for 2006. Ordinary

people can instantly become celebrities by posting their original videos and getting others

to watch and rate these for free. The videos can be about anything—from extreme sports

shots to concert clips to science experiments to music videos to amateur shots to wacky

antics. According to a study by Lee Gomes of the Wall Street Journal, YouTube hosts

over 6 million videos, which are increasing by about 20 percent a month. User-generated

content is certainly on the rise.

        The potential of video is immense. Capturing even the most ordinary events can

enable people to entertain, enlighten, educate and even embarrass one another. For

instance, a member of the crowd can post a racist comment by a popular candidate in the

elections or a student in Iraq can show you events surrounding a roadside bombing.

Anyone anywhere can make a statement by posting a video and sharing it with the rest of

the world. Video production has been made possible by cheap camcorders, webcams,

high-end phones and digital cameras as well as easy-to-use video software. Advances

such as Internet Protocol Television (IPTV) and 3G further encourage the development of

video applications that could open new avenues of possibilities.

       Take a university setting for instance. Nowadays, video is not only used by the

film students for making their own productions, but also by an increasing number of

other students for ordinary class presentations and reports. Quite a number of individuals

generate videos for fun and recreation. Academic events such as seminars, conferences

and keynote speeches held on campus are recorded on video. Non-academic events such

as varsity games, class projects or reports, theatrical productions or the Freshman

Orientation Seminar are also captured on video.

       In such a setting, one can easily see how much video content is being generated

for a single school year. However, this content resides in various computers and tapes,

handled by different persons and offices, or even posted in multiple Internet sites. This

makes it difficult to locate videos of past projects or past events. There are also times

when the video itself gets lost or accidentally deleted. A collection of videos takes up

quite a large amount of space on file and on shelves.

       In such a very dynamic environment, it is also essential that users would have

some venue to exchange information and air their opinions, comments or questions

regarding specific issues. Why not exchange information and give one‟s perspective on

video? Interactive features on any video website play an essential role in engaging users

to generate, view and react to video content. The rush to create the next original

interactive feature could very well cause the creation of new styles of communication.

1.2. Innovative Possibilities

         The implementation of an interactive video infrastructure could serve as a

framework that could be utilized in specific situations. The following are some possible

areas of study where it can be applied:

1. Biomedicine

    It can serve as a central repository of biomedical videos, such as those

         documenting medical breakthroughs or procedures.

    It can be used for remote diagnostics and patient monitoring, thus proving its

         usefulness in telemedicine/e-health.

2. Art

    Audience can give feedback to filmmakers and actors.

    Events (launchings, tours, etc) can be streamed live.

    Currently, Ayala Museum has a huge collection of videos available for podcasts.

         The system can be integrated into a kiosk through which museum visitors can

         access the videos.

3. Disaster

    Real-time monitoring and assessment of a victim's condition through live


    Collection of footage documenting human-rights abuses or the plight of victims

         can be easily uploaded and stored.

4. Education

 A Science Channel can be implemented to showcase profiles and achievements of

         Filipino scientists, pioneers and innovators.

    The thesis can also include the Virtual Classroom proposed by previous ECE


   An obvious advantage of such an infrastructure is that content is more organized and

specialized, allowing for easier browsing, with features to facilitate interactivity.

1.3. Key Accomplishments

        This thesis deals with the creation of an Internet Protocol (IP) infrastructure that

makes use of current advances in technology, stores video content made by members of

an academic community, and allows interaction among its users. This framework is built

in such a way that enables it to accommodate other possible real-life situations outside

the university setting.

        In addressing basic content and technology issues present in the construction of an

interactive video environment, the group was able:

   1. To build an interactive and secure IP infrastructure that will be working primarily

        with video in an academic setting but will be flexible enough to be adapted to a

        range of other situations.

   2. To identify and implement software and processes that would be essential in

        developing this infrastructure.

   3.   To determine the end devices that will be used for access.

   4. To gather as many diverse videos as possible that relate the many events and

        activities occurring in the university and organizing them into channels.

   5. To create an online site for uploading and viewing of content.

   6. To come up with interactive features that would enhance the experience it can

       offer to its users.

1.4. Novel Features

       The site created for this thesis‟ purposes gives the user the look and feel of a

video environment especially suited for academic purposes. It serves as a venue for

gathering all videos that are being produced by members of a university, specifically the

Ateneo de Manila University (ADMU). It minimizes clutter in terms of video storage

(e.g. copies of the President's message in last year‟s graduation can be obtained easily),

and promotes increased collaboration among the various departments and offices (e.g.

Chemistry videos can be easily shown in a Materials Engineering class attended by ECE

students). Users can engage in live streaming and be part of an event even if they are

engaged in work in another place on campus (e.g. a political conference in Escaler Hall

being viewed by political science students in the Social Sciences Building). Users can

access the site whenever and wherever they are as long as they have a computer

connected to the Local Area Network (LAN) of the Loyola Schools, or a 3G- or wireless

LAN-capable mobile phone.

       IP camera stations can be set up in key areas and facilities such as Fr. Masterson

Drive, Faura Hall, and the Science Education Complex to provide live video feeds to

network clients. Traffic monitoring and security checks can be easily conducted when

these stations are integrated with the rest of the proposed infrastructure. The television

screens in the college cafeteria can also be similarly integrated, thus presenting a new

mode of access to clients, and enabling them to view events occurring live on campus or

videos stored on the site.

       Aside from uploading and viewing live streams or videos on demand, interactive

features will allow the user to:

              Rate uploaded videos.

              Make text or audio comments on uploaded videos.

              Make comments on live feeds and answer questions posed by the server.

              Choose a video jockey (VJ) who can introduce and give background

               information on the videos.

              Have his own channel where he can serve as the VJ.

1.5. Scope and Limitations

       This thesis is mostly implemented using open-source software. Insertion of

metadata and encoding of video files is part of its functionality. However, not all video

file formats are supported by the encoder used.

       Registered users can access their account via LAN or 3G. The 3G connection is

simulated in this thesis using wireless LAN. The upload and streaming features are only

available with a LAN connection. Only registered users of the site can upload videos. The

size of uploaded videos cannot exceed 50 MB.

                                      CHAPTER 2
                               Review of Related Literature

2.1. IPTV

       Internet Protocol Television (IPTV) is a system used to deliver digital television

services to subscribed consumers. It is delivered over a broadband connection using the

Internet Protocol (IP). Its delivery via IP-based secure channels results in a sharp increase

in content distribution control.

       IPTV is able to integrate numerous ways to analyze and trace the choices of its

users. It can mark out the users‟ preferences and selections over a particular time period.

It is therefore seen as a perfect platform on which clients add personalized e-commerce

options and a more targeted advertising.

       It should be noted that IPTV is different from “Internet Video”. Internet Video

provides services to watch videos, such as movie previews and web-cams. This service is

a so-called “best effort” made by providers of Internet, which has no back-to-back service

management along with quality of service considerations.

       On the other hand, IPTV is more advanced, user friendly, and incorporated with

the higher speed digital subscriber line (DSL) access technologies, such as asymmetric

digital subscriber line (ADSL2), ADSL2+ and very-high-data-rate digital subscriber line

(VDSL). It allows the service providers to participate and to compete efficiently in the

so-called “triple play” market space.

       The architecture of IPTV is shown in Figure 2:

                           Figure 2. Generic IPTV system architecture.

       The IPTV architecture consists of the following components:

       Content Sources collect video content from producers and other sources. This

content is encoded and stored in an acquisition database for video-on-demand (VoD).

       Service Nodes receive video streams in different formats. These video streams

are then reformatted and encapsulated for transmission with appropriate quality of service

(QoS) indications to the wide-area network. This makes it ready for delivery to

customers. The Service Nodes communicate with the customer premises equipment

(CPE) and the IPTV service.

       The Wide Area Distribution Network takes care of the distribution capability,

capacity and quality of service. It also has other capabilities such as multi-cast, which is

necessary for the reliable and timely distribution of IPTV data streams from the service

nodes to the customer premises. The core and access networks cover the optical

distribution backbone network and the various digital subscriber line access multiplexers


       Customer Access Links deliver the service to the end-users. Service providers

may use a combination of fiber-to-the curb (FTTC) and DSL technologies or direct fiber-

to-the-home (FTTH) access.

         The Customer Premises Equipment (CPE) provides the broadband network

termination functionality. It can be a routing gateway and have home- networking

capabilities. The IPTV Client terminates the IPTV traffic at the customer premises. This

is a device, such as a set-top box, which performs the functional processing. The

functional processing includes setting up the connection and QoS with the service node,

decoding the video streams, channel change functionality, user display control and

connections to user appliances such as a standard definition television or a high definition

television monitor.

2.2. Video Distribution

         Video content providers have several options for distribution, which are primarily

based on the concepts of downloading and streaming.

2.2.1. Downloading

         When a file is downloaded, it is saved entirely, usually in the computer's

temporary folder or to a location that the user has specified. It can only be opened and

viewed after download, meaning there could be a long waiting time if the file is very


         This method of delivering video is known as HTTP streaming or HTTP delivery.

Hyper Text Transfer Protocol (HTTP) is the same protocol used to deliver web pages.

This method is easy to use, without requiring additional software or special hosting plans.

A hyperlink to the file is the simplest way to provide downloadable material. Embedding

the file in a web page using certain HTML commands can also be an alternative. HTTP

streaming is actually more of an imitation of video streaming.

2.2.2. Progressive Downloading

       Compared to ordinary downloading, progressive downloading more closely

resembles "true" streaming. With progressive download, content must be preloaded to

memory before a recipient can play it. Progressive movies generally should not be made

to last more than a few minutes. Content plays as soon as it is available so, on fast

connections, progressive movies can appear to be streaming. However, if a user wants to

jump ahead half an hour in such a presentation, he must download everything from the

point currently in view to the point of interest.

       The goal of progressive download is high quality at any connection speed. Given

its superior quality, progressive video has proven very popular in the entertainment

industry. It may take a lot longer for a user on a 28.8 kbps modem connection to

download the same clip as someone with a much faster cable modem, but once

downloaded; the clip will have exactly the same quality on each machine.

       Progressive downloads are sent using two different protocols, HTTP and File

Transmission Protocol (FTP). Both can be delivered using ordinary Web servers. HTTP

and FTP are part of the connection-oriented protocol suite called Transmission Control

Protocol/Internet Protocol (TCP/IP). Connection-oriented protocols guarantee the safe

delivery of every packet sent. If a packet is lost, the server continues re-transmitting it

until the packet is delivered or the connection is lost. Since progressive downloads use

the same protocol as common Web content, there is less a chance of encountering

problems getting past firewalls than with content from a streaming server.

Progressive video can also take advantage of more advanced methods of compression

than streaming video, such as Two-Pass Variable Bit Rate (VBR) encoding. It can take as

much as 1MB for a streaming file to imitate the quality of a 600KB file compressed using

Two-Pass VBR.

2.2.3. Streaming

       Streaming is the only way to present live feeds and support broadcasts and

multicasts (i.e. sending one stream to many viewers). The file is sent to the user in a

stream. A user's machine plays data as it is received and then discards it. No file is

downloaded to a viewer's hard drive. Whether providing live broadcasts or video-on-

demand stored on a server, streaming allows broadcasts to run as long as is needed.

       One of the primary goals of streaming video is to maintain real-time playback at

various connection speeds. To make this possible, streaming media relies on different

protocols and servers for delivery than standard Web pages. Real-time Transport Protocol

(RTP) and Real-time Streaming Protocol (RTSP) are known as connectionless protocols,

in which speed is more highly valued than accuracy. Streaming servers reduce bandwidth

overhead by broadcasting data across a network without verifying whether it is actually


       Streaming software is available for all common server platforms such as Linux

and Windows. Some examples of streaming media software are:

       7. Helix Universal Server from RealNetworks. This server supports a variety of

            formats including RealMedia, Windows Media, QuickTime and MPEG-4.

       8. Apple QuickTime Streaming Server which supports a few formats including

            MPEG-4 and 3GPP.

       9. Macromedia Communication Server which specializes in Flash-based video

           and interactive multimedia.

       The streaming server transmits video and audio streams to individuals in response

to requests from those individuals using client software. The requests are handled using

RTSP, a protocol for controlling a stream of real-time multimedia content. The streams

are sent using RTP, a transport protocol used for transmitting real-time multimedia

content over networks. A streaming server can create streams from movies stored on a

disk. It can also send copies of any live streams to which it has access.

       Streamed media can be viewed by any application that supports standard video

files. Streams can also be set up so that users can view them from within a web browser

when a certain plug-in is installed. When a user starts to play streamed media through a

web page, the plug-in sends a request to the streaming server. The server responds by

sending the multimedia content to the client computer.

       Considering the sizes of the files and the possibilities that the medium offers,

streaming would be the ideal method for delivering video. This is because streaming is

capable of handling larger traffic loads, broadcasting live events, as well as QoS

monitoring (i.e. detecting a user's connection speed and delivering files accordingly).

2.2.4. PHP FLV streaming

       There are many video file formats to choose from when dealing with video

streams. The most common formats are Windows Media, RealMedia, QuickTime, MPEG

(in particular MPEG-4) and Flash Video. The Flash Video format is being touted as the

best option, particularly in terms of spread (i.e. its pervasiveness in Internet-enabled

desktops in mature markets) and installer file size. Flash Video can be viewed on most

operating systems; the Adobe Flash player and web browser plug-in is also available on

most end user computers. The video quality of most formats is quite similar, except for

the MP4 format which results in a slightly better size-quality performance.

             Player                Spread         Size                  Formats

          Flash Player              97 %       1.31 MB                    FLV

    Windows Media Player            84 %       6.99 MB           WMV,AVI,MP4,MPG

       QuickTime Player             66 %       32.30 MB            MOV,MPG,MP4

          Real Player               56 %       8.08 MB           RM,RAM,AVI,MPG

                               Table 1. FLV Video Compression.

       Streaming the Flash Video (.FLV) files is the fastest way to start playing any

video on the Web. In fact, it is currently being used by sites such as YouTube, Google

Video and MySpace. Flash gives unparalleled power and flexibility when it comes to

interactive and other advanced features.

       PHP FLV streaming has been created by a community of users who have

experienced several different streaming services and have not been satisfied with any of

them. It cannot be used for live feeds or multicasts. It is a kind of 'progressive download'

offering immediate random access to different parts of a movie.

       PHP FLV streaming is low-cost as it does not require a specialized streaming

server but only a web server with PHP. Depending on the bandwidth, hundreds of

simultaneous connections can be possible.

       This method of streaming involves the use of metadata, specifically information

containing the exact starting position in bytes and the timecode of each keyframe. Using

this, user can request any part of the FLV file starting at a specified keyframe.

                                                                Progressive           PHP
                                                               Downloading         Streaming
Real-time broadcasts                          X
Long clips                                    X                                       X
Immediate random access to
                                              X                                       X
different parts of a movie
Downloads entire movie                                                X
Downloads required part of the
FLV is cached on the local
Requires a specialized streaming
Requires a web server with PHP                                                        X
Can be stopped by firewalls                   X
Consistent high quality playback
                                                                      X               X
at any connection speed
Retransmits lost packets                                              X               X
                  Table 2. Differences among several video distribution options.

2.3. 3G

       Third-Generation (3G) Wireless Technology Networks are based on an

International Telecommunication Union (ITU) endeavor for a single global wireless

standard and are intended to provide global mobility. While 3G is generally considered

applicable mainly to mobile wireless, it is also relevant to fixed wireless and portable

wireless. A 3G system should be operational from any location on, or over, the earth's

surface, including homes, businesses, government offices, medical establishments, the

military, personal and commercial land vehicles, private and commercial watercraft and

marine craft, private and commercial aircraft, pedestrians, hikers, cyclists, campers, and

space stations and spacecraft. 3G offers the potential to keep people connected at all

times and in all places. A 3G Network enjoys increased data rates compared to previous

wireless technologies: 384 kbps (while moving) and 2 Mbps (when stationary at specific

locations). 3G includes other capabilities and features such as:

          Enhanced multimedia (voice, data, video, and remote control).

          Usability on all popular modes (cellular telephone, e-mail, paging, fax,

           videoconferencing, and Web browsing).

          Broad bandwidth and high speed.

          Roaming capability throughout Europe, Japan, and North America.

                    Figure 3. 3G ideally includes LAN, WAN and satellite services

2.4. Streaming 3GP: Interactive Media Platform

       3GP is a file format specially developed for third generation mobile devices that

is based on the MP4 file format.

       The first version of the mobile packet-switched streaming service, commonly

referred to as the 3G-PSS standard, was finalized in March 2001. This service integrates

simultaneously playing video, audio, images, and formatted text into mobile multimedia


       The standard specifies both protocols and codecs. The protocols and their

applications are:

      RTSP and session description protocol (SDP) for session setup and control,

      Synchronized Multimedia Integration Language (SMIL) for session layout


      HTTP and transmission control protocol (TCP) for transporting static media such

       as session layouts, images, and text, and

      RTP for transporting real-time media such as video, speech, and audio.

       The codecs and media types are:

      ITU-T H.263 video,

      MPEG-4 simple visual profile video (optional),

      AMR (adaptive multirate) speech,

      MPEG-4 AAC low complexity (AAC-LC) audio (recommended but optional),

      JPEG and GIF images, and

      XHTML-encoded, formatted text.

       For interoperability between content servers, the standard specifies using MPEG-

4 as an optional file format for storing media on the server. When combined using the

SMIL presentation description language, the codecs enable rich multimedia presentations

and applications, including video, audio, slideshows, and multi-language subtitling.

       The 3GPP standard also uses the EventTiming, MetaInformation, and

MediaClipping modules. These add functionality such as changes in the presentation

schedule based on user interaction (EventTiming), sending metainformation about the

multimedia data (MetaInformation), and rendering only parts of a transmitted media

stream (Media-Clipping). In addition, a 3GPP streaming client should support the

PrefetchControl module, which lets the content creator include hints about when to start a

media stream.

       The Interactive Media Platform, illustrated in Figure 3, is a software platform for

mobile-streaming applications. It consists of

      content creation machines,

      a player application that runs on widely-used operating systems,

      content servers that hold the newly created multimedia content, and

      a proxy, which builds the interface between the player application and other parts

       of the platform.

       HTTP provides access to static content through a TCP connection, while RTP

packets transport streaming content through UDP connections. RTSP manages streaming

sessions. The system uses SDP via an RTSP connection to access stream descriptions.

       Introducing a proxy is necessary to serve the requirements of a mobile Internet

application using components designed for the fixed Internet. It also protects the core

network from the back-end components and vice versa. The back-end components can be

located outside the operator domain, using the proxy with a firewall extension.

2.4.1. Content creation machines

       The content creation machines host the applications needed for creating both live

and offline content. They are used to prepare streaming content, for example, to edit

videos and images and encode them in the appropriate formats for mobile streaming.

They upload the content to the streaming servers—for dynamic content—and to the Web

servers, which hold the static content and the SMIL files.

  Figure 4. Interactive Media platform. The client uses HTTP to request a SMIL presentation from a Web
server. Within the SMIL presentation, the client finds links to the streaming content, which it acquires from
      the streaming servers. Static content, such as an image, is fetched from a Web server via HTTP.

2.4.2. Player application

         The player application renders multimedia content and lets users navigate through

the SMIL presentations. The player fetches the SMIL file from a Web server via the

proxy. The player‟s SMIL engine interprets the contents of the SMIL file and fetches the

streams (using the RTSP protocol) and the static content (using HTTP) according to the

storyboard the SMIL file describes. The player‟s SMIL implementation is fully 3GPP-

compliant as are the supported codecs, which decode multimedia data and render it on the

output devices. Plug-in capabilities simplify extending the player with additional codecs.

         Applying skins changes the player application‟s appearance. A skin is a structure

that adapts the look of an application‟s user interface. An application can have several


2.4.3. Content servers

         Two kinds of back-end servers store the content the player renders: Off-the-shelf

Web servers hold the SMIL pages, images, and other static content, and dedicated

streaming servers store streaming content and related information.

       Upon receiving an HTTP GET request from the proxy or the player, the Web

server processes the request and fetches the appropriate content. The player application

uses the RTSP protocol to control the operation of the streaming server. After fetching

the description of a streaming session, which it transports using the session description

protocol, the player application sets up the streams of this session, for example, the video

and audio track. When it receives an RTSP PLAY request, the server starts sending out

RTP packets that transport the streaming content. Each stream can be in a different

state—for example, being set up, playing, paused. Therefore, the streaming servers must

keep track of all active sessions. The server uses the real-time control protocol to provide

the player, proxy, and streaming server with additional information about the session

such as packet loss. Each stream that the server sends out has an Real-Time Control

Protocol (RTCP) connection.

2.4.4. Proxy

       The proxy is the system‟s interface to both the radio network and the back-end

components. Acquiring static content such as images and text files is very

straightforward, but the proxy‟s value becomes more apparent when it transmits

streaming data to the client. The proxy dynamically adapts the delivered quality of

service in accordance with available bandwidth using feedback information from the

player application, radio network, and IP network.

       The user, content-provider, and operator use the proxy to configure preferences. A

content provider can specify a minimum bandwidth to ensure acceptable video-stream

quality. If this bandwidth is not available, a slide show is presented instead. If the current

bandwidth is insufficient for delivering a video, the proxy switches immediately to a

lower bandwidth as long as the QoS does not drop below a predefined value. The

operator also has the option of limiting bandwidth consumption to a certain user group.

       The proxy is also the interface to the operator‟s network components, including

operation and maintenance, charging and billing, and subscription management.

2.5 Multimedia Services

       Delivery options for real-time streaming media are divided into two categories:

live and on-demand. Live events, such as concerts, speeches, and lectures, are commonly

streamed over the Internet as they happen with the assistance of broadcasting software.

The broadcasting software encodes a live source, such as video from a camera, in real

time and delivers the resulting stream to the server. The server then serves, or “reflects,”

the live stream to clients. Regardless of when different customers connect to the stream,

each sees the same point in the stream at the same time. This live experience can be

simulated with recorded content by broadcasting from an archive source such as a tape

deck or creating playlists of media on the server.

       For an on-demand delivery experience, such as a movie or an archived lecture,

each customer initiates the stream from the beginning, so no customer ever comes in

“late” to the stream. No broadcasting software is required in this case.

2.6 Multicast and Unicast

       In a multicast, a single stream is shared among the clients (see Figure 4). Each

client “tunes in” to the stream just like a radio tunes in to an FM broadcast. Although this

technique reduces network congestion, it does require a network that either has access to

the multicast backbone, otherwise called the Mbone, for content generally distributed

over the Internet, or is multicast-enabled for content distributed within a contained

private network.

                                     Figure 5. Multicast

       In a unicast, each client initiates its own stream, resulting in the generation of

many one-to-one connections between client and server (see Figure 5). Many clients

connected via unicast to a stream in a local network can result in heavy network traffic.

But this technique is the most reliable for delivery over the Internet since no special

transport support is required.

                                      Figure 6. Unicast.

2.7 Performance Metrics

       These metrics can be used in evaluating and analyzing network performance.

2.7.1 Effective Throughput

       This refers to the number of bytes transferred in seconds. It can have different

values, depending on the path taken from source to destination or from destination to

source. Since it defines the system's capability for efficient bandwidth utilization, it is

significant when dealing with transfers of large amounts of data, particularly video.

2.7.2 File Transfer Time

       This refers to the time it takes for a certain amount of data to be transferred

completely to its destination. This metric can be estimated from the values of the

effective throughput.

                                    CHAPTER 3
                                Theoretical Framework

3.1. Network Configuration

       The implementation of this thesis involves the integration of the Loyola Schools

Campus Network with the servers primarily responsible for video streaming. Computer

clients or end-users can access the site primarily through wireless LAN. The 3G

connection of mobile clients is merely simulated through a Wi-Fi connection. The

network should be capable of high transmission rates in order to provide seamless

delivery of video content to the client. Ideally, the network should be able to accept any

video file format uploaded by its clients and convert it to FLV and 3GP, simultaneously

generating and injecting metadata. The network should also be able to utilize bandwidth

efficiently in providing services to its clients. The environment generated by the network

should encourage interaction among its users through live streaming, and rating and

comment features.

                                  Figure 7. Actual network.

3.2. Web and Streaming Servers

       These are the servers that were used in delivering video streams.

3.2.1. Darwin Streaming Server

       The Darwin Streaming Server (DSS) is the open source version of Apple's

QuickTime Streaming Server technology. It has the same code as QuickTime Streaming

Server but does not have technical support from Apple. It allows developers to modify

the code to suit their needs in streaming QuickTime, MPEG-4 and 3GPP media. Thus, it

can be used for streaming videos in 3G. Darwin Streaming Server allows users to send

streaming media to clients across the Internet using RTP and RTSP protocols.

       For the implementation of this thesis, the DSS is used to stream the video to the

mobile Wi-Fi device using 3GPP. Mobile devices connect to the Darwin Streaming

Server through a folder in the software which automatically connects the mobile device

to the server.

       Features of DSS include:

    10. Native MPEG-4 and 3GPP streaming: Standard hinted MPEG-4 and 3GPP files can be

        served directly, without being converted to .mov files.

    11. MP3 audio streaming: MP3 files can be served to clients that support MP3 streaming via

        HTTP, such as iTunes, WinAmp, and RealPlayer.

    12. An even easier-to-use web-based admin: New features include a set-up assistant and easy

        administration of relays between streaming servers.

    13. Improved stream quality: Enhancements result in even better stream quality.

    14. Performance enhancements: Overall stability and performance of the server has been


    15. Authentication:Two types of authentication, digest and basic, control access to protected


   16. Server-side playlists: A set of media files can be streamed as if it were a live broadcast.

       This can be ideal for creating and managing a virtual radio or television station.

   17. Relay support: Several layers of servers can be easily set up to broadcast streams to a

       virtually unlimited number of clients.

   18. Support for Instant-On: Dramatically improves the viewing experience by playing video

       and audio streams instantaneously.

   19. Integrated Broadcaster administration: Provides an easy way to set up or change the user

       name and password for QuickTime Broadcaster. A Broadcast Settings pane allows

       remote operation of QuickTime Broadcaster (on Mac OS X Server version 10.2 or later).

3.2.2. Red 5

       Red5 is an open source Flash server written in Java. For the thesis, it is used for

live streaming where the video source is real-time: a video camera/webcam is attached to

the computer and the video is simultaneously broadcast. Red5 sits on top of Apache

Tomcat and OpenLaszlo, which are just peripheral open source software. It is capable of:

    Streaming Audio/Video (FLV and MP3)

    Recording Client Streams (FLV only)

    Shared Objects

    Live Stream Publishing

    Remoting

3.2.3. Apache

       Apache is a full-featured web server with full support for the HTTP 1.1 standard,

proxy caching, password authenticated web pages, and many other features. A web server

is a program that runs on a host computer (also, confusingly enough, called a web server)

that serves up web sites. In other words, the web server program responds to requests

from visitors' web browsers for objects it has in its possession. Objects that web servers

can serve include HTML documents, plain text, images, sounds, video, and other forms

of data. These objects may not necessarily exist in static form, but instead are generated

on-the-fly by programs run by the server; CGI scripts are the most common of these

programs. Web servers and browsers communicate using HTTP, Hypertext Transfer

Protocol, a simple but effective language for requesting and transmitting data over a


       Apache is known to be:

      Powerful, stable and reliable.

      Feature-rich. The Apache server sports a host of features including XML support,

       server-side includes, powerful URL-rewriting, and virtual hosting.

      Modular. Modules add functionalities not included in the core network.

      Extensible. Anyone can write modules for Apache as well as make changes to

       Apache's source code.

      Popular. This means that it is very easy to find support in case of problems.

      Free.

3.2.4. Apache Tomcat

       Apache Tomcat is a web container that supports the servlet and the JavaServer

Pages specifications from Sun Microsystems. It provides tools for configuration and

management but can also be configured by editing configuration files that are normally


       The Tomcat servlet engine is often used along with Apache or other web servers.

However, it can also function as an independent web server. Earlier in its development,

the perception existed that Tomcat was only suitable for development environments and

other environments with minimal requirements for speed and transaction handling. Now,

Tomcat is increasingly used as a stand-alone web server in high-traffic, high-availability


       Tomcat is cross-platform, running on any operating system that has a Java

Runtime Environment.

3.3 OpenLaszlo

       OpenLaszlo is an open source platform for creating web applications with a user-

friendly interface. OpenLaszlo programs are written using the LZX programming

language, which is a JavaScript description language and XML, compiled in Flash. An

OpenLaszlo application developed on one machine will run on all leading Web browsers

on all leading desktop operating systems.

                         Figure 8. OpenLaszlo client-server architecture.

3.4. Conversion and Hinting Tools

3.4.1. FFmpeg

       FFmpeg is an open source video and audio converter developed by Linux that can

convert video and audio files from one format to another. The project is made of several


              ffmpeg is a command line tool to convert one video file format to another. It also

               supports grabbing and encoding in real time from a TV card.

              ffserver is an HTTP (RTSP is being developed) multimedia streaming server for

               live broadcasts. Time shifting of live broadcast is also supported. Note that this is

               very buggy and unlikely to work.

              ffplay is a simple media player based on SDL and on the FFmpeg libraries.

              libavcodec is a library containing all the FFmpeg audio/video encoders and

               decoders. Most codecs were developed from scratch to ensure best performance

               and high code reusability.

              libavformat is a library containing multiplexers and demultiplexers for

               audio/video container formats.

              libavutil is a helper library containing routines common to different parts of


              libpostproc is a library containing video post processing routines.

              libswscale is a library containing video scaling routines.

3.4.2. MP4Box

       MP4Box aims to provide tools needed to produce and distribute MPEG-4, 3GP

and 3GP2 content in a single command-line application. The following is a list of

MP4BOX features:

       file layout (fragmentation or interleaving), file cleaning (ISMA and 3GP conversions).

       file splitting by size or time, chunk extraction from file and file concatenation, including

        all supported input files concatenation (eg cat a set of AVIs to a single 3GPP/MP4).

       file hinting for RTP/RTSP and QTSS/DSS servers (MPEG-4 / ISMA / 3GP / 3GP2


       XML information dumping for MP4 and RTP hint tracks.

       MP4/3GP Conversion from MP3, AVI, MPEG-PS, AAC, H263, H264, AMR, QCP,


       Media Track extractions.

       ISMA E&A encryption and decryption.

       3GPP timed text tools (conversion from SUB/SRT/TTXT/TeXML and extraction to


       VobSub import/export

       Media stream import and extraction when encoding a BT/XMT file.

       MPEG-4 BIFS codec and scene conversion from and to MP4, BT and XMT-A formats.

       MPEG-4 LASeR codec and scene conversion from and to MP4, SVG and XSR (XML

        LASeR) formats.

       XML scene statistics for BIFS scene (BT, XMT-A and MP4).

       Conversion of simple Macromedia Flash (SWF) to MPEG-4 Systems (BT/XMT/MP4).

       Conversion to and from BT, XMT-A, WRL, X3D, X3DV formats.

        For this thesis, MP4BOX was primarily used for hinting. File hinting involves

creating special tracks in the file that contain transport protocol specific information and

optionally multiplexing information. These tracks, called hint tracks, are then used by the
server to create the actual packets being sent over the network, in other words they

provide the server 'hints' regarding packet building.

       MP4Box can generate these hint tracks for the RTP protocol (the most widely

used protocol for multimedia streaming). The resulting file can then be streamed to

clients with any streaming server understanding the file format and hint tracks, such as

the Darwin Streaming Server.

       -hint : hints the given file for RTP/RTSP
       -mtu size : specifies the desired maximum packet size, or MTU (Maximum Transmission
       Unit). This must be choosen carefully: specifying too large packets will result in
       undesired packet fragmentation at lower transport layers. The default size when hinting is
       1450 bytes (including the 12 bytes RTP header).
       -multi [maxptime] : enables sample concatenation in a single RTP packet for payload
       formats supporting it. maxptime is an optional integer specifying the maximum packet
       duration in milliseconds, used for some audio payloads. Its default value is 100 ms.
       -copy : forces hinted data to be copied to the hint track. This speeds up packet building at
       server side but takes much more space on disk.
       -rate clock_rate : specifies the rtp clock rate in Hz when no default one exists for the
       given RTP payload. The default rate of most AV formats is 90000 Hz or the audio sample
       -mpeg4 : forces usage of MPEG-4 Generic Payload whenever possible.
       -latm : forces usage of LATM payload for MPEG-4 AAC.
       -static : enables usage of static RTP payload IDs (pre-defined IDs as specified in RTP).
       By default MP4Box always uses dynamic payload IDs, since some players do not
       recognize static ones.
       -sdp_ex string : adds the given text to the movie SDP information (-sdp_ex "a=x-test: an
       sdp test") or to a track (-sdp_ex "N:a=x-test", where N is the hint track or its base track
       ID). This will take care of SDP line ordering.
       -unhint : removes all hint tracks and SDP information from file. This can be useful since
       MP4Box doesn't remove any existing hint tracks when hinting the file.

       MP4Box usually generates a temporary file when creating a new MP4 or 3GP
file. The location of this temporary file is OS-dependent, and it may happen that the
drive/partition the temporary file is created on has not enough space or no write access. In
such a case, a temporary file location can be specified with the -tmp path_to_dir option.
MP4Box always stores the file with 0.5 second interleaving and meta-data at the

beginning, making it suitable for HTTP streaming.
        MP4Box provides only a command line interface. For this thesis, the following

command was used:

                        mp4box -3gp -mtu 1450 -hint videofilename

3.4.3. Flash Video MetaData Injector (FLV MDI)

        FLV MetaData Injector is a Win32 console application that can add 'onMetaData'

AMF data to FLV files. FLVMDI optionally saves an XML version of the injected data,

and can add an additional string data or save the onMetaData data to an XML file.

Metadata include timestamps, duration or length of the video, height and weight in pixels,

data rates and file size.

        FLV MDI is operated from the command line with:

                            flvmdi inFile [outFile] [/v] [/s] [/x] [/e] [/l] [/k] [/p]

where inFile is the name of the source file or folder. If the outFile parameter is not

supplied, inFile will be overwritten, else the outFile path will be used for saving. If the

inFile parameter is a folder, all FLV files in that folder will be processed. If the outFile

parameter is specified when the inFile parameter is a folder, it must also be an existing

folder, where output files will be written. If the full path for the parameters is not given,

Windows will use the current working directory. The characters inside the braces are

optional operations. What is essential for this thesis is the /x option, which automatically

creates an XML file containing the metadata in the same location and with the same

name as the FLV file.

3.5. Media Players

        The following are the media players that were used in the implementation of this

3.5.1. Flash Video (FLV) player

          The Flash Video (FLV) Player can be used alone, without the need for the Flash

authoring tool. The player allows you to show your videos with more control and to a

broader audience than with QuickTime, Windows Media or Real Media. It supports

playback of a single FLV file, RTMP streams or RSS/XSPF playlists, a wide range of

settings for modifying both behavior and appearance and an extensive, documented

action script.

3.5.2. RealPlayer Mobile

          RealPlayer Mobile is the mobile version of RealPlayer; and is fully optimised for

Symbian OS version 6.0. RealPlayer Mobile allows mobile phones to play Real Audio,

Real Video, MP3, 3GP, AMR and other media formats.

3.6. Network Protocol Analyzer

          Ethereal is an open source network packet analyzer, released under the GNU

General Public License and available for popular platforms, such as Linux and Windows.

A network packet analyzer tries to capture network packets and tries to display that

packet data as detailed as possible. It is used to troubleshoot network problems, examine

security problems, debug protocol implementations and learn network protocol internals.

Ethereal can display packets with detailed information, open and save packet data

captured, import and export packet data from and to a lot of other capture programs, filter

packets, search for packets, colorize packet display based on filters and create various


        Ethereal can track the throughput of the network by monitoring the network

packet activity at the network interface device. Ethereal performs a live capture for a

predetermined amount of time for it to record all the packets sent and received through a

selected network device. Not all these packets are useful for an analysis of streaming

video, since servers can have side conversations with other devices. To address this

problem, the captured packets are filtered to ensure that only analyze the relevant packets

are analyzed.

3.6.1 User Interface

        Ethereal can display packets with very detailed information. The main window

has three panes which display different types of information regarding the packets

captured. The packet list pane displays a summary of each packet captured. By clicking

on packets in this pane, the user controls what is displayed in the other two panes. The

packet details pane displays the packet selected in the packet list in more detail.

Information from the layers of the OSI or TCP/IP protocol stack can be gathered in detail

from this pane. The packet bytes pane displays the data from the packet selected in the

packet list pane, and highlights the field selected in the packet details pane.

                             Figure 9. Ethereal user interface.

3.6.2. Filters

       Ethereal has two filtering languages: one for capturing packets and another for

displaying packets. A capture filter can be used before capturing packets on an interface.

This method sets a limit to the packets that Ethereal will capture from the interface. This

can be entered into the field of the capture options dialog box. A capture filter takes the

form of a series of primitive expressions connected by conjunctions (and/or) and

optionally preceded by not: [not] primitive [and|or [not] primitive …] Common primitive

expressions are shown below:

       Display filters allow the user to gather information only on packets that the user

needs. Packets can be selected by protocol, the presence of a field, the values of fields, a

comparison between fields and more. The syntax is a little different from the capture

filter. Every field in the packet details pane can be used as a filter string, effectively

showing only the packets where this field exists. In addition, a filter expression dialog

box can be used to generate a filter string.

Ethereal provides a wide range of network statistics. These statistics range from general

information about the loaded capture file to statistics about specific protocols. It can

provide a summary of the capture file, traffic to and from an IP address, traffic between

specific IP addresses and visualize the number of packets in time. General statistics of the

captured or filtered file can be viewed using the summary window. It contains general

information of the capture file, timestamps of the first and the last packet and traffic data.

IO graphs can provide data on packets or bytes transferred in time. Five differently

colored graphs can be defined and displayed simultaneously. The user can also use a filter

string to display graphs that the user needs.

                                        CHAPTER 4

4.1. Installation and configuration

       This chapter provides the steps and procedures undertaken by the group in

implementing the Framework of an Interactive Video Environment.

4.1.1. XAMPP 1.5.5.

       XAMPP is a free software bundle that contains the following elements:

    20. Apache 2.2.3
    21. MySQL 5.0.27
    22. PHP 5.2.0 & PHP 4.4.4
    23. phpMyAdmin
    24. FileZilla FTP Server 0.9.20
    25. OpenSSL 0.9.8d

       With Apache (the HTTP server), MySQL (the database management system),

PHP and Perl (the programming languages), including some other modules, dynamic web

pages can be delivered. XAMPP just needs to be downloaded and extracted. No editing

of configuration files is necessary.

       For        this       thesis,       XAMPP            was          downloaded    from After the complete installation,

XAMPP can be found under Start / Programs / XAMPP. The XAMPP Control Panel can

be used to start/stop all servers and also install/uninstall services.

4.1.2. Apache Tomcat, Red5 and OpenLaszlo

       OpenLaszlo is an open source platform for creating and delivering web

applications with interface capabilities comparable to desktop client software. It is a Java

servlet that compiles applications into executable binaries for targeted runtime

environments. Apache Tomcat is an open source implementation of Java Servlet and

JavaServer Pages (JSP) technologies. Red5 is an open source Flash server that supports

streaming and recording of audio and video, as well as live stream publishing.

       For the installation of an OpenLaszlo Presentation Server and Red5 Flash Server

on top of an Apache Tomcat server, these files were downloaded:

    JDK 5.0 Update „xx‟ (Java SE Development                       Kit    (JDK))     from
    Tomcat 5.5 from
     - Core (windows service installer)
     - Administration Web Application
    OpenLaszlo Dev Kit (war file) from
    Red5 war file from

       These instructions were followed for the installation of JDK and Tomcat 5.5:

      Perform a standard installation of JDK.
      Install Apache Tomcat using the default server port 8080 and remember the
       admin login credentials.
      Test the installation in the browser: http://localhost:8080.
      Install the Admin Web Application for easy Tomcat administration.
      Stop the Tomcat Service from the Taskbar.
      Open “” and drop the folders “conf” and “server”
       into “C:\Program Files\Apache Software Foundation\Tomcat 5.5\”.
      Test the installation again in the browser (http://localhost:8080) by clicking on
       “Tomcat Manager”.

       OpenLaszlo can be installed from within the Admin Web Application:

      Click on Tomcat Manager.
      Locate “WAR file to deploy” and use the buttons “Browse…” and “Deploy” to
       install “OpenLaszlo-3.3.3.war”.
      Test the OpenLaszlo installation by accessing http://localhost:8080/OpenLaszlo-

       Red5 can be installed by these instructions:

      Rename “red5-0.6rc1.war” into “red5.war” to get a nice deployment URL
       (context path) and deploy it.
      Test the Red5 installation by accessing http://localhost:8080/red5.

4.1.3. Darwin Streaming Server

       The following were the steps followed in setting up the Darwin Streaming Server

using Windows Server 2003:

      Click the Streaming Server Admin icon in the Dock. Open the web browser from
       a server with Darwin Streaming Server installed. From a remote computer, open
       Microsoft Internet Explorer version 4.5 or later, or Mozilla 1.0 or later.
      Enter the URL for the Streaming Server Admin computer. For example:
       http://hostname:1220 where hostname is the IP address of the streaming server
       computer and 1220 is the port number.
      Enter a username and password. This password will be used when sending an
       MP3 stream to the streaming server.
      Click Next. The Secure Administration page appears. Enable this option only if
       the server will be administered remotely and has an SSL certificate installed for
       secure remote administration.
      Click Next. The Media Folder page appears. Note the default path. This is where
       the media that will be streamed should be placed.
      Click Next. The Streaming on Port 80 page appears. Enable port 80 if viewing
       content from outside the local area network (that is, from the Internet) will be
      Click Finish. The Streaming Server Admin main screen appears. The message
       “Server is Running” should appear at the top of the screen.
      If the message “Server is Idle” appears, click the Start Server button to start the
       server. The streaming server is now active and ready to stream media.

       Specific ports need to be opened in the firewall to allow RTSP requests from

users, encoded video and audio from the broadcaster, and outbound streams to clients on

the local network and the Internet. These are the ports used by the Darwin Streaming

Server and for incoming and outgoing requests:

      Ports used to communicate with client: 554, 7070 TCP or 80 TCP

      Ports used to send media: 6970-6999 UDP, or 80 TCP

      Ports used to receive broadcast: 10000-65635 UDP

      Ports server will stream through: 554 RTSP 7070 TCP or 80 TCP

      Default port typically used by MP3 broadcasters: 8000 TCP

      Port used for remotely managing QTSS or DSS: 1220 TCP

4.1.4. FFmpeg

       FFmpeg is open source software that can record, convert and stream digital audio

and video. FFmpeg was installed by downloading and extracting the contents of the file

“” located at

4.1.5. MP4Box

       In order to serve files using Streaming Servers, files first need to be “hinted.”

MP4Box is the tool used in this thesis for hinting files. It is available for download at

4.1.6. FLVMDI 2.94

       FLV MetaData Injector (FLVMDI) is a command line application that can add

Metadata to FLV files. Metadata can be thought of as information that describes, or

supplements, the central data. FLVMDI (“” ) can be downloaded and

extracted from

4.1.7. Flash Player

       Flash Player should be embedded in the browser for the client to be able to view

video files. The embedded video file should reside in the same folder as the HTML file.

The FLV player was embedded in the browser using the following code, which consists

of two parts, object and embed. The object part is used by Microsoft's Internet Explorer

and the embed part is used by all other browsers.

<object width="250" height="400"
<param name="movie" value="mp3player.swf" />
<param name="menu" value="false" />
<param name="quality" value="low" />
<param name="bgcolor" value="#ff0000" />

<param name="flashvars"
 value="file=video.flv&autostart=true" />
<embed src="mp3player.swf" width="250" height="400"
 menu="false" quality="low" bgcolor="#ff0000"
 type="application/x-shockwave-flash" pluginspage=
 "" />

       Of these parameters, the most important one is the src in the embed part, which

contains the SWF file to be included. The width and height parameters comply with the

width and height of the SWF in pixels, but they can also be entered as a percentage of the

document's size (e.g: width="100%"). Last, the classic and code base parameters (type

and pluginspage for embed) tell the browsers what type of plug-in is needed and where it

can be downloaded.

       The code listed above uses the minimum amount of parameters needed to properly

embed an SWF file but there are a lot of other parameters available. The parameter

flashvars allows the sending of variables to the SWF file on start-up and enables the

automatic playing of the video file.

       Flashvars are configuration options that can be inserted into HTML code to

control both behavior and appearance of the player. All flashvars options are listed in the


4.2 Network Design and Implementation

4.2.1. Flowcharts General

                                      Figure 10. General Flowchart

       Only members can access the full features of the site. It is the administrator who

approves or rejects applications. Guests, or non-members, only have limited access, and

can only search and view videos available on the site. Guests cannot view videos tagged

for members only, post a comment, access the live video stream or upload videos.

       Members, however, can make full use of these features. Comments can be of text

or video form. Ideally, video files of any format can be uploaded and shared with the

community. Different servers provide the different services available. Members who will

access the site through their 3G-capable or wireless LAN-capable phones will be unable

to access the video upload and live video streaming features of the site. Registration

       As soon as the user connects to the site, he will be confronted with the login page.

The user can choose to login as a member or remain as a guest.
                              Figure 11. Registration Flowchart

       To login as a member, a user has to enter a username and password. If the

username is invalid, the login page will be reloaded and the message “Account is

invalid.” will be displayed. If the password is invalid, the login page will be reloaded and

the error message “Password is incorrect.” will be displayed. If the username and

password are confirmed, the session will be activated. The flag indicator in the database,

which is equivalent to administrator approval, will be set to one. Setting this flag to one

means the user is allowed full access to the site. If the user chooses to remain as a guest,

only a limited number of pages, including the main page (index-main.php), can be


       A guest can choose to apply as a member by navigating to the registration page,

and filling the online form. All fields should be filled or the message “All fields must be

filled in.” will be displayed upon entering the data. Otherwise, a new account will be

created. The user will not be able to login until the system administrator approves his

application to access the service. Video upload

                           Figure 12. Video Upload Flowchart

       Only members can upload videos on the site. For successful video upload, the

following requirements have to be met:

      The file should be in video format.

      The file size should not exceed 50 Mb.

      The chosen filename should be unique (i.e. No other existing video files should

       have the same name.)

      The fields in the video upload form should be completely filled.

       Otherwise, corresponding error messages will be displayed on the screen.

       If the upload is successful, a thumbnail of the video will be generated. The

original video will be converted to FLV and injected with metadata. A 3GP version of the

original video will then be created. This 3GP file will be hinted and saved. The original

video will be deleted and a message indicating successful upload will be displayed.

                         Figure 13 Processes involved in Video Upload. Live streaming

                             Figure 14. Live Streaming Flowchart

       If the registered member chooses to view a live stream, a connection will be

established with the Red5 Flash server. The server responds by sending the livestream

embedded in the webpage through RTMP port 1935. Ratings

                                 Figure 15. Ratings Flowchart

       The numeric rating option is only available to registered members. When a rating

is submitted, the server first checks if the user has already rated the video for the current

session. If the user has already done so, the rating will be discarded. Otherwise, it will be

added to the other ratings to produce a new average. The new average will be displayed

with its equivalent number of stars.


                             Figure 16. Comment Flowchart

       The comment option is only available to registered members, and is the only other

feature available over a mobile phone connection, aside from the feature of video on

demand. When a comment is submitted, it is added to the comment database before being

displayed along with the video on the webpage. Search

                         Figure 17. General Search Flowchart.

          To perform a search, the user has to enter his query on the search field located on

the search page. If the user enters an empty search field, an error message will be

displayed. Otherwise, the server checks the field selected in the video database for its

query and returns the filename and URL of the file. The user can perform a search over

the title, descriptions, channels, categories, sources or names of the registered members

who have uploaded videos. Note that if the user is connected via wireless LAN, the

search can only be performed over one field at any one time. With a 3G connection, a

user can direct a search by entering any keyword in the searchbox.

4.2.2. Discussion

          The thesis was implemented over LAN. The system communicates with the

Darwin, Red5 or Apache servers depending on the video service the client demands. The

Darwin Streaming Server provides services to mobile clients connected via wireless LAN

or 3G (simulated using wireless LAN). The Red5 Flash Server is responsible for

providing live streaming while the Apache server provides videos on- demand in FLV


          The Apache server included in XAMPP is a Hyper Text Transfer Protocol

(HTTP) server which runs in conjunction with MYSQL. Apache interfaces the server and

client to be able to supply video on demand. It sends data packets, receives commands,

and responds to the client through port 80.

          The Red5 Flash server works with FLV files and is mainly used in this thesis for

publishing live streams. This server was not used for streaming FLV files since Red5

documentation is incomplete and the server itself is still undergoing further development.

It communicates via port 1935. The Apache Tomcat server, which is required for running

Red5, communicates through port 8080.

       The Darwin Streaming Server, using port 1220, communicates with the 3G-

capable or wireless LAN-capable mobile handsets using RTSP and UDP. A mobile user

can only view videos on demand and make comments. The Darwin Streaming Server

supports only three types of file: MOV, MP4 and 3GP file formats. Regular MOV, MP4

and 3GP will not be of use since the server only supports “hinted” files of the mentioned

formats. Hinting means adding time and sync stamps to the regular files so that it would

be RTSP-compatible for streaming by the Darwin Streaming Server. These files can be

“hinted” using MP4box, software which adds time and sync stamps to the files in

batches. The following is the command used for hinting:

                     mp4box -3gp -mtu 1450 -hint "'.$filename.'.3gp

       FFmpeg is used for converting user-uploaded files into FLV and 3GP. Ideally, it

should be able to convert original files of any format. The following is the command used

for format conversion using Ffmpeg:

               ffmpeg -i '.$uploadfile." -r 20 -ab 24 -f 3gp -s 352x288 -b 400 -ac 1 -ar

               8000 -y $filename.3gp -vstats $filename.3gp 2>test.txt"

       FLVMDI adds Metadata to an existing FLV file and optionally saves an XML

version of the injected data. Since metadata is information that describes, or supplements,

the central data, it can prove useful for any features that require working with the central

or supplemental data. The following is the command used for injecting metadata:

                             flvmdi /x /k /l "'.$filename.'.flv"

       For the implementation of this thesis, four separate databases are used for easier

system management. These databases are named rating, review, user, and videos.

       The rating database handles the rating of the videos. It has the following columns:

rating_id, video_id, rater, rate, and date_rated. The rating_id is assigned to a particular

video the moment it receives its first rating. Each rated video has a unique rating_id. The

rater column contains the usernames of the members who rated the video. The rate

column contains the ratings made on a particular video. The rate ranges from 0 to 5; the

average is rounded to the nearest hundredths decimal. The dates, as well as times, of

rating instances is recorded in the date_rated column. The rate has an equivalent number

of stars, which will be displayed along with the video.

       The review database handles the comments made on the videos. It has the

following columns: review_id, video_id, comment, reviewer and review_date. The

review_id is assigned to a particular video the moment it receives its first comment. Each

reviewed video has a unique review_id. The reviewer column contains the usernames of

the members who commented on the video. The comment column contains all the

comments made on a particular video. All these comments will be displayed along with

the video, with the latest comment on the top of the list. The date, as well as time, of the

instances the video was reviewed is recorded in the date_rated column.

       The user database contains personal information of the users. It has the following

columns: user_id, username, password, email, birthdate, first, last, mi, nickname, gender,

image, nationality, profile, address, status, flag, date_joined, current_login, lastlogin,

and login_count. Each user is assigned a unique user_id and should have a unique

username. The password chosen by the user is stored in encrypted form. First, last and mi

pertains to the first name, surname and middle initial of the user. A user can upload an

image of himself to be displayed in his or her profile page. This picture will be stored in

image. The profile of a user can be any of the following: student, faculty or alumni. This

serves to ensure that users are limited to individuals with close ties with the university.

The status of a user mainly depends on the administrator. A user can be considered as a

guest or member, or be recognized as the administrator. The flag is the aforementioned

indicator that is equivalent to administrator approval.

       The videos database contains relevant information about the videos uploaded and

stored by the users. It contains the following columns: video_id, title, description,

channel,   category,    source,    uploader,    email,    file_name,   file_size,   file_type,

date_uploaded, thumbnail, view, rate_total, rate_current. The three channels used to

classify the videos are administrative, instructional and extra-curricular. Administrative

videos refer to video files produced by members of the university administration. These

include homilies, book launchings and seminars held on campus. Instructional videos

refer to video files that are taken by members of the faculty or of the student body that

promote academic learning. Extra-curricular videos include videos produced by student

organizations and varsity teams. Category gives a one-word description of the video

content, whether it is related to sports, or an organization, whether it be a lecture,

advertisement, report or movie. Source refers to whoever produced the video; this is

different from uploader, which refers to the specific user who uploaded the video on the

site. View refers to the number of times the video has already been viewed. This database

is also linked to the rating database, as seen by the columns rate_total and rate_current.

The rate_total column refers to the total of all ratings made on a particular video while

rate_current refers to the current average rating of the video.

       During the implementation, it was noted that sufficient attention be given to the

location of the wireless devices relative to the access points since the transmission rate is

very much affected by distance and obstacles between the router and the wireless LAN


          The performance of the network was measured through a network packet analyzer

which examines the throughput of the network interface device of the server and client.

Ethereal is the open source program used to perform this task.

4.2.3. Server Settings

 Settings (xampp-win32-1.5.5-installer)

          php.ini settings: (found in xampp/apache/ bin/php.ini)

          post_max_size = 50M
          output_buffering = ON
          max_execution_ time = 300
          upload_max_filesize =50M
          session.auto_ start= 1

 Red5 Settings (From

          rtmp.host_port =
          debug_proxy.host_port =
          proxy_forward.host_port =
          rtmps.host_port =

          webapp.virtualHosts=*,localhost, localhost:5080,

                                                                                          54 Darwin Streaming Server Settings

                       Figure 18. General settings.

                         Figure19. Log settings.

                         Figure 20. Port settings.

                                     CHAPTER 5
                                 Results and Discussion

5.1. Results with Ethereal

       The correct filters have to be set first before using Ethereal for performance

analysis. For this thesis, the network devices involved, as well as the IP addresses of the

server and clients were specified.

5.1.1. Live Streaming

       This set-up was implemented over wireless LAN and involved a webcam

streaming at 30 fps with 320 x 240 resolution. Six clients belonging to the same subnet

were connected one by one. Upon starting the Red5 Flash streaming server, there was

approximately zero outgoing bps registered on the Ethereal network analyzer. Whenever

a client tried to establish a connection to the server, there was a spike in the graph at

around 100kbps for a fraction of a second. This spike was due to the loading of the

service on the client's side. As the clients were connected one by one, the following

throughput values were recorded:

   1. 17kbps with one client connected,

    2. 34kbps with two clients connected,

    3. 50.9 kbps with three clients connected,

    4. 63kbps with four clients connected,

    5. 87kbps with five clients connected, and

    6. 93kbps with all clients connected.

       On the client side, the recorded incoming data for each client was relatively stable

at 17 kbps. Outgoing traffic was unnoticeable in Ethereal, registering only a few

kilobytes. On the other hand, through traffic (i.e. total flow of traffic on all connections)

was observed to be unequal to the total of all the kilobytes sent by the server perhaps

because some of the packets have already been received by the other clients beforehand.

              Figure 21. Six clients connected to Red5 Flash server over wireless LAN.

       The graph below shows the throughput results for 13 clients connected to the

Red5 Flash server over wired LAN. This set-up involved live streaming at 30 fps with

320 x 240 resolution. There was a progressive increase in the throughput, with the usual

spike occurring whenever a client establishes connection. The graph in red shows the

instances when the clients connect to the server. This was derived by filtering the HTTP

protocol as it is used for making requests to the server.

                  Figure 22. Thirteen clients accessing live streams over wired LAN.

Figure 23. Network configuration for wireless LAN with 6 clients (below) and wired LAN with 13 clients

5.1.2. Apache Server

       For delivering videos on demand over wireless LAN using the Apache server,

FLV files encoded at 30fps were used. Starting with 0 bps as the incoming throughput, it

was observed that whenever a client received a video from the server, there was a sudden

increase for about 4-5 seconds before going back to 0 bps. The increase depended on the

size of the file. The outgoing throughput, on the other hand, is very small, with only a

few kilobytes because it is just for the request protocol involved.

       On the client side, the FLV file was received in its entirety and saved in the cache.

It was then played by the FLV Player embedded in the web page. The same results were

obtained in the case of multiple clients.

       Performance of the system during upload of a 10MB FLV file was analyzed using

Ethereal. The graph showed that 2.3 Mbps registered for about 6 seconds, after which the

outgoing throughput returned to zero. The page indicating successful file upload appeared


                 Figure 24. Graph for video upload of a 10MB FLV file.

       The graph below shows the results with 13 clients connected to the server via

wired LAN. The clients tried to access a 20MB video file one at a time using the Apache

server. A sudden increase appeared in the graph whenever the clients established

connection. This went back to zero in approximately 5 seconds. This means that the video

was immediately downloaded and saved in the computer's cache as it was played in the

browser. There was also the occasional superimposition of the throughput whenever a

client established connection while another was still downloading the video.

                    Figure 25. Accessing video on demand using wired LAN.

       The graph below shows the bytes received by the server as a client tried to upload

a 40MB file. The session lasted for 20 seconds, and transferred data at an average rate of

approximately 20MBps.

                        Figure 26. Graph of video upload for a 40MB file.

               Figure 27. Network configuration for video upload over wireless LAN.

5.1.3. Darwin Streaming Server

       The Darwin Streaming Server for mobile devices used 3GP files encoded at 15

fps. The graph below shows the throughput results when two mobile devices connected

via wireless LAN accessed the video on demand service using the Darwin Streaming

Server. The file had a duration of four minutes and twelve seconds, and a size of 6.1 MB.

The file was accessed within a 20 second interval. The throughput doubled as the two

devices simultaneously accessed the file. In this set-up, the files are not recorded and

stored in a cache since the mobile devices either have small or no cache for video files.

               Figure 28. Two mobile devices accessing the Darwin Streaming Server.

       The graph below shows the throughput when a single mobile device accessed the

video on demand service and established connection with the Darwin Streaming Server.

              Figure 29. Single mobile device accessing the Darwin Streaming Server.

                      Figure 30. Network configurations over wireless LAN

             involving two mobile devices (above) and a single mobile device (below).

5.2. Streaming and Video on Demand Results

       The infrastructure successfully published a live video stream for stationary clients

using a webcamera and the Red5 Flash Server. This is evidenced by Figure 31 below:

                               Figure 31. Live streaming screenshot.

A very slight delay (not exceeding two seconds) was observed between the actual

movement and the movement displayed via live streaming.

       Video on demand was successful for LAN connections. It should be noted

however that the 3G connection was merely simulated using wireless LAN since the

group had no access to the actual 3G network.

               Figure 32. Screenshot of the original video (mondyreport_cie.mp4).

      File Type                  MP4                       3GP                       FLV
   Stream 0 Type                 video                     video                     video
       Codec                     mp4v                      h263                      flv1
     Resolution                320x240                   352x288                    320x240
 Display resolution            320x240                   352x288
     Frame rate               30.000000                 20.000000

    Stream 1 Type                 audio                     audio                      audio
        Codec                     mp4a                      samr                        mp3
       Channels                     2                         1                          2
     Sample rate               32000 Hz                   8000 Hz                     22050 Hz
   Bits per sample                  16                        16                        16
        Bitrate                 512 kbps                  128 kbps
   AAC extension                  SBR

       Duration                  0:05:46

                  Table 3. Comparison of video files after conversion using FFmpeg.

       The table above shows some characteristics of the original video file shown in

Figure 23, as well as its equivalents in FLV and 3GP. These results were obtained using

one of the features available in the VLC Media Player.

       Obviously, each type of file makes use of different audio and video codecs.

Converting the original video to 3GP increased its resolution, while converting it to FLV

did not make any difference. The frame rate decreased when the original video was

converted to 3GP. Unfortunately, there was no way of knowing the effect on video frame

rate in converting the original video file to FLV. The audio sample rate and bitrate

decreased when the original video was converted to 3GP. Unlike FLV and MP4, only one

channel was used for audio with 3GP.

       The table shows that the 3GP file occupies less bandwidth compared to the

original video file.

5.3. Channels and Features

       The implemented video platform has three channels: Ignacio, Greg&Joey and

MVP. Videos from the administrative offices are sorted into the Ignacio channel, while

class reports, projects and lectures are classified under Greg&Joey (named after the

group's thesis advisers). The MVP channel contains videos from the various

organizations and varsity teams. Here is a screenshot of the main page of the website:

                               Figure 33. Main menu screenshot.

       The following is a list of features included in the site:

      Video upload

      Video search

      Video rating

      Live streaming

      Video-on-demand

      Text and video comments

      Live feed comments

      Background information on videos delivered by video jockeys

      Picture In Picture (PIP)

The platform can be expanded through integration with televisions located in the

cafeteria, or IP camera stations that can be deployed around campus.

       Here are some screenshots that give an idea of the platform's interactive features:

                         Figure 34. Screenshot showing text comments.

                          Figure 35. Image demonstrating PIP.

                                    CHAPTER 6
                          Conclusion and Recommendations

       The Framework for an Interactive Video Environment is a pioneer in the field of

Internet Protocol Television (IPTV) and video-on-demand.In this thesis, the group was

able to develop a fully functional and interactive video streaming and video on demand

portal that can also be customized to suit various and specific needs. The implemented

infrastructure is flexible enough to be accessed over LAN or 3G. There was a near

convergence of the mobile and PC platforms, since stationary or mobile clients access the

same databases. Educational institutions like medical schools can use this interactive

video framework as another channel to deliver knowledge in an effective and efficient

manner. In this thesis, a specific community (Ateneo De Manila University) served as a

case study for the interactive video framework.

       This portal can be further improved by adding more interactive functions. Live

streaming could be made available to mobile clients. In case there is significant

development of the Red5 Flash server, the infrastructure can be simplified by using it for

both video on demand and live streaming services. PHP streaming is also an alternative

option for servicing video on demand requests. The addition of a content management

system would greatly ease the management of the portal. The features that appear on the

site could also be varied, depending on the profile of the user (i.e. whether the user is a

student, faculty or alumni). Possible customization of the portal for use in other settings

could also be implemented to serve as further case studies. The video portal's integration

with the actual IPTV network, or at least with the customer premises equipment, could

help to advance the development of IPTV in the Philippines.

                                          CHAPTER 7

3G Tutorial. Turner, B. and Orange, M.

A webserver guide—help using Apache. Goyal, N.

An overview of 3G mobile network infrastructure. Miah, A. and Tan, K.

Apache Tomcat.

Can IP camera technology truly serve the networking issue?

Darwin Streaming Server.,
Retrieved on 2007-02-05.

Delivering Flash Video: Understanding the Difference Between Progressive Download and
Streaming Video.

FFmpeg Documentation., Retrieved on 2007-02-05.

Flash Player Statistics.

Flash Video 101: Flash Video Delivery Options. James Gonzalez.

Flash Video Player 3.5.

FLV video Compression.

Internet Protocol Television (IPTV).

Introduction - How to create streaming video.

Microsoft (April 24, 2003). Microsoft Windows Server 2003 Is Available Worldwide Today.,
Retrieved on 2007-02-05.

MP4Box Documentation.

Red 5., Retrieved on 2007-02-05.


Streaming Technology in 3G Mobile Communication Systems. Elsen,I., Hartung,F., Horn, U.,
Kampmann, M. and L. Peters.

Streaming vs Progressive Download vs PHP streaming.

Symbian and RealNetworks form alliance to enable mobile media experiences for next generation
mobile handsets.

TIME Best Inventions 2006 (November 7, 2006)., Retrieved on

                             Appendix A: Video File Formats

Flash Video (FLV)

          The Macromedia Flash Video format lets the user import or export a static video

stream with encoded video. This format is intended for use in communications

applications, examples of which are video conferencing. Common websites that use FLV

are YouTube and Google Video.

          When videos are exported with streaming audio in FLV format, the audio is

compressed using the Streaming Audio settings in the Publish Settings dialog box. Files

in the FLV format are compressed with the Sorensen codec. The Sorensen codec is an

innovative compression codec that have advanced the horizons in areas such as vector

quantization, discrete cosine transform, fractals, wavelets, and sophisticated motion

compensation techniques.

Audio Video Interleaver (AVI)

          The AVI file format is based on the Resource Interchange File Format (RIFF).

The Microsoft AVI file format is a RIFF file specification used with applications that

capture, edit, and play back audio-video sequences. In general, AVI files contain multiple

streams of different types of data. Most AVI sequences use both audio and video streams.

A simple variation for an AVI sequence uses video data and does not require an audio


Moving Picture Experts Group 4 (MPEG-4)

          MPEG4 was created by the Moving Pictures Experts Group (MPEG), the working

group within the International Organization for Standardization that also gave us the

widely used standards MPEG-1, MPEG-2 and MPEG-3, popularly known as MP3.

MPEG-4 is a universal multimedia standard that can deliver good quality audio and video

streams over a range of bandwidths, from cell phones to websites.

       For developers, MPEG-4 enables the production of content that has greater

reusability and greater flexibility than is possible today with individual technologies such

as digital television, animated graphics, World Wide Web pages and their extensions. For

end users, MPEG-4 brings higher levels of interaction with content, within the limits set

by the developer. End user applications include interactive multimedia broadcast and

mobile communications.

3rd Generation Partnership Project (3GPP)

       3GPP and 3GPP2 are the worldwide standards for the creation, delivery and

playback of multimedia over 3rd generation, high-speed wireless networks. 3GPP was

established in December 1998 by the signing of the “The 3 rd Generation Partnership

Project Agreement”.

       The original scope of 3GPP was to produce global applicable Technical

Specifications and Technical Reports for a 3rd Generation Mobile System based on

evolved GSM core networks and the radio access technologies that they support (e.g.

Universal Terrestrial Radio Access, Frequency Division Duplex and Time Division

Duplex modes). The scope was subsequently amended to include the maintenance and

development of the Global System for Mobile communication Technical Specifications

and Technical Reports including evolved radio access technologies (e.g. General Packet

Radio Service and Enhanced Data rates for GSM Evolution).

                                 Appendix B: IP Cameras

       IP cameras are cameras that basically plug directly into a network. They are also

digital, meaning that the video is broken down into data packets, which allows

compression and throttling to take place. IP cameras do the compressing at the camera.

Throttling is basically managing the amount of data that is sent. Additionally, IP cameras

allow you to alter the frames per second and the resolution. .

       IP cameras offer flexibility in the access of information and video. Analog camera

systems require a point-to-point mode, where a constant video stream of frames is sent

from the camera to the DVR. With analog camera systems, traditionally viewing could

normally only be done on designated stations that have hardware connected directly to

the camera. IP cameras allow access to the camera via the basic web browser as long as

one has access to the network.

       IP cameras are ideal for traffic control, video conferencing, process control, or

marketing and advertising. They are perfect for companies that want multiple persons to

have access to view their facility, like the travel industry. IP cameras are also used for

applications that just want to drop in a camera for temporary purposes: Covert operations,

construction sites, or remote facilities that have difficulty housing a recording device on-

site, due to lack of environmental or vandal safe structures. IP cameras also allow offsite

recording of video.

       To be considered a network IP camera, all that is required is that the camera be

connected directly (wired or wireless) to the network to send and receive video

information. Image quality, resolution, frame speed and the amount of bandwidth

required to transmit are typical considerations in choosing IP cameras, but one must also

consider the embedded operating systems, storage capability (for example, 560 images at

320x240) and software that allows integration to other security and surveillance

solutions. IP cameras eliminate the need for point-to-point connection to a PC. The IP

camera maintains its own IP/TCP or UDP address and its operating software to manage

the video and integrate with other devices such as access control. The PC is only needed

for programming, playback, viewing and recording. But the IP camera industry now uses

IP servers that allow a single controller (or multiple controllers if the application calls for

it) to manage hundreds even thousands of cameras.

                              Appendix C: Flashvars Options

        Flashvars are configuration options that can be inserted into HTML code to

control both behavior and appearance of the player. In the lists below, all flashvars are



       file (url): The location of the file to play. It can be a single file
         (MP3/FLV/RTMP/JPG/SWF/PNG/GIF) or a playlist for the players. The rotator
         only accepts playlists.
       image (url): If you play MP3 of FLV files, you can use this flashvar to show a
         preview image or album cover. It can be a JPG/SWF/PNG/GIF file.
       displayheight (number): This flashvar is used by the players and sets the height
         of the display. It defaults to the height of the SWF object minus the controlbar
         (20px), but if you set it to a smaller height, the playlist will show up. If you set it
         to exactly the height of the SWF object, the controlbar wil disappear as well.
       transition (fade,bgfade,blocks,circles,fluids,lines,random): This flashvar is only
         used by the rotator. It sets the transition to use between images. "random" will
         show all transitions randomly. The default is "fade".
       shownavigation (true,false): Another flashvar only for the rotator. It
         enables/disables the navigation bar.

       backcolor (color): Backgroundcolor of the player/rotator. In the "extras" folder
        of this download there's a colorpicker script with which you can pick a color
        value. The default for the players is 0xFFFFFF (white) and for the rotator
        0x000000 (black).
       frontcolor (color): Texts / buttons color of the player/rotator. The default for the
        players is 0x000000 (black) and for the rotator 0xFFFFFF (white).
       lightcolor (color): Rollover/ active color of the player/rotator. The default for the
        players is 0x000000 (black) and for the rotator 0xCC0000 (red).

     showicons (true,false): Show or hide the play and activity icons in the middle of
       the display. Defaults to true for the players and false for the rotator.
     overstretch (true,false,fit,none): Defines how to stretch images/movies to make
       them fit the display. "true" will stretch them proportionally to fill the display,
       "false" will stretch them to fit. "fit" will stretch them disproportionally to fit both
       height and width. "none" will show all items in their original dimensions.
       Defaults to "fit" for the players and "false" for the rotator.

   logo (url): Set this flashvar to put a watermark logo in the bottom right corner of
     the display. If you've set the "link" flashvar as well, the logo will link to there.
     Again, all image formats are supported, but transparent PNG files give the best
   captions (url): You can set this flashvar to the location of a textfile with captions.
     The players support SMIL's TimedText format and the SRT format used with
     ripped DVD's. An example of both formats can be found in the "extras" folder of
     the download.
   showeq (true,false): Set to true to show a fake equalizer in the display. It adds a
     nice graphical touch when you are playing MP3 files.
   showdigits (true,false): Set this to false if you don't want the elapsed/remaining
     time to display in the controlbar of the players. Quite handy to save some space.
   thumbsinplaylist (true,false): If you have a playlist that also includes preview
     images with the <image> element, you can set this flashvar to "true" to show
     them in the playlist.
   autoscroll (true,false): By default, the playlist area of the players will have a
     scrollbar if the number of items is too long. If you set this flashvar to "true", the
     scrollbar wil disappear and the playlist will scroll automatically, depending upon
     the mouse position.

   fullscreenpage (url): The players automatically show a fullscreen button if a user
     has installed a flashplayer capable of true fullscreen (from 9.0.28). With this
     flashvar, you can also present a sort-of fullscreen for users who have an older
     version of the Flash plugin. A click on the fullscreen button will jump to the
     HTML page you specified here. In this HTML page, you can present a full-
     browser-screen version of the flvplayer/mediaplayer (just like in the download's
   fsreturnpage (url): To let the browser know what page to jump to when
     somebody wants to close the semi-fullscreen, you can set the "normal" page as
     the fsreturnpage flashvar. It will be passed through to the fullscreen page with a
   fullscreenmode (true,false): Set this flashvar to true for embedding of the player
     in the fullscreen page. The player will then get the "file","image","id" and
     "fsreturnpage" flashvars from a cookie and will present the "normal screen"
     button in the playlist, instead of the "full screen" button.
   showfsbutton (true,false): Set this flashvar to false to hide the fullscreenbutton,
     even if flash9 is detected.

   link (url): If you have set a watermark logo, you can set this flashvar to a web
     address you want the logo to link to.
   linkfromdisplay (true,false): Additionally, you can set this flashvar to "true" to
     make a click on the image/video display result in a jump to the "link" webpage.

   linktarget (frame): The targetframe a link (from logo, display or playlist buttons)
     will open into. The default is "_self". Set it to "_blank" to open links in a new
   callback (url): Set this flashvar to the location of a serverside script (PHP/ASP)
     that can process callbacks. The players will send a callback every time an item
     starts/stops, so you can save statistics with the serverside script. More info can be
     found in this demonstration page. An example callback script is placed in the
     "extras" folder of the downloads.
   enablejs (true,false): Set this to true to enable javascript interaction. This'll only
     work online! Javascript interaction includes playback control, asynchroneous
     loading of media files and return of track information to javascript.An example
     of all supported javascript functions can be found on this page.

   autostart (true,false): Set this to "true" to make the player automatically start
     playing when the page loads.
   volume (number): The default volume for playback of sounds/movies is 80, but
     you can set another value with this flashvar.
   shuffle (true,false): If you use a playlist, the players and rotator will automatically
     shuffle the entries to prevent boredom. Set this flashvar to "false" to play all
     items sequentially.
   repeat (true,false,list): By default, the players will stop playback after every item
     to preserve bandwidth (repeat=false). You can set this to "list" to playback all
     items in a playlist once, or to "true" to continously playback your
     song/movie/playlist. The rotator's default is "true".
   rotatetime (number): Use this flashvar to set the number of seconds you want an
     image to display. The default is "10" for the mediaplayer and "5" for the rotator.
   bufferlength (number): This sets the number of seconds an FLV should be
     buffered ahead before the player starts it. Set this smaller for fast connections or
     short videos. Set this bigger for slow connections. The default is 5 seconds.
   streamscript (url): This flashvar is the URL of an optional script to use for 'fake
     streaming' FLV files, eg. through PHP, ASP or LigHTTPD. The parameters 'file'
     and 'pos' are sent to the script.


To top