Re: [Linphone-developers] G722

[Simon Brenner]

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:

https://bitbucket.org/herrpi/msg722

Greetings!

-Simon.


> 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