len field in an ast_frame of audio was wrong when G.722 is in use. The len field
represents the number of ms of audio that the frame contains. It would have
set the value to be twice what it should be.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@105932 65c4cc65-6c06-0410-ace0-fbb531ad65f3
from a translator. This showed itself by g729 decoders not getting released.
Since the flag inside the translator frame never got unset by freeing the frame
to indicate it was no longer in use, the translators never got destroyed, and
thus the g729 licenses were not released.
(closes issue #11892)
Reported by: xrg
Patches:
11892.diff uploaded by russell (license 2)
Tested by: xrg, russell
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@101601 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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: https://origsvn.digium.com/svn/asterisk/branches/1.4@98943 65c4cc65-6c06-0410-ace0-fbb531ad65f3
translator pvt is freed before we use the frame, bad things happen.
2) Getting a failure from ast_sched_delete means that the schedule
ID is currently running. Don't just ignore it.
(Closes issue #11698)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@97973 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@94828 65c4cc65-6c06-0410-ace0-fbb531ad65f3
are translatable based on the source format. If we have already determined
that there is no translation path in one direction, don't bother checking the
other direction.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@46554 65c4cc65-6c06-0410-ace0-fbb531ad65f3
get the format index.
- Don't run through the audio and video loops if there is no audio or video
portion of the source
If 0 is passed to powerof, it will return -1. This value of -1 was then being
used as an array index in these loops, which caused a crash on some systems.
Other than this issue, this code works as we expected it to. If a format is
not in the source, and we have to translation path to it, it is not offered in
the list of acceptable destination formats.
(fixes issue #8231)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@46329 65c4cc65-6c06-0410-ace0-fbb531ad65f3
- 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: https://origsvn.digium.com/svn/asterisk/trunk@40722 65c4cc65-6c06-0410-ace0-fbb531ad65f3
