[Bug 739868] rtpmanager: rtpjitterbuffer fixes and improvements

GStreamer (GNOME Bugzilla) bugzilla at gnome.org
Fri Mar 20 11:32:20 PDT 2015


https://bugzilla.gnome.org/show_bug.cgi?id=739868

Sebastian Dröge (slomo) <slomo at coaxion.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #290318|none                        |needs-work
             status|                            |

--- Comment #23 from Sebastian Dröge (slomo) <slomo at coaxion.net> ---
Comment on attachment 290318
  --> https://bugzilla.gnome.org/attachment.cgi?id=290318
0007-gstrtpjitterbuffer-add-rtp-max-dropout-property.patch

This changes the default behaviour from 3000 as rtp-max-dropout to something
adaptive. Not sure that's a good idea, the default should probably stay as is.

Then calculate_n_packets_last_second() returns the length of the queue but you
don't use that. You don't need it?

destroy_GstClockTime() should be renamed to something non-camelcase :)
clock_time_free() or something.

get_rtp_max_dropout() seems to do the wrong thing if we have less than 1 second
of packets so far. If we have more than 1 second it will amount to about 0.5s
worth of data, if we have less than 1 second (e.g. X=0.5 seconds), we will only
allow 0.25 (X/2) of dropout. I think this code should just return some default
if we didn't observe 1 second of packets yet.


I think the dts queue also needs to be reset whenever the jitterbuffer is
reset, otherwise it will contain old data that is not relevant anymore.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.


More information about the gstreamer-bugs mailing list