A Free Software Streaming-Video Application based on MMTP

A <strong>Free</strong> <strong>Software</strong> <strong>Streaming</strong>-<strong>Video</strong> <strong>Application</strong> <strong>based</strong> onMMTPDouglas Teixeira and Luiz MagalhãesCentro Tecnológico, Escola de Engenharia – Universidade Federal Fluminense (UFF)Rua Passo da Pátria, 156 – Bloco D – São Domingos – CEP: 24.210-240Niterói, RJ – Brasil{vidal, schara}@midiacom.uff.brAbstractThere are many streaming video protocols, but most are proprietary, and while theclient is free, the server is not. The proprietary nature of the protocol also precludesinvestigation on its congestion control mechanism, which is fundamental for the wellbeing of a best-effort network. In this work we present a client-server streaming videoapplication that bases its transport on MMTP, the Multimedia Multiplexing TransportProtocol. The rate-<strong>based</strong> nature of streaming video is a good match for the rate-<strong>based</strong>MMTP, and a prototype is used to validate our model.1. Introduction and Related WorkThe work presented in the paper is part of a larger project on Interactive Televisionwithin the free-software initiative funded by the Brazilian Government. There are threemajor lines of work on the Interactive Television Group (Midiacom Lab) atUniversidade Federal Fluminense. The first is the definition of a framework forinteractivity[1]. The second is the study of transport protocols[2] for communication,and the third is the formal definition and testing of those protocols[3]. The first spin-offof the project is a client-server video-streaming application. In this work we begin theformal definition of the Multimedia Multiplexing Transport Protocol, MMTP, theprotocol used as the basis for our video-streaming application. MMTP is describedthrough state machines, which we intend to use to generate a description that can beformally validated. A further step is to use this description to generate the actual codefor the protocol through a description compiler. At this stage, the code is still handproducedfrom a high-level protocol definition.<strong>Video</strong> streaming is an interesting problem because the most widely usedtransport protocols are so badly suited for it. A video stream does not require the fullreliability offered by TCP. In fact, video streaming as done daily in open television,cable and satellite has no reliability at all, and occasional glitches are well tolerated by

the receiving parties 1 . Moreover, TCP’s retransmission mechanism to implementreliability and its requirement of in-order delivery introduces too much jitter to be usedin streaming. On the other hand, the bare-bones approach, which is to stream framesusing UDP, requires that each video-streaming application has to build its ownbuffering and flow control, and the absence of congestion control can wreak havoc withthe network.The first approaches to video streaming were to build flow (and sometimescongestion) control over UDP. The growing availability of high-bandwidth access in thelast mile meant that a growing segment of users could access richer content, and theimportance of video streaming grew. The economic model pursued by companies thatdeveloped video streaming was to freely distribute the client application (sometimescharging a premium for better/more sophisticated clients), while charging for theservers. The proprietary nature of the application level streaming protocols made usershave several pieces of software, each one for the specific standard used by the providerof the media the user was interested in.A free client/server streaming video application option can fulfill similar needsas the free operating system and free “office” applications initiatives. Remote learningis an example where live and pre-recorded classes can be streamed to students and byitself can justify the project. Our project differs from other free streaming videoinitiatives such as MPEG4IP[4] and <strong>Video</strong>LAN[5] in that we are specifically interestedin the transport aspects of streaming, and less interested in media coding.It should be pointed out that there is a framework for multimedia transport in theInternet, which is composed by RTP/RTCP[6,7]. The Real-time Transport Protocol canbe thought as an application-level framing protocol, and offers a framework wheredifferent applications can build their own controls as needed/desired. MMTP is morefine-tuned with the transmission of video streams, and has most mechanisms needed byvideo streaming applications without the need for further development.The remainder of the paper is organized as follows: in Section 2 we describebriefly the MMTP; in Section 3 we present our video streaming application; Section 4closes the paper with conclusions and future work.2. MMTPThe Multimedia Multiplexing Transport Protocol was originally designed as a mobilityawaretransport protocol, part of a suite of transport protocols belonging to a frameworkthat simplify mobility by requiring no external agents (as it is the case in Mobile IP),and that are able to deal with the higher bit error rate found in wireless links. Allprotocols in the suite share the characteristic of being rate-<strong>based</strong>. Mobility is achievedby dynamically adding and deleting sub-channels. A sub-channel is an end-to-end pathwith at least one unique end-point, characterized by an IP address. The assumption isthat a mobile host will potentially have many interfaces, or a single interface that willacquire different IP addresses as the host moves. The novel aspect of the protocol is its1 Compressed digital content as we use today is naturally less failure tolerant due to frameinterdependence, but can be made more resilient by adding redundancy in the coding process.

