[Bug 722370] rtprtxsend: push rtx buffers from a different thread to avoid long retransmission delays

[GStreamer (bugzilla.gnome.org)]

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

--- Comment #2 from George Kiagiadakis <kiagiadakis.george at gmail.com> 2014-01-21 12:57:46 UTC ---
(In reply to comment #1)
> Please don't remove the tests, the reason why they fail in this case is because
> they reveal a bug in the elements. The EOS event jumps over the RTX packets and
> causes the pipeline to stop early and racily. The rtx sender should probably
> place the EOS event in the queue and only push it forward when the queue is
> drained.

Thanks for the hint. I had actually thought of something going wrong with the
EOS event, so I tried to drop all EOS events from the pad probe that is
installed right after the queue element and manually stop the pipeline a few
seconds after the last expected EOS event was received (there are 4 sources, so
4 EOS events), but that didn't really help.

But anyway, I tried to implement your suggestion and it seems that if I send
the EOS event from the srcpad task *and* flush the queue afterwards so that no
more rtx buffers can be sent, then it works.

The patch is in the same branch.

-- 
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.