[Live-devel] Re: Integrate multicast and on-demand unicast

[worm520]

> It sounds like you will need to modify your input source object to deliver
> to *two* downstream objects rather than just one.  The easiest way to do
> this is probably to have your input source class create two dependent
> objects (of some new "FramedSource" subclass).  This new "FramedSource"
> subclass would - as usual - implement "doGetNextFrame()".  In this case,
> "doGetNextFrame()" would ask the parent input source object for data.  The
> parent would deliver data, but would handle new incoming data (i.e., from
> the input encoder device) only when both dependent objects have been served.
> 
>         Ross Finlayson
>         LIVE.COM
>         <http://www.live.com/>
> 

Your suggestions are appreciated! However, I am not still very clear
about the modification on the data flow. Actually, what I imagine is a
smart OnDemandRTSPServer which handles each client session according
to its source address and the given network mask, that is, if the
client is located on the same subnet, the media subsession choose to
present an SDP description and RTSP response that directing the client
to access the media via multicast instead of unicast. Otherwise,
unicast is applied as usual. Therefore, the server maintains only a
server media session with a single RTSP URL.

What I first try is to modify the OnDemandServerMediaSubsession. I put
the logic in its method getStreamParameters() and alter
setSDPLinesFromRTPSink() to make it output appropriate SDP description
but have difficulty since at the time server generates the SDP, the
client info is not passed into generateSDPDescription() and the
current design of ServerMediaSession seems to generate it sdpLines
only once without caring where the client comes from. Anyway, I
modified the possible involved sources to achive the goal but  failed
at last even though the multicast destinations is added, the stream
state is played and the corresponding SDP is generated. Needless to
say, I must miss some details.

As a result, I adopt another simple approach and it works basically as
expected. The idea is to share a sink between ServerMediaSessions.
Howevery, the current design interface seems not to support this. So I
modify the interface again to let OnDemandServerMediaSubsession accept
an played RTPSink and RTCPInstance pointers. The sink has already
contain a predetermined multicast address and serves the
PassiveServerMediaSession. All that we should take care of is to reuse
the groupsock in the sink in the OnDemandServerMediaSubsession. This
alleviate the latency problem when we combine both
OnDemandServerMediaSubsession and PassiveServerMediaSession to stream
the same live source. However, the solution is not smart and elegant
enough: a client still needs to distinquish between the two RTSP URL
to determine which one can satisfy his requirement without puting
extra burden on the server. Besides, the interfaces change will
ripples over all the necessarysubclasses if other media type is
adopted.

Finally, I have some more questions to ask:

1. According to the test***Streamer, does the RTCP instance hanles the
RTCP reports for each multicast client ?

2. The build-in RTSP server seems not to support the redirect method ?
It would be helpful to switch a client between different server media
sessions.

3. The build-in RTSP server seems not to support RTP over HTTP ? I ran
openRTSP and set the option -T but the server response a bad request.

Also, some suggestions:

1. What about refining the relationships among ServerMediaSubsessions
to help share sinks and sources more elegantly ?

2. How about compiling the library based on uClibc? This may help
reduce the code size for application running on certain embedded
systems where only static linking is provided.

3.  I complie the library successfully on a linux platform which is on
top of a BSP-15 VLIW SoC (from Equator tech.). It should be convenient
if the following config.bsplinux is added to the next release:

CROSS_COMPILE=
COMPILE_OPTS =          $(INCLUDES) -I. -O2 -DSOCKLEN_T=socklen_t
-DNO_STRSTREAM=1
C =                     c
C_COMPILER =            $(CROSS_COMPILE)ecc
C_FLAGS =               $(COMPILE_OPTS)
CPP =                   cpp
CPLUSPLUS_COMPILER =    $(CROSS_COMPILE)e++
CPLUSPLUS_FLAGS =       $(COMPILE_OPTS) -Wall -DBSD=1
OBJ =                   o
LINK =                  $(CROSS_COMPILE)e++ -o
LINK_OPTS =             -L.
CONSOLE_LINK_OPTS =     $(LINK_OPTS)
LIBRARY_LINK =          $(CROSS_COMPILE)eld -o
LIBRARY_LINK_OPTS =     $(LINK_OPTS) -r -Bstatic
LIB_SUFFIX =                    a
LIBS_FOR_CONSOLE_APPLICATION = -lm
LIBS_FOR_GUI_APPLICATION =
EXE =
---------------------------------------------------------------------------------
BTW, a compile error can be fixed by changing the following in
ByteStreamFileSource.cpp

#if defined(_WIN32_WCE)
        return fseek(fid, (long)(offset), whence);
#else
        return fseeko(fid, (off_t)(offset), whence);
#endif

to

#if defined(_WIN32_WCE)
        return fseek(fid, (long)(offset), whence);
#else
        return fseek(fid, (off_t)(offset), whence);
#endif

However, I am not sure about the impact ~~

Thanks in advance.
Worm