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

[GStreamer (GNOME Bugzilla)]

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

--- Comment #14 from Sebastian Dröge (slomo) <slomo at coaxion.net> ---
(In reply to Alejandro G. Castro from comment #12)
> (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.

Can you open a new bug about the EOS events that come from the outside? Let's
keep this bug only about the BYE handling then :)


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


ack

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