[Asterisk-video] several questions to source code of app_h324m
Atle Samuelsen
clona at cyberhouse.no
Fri Jul 27 05:19:22 CDT 2007
G711,
H263+
- atle
* Klaus Darilion <klaus.mailinglists at pernau.at> [070727 11:21]:
> which audio codec?
> which video codec?
>
> Atle Samuelsen wrote:
> > * Klaus Darilion <klaus.mailinglists at pernau.at> [070727 09:21]:
> >> What scenario do you use? SIP<->mp4play or h324m_gw<->mp4play or ....?
> >
> > Hi Klaus,
> >
> > I used sip-> mp4play
> >
> > My extentions conf looks somewhat like this:
> > exten => 1,1,answer()
> > exten => 1,n,mp4play(/tmp/test.mp4)
> > exten => 1,n,mp4save(/tmp/test.mp4)
> >
> > The test.mp4 is recorded with mp4save()
> > -A
> >> 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
> >> _______________________________________________
> >> --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
More information about the asterisk-video
mailing list