Interesting, I'll definitely have to try out the new code whenever it is ready. In the mean time, at least the current jitter buffer will be a bit more useful.
Regards, ~Scott On Thursday 18 January 2007 06:51, Philippe Khalaf wrote: > Hi, > As a side note, this whole jitterbuffer is going to be replaced soon > by completely new code that actually works :) But the test app will be > very useful. > > Regards, > Philippe > > > On Thu, 18 Jan 2007 12:20:00 +0200 (EET) > > Kai Vehmanen <[EMAIL PROTECTED]> wrote: > > Hi, > > > > On Thu, 18 Jan 2007, Scott Zuk wrote: > > > I've run into a bug with the jitter buffer implementation in rtpbin > > > that causes the jitter buffer to stop working when there is some packet > > > loss in the rtp stream. I have attached a simple testcase and a patch > > > that I believe corrects the problem. > > > > [...] > > > > > I believe the problem is in gst_rtp_jitter_buffer_add_to_queue with the > > > 'late packet' case. There should be a condition that checks that the > > > timestamp of the newly received packet is actually less than > > > jbuffer->min_ts otherwise the > > > > thanks for the patch! I just committed this to the darcs tree. > > > > > Anyway, please try out my patch, it has some extra debugging code to > > > print out the data in the queue that probably isn't needed but helped > > > with debugging. Without the patch you will see the jitter buffer get > > > "stuck" when packets are lost, but with the patch the jitter buffer is > > > able cope with larger gaps in rtp seqnum/timestamp caused by packet > > > loss. > > > > Hmm, the test app would be a nice addition to the default set of utils > > built. > > > > > I also had to fix some pretty > > > evil errors in priv_compare_rtp_seq_lt and priv_delta_rtp_ts. Half of > > > 16 bit range is 1<<15 not 1<<7 (which is only 128), and half of 32 bit > > > range is 1<<31 not G_MAXUINT16. Looks like somebody was thinking in > > > base 10 ;) > > > > Ugh, yes, those are not quite right (either comments or code need fixing, > > preferably the latter ;)). 128 seqs is still multiple seconds worth of > > media, so the code does work most of the time, but yeah, a stupid, stupid > > bug. > > > > -- > > under work: Sofia-SIP at http://sofia-sip.sf.net > > > > ------------------------------------------------------------------------- > > Take Surveys. Earn Cash. Influence the Future of IT > > Join SourceForge.net's Techsay panel and you'll get the chance to share > > your opinions on IT & business topics through brief surveys - and earn > > cash > > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > > _______________________________________________ > > Farsight-devel mailing list > > Farsight-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/farsight-devel > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share > your opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Farsight-devel mailing list > Farsight-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/farsight-devel ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Farsight-devel mailing list Farsight-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/farsight-devel
