Robert:
Normally you would have something like this in the relayconfig.xml file:
<OBJECT TYPE="relay" NAME="camrelay">
<!-- an rtsp_source is used to request a stream from a server -->
<OBJECT CLASS="source" TYPE="rtsp_source">
<!-- source_addr is the address of the server -->
<PREF NAME="source_addr">63.100.142.111</PREF>
<!-- rtsp_port is the port the server is listening on -->
<PREF NAME="rtsp_port">554</PREF>
<!-- the is the url to request -->
<PREF NAME="url">/now.jpg?snap=spush</PREF>
</OBJECT>
<OBJECT CLASS="destination" TYPE="udp_destination">
<PREF NAME="ttl">5</PREF>
<PREF NAME="dest_addr">239.10.10.101</PREF>
<PREF NAME="url"></PREF>
<PREF NAME="udp_base_port">9600</PREF>
</OBJECT>
<PREF NAME="enabled">true</PREF>
</OBJECT>
The relay above tunes in on a source, and sends it to a multicast
address. The configuration above didn't work for me with your
camera/encoder. I'm not sure why, it works with other encoders
specified as the source. In all other encoders I've tested the url
references an sdp source - that might be the problem. It could also be
the format of the incoming stream isn't supported by the streaming
server. The first thing I'd look into is the possibility of getting an
sdp directly from the camera/encoder via an rtsp url - if that's
possible it would be the first thing to try.
Another source type for relays is udp. This works well if you can
configure your encoder to "push" to a specific IP address and port
numbers. In this case the source would look something like:
<OBJECT CLASS="source" TYPE="udp_source">
<!-- source_addr is the address of the server -->
<PREF NAME="source_addr">63.100.142.111</PREF>
<!-- ports the encoder is transmitting on -->
<LIST-PREF NAME="udp_ports">
<VALUE>6828</VALUE>
</LIST-PREF>
</OBJECT>
I'm not sure if the encoder you are working with supports sending to a
specific IP address and Port numbers via UDP. If so, the configuration
above can be used to relay an incoming unicast stream. If you can
configure the camera to "push" via udp to a specific IP/port you could
try the above as a source. You will need to generate the sdp file
(perhaps by sniffing the network for that data).
> Also, is there a document or collection of documents that describes
> the details in networking terminology, or even just documents all the
> details of how a connection works, who sends requests where and who
> sends data where. Are the RFCs the only options? I see that in item
> (1.) below, you state "Encoder directs a unicast stream to the server"
> - which I obviously misinterpreted before doing the packet sniffing -
> it means "The encoder pushes (sends without request) UDP stream
> packets to the server"
A good place to start is the Apple Developer Documentation on QTSS/DSS:
http://developer.apple.com/documentation/QuickTime/Streaming-date.html
For instance the Operations Overview page describes the operation of
the server:
http://developer.apple.com/documentation/QuickTime/QTSS/index.html
You are correct that I was referring to the encoder sending the stream
directly to the server (sends without a request). I could have listed a
third possibility:
3. Server requests a stream from an rtsp source and relays the stream
to an unannounced udp stream (no sdp file generated on target) or an
announced stream (sdp file generated on target).
> This particular camera is not ours, but the next camera I work with
> WILL be our own camera and we can configure it however we want. Would
> it be better to configure it as an Encoder/Broadcaster, or as a server
> (or both)? In the former, the camera would generate an SDP file which
> I would use on the QTSS, but it would also mean that I wouldn't be
> able to easily connect directly to the camera AND it would mean that
> the camera would be spewing data even if no one was watching it. In
> the server case, the camera would only generate data when being
> watched, but configuring the server is a bit more complex. Is this a
> correct assesment?
It is good to support as many options as possible. Products such as the
JVC DM-NC40 support multicast, unicast to a specific IP/port, and also
can act as a server for Unicast requests. In the case of the JVC
product these options are three different ways to configure the encoder
(only one configuration can be active at a time). Setting up an encoder
as multicast allows it to act as a server on the local multicast
enabled LAN/network, while simultaneously reflecting through a
streaming server for Unicast client connections.
If you are reflecting through a server it's a good idea to have the
packets flowing from the encoder to the server (via multicast or
directed unicast): Setting up a reflector is simpler than configuring
relays. All of the encoders I listed on my site (software and hardware)
function this way. Separating the encoder from the server lets you put
the server in the best place on your network (i.e. edge server). The
server can relay to other servers for additional scalability or inject
the stream into a content distribution network such as Akamai.
Encoders generally don't scale well as servers for multiple Unicast
requests, but having that option for a small number of client
connections is a possibility. INMHO this functionality is lower
priority than the capability to multicast and send directed unicasts to
a specific IP/ports.
Hope this helps,
-George
[demime 0.98b removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]
_______________________________________________
streaming-server-users mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/streaming-server-users
Do not post admin requests to the list. They will be ignored.
