[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