[Live-devel] OnDemandServerMediaSubsession and FramedSource subclassing

[Zdenek Bouresh]

Hello,
I have done what you are describing.
Extended on demand server to stream on demand from unicast or multicast to
unicast or multicast clients any UDP or RTP TS stream.

Its rather simple once you get the hang of it.
Stared at it for a month then came up with  working code in 1-2 days.

Contact me, perhaps we can exchange knowledge.

Zed

On Fri, Dec 10, 2010 at 3:23 PM, Wiser, Tyson <TWiser at logostech.net> wrote:

> Ross,
>
> Thanks for the help.  After doing a quick test it appears that making the
> suggested modifications to my subclass of "OnDemandServerMediaSubsession"
> does work as expected.  I appreciate your great work on this library.
>
> Tyson
>
> -----Original Message-----
> From: live-devel-bounces at ns.live555.com [mailto:
> live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson
> Sent: Friday, December 10, 2010 3:10 AM
> To: LIVE555 Streaming Media - development & use
> Subject: Re: [Live-devel] OnDemandServerMediaSubsession and FramedSource
> subclassing
>
> >Basically, I need a server that streams data on demand from a live
> >source to a client.  The stream needs to be able to be sent using
> >either unicast or multicast to an address and port combination
> >dictated by the client in the SETUP message.
>
> It's usually the server, not the client, that decides whether or not
> the stream is unicast or multicast.  The usual way for a server to
> support both kinds of stream is to have both a
> "OnDemandServerMediaSubsession" and a "PassiveServerMediaSubsession"
> - with different names, of course.  The client could use the stream
> name to choose between unicast and multicast.
>
> In principle this would work, but in your case you'd have a problem:
> The 'reuseFirstSource' mechanism has been implemented only for
> "OnDemandServerMediaSubsession"s; not for
> "PassiveServerMediaSubsession".  Furthernore, there's no way for
> those two separate classes to share the same input source.  So, to
> have both the unicast and multicast streams reading from the same
> source, you'd need to modify the code.
>
> A simpler alternative is to do what you seem to be doing: Allow the
> client to specify the destination address (i.e., unicast or
> multicast), using a "destination=" parameter in the RTSP "SETUP"
> message.  To support this, you'll need to define
>        RTSP_ALLOW_CLIENT_DESTINATION_SETTING
> before you compile "RTSPServer.cpp"; I presume that you've done this.
>
>
> >First, if I wanted to subclass OnDemandServerMediaSubsession to
> >handle multicast as well as unicast, is it sufficient to change
> >getStreamParameters() so that it doesn't automatically set
> >isMulticast to False, but instead sets it based on the destination
> >address?
>
> I haven't tested this, but yes, I believe so.  It should be easy:
> Your subclass could redefine the "getStreamParameters()" virtual
> function to do this:
>
> void mySubclass::getStreamParameters( ...parameters... ) {
>        OnDemandServerMediaSubsession::getStreamParameters( ...parameters...
> );
>        if (IsMulticastAddress(destinationAddress) isMulticast = True;
> }
>
>
> >The problem, when using OnDemandServerMediaSubsession, is that I
> >don't know how to get a reference to my source object.  That object,
> >as the name of the class implies, is created on demand and I have
> >not found any functions that return to me a FramedSource* or a
> >RTPSink*.  I have made sure that I set reuseFirstSource to True when
> >creating the OnDemandServerMediaSubsession subclass, which I
> >understand to mean that there will only ever be one source.  Is
> >there a way to get a reference to that source?
>
> Yes, when your "OnDemandServerMediaSubsession " subclass creates a
> source object - in your implementation of the
> "createNewStreamSource()" virtual function - you can store a pointer
> to the source object (e.g., in a global variable).  (Because
> "reuseFirstSource" is true, "createNewStreamSource()" should be
> called just once, so there will be only one such source object.)
> --
>
> 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
>
> _______________________________________________
> live-devel mailing list
> live-devel at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel
>



-- 
Zdenek Bouresh
NextStream LTD.

The information contained within this email transmission and any attachments
is confidential and intended solely for the attention and use of the named
individual addressee(s) or entity. It may not be legally revealed or be
disclosed to any other person or third party without the express authority
(prior written approval) of NextStream LTD and/or the original recipient, or
the intended recipients, or both. If you are not the intended recipient, you
must not disclose, copy, distribute, print, rely on or retain this message
or any part of it. The information contained within is strictly prohibited.
If you have received this email in error please notify the sender by reply,
and delete this message from your email system(s). Any hard copies must also
be destroyed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20110114/ffb58087/attachment-0001.html>