multiplexing characteristics, where not only a mobile host can have multiple activeinterfaces (with a different IP address in each interface), but a single flow can be sent(or received) simultaneously through all active interfaces (each defining a sub-channel).MMTP is a real time protocol for multimedia content, aware of frame deadlinesand differing priorities that are assigned to different frames. Because it is wasteful ofnetwork resources to transmit a frame that will arrive past its deadline, frames thatcannot arrive on time for display will not be transmitted. In the same token, framestagged with higher priorities are transmitted ahead of lower priority frames. Theexistence of lower priority frames enqueued means that not enough bandwidth isavailable for transmission at full source rate, and lower priority frames will be droppedahead of higher priority frames. The application has the task of setting frame priorities,<strong>based</strong> on its content, informing MMTP when the frame is sent. For instance, a MPEG I-frame should get a higher priority than a P-frame. MMTP provides the mechanismwhere the application can select different treatment of transmitted frames. It rests on theapplication to tag its traffic the best way, that is, to choose the policy it will use. It mayhave a MJPEG source, where each frame is of equal importance, and tag the sent framesaccordingly. On the other hand, it may choose to alternate between priorities, so in theevent MMTP has to drop frames for lack of bandwidth, the probability of twoconsecutive frames being dropped is lowered. The assumption is that the applicationknows its content, and it is better to leave the decision of what should be dropped in thecase the need arises to it.As a result of the reverse multiplexing, the protocol can offer to the applicationlayer a Channel abstraction. The application won't be aware of the use of multiple linksand will deal with the abstraction through the protocol interface. This architecture willalso require a link-layer-aware system entity responsible for finding when newlydetected links acquire an IP address (or vice-versa, when an address is lost), andnotifying MMTP of those changes in link-layer availability. This entity is called theLocal Link Manager (LLM). The Channel will handle multiple SubChannels, each onereading the frames from the protocol single queue and sending it using lower layer (IP)services.3. <strong>Streaming</strong> video applicationTo stream a stored video file using MMTP it has to be parsed into frames, and thoseframes fed to MMTP with their deadlines. We decided to use as a parser (and player)the Berkeley MPEG tools player [12], which is an open source video player that worksunder Linux.The base of our work is the Berkley video player software developed by theBerkley MPEG Tools team [10]. Basically, it is a set of C programs working with someX11 libraries to create an interactive, graphical interface for the playback of mpeg files.The next issue treated was the transport over the Internet using the MMTP. In [2] it isexplained the available structures in the MMTP for the data encapsulation. However,none work has been done surrounding the delivery of rate <strong>based</strong> streaming video datawith distinct priorities. At last, the third issue treated was the creation of the parsingapplication that sends MPEG frames in constants rates. Furthermore, before we start to

