Using QTSS and Broadcaster on a separate machines, along with a packet
sniffer, I have discovered a few things:
An original question I had was "how does the broadcast application
start and stop it's stream to the server?"
After doing packet sniffing, I see that the Broadcaster PUSHES the RTP
stream to the server that is specified in the Broadcaster configuration
screen. This is not how I originally thought it worked, I thought the
Server would REQUEST the stream from the Broadcast application if there
were any viewers attached to the Server - hence my first basic
misconception of how the system works.
The camera is NOT doing this, the camera is acting as a server, not a
broadcast source. Based on this, it look like I need to configure QTSS
as a Relay from the Camera to the QTSS server machine.
I did a packet sniff of a connection from QuickTime player to the
camera (i.e., I entered the URL in 'Open URL' in QT Player). Here is
what I got (BTW, the map=jpeg.elf in the URI just makes the camera run
at a higher framerate for local viewing - for internet, don't use it,
use what I showed above):
---------- Host to Camera - port 554 -------------
DESCRIBE rtsp://192.168.1.48/now.jpg?snap=spush&map=jpeg.elf
RTSP/1.0..CSeq: 1
Accept: application/sdp
Bandwidth: 2147483647
Accept-Language: en-US
User-Agent: QTS (qtver=6.5;cpu=PPC;os=Mac 10.3.2)
<CRLF>
---------- Camera to Host - port 554 -------------
RTSP/1.0 200 OK
Server: Gordian Embedded1.0..CSeq: 1
Content-Type: application/sdp
Content-Length: 247
Cache-Control: must-revalidate
Content-base: rtsp://192.168.1.48/now.jpg/
Date: Tue, 30 Mar 2004 18:53:56 GMT
Last-Modified: Tue, 30 Mar 2004 18:53:56 GMT
<CRLF>
v=0
c=IN IP4 192.168.1.48
a=range:npt=0-
a=x-qt-text-nam:trash
a=x-qt-text-cpy:
a=x-qt-text-inf:Live A/V stream
a=x-qt-text-aut:
a=x-qt-text-cmt:opts: snap=spush&map=jpeg.elf
m=video 0 RTP/AVP 26
a=control:trackID=2
a=x-bufferdelay:0
---------- Host to Camera - port 554 -------------
SETUP rtsp://192.168.1.48/now.jpg/trackID=2 RTSP/1.0
CSeq: 2
Transport: RTP/AVP;unicast;client_port=6970-6971
x-retransmit: our-retransmit
x-dynamic-rate: 1
x-transport-options: late-tolerance=2.900000
User-Agent: QTS (qtver=6.5;cpu=PPC;os=Mac 10.3.2)
Accept-Language: en-US
<CRLF>
---------- Camera to Host - port 554 -------------
RTSP/1.0 200 OK
Server: Gordian Embedded1.0
CSeq: 2
Content-Type: application/octet-stream..Content-Length: 0
Cache-Control: must-revalidate
Session: 380533611
Transport: RTP/AVP;unicast;server_port=6972-6973;client_port=6970-6971
Date: Tue, 30 Mar 2004 18:53:57 GMT
Last-Modified: Tue, 30 Mar 2004 18:53:57 GMT
<CRLF>
---------- Host to Camera - port 554 -------------
PLAY rtsp://192.168.1.48/now.jpg?snap=spush&map=jpeg.elf RTSP/1.0
CSeq: 3
Range: npt=0.000000-
x-prebuffer: maxtime=2.000000
Session: 380533611
User-Agent: QTS (qtver=6.5;cpu=PPC;os=Mac 10.3.2)
<CRLF>
As you can see in the second packet, the camera is sending an SDP file,
even though the URL doesn't contain a direct reference to an SDP file
(which is perfectly fine, right!?).
So am I correct in my interpretation that to get QTSS to function as a
Unicast reflector, I need to configure it as a Relay From the camera to
the QTSS machine? My problem here is that each time I configure a
source, it "magically disappears" from the source list after a couple
of minutes.
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"
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?
Robert
On Mar 29, 2004, at 10:36 PM, George Cook wrote:
Robert:
The general ways to reflect a broadcast through the streaming server
are:
1. Encoder directs a unicast stream to the server. The server tunes in
on the unicast stream and reflects the stream to clients as unicast
streams.
... snip ...
Hope the above makes sense. If this is one of your company's cameras
and you have one accessible on the Internet, I can tune in on it and
see if I can figure out some of the details outlined above...
-George
On Mar 29, 2004, at 4:35 PM, Robert G Palmer Jr wrote:
To no avail, I have searched the archives, google, etc...
I have a network video camera that can be accessed via an rtsp URL
(rtps://mycamera/imgstream.jpg). I want to use QTSS to allow many
users to view this stream using multicast. I can't figure out how to
configure this. I can open QT Player and type the above URL into
"Open URL in a new window" and it plays just fine.
