Free lame rtp 2 software for linux

LAME is short from LAME Aint an MP3 Encoder and is a research project for learning about and improving MP3 encoding technology. LAME includes an MP3 encoding library, simple frontend application, a much-improved psycho-acoustic model (GPSYCHO), and a graphical frame analyzer (MP3x).
Please note that any commercial use (including distributing the LAME encoding engine in a free encoder) may require a patent license from Thomson Multimedia.
Main features:
- Many improvements in quality in speed over ISO reference software. See history.
- MPEG1,2 and 2.5 layer III encoding.
- CBR (constant bitrate) and two types of variable bitrate, VBR and ABR.
- Encoding engine can be compiled as a shared library (Linux/UNIX), DLL or ACM codec (Windows)
- free format encoding and decoding
- GPSYCHO: a GPLd psycho acoustic and noise shaping model.
- Powerfull and easy to use presets
- Quality is comparable to FhG encoding engines and substantially better than most other encoders.
- Fast! Encodes faster than real time on a PII 266 at highest quality mode.
- MP3x: a GTK/X-Window MP3 frame analyzer for both .mp3 and unencoded audio files.
Software which uses "LAME":
- andromeda (PHP and ASP) Dynamically presents collections of mp3s as streaming web sites.
- rip (Perl) Script for ripping and encoding.
- avifile AVI/DIVX encoder and decoder for Linux.
- Grip (Linux) gtk-based cd-player, ripper and encoder. Supports cddb, cdparanoia and LAME.
- jbm2 (Linux) A KDE jukebox style application for public places (bars, pubs,...)
- Krabber (Linux) A KDE ripper & encoder, can use LAME.
- Mp3Maker (Linux) A WindowMaker enhanced front end to cdda2wav/cdparanoia and lame/bladeenc.
- dekagenc (Linux) Bourne shell script for ripping, encoding and CDDB naming.
- ripperX (Linux) GTK frontend for rippers and several encoders featuring CDDB support.
- T.E.A.R. (Linux) frontend to LAME, cdparanoia and CDDB.
- Xmcd. (Linux) CD Player with CDDB and ripping to MP3 and OGG.
- xtunes (Linux) GTK frontend for LAME, MAD, cdparanoia, cdrecord and more.
- DropMP3 (Mac) includes LAME binaries.
- CDex (Windows) Ripper & encoder, includes LAME binaries (the Blade compatible dll)
- Lamedrop (Windows) OggDrop style frontend.
- LAMEX (Windows) An activex control for LAME, and a GUI. Source code only, includes LAME.
- m3w (Windows) A live mp3 streamer for the WWW. Works with LAME, icecast, soundcard input
- out_lame (Windows) Winamp output plug-in. Create MP3 files directly from Winamp!
- RazorLame (Windows) The RazorBlade front end now supports LAME.
- winLAME (Windows) The only *nice* windows UI for LAME, according to the author :-)
- DarkIce Live streamer for IceCast.
- LiveIce Real time streaming of mp3s. Works with IceCast
- MuSE A mixing, encoding and streaming engine.
- Flash Forth a Flash-like development library
Enhancements:
- This version is identical to 3.97b3, which was promoted to release.

AudConvert is an application that is designed to take any audio format and convert it to any other audio format.
The idea for AudConvert came from my need to turn my Ogg Vorbis collection into MP3s for portable devices.
Yes, this process sometimes will result in lower quality, but sometimes it must be done.
Main features:
- Input any directory of files, get out the same directory structure (or flat directory) of newly encoded files.
- Multi-threaded: Encode up to 8 files simultaneously.
This is the first release of this software and it needs a lot of testing.
Supported Inputs:
- Ogg Vorbis (oggdec)
- MP3 (mpg123)
- FLAC (flac)
Supported Outputs:
- Ogg Vorbis (oggenc)
- MP3 (lame)

Vat is an audio conferencing application developed by the Network Research Group of Lawrence Berkeley National Laboratory. Source code and pre-compiled binaries are available via anonymous ftp.
The LBNL audio tool, vat, is a real-time, multi-party, multimedia application for audio conferencing over the Internet. Vat is based on the Draft Internet Standard Real-time Transport Protocol (RTP) developed by the IETF Audio/Video Transport working group. RTP is an application-level protocol implemented entirely within vat -- you need no special system enhancements to run RTP. Although vat can be run point-to-point using standard unicast IP addresses, it is primarily intended as a multiparty conferencing application. To make use of the conferencing capabilities, your system must support IP Multicast, and ideally, your network should be connected to the IP Multicast Backbone (MBone).
Vat provides only the audio part of a multimedia conference; video, whiteboard, and session control tools are implemented in separate applications. Our video tool is called vic and our whiteboard tool wb, UCL developed the session directory tool sdr Other related applications include ISIs Multimedia Conference Control, mmcc, the Xerox PARC Network Video tool, nv and the INRIA Video-conferencing System, ivs.
Enhancements:
- Added code to Windows audio driver to convert to 8-bit linear if driver doesnt support 16-bit linear (the code in Win95 thats supposed to do this is apparently broken). Problem reported by dozens of SoundBlaster users.
- Unicast sessions wouldnt work under Windows. (Re-)Incoporated fix from John Brezak that somehow got left out of b1 release.
- Restored vat 3.4 "[net localport]" command (needed by ISI/MIT RSVP additions to vat). Requested by Steve Berson.
- Fixed sitebox display bug on monochrome displays. Reported by Evi Nemeth.
- Fixed bug where SS-10 could get stuck sending a continuous tone if the last byte before a completely silent frame was non-zero. Reported by Steve Deering.
- Correct URL of SCO port on vat homepage. Fix from Shawn McMurdo.
- Incorporated Irix5.3 and 6.x configure and config.h fixes from Andrew Cherenson.
- Incorporated AIX configure and config.h fixes from Christian Zahl.

