<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
--></style><title>Re: [Live-devel] Unicast and Multicast from a
single sourc</title></head><body>
<blockquote type="cite" cite><font face="Times New Roman">I want to
make a server that will stream from a single source to multiple
unicast clients and at least one multicast address. To further
complicate matters I believe it will need to support ASM (I haven't
been able to convince Quicktime to supports SSM).</font><br>
<font face="Times New Roman"></font></blockquote>
<blockquote type="cite" cite><font face="Times New Roman">Before I go
too far down the wrong path I thought I'd pose the problem to the
mailing list for any suggestions.</font><br>
<font face="Times New Roman"></font></blockquote>
<blockquote type="cite" cite><font face="Times New Roman">I see three
options:</font><br>
<font face="Times New Roman"></font></blockquote>
<blockquote type="cite" cite><font face="Times New Roman">1. Use two
different server sessions one for unicast (OnDemand based subsession)
and a separate session for multicast (Passive based
subsession)</font></blockquote>
<div><br></div>
<div>This is by far the best solution, because it doesn't require
messing around with the existing RTSP/RTP implementation - which works
well as is. The RTSP protocol works differently for unicast and
multicast streams, and I definitely don't recommend trying to hack the
unicast implementation to support multicast, or vice versa.</div>
<div><br></div>
<div><br></div>
<blockquote type="cite" cite><font face="Times New Roman"> then
feed them from a single FramedSource.</font></blockquote>
<div><br></div>
<div>No, each would need to read from a different "FramedSource"
(because the implementation of "FramedSource" does not allow
more than one object to read from a single
"FramedSource").</div>
<div><br></div>
<div>However, is your input source accessible as a file (e.g., in
/dev/)? If so, then you could probably just create two separate
"ByteStreamFileSource" objects, each reading from this
file.</div>
<div><br></div>
<div>If, however, your input source is not accessible as a file, then
you would need to</div>
<div><x-tab> </x-tab>1/
Write a class (which would *not* be a "FramedSource"
subclass to encapsulate it), and</div>
<div><x-tab> </x-tab>2/
Write a FramedSource subclass that encapsulates a single copy of data
from the source.</div>
<div>This is nontrivial, but you could use the existing
"MPEG1or2Demux" and "MPEG1or2DemuxedElementaryStream"
code as a model, because this does something similar.</div>
<div><br></div>
<div><br></div>
<blockquote type="cite" cite><font face="Times New Roman"> This
has complications in the design of the
FramedSource</font></blockquote>
<div><br></div>
<div>Yes, but that's much simpler than hacking with the RTSP/RTP
code.</div>
<div><br></div>
<div><br></div>
<blockquote type="cite" cite><font face="Times New Roman"> and it
duplicates the RTP framing and buffering.</font></blockquote>
<div><br></div>
<div>That really doesn't matter at all. You just create two
"RTPSink" (subclass) objects instead of one.</div>
<x-sigsep><pre>--
</pre></x-sigsep>
<div><br>
Ross Finlayson<br>
Live Networks, Inc.<br>
http://www.live555.com/</div>
</body>
</html>