[Bug 790412] unit test failure: rtspclientsink test_record fails with GST_MESSAGE_TYPE (msg) != GST_MESSAGE_EOS

[GStreamer (GNOME Bugzilla)]

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

--- Comment #19 from Sebastian Dröge (slomo) <slomo at coaxion.net> ---
(In reply to Patricia Muscalu from comment #17)
> (In reply to Sebastian Dröge (slomo) from comment #16)
> > Also the udpsink destination in our case would have to be configured after
> > SETUP.
> > 
> > So _join_bin() should be called before SETUP (it is now, in _open()). And
> 
> Correct.
> 
> > _complete() should be called after all SETUPs to add the transport elements
> > (that's what it does, right?).
> 
> Yes, as long as we talk about the server side it's true.

I'm talking about the client, in RECORD mode. I don't care about the server for
now, it's the client that completely falls apart currently :)

> So when the stream part is provided by the client (client_side set on
> rtsp-stream) only the rtcp sending part is added to the stream in
> _complete_stream().
> "client_side" attribute should be probably changed to "receiving_mode":

What does receiving mode mean exactly? Receiving an RTP stream, so RECORD
(server) and PLAY (client)?

Or client side as in the one who connects to the RTSP server and sends
requests?

> * in receiving_mode recv_rtcp_src pad of rtpbin is active and connected to
> depay 
> * in !receiving_mode send_rtp_src is active and connected to sender part
> (created in create_sender_part()).
> If this code is supposed to be called from the rtspclientsink, we need to
> introduce more complexity, because in this case we want to add the sender
> part connected to send_rtp_src (I tried to describe the idea of
> client/server mode in the text above).

Yes, it's supposed to be called from rtspclientsink. I'm also planning a
rtspsrc2 around the RTSP infrastructure from the server, as it's more
well-designed than what exists in the rtspsrc plugin right now.

> The current design, limits the rtspclientsink's functionality (this is my
> interpretation, correct me if I'm wrong). It would be nice to use this sink
> element as a standalone plugin (it's functionality is comparable to rtspsrc
> I guess).

It is a standalone sink. It connects to an RTSP server and sends a RECORD
stream to it.


So now I'm more confused, or we're maybe talking about different things :)
Generally what would have to happen for rtspclientsink is:

1) In READY->PAUSED the rtsp-streams are created, added to the rtpbin and
blocked. This allows us to get all the information needed for sending ANNOUNCE
to the server (i.e. the SDP)

2) In PAUSED->PLAYING the sink is doing SETUP(s) and RECORD. Between the last
SETUP and RECORD, all transports are known and can be configured on the
rtsp-streams. Which can then be "completed" (-> add udpsink, appsink, etc. as
needed for the RTP streams but also for the RTCP streams. How would we know
before this where to send the RTCP?), and once RECORD has happened we can
unblock the rtsp-streams so that data gets send to the RTP sinks, and thus to
the RTSP server.

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