[Bug 722370] rtprtxsend: push rtx buffers from a different thread to avoid long retransmission delays
GStreamer (bugzilla.gnome.org)
bugzilla at gnome.org
Tue Jan 21 06:01:50 PST 2014
https://bugzilla.gnome.org/show_bug.cgi?id=722370
GStreamer | gst-plugins-good | git
Wim Taymans <wim.taymans> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution| |FIXED
Target Milestone|HEAD |1.3.1
--- Comment #3 from Wim Taymans <wim.taymans at gmail.com> 2014-01-21 14:01:45 UTC ---
commit 1a300eb50967e88ad73ffeeb44a84e268d4705b8
Author: George Kiagiadakis <george.kiagiadakis at collabora.com>
Date: Tue Jan 21 13:42:38 2014 +0100
rtprtxsend: ensure that no rtx buffers are sent after EOS
To do that, enqueue the EOS event to be sent from the srcpad task
thread and flush the queue right afterwards, so that no more rtx
buffers can be sent, even if there are more requests coming in.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=722370
commit 133913a11ae35656797a7101ad0e01d484bea46b
Author: George Kiagiadakis <george.kiagiadakis at collabora.com>
Date: Wed Jan 15 09:46:14 2014 +0100
rtprtxsend: run a new GstTask on the src pad
The reason behind this is to minimize the retransmission delay.
Previously, when a NACK was received, rtprtxsend would put a
retransmission packet in a queue and it would send it from chain(),
i.e. only after a new buffer would arrive.
This unfortunately was causing big delays, in the order of 60-100 ms,
which can be critical for the receiver side.
By having a separate GstTask for pushing buffers out of rtxsend,
we can push buffers out right after receiving the event, without
waiting for chain() to get called.
--
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