[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