Sunteți pe pagina 1din 18

Fountain Multimedia Broadcasting

First Semester Report Fall Semester 2011

By Aqeel Alhashim Ben Kappel Jassim Alhashim

Prepared to partially fulfill the requirements for ECE401 Department of Electrical and Computer Engineering Colorado State University Fort Collins, Colorado 80523

Project advisor: Dr. J Rockey Lou

Abstract This project focuses on the studies of multimedia broadcasting techniques, algorithms, and efficiencies. The primary focus of the study will be on fountain coding algorithms using current protocols of data transfer over a network. Multimedia broadcasting has recently become a major topic as digital media demand has increased. Also as network speeds increase we will continue to see a move towards more efficient digital multimedia broadcasting methods. Our hypothesis is that fountain coding can be shown to improve speed, efficiency, and increase the number of simultaneous clients streaming from a multimedia source. By coding and testing fountain coding algorithms we will be able to accurately test this hypothesis against current error correction algorithms. Our current progress leaves us with a multimedia-streaming program that we will use to test the efficiency and possibilities of fountain code algorithms.

ii

TABLE OF CONTENTS Title Abstract Table of Contents List of Figures and Tables I. Introduction II. Summary of Previous Work III. Previous Studies of Fountain Code IV. Summary of Current Work V. Future Work VI. Conclusion References Appendix A - Abbreviations Appendix B Budget i ii iii iv 1 2 5 7 9 11 12 13 14

iii

LIST OF FIGURES Figure 1 - TCP/IP packet transmission Figure 2 - UDP with forward error correction code Figure 3 - Example of Fountain Code 3 4 5

iv

Chapter I: Introduction

Multimedia broadcasting, in the past few years, has had a drastic increase in demand by everyday consumers. A study done by the Pew Research Center in 2010 showed that seven in ten Internet users have used the Internet for downloading or streaming video. It is also obvious that video uploads are popular. The website YouTube is one of the largest sources of user shared media and is increasing in users that download and upload everyday. Multimedia broadcasting has also seen an increase in digital multimedia subscription services. Services such as Netflix, Hulu, Comcast, and Blockbuster have increased the demand for streaming movies to a clients home. This move towards a digital rental service has increased the amount of data that is transferred over networks. Current protocol methods such as user datagram protocol and transmission control protocol are the most commonly used, and each has their advantages and disadvantages. TCP/IP has an acknowledgement packet to ensure error free transmissions, but is slow. UDP is known for its speed, but UDP is also very unreliable. Fountain coding uses user datagram protocol combined with an error correction algorithm that is purely decoded on the receiver side. This uses the speed of UDP mixed with a high reliability to reduce the problems with common UDP and TCP/IP protocols.

Chapter II: Previous and Current Network Protocols

Current network protocols work correctly, however there are some problems that need to be addressed as data transfer size is growing and the number of clients receiving the data is increasing as well. We currently have two major methods of streaming video: User Datagram Protocol (UDP) Transmission Control Protocol (TCP)

Both of these methods are currently used for different types of applications. First we will discuss TCP/IP and some applications that use this type of network transmission. TCP/IP applications include, but are not limited to: E-Mail Internet Browsers Computer IP addresses

TCP/IP is a great protocol for reliability. It uses an acknowledgement signal from the receiver back to the sender to confirm that every packet has been received before sending the next packet in line. While very efficient for small files, it the server is sending large files and the network has a high error probability this will slow the transfer speed significantly. Below in Figure 1 we can see a basic picture of how the TCP/IP protocol sends and receives packets.

Figure 1: TCP/IP packet transmission Thus we can see that TCP/IP is great for small files and networks that have little errors present. Due to high efficiency, TCP/IP is one of the most commonly used protocols on the Internet right now. The second major type of network transmission protocol is the user datagram protocol or UDP for short. UDP is typically used where speed is essential. This method of sending data will not wait for an acknowledgement signal back and will keep sending packets regardless of whether the receiver has actually received them. Current methods of using UDP often use an extra error correction code attached to each packet so that the receiver can decode the original data if a packet is lost in transmission. Figure 2 below shows a method of attaching error correction code to a UDP packet. This method is called forward error correction or FEC for short.

Figure 2: UDP with forward error correction code While this method of forward error correction eliminates the problem of reliability with UDP, it has a downside. The problem with UDP with FEC is that there is a high amount of redundancy. We can see above in Figure 2 that each packet has an error correction code added to the original data to allow the receiver to correct any missing packets. This turns a small file transfer into a much larger one and increases latency of this packet on the network.

Chapter III: Previous Studies of Fountain Code

Fountain code is a type of error correction algorithm using UDP transmission protocol. Few studies have been done about this type of error correction, as it is relatively new. Fountain code is a way to correct packet loss over a network. The basic theory behind this code is that it takes in packets of source data, encodes this data into an infinite number of packets. The server then sends out these packets randomly to a receiver or multiple receivers. The receiving end gathers as many packets as it needs to decode back to the original source data. The number of packets needed to decode the encoded data on the receiver side is larger then the original amount of packets, so a feedback transmission is needed to let the server know when to send more encoded packets. Shown below in Figure 3 is a basic diagram that explains, at a higher level, a basic form of fountain code.

Figure 3: Example of Fountain Code

From a paper (MacKay) written in 2005, there are three main types of fountain code: Random Linear Fountain LT Code Raptor Code

