[Asterisk-video] can't hear amr audio
Andrew Buchanan
Andrew.Buchanan at ThinkTel.ca
Fri Jul 18 12:03:48 CDT 2008
Hi Sergio/Klaus,
I'm going to be away next week but after that I'll look at two functions
you suggested, ast_get_best_ codec or ast_codec_choose
Andrew
-----Original Message-----
From: asterisk-video-bounces at lists.digium.com
[mailto:asterisk-video-bounces at lists.digium.com] On Behalf Of
asterisk-video-request at lists.digium.com
Sent: July 18, 2008 11:00 AM
To: asterisk-video at lists.digium.com
Subject: asterisk-video Digest, Vol 27, Issue 11
Send asterisk-video mailing list submissions to
asterisk-video at lists.digium.com
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.digium.com/mailman/listinfo/asterisk-video
or, via email, send a message with subject or body 'help' to
asterisk-video-request at lists.digium.com
You can reach the person managing the list at
asterisk-video-owner at lists.digium.com
When replying, please edit your Subject line so it is more specific
than "Re: Contents of asterisk-video digest..."
Today's Topics:
1. Re: can't hear amr audio (Sergio Garcia Murillo)
2. Re: recent app_h324m.c commit - AMR frame size
patches
(Klaus Darilion)
----------------------------------------------------------------------
Message: 1
Date: Thu, 17 Jul 2008 22:20:37 +0200
From: Sergio Garcia Murillo <sergio.garcia at fontventa.com>
Subject: Re: [Asterisk-video] can't hear amr audio
To: Development discussion of video media support in Asterisk
<asterisk-video at lists.digium.com>
Message-ID: <487FA995.9020407 at fontventa.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi Klaus and Andrew,
I've just taken a quick look at the code, but I think that the code was
there to be able to choose between the different codecs offered (without
transcoding)
Now that we have support for amr in asterisk perhaps could be changed
for something like ast_get_best_ codec or ast_codec_choose.
BR
Sergio
Klaus Darilion escribi?:
> Andrew Buchanan wrote:
>
>> Hi Klaus,
>>
>> Thanks for your reply.
>>
>> The line
>> "audioFormat = sdp->audio->formats[i]->format;" (app_rtsp.c)
>> is never processed because the comparision
>> "if (sdp->audio->formats[i]->format & chan->nativeformats)"
(app_rtsp.c)
>> fails.
>>
>
> MAybe the bug is in this line. Actually it should work even if the sdp
> does not contain a native format as Asterisk can do transcoding - I
> think to do this the channels format has to be set to AMR (maybe with
> ast_set_write_format()?)
>
> Can you try changing the code?
>
> regards
> klaus
>
>
>> the value of format is 0x00002000
>> the value of nativeformats is 0x00580004
>> But the value written by
>> "ast_set_write_format(chan, audioFormat | videoFormat);"
>> Is nonzero as videoformat has a value 0x00400000
>>
>> Andrew Buchanan
>>
>
>
> _______________________________________________
> --Bandwidth and Colocation Provided by http://www.api-digital.com--
>
> asterisk-video mailing list
> To UNSUBSCRIBE or update options visit:
> http://lists.digium.com/mailman/listinfo/asterisk-video
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.digium.com/pipermail/asterisk-video/attachments/20080717/bf
0564f9/attachment.html
------------------------------
Message: 2
Date: Fri, 18 Jul 2008 00:30:41 +0200
From: Klaus Darilion <klaus.mailinglists at pernau.at>
Subject: Re: [Asterisk-video] recent app_h324m.c commit - AMR
frame
size patches
To: Development discussion of video media support in Asterisk
<asterisk-video at lists.digium.com>
Message-ID: <487FC811.2010203 at pernau.at>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Sergio Garcia Murillo wrote:
> I agree, thank you very much Klaus. Patch commited.
Can you please test your scenario again if it still works?
thanks
klaus
>
> BR
> Sergio
>
> Klaus Darilion escribi?:
>> Hi Sergio!
>>
>> I think if we define blocksize as in the previous mail, the code for
>> if2->AMR conversion is wrong and should be:
>>
>> /*If amr+TOC needs a byte more than if2 */
>> if(stuf < 4)
>> {
>> /* Set last byte */
>> data[bs] = data[bs - 1] << 4;
>> /*Increase size of frame*/
>> send->datalen++;
>>
>> /* For each byte */
>> for(j=bs-1; j>0; j--)
>> data[j] = data[j] >> 4 | data[j-1] << 4;
>> }
>> else
>> {
>> /* For each byte */
>> for(j=bs; j>0; j--)
>> data[j] = data[j] >> 4 | data[j-1] << 4;
>> }
>>
>>
>> instead of
>>
>> /*If amr has a byte more than if2 */
>> if(stuf < 4)
>> {
>> /* Set last byte */
>> data[bs] = data[bs - 1] << 4;
>> /*Increase size of frame*/
>> send->datalen++;
>> }
>>
>> /* For each byte */
>> for(j=bs-1; j>0; j--)
>> data[j] = data[j] >> 4 | data[j-1] << 4;
>>
>>
>> regards
>> klaus
>>
>> Klaus Darilion schrieb:
>>
>>> Again the same old story :-) Whe should have documented that. It is
up
>>> to use how we define the term "blocksize". It can be either the size
of
>>> the frame received from libh324m (in if2 format) or the size of the
AMR
>>> frame used in ast_frame (octed aligned RFC 3267 mode).
>>>
>>> I think the code now handles "blocksize" as the octed-aligned AMR
frame
>>> size. Currently the blocksize is mixed (before it was if2). What
about
>>> this wording:
>>>
>>>
>>>
>>>
>>>
>>> These are the different AMR modes (Table 1 from RFC 3267)
>>>
>>> Class A total speech
>>> Index Mode bits bits
>>> ----------------------------------------
>>> 0 AMR 4.75 42 95
>>> 1 AMR 5.15 49 103
>>> 2 AMR 5.9 55 118
>>> 3 AMR 6.7 58 134
>>> 4 AMR 7.4 61 148
>>> 5 AMR 7.95 75 159
>>> 6 AMR 10.2 65 204
>>> 7 AMR 12.2 81 244
>>> 8 AMR SID 39 39
>>>
>>> Table 1. The number of class A bits for the AMR codec.
>>>
>>> Asterisk's internal AMR format:
>>> ===============================
>>>
>>> Asterisk internally use the "octed-aligned" RTP format in ast_frame.
>>> (see section 4.4 in RFC 3267)
>>> This allows to have multiple AMR frames in one Asterisk frame. This
>>> means, the payload of an ast_frame wich contains N AMR frames
consists
>>> of (se also section 4.4.5.1 of RFC 3267):
>>>
>>> 1. 1 byte CMR (codec mode request)
>>> 2. N byte TOC (the TOC contains the AMR mode of the respecitve
frame
>>> and one bit which tells us if it is the last TOC or if there
are
>>> some more)
>>> 3. blocksize(AMR frame 0) + ..... + blocksize(AMR frame N)
>>>
>>> We define the blocksize of an AMR frame os the number of bytes
needed
>>> to contain an AMR frame in the respective mode. Thus, it is the
number
>>> of total speech bits divided by 8 and rounded upwards.
>>> E.g. an AMR frame in mode 5 has 159 bits. To store this frame we
need
>>> 20 bytes. Thus, the blocksize of an AMR frame in mode 5 is 20 bytes.
>>>
>>> H324M AMR format:
>>> =================
>>> In H324M, the AMR frames received from are in if2 format from
libh324m.
>>> (see Annex A in TS 26.101). This means that there are 4 bits for the
AMR
>>> mode followed by the speech bits. E.g. an AMR frame in mode 5 in if
format
>>> needs 159+4 => 21 bytes.
>>> There is always only one AMR frame in an if2 packet.
>>>
>>> Extended Table 1:
>>> ==================
>>>
>>> Class A total speech block if2 frame
>>> Index Mode bits bits size size
>>> -------------------------------------------------------------
>>> 0 AMR 4.75 42 95 12 13
>>> 1 AMR 5.15 49 103 13 14
>>> 2 AMR 5.9 55 118 15 16
>>> 3 AMR 6.7 58 134 17 18
>>> 4 AMR 7.4 61 148 19 19
>>> 5 AMR 7.95 75 159 20 21
>>> 6 AMR 10.2 65 204 26 26
>>> 7 AMR 12.2 81 244 31 31
>>> 8 AMR SID 39 39 5 6
>>>
>>>
>>>
>>>
>>>
>>> regards
>>> klaus
>>>
>>> Sergio Garcia Murillo schrieb:
>>>
>>>> Hi Klaus,
>>>>
>>>> I used an advanced method called try & error ;)
>>>>
>>>> The original values were taken from the mpeg4ip packetization code,
the
>>>> latest changes in the values from the low
>>>> bit rates ones are due to an error reproducing a mp4 file created
with
>>>> ffmpeg at those bit rates and adjusted them til
>>>> everything worked again.
>>>>
>>>> If everyone find any mode not working just let me know and I'll try
to
>>>> fix it. Or if anyone knows how to calculate the
>>>> correct ones then please tell me.
>>>>
>>>> Best regards
>>>> Sergio
>>>>
>>>> Klaus Darilion escribi?:
>>>>
>>>>> Hi Sergio!
>>>>>
>>>>> I wonder how you calculate the block size - I can not reproduce
it.
>>>>>
>>>>> Is it just dividing the bits of table 1 in RFC 3267 by 8 and
rounding or
>>>>> is there some more magic?
>>>>>
>>>>> thanks
>>>>> klaus
>>>>>
>>>>> _______________________________________________
>>>>> --Bandwidth and Colocation Provided by
http://www.api-digital.com--
>>>>>
>>>>> asterisk-video mailing list
>>>>> To UNSUBSCRIBE or update options visit:
>>>>> http://lists.digium.com/mailman/listinfo/asterisk-video
>>>>>
>>>>>
>>>> _______________________________________________
>>>> --Bandwidth and Colocation Provided by http://www.api-digital.com--
>>>>
>>>> asterisk-video mailing list
>>>> To UNSUBSCRIBE or update options visit:
>>>> http://lists.digium.com/mailman/listinfo/asterisk-video
>>>>
>>> _______________________________________________
>>> --Bandwidth and Colocation Provided by http://www.api-digital.com--
>>>
>>> asterisk-video mailing list
>>> To UNSUBSCRIBE or update options visit:
>>> http://lists.digium.com/mailman/listinfo/asterisk-video
>>>
>>
>> _______________________________________________
>> --Bandwidth and Colocation Provided by http://www.api-digital.com--
>>
>> asterisk-video mailing list
>> To UNSUBSCRIBE or update options visit:
>> http://lists.digium.com/mailman/listinfo/asterisk-video
>>
>
>
>
------------------------------------------------------------------------
>
> _______________________________________________
> --Bandwidth and Colocation Provided by http://www.api-digital.com--
>
> asterisk-video mailing list
> To UNSUBSCRIBE or update options visit:
> http://lists.digium.com/mailman/listinfo/asterisk-video
------------------------------
_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.com--
asterisk-video mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-video
End of asterisk-video Digest, Vol 27, Issue 11
**********************************************
More information about the asterisk-video
mailing list