Re: [Linphone-developers] G722

[Simon Brenner]

Hi Simon,

I hope my last answer to your reply reached you via email because there was 
some error related to
the mailing list cc.

I saw your oRTP fix, great! That means I can remove the payload_type_g722 
declaration and the
payload_type_set_user_data and rtp_profile_set_payload function calls from my 
msg722.c now?

What's the better way of setting those things? Wouldn't it be better to have 
everything done by the
plugin instead of hard coding it into Linphone?

And then there are still those 3 patches I have to apply to 
coreapi/sal_eXosip2_sdp.c, what about
them? Have you seen them in my repository and are you going to fix them in 
Linphone?

Many regards,

-Simon.



Simon Morlat wrote:
> Hi Simon,
> 
> Interesting work !
> Thank you very much !
> I integrated the oRTP fix.
> Are you still developing into your repository ? I could add it to
> git.linphone.org with other plugins, what do you think ?
> Also, if nobody has objections to it (Vadim and you), I would like his
> license to be changed to LGPL. Indeed it relies on LGPL source code
> taken from spandsp. Agreed ?
> 
> Simon
> 
> 
> Le mardi 20 juillet 2010 à 17:19 +0200, Simon Brenner a écrit :
>> 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

signature.asc
Description: OpenPGP digital signature