[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