GNOME Bugzilla – Bug 552560
new "max-lateness" property on rtpbin / jitterbuffer
Last modified: 2009-01-26 15:44:13 UTC
Working with rtpbin and jitterbuffer, we sometimes have observed that with an element downstream blocking the pipeline for some reason, the jitterbuffer can end up buffering up "unlimited" buffers. If these buffers are high definition video then memory-issues are short to follow. The proposed patch is not in any way a good solution to such a problem, since it will hide the real cause of it and should in theory never be necessary for a well written pipeline, however it can be thought of as a "security vent", making sure that there is SOME limit to how big the jitterbuffer can grow, and the sort of extra protection an application might want. The idea is that you set a time (in ms) how late a buffer can be before it gets dropped.
Created attachment 118847 [details] [review] the proposed patch
We can't use the clock in the chain function because it might be called in the PAUSED state. Isn't it enough to just check the total time size in the queue based on the rtp timestamps and drop when full? Similar to priv->drop_on_latency but then with a different limit.