rtplib

所属分类:TCP/IP协议栈
开发工具:C/C++
文件大小:92KB
下载次数:597
上传日期:2005-07-31 15:41:10
上 传 者管理员
说明:  comer的RTP/PTCP实现源码,简单明晰,是学习RTP/RTCP的好例子。
(comer RTP/paper, realizing source, the simple clarity is learning RTP/RTCP good example.)

文件列表:
rtplib\rtplib-1.0\compile_linux\Makefile (105780, 2000-06-30)
rtplib\rtplib-1.0\compile_linux (0, 2005-07-31)
rtplib\rtplib-1.0\compile_solaris\Makefile (108596, 2000-06-30)
rtplib\rtplib-1.0\compile_solaris (0, 2005-07-31)
rtplib\rtplib-1.0\frame\frameread.c (5655, 2000-06-29)
rtplib\rtplib-1.0\frame\framereadfragmented.c (5706, 2000-06-29)
rtplib\rtplib-1.0\frame\framereadnonfragmented.c (2358, 2000-06-29)
rtplib\rtplib-1.0\frame (0, 2005-07-31)
rtplib\rtplib-1.0\h\bufpool.h (794, 2000-06-30)
rtplib\rtplib-1.0\h\event.h (3452, 2000-06-30)
rtplib\rtplib-1.0\h\frame.h (1813, 2000-06-30)
rtplib\rtplib-1.0\h\hash.h (2017, 2000-03-01)
rtplib\rtplib-1.0\h\linux.h (451, 2000-06-30)
rtplib\rtplib-1.0\h\packet.h (474, 2000-06-30)
rtplib\rtplib-1.0\h\payload.h (777, 2000-06-30)
rtplib\rtplib-1.0\h\rtcp.h (4701, 2000-06-30)
rtplib\rtplib-1.0\h\rtp.h (11185, 2000-06-30)
rtplib\rtplib-1.0\h\rtplibcommon.h (757, 2000-06-30)
rtplib\rtplib-1.0\h\sample.h (770, 2000-06-30)
rtplib\rtplib-1.0\h\syn.h (5258, 2000-06-30)
rtplib\rtplib-1.0\h\util.h (1212, 2000-06-30)
rtplib\rtplib-1.0\h (0, 2005-07-31)
rtplib\rtplib-1.0\main\main.c (7617, 2000-06-30)
rtplib\rtplib-1.0\main\main.h (187, 2000-03-07)
rtplib\rtplib-1.0\main (0, 2005-07-31)
rtplib\rtplib-1.0\mpadecoder\common.c.patch (2102, 2000-06-30)
rtplib\rtplib-1.0\mpadecoder\musicout.c.patch (16021, 2000-06-30)
rtplib\rtplib-1.0\mpadecoder\out_audio.c (771, 2000-06-30)
rtplib\rtplib-1.0\mpadecoder\upcall.c (3707, 2000-06-30)
rtplib\rtplib-1.0\mpadecoder (0, 2005-07-31)
rtplib\rtplib-1.0\packet\packread.c (2685, 2000-06-29)
rtplib\rtplib-1.0\packet (0, 2005-07-31)
rtplib\rtplib-1.0\rtcp\rtcpapp.c (1161, 2000-06-29)
rtplib\rtplib-1.0\rtcp\rtcpbye.c (1807, 2000-06-29)
rtplib\rtplib-1.0\rtcp\rtcpcname.c (2558, 2000-06-29)
rtplib\rtplib-1.0\rtcp\rtcpcycle.c (6600, 2000-06-29)
rtplib\rtplib-1.0\rtcp\rtcpcyclethreadfcn.c (1634, 2000-06-29)
rtplib\rtplib-1.0\rtcp\rtcpheader.c (1533, 2000-06-29)
rtplib\rtplib-1.0\rtcp\rtcpinterval.c (4092, 2000-06-29)
... ...