detail the application’s functions, at this point it becomes necessary to make a brieflyexplanation about MPEG files.3.1 <strong>Application</strong> general structureThe user software is composed by four executable files, each one running a distinctsystem process, two in the sending terminal and the other two in the receiving one:Parser and Sender are the former, and Receiver and Mpeg_play are the other two.Being yet only a prototype, the software management is not intuitive for theinexperienced user. We will now explain how they interact:First, in the receiver terminal, the Mpeg_play must be called, this means that wewill have a process running and wainting. Then the Receiver is started, thereby anotherwaiting process will be in standby in the terminal. Now, the sending terminal must bestarted. The first process to be called is the Sender, after that the Receiver process mustanswer because of the MMTP handshake process. After that, the Parser process isstarted with the movie file name filled in the command line; then streaming processbegins. The Parser program sends the mpeg frames, through a local UDP pipe, to theSender. The Sender will encapsulate those mpeg frames in a MMTP packet and willsend them through the Internet to the Receiver process, running in the other terminal.The Receiver retrieves the frames in the correct order and delivers them to theMpeg_play process, through another UDP local pipe. The frames are exhibited by thetime they arrive in the receiver terminal due to the minimal processing time expended inthe local pipe. The process is illustrated in the figure above:Parser (local UDP pipe) Sender (MMTP) Receiver (local UDP pipe) Mpeg_playMpeg videoframesMMTP control packets anddataMpeg videoframsMMTP control packetsSecond configuration: mpegvideo frames transmission throughUDP, without MMTP.Inter-process communicationOne of the reasons for the entire application be constructed in that way was tokeep the edge processes (Parser and Mpeg_play) independents. In that way, we couldhave the same application transmitting mpeg frames only over UDP (without theMMTP protocol encapsulation). Therefore we were able to compare the MMTPprotocol performance face none application-level-transport protocol.

The actual state of the application demands attention from the user. They mustbe started in the way it was presented: First, receiving terminal: Mpeg_play andReceiver. Then, the sending terminal: Sender and Parser.Another important issue remains over the implementation of the MMTPprotocol. Three distinct main programs compose the original MMTP protocol package:source, sender and receiver [2]. Our application did not require the source program,which was formerly built for testing purposes. The present state of the MMTP protocolrequires a configuration file for each running program, the “params.txt”. It is a text filewhere the user must correctly fill in some information. Some of them, like initialMMTP rate and network latency, may be acquired over the network through probingprocesses (this is currently under work, in the present state they must be filled in by theuser) other may not (like machine addresses and ports).We choose to keep this characteristic of the protocol and we applied the sameidea in our two extra programs. Therefore all the four application programs have, eachone, a configuration file. Using the “params.txt” file for the Parser program, we areable to choose the frame rate and the transmission protocol (this means the presence ornot of the MMTP protocol).3.2 The playback program Mpeg_playThe basic structure is <strong>based</strong> on the client-server paradigm. One terminal waits requestscoming from the network and another terminal must send the request to start thestreaming. In that way, we will have a database of mpeg movies in the server and aclient receiving them and performing the playback.Our user level client is an adjustment of the original software created by [10] formpeg files playback only. Instead of reading a file from the hard disk, ourimplementation reads blocks from a local UDP pipe between the player and the receivertransport application. Those blocks must be well-defined frames from the original file;otherwise the player will not recognize them and will stop the execution. Thoseadjustments in the original program were made in a function called “get_more_data”,which uses another function called “pure_get_more_data”. They are located in thearchive “readfile.c”.The “get_more_data” function does the reading of the mpeg file from the diskand loads the memory buffer with it. Besides, it analyses the presence of system calls inthe bitstream to return the presence or not of multiplexed audio with the video. If audiois detected, it calls the “read_sys” function to separate it from the video stream. Thisproceeding does only the disjointing of the audio stream, without processing it. In fact,the present state of the Berkley mpeg player is not processing audio. Therefore, thestudy of the “read_sys” function is now unnecessary. Continuing, if no audio isdetected, the “get_more_data” function calls the “pure_get_more_data” function toread only video stream.The exhibition of the frames is done by a function called “correct_underflow”(located in the “utils.c” archive of the original program). This function is called severaltimes during the video decoding and, therefore, it uses the two functions describedabove. Every time the memory buffer needs to be loaded, the program calls“correct_underflow”. The next proceeding made in the original program was thereplacement of the C function fread to a MMTP function called “UdpRecv” in the

