[asterisk-dev] AST_FRAME_DIGITAL

[Tilghman Lesher]

On Sunday 09 September 2007 06:58:08 Sergio Garcia Murillo wrote:
> ----- Original Message -----
> From: "Tilghman Lesher" <tilghman at mail.jeffandtilghman.com>
> To: "Asterisk Developers Mailing List" <asterisk-dev at lists.digium.com>
> Sent: Saturday, September 08, 2007 11:46 PM
> Subject: Re: [asterisk-dev] AST_FRAME_DIGITAL
>
> > On Saturday 08 September 2007 10:28:06 Sergio Garcia Murillo wrote:
> > > In fact the problem is when you want to transmit the data from a
> > > channel to an application. The real case that we have to deal with
> > > is with h234m (i.e. 3g  videocalls).  The call is received by the
> > > isdn channel (chan_zap in klaus case), but the content
> > > is a h223 multiplexed data carrying h245 negotiation data, h263
> > > video and amr audio.
> > > So the problem is, how do we implement a pseudo channel in top
> > > of that channel?  We could have modified the chan_zap to decode
> > > it an directly output the demuxed frames to asterisk. The problem
> > > is that appart of beeing innecesarily difficult I would have to patch
> > > each isdn channel not only chan_zap.  So what I decided to do is
> > > implement an application to receive the incomming data
> > > and demultiplex it into a new local psuedo channel.
> > > The problem is that the data between the channel and the
> > > application is neither ALAW nor ULAW, or any other asterisk voice
> > > formats, and any conversion or transformation done will  screw
> > > the data.
> >
> > Excellent.  So it is now clear that you should be using
> > AST_FRAME_VIDEO for the data, not an opaque data type.
>
> Let me try to explain myself again, because it seems that you have not
> undestood the issue yet.
> The data is NOT video, is h223 data, which is a multiplexed stream that
> carries
> simultaniously audio,video and h245 control data. Once it's processed by
> the application then you can extract video frames and audio frames which
> can be correctly handled by asterisk.
> So if you don't want to create an opaque data type, then it will be great
> if you
> create it's correct type that would be AST_FRAME_DIGITAL and it's correct
> format AST_FORMAT_H223.
> Also if you want you could also include other digital formats, as for
> example
> AST_FORMAT_H320 (for isdn conferencing) that would be great.

Okay, so it's clear that you want to be able to demux the data in one place,
to have no code duplication.  I would encourage you to create a common API
in a resource module (perhaps res_demux) and call that API from every channel
driver that needs to demux the stream into multiples and send the data through
the core as each individual frame type (voice, video, and control).  Again,
with a native bridge, you could short circuit this step and avoid the demux,
but you should follow the Asterisk model of separating the streams in the
general case, such that other channels can interpret the data successfully.

-- 
Tilghman