ccrtp-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Ccrtp-devel] adapative jitter buffer example


From: David Sugar
Subject: Re: [Ccrtp-devel] adapative jitter buffer example
Date: Tue, 05 Apr 2005 12:45:23 -0400
User-agent: Mozilla Thunderbird 1.0.2 (X11/20050403)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

If ccrtp ever has a class that implements a jitter buffer directly, it
will be an optional class.  This was meant to offer some discussion and
and provide an example of how one can create a jitter buffer using the
existing ccrtp, and not something that will be implimented within/as
part of it, except perhaps in some existing or future demo apps.

Michel de Boer wrote:
> Hi David,
> 
> I did not really study the code for jitter that you posted, but I am
> triggered by
> the topic of this mail thread. Has there always been jitter handling in
> ccRTP or
> is this just new functionality?
> 
> If it is new, I would like it if the functionality is optional, i.e. it
> can be enabled
> or disabled. Currently I am handling the jitter myself in my application
> (just a
> simple static jitter buffer).
> In the future I might remove my own jitter buffer coding in favor of the
> ccRTP
> jitter buffer stuff.
> 
> You refer to modifying your jitter handling algorithm based on received
> RTCP
> jitter reports. I wonder how you will do that. The received RTCP jitter
> reports
> only give you information on the jitter experienced at the far-end, so
> that is
> the RTP stream you are sending out. I don't see how this can help you
> handling
> the jitter you experience on the RTP stream you receive.
> 
> Regards,
> Michel
> 
> 
> David Sugar wrote:
> 
> This is a section of code I developed over the last two weekends while
> rewriting the Bayonne SIP driver code and working on the Troll server.
> It essentially attempts to implement an adaptive jitter buffer in the
> run method of a Symmetric RTP stack.  Basically, it waits for some
> "initial" packet(s) to arrive, absorbs them, and then backs off to an
> additional packet timing frame, before processing further input, one
> frame at a time, all the while maintaining a wall clock for streaming of
> outgoing data.  If there are dropped (or silence suppressed) inbound
> packets, and the input queue hence becomes empty again, it simply
> resynchronizes to the next arriving packet(s) all over again.
> 
> Federico thinks it could be adapted to be more flexible in the way it
> handles jitter by offering a settable jitter timing window larger than
> one packet frame, or perhaps even to further modify it's behavior based
> on rtcp jitter reports.  I may look at that.  Having an example of a
> reference implementation for Jitter handling in ccrtp, at least in in
> the documentation, if not in an actual example app, I think also would
> be very useful.

>>
- ------------------------------------------------------------------------
>>
void RTPStream::run(void)
{
       size_t r, n;
       size_t size = info.framesize;
       unsigned char buf[size];
       timeout_t timer;
    bool first = true;
    bool jitter;
>>
       setTimer(0);
>>
       for(;;)
       {
               incTimer(info.framing);
               setCancel(cancelDeferred);
               enter();
               if(source)
               {
                       source->getBuffer(buf, size);
                       putBuffer(buf, size);
                       r = dispatchDataPacket();
               }
               leave();
               setCancel(cancelImmediate);
>>
        if(first)
        {
            while(isPendingData(0))
            {
                            setCancel(cancelDeferred);
                           r = takeInDataPacket();
                           if(r < 0)
                                   break;
>>
                jitter = false;
                first = false;
>>
                            enter();
                           n = getBuffer(buf, r);
                           if(sink)
                                   sink->putBuffer(buf, n);
                           leave();
                           setCancel(cancelImmediate);
                    }
        }
        else if(jitter)
        {
            if(isPendingData(0))
            {
                setCancel(cancelDeferred);
                r = takeInDataPacket();
                if(r < 0)
                    break;
>>
                enter();
                n = getBuffer(buf, r);
                if(sink)
                    sink->putBuffer(buf, n);
                leave();
                setCancel(cancelImmediate);
            }
            else
                first = true;
        }
        else
            jitter = true;
>>
               timer = getTimer();
>>
               if(timer)
                       Thread::sleep(timer);
       }
}

>>
_______________________________________________
Ccrtp-devel mailing list
address@hidden
http://lists.gnu.org/mailman/listinfo/ccrtp-devel

>>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCUsCiJlWtSTiTVsYRAn+2AJ9Fe67WxIVodZrOcUpAZZvb49RArQCeOsE7
FfqfGrjatN0/+asREBS0LQM=
=KibU
-----END PGP SIGNATURE-----

Attachment: dyfet.vcf
Description: Vcard


reply via email to

[Prev in Thread] Current Thread [Next in Thread]