[Red5] Nellymoser decoder on Java ...

Wed Jan 21 06:45:07 PST 2009

If you look at RTPStreamReciever it has the following in the main run()
loop.

if (false) {

encoderMap = encoder.encode(encoderMap, aux1, 0, encodedStream.bytes, 0);

      rtmpUser.pushAudio(64, encodedStream.bytes, timeStamp, 82);

      //first byte 2 mono 5500; 6 mono 11025; 22 mono 11025 adpcm 82
nellymoser 8000 178 speex 8000

} else {

      byte[] aux = resample ((float)(8.0/11.025), aux1);

      rtmpUser.pushAudio(aux.length, aux, timeStamp, 6);

}

He has hardcoded it to always resample the audio from 8Khz to 11.025Khz and
publish as mono 11025 linear PCM audio (codec 6).  When changing the code to
use the NellyMoser encoder and publish nellymoser audio (codec 82), we just
hear silence in the FMS stream.

Right now we are only handling one way audio, G.711 audio -> red5phone ->
red5.  Is the reverse easy to setup as well?  We have not had a chance to
take a look at that part yet.

Thanks,

  _____  

 http://www.omnovia.com/images/mailicon.gif
next generation web conferencing

Prabhu Tamilarasan 
Senior Software Engineer

675 Bering Drive, Suite 290
Houston, TX 77057 USA
www.omnovia.com

ptamilarasan at omnovia.com 

T +1.281.500.4065 x 731 

  _____  

From: red5-bounces at osflash.org [mailto:red5-bounces at osflash.org] On Behalf
Of Mauro Sérgio Ferreira Brasil
Sent: Tuesday, January 20, 2009 5:09 AM
To: red5 at osflash.org
Subject: Re: [Red5] Nellymoser decoder on Java ...

Hi Prabhu!

If you are talking about new version of red5phone, we have tested here and
it works pretty fine.
The only maintenance we are making here is to adapt the changes we have made
on prior version to consider packetization "ptime" received from other part.

We noticed that packetization adopted for outgoing channel has changed
between versions from 32ms (which results on a payload with 256 bytes) to
20ms (payload with 160 bytes), that is a more likely.
Old version that works only with 256 bytes of payload, used to present
annoying clicks on other part voip client that commonly expects a payload of
only 160 bytes per packet.

Dispite from packetization issues, we get this new version running without
any changes, so I don't have any idea of which your problem is.
Maybe you can send more details about it.

I didn't understant what you mean about trying it out with just linear PCM
and trying after the nellymoser audio.
Anyway, can you provide additional info ?

Best regards,
Mauro.

Prabhu Tamilarasan (omNovia) escreveu: 

Has anyone had a chance to look at this new version?  The linear PCM audio
quality is much better than the previous version, has eliminated all
static/clicking we had before.  But when trying to use nellymoser, I get
blank audio.  Has anyone verified that nellymoser in this new version works?
It may be something I messed up when changing it to work with our system.

Thanks,

  _____  

 http://www.omnovia.com/images/mailicon.gif
next generation web conferencing

Prabhu Tamilarasan 
Senior Software Engineer

675 Bering Drive, Suite 290
Houston, TX 77057 USA
www.omnovia.com

ptamilarasan at omnovia.com 

T +1.281.500.4065 x 731 

  _____  

From: red5-bounces at osflash.org [mailto:red5-bounces at osflash.org] On Behalf
Of Mauro Sérgio Ferreira Brasil
Sent: Friday, January 16, 2009 6:38 AM
To: red5 at osflash.org
Subject: Re: [Red5] Nellymoser decoder on Java ...

Thank's a lot Paul. I'll be.

For now I'll have a better look on new red5phone version provided by Dele,
that already have a Java version of Nellymoser decoder.

It will demand lesser work for me to make it work with this version adding
only support to alaw (codes are already present, needing just validation
tests and incorporate on media negotiation), and ilbc that is not present on
FFMPEG (and Xuggler inevitably) as well.

But please keep we informed, because I'm not sure yet this will be the
better approach.

