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

[GStreamer (GNOME Bugzilla)]

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

--- Comment #16 from Alejandro G. Castro <alex at igalia.com> ---
(In reply to Sebastian Dröge (slomo) from comment #15)
> Review of attachment 338501 [details] [review]:
> 
> Seems almost good to go
> 
> ::: gst/rtpmanager/gstrtpsession.c
> @@ +1167,3 @@
> +        gst_object_ref (rtcp_src);
> +        GST_LOG_OBJECT (rtpsession, "sending EOS");
> +        gst_pad_push_event (rtpsession->send_rtcp_src, gst_event_new_eos
> ());
> 
> Unlock before pushing the event, lock afterwards

(In reply to Sebastian Dröge (slomo) from comment #14)
> (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 :)
> 

Done: bufg #773574

Thanks very much for your review.

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