[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Linphone-developers] G722
RE: [Linphone-developers] G722
Wed, 21 Jul 2010 12:29:57 +0200
I tried out your code in our project and got it working at least as far as
streaming G722 in a loop back to myself (so the plugin can decode what it
I didn't manage to compile it as a plugin but our build-environment is rather
backwards, we're building a win32 app in a linux environment with mingw that
links with mediastreamer2 and oRTP, we're not using the Linphone parts at all.
I think that your plugin works fine, but oRTP is missing the PayloadType for
G722, I patched it so that it recognizes G722 and registers it for payload type
9. I'm certainly not sure about the details for the PayloadType, most notably
the rate mentioned below. Initially I set the rate to 8000 but that caused
msrtp to constantly resynchronize the time. Setting it to 16000 removed that
but I have no idea if it's actually correct, I haven't tested it with an
external decoder/encoder yet.
Attached is the patch for oRTP.
From: address@hidden [mailto:address@hidden On Behalf Of Simon Brenner
Sent: den 20 juli 2010 17:19
Subject: Re: [Linphone-developers] G722
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:
> 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 ?
> Le Wednesday 28 January 2009 19:30:56 Vadim Lebedev, vous avez écrit :
>> 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?
Linphone-developers mailing list