Makepack project is a Makefile which together with a settings file and some simple rule files are able to download, compile and install software for your Slackware installation.

As the installation is done using checkinstall a Slackware package is also created at the same time.

The big strenght of makepack is that it has mechanisms to keep track of dependencies when downloading and installing software.

Exemple:

$ make list

Numeric: Python package for scientific computing
SDL_image: Image file loading library
SDL_mixer: Sample multi-channel audio mixer library.
SDL_ttf: Library for using TrueType fonts in SDL applications.
angrydd: Angry, Drunken Dwarves, falling blocks puzzle game
atlas: Automatically Tuned Linear Algebra Software (ATLAS)
easytag: graphical (gtk) mp3 id3 tag editor
flac: library for Free Lossless Audio Codec
id3lib: library for mp3 id3 tags
ms-sys: Utility for writing microsoft compatible boot records
numpy: Python package for scientific computing
pygame: A set of Python modules designed for writing games
qemu: Generic processor emulator
smpeg: SDL MPEG Player Library

Whats New in This Release:

Upgraded the following rules:
MPlayer to version 1.0rc1
MPlayer_win_codecs to version 20061022, also
placed this file on a mirror as previos
versions has been removed from mplayerhq.
dvdauthor to version 0.6.14
gpgme to version 1.1.4
gphoto2 to version 2.3.1
jack to version 0.103.0
kqemu to version 1.3.0pre9, also changed dependencies so that
kqemu now depends on qemu instead of qemu depending on
kqemu. This might make sense for future versions of qemu
which might use kvm instead of kqemu.
qemu to version 0.9.0, qemu will not compile with gcc 4 which is
included with Slackware 12. Also, once compiled it does not
seem very stable.
lame to version 3.97
libdv to version 1.0.0
libdvdread to version 0.9.7
libggi to version 2.2.2
libgphoto2 to version 2.3.1
libgii to version 1.0.2
libgpg-error to version 1.5
libquicktime to version 1.0.0
libmpeg3 to version 1.7
libtheora to version 1.0alpha7
mjpegtools to version 1.9.0rc2
mpeg2dec to version 0.4.1
mplayerplug-in to version 3.40
nas to version 1.9
sylpheed to version 2.4.4
transcode to version 1.0.3
valgrind to version 3.2.3
xvidcore to version 1.1.3

New rules. Support for the following applications:
FileRunner http://www.cd.chalmers.se/~hch/filerunner.html
Image-ExifTool http://www.sno.phy.queensu.ca/~phil/exiftool/
bfr http://www.glines.org/wiki/bfr
cdlabelgen http://www.aczoom.com/tools/cdinsert/
cstream http://www.cons.org/cracauer/cstream.html
cvsgraph http://www.akhphd.au.dk/~bertho/cvsgraph/
ddd http://www.gnu.org/software/ddd/
However, ddd does not compile on Slackware 12
dvgrab http://www.kinodv.org/
epstool http://pages.cs.wisc.edu/~ghost/gsview/epstool.htm
gocr http://jocr.sourceforge.net/
gscanbus http://gscanbus.berlios.de/
gtimer http://www.k5n.us/gtimer.php
jhead http://www.sentex.net/~mwandel/jhead/
kdiff3 http://kdiff3.sourceforge.net/
nedit http://www.nedit.org/
mercurial http://www.selenic.com/mercurial/
privoxy http://www.privoxy.org/
pstoedit http://www.pstoedit.net/
rpc.rstatd http://rstatd.sourceforge.net/
saytime http://www.acme.com/software/saytime/
tor http://tor.eff.org/
wine http://www.winehq.org/

Support for the following libraries:
libavc1394 http://sourceforge.net/projects/libavc1394/
libdvdcss http://www.videolan.org/developers/libdvdcss.html
libevent http://www.monkey.org/~provos/libevent/
libmpcdec http://www.musepack.net/
libraw1394 http://www.linux1394.org/
libiec61883 http://www.linux1394.org/
onig http://www.geocities.jp/kosako3/oniguruma/
x264 http://www.videolan.org/developers/x264.html

Wildcards in REMOVE_FROM_PACKAGE now also works with newer
versions of tar.
This version of makepack is supposed to work with
Slackware 12. Unfortunately ddd does not compile on
Slackware 12 because of broken header files from X.org or
lesstif. If you really want ddd on Slackware 12 there are
instructions out there on how to modify those header files.

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.

FAME project is a set of tools for encoding multimedia content.

It currently consists in the following tools:

libfame

libfame is a video encoding library.

It can currently encode MPEG-1 and MPEG-4 rectangular video, as well as MPEG-4 video with arbitrary shape.

Compliance

Provide bitstreams compliant to the MPEG-1, MPEG-2 and MPEG-4 video standards.

Speed

Provide a fast implementation of the techniques used in MPEG standards.

Flexibility

Allow the user to choose between different options for speed, compression ratio and quality.

Portability Support many different platforms and architectures.

fame

fame is a multimedia encoder, which captures video from a video4linux device, and optionnaly sound, for MPEG encoding.

It is based on libfame and lame and thus supports the same output formats as these two libraries.