Your SlideShare is downloading. ×
0513_FR.doc
0513_FR.doc
0513_FR.doc
0513_FR.doc
0513_FR.doc
0513_FR.doc
0513_FR.doc
0513_FR.doc
0513_FR.doc
0513_FR.doc
0513_FR.doc
0513_FR.doc
0513_FR.doc
0513_FR.doc
0513_FR.doc
0513_FR.doc
0513_FR.doc
0513_FR.doc
0513_FR.doc
0513_FR.doc
0513_FR.doc
0513_FR.doc
0513_FR.doc
0513_FR.doc
0513_FR.doc
0513_FR.doc
0513_FR.doc
0513_FR.doc
0513_FR.doc
0513_FR.doc
0513_FR.doc
0513_FR.doc
0513_FR.doc
0513_FR.doc
0513_FR.doc
0513_FR.doc
0513_FR.doc
0513_FR.doc
0513_FR.doc
0513_FR.doc
0513_FR.doc
0513_FR.doc
0513_FR.doc
0513_FR.doc
0513_FR.doc
0513_FR.doc
0513_FR.doc
0513_FR.doc
0513_FR.doc
0513_FR.doc
0513_FR.doc
0513_FR.doc
0513_FR.doc
0513_FR.doc
0513_FR.doc
0513_FR.doc
0513_FR.doc
0513_FR.doc
0513_FR.doc
0513_FR.doc
0513_FR.doc
0513_FR.doc
0513_FR.doc
0513_FR.doc
0513_FR.doc
0513_FR.doc
0513_FR.doc
0513_FR.doc
0513_FR.doc
0513_FR.doc
0513_FR.doc
0513_FR.doc
0513_FR.doc
0513_FR.doc
0513_FR.doc
0513_FR.doc
0513_FR.doc
0513_FR.doc
0513_FR.doc
0513_FR.doc
0513_FR.doc
0513_FR.doc
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

0513_FR.doc

