A Free Software Streaming-Video Application based on MMTP

More documents

Recommendations

Info

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
Page 1 and 2: A Free Sof
Page 3: multiplexing characteristics, where
Page 7 and 8: packet structure. The parser progra

A Free Software Streaming-Video Application based on MMTP

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?