[Bug 739868] rtpmanager: rtpjitterbuffer fixes and improvements

[GStreamer (GNOME Bugzilla)]

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

--- Comment #25 from Miguel París Díaz <mparisdiaz at gmail.com> ---
(In reply to Sebastian Dröge (slomo) from comment #23)
> Comment on attachment 290318 [details] [review]
> 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.
> 
By default this property has RTP_MAX_DROPOUT (3000) as value, so it is not
adaptative because get_rtp_max_dropout returns this value.

> Then calculate_n_packets_last_second() returns the length of the queue but
> you don't use that. You don't need it?
> 
This function returns the length if the user want to use it. In my case I don't
use this returned value but use the length of the queue into
get_rtp_max_dropout, so I change it to returns void.

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

> 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.
> 
Done!

> 
> 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.
Done!

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