[Asterisk-video] several questions to source code of app_h324m

Fri Jul 27 02:18:48 CDT 2007

What scenario do you use? SIP<->mp4play or h324m_gw<->mp4play or ....?

Atle Samuelsen wrote:
> Hey Klaus,
> 
> I tried this patch with app_mp4.c it does not work as expected to say it
> simple :) I get a crash when doing this. a backtrace of the coredump
> looks like this: 
> 
> (gdb) bt
> #0  0x001c87a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
> #1  0x002087d5 in raise () from /lib/tls/libc.so.6
> #2  0x0020a149 in abort () from /lib/tls/libc.so.6
> #3  0x0023c40a in __libc_message () from /lib/tls/libc.so.6
> #4  0x0024351c in _int_malloc () from /lib/tls/libc.so.6
> #5  0x00244f81 in malloc () from /lib/tls/libc.so.6
> #6  0x004da969 in MP4Track::ReadSample (this=0xffffffe8,
> sampleId=3180576, ppBytes=0x8348f68, pNumBytes=0x8348f6c,
> pStartTime=0x0, pDuration=0x0, pRenderingOffset=0x0, pIsSyncSample=0x0)
> at mp4util.h:176
> #7  0x004dac02 in MP4Track::ReadSampleFragment (this=0x8348f48,
> sampleId=2, sampleOffset=2, sampleLength=152, pDest=0x835530a "") at
> mp4track.cpp:340
> #8  0x004eb5c3 in MP4RtpSampleData::GetData (this=0x83591d0,
> pDest=0x835530a "") at mp4property.h:186
> #9  0x004e5ad3 in MP4RtpPacket::GetData (this=0x8358da8, pDest=0x835530a
> "") at rtphint.cpp:1039
> #10 0x004e5d08 in MP4RtpHintTrack::ReadPacket (this=0x8349038,
> packetIndex=0, ppBytes=0x83552a8, pNumBytes=0x8355290, ssrc=0,
> addHeader=false, addPayload=true) at rtphint.cpp:243
> #11 0x004ca978 in MP4File::ReadRtpPacket (this=0x833b930, hintTrackId=4,
> packetIndex=0, ppBytes=0x83552a8, pNumBytes=0x8355290, ssrc=0,
> includeHeader=false, includePayload=true) at mp4file.cpp:2877
> #12 0x004bc623 in MP4ReadRtpPacket (hFile=0x833b930, hintTrackId=4,
> packetIndex=0, ppBytes=0x83552a8, pNumBytes=0x8355290, ssrc=0,
> includeHeader=false, includePayload=true) at mp4.cpp:2786
> #13 0x003cf1ad in mp4_rtp_read (p=0xb79f9de0) at app_mp4.c:256
> #14 0x003cfb2c in mp4_play (chan=0x833a6c8, data=0xb79fe030) at
> app_mp4.c:511
> #15 0x080c6611 in pbx_extension_helper (c=0x833a6c8, con=Variable "con"
> is not available.
> ) at pbx.c:532
> #16 0x080c794f in __ast_pbx_run (c=0x833a6c8) at pbx.c:2274
> #17 0x080c97fe in pbx_thread (data=0x833a6c8) at pbx.c:2587
> #18 0x080f6375 in dummy_start (data=0x6) at utils.c:545
> #19 0x0034f341 in start_thread () from /lib/tls/libpthread.so.0
> #20 0x002a86fe in clone () from /lib/tls/libc.so.6
> (gdb) 
> 
> 
> Best Regards
> 
>  Atle
> 
> * Klaus Darilion <klaus.mailinglists at pernau.at> [070726 15:26]:
>>
>> Sergio Garcia wrote:
>>>
>>> ---------- Original Message ---------------------------------- From:
>>> Klaus Darilion <klaus.mailinglists at pernau.at> Reply-To: Development
>>> discussion of video media support in
>>> Asterisk<asterisk-video at lists.digium.com> Date:  Wed, 25 Jul 2007
>>> 16:10:32 +0200
>>>
>>>> Hi Sergio!
>>>>
>>>> I'm reading the code to find out why some things don't work for me.
>>>> Can you please comment on my questions?
>>>>
>>>>
>>>> static struct ast_frame* create_ast_frame(void *frame, struct
>>>> video_tr *vtr) { int mark = 0; struct ast_frame* send;
>>>>
>>>> /* Get data & size */ unsigned char * framedata =
>>>> FrameGetData(frame); unsigned int framelength =
>>>> FrameGetLength(frame);
>>>>
>>>> /* Depending on the type */ switch(FrameGetType(frame)) { case
>>>> MEDIA_AUDIO: /*Check it's AMR */ if
>>>> (FrameGetCodec(frame)!=CODEC_AMR) /* exit */ return NULL; /* Create
>>>> frame */ send = (struct ast_frame *) malloc(sizeof(struct
>>>> ast_frame) + AST_FRIENDLY_OFFSET + framelength + 2);
>>>>
>>>> If I Understand Correctly (IIUC) you allocate the frame structure
>>>> AND the buffer for the data with one malloc. Thus, the frist part
>>>> of the allocated memory is the structure, followed by the data
>>>> buffer?
>>>>
>>>> /* Set data*/ send->data = (void*)send + AST_FRIENDLY_OFFSET;
>>>>
>>>> I think this is wrong - it overwrites the structure. send->data =
>>>> (void*)send + sizeof(struct ast_frame) + AST_FRIENDLY_OFFSET;
>>> Ups you-'re rigth
>> Same problem in app_mp4.c static: mp4_rtp_read(struct mp4rtp *p)
>>
>>
>>
>> -  memset(f, 0, sizeof(struct ast_frame) + 1500);
>> +  memset(f, 0, sizeof(struct ast_frame) + AST_FRIENDLY_OFFSET + 1500);
>>          /* Let mp4 lib allocate memory */
>> -   f->data = (void*)f + AST_FRIENDLY_OFFSET;
>> +   f->data = (void*)f + sizeof(struct ast_frame) + AST_FRIENDLY_OFFSET;
>> +   f->offset = AST_FRIENDLY_OFFSET;
>>      f->datalen = 1500;
>>
>>
>> btw: setting datalen to 1500 is no safe method, as datalen is not
>> checked in mpeg4ip library:
>>
>>> ... The calling application is responsible for ensuring that the
>>> buffer is large enough to hold the packet. This can be done by using
>>> MP4GetRtpPayload() to retrieve the maximum packet payload size and
>>> hence how large the receiving buffer must be. ...
>> But I could not find the MP4GetRtpPayload() function. :-(
>>
>>>> send->datalen = framelength; /* Set header cmr */ ((unsigned
>>>> char*)(send->data))[0] = 0xF0; /* Set mode */ ((unsigned
>>>> char*)(send->data))[1] = (framedata[0] & 0x78) | 0x04;
>>>>
>>>>
>>>> Here you set the Codec Mode Request 2 times? You set the byte 0 to
>>>> 0xF0 (what is that - is that something standardized or just a
>>>> proprietary method for signaling something?).
>>>>
>>>> Then you reset the bits 7,2,1,0 and then you set the bit 2. What
>>>> for? I though the topmost 4 bits (7,6,5,4) are relevant for the
>>>> codec mode?
>>>>
>>>> /* Copy */ memcpy(send->data+2, framedata, framelength);
>>>>
>>>> Although the cmr is already copy to framedata[1], it will be copied
>>>>  (with the original value) to framedata[2] too. Why?
>>>
>>> What you receive in the framedata is the amr if2 frame, you have to
>>> add a 2 byte header for rtp transmision. The problem is that I don't
>>> have any softphone client with amr support to test it.. :(
>>>
>>> See http://www.ietf.org/rfc/rfc3267.txt Chapter 4.4.1. The Payload
>>> Header
>> I have just read RFC 4867 and things are much more clear now.
>>
>> Thus - what is the exact format how AMR should be encoded in 
>> ast_frame->data ? Like RFC 4867, octet-aligned, normal order?
>>
>>>> /* Set video type */ send->frametype = AST_FRAME_VOICE; /* Set
>>>> codec value */ send->subclass = AST_FORMAT_AMRNB; /* Rest of
>>>> values*/ send->src = "h324m"; wouldn't it be nicer to define
>>>> "h324m" as global variable?
>>> Ok.
>>>
>>>> send->samples = 160; send->delivery.tv_usec = 0; 
>>>> send->delivery.tv_sec = 0; send->mallocd = 0; IIUC setting
>>>> mallocd=0 works as the data buffer is allocated together with the
>>>> frame structure. Thus it will be freed when to frame structure is
>>>> freed.
>>>
>>> I'll have to check that, probably it's wrong also.
>> No. I think it is fine. it was just a comment that in this special case 
>> (allocating the frame structure AND the data buffer with a single 
>> malloc) it is fine.
>>
>> regards
>> 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