After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 552560 - new "max-lateness" property on rtpbin / jitterbuffer
new "max-lateness" property on rtpbin / jitterbuffer
Status: RESOLVED INVALID
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
git master
Other All
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2008-09-16 22:01 UTC by Håvard Graff (hgr)
Modified: 2009-01-26 15:44 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
the proposed patch (12.55 KB, patch)
2008-09-16 22:02 UTC, Håvard Graff (hgr)
rejected Details | Review

Description Håvard Graff (hgr) 2008-09-16 22:01:57 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.
Comment 1 Håvard Graff (hgr) 2008-09-16 22:02:28 UTC
Created attachment 118847 [details] [review]
the proposed patch
Comment 2 Wim Taymans 2008-09-26 09:14:45 UTC
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.