<div dir="ltr"><div><div>Thanks Ross for your detailed answers,<br><br></div>Sure, we just make subclasses of livemedia library installing it to the system as a shared library from your latest source (at least while developing we keep upgrading liveMedia). And yes we want to be able to stream to RTSP clients and to non RTSP clients. So I guess we will have to go for your suggestion of usign the stream replicator (thanks for the suggestion, it looks pretty straight forward!).<br>

<br>I completely agree that it looks like complicating things unnecessarily, but the use case we are trying to implement is to built a system that makes some multimedia process in a video conference scenario, so it stands behind and MCU. In fact we open an RTPSource for receving from an MCU -> we process some data -> and we resend it to the MCU (the MCU itselt tells to our software via a REST API the IP and Port were is going to listen for), as you sugest usign the apropiate RTPSink subclass direclty. However in this scenario we wanted as well to make the stream available via standard RTSP in order to be able to be a watcher of the videoconference (not a participant) using any standard RTSP client. Because of that when I integrated the RTSP server to our software and realized that using the flag fReuseFirstSource to true it was capable to stream to an arbitrary number of clients I though about trying emulate RTSP negotiation via direct calls to the desired ServerMediaSubsesion in order to directly stream to a non RTSP client, avoiding this way to handle different sources and let the subsession do the work. <br>

<br>Anyway, I undersand that this wired way of using ServerMediaSubsession is far from how they are supposed to be used, so trying to achieve this behaviour it may lead to a nonesense dirty hacking. Thanks for the advice.<br>

<br></div><div>Regards,<br></div>David Cassany<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">2014-07-15 16:35 GMT+02:00 Ross Finlayson <span dir="ltr"><<a href="mailto:finlayson@live555.com" target="_blank">finlayson@live555.com</a>></span>:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div class=""><blockquote type="cite"><div dir="ltr"><div>Now I am trying to achieve is to be able to stream the same source via RTSP (to any client that connects to the rtsp url) and via an static RTP/RTCP session (by static I mean that I want the server to stream to an specific IP and port, passed as a command argument for instance)<i>. </i><br>

</div></div></blockquote><div><br></div></div><div>Reading this again, I suspect that - because, in the second case, your clients won't be using RTSP - you wouldn't use a "PassiveServerMediaSubsession", or *any* subclass of "ServerMediaSubsession" for this.  (The "ServerMediaS*ession" classes are used specifically to implement RTSP servers.)</div>

<div><br></div><div>Instead, I suspect that you'll want to 'replicate' your original stream source using the "StreamReplicator" class (see the "testReplicator" demo application for an example of how to use this).  One replica will be used as a source to your "OnDemandServerMediaSubsession" subclass (with "reuseFirstSource" as "True") - for streaming to your normal RTSP clients.  The other replica would be fed directly into a "RTPSink" (subclass) object that you'd create (along with a "RTCPInstance") as a result of your command-line argument.</div>

<div><br></div><div>But anyway, why bother streaming "to an specific IP and port, passed as a command argument for instance"?  Why complicate your life unnecessarily?  Why not just use RTSP for everything?</div>

</div><div class=""><br><div>
<span style="border-collapse:separate;border-spacing:0px"><span style="border-collapse:separate;color:rgb(0,0,0);font-family:Helvetica;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:-webkit-auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">Ross Finlayson<br>

Live Networks, Inc.<br><a href="http://www.live555.com/" target="_blank">http://www.live555.com/</a></span></span>
</div>
<br></div></div><br>_______________________________________________<br>
live-devel mailing list<br>
<a href="mailto:live-devel@lists.live555.com">live-devel@lists.live555.com</a><br>
<a href="http://lists.live555.com/mailman/listinfo/live-devel" target="_blank">http://lists.live555.com/mailman/listinfo/live-devel</a><br>
<br></blockquote></div><br></div>