[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Linphone-developers] G722

From: Simon Brenner
Subject: Re: [Linphone-developers] G722
Date: Tue, 20 Jul 2010 17:19:02 +0200
User-agent: Thunderbird (X11/20091015)

Hi Simon & everyone,

I found this post on a mailing list archive and I wanted to ask you whether 
you've tried out my
plugin code. It was once your suggestion to realize a G.722 en-/decoder as a 
plugin and that is what
I've tried to do.

I would be glad about probably some final hints to get the plugin running. 
There were quite some
requests related to G.722 in Linphone.

Here's the repository:



> Hello,
> First of all thanks for G722 and G726 contributions. Actually instead of
> integrating them directly in mediastreamer2, I would like to make them
> plugins, such as msilbc and msx264.
> I've applied your portaudio fix.
> Concerning the ugly IETF mistake concerning the rate of G722, my preferrence
> would be to define the PayloadType with a 8000 Hz clockrate, but put a
> limited hack within audiostream.c so that the soundcards are open at 16000 Hz
> instead of 8000 as written in the payloadtype.
> Or do the reverse thing (perhaps it's better):
> declare the PayloadType as 16000 Hz but msrtp will "read" 8000 in case
> mime_type=="g722" .
> I think it should work.
> The reason why I dislike the rtp_rate addon is that it modifies the ABI the
> PayloadType struct and brings confustion just to workaround an IETF mistake
> for a single payload type. Not sure it is worth to do that.
> What do you think ?
> Simon
> Le Wednesday 28 January 2009 19:30:56 Vadim Lebedev, vous avez écrit :
>> Hello,
>> We've a following interop problem with G722 codec:
>> Because of historical reasons the relevant RTP RFC   speicifies that
>> when using G722 payload
>> RTP TIMESTAMP should be incremented with 8KHZ frequency  even if the
>> REAL sampling rate
>> is 16KHZ.
>> As you understand msrtp.c filter is unable to handle this situation,
>> so we've been thinking about possible enchancements.
>> One idea that comes to mind is to add a 'rtp_rate'  field to Payloadtype
>> structure , and if it is non zero and different from sampling rate to
>> compute adjustement (divider or multiplier) to rtp time stamp.
>> Any comments on this approach?
>> Thanks
>> Vadim

reply via email to

[Prev in Thread] Current Thread [Next in Thread]