Re: libh324m frame format

libh324m does not do any kind of transcoding, so the amr
frame you receive on the app is in if2. 

Best regards 
Sergio 

---------- Original Message
----------------------------------
From: Klaus Darilion <klaus.mailinglistspernau.at>
Reply-To: Development discussion of video media support in
Asterisk<asterisk-videolists.digium.com>
Date:  Thu, 26 Jul 2007 09:22:39 +0200

>Hi Sergio!
>
>I have problems to understand the frame format used by
libh324m.
>
>AFAIK AMR is received from H324M in if2. When app_h324m
reads an 
>libh324m audio frame from libh324m - is the AMR frame
still in if2 or is 
>it converted to if1 inside libh324m?
>
>thanks
>klaus
>
>_______________________________________________
>--Bandwidth and Colocation Provided by http://www.api-digital.c
om--
>
>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.c
om--

asterisk-video mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-video

Ok. But there is still one thing I do not understand:

1. h324m_gw reads from the zap channel
2. It feeds the received frame (h223) into libh324m using
H324MSessionRead()
3. It reads demultiplexed frames from libh324m using
H324MSessionGetFrame().

4. It converts the h324m frames to ast_frames. If I analyze
the h324m 
audio frames retrieved with H324MSessionGetFrame, the frame
length is 31 
byte. Thus, this is plain AMR playload withouth ToC.

To make ast_frames with proper ToC I would guess there
should be a 
lookup in blockSize[] to find out the corresponding mode
instead of 
using framedata[0] (see below code from create_ast_frame)
which is not 
the mode but already the plain AMR data.

((unsigned char*)(send->data))[1] = (framedata[0] &
0x78) | 0x04;

regards
klaus

Sergio Garcia wrote:
> libh324m does not do any kind of transcoding, so the
amr frame you receive on the app is in if2. 
> 
> Best regards 
> Sergio 
> 
> ---------- Original Message
----------------------------------
> From: Klaus Darilion <klaus.mailinglistspernau.at>
> Reply-To: Development discussion of video media support
in Asterisk<asterisk-videolists.digium.com>
> Date:  Thu, 26 Jul 2007 09:22:39 +0200
> 
>> Hi Sergio!
>>
>> I have problems to understand the frame format used
by libh324m.
>>
>> AFAIK AMR is received from H324M in if2. When
app_h324m reads an 
>> libh324m audio frame from libh324m - is the AMR
frame still in if2 or is 
>> it converted to if1 inside libh324m?
>>
>> thanks
>> klaus
>>
>> _______________________________________________
>> --Bandwidth and Colocation Provided by http://www.api-digital.c
om--
>>
>> 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.c
om--
> 
> 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.c
om--

asterisk-video mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-video

Hi Sergio!

I've fixed some bugs in app_h324m and app_mp4 and it is
getting more 
stable. (patches will come next week)

But I can't solve this one:

I use h324m_gw and Echo(). Video works fine but audio sounds
wrong.

In create_ast_frame I dump the whole h324m frame to the log
file. In a 
sample call this looks like:

[Jul 27 14:07:06] DEBUG[22680] app_h324m.c:
create_ast_frame: H324M 
frame: ========= AUDIO =========
[Jul 27 14:07:06] DEBUG[22680] app_h324m.c:
create_ast_frame: H324M 
frame: length=31, buffer=0x844c3e8
07 a1 6a 9b 22 e3 58 58 10 78 7e b5 04 42 22 12 00 00 37 1b
d4 81 88 01 
00 90 3e e2 29 e7 2e

[Jul 27 14:07:06] DEBUG[22680] app_h324m.c:
create_ast_frame: H324M 
frame: ========= AUDIO =========
[Jul 27 14:07:06] DEBUG[22680] app_h324m.c:
create_ast_frame: H324M 
frame: length=31, buffer=0x84077a0
07 a1 6a 9b 22 e3 58 58 10 78 7e b5 04 42 22 12 00 00 37 1b
d4 81 88 01 
00 90 3e e2 29 e7 2e

[Jul 27 14:07:06] DEBUG[22680] app_h324m.c:
create_ast_frame: H324M 
frame: ========= AUDIO =========
[Jul 27 14:07:06] DEBUG[22680] app_h324m.c:
create_ast_frame: H324M 
frame: length=31, buffer=0x84077a0
b7 f7 ae 1f 77 f6 3c 78 01 6f ba f5 e4 24 24 10 00 00 3c 1e
1e a4 56 02 
00 50 2c 44 23 fd 3c


As this frames are 31 byte I guess this is mode 7. Mode 7
uses 244 bits. 
Thus, to fill up 31 bytes the last 4 bits should be zero. I
verified 
this with an helix producer AMR where the last 4 bits of a
frame are 
always zero.

Any comments in this?

thanks
klaus

_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.c
om--

asterisk-video mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-video