A Free Software Streaming-Video Application based on MMTP
A Free Software Streaming-Video Application based on MMTP
A Free Software Streaming-Video Application based on MMTP
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
the receiving parties 1 . Moreover, TCP’s retransmissi<strong>on</strong> mechanism to implementreliability and its requirement of in-order delivery introduces too much jitter to be usedin streaming. On the other hand, the bare-b<strong>on</strong>es approach, which is to stream framesusing UDP, requires that each video-streaming applicati<strong>on</strong> has to build its ownbuffering and flow c<strong>on</strong>trol, and the absence of c<strong>on</strong>gesti<strong>on</strong> c<strong>on</strong>trol can wreak havoc withthe network.The first approaches to video streaming were to build flow (and sometimesc<strong>on</strong>gesti<strong>on</strong>) c<strong>on</strong>trol over UDP. The growing availability of high-bandwidth access in thelast mile meant that a growing segment of users could access richer c<strong>on</strong>tent, and theimportance of video streaming grew. The ec<strong>on</strong>omic model pursued by companies thatdeveloped video streaming was to freely distribute the client applicati<strong>on</strong> (sometimescharging a premium for better/more sophisticated clients), while charging for theservers. The proprietary nature of the applicati<strong>on</strong> level streaming protocols made usershave several pieces of software, each <strong>on</strong>e for the specific standard used by the providerof the media the user was interested in.A free client/server streaming video applicati<strong>on</strong> opti<strong>on</strong> can fulfill similar needsas the free operating system and free “office” applicati<strong>on</strong>s 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 <str<strong>on</strong>g>Video</str<strong>on</strong>g>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 applicati<strong>on</strong>-level framing protocol, and offers a framework wheredifferent applicati<strong>on</strong>s can build their own c<strong>on</strong>trols as needed/desired. <strong>MMTP</strong> is morefine-tuned with the transmissi<strong>on</strong> of video streams, and has most mechanisms needed byvideo streaming applicati<strong>on</strong>s without the need for further development.The remainder of the paper is organized as follows: in Secti<strong>on</strong> 2 we describebriefly the <strong>MMTP</strong>; in Secti<strong>on</strong> 3 we present our video streaming applicati<strong>on</strong>; Secti<strong>on</strong> 4closes the paper with c<strong>on</strong>clusi<strong>on</strong>s and future work.2. <strong>MMTP</strong>The Multimedia Multiplexing Transport Protocol was originally designed as a mobilityawaretransport protocol, part of a suite of transport protocols bel<strong>on</strong>ging 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-<str<strong>on</strong>g>based</str<strong>on</strong>g>. Mobility is achievedby dynamically adding and deleting sub-channels. A sub-channel is an end-to-end pathwith at least <strong>on</strong>e unique end-point, characterized by an IP address. The assumpti<strong>on</strong> 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 c<strong>on</strong>tent 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.