[Bug 773218] rtpbin: pipeline gets an EOS when any rtpsources byes

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=773218

--- Comment #12 from Alejandro G. Castro <alex at igalia.com> ---
(In reply to Sebastian Dröge (slomo) from comment #11)
> (In reply to Alejandro G. Castro from comment #10)
> 
> > > For the RTP we already forward EOS events already on all the related pads,
> > > right?
> > 
> > I'm not sure about this, I did not check the code for other pads. I'll check
> > it, but it seems this is the only eos we were generating.
> 
> Basically check what the sink pad event functions are doing with EOS. If
> they do nothing (gst_pad_event_default()), then it should be fine. If they
> are doing something explicit, it might not be ok

I checked this situation, the EOS event for the receive sink pad sends the
event also fo the rtcp_src, here I wonder if we should also do the same for the
send source because without the rtcp connection not sure if the send if going
to behave. For the send sink pad it basically schedules a bye message in all
the rtpsources, there is a fixme though because it is not clear we could be
still receiving and we do not want to stop that even if the send closes. I
guess it is good solution for the moment but when checking different use cases
we could have to review that part also in the near future.

Going back to the case we are checking, we can not send EOS to the rtcp pad
when one of the sources byes because we could have still other sources alive in
the session, for instance when rtx source is closed, or when the initial dummy
source is destroyed. Trying to make sure we send the EOS in the right moment we
added it when there is no more rtpsources in the session, it is safe because we
are sure no source is open or has any pending events.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.