“get_more_data” and in the “pure_get_more_data” functions. The “UdpRecv” functionis specified in the file “net.c” of the MMTP protocol set of archives: int UdpRecv(unsigned char * buf, int len, int interface). The required parameters are:• char *buf pointer to a local buffer where data from socket will be stored;• int len number of bytes to be read from socket;• int interface number, starting from 0, which identifies the selected networkinterface to be connect to the socket. Due to the capability of the MMTPfunction to work with multiple interfaces, this function receives this parameterspecified in the text file “params.txt”. If only one interface is being used, thisnumber must be 0. Using the UdpRecv our playback application will receive data coming from thetransport application through local pipe. Intuitively, the UdpRecv function in the playerprogram will only have the loopback interface specified in the parameters file, beingrepresented by 0 in the function “interface” parameter. This function is very useful fortwo reasons: reduces the number of input parameters of the original recvfrom C functionand allows the user to handles multiple interfaces in a very easy way.Finally, the player application loads its video buffer directly from UdpRecv.Keeping the rest of the original Berkley program, it will perform the playback normally(decoding and exhibiting) as it receives from the transport application, since data isdelivery correctly (well-defined frames in order).3.3 Transport: Linking the client and server applications to the MMTP protocolThe UdpRecv function from the MMTP library, used in our client and serverapplications, uses another two MMTP set of archives: “defs.h” and “params.c”. Thefirst one works with structures and parameters needed by the UDP protocol semantics.A good reference (and by the way the best in my opinion) for the BSD-UNIXnetworking functions can be found in [14]. The second one specifies the “ReadParams”function, which reads the necessary parameters from the “params.txt” text file inexecution time. In this file it must be written, in the correct order, some necessaryinformation for the communication process. There is work in progress to reduce the userknowledge to fill the file (such as initial interface transmission rate).This subsection will explain our implementations made in the original protocolfor our video streaming purposes.Intuitively, some work had to be made in the protocol for the transport of mpegbit stream instead of assorted data. At the server side, we have a running program: theserver. A specific code was included in the original protocol server program to interactwith the parser program. Its purpose was, firstly, to analyze the header bits of eachreceived frame to identify the type of frame (I, P or B). After that, our implementationshould “tell” to the MMTP protocol each frame priority (0, 1 or 2, highest to lowestpriority), through the encapsulation process. It is clear that I frames must receive highestpriority, in that way those will be delivered with guarantee. The MMTP supplies anintermediate priority where the packets will be delivered if the network offers areasonable throughput for the packets deadlines. We can set P frames to this priority.The B frames will not receive any kind of guarantee treatment (they will have nopriority) the same way UDP works when none kind of user level treatment is present. Inthat way, the sender application gives to each frame its specific priority in the MMTP

packet structure. The parser program specifies the type of frame during the reading ofthe video bit streams from the disk. Besides, it is necessary to guarantee the highestpriority to the first frame, otherwise if it is dropped, the playback will not even start.Last, by the client side we have the “receiver.c” program running. Here, theMMTP code was modified in the “process_data” function, so that it could be able torebuild the frame when all its related packets were already received and stored in thearriving buffer. When the frame is complete, the receiver program delivers it, throughlocal UDP pipe, to the video playback application “mpeg_play”.3.4 The frame server program “Parser”The parser program, which receives the same name, was entirely written by us.It works through the following steps: 1 st the mpeg file is read from the local source(disk, video-camera, etc); 2 nd the header of the mpeg file is sent through local UDP pipeby the MMTP UdpSend function to the sender application; 3 rd . does the parsing process,breaking the bit streams in distinct video frames; 4 th . send those frames throughUdpSend function to the sender application.The UdpSend is similar to the UdpRecv function. Its specification is placed in thesame archive “net.c“ and requires the same other functions described above forUdpRecv: int UdpSend (unsigned char *buf, int len, int interface).The server application does not the video playback, it only does the parsing and thesending proceedings. It is still necessary to say that the parser does the breaking processof the video bit streams reading information present in the same video file. Besides thetype of frame, the parser program also informs the sender program whether it is astarting frame or not and its timestamp. The sending of the timestamp is essential for theMMTP to determine the packet deadline and to deliver them correctly.4. Conclusions and Future WorkThe first application test was done comparing it with UDP protocol. Wetransmitted a 416K video file of 100 frames through direct link between the parser andthe mpeg_player (UDP) and with the MMTP suite, measuring the number of deliveredpackets for different rates, shown above:Taxa (bps) UDP (received frames) MMTP (received frames)9600 3 119200 6 738400 14 1257600 14 3078800 57 60115200 54 871M 99 99