RTP Library 1.0 README Description: ------------ This directory contains the code for a library that receives real-time data carried with the Real-Time Transport Protocol (RTP). The code was written to accompany the text: Comer and Stevens, Internetworking With TCP/IP Volume 3: Client-Server Programming and Applications (Linux/POSIX version), Prentice Hall, 2000. The standards for RTP and the RTP Control Protocol (RTCP)are RFCs 1889 and 1890. Also contained in the directory ``main'' is an application that uses the library to play real-time audio streams in various formats. The application contains code to interface with a publicly-available MPEG audio decoder so that it can be used to play MPEG encoded (e.g., ``MP3'') streaming audio. The RTP library and application were developed and tested under Solaris 2.6/x86 and Linux x86 kernel 2.12-20 (RedHat Linux 6.1). Compilation: ------------ This distribution contains two compilation directories: compile_solaris and compile_linux. Use the directory appropriate to your operating system. Before you begin, you must tailor the Makefile for your system. Edit Makefile to reflect the names and locations of required executables (e.g., the C compiler). Then, from the compile_ directory, issue the command ``make depend'' to generate the Makefile dependencies for your system. The Makefile has the following targets, as described in Makefile: # rtplib.o Builds the RTP library # audioplayer Builds audioplayer application without MPEG audio support. # Make sure that MPEG *is not* #defined in ../main/main.c # audioplayer-mpeg Builds the audioplayer application with MPEG audio support. # Make sure that MPEG *is* #defined in ../main/main.c # and that the MPEG player source code is present as # described in ../README. # clean Removes object and executable files # depend Updates Makefile's dependencies Compilation with MPEG Audio Support: ------------------------------------ To use the audioplayer application to play MPEG audio (e.g., MP3) you must obtain the ISO reference MPEG audio decoder source code. To integrate MPEG support follow the instructions below. Note that the MPEG decoding process is computationally intensive. In addition, the reference MPEG decoder used by audioplayer is not very efficient. Due to these two factors, less powerful systems may not be able to decode MPEG audio in real time, resulting in poor audio quality. 1. Download the MPEG decoder source code from http://www.mp3-tech.org/programmer/sources/dist10.tgz. 2. Gunzip and untar the decoder source code. 3. Copy the following files from the MPEG decoder's directory dist10/lsf/decoder to the RTP library's mpadecoder/ directory: common.c common.h decode.c decoder.h huffman.c huffman.h ieeefloat.c ieeefloat.h musicout.c portableio.c portableio.h 4. Copy the directory tables/ and its contents from dist10/lsf/decoder to the RTP library's compile_ directory. The tables/ directory must be present in the working directory when the audioplayer application is to decode MPEG audio. 5. The files common.c and musicout.c must be modified to work with the RTP library. A patch file is provided for each to automatically install the necessary modifications. To patch the file, from the RTP library's mpadecoder/ directory issue the commands: patch musicout.c musticout.c.patch patch common.c common.c.patch 6. Uncomment the line #define MPEG in the RTP library's file main/main.c. 7. Compile the audioplayer application by using the target ``audioplayer-mpeg''. The executable will still be named ``audioplayer''. Audioplayer Application Usage: ------------------------------ The command line usage for the audioplayer application is: audioplayer The sample audioplayer application joins a multicast group and listens for real-time audio data. It will play the first audio stream detected that is in one of its supported formats. When the stream ceases, the player will wait for and play another audio stream. Audioplayer takes two arguments. The arguments are a session address and port number. If the session address is a multicast address, the application will join and listen to that group for data. If unicast, the application will listen for data on the specified port on the local machine. As specified by the standard, the RTP port number must be an even integer. To generate an audio stream you must obtain an application that streams audio using RTP. The Robust Audio Tool, available at www-mice.cs.ucl.ac.uk/multimedia/projects/rat/index.html generates audio in a number of formats including mu-law, A-law, L16, DVI, and DVI4. Livecaster, available at www.live.com streams an MPEG encoded audio file created with another application. Real Jukebox, available from www.real.com can be used to generate MP3 audio files suitable for streaming with LiveCaster. See the applications' respective documentation for instructions on their use. RTP Library Organization: ------------------------- As described in the text, the RTP library is organized into two primary layers, the RTP layer and the synchronization layer. RTP Layer: The RTP layer is responsible for receiving, demultiplexing, and queueing RTP data packets for the streams participating in a particular RTP session. The RTP layer computes and stores the necessary state and statistics for each stream participating in the session. An application using the RTP layer may individually turn on and off RTP data queueing for individual RTP streams. The RTP layer also contains code for RTCP. The RTP layer receives and processes incoming RTCP messages. Data and statistics received via RTCP for a stream are stored in the state for that stream. The RTP layer also is responsible for generating the necessary periodic receiver report messages and detecting timed-out sources. The RTP layer includes three threads that can be started and stopped independently. One to receive and process RTP packets, one to receive and process RTCP packets, and one to periodically generate RTCP receiver reports. The code for the RTP layer is contained in the directories rtp/ and rtcp/. Synchronization Layer: The synchronization layer is built upon the RTP layer and extends the RTP layer's functionality. The synchronization layer provides jitter buffering, computes the relationship between the local system clock and each stream's media clock, performs inter-stream and inter-session synchronization (experimental), and provides three read interfaces that an application may use to read from a real-time stream. The RTP layer provides only a queue of RTP packets ordered by sequence number. The synchronization layer aids an application by extracting data from RTP packet to return in the units required by the application, either fixed-size samples, or frames. The synchronization layer's read interface also aids the application by discarding data whose playback time has already passed and by preventing reading of data whose playback time is too far in the future. Unlike other data streams, real-time data has a temporal aspect. In receiving real-time data, an application may not wish to read a stream at the point immediately after the last data read (such as when reading a file from disk), but at the point in the data stream corresponding to ``now''. The synchronization layer provides this option via each stream's FLUSH flag stored in the stream's state. When set to TRUE, a read will flush all data that corresponds to time before the time at which read is called. In other words, all reads will correspond to ``now''. When false, all reads will return the oldest data that is after the last data read. The synchronization layer read function may operate in a blocking or non-blocking mode. If in non-blocking mode, when there is no data to return (e.g., the queue is empty or the first data in the queue is too new) read will return an error code, otherwise the reading thread is blocked. The three read interfaces are: - Raw packet The raw packet read interface allows an application to extract entire RTP packets with the header intact. Each read returns a single RTP packet. Because the RTP library cannot return a partial packet, it may return a packet in which some of the data's playback time has passed. - Sample The sample read interface aids an application in reading from a stream of fixed-size samples (e.g., PCM). Each read returns the maximum of the number of contiguous samples available in the stream's data queue and the maximum number the application's buffer can hold. The sample read interface always returns a number of samples that is a multiple of the number of stream channels. - Frame The frame read interface attempts to return 1 * number-of-channels frames (i.e., one frame per channel), as defined by the encoding scheme. The frame read interface is the most complex of the three. Reading frames is complex because multiple frame may be packed into a single packet, and a single frame may be fragmented and carried in multiple packets, as described in RFC 1890. Because the format of a frame is encoding dependent, the RTP library cannot know a frame's length, playback duration, or even if a packet starts on a frame boundary or contains a partial frame. To solve this problem, the synchronization layer requires the application to provide four helper functions that return specific information about an RTP packet or frame. These functions determine whether a packet contains whole frames or a frame fragment, the beginning of the frame within a packet (i.e., some encodings, such as MPEG, prepend per-packet data before the beginning of any frames), the frame's duration in media time units, and the frame's length in bytes. Like the packet encoding, the RTP library cannot return a partial frame. Thus, the playback time of some of the data contained in the frame may have already passed. The code for the synchronization layer is contained in the directories synch/, packet/, frame/, and sample/. Documentation: -------------- There is currently no detailed documentation for the individual functions provided by the RTP library. The audioplayer application (in main/main.c and mpadecoder/musicout.c) provides an example of the use of the synchronization layer to read both sample- and frame-oriented real-time streams. The source files for the individual functions contain descriptions of their purposes, parameters, and return values. Known Issues: ------------- * The RTP layer does not correctly handle sequence space wraparound. It is not a problem until after 2^32 - 2^16 packets have been received for a particular stream. * Inter-stream and inter-session synchronization is experimental and not tested. To enable synchronization, uncomment the #define RTPLIB_SYNCHRONIZE in h/rtplibcommon.h. Bug Reporting: -------------- Please report bugs to rtplib@cs.purdue.edu.

近期下载者

相关文件


收藏者