better description is our "server process" embeds "rtsp server" and "video player". another process on the same machine acts as a "rtsp client" for "playback control" without receiving rtp packets. because "rtsp server" and "video player" code runs in the same process no need to send the packets over a socket. if a "local video sink" implementation handles "rtcp reception reports" (session timeout prevention) this can work?
thanks, gerald On Mon, Jun 15, 2020 at 9:00 PM <live-devel-requ...@us.live555.com> wrote: > Send live-devel mailing list submissions to > live-devel@lists.live555.com > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.live555.com/mailman/listinfo/live-devel > or, via email, send a message with subject or body 'help' to > live-devel-requ...@lists.live555.com > > You can reach the person managing the list at > live-devel-ow...@lists.live555.com > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of live-devel digest..." > > > Today's Topics: > > 1. local rtsp client playback control only (Gerald Hansink) > 2. Re: local rtsp client playback control only (Ross Finlayson) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 15 Jun 2020 13:53:54 +0200 > From: Gerald Hansink <gerald.hans...@ieee.org> > To: live-de...@us.live555.com > Subject: [Live-devel] local rtsp client playback control only > Message-ID: > <CANfiUfdue7k9Rk= > np16xv8zwzvnmqbpuxdo7zeupujawbbe...@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > hi ross, > > for the use case where client is only used as "playback controller" without > consuming video and the rtsp server acts as a "local video player". > do you think this can be "easily" supported by implementing own "video > sink" / "media session"? > > thanks, > gerald > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://lists.live555.com/pipermail/live-devel/attachments/20200615/2d5c2ecf/attachment-0001.htm > > > > ------------------------------ > > Message: 2 > Date: Tue, 16 Jun 2020 03:59:38 +1200 > From: Ross Finlayson <finlay...@live555.com> > To: LIVE555 Streaming Media - development & use > <live-de...@us.live555.com> > Subject: Re: [Live-devel] local rtsp client playback control only > Message-ID: <187bb12d-f1da-40d3-9548-fd0499614...@live555.com> > Content-Type: text/plain; charset=utf-8 > > > > > On Jun 15, 2020, at 11:53 PM, Gerald Hansink <gerald.hans...@ieee.org> > wrote: > > > > hi ross, > > > > for the use case where client is only used as "playback controller" > without consuming video and the rtsp server acts as a "local video player". > > I?m not sure what you mean by 'rtsp server acts as a "local video > player??. The RTSP server is the thing that responds to RTSP commands. It > is usually the thing that transmits outgoing RTP (i.e., media) packets. In > contrast, a ?video player? is the thing that renders/displays incoming > media packets. > > However, the first part of your statement makes sense. It is possible for > the RTSP client to just send RTSP commands (to the RTSP server), without > actually receiving incoming RTP (i.e., media) packets from the server. (In > this case, a separate process - running on the same computer - would > usually receive the incoming RTP packets.) > > To do this, your client would need to specify which UDP port number (on > the same computer) would be used to receive the incoming RTP packets. (I?m > assuming a unicast stream here; for a multicast stream, it?s usually the > server that chooses the port number (and destination IP multicast > address).) To do this, look at how our ?openRTSP? application implements > the > -r (?don?t receive?) > and > -p <startingPortNumber> > options; see > http://live555.com/openRTSP/#no-receive > > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > live-devel mailing list > live-devel@lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > > > ------------------------------ > > End of live-devel Digest, Vol 199, Issue 3 > ****************************************** >
_______________________________________________ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