At higher taxes, MMTP works exactly as UDP protocol, as it was expected.However, with lower taxes MMTP shows better performance. It is still necessary to saythat this test was done without any kind of traffic, which would decrease drastically thenumber of delivered packets by UDP.We now are improving a test bed with a sub-network working with trafficgenerator for the next tests. Another work is to create the same application using theRTP (Real Time Protocol) [6] instead of the MMTP. A related work was done in agraduation work [15] with better results for the MMTP, when comparing both protocols.However, they transmitted only assorted data (not video frames with priority levels) andwithout any traffic generator.A free video streaming application has many interesting uses. MMTP is wellsuited as the transport protocol for such application, even when used in a differentenvironment that it was designed to work. By creating a tool to generate formal protocoldefinitions, we expect to make future changes to existing protocols easier, and be able todesign protocols for specific applications, without having to make the application fit theexisting protocols.5. References[1] RODRIGUES, L. M., ANTONACCI, M. J., RODRIGUES, Rogério Ferreira,MUCHALUAT-SAADE, D. C., SOARES, Luiz Fernando Gomes “Improving SMIL with NCMFacilities. Multimedia Tools And <strong>Application</strong>s”. Amsterdam, Holanda: , v.16, n.1, p.29 - 54,2002.[2] L. Magalhaes and R. Kravets, “MMTP: Multimedia Multiplexing Transport Protocol” TheFirst Workshop on Data Communications in Latin America and the Caribbean SIGCOMM-LA2001), 2001.[3] SANCHEZ, M. L. D., BASTOS, Silvino, “Modelling Real Time Systems From ObjectOriented Models” In: SBRC - Workshop de Sistemas de Tempo-Real, 2002, Buzios. SBRC -Workshop de Sistemas de Tempo-Real. , 2002. v.1. p.1 - 8[4] MPEG4IP: http://mpeg4ip.sourceforge.net[5] <strong>Video</strong>LAN: http://www.videolan.org[6] RTP: RFC 3550 'RTP: A Transport Protocol for Real-Time <strong>Application</strong>s '[7] RTCP: RFC 3605 Real Time Control Protocol (RTCP) attribute in Session DescriptionProtocol (SDP).[8] L. Magalhaes and R. Kravets, “Transport Level Mechanisms for Bandwidth Aggregation onMobile Hosts” The 9th International Conference on Network Protocols (ICNP 2001), 2001.[9] L. Magalhaes and R. Kravets, “End-to-End Inverse Multiplexing for Mobile Hosts”, The19th Brazilian Symposium on Computer Networks, Florianopolis, Brazil, 2001[10] “Berkley MPEG tools”, site: < http://bmrc.berkeley.edu/frame/research/mpeg/>. Feb 2004.[11] Site: MPEG - Moving Picture Experts Group: , Feb 2004.[12] HALSALL, Fred. Multimedia Communications (<strong>Application</strong>s, Networks, Protocols andStandards).Addison – Wesley, 1 st edition.[13] T. SIKORA, “MPEG-1 and MPEG-2 digital video coding standards.” Site:http://wwwam.hhi.de/mpeg-video/papers/sikora/mpeg1_2/mpeg1_2.htm, Dec 2003.[14] STEVENS, W.Richard. Unix Network Programming: Interprocess Communications withAdvanced Programming in the UNIX Environment. Editora: Prentice Hall PTR.[15] Peres and Leite, Francisco de Assis Campos and Julio Cesar Costa. Análise do protocolo detransporte RTP e comparação com o MMTP. 2º semester, 2004. Final Graduation Work as partof the conclusion of Telecommunications Engineering Course, Universidade FederalFluminense, RJ - Brasil.