Thanks and best regards,
Mauro.

Mondain escreveu: 

Mario, 

I started using red5phone for a project some time ago as well, I am also a
member of the red5phone project btw. I hated that native nelly2pcm
application, it was quite unreliable in my case and did not have an OSX
version. I was privileged to know Art and get previews of Xuggler, which I
integrated into red5phone, so it can be done. Once my project is completed I
plan to put the opensource parts and updates to red5phone into the
repository, so at this time I can only say stay tuned.

Paul

On Thu, Jan 15, 2009 at 10:50 AM, Mauro Sérgio Ferreira Brasil
<mauro.brasil at tqi.com.br> wrote:

Hi Art, 

First of all, let me thank you very much for your patience and completeness
of your answers.

I'm still having a look on Xuggle and until now I'm liking of what I'm seing
:-)
Nevertheless, I would like to validade something with you.

I have no problem with "C" code at all, on the contrary. It's in fact the
language that I mostly work with.
I was searching for Java implementations because I was very affraid of how
an external application could degradate or limitate the scalability of a SIP
Web solution.

We intend to provide access using a fully reestruturated version of
red5phone for lots of users, and the implications of that external
application were frightening me.

I saw some information about additional latencies using Xuggle, but they
don't seem to be dramatic at all.
Are you confortable enought to tell me whether the use of Xuggle on such
scenario (lots of users making void calls with a client that uses
transcoding from Nellymoser to ulaw/alaw, for example) will be critical for
the final solution's scalability ?

Thanks in advance!
Mauro.

Art Clarke escreveu: 

On Thu, Jan 15, 2009 at 8:48 AM, Mauro Sérgio Ferreira Brasil
 <mailto:mauro.brasil at tqi.com.br> <mauro.brasil at tqi.com.br> wrote:

Hi Art,

Can you see any problems to me using Xuggle on a Web Voip application like
red5phone ? (please consider all problems with audio conversion, including
the need to get this done on the fly)

Not really; in fact I know of at least one other person (who
subscribes to this list) who is doing exactly that with Xuggler.  I'll
let him or her chime in if he or she feel like it (don't want to give
away what they might be working on) :)

- Art

_______________________________________________
Red5 mailing list
Red5 at osflash.org
http://osflash.org/mailman/listinfo/red5_osflash.org

-- 

At.,

Error! Filename not specified.  

Technology and Quality on Information

Mauro Sérgio Ferreira Brasil

Coordenador de Projetos e Analista de Sistemas

+ mauro.brasil at tqi.com.br <mailto:@tqi.com.br> 

: www.tqi.com.br

( + 55 (34)3291-1700

( + 55 (34)9971-2572

_______________________________________________
Red5 mailing list
Red5 at osflash.org
http://osflash.org/mailman/listinfo/red5_osflash.org

-- 
http://gregoire.org/
http://osflash.org/red5

  _____  

_______________________________________________
Red5 mailing list
Red5 at osflash.org
http://osflash.org/mailman/listinfo/red5_osflash.org

-- 

At.,

Technology and Quality on Information

Mauro Sérgio Ferreira Brasil

Coordenador de Projetos e Analista de Sistemas

+ mauro.brasil at tqi.com.br <mailto:@tqi.com.br> 

: www.tqi.com.br

( + 55 (34)3291-1700

( + 55 (34)9971-2572

  _____  

_______________________________________________
Red5 mailing list
Red5 at osflash.org
http://osflash.org/mailman/listinfo/red5_osflash.org

-- 

At.,

Technology and Quality on Information

Mauro Sérgio Ferreira Brasil

Coordenador de Projetos e Analista de Sistemas

+ mauro.brasil at tqi.com.br <mailto:@tqi.com.br> 

: www.tqi.com.br

( + 55 (34)3291-1700

( + 55 (34)9971-2572

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://osflash.org/pipermail/red5_osflash.org/attachments/20090121/e17f0082/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 1705 bytes
Desc: not available
URL: <http://osflash.org/pipermail/red5_osflash.org/attachments/20090121/e17f0082/attachment-0001.jpe>