Free sr rtp software for linux

The SR-RTP library enables real-time streaming applications (such as streaming MPEG-4 video) to cope with packet loss, variable bandwidth, and variable delay on the Internet.

It provides a means for selective retransmission of lost packets in a fashion that is backwards-compatible with RTP. Additionally, it provides integration with the Congestion Manager to provide a system capable of performing TCP- friendly streaming of real-time data.

Installation:

The `configure shell script attempts to guess correct values for various system-dependent variables used during compilation.

It uses those values to create a `Makefile in each directory of the package. It may also create one or more `.h files containing system-dependent definitions.

Finally, it creates a shell script `config.status that you can run in the future to recreate the current configuration, a file `config.cache that saves the results of its tests to speed up reconfiguring, and a file `config.log containing compiler output (useful mainly for debugging `configure).

If you need to do unusual things to compile the package, please try to figure out how `configure could check whether to do them, and mail diffs or instructions to the address given in the `README so they can be considered for the next release.

If at some point `config.cache contains results you dont want to keep, you may remove or edit it.

The file `configure.in is used to create `configure by a program called `autoconf. You only need `configure.in if you want to change it or regenerate `configure using a newer version of `autoconf.

The simplest way to compile this package is:

1. `cd to the directory containing the packages source code and type `./configure to configure the package for your system. If youre using `csh on an old version of System V, you might need to type `sh ./configure instead to prevent `csh from trying to execute
`configure itself.

Running `configure takes awhile. While running, it prints some messages telling which features it is checking for.

2. Type `make to compile the package.

3. Optionally, type `make check to run any self-tests that come with the package.

4. Type `make install to install the programs and any data files and documentation.

5. You can remove the program binaries and object files from the source code directory by typing `make clean. To also remove the files that `configure created (so you can compile the package for a different kind of computer), type `make distclean.

There is also a `make maintainer-clean target, but that is intended mainly for the packages developers. If you use it, you may have to get all sorts of other programs in order to regenerate files that came with the distribution.

libSRTP library is an open-source implementation of the Secure Real-time Transport Protocol (SRTP) originally authored by Cisco Systems, Inc. It is available under a BSD-style license.
SRTP is a security profile for RTP that adds confidentiality, message authentication, and replay protection to that protocol. It is specified in RFC 3711. More information on the SRTP protocol itself can be found on the Secure RTP Page.
Installation:
./configure [ options ] # GNU autoconf script
make # or gmake if needed; use GNU make
The configure script accepts the following options:
--help provides a usage summary
--disable-debug compile without the runtime debugging system
--enable-syslog use syslog for error reporting
--disable-stdout use stdout for error reporting
--enable-console use /dev/console for error reporting
--gdoi use GDOI key management (disabled at present)
By default, debbuging is enabled and stdout is used for debugging. You can use the above configure options to have the debugging output sent to syslog or the system console. Alternatively, you can define ERR_REPORTING_FILE in include/conf.h to be any other file that can be opened by libSRTP, and debug messages will be sent to it.
This package has been tested on Mac OS X (powerpc-apple-darwin1.4),
Cygwin (i686-pc-cygwin), and Sparc (sparc-sun-solaris2.6). Previous
versions have been tested on Linux and OpenBSD on both x86 and sparc
platforms.
Enhancements:
- Release 1.4.4 is a snapshot of the code in CVS, which has been slowly accumulating minor fixes and extensions.

oRTP is a library implementing the Real-time Transport Protocol (RFC3550), written in C.
oRTP project is easy to use and provides a packet scheduler for sending and receiving packets on time, adaptive jitter compensation, and automatic sending of RTCP compound packets. It works with IPv6.
Main features:
- Written in C
- Implement the RFC3550 (RTP) with a easy to use API with high and low level access.
- Includes support for multiples profiles, AV profile (RFC1890) being the one by default.
- Includes a packet scheduler for synchronizing rtp recv and send. Scheduling is optionnal, rtp sessions can remain not scheduled.
- Implements blocking and non blocking IO for RTP sessions.
- Supports mutiplexing IO, so that hundreds of RTP sessions can be managed by a single thread.
- Supports part of RFC2833 for telephone events over RTP.
- The API is well documented using gtk-doc.
- Licensed under the Lesser Gnu Public License.
- RTCP messages sent periodically since 0.7.0 (compound packet including sender report or receiver report + SDES)
Enhancements:
- This version includes new API documentation built with Doxygen and integrates minor patches and optimizations.

JRTPLIB is an object-oriented library written in C++ which offers support for the Real-time Transport Protocol (RTP) as defined in RFC 3550.
JRTPLIB project makes it very easy to send and receive RTP packets and the RTCP (RTP Control Protocol) functions can be handled entirely internally.
Enhancements:
- A memory management system was added.
- A bug concerning the use of the rand_s function in the Win32 version was fixed.

GNU ccRTP is an implementation of RTP, the real-time transport protocol from the IETF (see RFC 3550, RFC 3551 and RFC 3555). ccRTP is a C++ library based on GNU Common C++ which provides a high performance, flexible and extensible standards-compliant RTP stack with full RTCP support. The design and implementation of ccRTP make it suitable for high capacity servers and gateways as well as personal client applications.
In designing ccRTP, we have taken into account that RTP has been defined as an application level protocol framework rather than a typical Internet transport protocol such as TCP and UDP. Thus, RTP is hardly ever implemented as a layer separated from the application.
Consequently, RTP applications often must customize the adaptable RTP packet layout and processing rules, timing constraints, session membership rules as well as other RTP and RTCP mechanisms. ccRTP aims to provide a framework for the RTP framework, rather than being just an RTP packet manipulation library.
Support for both audio and video data is also considered in the design of ccRTP, that can do partial frame splits/re-assembly. Unicast, multi-unicast and multicast transport models are supported, as well as multiple active synchronization sources, multiple RTP sessions (SSRC spaces), and multiple RTP applications (CNAME spaces). This allows its use for building all forms of Internet standards based audio and visual conferencing systems.
GNU ccRTP is threadsafe and high performance. It uses packet queue lists for the reception and transmission of data packets. Both inter-media and intra-media synchronization is automatically handled within the incoming and outgoing packet queues. GNU ccRTP offers support for RTCP and many other standard and extended features that are needed for both compatible and advanced streaming applications.
It can mix multiple payload types in stream, and hence can be used to impliment RFC 2833 compliant signaling applications as well as other specialized things. GNU ccRTP also offers direct RTP and RTCP packet filtering.
GNU ccRTP uses templates to isolate threading and sockets related dependencies, so that it can be used to impliment realtime streaming with different threading models and underlying transport protocols, not just with IPV4 UDP sockets. For a more detailed list of ccRTP features you can have a look at the programmers manual.
At its highest level, ccRTP provides classes for the real-time transport of data through RTP sessions, as well as the control functions of RTCP.
The main concept in the ccRTP implementation of RTP sessions is the use of packet queues to handle transmission and reception of RTP data packets/application data units. In ccRTP, a data block is transmitted by putting it into the transmission (outgoing packets) queue, and received by getting it from the reception (incoming packets) queue.
Main features:
- Highly extensible to specialized stacks.
- Supports unicast, multi-unicast and multicast. Handles multiple sources (including synchronization sources and contributing sources) and destinations. Also supports symmetric RTP.
- Automatic RTCP functions handling, such as association of synchronization sources from the same participant or NTP-RTP timestamp mapping.
- Genericity as for underlying network and transport protocols through templates.
- It is threadsafe and supports almost any threading model.
- Generic and extensible RTP and RTCP header validity checks.
- Handles source states and information as well as statistics recording.
- Automatically handles SSRC collisions and performs loop detection.
- Implements timer reconsideration and reverse reconsideration.
- Provides good random numbers, based on /dev/urandom or, alternatively, on MD5.
There are several levels of interface (public interface, public or protected inheritance, etc) in ccRTP. For instance, the rtphello demo program distributed with ccRTP just uses the public interface of the RTPSession class and does not redefine the virtual method onGotSR, thus what this program knows about SR reports is the information conveyed in the last sender report from any source, which can be retrieved via the getMRSenderInfo method of the SyncSource class.
On the contrary, the rtplisten demo program redefines onGotSR by means of inheritance and could do specialized processing of these RTCP packets. Generally, both data and control packets are not directly accessible through the most external interface.
All this functions are performed through a few essential classes and types. The most basic ones are the enumerated type StaticPayloadType, and the classes StaticPayloadFormat and DynamicPayloadFormat.
The most important ones are the classes RTPSession, SyncSource, Participant and AppDataUnit, that represent RTP sessions, synchronization sources, participants in an RTP application, and application data units conveyed in RTP data packets, respectively.
When using ccRTP, both sending and receiving of data transported over RTP sessions is done through reception and transmission queues handled by the RTP stack. In the most common case, a separate execution thread for each RTP session handles the queues. This case is the threading model that we will generally assume throughout this document. Note however that ccRTP supports other threading models, particularly ccRTP supports the use of a single execution thread to serve a set of RTP sessions. It is also possible to not associate any separate thread with any RTP session, manually calling the main data and control service methods from whatever other thread.
The basic idea for packet reception with ccRTP is that the application does not directly read packets from sockets but gets them from a reception queue. The stack is responsible for inserting received packets in the reception queue and handling this queue. In general, a packet reception and insertion in the reception queue does not occur at the same time the application gets it from the queue.
Conversely, the basic idea for packet transmission with ccRTP is that packets are not directly written to sockets but inserted in a transmission queue handled by the stack. In general, packet insertion and transmission occur at different times, though it is not necessary.
In order to use ccRTP, you must include the main header (#include < ccrtp/rtp.h >. Two additional headers are provided by ccRTP:
#include < ccrtp/rtppool.h
Classes for pools of RTP service threads.
#include < ccrtp/rtpext.h >
Classes for RTP extensions which are not mature yet.
You must also link in the library, currently ccrtp1.
Enhancements:
- Brand new support has been introduced for Secure RTP Profile (srtp) as per RFC 3711.
- This release also supports a new add-on package, libzrtpcpp, that directly offers native zfone (zrtp) compatible encryption capabilities to Common C++ RTP based applications.
- This is the first softphone client to use both Common C++ RTP srtp and zrtp support.

MPlayer is a movie player for Linux (runs on many other Unices, and non-x86 CPUs, see the documentation). MPlayer plays most MPEG, VOB, AVI, Ogg/OGM, VIVO, ASF/WMA/WMV, QT/MOV/MP4, FLI, RM, NuppelVideo, YUV4MPEG, FILM, RoQ, PVA files, supported by many native, XAnim, and Win32 DLL codecs. You can watch VideoCD, SVCD, DVD, 3ivx, DivX 3/4/5 and even WMV movies, too (without the avifile library).
Another great feature of MPlayer is the wide range of supported output drivers. It works with X11, Xv, DGA, OpenGL, SVGAlib, fbdev, AAlib, DirectFB, but you can use GGI, SDL (and this way all their drivers), VESA (on every VESA compatible card, even without X11!) and some low level card-specific drivers (for Matrox, 3Dfx and ATI), too!
Most of them support software or hardware scaling, so you can enjoy movies in fullscreen. MPlayer supports displaying through some hardware MPEG decoder boards, such as the Siemens DVB, DXR2 and DXR3/Hollywood+.
MPlayer has an onscreen display (OSD) for status information, nice big antialiased shaded subtitles and visual feedback for keyboard controls. European/ISO 8859-1,2 (Hungarian, English, Czech, etc), Cyrillic and Korean fonts are supported along with 12 subtitle formats (MicroDVD, SubRip, OGM, SubViewer, Sami, VPlayer, RT, SSA, AQTitle, JACOsub, PJS and our own: MPsub). DVD subtitles (SPU streams, VOBsub and Closed Captions) are supported as well.
Main features:
- (S)VCD (Super Video CD)
- CDRwins .bin image file
- DVD, including encrypted DVD
- MPEG-1/2 (ES/PS/PES/VOB)
- RIFF AVI file format
- ASF/WMV/WMA format
- QT/MOV/MP4 format
- RealAudio/RealVideo format
- Ogg/OGM files
- VIVO format
- FLI format
- NuppelVideo format
- yuv4mpeg format
- FILM (.cpk) format
- RoQ format
- PVA format
- Matroska
- NSV - Nullsoft Streaming Video
- streaming via http, RTP, RTSP, mms, mmst, mpst, sdp
- TV
Supported Video and Audio Codecs:
- MPEG-1 (VCD) and MPEG-2 (SVCD/DVD/DVB) video
- MPEG-4 in all variants including DivX ;-), OpenDivX (DivX4), DivX 5 (Pro), XviD
- Windows Media Video 7/8 (WMV1/2)
- Windows Media Video 9 (WMV3) (using x86 DLL)
- RealVideo 1.0, 2.0 (G2)
- RealVideo 3.0 (RP8), 4.0 (RP9) (using Real libraries)
- Sorenson v1/v3 (SVQ1/SVQ3), Cinepak, RPZA and other QuickTime codecs
- DV video
- 3ivx
- Intel Indeo3 (3.1, 3.2)
- Intel Indeo 4.1 and 5.0 (using x86 DLL or XAnim codecs)
- VIVO 1.0, 2.0, I263 and other H.263(+) variants (using x86 DLL)
- MJPEG, AVID, VCR2, ASV2 and other hardware formats
- FLI/FLC
- HuffYUV
- various old simple RLE-like formats
- MPEG layer 1, 2, and 3 (MP3) audio
- AC3/A52 (Dolby Digital) audio (software or SP/DIF)
- AAC (MPEG-4 audio)
- WMA (DivX Audio) v1, v2
- WMA 9 (WMAv3), Voxware audio, ACELP.net etc (using x86 DLLs)
- RealAudio: COOK, SIPRO, ATRAC3 (using Real libraries)
- RealAudio: DNET and older codecs
- QuickTime: Qclp, Q-Design QDMC/QDM2, MACE 3/6 (using QT libraries)
- Ogg Vorbis audio
- VIVO audio (g723, Vivo Siren) (using x86 DLL)
- alaw/ulaw, (ms)gsm, pcm, *adpcm and other simple old audio format

Oreka is a modular and cross-platform system for recording and retrieval of audio streams.
Oreka project currently supports VoIP SIP and sound device based capture. Recordings metadata can be stored in any mainstream database. Retrieval of captured sessions is web based.
Main features:
Recording and storage
- Record VoIP SIP sessions by passively listening to network packets. Both sides of a conversation are mixed together and each call is logged as a separate audio file.
- Record from a standard sound device (e.g. microphone or line input). Can record multiple channels at the same time. Each recording goes to separate audio files
- Open plugin architecture for audio capture means that the system is potentially capable of recording from any audio source.
- Automatic audio segmentation so that continuous audio sources can be split in separate audio files and easily retrieved later.
- Voice activity detection.
- GSM6.10, A-Law and u-Law compression available in order to save disk space.
- Recording metadata logged to file and/or any mainstream database system.
User interface
- Recordings retrieval can be done using the following criteria (when available):
- Timestamp
- Recording duration
- Direction (for a telephone call)
- Remote Party (for a telephone call)
- Local Party (for a telephone call)
Enhancements:
- A critical bug that could cause Orkaudio to crash given a certain sequence of RTP packets was fixed.
- A SIP detection issue on the Siemens platform (Siemens Optipoint 400) was fixed.

Mediastreamer is library written in C that allows you to create and run audio and video streams. It is designed for any kind of voice over IP applications.

It features RTP connectivity, audio codecs (Speex, iLBC, G711, GSM), video codecs (MPEG4, H263, Theora), I/O from soundcards, wav files, webcams, echo-cancelation, conferencing, and various other utilities.

Mediastreamer has a modular design that makes it extensible through plugins. This is the media-streaming component of linphone, a GPL SIP video phone.