Re: [Linphone-developers] ortp: processing incoming stream

[Petr Kuba]

Hi Simon,

Simon Morlat wrote:
> Ok I understand.
> The correct way of setting off the jitter buffer is to do 
> rtp_session_enable_jitter_buffer(session,FALSE);
> In this mode you'll get all packets regardless that they are late or
> not.

I've tested this mode and it worked as expected. Thanks.

> About SSID: don't you meant SSRC ? Yes you should expect a random value.
> How did you see this 0x29 value ? gdb ? wireshark ? 

Now I see the problem: You call init_random_number_generator() in 
ortp_init() and then

session->snd.ssrc=uint32_t_random();

in rtp_session_init().

The problem is that I call ortp_init() and rtp_session_init() from 
different threads. And since srand() influences only current thread 
rand() is called without initializing randomizer. I'm not sure whether 
this is a bug or a feature ;-) What do you think?

Nevertheless, I can solve this by calling rtp_session_set_ssrc() so it 
isn't serious problem for me.

Thanks,
Petr


> Simon
>
> Le vendredi 27 novembre 2009 à 15:39 +0100, Petr Kuba a écrit :
> > Hi Simon,
> >
> > Thanks for your response.
> >
> > I've tested your approach and it works well with low jitter of an 
> > incoming stream and adaptive jitter enabled.
> >
> > However, if I disable the jitter buffer I miss quite a lot of packets 
> > (jitter is up to 10ms) and I have to use rtp_getq_permissive(). Then I 
> > receive all the packets.
> >
> > I'm handling situations where I just forward packets from one RTP stream 
> > to another and I don't want to delay the packet by using jitter buffer. 
> > And I don't want to miss packets event if they are e.g. 40ms late.
> >
> > So, I have several questions:
> >
> > 1) What is the correct way to receive all the packets without modifying 
> > ORTP source code if I don't use jitter buffer? It would be nice to 
> > obtain a packet immediately after it is delivered.
> >
> > 2) I'm not sure how to correctly configure jitter buffer. What is the 
> > correct way to switch the jitter buffer off? Calling 
> > rtp_session_set_jitter_compensation(s, 0) or calling nothing?
> >
> > 3) When switching the jitter buffer on do I have to call 
> > rtp_session_set_jitter_compensation() before 
> > rtp_session_enable_adaptive_jitter_compensation()? And what happens if I 
> > call rtp_session_set_jitter_compensation() after 
> > rtp_session_enable_adaptive_jitter_compensation()? Does it make sense to 
> > combine these two methods?
> >
> > 4) I've noticed that all my outgoing stream have SSID=0x29. I don't call
> > rtp_session_set_ssrc() so I would expect it to have a random value. Do 
> > you have any idea what is wrong?
> >
> > Thanks,
> > Petr
> >
> >
> > Simon Morlat wrote:
> > > Hi Petr,
> > >
> > > Your application should increment the timestamp using its theoritical
> > > value (ex: 10 ms if your application is supposed to wake up and do
> > > processing every 10 ms), no matter if it is a bit late compared to real
> > > time or not.
> > > The important is only that on the long term, the timestamp and the time
> > > elapsed are equivalent (no drift).
> > >
> > > Simon
> > >
> > > Le vendredi 20 novembre 2009 à 14:43 +0100, Petr Kuba a écrit :
> > > > Hello,
> > > >
> > > > I'm experiencing the following problem:
> > > >
> > > > Since the timer we use for calling rtp_session_recvm_with_ts() is not 
> > > > 100% precise (mainly in windows) it happens quite often that the time 
> > > > between two calls of rtp_session_recvm_with_ts() is (a little bit) 
> > > > longer that 20ms. Then it is quite often that there are already two 
> > > > packets older than current timestamp in the ortp queue.
> > > >
> > > > However, rtp_session_recvm_with_ts() calls rtp_getq() which returns only 
> > > > the last packet and discards all older packets. I believe that this is 
> > > > not good idea when we are only few ms late.
> > > >
> > > > In my case it would be better to call rtp_getq_permissive() instead of 
> > > > rtp_getq() not to miss any packets.
> > > >
> > > > What do you think? Do I miss any important idea of this algorithm? What 
> > > > is the reason for discarding a packet that we wouldn't discard e.g. just 
> > > > 1ms earlier?
> > > >
> > > > Thanks,
> > > > Petr

--
   Petr Kuba, Project Manager
   OptimSys, s.r.o
   address@hidden
   Tel: +420 541 143 065
   Fax: +420 541 143 066
   http://www.optimsys.cz