[Bug 743945] rtpjitterbuffer: add "do-deadline" property

GStreamer (bugzilla.gnome.org) bugzilla at gnome.org
Thu Feb 5 02:52:04 PST 2015


https://bugzilla.gnome.org/show_bug.cgi?id=743945
  GStreamer | gst-plugins-good | 1.4.5

--- Comment #17 from Miguel París Díaz <mparisdiaz at gmail.com> 2015-02-05 10:51:56 UTC ---
The point here is when a timer for a packet lost is scheduled. There are 3
cases:
1) Commented by you:
http://cgit.freedesktop.org/gstreamer/gst-plugins-good/tree/gst/rtpmanager/gstrtpjitterbuffer.c?id=1.4.5#n1984
2) Without retransmissions:
http://cgit.freedesktop.org/gstreamer/gst-plugins-good/tree/gst/rtpmanager/gstrtpjitterbuffer.c?id=1.4.5#n2011
3) Taking into account rtx_retry_period
http://cgit.freedesktop.org/gstreamer/gst-plugins-good/tree/gst/rtpmanager/gstrtpjitterbuffer.c?id=1.4.5#n2748

So, you are right but only in the first case.

In the 3rd case, the packet will be considered lost when a timeout based on the
RTT and the jitter
(http://cgit.freedesktop.org/gstreamer/gst-plugins-good/tree/gst/rtpmanager/gstrtpjitterbuffer.c?id=1.4.5#n2683),
so the delay added is not the "latency".

Moreover, I am using a patch suggested by me few months ago:
https://bug739868.bugzilla-attachments.gnome.org/attachment.cgi?id=290320
This patch adds a property to set the max number of retransmission retries. So
if it is 0, only a retransmission will be requested, and if the related RTP
packet does not arrive on the timeout, it is considered lost (applying the 3rd
case).

You can see a set of patches to improve jitterbuffer (in our case):
https://bugzilla.gnome.org/show_bug.cgi?id=739868

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- 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