-Functional changes
1. Dynamic global format list build by codecs defined in codecs.conf
2. SILK 8khz, 12khz, 16khz, and 24khz with custom attributes defined in codecs.conf
3. Negotiation of SILK attributes in chan_sip.
4. SPEEX 32khz with translation
5. SLINEAR 8khz, 12khz, 24khz, 32khz, 44.1khz, 48khz, 96khz, 192khz with translation
using codec_resample.c
6. Various changes to RTP code required to properly handle the dynamic format list
and formats with attributes.
7. ConfBridge now dynamically jumps to the best possible sample rate. This allows
for conferences to take advantage of HD audio (Which sounds awesome)
8. Audiohooks are no longer limited to 8khz audio, and most effects have been
updated to take advantage of this such as Volume, DENOISE, PITCH_SHIFT.
9. codec_resample now uses its own code rather than depending on libresample.
-Organizational changes
Global format list is moved from frame.c to format.c
Various format specific functions moved from frame.c to format.c
Review: https://reviewboard.asterisk.org/r/1104/
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@308582 f38db490-d61c-443f-a65b-d21fe96a405b
This patch is the foundation of an entire new way of looking at media in Asterisk.
The code present in this patch is everything required to complete phase1 of my
Media Architecture proposal. For more information about this project visit the link below.
https://wiki.asterisk.org/wiki/display/AST/Media+Architecture+Proposal
The primary function of this patch is to convert all the usages of format
bitfields in Asterisk to use the new format and format_cap APIs. Functionally
no change in behavior should be present in this patch. Thanks to twilson
and russell for all the time they spent reviewing these changes.
Review: https://reviewboard.asterisk.org/r/1083/
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@306010 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r282047 | dvossel | 2010-08-12 15:15:41 -0500 (Thu, 12 Aug 2010) | 35 lines
improved translation paths for wideband codecs
The problem I'm addressing is that Asterisk's current
method of building the least cost translation paths
between codecs does not take into account sample rate.
For instance, it was possible for siren14 (a 32khz codec),
to contain the a translation path to siren7 (a 16khz
audio codec) that goes through slin at 8khz. In this
case Asterisk takes a 32khz codec, down samples it to
8khz and then up samples it to 16khz which is terrible
regardless if it is computationally less expensive. This
patch now builds translation paths that give priority to
maintaining the best possible sample rate before taking
into consideration computational cost. This patch also
adds cli commands to expose what translation paths are
actually being used.
Changes:
1. Translation paths will never contain a step that changes
the sample rate unless absolutely necessary.
2. When choosing the best codec to make two channels compatible.
Shared codecs with the highest sample rate are given priority.
3. A new cli command to show all translation paths available
for a specific codec 'core show translation paths [codec name]'
has been added.
4. 'core show translation' which displays the translation
matrix now includes the new higher bit audio codecs in the table.
5. 'core show channel [channel name]' now displays the
translation paths if translation is used.
(closes issue #16841)
Reported by: dvossel
Review: https://reviewboard.asterisk.org/r/842/
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@282048 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r224931 | russell | 2009-10-20 21:59:54 -0500 (Tue, 20 Oct 2009) | 5 lines
Isolate frames returned from a DSP instance or codec translator.
The reasoning for these changes are the same as what I wrote in the commit
message for rev 222878.
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@224932 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r99081 | russell | 2008-01-18 15:37:21 -0600 (Fri, 18 Jan 2008) | 9 lines
Revert adding the packed attribute, as it really doesn't make sense why that
would do any good. Fix the real bug, which is to do the check to see if the
frame came from a translator at the beginning of ast_frame_free(), instead of
at the end. This ensures that it always gets checked, even if none of the
parts of the frame are malloc'd, and also ensures that we aren't looking at
free'd memory in the case that it is a malloc'd frame.
(closes issue #11792, reported by explidous, patched by me)
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@99082 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r99079 | russell | 2008-01-18 15:22:21 -0600 (Fri, 18 Jan 2008) | 4 lines
Since we're relying on the offset between the frame and the beginning of the translator
pvt struct, set the packed attribute to make sure we get to the right place.
(potential fix for issue #11792)
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@99080 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r98943 | russell | 2008-01-15 17:26:52 -0600 (Tue, 15 Jan 2008) | 25 lines
Commit a fix for some memory access errors pointed out by the valgrind2.txt
output on issue #11698.
The issue here is that it is possible for an instance of a translator to get
destroyed while the frame allocated as a part of the translator is still being
processed. Specifically, this is possible anywhere between a call to ast_read()
and ast_frame_free(), which is _a lot_ of places in the code. The reason this
happens is that the channel might get masqueraded during this time. During a
masquerade, existing translation paths get destroyed.
So, this patch fixes the issue in an API and ABI compatible way. (This one is
for you, paravoid!)
It changes an int in ast_frame to be used as flag bits. The 1 bit is still used
to indicate that the frame contains timing information. Also, a second flag has
been added to indicate that the frame came from a translator. When a frame with
this flag gets released and has this flag, a function is called in translate.c to
let it know that this frame is doing being processed. At this point, the flag gets
cleared. Also, if the translator was requested to be destroyed while its internal
frame still had this flag set, its destruction has been deffered until it finds out
that the frame is no longer being processed.
Admittedly, this feels like a hack. But, it does fix the issue, and I was not able
to think of a better solution ...
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@98944 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r94828 | russell | 2007-12-27 08:33:21 -0600 (Thu, 27 Dec 2007) | 9 lines
Change ast_translator_best_choice() to only pay attention to audio formats.
This fixes a problem where Asterisk claims that a translation path can not be
found for channels involving video.
(closes issue #11638)
Reported by: cwhuang
Tested by: cwhuang
Patch suggested by cwhuang, with some additional changes by me.
........
r94829 | russell | 2007-12-27 08:44:29 -0600 (Thu, 27 Dec 2007) | 2 lines
Use the constant that I really meant to use here ...
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@94830 f38db490-d61c-443f-a65b-d21fe96a405b
- Remove the AST_FORMAT_MAX_* types, as these are consuming 3 out of our available 32 bits.
- Add a native slin16 type, so that 16kHz codecs can translate without losing resolution.
(This doesn't affect anything immediately, until another codec has wb support.)
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@89071 f38db490-d61c-443f-a65b-d21fe96a405b
use the \retval tag for documenting return values, fixing various warnings
when generating the documentation, and various other things.
(closes issue #10203, snuffy)
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@75164 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r46082 | kpfleming | 2006-10-23 22:45:42 -0500 (Mon, 23 Oct 2006) | 2 lines
add an API call to allow channel drivers to determine which media formats are compatible (passthrough or transcode) with the format an existing channel is already using
........
r46083 | kpfleming | 2006-10-23 22:53:32 -0500 (Mon, 23 Oct 2006) | 2 lines
ensure that the translation matrix is properly lock-protected every place it is used
........
r46152 | kpfleming | 2006-10-24 18:45:19 -0500 (Tue, 24 Oct 2006) | 2 lines
if multiple translators are registered for the same source/dest combination, ensure that the lowest-cost one is always inserted earlier in the list
........
r46153 | kpfleming | 2006-10-24 19:10:54 -0500 (Tue, 24 Oct 2006) | 2 lines
code zone experiment: don't offer formats in the outbound INVITE that aren't either passthrough or translatable
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@46203 f38db490-d61c-443f-a65b-d21fe96a405b
- restructured build tree and makefiles to eliminate recursion problems
- support for embedded modules
- support for static builds
- simpler cross-compilation support
- simpler module/loader interface (no exported symbols)
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@40722 f38db490-d61c-443f-a65b-d21fe96a405b
support the new location for zaptel.h and tonezone.h
use the dependency information output by menuselect to build Makefile rules for each module for header files and libraries
combine the common rules into a top-level Makefile.rules file
remove all (now) unnecessary stuff from subdir Makefiles
change translator API so that the newpvt() callback returns an int instead of a pointer (it no longer allocates memory)
alphabetize --with-<foo> options in configure script
enhance Net-SNMP support in configure script to provide a --with-netsnmp option
fix support for --with-pq so that if pg-config is not found when --with-pq is specified, an error will be generated
add 'optional package' usage to modules now that menuselect can output it
allow res_snmp to build by default, since the new loader changes coming soon will solve the function naming problem (and users can disable it via menuselect anyway)
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@35832 f38db490-d61c-443f-a65b-d21fe96a405b
and some patches (all disclaimed).
- Don't change RTP properties if we reject a re-INVITE
- Don't add video to an outbound channel if there's no video on the inbound channel
- Don't include video in the "preferred codec" list for codec selection
- Clean up and document code that parses and adds SDP attachments
Since we do not transcode video, we can't handle video the same way as audio. This is a
bug fix patch. In future releases, we need to work on a solution for video negotiation,
not codecs but formats and framerates instead.
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@32597 f38db490-d61c-443f-a65b-d21fe96a405b
don't transcode via SLINEAR when the option is enabled but there is a direct path from the source to the destination
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@20962 f38db490-d61c-443f-a65b-d21fe96a405b
As partly documented in loader.c and include/asterisk/module.h,
modules are now expected to return all of their methods and flags
into a structure 'mod_data', and are normally loaded with RTLD_NOW
| RTLD_LOCAL, so symbols are resolved immediately and conflicts
should be less likely. Only in a small number of cases (res_*,
typically) modules are loaded RTLD_GLOBAL, so they can export
symbols.
The core of the change is only the two files loader.c and
include/asterisk/module.h, all the rest is simply adaptation of the
existing modules to the new API, a rather mechanical (but believe
me, time and finger-consuming!) process whose detail you can figure
out by svn diff'ing any single module.
Expect some minor compilation issue after this change, please
report it on mantis http://bugs.digium.com/view.php?id=6968
so we collect all the feedback in one place.
I am just sorry that this change missed SVN version number 20000!
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@20003 f38db490-d61c-443f-a65b-d21fe96a405b
dvossel