From these three types of code, Raptor code is the most efficient. Raptor code uses two types of LT code to make the fountain code more efficient. All of these codes use a generating matrix to encode the original source data. From this on the receiving end the r encoded packets can be combined with the inverse of the generating matrix to decode the original source data. Common fountain code encoding and decoding uses an algorithm based off of a bitwise sum, modulo 2. This can also be seen as an algorithm based off of a bitwise exclusive or, Boolean function. We will study further, how fountain code is implemented into the server client program next semester.

Chapter IV: Summary of Current Work

Our project is so big and it has a lot of work to be done with. However, until now we have done the most important part in our project, which is sender or server and receiver, client. Our project depends on these two programs because we are going to use them for implement the idea of fountain code. Im going to clarify the function of both programs in the next sections. Sender: First thing the sender would do is; Takes the original data we are using video as the original data- that we want to send and read it as a binary file 0/1. We make sender read the data as a binary, so it would be valid to implement the fountain code with them. Split the data into a certain amount of packages. These packages would have certain amount of size, for example one kilobyte for every package. The size is not a big of deal, since its not exceeding the size of sender functionality. Therefore, the send function still has the ability to send this amount of size bytes. Sender will send one package at a time, and then it would what for certain unit of time to send the next packet. Probably, we wont need this feature in the future, due to the fact that we are going to send the source data or the original data from one machine to another to test the program. Receiver:

The receiver will receive the packages from our sender. We are using UDP, which unreliable way of sending data across Internet. Receiver will receive one packet at a time and it will buffer the data in the current memory of the receiver machine. Before that, receiver will create a new file to store the data that got buffered from the sender and store it in the hard disk of receiver machine. In that way, we could use the buffer to buffer the next coming packet.

Receiver will buffer each packet it got received and write it as a binary file to the file that has been created.

What the receiver would do after a certain amount of time, it will start playing the data that has been sent, and either data was video or audio, before the whole data is received. It supposed to be real time when the receiver plays the data.

Chapter V: Future Work

By the end of this semester and after we have successfully accomplished the goals that we have set for this semester which were building UDP streaming multimedia program which has many assignments under that main part like using C programming language to design a sender (server) and receiver (client) programs in order to transmit the data through the network, splitting our data into small multiple packages, and using UDP as transmitter on our program. Then we tested our UDP streaming program and after we had tested our program we find out that it has some problems like the quality of the data and that our sender program sending more packages than we need. As result of that we will need to set other goals in addition to the goals that we have already set in the timeline and these goals will be the adding a feedback to the receiver side and encoding/decoding. Now we will present our future goals individually and in more details. First goal is to implement a feedback to our receiver side in order to inform the sender to stop sending more packages when the receiver has received the required amount to be able to decode them and get the original data back and by that we will solve the inefficiency of being sending more data than needed. Next goal will be about increasing the quality of the data being received by the receiver and will be applied by using the encoding/decoding (image frame) which will be dividing the video in multiple images and encoding them in the sender side then transmitting them through the UDP. After that the receiver side received the encoded packages of the images frame, the receiver will decode them and by that will get the

multiple images of the video back. So now we could play the video (as we know that the video is multiple images that being run at specific speed (image/second) in order to create the video) and by using this method we could increase the quality of the video. This encoding/decoding (image frame) method will replace the splitting video in some parts method. Next goal is implementing the fountain code to our UDP program and that will be in multiple steps. First step is writing the fountain code using the C program language, and this program will have the mixing matrix in order to encoding the source data and decoding the encoded data to get the original data after the transmission between the sender and receiver. The sender will have the fountain code, which will encode the data using the mixing matrix; on the other hand the receiver will have the fountain code, which will decode the encoded packages using the inverse of the mixing matrix, which will give us the original packages back. Second step will be using the feedback to inform the sender that the receiver side had received enough packages to decode them and get the original packages back and by that we will increase the efficiency by not sending more packages than needed. After we have done with implementing the fountain code to our UDP program, now we could move to the next goal which will be testing and research in order to find out if our project has solved the problem and that will be through making some testing in our program to find out how well our program is working, then in the research part we could compare our results with other projects and researches about this topic to find out how efficient our program and if we have accomplished the goal of our project.

10

Chapter VI: Conclusion

Streaming media has increased in demand, size, and speed as technology has advanced. The current protocol methods for streaming media efficiently are a significant bottleneck in the speed of streaming media. TCP and UDP methods have significant problems with efficiency and speed, and using UDP with fountain code algorithms is a good way to eliminate these problems. This semester we have finished a UDP streaming program, which is the base for testing the fountain code error correction. Once we start testing fountain code we will be able to see if our hypothesis is confirmed or refuted. So far based on looking at past studies in fountain code, it is evident that fountain code can be more efficient. We will devote all of next semester to researching fountain code.

11

References

Kristen Purcell, The State of Online Video, Pew Internet & American Life Project, Jun 3, 2010, http://pewinternet.org/Reports/2010/State-of-Online-Video.aspx, Dec 7, 2010.

MacKay, D.J.C.; , "Fountain codes," Communications, IEE Proceedings- , vol.152, no.6, pp. 1062- 1068, 9 Dec. 2005 doi: 10.1049/ip-com:20050237

Figure 1 - htp://www.tutorialsweb.com/networking/tcp-ip/udp-tcp.htm Figure 2 - http://www.freepatentsonline.com/6675340.html Figure 3 - http://www1.tlc.polito.it/sas-ipl/research_digital_fountains.php

12

Appendix A Abbreviations UDP User Datagram Protocol TCP Transmission Control Protocol LT code Luby Transform code

13

Appendix B - Budget We have a budget of three hundred dollars. Fortunately we can do all of our programming on our personal computers. We will need some of the budget to print out materials for E-Day.

14

S-ar putea să vă placă și