1,169

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
1,169
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
10
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. X-Stream TV Final Project Report Senior Project Session 2001-2005 Submitted By Atif Shah 2005-02-0031 Nehdia Sameen 2005-02-0124 Usman Dawood 2005-02-0197 Yasir Baghpati 2005-02-0275 Department of Computer Science Lahore University of Management Sciences
  • 2. A report submitted to the Department of Computer Science in partial fulfillment of the requirements for the degree BSc (Honours) in Computer Science by Atif Shah Nehdia Sameen Usman Dawood Yasir Jawed Baghpati Lahore University of Management Sciences May 13, 2005 X-Stream TV i
  • 3. Statement of Submission Submitted to: _______________________ Dr. Shahid Masud Primary Project Advisor _______________________ _______________________ Dr Tariq Jadoon Dr. Jehangir Ikram Secondary Project Advisor Secondary Project Advisor X-Stream TV ii
  • 4. Acknowledgements We truly acknowledge the assistance of our Senior Project advisors – Dr. Shahid Masud, Dr. Jahangir Ikram and Dr. Tariq Jadoon for their comments, recommendations, and regular critique of our work that guided us through our project. We are also thankful to Dr. Asim Loan, Senior Project Coordinator, for his continual guidance and support during the development of this project. (Signed) Atif Shah 2005-02-0031 Nehdia Sameen 2005-02-0124 Usman Dawood 2005-02-0197 Yasir Jawed Baghpati 2005-02-0275 Date May 13, 2005 X-Stream TV iii
  • 5. Abstract We have been unable to locate any software in the local market available to the small business/home user that allows the streaming of multimedia information from an external television source (e.g. TV antenna, cable, cassette/VCD/DVD players, etc.) over a TCP/IP network. Our product allows the end user to receive TV input (using a TV Tuner and a soundcard) and broadcast it to network client(s). Our product does not include client software (e.g. multimedia players, etc.), but provides a multimedia stream that is compatible with most popularly available client applications (e.g. Windows Media Player, WinAmp). To provide a viable product, we plan to include a real-time compression engine that compresses the audiovisual information to a variable bit rate that can be broadcast over a TCP/IP network without significant loss in quality. Potential applications for such software include the following: • broadcasting TV channels from a single cable connection to multiple network clients • broadcasting live or pre-recorded video feeds (such as presentations, lectures or documentaries) on an office or campus network • individual users can access their personal cable connection or video collection via a network X-Stream TV iv
  • 6. Table of Contents STATEMENT OF SUBMISSION.......................................................................................................................II ACKNOWLEDGEMENTS................................................................................................................................III ABSTRACT.........................................................................................................................................................IV TABLE OF CONTENTS.....................................................................................................................................V LIST OF FIGURES.............................................................................................................................................IX LIST OF TABLES................................................................................................................................................X CHAPTER 1 INTRODUCTION..................................................................................................................................................1 1.1 BENEFITS........................................................................................................................................................1 1.2 OBJECTIVES .................................................................................................................................................2 CHAPTER 2 REQUIREMENTS AND ANALYSIS..................................................................................................................3 2.1 PRODUCT PERSPECTIVE...........................................................................................................................3 2.1.1 USER INTERFACES...........................................................................................................................................3 2.1.2 HARDWARE INTERFACES..................................................................................................................................3 2.1.3 SOFTWARE INTERFACES....................................................................................................................................3 2.1.4 COMMUNICATIONS INTERFACES.........................................................................................................................4 2.1.5 MEMORY CONSTRAINTS...................................................................................................................................4 2.1.6 OPERATIONS..................................................................................................................................................4 2.1.7 SITE ADAPTATION REQUIREMENTS......................................................................................................................4 2.2 PRODUCT FUNCTIONS...............................................................................................................................5 2.3 USER CHARACTERISTICS ........................................................................................................................5 2.4 CONSTRAINTS...............................................................................................................................................5 2.5 ASSUMPTIONS AND DEPENDENCIES.....................................................................................................6 2.6 SPECIFIC REQUIREMENTS.......................................................................................................................6 2.6.1 EXTERNAL INTERFACE REQUIREMENTS................................................................................................................6 a) User interfaces...........................................................................................................................................6 b) Hardware interfaces..................................................................................................................................7 c) Software interfaces....................................................................................................................................7 d) Communications interfaces.......................................................................................................................8 CHAPTER 3 DESIGN..................................................................................................................................................................9 3.1 MODULE DECOMPOSITION......................................................................................................................9 3.1.1 MODULE 1.0 – GET FEED...............................................................................................................................9 a) Module 1.1 Initiate Session.......................................................................................................................9 b) Module 1.2 Interface with TV Tuner + Sound Card..................................................................................9 c) Module 1.3 Get Audio/Video Stream.........................................................................................................9 3.1.2 MODULE 2.0 – ENCODE STREAM...................................................................................................................10 a) Module 2.1 Get Stream............................................................................................................................10 b) Module 2.2 Configure Encoder...............................................................................................................10 c) Module 2.3 Encode Stream......................................................................................................................10 3.1.3 MODULE 3.0 – NETWORK OUTPUT.................................................................................................................10 X-Stream TV v
  • 7. a) Module 3.1 Interface with Network Card................................................................................................11 b) Module 3.2 Generate RTSP Packets........................................................................................................11 c) Module 3.3 Output to Network................................................................................................................11 3.1.4 MODULE 4.0 – GENERATE FEEDBACK.............................................................................................................11 a) Module 4.1 Get Statistics.........................................................................................................................11 b) Module 4.2 Tabulate Results...................................................................................................................11 c) Module 4.3 Generate Feedback...............................................................................................................11 CHAPTER 4 CHOOSING THE APPROPRIATE SDK.........................................................................................................12 CHAPTER 5 QUALITY ASSURANCE...................................................................................................................................13 5.1 OBJECTIVES................................................................................................................................................13 5.2 BACKGROUND............................................................................................................................................13 5.3 SCOPE............................................................................................................................................................13 5.4 REFERENCES...............................................................................................................................................13 5.5 TEST ITEMS.................................................................................................................................................14 5.5.1 PROGRAM MODULES .....................................................................................................................................14 5.5.2 JOB CONTROL PROCEDURES ............................................................................................................................14 5.5.3 USER PROCEDURES .......................................................................................................................................14 5.5.4 OPERATOR PROCEDURES.................................................................................................................................14 5.6 FEATURES TO BE TESTED......................................................................................................................15 5.7 FEATURES NOT TO BE TESTED.............................................................................................................15 5.8 APPROACH...................................................................................................................................................15 5.8.1 LIVE STREAMING..........................................................................................................................................15 5.8.2 FILE STREAMING...........................................................................................................................................16 5.8.3 FILE RECORDING...........................................................................................................................................16 5.8.4 INTERFACE TESTING.......................................................................................................................................16 5.8.5 PERFORMANCE TESTING.................................................................................................................................16 5.8.6 COMPREHENSIVENESS....................................................................................................................................16 5.9 ITEM PASS/FAIL CRITERIA....................................................................................................................17 5.10 SUSPENSION CRITERIA AND RESUMPTION REQUIREMENTS .................................................18 5.10.1 SUSPENSION CRITERIA .................................................................................................................................18 5.10.2 RESUMPTION REQUIREMENTS.........................................................................................................................18 5.11 TEST DELIVERABLES ............................................................................................................................18 5.12 TESTING TASKS........................................................................................................................................18 5.13 ENVIRONMENTAL NEEDS.....................................................................................................................19 5.13.1 HARDWARE...............................................................................................................................................19 5.13.2 SOFTWARE.................................................................................................................................................19 a) Operating system.....................................................................................................................................19 b) Communications software.......................................................................................................................19 5.13.3 SECURITY..................................................................................................................................................19 5.13.4 TOOLS......................................................................................................................................................19 5.13.5 PUBLICATIONS............................................................................................................................................19 5.14 RESPONSIBILITIES..................................................................................................................................19 5.14.1 SYSTEM TEST GROUP...................................................................................................................................20 X-Stream TV vi
  • 8. 5.14.2 PROJECT ADVISORS......................................................................................................................................20 5.15 STAFFING AND TRAINING NEEDS......................................................................................................20 5.16 SCHEDULE..................................................................................................................................................20 5.17 RISKS AND CONTINGENCIES...............................................................................................................20 ATTACHMENT A: TASK LIST.......................................................................................................................21 5.18. TEST DESIGN SPECIFICATIONS.........................................................................................................22 5.18.1 XD1: LIVE STREAMING FROM EXTERNAL SOURCE............................................................................................22 Features to be tested....................................................................................................................................22 Approach refinements..................................................................................................................................22 Test identification.........................................................................................................................................22 Feature pass/fail criteria.............................................................................................................................23 5.18.2 XD2. STREAMING A PRE-EXISTING FILE ON THE SERVER...................................................................................23 Features to be tested....................................................................................................................................23 Approach refinements..................................................................................................................................23 Test identification.........................................................................................................................................24 5.18.3 XC3: PRE-EXISTING FILE............................................................................................................................24 Feature pass/fail criteria.............................................................................................................................24 5.19 TEST CASE SPECIFICATIONS...............................................................................................................25 5.19.1 XC1. VCD PLAYER..................................................................................................................................25 Test items.....................................................................................................................................................25 Input specifications......................................................................................................................................25 Output specifications...................................................................................................................................25 Environmental needs....................................................................................................................................25 5.19.2 XC2. DIGITAL CAMERA..............................................................................................................................26 Test items.....................................................................................................................................................26 Input specifications......................................................................................................................................26 Output specifications...................................................................................................................................26 Environmental needs....................................................................................................................................26 5.19.3 XC3. PRE-EXISTING FILE............................................................................................................................27 Test items.....................................................................................................................................................27 Input specifications......................................................................................................................................27 Output specifications...................................................................................................................................27 Environmental needs....................................................................................................................................27 5.20 TEST PROCEDURE SPECIFICATIONS................................................................................................29 5.20.1 XP1. EXECUTING ALL TEST CASES................................................................................................................29 Purpose........................................................................................................................................................29 Special requirements....................................................................................................................................29 Procedure steps............................................................................................................................................29 5.21 TEST INCIDENT REPORTS....................................................................................................................30 5.21.1 XI1. INCIDENT REPORT 1............................................................................................................................30 5.21.2 XI2. INCIDENT REPORT 2............................................................................................................................31 5.21.3 XI3. INCIDENT REPORT 3............................................................................................................................31 5.21.4 XI4. INCIDENT REPORT 4............................................................................................................................32 5.21.5 XI5. INCIDENT REPORT 5............................................................................................................................33 5.21.6 XI6. INCIDENT REPORT 6............................................................................................................................34 5.21.7 XI7. INCIDENT REPORT 7............................................................................................................................35 5.21.8 XI8. INCIDENT REPORT 8............................................................................................................................36 5.21.9 XI9. INCIDENT REPORT 9............................................................................................................................37 5.21.10 XI10. INCIDENT REPORT 10......................................................................................................................38 X-Stream TV vii
  • 9. 5.21.11 X11. INCIDENT REPORT 11........................................................................................................................39 5.22 TEST SUMMARY REPORT.....................................................................................................................40 5.22.1 XS1. OVERALL SUMMARY REPORT................................................................................................................40 Summary......................................................................................................................................................40 Variances.....................................................................................................................................................40 Comprehensive assessment..........................................................................................................................40 Summary of results.......................................................................................................................................41 Evaluation....................................................................................................................................................42 Summary of activities...................................................................................................................................43 5.23 TEST RESULTS..........................................................................................................................................44 CHAPTER 6 DEPLOYMENT ..................................................................................................................................................55 CHAPTER 7 RESULTS AND CONCLUSION.......................................................................................................................56 CHAPTER 8 FUTURE WORK.................................................................................................................................................57 APPENDIX A WINDOWS MEDIA VS. MICROSOFT DIRECTSHOW..............................................................................58 APPENDIX B STREAMING TECHNOLOGY.........................................................................................................................62 X-Stream TV viii
  • 10. List of Figures FIGURE 1: DIAL-UP MODEMS OR SINGLE-CHANNEL ISDN (28.8 TO 56 KBPS)..............................44 FIGURE 2: LAN, CABLE MODEM, OR XDSL (100 TO 768 KBPS)...........................................................45 FIGURE 3: DIAL-UP MODEMS OR LAN (28.8 TO 100 KBPS)..................................................................46 FIGURE 4: DIAL-UP MODEMS (28.8 KBPS)................................................................................................47 FIGURE 5: DIAL-UP MODEMS (56 KBPS)...................................................................................................48 FIGURE 6: LOCAL AREA NETWORK (100 KBPS).....................................................................................49 FIGURE 7: LOCAL AREA NETWORK (256 KBPS).....................................................................................50 FIGURE 8: LOCAL AREA NETWORK (384 KBPS).....................................................................................51 FIGURE 9: LOCAL AREA NETWORK (768 KBPS).....................................................................................52 FIGURE 10: 28.8 MODEM WITH SAVE TO FILE OPTION.......................................................................53 FIGURE 11: LOCAL AREA NETWORK (768 KBPS) WITH SAVE TO FILE OPTION.........................54 X-Stream TV ix
  • 11. List of Tables TABLE 1: PROGRAM MODULES..................................................................................................................14 TABLE 2: USER PROCEDURES.....................................................................................................................14 TABLE 3: OPERATOR PROCEDURES.........................................................................................................14 TABLE 4: FEATURES TO BE TESTED.........................................................................................................15 TABLE 5: ITEM PASS/FAIL CRITERIA.......................................................................................................17 TABLE 6: TASK LIST........................................................................................................................................21 TABLE 7: VCD PLAYER TEST ITEMS.........................................................................................................25 TABLE 8: DIGITAL CAMERA TEST ITEMS...............................................................................................26 TABLE 9: PRE-EXISTING FILE TEST ITEMS............................................................................................27 TABLE 10: TEST ITEM ASSESSMENT.........................................................................................................41 TABLE 11: TEST ITEM EVALUATION.........................................................................................................42 X-Stream TV x
  • 12. Chapter 1 Introduction The application being developed, X-Stream TV is an engine for streaming live multimedia over a network. The objective of X-Stream TV is taking a live feed from a TV Tuner and sound card, and streaming it over a network in real time. Its intended uses include video conferencing, live TV distribution, and live presentation viewing, etc. using a pre-existing network. Depending on usage, the live feed is obtained from a TV antenna, a video camera, or any other compatible audio/video device. X-Stream TV transmits the captured feed for display on a remote terminal. In order to reduce time lag, and distortion, while maintaining quality, X-Stream TV incorporates real-time encoding modules to manage the transmitted data size. Using streaming, multimedia servers allow clients the ability to play files before the downloading process is completed. The obvious benefit of this technology is that clients do not have to wait a long time for the complete file to download, but can instead start playback of audio/video data almost immediately. A developer or web designer can place specially formatted links within their website that reference network or internet locations that serve streaming multimedia content. When a client clicks on such a link, the multimedia server streams the content directly to the viewer’s PC, possibly via an embedded player on the website, or an external media player application. Not only does the viewer think that the website is streaming the content, the web server does not suffer network degradation, since the multimedia content is streamed to the client directly from a high-bandwidth dedicated server. This allows the integration of textual and graphical data on websites with high-quality, streaming audio/video content. X-Stream TV is an ideal application for a multimedia streaming server, since it allows its users to capture audio/video content from a variety of sources, encode it on the fly using any number of different compression levels, and stream it using the optimal network configuration to remote clients, particularly via an Ethernet LAN or potentially the World Wide Web. 1.1 Benefits Since X-Stream TV does not have a particular category of user in mind, it holds potential for both professionals and casual users, and further for leisure as well as work. Users can benefit from the venues for distribution that X-Stream TV provides, since (depending on network performance) a large number of users can log on to a shared server from various remote clients. Leisure-seekers separated geographically can all enjoy the same TV channel or televised performance, while executives can attend seminars virtually or presentations, or use videoconferencing. Various media are used in Internet, not only for the obvious purpose of entertainment applications, but for other applications such as video conferencing, video archives and libraries, remote learning, multimedia presentations, video surveillance, and of course, video on demand. X-Stream TV 1
  • 13. 1.2 Objectives The main targets X-Stream TV shall achieve are: Frame resolution : Minimum 160 x 120 pixels Refresh rate : Minimum 4 fps Network requirements : Ethernet LAN or Internet Hardware requirements : 1 GHz processor, 256 MB RAM X-Stream TV is an independent product, and completely self-contained. At this time, it is not planned as part of any larger product. X-Stream TV references the Windows Media Encoder SDK library in order to encode the captured feed using an industry standard audio/video compression format, before broadcasting this data over the network. However, the Windows Media Encoder library helps encode the data according to specification provided by the product; X-Stream TV handles the capture, and eventual broadcast of the stream. X-Stream TV 2
  • 14. Chapter 2 Requirements and Analysis 2.1 Product Perspective 2.1.1 User interfaces The X-Stream TV user interface will incorporate user friendliness, and a low learning curve. The immediate objective is to provide an interface appealing to both professional and casual users, and provides a high level of functionality regardless of prior computer experience and skill. X-Stream TV will only require initial user input to determine the following runtime configuration: • Audio source: Where X-Stream TV should capture audio feed • Video source: Where X-Stream TV should capture video feed • Connection type: How does the user connect to the network • Port: What port the server will be listening at • Streaming Filename: What file to be streamed, if any • Save to Filename: What file to save to while streaming, if any The server-side interface will allow the above settings to be modified. The client-side interface will be a web browser. The web browser on the client side will be able to access a web page on the streaming server via HTTP. Multimedia will be embedded in this webpage and the server will stream directly to the web browser in this manner. Considering the above requirements, users can utilize X-Stream TV with a high measure of success regardless of their skill or prior computer experience. A user will not have to alter the configuration for best results repeatedly, since only initial input from the user is necessary. On the client side, no special knowledge is required, as anyone with sufficient experience with Windows Media Player and any web browser will be able to use the system. 2.1.2 Hardware interfaces Due to its nature and requirements, X-Stream TV interfaces with a number of hardware components, which are as follows: • TV Tuner: Provides the live video feed • Sound Card: Provides the live audio feed • Data store: e.g. hard drive, main memory. Temporarily stores intermediate data • Network interface: e.g. LAN card or modem. Used to stream over the network. 2.1.3 Software interfaces X-Stream TV interacts with Windows Media Encoder SDK library in order to encode the captured audio/video data prior to broadcasting it over the network. The nature of this X-Stream TV 3
  • 15. software interface is object-based. X-Stream TV references the appropriate libraries and components. When needed, it creates a reference of the encoder, and sets the appropriate configuration according to the parameters and settings, etc. X-Stream TV sends the referenced encoder the audio/video data. The encoder returns the compressed/encoded data and X-Stream TV streams this over the network.| At this time, X-Stream TV is being designed to work in conjunction with Windows Media Encoder (9 series), which is freely available for download from Microsoft at: http://www.microsoft.com/windows/windowsmedia/9series/encoder/default.aspx X-Stream TV is designed primarily for the Microsoft Windows operating system. It is designed specifically for use with Windows 2000 and XP (recommended). X-Stream TV is implemented in C# using the Microsoft Visual Studio .NET development environment. 2.1.4 Communications Interfaces The application broadcasts the encoded audio/video stream using the Real Time Streaming Protocol (RTSP) over a TCP/IP network. X-Stream TV generates RTSP packets on the fly, comprising of the MAC header, IP header, TCP header, and the encoded data. 2.1.5 Memory constraints X-Stream TV requires a large amount of high-speed memory for simultaneous encoding and streaming multimedia. The frames captured from the TV Tuner, and the clips captured from the sound card need to be integrated before being sent to the encoder for compression. Furthermore, the compressed data returned by the encoder also needs to be stored temporarily prior to streaming it over the network. No doubt, the referenced encoder has its own memory requirements for ideal performance. 2.1.6 Operations Various modes of operations are supported involving different amounts of compression over different frame rates. To maintain the jitter free quality of the stream the user can select the connection type. X-Stream TV sets the encoding standards according to the user-selected connection type. 2.1.7 Site adaptation requirements X-Stream TV will only require initial user input to determine the following runtime configuration: • Audio source: Where X-Stream TV should capture audio feed • Video source: Where X-Stream TV should capture video feed • Connection type: How does the user connect to the network X-Stream TV 4
  • 16. • Port: What port the server will be listening at • Streaming Filename: What file to be streamed, if any • Save to Filename: What file to save to while streaming, if any Aside from these initial settings, X-Stream TV does not require any other form of site adaptation. In addition, X-Stream TV is self-adapting, i.e. it dynamically reconfigures itself to suit the available network resources. 2.2 Product Functions This section describes the basic functions that X-Stream TV will provide. Further details are provided in Chapter 3. 1. Capture audio/video feed from TV Tuner and Sound Card. 2. Reference and configure Windows Media Encoder SDK library. 3. Generate and broadcast stream. 4. Tabulate network statistics. 2.3 User Characteristics X-Stream TV is designed to enable computer users to get results in a quick, efficient, and hassle-free manner. As such, there is little requirement for user skill or expertise. It is assumed that the user is familiar with the Microsoft Windows OS, and has a modicum of experience using computers. Moreover, the user is expected to specify the appropriate hardware devices that X-Stream TV will interface with (i.e. TV tuner, sound card), and specify the type of connection the computer has to the network. The user also has the option to stream from a file by just specifying the filename and directory location during the initial configuration. Beyond this, X-Stream TV does not require the user to have any prior knowledge of network technologies and protocols, multimedia compression, audio/video codecs, etc. 2.4 Constraints The following factors are constraints on the development of X-Stream TV that are outside the development team’s sphere of control: • Regulatory policies: Distribution of certain types of content without obtaining permission (and a license) is illegal, especially for profit. In order to protect itself from potential claims, the development team will have to bundle an End User License Agreement with the product that releases X-Stream TV and its developers from legal responsibilities. • Hardware limitations: Due to its use of real time capture and encoding, X-Stream TV requires a fast processor (recommended clock speed of 1 GHz or above), and vast X-Stream TV 5
  • 17. amounts of memory (recommended 256 MB of RAM or above). Simultaneous execution of other (background) processes further detriments the product’s performance. Moreover, limited bandwidth adversely affects the product’s ability to stream data without error and jitter. • Software limitations: Relies on referencing Windows Media Encoder SDK library and a working installation of this SDK and the application are necessary for the successful working of X-Stream TV. • Higher order language requirements: X-Stream TV is implemented in C# using with the Microsoft .NET framework. Currently, only Microsoft Windows OS supports the framework, so X-Stream TV is limited to operation on systems using Windows. • Reliability requirements: In order to be of any practical appliance, X-Stream TV must provide at least a minimum level of quality, i.e. a video resolution of 160 x 120 pixels at 4 fps. 2.5 Assumptions and Dependencies X-Stream TV runs on any system using the Microsoft Windows operating system. While it is designed specifically for use with Windows 2000 / XP, it should also run on earlier versions of the OS as well. X-Stream TV requires a working installation of Windows Media Encoder to operate. At this time, it is designed specifically for use with Windows Media Encoder (9 series), but may work with earlier and future versions of this product. Since X-Stream TV is implemented in C# using the Microsoft .NET framework, it is currently dependant on the Microsoft Windows OS. 2.6 Specific Requirements 2.6.1 External interface requirements a) User interfaces The X-Stream TV user interface will incorporate user friendliness, and a low learning curve. The immediate objective is to provide an interface appealing to both professional and casual users, and provides a high level of functionality regardless of prior computer experience and skill. X-Stream TV will only require initial user input to determine the following runtime configuration: • Audio source: Where X-Stream TV should capture audio feed • Video source: Where X-Stream TV should capture video feed • Connection type: How does the user connect to the network X-Stream TV 6
  • 18. • Port: What port the server will be listening at • Streaming Filename: What file to be streamed, if any • Save to Filename: What file to save to while streaming, if any The server-side interface will allow the above settings to be modified. The client-side interface will be a web browser. The web browser on the client side will be able to access a web page on the streaming server via HTTP. Multimedia will be embedded in this webpage and the server will stream directly to the web browser in this manner. Considering the above requirements, users can use X-Stream TV with a high measure of success regardless of their skill or prior computer experience. A user will not have to alter the configuration for best results repeatedly, since only initial input from the user is necessary. b) Hardware interfaces Due to its nature and requirements, X-Stream TV interfaces with a number of hardware components, which are as follows: • TV Tuner: Provides the live video feed • Sound Card: Provides the live audio feed • Data store: e.g. hard drive. Temporarily stores intermediate data • Network interface: e.g. LAN card or modem. Used to stream over the network. c) Software interfaces X-Stream TV interacts with Windows Media Encoder SDK reference library in order to encode the captured audio/video data prior to broadcasting it over the network. X-Stream TV references the appropriate libraries and components. When needed, it creates a reference of the encoder, and sets the appropriate configuration parameters and settings, etc. X-Stream TV sends the encoder reference the audio/video data. The encoder returns the compressed/encoded data and X-Stream TV streams this over the network. At this time, X-Stream TV is being designed to work in conjunction with Windows Media Encoder (9 series), which is freely available for download from Microsoft at: http://www.microsoft.com/windows/windowsmedia/9series/encoder/default.aspx X-Stream TV is designed primarily for the Microsoft Windows operating system. It is designed specifically for use with Windows 2000 and XP (recommended). X-Stream TV is implemented in C# using the Microsoft Visual Studio .NET development environment. X-Stream TV 7
  • 19. d) Communications interfaces The application broadcasts the encoded audio/video stream using the Real Time Streaming Protocol (RTSP) over a TCP/IP network. X-Stream TV generates RTSP packets on the fly, comprising of the MAC header, IP header, TCP header, and the encoded data. X-Stream TV uses a C# reference library provided by the Windows Media SDK to stream its encoded content to remote clients. Under normal circumstances, two media protocols are available to X-Stream TV using this library. They are: • Real Time Streaming Protocol (RTSP) • Microsoft Media Server (MMS) protocol Both these protocols provide controls to the user to manipulate the multimedia stream, featuring common operations such as pause, rewind, fast-forward, and stop. MMS is a proprietary application layer protocol that provides backward compatibility for older versions of Windows Media, e.g. the Windows Media Player available on Windows 98/2000/XP. The RTSP protocol allows these operations by employing the following two TCP/IP standards: • Real Time Control Protocol (RTCP) that delivers control messages, e.g. negative ACKS, and requests, e.g. resend, when using RTSP over UDP. • Real Time Protocol (RTP) that delivers data packets when using RTSP over TCP. As a last resort, if neither RTSP nor MMS, then X-Stream TV uses standard and universal HyperText Transfer Protocol (HTTP). X-Stream TV manages this use of multiple protocols using the “protocol rollover” effect. Protocol Rollover refers to X-Stream TV’s ability to stream content to remote clients using the protocol that is most suited to their software’s compatibility, firewall issues, and network performance. The preferred protocol is RTSP, or MMS for clients using older versions of Windows Media Player. Initially, the server attempts transport using RTSP over TCP or UDP, or MMS over TCP or UDP. If the server is unable to stream content at an optimal level, then it switches from RTSP or MMS to HTTP transports. The rollover effect can be curtailed by remote clients by blocking the use of certain protocols in their Media Player. A client may block the MMS protocol and force X-Stream TV to stream using HTTP, or vice versa, in this manner. For more information on RTSP, see Appendix B. X-Stream TV 8
  • 20. Chapter 3 Design The decomposition description records the division of the software system into design modules. It describes the way the system has been structured and the purpose and function of each module. For each module, a preliminary description is provided. The decomposition description can be used to identify the major design modules of the software system for purposes such as determining which module is responsible for performing specific functions and tracing requirements to modules. The modules are grouped into major classes show the design hierarchy, and to assist in reviewing the decomposition for completeness. Further, the decomposition description allows identification of each software component, its purpose, and basic functionality. This design information together with other project information can be used in estimating cost, staff, and schedule for the development effort. 3.1 Module decomposition 3.1.1 Module 1.0 – Get Feed This module is responsible for setting up the streaming server. It will initiate the server by interfacing the system with the hardware (TV Tuner, Sound Card) and obtaining the required audio/video (frames) streams. The obtained streams are passed onto the Encode Feed Module (2.0). Module 1.0 is subdivided into the three modules that provide the required functionality. a) Module 1.1 Initiate Session This module will take appropriate input from the user to setup the server so that it is up and running, i.e. streaming the live feed over a network. b) Module 1.2 Interface with TV Tuner + Sound Card This module interfaces the system with the TV Tuner and Sound Card, and configures it according to the application’s requirements so that audio/video streams can be extracted from them. c) Module 1.3 Get Audio/Video Stream This module extracts the audio/video stream from the TV Tuner and Sound Card. X-Stream TV 9
  • 21. 3.1.2 Module 2.0 – Encode Stream The functionality of this Module is to transform the raw feed obtained from Get Feed Module, into an encoded form according to the Windows Media Format. The module references compatible components and libraries available in the Windows Media Encoder SDK. After configuring the reference according to the user’s specifications, the encoder compresses the raw feed into a Windows Media Format stream. This extremely powerful library also enables users to create multimedia productions from devices attached to their computers, translate audio and video files into Windows Media Format, and save the Windows Media-based content to a local file, broadcast it to the Internet, or push it to a Windows Media server. However, at this stage, X-Stream TV relies on the Windows Media Encoder reference library for the compression of the audio/video stream. To achieve this functionality this module is divided into three parts: a) Module 2.1 Get Stream This sub-module receives the Audio/Video Stream from the Get Feed module, and passes it on to the Encode Stream sub-module. On the successful instantiation of this object a success flag is passed on to the next sub-module. b) Module 2.2 Configure Encoder After the successful instantiation of the previous sub-module, the Configure Encoder sub- module analyzes the initially provided user configuration to determine the precise configuration of the encoder reference. This correct reference is passed on to the Encode Stream sub-module. c) Module 2.3 Encode Stream The purpose of this sub-module is to encode the audio/video data obtained from the user- defined hardware or multimedia file. The Windows Media Format codec is used, since this is universally compliant with the Windows Media Player (used at the client-end), and the compression rate varies according to the configuration of the encoder reference. The output of this sub-module is the encoded data which is passed on to Module 3.0, Network Output. If the user has opted to save the stream in a multimedia Windows Media Format file, then the encoded data is simultaneously written to file on the server’s hard drive. 3.1.3 Module 3.0 – Network Output After the Encoded data has been buffered the next step is to make this available for the users on the network. This is the functionality of this module. It interfaces the system with the Network Interface Card, generates Real Time Streaming Protocol (RTSP) packets and outputs them to the network. To achieve this, the Network Output Module is divided into three sub-modules: X-Stream TV 10
  • 22. a) Module 3.1 Interface with Network Card This module interfaces the system with the selected network card so that the encoded audio/video streams can be output to the network. On successful interfacing a success flag is passed onto the next sub-module. b) Module 3.2 Generate RTSP Packets This sub-module takes in the Encoded data as inputs and creates RTSP packets by attaching appropriate headers to segments of the Encoded data. These headers include the MAC, IP and TCP/UDP headers, besides other data. The packets that have been created are passed on to the next sub-module. c) Module 3.3 Output to Network The function of this sub-module is to output the RTSP packets, obtained from the sub- module Generate RTSP Packets, to the network. 3.1.4 Module 4.0 – Generate Feedback The purpose of this module is to measure network performance and determine the necessary measures to maintain Quality of Service. It performs this functionality by obtaining network statistics, and tabulating them for presentation to the user at the end of streaming activity. All these functions are achieved by the following sub-modules: a) Module 4.1 Get Statistics The purpose of this sub-module is to obtain statistics such as Current and Expected Bit Rate, number of clients, etc. These statistics are passed onto the next sub-module. b) Module 4.2 Tabulate Results This module tabulates the statistics collected in the previous sub-module at regular intervals during the streaming process in a user-friendly and easily interpreted format. This formatted table is passed on to the next module for display to the user. c) Module 4.3 Generate Feedback This module will generate a feedback for the system based on the pre-formatted table that it receives from the Module Tabulate Results. The purpose of this feedback is to present a complete record of the system’s performance to the user. X-Stream TV 11
  • 23. Chapter 4 Choosing the Appropriate SDK To provide the multimedia compression functionality for the X-Stream TV server, we had to interface using a third-party reference library for C#. In the interests of providing compatibility to our immediate projected clientele, i.e. users at LUMS, and throughout Pakistan, we wanted a compression engine that would use audio and video codec compatible with the popular Microsoft Windows systems and applications. For this reason, X-Stream TV interfaces with a library provided by Microsoft for application developers. As described elsewhere in this document, this reference library is mainly for the encoding process wherein X-Stream TV compresses the audio and video feed received from the source into a stream-able format compatible with Windows Media Player at the client end. Microsoft currently provides two major SDKs for application developers, DirectShow and the Windows Media SDK. Either option provides a number of advantages, as well as drawbacks. It was imperative that we select the right SDK for use in X-Stream TV to ensure problem-free performance at the server, and universal compatibility at the remote client. DirectShow provides high-level access to multimedia manipulation and streaming using plug-ins and filters, including those other vendors. DirectShow offers a variety of extremely powerful video-editing tools, which provide the ability to create and edit Windows Media Format files, preview and stream audio/video in real-time, conversion of frame rates and sampling rates, and resizing/cropping of frames, etc. While DirectShow uses less processor resources, it has a tendency to create extremely large files unless using an extremely effective encoding filter/plug-in. On the other hand, the Windows Media SDK is available to developers hoping to integrate support for and manipulation of the Windows Media Format in their applications. It allows the reading, writing, and editing of Windows Media Format files, particularly the packaging of other multimedia formats into Microsoft’s ASF container for streaming to Windows Media clients. Windows Media SDK provides low-level access to the media stream, and benefits developers by generating small files for streaming and distribution over the internet or LAN. Initially, X-Stream TV was built around the DirectShow library, but in light of the above- mentioned information, it was extensively modified to interface with the Windows Media SDK reference library for its final version, since it offers greater compatibility for the Windows Media Format, uses compression technologies that are available by default with the Windows Media Player, and produces smaller files that are ideal for streaming over a network environment. For further information about Microsoft DirectShow, the Windows Media SDK, and the Windows Media Format, please refer to Appendix A. X-Stream TV 12
  • 24. Chapter 5 Quality Assurance 5.1 Objectives A system test plan for X-Stream TV should support the following objectives: 1. To detail the activities required to prepare for and conduct the system test. 2. To communicate to all responsible parties the tasks that they are to perform and the schedule to be followed in performing the tasks. 3. To define the sources of the information used to prepare the plan. 4. To define the test tools and environment needed to conduct the system test. 5.2 Background Due to the unavailability of any software in the local market that allows the streaming of multimedia information from an external television source (e.g. TV antenna, cable, cassette/ VCD/DVD players, etc.) over a TCP/IP network, we decided to develop a system that would achieve this goal. Our product allows the end user to receive TV input (using a TV Tuner and a soundcard) and broadcast it to a network client(s). It does not include client software (e.g. multimedia players, etc.), but provides a multimedia stream that is compatible with Windows Media Player. It constitutes a real-time compression engine that compresses the audiovisual information to a variable bit rate that can be broadcast over a TCP/IP network without significant loss in quality. Potential applications for such software include the following: • broadcasting TV channels from a single cable connection to multiple network clients • broadcasting live or pre-recorded video feeds (such as presentations, lectures or documentaries) on an office or campus network • individual users can access their personal cable connection or video collection via a network 5.3 Scope This test plan covers a full systems test of the X-Stream TV Streaming Server. This includes comprehensively testing the streaming server and its features, as well as the client-side interface. In addition to features, the performance of the server will also be evaluated. 5.4 References Software Requirements Specifications (SRS) Software Design Document (SDD) X-Stream TV 13
  • 25. 5.5 Test items 5.5.1 Program modules Table 1: Program Modules Program Module Filename Description XST01-01 Form1.cs Splash screen XST01-02 Form2.cs Configuration screen; allows server operator to set parameters for the server configuration and to set up a connection for streaming multimedia from a source XST01-03 Form3.cs Streams multimedia to clients while also displaying a preview of the video being streamed XST01-04 Form4.cs Displays session statistics XST01-05 stat.cs Class to hold statistics XST01-06 session.cs Class that contains statistics collected during any one session 5.5.2 Job control procedures N/A 5.5.3 User procedures The user procedures to be tested include the following: Table 2: User Procedures User Procedures Description XST02-01 Accessing the X-Stream TV webpage from a client on the LAN XST02-02 Viewing the audio/video stream through the Windows Media Player by clicking the link on the X-Stream TV webpage 5.5.4 Operator procedures Table 3: Operator Procedures Operator Procedure Description XST03-01 Selecting desired input source (hardware or file) XST03-02 Selecting desired output (configuring port, connection and/or file to record to) XST03-03 Stop/resume stream XST03-04 Viewing streaming statistics X-Stream TV 14
  • 26. 5.6 Features to be tested Table 4: Features to be tested Test Design Description Specification Number XST04-01 Live streaming using various sources XST04-02 Recording a file XST04-03 Performance testing 5.7 Features not to be tested The following features will not be included in the system tests because they cannot be tested at this moment despite being supported by the application: • S-Video due to unavailability of compliant hardware • Unable to test the Video Tuner input due to unavailability of a TV antenna connection • No testing in a real-world environment due to unavailability of a dial-up or cable connection • No testing from an external network due to unavailability of an external IP address 5.8 Approach The test personnel will use the system documentation to prepare all test design, case, and procedure specifications. This approach will verify the accuracy and comprehensiveness of the information in the documentation in those areas covered by the tests. 5.8.1 Live streaming In order to test live streaming, we will demonstrate X-Stream TV with the following inputs: any multimedia device plugged into the TV Tuner card’s Video Composite input, e.g. digital camera, VCD player, etc. After connecting the source to the hardware, we will demonstrate streaming on client computers. 1. The X-Stream TV Streaming Server will be installed on a server computer on a LAN. 2. The client interface is a webpage which has been designed and set up on the server computer. 3. The HTTP server software being used is the native Windows XP server, i.e. Microsoft Internet Information Server. 4. Client computers on the same LAN will be able to access the X-Stream TV webpage. 5. Any multimedia source is connected to the server’s TV Tuner Video Composite. 6. The server is used to stream live multimedia from a connected multimedia source to the client computers, which access it through the Windows Media Player installed on them, using the mms:// URL presented on the X-Stream TV webpage. X-Stream TV 15
  • 27. 5.8.2 File streaming In order to test file streaming, the input is any pre-existing multimedia file on the server. The remainder of the approach is virtually the same as that above. 1. The X-Stream TV Streaming Server will be installed on a server computer on a LAN. 2. The client interface is a webpage which has been designed and set up on the server computer. 3. The HTTP server software being used is the native Windows XP server, i.e. Microsoft Internet Information Server. 4. Client computers on the same LAN will be able to access the X-Stream TV webpage. 5. The server is used to stream multimedia from a saved pre-existing multimedia file on the server to the client computers, which access it through the Windows Media Player installed on them, using the mms:// URL presented on the X-Stream TV webpage. 5.8.3 File recording In order to test file recording, the following approach is to be taken: 1. The X-Stream TV Streaming Server will be installed on a server computer on a LAN. 2. Any multimedia source is connected to the server’s TV Tuner Video Composite. 3. The server software will receive input from the multimedia source, and while broadcasting the stream to clients, will simultaneously save it to the hard disk on the server computer in the Windows Media Video format. 4. The saved file may thus later be streamed to clients. 5.8.4 Interface testing In order to test the interface between the X-Stream TV Server and the clients, a webpage has been designed and placed on the server computer. The webpage will be accessed by the client computers, and it contains a pre-formatted URL that will launch Windows Media Player and play the streamed video. 5.8.5 Performance testing Performance will be evaluated against the following performance requirements (previously specified in the SRS): 1. Bandwidth: supports a bandwidth from 28.8 Kbps to 768 Kbps 2. Frame rate: minimum 4 fps, maximum as defined by the user’s TV Tuner card 3. Resolution: minimum 160 x120, maximum 320 x 240 4. Number of clients: 1 – 50 5.8.6 Comprehensiveness Each of the system features described in the Software Requirements Specification (SRS) will be tested. Briefly restated, these functions are as follows: 1. Capturing audio/video feed from a TV Tuner and Sound Card. 2. Configure the Windows Media Encoder. 3. Send audio/video data to the Encoder. X-Stream TV 16
  • 28. 4. Receive the encoded data. 5. Generate and broadcast the multimedia stream. 6. Generate network feedback statistics. Each of the user procedures described earlier in this document will be tested at least once. Each of the operating procedures specified earlier in this document will be tested at least once. 5.9 Item pass/fail criteria The system must satisfy the following requirements for system pass/fail: Table 5: Item pass/fail criteria Module/ Pass/Fail Criteria Procedure XST01-01 Splash screen correctly displayed XST01-02 Correctly displays available audio sources, available TV Tuner inputs, and allows selection of a pre-existing file to stream; correctly allows port selection, displays available connection types and allows selection of an output file to save to while streaming XST01-03 Based on the options selected by the user, correctly selects and configures the input sources, receives the input, creates a broadcast, encodes the video and streams it from the hardware to clients; also displays a preview and measures and displays performance-related statistics XST01-04 Correctly displays session statistics XST01-05 Correctly stores statistics; will be tested on modules XST01-03 and XST01-04 XST01-06 Correctly stores statistics collected every five seconds, i.e. statistics collected for a particular session XST02-01 X-Stream TV webpage is correctly accessed through a browser on the user’s client XST02-02 Multimedia streams efficiently and easily, allowing the user to view multimedia through the Windows Media Player XST03-01 Input source is correctly configured and interfaced with the server software XST03-02 Output port is correctly configured, connection is correctly set up, and/or the output stream to a file is correctly set up XST03-03 The multimedia stream is started or resumed as desired XST03-04 Streaming statistics are correctly displayed and updated at all times; session statistics are displayed each time the multimedia stream is paused/ stopped XST04-01 Multimedia is streamed correctly with input provided by any source such as a VCD player or a digital camera XST04-02 The multimedia stream is correctly saved to a file on the hard disk X-Stream TV 17
  • 29. XST04-03 The performance requirements as stated earlier in this document are met The system must also satisfy the following requirement: • User procedures must be consistent with the software being used on the client-side, i.e. Windows Media Player. 5.10 Suspension criteria and resumption requirements 5.10.1 Suspension criteria The inability of the server to correctly set up a connection and/or a much greater lag than expected (we have defined the upper limit to be 15 seconds) will cause suspension of all testing activities. 5.10.2 Resumption requirements For each new version of the system, any unexpected impact resulting from program modifications needs to be tested. Each test defined for each test item will be run on both the previous version of the system as well as the new version of the system, and then the results will be compared. 5.11 Test deliverables The following documents will be generated and will be delivered after test completion: Test documentation: System Test Plan System Test Design Specifications System Test Case Specifications System Test Procedure Specifications System Test Incident Reports System Test Summary Report Test data: (1) Input files will be placed on the server so that they may be streamed to the client. (2) Other multimedia sources such as a good quality digital camera, VCD player, DVD player, etc. (3) Output files (generated when the input is saved to a file while streaming it) will be saved to the server. 5.12 Testing tasks See Task List, Attachment A. X-Stream TV 18
  • 30. 5.13 Environmental needs 5.13.1 Hardware The testing will be done using the following hardware configuration for the server computer: • Intel Pentium 4 HT CPU 2.8 GHz • 512 MB of RAM • 80 GB hard disk • PixelView TV Tuner card The client hardware is identical, except it does not have the TV Tuner card. 5.13.2 Software a) Operating system The operating system used to execute these tests is Microsoft Windows XP Professional Version 2002, Service Pack 2. b) Communications software The web server software being used to allow clients access to the X-Stream TV webpage is Microsoft Internet Information Server. On the client side, the native Windows Media Player will be used to access streams being provided by the server. 5.13.3 Security User authentication is not being handled; access is open to all clients that can access the network on which the server is running. Authentication is handled by the underlying network itself. 5.13.4 Tools No external test tools are being used. One of the features of the X-Stream TV server is to generate statistics on the fly regarding the performance quality of the server. 5.13.5 Publications The following documents are required to support systems testing: • Software Requirements Specification (SRS) • Software Design Document (SDD) • Task List, Attachment A 5.14 Responsibilities The following groups have responsibility for segments of the testing. X-Stream TV 19
  • 31. 5.14.1 System test group Group 0513 will be carrying out all testing procedures. 5.14.2 Project advisors The group’s senior project advisors will provide assistance to the group in the following activities: • Reviewing the test design specifications • Executing the online tests • Checking output screens and reports 5.15 Staffing and Training Needs There are no special staffing or training needs as the X-Stream TV Streaming Server runs on any Windows XP machine and interfaces with clients running Windows XP and running the native Windows Media Player. Any user who is comfortable using Windows XP and Internet Explorer will have no trouble using the server. 5.16 Schedule See Task List, Attachment A. 5.17 Risks and contingencies If the testing schedule is significantly impacted by system failure, the group will abandon all testing to perform extensive debugging. If hardware problems impact system availability, the group will schedule their activities using other computers provided by the ITSS. The first production runs of the X-Stream TV Streaming Server must be checked out in detail before the final demonstration, and any checks in error must be corrected manually. X-Stream TV 20
  • 32. Attachment A: Task List Table 6: Task List Task Predecessor tasks Special skills Effort Finish date (1) Prepare test plan. Complete project Windows 4 23/04/05 requirements analysis (SRS), Media design document (SDD), and Encoder, implementation code. C#, .NET framework (2) Prepare test Task 1 – 3 24/04/05 design specifications. (3) Prepare test case Complete corresponding test – 3 24/04/05 specifications. designs (Task 2) (4) Prepare test Complete corresponding test – 3 24/04/05 procedure cases (Task 3) specifications. (5) Collect Task 4 – 1 24/04/05 multimedia inputs for test cases. (6) Execute test Task 5 Knowledge of 4 24/04/05 procedures for each IIS test item. (7) Record and Task 6 – 4 24/04/05 resolve test incident reports. (8) Repeat tasks (6)- Task 6, Task 7 – 1 24/04/05 (7) until all test procedures have succeeded. (9) Write the system Task 8 – 2 25/04/05 test summary report. (10) Present all test Task 9 – 1 02/05/05 documentation and test data to the project advisors. X-Stream TV 21
  • 33. 5.18. Test design specifications 5.18.1 XD1: Live streaming from external source Features to be tested The features to be tested are: 1. Capturing audio/video feed from the TV Tuner and Sound Card. 2. Configure the Windows Media Encoder. 3. Send audio/video data to the Encoder. 4. Receive the encoded data. 5. Generate and broadcast the multimedia stream. 6. Generate network feedback statistics. Approach refinements In order to test live streaming, we will demonstrate X-Stream TV with the following inputs: any multimedia device plugged into the TV Tuner card, e.g. live digital camera, VCD player, etc. After connecting the source to the hardware, we will demonstrate streaming on client computers. 1. The X-Stream TV Streaming Server will be installed on a server computer on a LAN. 2. The client interface is a webpage which has been designed and set up on the server computer. 3. The HTTP server software being used is the native Windows XP server, i.e. Microsoft Internet Information Server. 4. Client computers on the same LAN will be able to access the X-Stream TV webpage. 5. Any multimedia source is connected to the server via TV Tuner Video Composite. 6. The server is used to stream live multimedia from a connected multimedia source to the client computers, which access it through the Windows Media Player installed on them, using the mms:// URL presented on the X-Stream TV webpage. In addition to the above, we are using the following method: 1. Stream to one client for one minute. 2. Record the actual frame rate and the bandwidth in use. 3. After one minute, access the stream from another client simultaneously. 4. Record the new actual frame rate and the bandwidth in use. 5. Every five seconds, the program generates the current bit rate and the expected bit rate. Stop the stream after two minutes, and observe the sessions statistics that are returned. 6. Plot a graph against time elapsed showing the fluctuation of the actual bit rate as opposed to the expected bit rate. Note that after one minute, another client has been added. Test identification The test cases to be used here are as follows: X-Stream TV 22
  • 34. • XC1: VCD player The external input source used will be a VCD player, and it will be used to play high- quality video that will subsequently be streamed. • XC2: Digital camera The external input source used will be a digital camera, and it will be used to capture and stream live video. Feature pass/fail criteria • XST01-02: Correctly displays available audio sources, available TV Tuner inputs, and allows selection of a pre-existing file to stream; correctly allows port selection, displays available connection types and allows selection of an output file to save to while streaming • XST01-03: Based on the options selected by the user, correctly selects and configures the input sources, receives the input, creates a broadcast, encodes the video and streams it from the hardware to clients; also displays a preview and measures and displays performance-related statistics 5.18.2 XD2. Streaming a pre-existing file on the server Features to be tested The features to be tested are: 1. Set up a pre-existing file on the server as an input source. 2. Configure the Windows Media Encoder. 3. Send audio/video data to the Encoder. 4. Receive the encoded data. 5. Generate and broadcast the multimedia stream. 6. Generate network feedback statistics. Approach refinements In order to test file streaming, the input is any pre-existing multimedia file on the server. The remainder of the approach is virtually the same as that above. 1. The X-Stream TV Streaming Server will be installed on a server computer on a LAN. 2. The client interface is a webpage which has been designed and set up on the server computer. 3. The HTTP server software being used is the native Windows XP server, i.e. Microsoft Internet Information Server. 4. Client computers on the same LAN will be able to access the X-Stream TV webpage. 5. The server is used to stream multimedia from a saved pre-existing multimedia file on the server to the client computers, which access it through the Windows Media Player installed on them, using the mms:// URL presented on the X-Stream TV webpage. In addition to the above, we are using the following method: X-Stream TV 23
  • 35. 1. Stream to one client for one minute. 2. Record the actual frame rate and the bandwidth in use. 3. After one minute, access the stream from another client simultaneously. 4. Record the new actual frame rate and the bandwidth in use. 5. Every five seconds, the program generates the current bit rate and the expected bit rate. Stop the stream after two minutes, and observe the sessions statistics that are returned. 6. Plot a graph against time elapsed showing the fluctuation of the actual bit rate as opposed to the expected bit rate. Note that after one minute, another client has been added. Test identification The test cases to be used here are as follows: 5.18.3 XC3: Pre-existing file A pre-existing file will be placed on the server and used as an input source for the server. Feature pass/fail criteria • XST01-02: Correctly displays available audio sources, available TV Tuner inputs, and allows selection of a pre-existing file to stream; correctly allows port selection, displays available connection types and allows selection of an output file to save to while streaming • XST01-03: Based on the options selected by the user, correctly selects and configures the input sources, receives the input, creates a broadcast, encodes the video and streams it from the hardware to clients; also displays a preview and measures and displays performance-related statistics X-Stream TV 24
  • 36. 5.19 Test case specifications 5.19.1 XC1. VCD player Test items The test items to be tested by this test case are, primarily: Table 7: VCD Player Test Items Program Module Filename Description XST01-02 Form2.cs Configuration screen; allows server operator to set parameters for the server configuration and to set up a connection for streaming multimedia from a source XST01-03 Form3.cs Streams multimedia to clients while also displaying a preview of the video being streamed XST01-04 Form4.cs Displays session statistics XST01-05 stat.cs Class to hold statistics XST01-06 session.cs Class that contains statistics collected during any one session Input specifications • The input for this test case will be a selected VCD that will be played through the VCD player and streamed to clients over the selected connection. • The audio source chosen here is SoundMAX. • The TV tuner input selected here is Video Composite. • Any connection type may be chosen. • The port chosen is 5110. Output specifications The output is a multimedia stream which may be received by any client that accesses the X- Stream TV webpage. Environmental needs The testing will be done using the following hardware configuration for the server computer: • Intel Pentium 4 HT CPU 2.8 GHz • 512 MB of RAM • 80 GB hard disk • PixelView TV Tuner card The client hardware is identical, except it does not have the TV Tuner card. X-Stream TV 25
  • 37. The operating system used to execute these tests is Microsoft Windows XP Professional Version 2002, Service Pack 2. The web server software being used to allow clients access to the X-Stream TV webpage is Microsoft Internet Information Server. On the client side, the native Windows Media Player will be used to access streams being provided by the server. 5.19.2 XC2. Digital camera Test items The test items to be tested by this test case are, primarily: Table 8: Digital Camera Test Items Program Module Filename Description XST01-02 Form2.cs Configuration screen; allows server operator to set parameters for the server configuration and to set up a connection for streaming multimedia from a source XST01-03 Form3.cs Streams multimedia to clients while also displaying a preview of the video being streamed XST01-04 Form4.cs Displays session statistics XST01-05 stat.cs Class to hold statistics XST01-06 session.cs Class that contains statistics collected during any one session Input specifications • The input for this test case will be a digital camera which will capture video that will be streamed live to clients. • The audio source chosen here is SoundMAX. • The TV tuner input selected here is Video Composite. • Any connection type may be chosen. • The port chosen is 5110. Output specifications The output is a multimedia stream which may be received by any client that accesses the X- Stream TV webpage. Environmental needs The testing will be done using the following hardware configuration for the server computer: • Intel Pentium 4 HT CPU 2.8 GHz • 512 MB of RAM • 80 GB hard disk • PixelView TV Tuner card The client hardware is identical, except it does not have the TV Tuner card. X-Stream TV 26
  • 38. The operating system used to execute these tests is Microsoft Windows XP Professional Version 2002, Service Pack 2. The web server software being used to allow clients access to the X-Stream TV webpage is Microsoft Internet Information Server. On the client side, the native Windows Media Player will be used to access streams being provided by the server. 5.19.3 XC3. Pre-existing file Test items The test items to be tested by this test case are, primarily: Table 9: Pre-existing File Test Items Program Module Filename Description XST01-02 Form2.cs Configuration screen; allows server operator to set parameters for the server configuration and to set up a connection for streaming multimedia from a source XST01-03 Form3.cs Streams multimedia to clients while also displaying a preview of the video being streamed XST01-04 Form4.cs Displays session statistics XST01-05 stat.cs Class to hold statistics XST01-06 session.cs Class that contains statistics collected during any one session Input specifications • The input for this test case will be a pre-existing file lying on the server. • The audio source chosen here is SoundMAX. • The TV tuner input selected here is Video Composite. • Any connection type may be chosen. • The port chosen is 5110. Output specifications The output is a multimedia stream which may be received by any client that accesses the X- Stream TV webpage. Environmental needs The testing will be done using the following hardware configuration for the server computer: • Intel Pentium 4 HT CPU 2.8 GHz • 512 MB of RAM • 80 GB hard disk • PixelView TV Tuner card The client hardware is identical, except it does not have the TV Tuner card. X-Stream TV 27
  • 39. The operating system used to execute these tests is Microsoft Windows XP Professional Version 2002, Service Pack 2. The web server software being used to allow clients access to the X-Stream TV webpage is Microsoft Internet Information Server. On the client side, the native Windows Media Player will be used to access streams being provided by the server. X-Stream TV 28
  • 40. 5.20 Test procedure specifications 5.20.1 XP1. Executing all test cases Purpose This test procedure is defined to explain how a complete system test will be run. Each of the tests designed in the earlier section will be run here. Special requirements Make sure that Microsoft Internet Information Server is installed and correctly configured on the server. Make sure that Windows Media Player is installed on all clients so that they can view the streaming media through their web browsers. Procedure steps 1. Set up: Connect an external source to the TV Tuner card. 2. Start: Select an audio source and the TV Tuner card input, or select a file to stream from. Choose a port to stream to and a connection type. 3. Proceed: Observe statistics during streaming; you can also stop and resume the stream from the server while streaming is ongoing. 4. Measure: Every five seconds, the software records the current bit rate and the expected bit rate. Session statistics are generated for each session between the start and stop. These will be observed, recorded and plotted on graphs. 5. Shut down: Stop the stream by clicking the Stop button and exit the program using the Exit button. 6. Restart: Repeat these steps for each of the test cases XC1, XC2 and XC3 as needed. X-Stream TV 29
  • 41. 5.21 Test incident reports 5.21.1 XI1. Incident report 1 Inputs Audio source: select appropriate source from the combo box Video source: select appropriate source from the combo box Connection type: Dial-up Modems or Single-channel ISDN (28.8 to 56 Kbps) Expected results Frame rate: 30 fps Bandwidth: 28.8 to 56 Kbps Actual results Number of clients: 1 Frame rate: 28 fps Bandwidth: 20-25 Kbps Number of clients: 2 Client 1 Frame rate: 25 fps Bandwidth: 20-25 Kbps Client 2 Frame rate: 20-25 fps Bandwidth: 20-25 Kbps Anomalies None Attempts to repeat The test was run twice to get an unbiased result. Testers Atif Shah Nehdia Sameen Usman Dawood Yasir Baghpati Observers Atif Shah Nehdia Sameen Usman Dawood Yasir Baghpati X-Stream TV 30
  • 42. 5.21.2 XI2. Incident report 2 Inputs Audio source: select appropriate source from the combo box Video source: select appropriate source from the combo box Connection type: LAN, Cable Modem, or xDSL (100 to 768 Kbps) Expected results Frame rate: 30 fps Bandwidth: 100 to 768 Kbps Actual results Number of clients: 1 Frame rate: 8 fps Bandwidth: 97 Kbps Number of clients: 2 Client 1 Frame rate: 8 fps Bandwidth: 97 Kbps Client 2 Frame rate: 7 fps Bandwidth: 96.5 Kbps Anomalies None Attempts to repeat The test was run twice to get an unbiased result. Testers Atif Shah Nehdia Sameen Usman Dawood Yasir Baghpati Observers Atif Shah Nehdia Sameen Usman Dawood Yasir Baghpati 5.21.3 XI3. Incident report 3 Inputs Audio source: select appropriate source from the combo box Video source: select appropriate source from the combo box X-Stream TV 31
  • 43. Connection type: Dial-up Modems or LAN (28.8 to 100 Kbps) Expected results Frame rate: 30 fps Bandwidth: 28.8 to 100 Kbps Actual results Number of clients: 1 Frame rate: 15 fps Bandwidth: 45-90 Kbps Number of clients: 2 Client 1 Frame rate: 15 fps Bandwidth: 70-90 Kbps Client 2 Frame rate: 14.7 fps Bandwidth: 70-100 Kbps Anomalies None Attempts to repeat The test was run twice to get an unbiased result. Testers Atif Shah Nehdia Sameen Usman Dawood Yasir Baghpati Observers Atif Shah Nehdia Sameen Usman Dawood Yasir Baghpati 5.21.4 XI4. Incident report 4 Inputs Audio source: select appropriate source from the combo box Video source: select appropriate source from the combo box Connection type: Dial-up Modems (28.8 Kbps) Expected results Frame rate: 30 fps Bandwidth: 28.8 Kbps X-Stream TV 32
  • 44. Actual results Number of clients: 1 Frame rate: 28 fps Bandwidth: 54 Kbps Number of clients: 2 Client 1 Frame rate: 28 fps Bandwidth: 56 Kbps Client 2 Frame rate: 24.5 fps Bandwidth: 55 Kbps Anomalies None Attempts to repeat The test was run twice to get an unbiased result. Testers Atif Shah Nehdia Sameen Usman Dawood Yasir Baghpati Observers Atif Shah Nehdia Sameen Usman Dawood Yasir Baghpati 5.21.5 XI5. Incident report 5 Inputs Audio source: select appropriate source from the combo box Video source: select appropriate source from the combo box Connection type: Dial-up Modems (56.6 Kbps) Expected results Frame rate: 30 fps Bandwidth: 56.6 Kbps Actual results Number of clients: 1 Frame rate: 25-29 fps Bandwidth: 35-40 Kbps X-Stream TV 33
  • 45. Number of clients: 2 Client 1 Frame rate: 17 fps Bandwidth: 15-35 Kbps Client 2 Frame rate: 25-29 fps Bandwidth: 32-35 Kbps Anomalies None Attempts to repeat The test was run twice to get an unbiased result. Testers Atif Shah Nehdia Sameen Usman Dawood Yasir Baghpati Observers Atif Shah Nehdia Sameen Usman Dawood Yasir Baghpati 5.21.6 XI6. Incident report 6 Inputs Audio source: select appropriate source from the combo box Video source: select appropriate source from the combo box Connection type: Local Area Network (100 kbps) Expected results Frame rate: 30 fps Bandwidth: 100 Kbps Actual results Number of clients: 1 Frame rate: 27-29 fps Bandwidth: 108-110 Kbps Number of clients: 2 Client 1 Frame rate: 28.9 fps Bandwidth: 36-110 Kbps Client 2 X-Stream TV 34
  • 46. Frame rate: 4-15 fps Bandwidth: 15-55 Kbps Anomalies None Attempts to repeat The test was run twice to get an unbiased result. Testers Atif Shah Nehdia Sameen Usman Dawood Yasir Baghpati Observers Atif Shah Nehdia Sameen Usman Dawood Yasir Baghpati 5.21.7 XI7. Incident report 7 Inputs Audio source: select appropriate source from the combo box Video source: select appropriate source from the combo box Connection type: Local Area Network (256 Kbps) Expected results Frame rate: 30 fps Bandwidth: 256Kbps Actual results Number of clients: 1 Frame rate: 24.9 fps Bandwidth: 241-245 Kbps Number of clients: 2 Client 1 Frame rate: 24.9 fps Bandwidth: 228-231 Kbps Client 2 Frame rate: 24.9 fps Bandwidth: 225-240 Kbps Anomalies X-Stream TV 35
  • 47. None Attempts to repeat The test was run twice to get an unbiased result. Testers Atif Shah Nehdia Sameen Usman Dawood Yasir Baghpati Observers Atif Shah Nehdia Sameen Usman Dawood Yasir Baghpati 5.21.8 XI8. Incident report 8 Inputs Audio source: select appropriate source from the combo box Video source: select appropriate source from the combo box Connection type: Local Area Network (384 Kbps) Expected results Frame rate: 30 fps Bandwidth: 384 Kbps Actual results Number of clients: 1 Frame rate: 24.9 fps Bandwidth: 372-374 Kbps Number of clients: 2 Client 1 Frame rate: 24.9 fps Bandwidth: 350-370 Kbps Client 2 Frame rate: 24.9 fps Bandwidth: 350-370 Kbps Anomalies None Attempts to repeat The test was run twice to get an unbiased result. X-Stream TV 36
  • 48. Testers Atif Shah Nehdia Sameen Usman Dawood Yasir Baghpati Observers Atif Shah Nehdia Sameen Usman Dawood Yasir Baghpati 5.21.9 XI9. Incident report 9 Inputs Audio source: select appropriate source from the combo box Video source: select appropriate source from the combo box Connection type: Local Area Network (768 Kbps) Expected results Frame rate: 30 fps Bandwidth: 768 Kbps Actual results Number of clients: 1 Frame rate: 20-23 fps Bandwidth: 460 Kbps Number of clients: 2 Client 1 Frame rate: 24 fps Bandwidth: 440-463 Kbps Client 2 Frame rate: 24.7 fps Bandwidth: 445-465 Kbps Anomalies None Attempts to repeat The test was run twice to get an unbiased result. Testers Atif Shah Nehdia Sameen Usman Dawood X-Stream TV 37
  • 49. Yasir Baghpati Observers Atif Shah Nehdia Sameen Usman Dawood Yasir Baghpati 5.21.10 XI10. Incident report 10 Inputs Audio source: select appropriate source from the combo box Video source: select appropriate source from the combo box Save to file checkbox checked Connection type: Dial-up Modems (28.8 Kbps) Expected results Frame rate: 30 fps Bandwidth: 28.8 Kbps Actual results Number of clients: 1 Frame rate: 14-20 fps Bandwidth: 20-23 Kbps Number of clients: 2 Client 1 Frame rate: 29 fps Bandwidth: 54 Kbps Client 2 Frame rate: 28 fps Bandwidth: 20-22Kbps Anomalies None Attempts to repeat The test was run twice to get an unbiased result. Testers Atif Shah Nehdia Sameen Usman Dawood Yasir Baghpati Observers Atif Shah X-Stream TV 38
  • 50. Nehdia Sameen Usman Dawood Yasir Baghpati 5.21.11 X11. Incident report 11 Inputs Audio source: select appropriate source from the combo box Video source: select appropriate source from the combo box Save to file checkbox checked Connection type: Local Area Network (768 Kbps) Expected results Frame rate: 30 fps Bandwidth: 768 Kbps Actual results Number of clients: 1 Frame rate: 15-20 fps Bandwidth: 460 Kbps Number of clients: 2 Client 1 Frame rate: 21-23 fps Bandwidth: 460-465 Kbps Client 2 Frame rate: 24.9 fps Bandwidth: 290-400 Kbps Anomalies None Attempts to repeat The test was run twice to get an unbiased result. Testers Atif Shah Nehdia Sameen Usman Dawood Yasir Baghpati Observers Atif Shah Nehdia Sameen Usman Dawood Yasir Baghpati X-Stream TV 39
  • 51. 5.22 Test summary report 5.22.1 XS1. Overall summary report Summary After completing the system test, we have concluded that the X-Stream TV streaming server is working properly as far as all major functionality is concerned. The test items were the following: 1. General system features • Live streaming • Recording a file • Performance 2. Modules • Splash screen (Form1.cs) • Server configuration (Form2.cs) • Streaming video with preview (Form3.cs) • Session statistics (Form4.cs) • Statistics class (stats.cs) • Session statistics collection (session.cs) 3. User procedures • Accessing the X-Stream TV webpage • Watching streaming video through Windows Media Player 4. Operator procedures • Selecting an input source • Selecting an output port, connection, and/or file to record to • Start/stop streaming as needed Variances No major changes were made to any test item vis-à-vis the design specifications. Superficial changes were made including more specialized error-checking (as regards exception handling) and interface improvement and design. Comprehensive assessment Each of the modules, system features, user procedures and operator procedures defined earlier were tested thoroughly. X-Stream TV 40
  • 52. Table 10: Test Item Assessment Test item Name Assessment XST01-01 Form1.cs Splash screen was correctly displayed XST01-02 Form2.cs Correctly displayed available audio sources, available TV Tuner inputs, and allowed selection of a pre-existing file to stream; correctly allowed port selection, displayed available connection types and allowed selection of an output file to save to while streaming XST01-03 Form3.cs Based on the options selected by the user, correctly selected and configured the input sources, received the input, created a broadcast, encoded the video and streamed it from the hardware to clients; also displayed a preview and measured and displayed performance-related statistics XST01-04 Form4.cs Correctly displayed session statistics XST01-05 stats.cs Correctly stored statistics XST01-06 Session.cs Correctly stored statistics collected every five seconds, i.e. statistics collected for a particular session XST02-01 Webpage X-Stream TV webpage was correctly accessed through a access browser on the user’s client XST02-02 Windows Multimedia streamed efficiently and easily, allowing the user Media Player to view multimedia through the Windows Media Player client XST03-01 Selecting Input source was correctly configured and interfaced with the input source server software XST03-02 Selecting Output port was correctly configured, connection is correctly output set up, and/or the output stream to a file is correctly set up XST03-03 Stop/resume The multimedia stream was started or resumed as desired stream Test item Name Assessment XST03-04 View statistics Streaming statistics were correctly displayed and updated at all times; session statistics were displayed each time the multimedia stream was paused/stopped XST04-01 Live streaming Multimedia was streamed correctly with input provided by any source such as a VCD player or a digital camera XST04-02 Recording a The multimedia stream was correctly saved to a file on the file hard disk XST04-03 Performance The performance requirements as stated earlier in this testing document were met; see ahead for detailed statistics and graphs Summary of results Overall, the system is functioning without a problem. Minor incidents that occurred involved interface design issues and client-side webpage access, but these were resolved. All modules and procedures appear to be working. However, we ran into the following limitations that are built into Windows Media Encoder: X-Stream TV 41
  • 53. • The server can only play/preview the video being streamed; it does not play audio. This is a feature of Windows Media Encoder itself; the encoding computer can only view video, not hear audio. • There is a slight time lag of 5-15 seconds depending on network performance and settings before the live stream is actually received by the client computer. The amount of time it takes for someone to receive content in a live broadcast cannot be reduced. It is important to first understand the difference between buffering and delay. Buffering refers to the time it takes a player to fill its buffer before it starts playing the content. In other words, it is the difference between the time at which a user opens a connection to a streaming media server and time at which the content begins playing. On the other hand, delay refers to the difference, in a live broadcast, between the time at which content is encoded and the time at which the content is played. Delay is also known as network latency. Streaming using the Windows Media reduces buffering greatly as a result of the Fast Start and Fast Cache features. When streaming content either as a live broadcast or an on- demand stream, the server takes advantage of available bandwidth to burst data to Windows Media Player 9 Series so that playback begins almost immediately. While it is not possible to eliminate delay, it can be minimized it by adjusting settings on the server, encoder, and the Player. Doing so will only reduce delay by a couple of seconds. Also, playback quality and performance may be impacted negatively. • At any one time, no more than five clients can simultaneous receive the stream being provided by the server. Evaluation Table 11: Test Item Evaluation Test item Name Evaluation XST01-01 Form1.cs Splash screen was correctly displayed XST01-02 Form2.cs Correctly displayed available audio sources, available TV Tuner inputs, and allowed selection of a pre-existing file to stream; correctly allowed port selection, displayed available connection types and allowed selection of an output file to save to while streaming XST01-03 Form3.cs Based on the options selected by the user, correctly selected and configured the input sources, received the input, created a broadcast, encoded the video and streamed it from the hardware to clients; also displayed a video preview and measured and displayed performance-related statistics XST01-04 Form4.cs Correctly displayed session statistics XST01-05 stats.cs Correctly stored statistics XST01-06 Session.cs Correctly stored statistics collected every five seconds, i.e. statistics collected for a particular session X-Stream TV 42
  • 54. Test item Name Evaluation XST02-01 Webpage X-Stream TV webpage was correctly accessed through a access browser on the user’s client XST02-02 Windows Multimedia streamed efficiently and easily, allowing the user Media to view multimedia through both embedded and external Player Windows Media Player client XST03-01 Selecting Input source was correctly configured and interfaced with the input source server software XST03-02 Selecting Output port was correctly configured, connection is correctly output set up, and/or the output stream to a file is correctly set up XST03-03 Stop/resume The multimedia stream was started or resumed as desired stream XST03-04 View Streaming statistics were correctly displayed and updated at statistics all times; session statistics were displayed each time the multimedia stream was paused/stopped XST04-01 Live Multimedia was streamed correctly with input provided by streaming any source such as a VCD player or a digital camera XST04-02 Recording a The multimedia stream was correctly saved to a file on the file hard disk XST04-03 Performance The performance requirements as stated earlier in this testing document were met; see ahead for detailed statistics and graphs. Some anomalies were reported. At times, the frame rate or bit rate requested from the encoder was not received. The setting specified represents the maximum value; if encoding low-motion video, the frame rate or bit rate of the encoded content might be lower. Other factors that may reduce the frame rate or bit rate include a high video quality setting, insufficient network bandwidth, a large frame size, and a system that is not sufficiently powerful. If the encoding system is not sufficiently powerful, it may be necessary to optimize the system by closing all other applications while encoding, turning off video preview and postview, and adjusting the performance settings. Summary of activities The following activities were carried out to test the system’s features: 1. Tests were run using a VCD Player, a digital camera or a pre-existing file as test cases. Each test item was examined thoroughly. 2. Every minute, the frame rate and bandwidth was recorded and another client was added. 3. Session statistics regarding the expected bit rate and the current bit rate were collected, varying every single connection type. These statistics were plotted against elapsed time on a graph and incident reports were written. X-Stream TV 43
  • 55. 5.23 Test Results Elapsed Current Expected No. of Bit Rates Fluctuation Time Bit rate Bit rate Clients 5.641 141 138 1 Dial-up Modems or Single-channel ISDN (28.8 to 56 Kbps) 11.201 108 138 1 16.801 140 138 1 22.361 106 138 1 180 27.841 147 138 1 160 140 33.521 121 138 1 Bit Rate (Kbps) 120 39.041 124 138 1 100 Current Bit rate 44.681 140 138 1 80 Expected Bit rate 50.201 134 138 1 60 55.841 106 138 1 40 61.401 135 138 1 20 67.001 153 138 2 0 72.521 106 138 2 5.64 16.8 27.8 39 50.2 61.4 83.7 117 72.5 94.8 106 78.161 90 138 2 Time Elapsed (s) 83.721 139 138 2 89.201 121 138 2 94.841 142 138 2 100.401 143 138 2 106.041 133 138 2 111.521 140 138 2 117.201 145 138 2 122.721 139 138 2 Figure 1: Dial-up Modems or Single-channel ISDN (28.8 to 56 Kbps) X-Stream TV 44
  • 56. Elapsed Current Expected No. of Bit Rates Fluctuation Time Bit rate Bit rate Clients LAN, Cable Modem, or xDSL (100 to 768 Kbps) 5.613 137 137 0 11.168 137 137 1 160 16.725 129 137 1 140 22.365 69 137 1 Bit Rate (Kbps) 120 27.885 33 137 1 100 Current Bit rate 33.525 129 137 1 80 60 Expected Bit rate 39.085 112 137 1 40 44.685 128 137 1 20 50.205 129 137 1 0 55.845 132 137 1 5.61 22.4 72.5 89.2 123 139 173 39.1 55.8 106 156 61.405 119 137 1 Time Elapsed (s) 67.005 137 137 1 72.525 120 137 1 78.165 133 137 1 Elapsed Current Expected No. of 83.725 126 137 1 Time Bit rate Bit rate Clients 89.205 130 137 1 150.645 119 137 2 94.885 132 137 1 156.205 138 137 2 100.405 131 137 1 161.725 125 137 2 106.045 130 137 1 167.405 96 137 2 111.525 126 137 1 172.885 139 137 2 117.205 144 137 2 122.725 139 137 2 Figure 2: LAN, Cable Modem, or xDSL (100 to 768 Kbps) X-Stream TV 45
  • 57. Elapsed Current Expected No. of Bit Rates Fluctuation Time Bit rate Bit rate Clients Dial-up Modems or LAN (28.8 to 100 Kbps) 5.623 115 137 1 11.183 124 137 1 16.783 69 137 1 160 22.343 91 137 1 140 27.943 100 137 1 Bit Rate (Kbps) 120 33.503 140 137 1 100 Current Bit rate 39.023 127 137 1 80 Expected Bit rate 44.663 129 137 1 60 50.183 135 137 1 40 20 55.823 125 137 1 0 61.383 125 137 1 66.983 133 137 1 03 3 43 23 23 10 3 12 3 13 3 3 18 98 70 62 0 .3 .0 .5 .5 .8 6. 9. 2. 5. 72.503 114 137 1 39 72 89 22 55 78.343 134 137 1 Time Elapsed (s) 83.943 136 137 1 89.503 146 137 2 95.023 86 137 2 Elapsed Current Expected No. of 100.663 90 137 2 Time Bit rate Bit rate Clients 106.183 135 137 2 139.703 120 137 2 111.823 134 137 2 145.303 135 137 2 117.383 128 137 2 122.983 123 137 2 128.503 133 137 2 134.143 129 137 2 Figure 3: Dial-up Modems or LAN (28.8 to 100 Kbps) X-Stream TV 46
  • 58. Elapsed Current Expected No. of Bit Rates Fluctuation Time Bit rate Bit rate Client Dial-up Modems (28.8 Kbps) s 5.55 20 20 1 11.23 21 20 1 25 16.75 23 20 1 22.39 14 20 1 20 Bit Rate (Kbps) 27.87 23 20 1 15 33.55 14 20 1 Current Bit rate 39.07 21 20 1 10 Expected Bit rate 44.71 12 20 1 50.23 21 20 1 5 55.87 21 20 2 0 61.43 19 20 2 16.8 27.9 50.2 61.4 72.6 94.9 106 5.55 39.1 83.8 117 66.99 12 20 2 72.55 9 20 2 Time Elapsed (s) 78.071 20 20 2 83.75 23 20 2 89.231 18 20 2 94.871 19 20 2 100.431 19 20 2 106.071 19 20 2 111.551 19 20 2 117.191 19 20 2 Figure 4: Dial-up Modems (28.8 Kbps) X-Stream TV 47
  • 59. Elapsed Current Expected No. of Bit Rates Fluctuation Time Bit rate Bit rate Clients Dial-up Modems (56 Kbps) 5.634 32 32 1 11.194 38 32 1 40 16.714 35 32 1 22.354 33 32 1 35 27.834 25 32 1 30 Bit Rate (Kbps) 33.514 36 32 1 25 39.034 34 32 1 Current Bit rate 20 44.674 31 32 1 Expected Bit rate 15 50.194 25 32 1 10 55.834 33 32 1 61.394 31 32 2 5 66.954 33 32 2 0 72.514 28 32 2 16.7 27.8 39 50.2 61.4 72.5 94.8 106 117 5.63 83.7 128 78.034 25 32 2 Time Elapsed (s) 83.714 35 32 2 89.194 30 32 2 94.834 28 32 2 100.394 33 32 2 106.034 30 32 2 111.514 25 32 2 117.194 27 32 2 122.714 27 32 2 128.314 25 32 2 Figure 5: Dial-up Modems (56 Kbps) X-Stream TV 48
  • 60. Elapsed Current Expected No. of Time Bit rate Bit rate Clients 5.629 105 100 1 Bit Rates Fluctuation Local Area Network (100 Kbps) 11.189 103 100 1 16.789 101 100 1 120 22.349 101 100 1 27.949 101 100 1 100 Bit Rate (Kbps) 33.509 97 100 1 80 Current Bit rate 39.029 60 100 1 60 Expected Bit rate 44.669 101 100 1 40 50.189 102 100 1 20 55.829 96 100 1 0 61.389 99 100 2 106 117 27.9 39 72.5 83.7 94.8 5.63 16.8 50.2 61.4 66.989 103 100 2 72.509 104 100 2 Time Elapsed (s) 78.149 81 100 2 83.709 100 100 2 89.309 79 100 2 94.829 98 100 2 100.389 104 100 2 106.029 95 100 2 111.509 103 100 2 117.189 98 100 2 122.709 98 100 2 Figure 6: Local Area Network (100 Kbps) X-Stream TV 49
  • 61. Elapsed Current Expected No. of Time Bit rate Bit rate Clients Bit Rates Fluctuation 5.604 246 225 1 Local Area Network (256 Kbps) 11.164 227 225 1 16.764 231 225 1 300 22.324 236 225 1 250 Bit Rate (Kbps) 27.924 229 225 1 200 33.484 230 225 1 Current Bit rate 150 39.044 229 225 1 Expected Bit rate 100 44.644 218 225 1 50.204 239 225 1 50 55.804 235 225 1 0 16.8 39 61.4 72.5 83.7 94.8 106 117 5.6 27.9 50.2 61.364 220 225 2 66.964 234 225 2 Time Elapsed (s) 72.524 227 225 2 78.124 191 225 2 83.684 215 225 2 89.244 232 225 2 94.844 224 225 2 100.404 228 225 2 106.004 211 225 2 111.564 228 225 2 117.164 227 225 2 Figure 7: Local Area Network (256 Kbps) X-Stream TV 50
  • 62. Elapsed Current Expected No. of Time Bit rate Bit rate Clients 5.594 353 350 1 11.154 360 350 1 Bit Rates Fluctuation 16.754 364 350 1 Local Area Network (384 Kbps) 22.314 361 350 1 27.914 360 350 1 400 33.474 352 350 1 350 Bit Rate (Kbps) 39.074 374 350 1 300 44.634 358 350 1 250 Current Bit rate 200 50.194 365 350 1 Expected Bit rate 150 55.794 341 350 1 100 61.354 348 350 2 50 66.954 275 350 2 0 72.514 349 350 2 16.8 39.1 61.4 72.5 83.7 94.8 106 117 5.59 27.9 50.2 78.114 349 350 2 Time Elapsed (s) 83.674 351 350 2 89.274 362 350 2 94.834 345 350 2 100.394 336 350 2 105.994 357 350 2 111.554 361 350 2 117.154 355 350 2 Figure 8: Local Area Network (384 Kbps) X-Stream TV 51
  • 63. Elapsed Current Expected No. of Time Bit rate Bit rate Clients 5.59 457 450 0 Bit Rates Fluctuation 11.19 480 450 0 Local Area Network (768 Kbps) 16.75 439 450 1 22.351 444 450 1 600 27.911 462 450 1 500 33.511 452 450 1 Bit Rate (Kbps) 39.071 447 450 1 400 Current Bit rate 44.671 451 450 2 300 Expected Bit rate 50.231 455 450 2 200 55.791 460 450 2 61.391 463 450 2 100 66.951 440 450 2 0 72.551 352 450 2 16.8 39.1 61.4 72.6 83.7 94.8 106 117 5.59 27.9 50.2 78.111 496 450 2 83.711 454 450 2 Time Elaspsed (s) 89.271 452 450 2 94.831 458 450 2 100.431 463 450 2 105.991 453 450 2 111.591 415 450 2 117.151 436 450 2 Figure 9: Local Area Network (768 Kbps) X-Stream TV 52
  • 64. Elapsed Current Expected No. of Time Bit rate Bit rate Clients 5.658 20 20 0 Bit Rates Fluctuation 28.8 Modem with save to file option 11.214 15 20 1 16.734 5 20 1 25 22.374 5 20 1 Bit Rate (Kbps) 20 27.934 19 20 1 15 Current Bit rate 33.534 19 20 1 10 Expected Bit rate 39.054 21 20 1 5 44.694 13 20 1 0 50.254 23 20 1 55.854 16 20 1 27 4 39 4 50 4 61 4 72 4 83 4 94 4 11 5 21 16 8 10 4 65 3 5 1 3 3 5 7 9 0 .9 .0 .4 .7 .2 .5 .7 .8 6. 7. 5. 61.414 18 20 1 67.014 13 20 1 Time Elapsed (s) 72.574 16 20 1 78.174 16 20 1 83.734 17 20 1 89.254 14 20 1 94.894 21 20 1 100.414 13 20 2 106.054 19 20 2 111.614 18 20 2 117.214 19 20 2 122.734 15 20 2 Figure 10: 28.8 Modem with Save to File option X-Stream TV 53
  • 65. Elapsed Current Expected No. of Time Bit rate Bit rate Clients Bit Rates Fluctuation 5.594 447 450 1 Local Area Network (768 Kbps) 11.194 437 450 1 16.754 453 450 1 500 22.314 356 450 1 450 27.914 452 450 1 400 33.474 462 450 1 Bit Rate (Kbps) 350 39.074 452 450 1 300 Current Bit rate 44.634 393 450 1 250 Expected Bit rate 50.234 454 450 1 200 150 55.794 428 450 1 100 61.354 455 450 2 50 66.954 322 450 2 0 72.514 272 450 2 27.9 72.5 83.7 94.8 106 117 5.59 16.8 39.1 50.2 61.4 78.114 463 450 2 Time Elapsed (s) 83.674 460 450 2 89.274 448 450 2 94.834 451 450 2 100.434 295 450 2 105.994 273 450 2 111.594 433 450 2 117.155 460 450 2 122.715 456 450 2 Figure 11: Local Area Network (768 Kbps) with Save to File option X-Stream TV 54
  • 66. Chapter 6 Deployment For X-Stream TV to work properly it is mandatory that the Windows Media Encoder SDK reference library is properly installed on the server computer. Additionally, the hardware driver must be properly installed on the server side; in X-Stream TV’s case, the driver for the PixelView TV Tuner, and Sound Card should be properly installed. Hardware Issues 1. Windows Media is compatible with a limited number of TV Tuner cards. These include the more popular ones such as Pinnacle, Haupage, PixelView, etc. The card we chose to demonstrate the working of X-Stream TV was designed by PixelView. 2. If the cables connecting the input device to the TV Tuner card are not properly connected then input will not be correctly received and the user will be prompted with an error message. X-Stream TV 55
  • 67. Chapter 7 Results and Conclusion After two quarters of intensive research, extensive documentation, and rigorous coding, we have finally delivered a high-quality, seamlessly working, bug-free application that can potentially improve the professional and leisurely activities for numerous users, at home, school, or the office. While developing X-Stream TV, we had to research a number of technologies, e.g. Windows Media SDK, DirectShow SDK, streaming protocols, etc. Through this endeavor, we can now boast an above-average working knowledge of how to interface and integrate these various technologies using the .NET framework, and C#. The Senior Project has been the most ambitious project we have attempted during our programme at LUMS, and we are extremely grateful that we have managed to complete X- Stream TV in a manner that exceeds our initial expectations. Working on the project has led us to evaluate personal capabilities, as well as group dynamics. We have achieved the scope initially stated in the SRS. The application developed, X-Stream TV, is an engine for streaming live multimedia over a network. The objective of X-Stream TV is taking a live feed from a TV Tuner and sound card, and streaming it over a network in real time. Its intended uses include video conferencing, live TV distribution, and live presentation viewing, etc. using a pre-existing network. Depending on usage, the live feed is obtained from a TV antenna, a video camera, or any other compatible audio/video device. X- Stream TV transmits the captured feed for display on a remote terminal. In order to reduce time lag, and distortion, while maintaining quality, X-Stream TV incorporates real-time encoding modules to manage the transmitted data size. The current version of X-Stream TV can perform the following tasks with no errors: • broadcasting TV channels from a single cable connection to multiple network clients • broadcasting live or pre-recorded video feeds (such as presentations, lectures or documentaries) on an office or campus network • individual users can access their personal cable connection or video collection via a network X-Stream TV 56
  • 68. Chapter 8 Future Work • Deploy the X-stream TV server in LUMS academic, for entertainment and educational purposes. Currently X-stream TV is capable of streaming anywhere over the LUMS LAN. However no controlled tests have been carried out to evaluate the performance of the server over the whole LAN. Deployment of the X-Stream TV server over the whole of the LUMS LAN will provide many benefits to the institution. The student body has been increasing steadily over the four years; however the largest auditorium can only hold a limited number of students. This makes it impossible to hold large seminars or screen live television broadcasts in the auditoriums where a large number of students can attend. X-Stream TV can solve the problem; the seminar can be streamed live to different auditoriums, hostels, labs and offices. In this manner a much larger audience can view the ongoing seminar. Moreover, X-Stream TV can be used to save important presentations to file and stream them simultaneously. This feature enables the administration to stream the presentation at some other time. Current limitations in the X-stream TV server is the number of clients that can successfully view the live Stream. The limit is set to 50 users, but it has not been tested with that large a number of users. • Extend the functionality of X-Stream TV to WAN and the internet by providing the X- Stream TV server with an external IP. In this manner, off-campus users, e.g. students or instructors working from their remote home connections, can access a live broadcast of events taking place on campus. Additionally, X-Stream TV can also aid in high-quality teleconferencing between students and faculty from LUMS and other domestic and foreign institutes. • Develop a X-Stream TV version that is capable of streaming to mobile phones and wireless networks via the WAP and 3G technologies. With the current telecom infrastructure in Pakistan gradually improving, X-Stream TV can be configured to stream a low-quality stream over a wireless and/or cellular network, and this audio/video content will be accessible to all cellular phone users whose network carrier supports data wireless data transfer protocols. • Future work in the X-Stream TV server can also include giving the server application greater control over the hardware, e.g. channel selection and tuning on the TV Tuner, and selecting different or multiple inputs on the Sound Card. • At the web interface, the X-Stream TV server can also provide an RSS feed of the current broadcast schedule so that remote users know when to logon for their preferred content. X-Stream TV 57
  • 69. Appendix A Windows Media vs. Microsoft DirectShow Reference The following is an excerpt from “Microsoft Windows Media and DirectShow: Options for Application Developers”, and is available in its entirety at http://msdn.microsoft.com/library/default.asp?url=/library/en- us/dnwmt/html/wm_ds_options.asp Introduction Microsoft provides a number of software development kits (SDKs) for developers of digital media applications for the Microsoft® Windows® platform. Currently, the two primary SDKs are Microsoft DirectShow® and the Windows Media™ SDK. DirectShow provides support for creating many types of digital media applications and many different media formats, including Windows Media. The Windows Media SDK is actually a suite of SDKs focused on specific support for the Windows Media Format. In some ways, the capabilities of these SDKs overlap. For example, simple playback of Windows Media Format files can be performed using the DirectShow SDK, the Windows Media Format SDK, or the Windows Media Player SDK; each option has its advantages and limitations. In other ways, each SDK offers unique capabilities. The purpose of this article is to compare the capabilities and limitations of each SDK in order to help developers decide which SDK is best suited to their needs. About the Windows Media Format The Windows Media Format is an extensible file format that enables audio and video content to be compressed and distributed through streaming, downloading, or local storage such as CD-ROM. The format comprises a file container called the Advanced Systems Format (ASF) along with audio and video data compressed with any of the following codecs: • Windows Media Audio 8 codec for high-fidelity music and mixed audio. • Windows Media Video 8 codec for low bandwidth or high-quality video delivery. • The ISO MPEG-4 Version 1 video codec, which provides standards-based codec implementation for situations where standards are important. (This codec does not offer the same quality as the later Windows Media Video codecs but is provided for compatibility with this long-established industry standard.) Windows Media Format supports additional data, such as: • Metadata about the content, such as its title or author. • A script stream that allows content to be synchronized with other information such as HTML, captioning, and so on. This stream also enables you to control the user interface in a browser from within the encoded stream itself. The Windows Media Format is designed to arrange and organize synchronized multimedia data. It is optimized for streaming data over networks and rendering the data on a client computer. Windows Media Format is suitable for streaming live presentations, as well as prerecorded files. Windows Media Format offers the following advantages to developers and users: • The size of ASF files is virtually unlimited, with a practical limitation based on the particular file system and operating system being used.On Microsoft Windows® 95, Windows 98, and Windows NT® 4, the maximum file size (using FAT and FAT32 file systems) is 4 gigabytes (GB). On Windows 2000 the NTFS file system has a very large theoretical file size limitation, but can support ASF files with a maximum practical file size of about 50 GB. • Windows Media Format uses Windows Media Audio and Windows Media Video codecs to compress and decompress the data. Both codecs combine high-quality audio and video output with significant improvements in file compression, so that audio and video data uses less storage space and/or can provide greater quality over low bandwidth connections into the home or office. • Many different types of software and hardware players can decode content stored in Windows Media Format, including Windows Media Player on Windows, Macintosh, X-Stream TV 58
  • 70. and Unix operating systems, portable audio devices, and set-top decoders. In the future, it is likely that home and car stereo devices, cellular phones, and many other types of hardware will support Windows Media Format, providing users with access to their content wherever they may be. • Windows Media Format provides robust and reliable synchronization of audio and video. • Windows Media Format also guarantees the user experience will be of high quality. • Content in Windows Media Format can be secured through digital rights management. Content providers can license their Windows Media data to users and protect it from copyright infringement and piracy. Overview of the Windows Media SDK The Windows Media SDK is an umbrella term for a suite of SDKs specifically geared toward creation, playback (including network streaming), and DRM protection of Windows Media content. The individual SDKs are described briefly below. Windows Media Format SDK Offers a low-level interface designed for natively integrating Windows Media Format into applications. Both Windows Media Encoder and the DirectShow ASF filters use this SDK internally. The Windows Media Format SDK enables applications to read, write, edit, and transfer Windows Media Format files, including playback of DRM-protected content and streaming of content over a network. This SDK also provides the only way to package non– Windows Media content inside the ASF file container. Here are some points to consider in deciding whether the Windows Media Format SDK is appropriate for your needs: • While the Windows Media Format SDK provides low-level access to the media stream, applications are entirely responsible for capturing data from hardware devices and rendering it to the screen or the speakers. This gives developers complete control over the media streaming functions of their code, which can be useful for application- specific optimization and debugging. If such control is not required and your application must perform either capture or rendering, especially of video content, consider using the Windows Media Encoder SDK or the DirectShow SDK for those tasks to reduce development time. • Because Windows Media Format application programming interfaces (APIs) are focused exclusively on Windows Media Format, they might be easier to learn for developers who are already familiar with streaming media applications and whose applications are not based on DirectShow. • The Windows Media Format SDK files that applications redistribute are relatively small compared to the Microsoft DirectX® files that are necessary for DirectShow. As a result, applications written using the Windows Media Format SDK may be smaller. This is an advantage when download time is important. Windows Media Encoder SDK Offers an Automation interface for the Windows Media Encoder, a free software tool available from Microsoft at the Windows Media page of the Microsoft Web site. The Windows Media Encoder captures audio and video from live sources such as TV cards and digital video (DV) camcorders, file conversion services, and from streamed audio and video content over a network. Developers can use the SDK to extend the capabilities of Windows Media Encoder, for example to perform automated batch encoding operations, or create a custom user interface. If your application requirements do not extend beyond the capabilities of Windows Media Encoder, this ready-to-run application is probably the most cost-effective solution for creating or streaming Windows Media content. Windows Media Player SDK Offers a scripting interface for controlling Windows Media Player, which is available at no cost from the Windows Media page of the Microsoft Web site. Developers who need simple audio or video playback capabilities in COM-based documents, applications, or Web pages can embed the Windows Media Player control and control it with Automation. Windows Media Player supports not only Windows Media content, but also any format supported by DirectShow, such as AVI, WAV, AIFF, MP3 and MPEG-1. This includes non-standard formats, assuming that the required codecs or DirectShow filters have been installed on the local system. Developers can use the Windows Media Player SDK to create custom skins and visualizations for the 7.x versions of the Player, and to manage playlists. The SDK also X-Stream TV 59
  • 71. contains scripting interfaces for Windows Media Player version 6.4, which is installed with Microsoft Internet Explorer 5, Microsoft Windows 98 Second Edition, Microsoft Windows 2000, and Microsoft Windows XP Home Edition and Windows XP Professional. Overview of the DirectShow SDK The DirectShow SDK offers a powerful digital media streaming architecture, high-level APIs, and an extensive library of plug-in components called filters that have been field-tested over several years of use. Filters separate the processing of digital media data into discrete steps; each filter represents one (or sometimes more than one) processing step, such as file reading or writing, parsing, decoding, rendering, and so on. Third parties can create their own filters to perform any type of custom processing. The DirectShow architecture provides a generalized and consistent approach for creating virtually any type of digital media application. You write a DirectShow application by creating an instance of a high-level object called the filter graph manager, and then use it to create configurations of filters (called filter graphs) that work together to perform some desired task on a media stream. The filter graph manager and the filters themselves handle all buffer creation, synchronization, and connection details, so the application developer needs only to write code to build and operate the filter graph; there is no need to touch the media stream directly, although access to the raw data is provided in various ways for those applications that require it. Construction of many standard types of filter graphs can be accomplished with only one or two method calls. DirectShow also includes a set of high-level APIs, known as DirectShow Editing Services (DES), which enables the creation of non-linear video editing applications. DES brings the following features to DirectShow: • A timeline model that organizes video and audio tracks into nested layers, making it easy to manipulate the final production. • Support for reading from and writing to Windows Media files. • The ability to preview a video project on the fly. • Project persistence through an XML-based format. • Support for audio and video effects and transitions, such as fades and wipes. • Almost 100 standard wipes, as defined by the Society of Motion Picture and Television Engineers (SMPTE). • Keying based on hue, luminance, RGB value, or alpha value. • Automatic conversion of frame rates and audio sampling rates, enabling a production to use a wide variety of sources. • Resizing or cropping of video. DirectShow support for Windows Media files is provided through two filters, the ASF Reader and the ASF Writer. (Actually, there are two versions of the ASF Reader filter; we'll discuss the differences between them in a moment.) The ASF Reader is used for playing Windows Media files. It acts as both a file reader and a stream parser. It reads Windows Media Audio or Windows Media Video files and passes the encoded content downstream to the audio and/or video decoders, which in turn pass the decoded content to the renderer(s). The ASF Writer is used for creating Windows Media files. Both of these filters use the Windows Media Format SDK internally to do their work, but as with any DirectShow filter, they handle all the low-level streaming details such as synchronization and buffer allocation. For an application, construction of a Windows Media playback filter graph is trivial. Creating a file-writing filter graph is slightly more complex, because the application must use the Windows Media Format SDK directly in this case to specify a profile, or set custom parameters such as bit rate, seconds per key frame, and so on. As stated before, DirectShow has two ASF Reader filters. The original filter is maintained to ensure backward compatibility with Windows Media Player Version 6.4. This filter is geared toward network playback and provides support for fast-forwarding but not rate control. It is the default filter for playing Windows Media files and will be selected by the filter graph manager during automatic graph construction unless the new filter is specifically added to the graph by the application. The newer filter supports rate control, and should be used in most new applications. The DirectShow SDK explains how to ensure that the newer ASF Reader is used for file playback. For playback of Windows Media, the advantage of DirectShow over the Windows Media Player SDK is that DirectShow allows you to integrate the playback window in containers other than a Web page. For creating Windows Media Files, the advantage of DirectShow over the Windows Media Encoder SDK is that DirectShow has a smaller footprint in host X-Stream TV 60
  • 72. memory. For both reading and writing, the advantage of DirectShow over the Windows Media Format SDK is ease of use, especially if you are familiar with DirectShow, or your application is already using DirectShow for other tasks such as video capture or non-linear video editing. However, there are some limitations in DirectShow's support for Windows Media: • The DirectShow ASF Reader filters that shipped prior to DirectX 8.1 do not handle files that have been protected with digital rights management. • The ASF Writer cannot be use to create ASF files using non-Microsoft codecs. DirectShow is a component of the Microsoft DirectX SDK. Using DirectShow with Windows Media requires the presence of Windows Media Format run-time components, and development requires the Windows Media Format SDK with proper licensing. X-Stream TV 61
  • 73. Appendix B Streaming Technology Reference The following is an excerpt from “Basic Streaming Technology and RTSP Protocol” by the California Software Laboratories, and is available in its entirety at: http://www.cswl.com/whiteppr/tech/StreamingTechnology.html#definition Definition Streaming is the process of playing a file while it is still downloading. Streaming technology, also known as streaming media, lets a user view and hear digitized content — video, sound and animation — as it is being downloaded. Using a World Wide Web browser plug-in, streamed sounds and images can arrive within seconds of a user's click. The need for video on the internet Various media are used in Internet, not only for the obvious purpose of entertainment applications, but for other applications such as video conferencing, video archives and libraries, remote learning, multimedia presentations, and of course, video on demand. Here is a list of the common applications: • Internet Multimedia. • Interactive Video Games. • Personal Communications. • Video Storage. • Multimedia Email. • Database Services and Archives. • Video Surveillance. • Emergency Systems. • Broadcasting. How Does it Work A web designer can add links that reference a media hosting network, to a website. When a viewer clicks on one of the links, the media network streams the clip directly to the viewer's PC as though it was coming from the original website. Because the media files are hosted on a separate network, the streaming has no impact on any existing web servers. When a user logs into a hosted streaming network for instance, he or she is automatically fed content from the nearest available server on the Internet. This content is thus delivered at the best quality possible for that connection. Key Words in Streaming Technology 1. Buffering Receiving and storing data before playing it back. 2. Codec Coder/decoder. Codecs convert data between uncompressed and compressed formats, thereby reducing the bandwidth a clip consumes. 3. Encoding Converting a file into a compressed, streaming format. For example, you can encode WAV files as RealAudio. 4. SMIL Synchronized Multimedia Integration Language. A mark-up language for specifying how and when each clip plays. SMIL files use the .smil or .smi extension. X-Stream TV 62
  • 74. 5. Stream A flow of a single type of data, measured in Kilobits per second (Kbps). 6. Multicast Used for broadcasting large events over the Internet. Allows a single computer to create the content (film, etc.) and many computers to play the same single stream simultaneously. 7. Streaming When a large media file (audio, video, etc.) is broken into smaller pieces so it can viewed or heard immediately. This avoids the wait for the whole file to be downloaded first. 8. Firewall Security devices used to protect companies from unauthorized access to their servers. A firewall, using either proxy services or packet filtering, ensures that all communication between an organization's network and the Internet, conforms to the organization's security policies. 9. On-Demand A type of streaming in which a clip plays from start to finish when a user clicks a link. Most clips are streamed this way. 10. Request headers Request headers are used in client requests to communicate information about the client. 11. Response Headers Response headers are used in server responses to communicate information about the server and how it may handle requests. 12. AVI AVI, or Audio Video Interleave, is the most common format for audio/video data on the PC. It is a special case of the RIFF (Resource Interchange File Format), and is defined by Microsoft. 13. MPEG MPEG (pronounced M-peg) stands for Moving Picture Experts Group. MPEG is the name given to the family of standards used for coding audio-visual information (e.g., movies, video, music) in a digitally compressed format. 14. SMPTE SMPTE is a time code synchronization protocol originally developed for use in the television and motion picture industry where it was used to handle video tape technology. 15. ASF ASF(Advanced Streaming Format) is a file format that stores audio and video information and is specially designed to run over networks like the Internet. Protocols Used in Streaming Technology Protocols are the rules implemented for a particular technology. Protocols in streaming technology are used to carry message packets, and communication takes place only through them. Some of the protocols used in streaming technology are: 1. Session Description Protocol (SDP) A media description format intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. X-Stream TV 63
  • 75. 2. Real Time Transport Protocol (RTP) A UDP packet format and set of conventions that provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio, video or simulation data, over multicast or unicast network services. 3. Real-time Control Protocol (RTCP) RTCP is the control protocol that works in conjunction with RTP. RTCP control packets are periodically transmitted by each participant in an RTP session to all other participants. RTCP is used to control performance and for diagnostic purposes. 4. Hypertext Transfer Protocol (HTTP) An application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, object-oriented protocol that can be used for many tasks, such as name servers and distributed object management systems, through extension of its request methods. 5. Real Time Streaming Protocol (RTSP) An application-level protocol for control over the delivery of data with real-time properties. RTSP provides an extensible framework to enable controlled, on-demand delivery of real-time data, such as audio and video, using the Transmission Control Protocol (TCP) or the User Data Protocol (UDP). Example For example, the following diagram depicts how protocols are used to communicate between the components of RTSP system. Streaming Video Streaming video is a sequence of "moving images" that are sent in compressed form over the Internet and are seen by the viewer as they arrive. 1. Video Streaming System A complete video-streaming system involves all of the basic elements of creating, delivering, and ultimately playing the video content. The main components of a complete video streaming system used to accomplish this—Encoding Station, Video Server, Network Infrastructure, and Playback Client— are illustrated in the following diagram.  Step 1. Capture: X-Stream TV 64
  • 76. As this diagram shows, the first step in the process of creating streaming video is to "capture" the video from an analog source such as a camcorder or VHS tape, digitize it and store it to disk. This is usually accomplished with an add-in analog video capture card and the appropriate capture software. Newer digital video sources such as digital video camcorders can be captured straight to disk with a "Firewire" capture board without the analog-to-digital conversion step. The capture card may also support the delivery of “live” video in addition to “stored” video.  Step 2. Edit/Author : Once the video is converted to digital and is stored on disk it can be edited using a variety of non-linear editing tools. At this stage, as described below, an authoring tool may also be used to integrate the video with other multimedia into a presentation, entertainment, or training format.  Step 3. Encode: After the video is edited and is integrated with other media it may be encoded to the appropriate streaming file format. This generally involves using the encoding software from the video-streaming vendor and specifying the desired output resolution, frame rate, and data rate for the streaming video file. When multiple data rates need to be supported, multiple files may be produced corresponding to each data rate. As an alternative, newer video streaming technologies create one file that has "dynamic bandwidth adjustment" to the needed client data rate.  Step 4. Serve: The video server manages the delivery of video to clients using the appropriate network transport protocols over the network connection. The video server consists of a hardware platform that has been optimally configured for the delivery of real-time video plus video server software that runs under an operating system such as Microsoft Windows NT that acts as a "traffic cop" for the delivery of video streams. Video server software is generally licensed by the "number of streams." If more streams are requested than the server is licensed for, the software rejects the request.  Step 5. Play: Finally, at the client station the video player receives and buffers the video stream and plays it in the appropriate size window using a VCR-like user interface. The player generally supports such functions as play, pause, stop, rewind, seek, and fast forward. Client players can run stand-alone or can be ActiveX controls or browser plug-ins. They can decode video using software or using hardware add-in decoder boards. Streaming Media Sample X-Stream TV 65
  • 77. 1. NETSHOW Microsoft Windows NT® Server NetShow™ Services enable Internet Providers and organizations to deliver the highest-quality audio and video across the Internet or enterprise networks. NetShow Services allow users to receive audio and video broadcasts from their personal computers. NetShow Services consist of server and tools components for streaming audio, video, illustrated audio, animations, and other multimedia file types over networks. The streaming media components of the Windows Media Technologies provide a complete solution for integrating audio and video into online applications, bringing the vibrant power of networked multimedia to the Internet and corporate intranets. The Windows Media Player continuously decompresses and plays the content in real time. The NetShow 3.0 system includes the player, the server, the software developer's kit (SDK), and other tools. 2. Real Media RealServer streams audio, video, images, animation, text, and other data types to client computers. This newest version of RealServer has been designed to keep pace with your multimedia needs as they continue to change. RealServer is server software that streams both live and prerecorded media over a network. The streamed data can originate either on the Internet or within an intranet. The client receives the media in real time, and without having to wait for clips to be downloaded.  Working of Real Server RealServer streams media to clients over networks and the Internet. It's usually employed in conjunction with a Web server. Note that you can use some RealServer features with third-party products to create specialized functions, such as report analysis.  Channels and Protocols RealServer uses two connections, known as channels, to communicate with clients: one for communication with the client, and one for actual data. The communication channel is known as the control channel, as it is over this line that RealServer requests and receives passwords and clients send instructions such as fast-forward, pause, and stop. Media clips themselves, on the other hand, are actually streamed over a separate data channel. Every link to content begins with a protocol identifier, such as rtsp, pnm, or http. RealServer uses two main protocols to communicate with clients: Real Time Streaming Protocol (RTSP) and Progressive Networks Audio (PNA). Occasionally, RealServer will use HTTP for metafiles that point to RealServer content, and for HTML pages that it serves (such as the Web-based RealSystem Administrator). It may also be used to deliver clips to clients that are located behind firewalls. Within these channels, RealServer uses two other protocols for sending instructions and data: 1. Transport Control Protocol (TCP), for sending commands from the client (such as "start" and "pause") and sending commands from RealServer to clients for specific information (such as the clips' titles). 2. User Datagram Protocol (UDP), for sending actual streamed content. X-Stream TV 66
  • 78. Streaming Media Delivery Methods 1. Delivery Methods There are two main ways that users access and experience media clips: 1. On-demand, as with renting a video at a 24-hour video store, a clip is available to a given user whenever she wants it. The user can fast-forward, rewind, or pause the clip, and MediaServer will send the right part of it. This type of clip is prerecorded or preassembled. 2. Live, as with a live telecast of the Olympic Games, a user can tune in to the action that is happening at any given time. Note that a user can not fast- forward or rewind through the clip, because the event is happening in real time. Of course, the delivery of content as a live event requires an actual live event, and it's possible only if you or the content creator have the software and hardware needed to capture the content and convert it to a media format that MediaServer can broadcast. There's also a third, less common method, which uses on-demand clips but delivers them as if they were live: 3. Simulated live: Just as television broadcasts sometimes record live events and then broadcast them later, such as Olympic sports that wouldn't be seen live everywhere because of time-zone differences, simulated live broadcasts take prerecorded events and broadcast them as live ones. Thus, although the content is prerecorded, users view the events as if they were live. 2. Choosing a Delivery Method Once you've determined how you want the user to experience a given clip (on- demand or live) 1. On-demand: Prerecorded clips are delivered, or streamed, to users upon request. A user who clicks a link to an on-demand clip watches the clip from the beginning. The user can fast- forward, rewind, or pause the clip. 2. Live: There are three ways to deliver the clip: unicasting, splitting, or multicasting.  Unicasting: This is the simplest and most popular method of live broadcasting, as it requires little or no configuration.  Splitting: Splitting is the term used to describe how one MediaServer can share its live media streams with other MediaServers. Clients connect to these other RealServers, called splitters, rather than to the main MediaServer where the streams originate. Splitting reduces the traffic load on the source MediaServer, enabling it to distribute other broadcasts simultaneously.  Multicasting: Multicasting is a standardized method for delivering presentations to large numbers of users over a network or the Internet. 3. Simulated Live The same delivery options are available as for live broadcasting: unicasting, splitting, and multicasting.The only difference is that, with simulated live broadcasting, the event has already been recorded, and no connection to a production tool or encoder is needed. Real –Time Streaming Protocol The main protocol that is used in Streaming is RTSP Protocol. Real-time Streaming Protocol is an application-level protocol that aims to provide a robust protocol for streaming multimedia in one-to-many applications over unicast and multicast, X-Stream TV 67
  • 79. and to support interoperability between clients and servers from different vendors. RTSP is considered more of a framework than a protocol. RTSP is designed to work on top of RTP to both control and deliver real-time content. How does RTSP Work? RTSP takes advantage of streaming which breaks data into packets sized according to the bandwidth available between client and server. When the client has received enough packets, the user's software can be playing one packet, decompressing another, and downloading the third. This enables the user to listen or view the real-time file almost immediately, and without downloading the entire media file. This applies to live data feeds as well as stored clips. Functions of RTSP • Provides for on-demand access of multimedia items such as stored real-time audio/video files, live real-time feeds, or stored non-real-time items. • Allows interoperability between client-server multimedia products from multiple vendors. • Provides for control and delivery of real-time media and associated events between a media server and large numbers of media clients. • Addresses key concerns of Internet content-providers and users - quality of service, efficiency of delivery, rights management, and measurement. It also provides a underpinning for developing the richest possible streaming multimedia applications. An example of how RTSP works with other protocols is shown below. Differences from HTTP • An RTSP server needs to maintain state by default in almost all case. • Both an RTSP server and client can issue requests. • The Request-URI always contains the absolute URI RTSP Data Packet Formats RealServer uses one of two packet formats for sending media data to an RTSP client: • Standard Real Time Transport Protocol, RTP • RealNetworks’ Real Data Transport, RDT RTSP Methods Method Description Options Get available methods SETUP Establish transport Change description of ANNOUNCE media object Get description of DESCRIBE media object X-Stream TV 68
  • 80. Start playback, PLAY reposition RECORD Start recording Redirect client to new REDIRECT server Halt delivery, but keep PAUSE state Device or encoding SET-PARAMETER control TEARDOWN Remove state RTSP Operation Putting all the methods together, to send a control request, the client constructs a line consisting of the method, the request URL, and the protocol version number. Then, the client includes a general header, a request header and possibly an entity header, as for the http protocol. This is sent to the server, which executes the request if possible. It then returns a response containing a status-line and general response and entity headers. The status line contains the protocol version, the numeric status code, and a textual description. The media streams are left unspecified by RTSP. These could be RTP streams, or any other form of media transmission. RTSP only specifies the control and its up to the client and server software to maintain the mapping between the control channel and the media streams. A key concept in RTSP is the notion of a session. RTSP works by first requesting a presentation to be started by a server, receiving in return a session identifier which it then uses in all subsequent controls. Eventually, the client can request the teardown of session, which releases the associated resources. The session identifier represents the shared state between the client and server. If the state is lost, for example through one of the machines being rebooted, then the protocol relies on the transport of the media stopping automatically, eg. through not receiving RTCP messages if using RTP, or the implementation using the GET_PARAMETER method below as a keep-alive. The control requests and responses may be sent over either TCP or UDP. Since the order of the requests matters, the requests are sequenced, so if any requests are lost, they must be retransmitted. Using UDP thus requires the construction of retransmission mechanisms, so there are very few occasions when the application can get away with using UDP. The most obvious additions to the request header fields are a Cseq field to contain the sequence numbers of requests generated by the client, and a Session field to both the request and response headers to identify the session. Session identifiers are generated in response to a SETUP request, and must be used in all stateful methods. The Transport field allows the X-Stream TV 69
  • 81. client and server to negotiate and set parameters for the sending of the media stream. In particular, it allows the client and server to set ports and multicast addresses for the RTP streams. X-Stream TV 70

×