[Live-devel] use ServerMediaSubsession for RTP & RTCP streaming

David Cassany Viladomat david.cassany at i2cat.net
Wed Jul 16 04:47:36 PDT 2014


Thanks Ross for your detailed answers,

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

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.

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.

Regards,
David Cassany


2014-07-15 16:35 GMT+02:00 Ross Finlayson <finlayson at live555.com>:

> 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)*. *
>
>
> 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.)
>
> 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.
>
> 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?
>
> Ross Finlayson
> Live Networks, Inc.
> http://www.live555.com/
>
>
> _______________________________________________
> live-devel mailing list
> live-devel at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20140716/375d9b54/attachment.html>


More information about the live-devel mailing list