summaryrefslogtreecommitdiff
path: root/README
diff options
context:
space:
mode:
authorNirbheek Chauhan <nirbheek@centricular.com>2014-07-24 17:56:02 (GMT)
committerNirbheek Chauhan <nirbheek@centricular.com>2014-07-24 20:55:42 (GMT)
commite0d453a3a2c120264b13c44f004025b0330547a8 (patch)
tree4517a7e8f3100f1f75b4cecd68486b42d4f7f0df /README
parentfae0aa58c19a1918e7b7750b4862e2abcbc55788 (diff)
downloadsoup-transcoding-proxy-e0d453a3a2c120264b13c44f004025b0330547a8.zip
soup-transcoding-proxy-e0d453a3a2c120264b13c44f004025b0330547a8.tar.gz
Implement concurrent RTP-UDP streams, and a REST API for status and auth
When the --token-server=ADDR/MASK argument is passed to the server, the token verification framework is enabled, and the specified subnet is allowed to access the REST API to add/revoke/list tokens that allow clients to connect, and to list/abort streams running on the server. Details about the REST API are documented in the file "REST-API". There were also some organisational and name changes in the code.
Diffstat (limited to 'README')
-rw-r--r--README71
1 files changed, 47 insertions, 24 deletions
diff --git a/README b/README
index 50c490a..6772060 100644
--- a/README
+++ b/README
@@ -7,54 +7,77 @@ Runs on port 8000 by default. Further options can be seen with the --help flag:
$ ./stp-server --help
-The server supports multiple PUT streams and multiple GET streams for each PUT
-stream.
+The server supports multiple HTTP PUT streams and multiple RTP/UDP and HTTP GET
+streams for each PUT stream.
Usage with curl:
----------------
-Sending a stream (PUT):
+> Sending a stream (PUT) for only HTTP GET streaming:
- $ curl -v "http://localhost:8000/somepath" -T - < [some video file]
+ $ curl -v "http://localhost:8000/[sessionid]?type=http" -T - < [video file]
This will use Chunked encoding and send the file in chunks.
Optionally, you can rate limit to emulate a live stream (--limit-rate)
Trying to create two streams on the same path will return a 409.
-Reading the webm output stream (GET):
+> Reading the webm output stream (GET):
- $ curl -v "http://localhost:8000/somepath" > [some output file]
+ $ curl -v "http://localhost:8000/[sessionid]" > [output file]
The server supports multiple PUT requests on different paths, and multiple GET
requests from these paths.
-A running/encoding stream can be aborted by sending a GET request with the query
-"abort" to a path where a stream is running.
+> Sending a stream (PUT) for only RTP-UDP streaming to 127.0.0.1:5004:
+
+ $ curl -v "http://localhost:8000/[sessionid]?type=rtp-udp&udp-clients=127.0.0.1:5004" -T - < [video file]
+
+> Sending a stream (PUT) for both RTP-UDP and HTTP GET streaming:
+
+ $ curl -v "http://localhost:8000/[sessionid]?type=rtp-udp,http&udp-clients=127.0.0.1:5004" -T - < [video file]
+
+> curl handles only HTTP, so there is no way to read the RTP-UDP stream using it
- $ curl -v "http://localhost:8000/somepath?abort"
Usage with souphttp:
--------------------
-Sending a stream from a file (PUT):
+> Sending a stream from a file (PUT) for only HTTP GET streaming:
$ gst-launch-1.0 filesrc location=[video file] ! \
- souphttpclientsink location="http://localhost:8000/somepath"
+ souphttpclientsink location="http://localhost:8000/[sessionid]?type=http"
This will use a persistent HTTP connection and Content-Length + Content-Range
headers to send the stream data.
-Reading a webm output stream (GET):
+> Sending a stream from a file (PUT) for only RTP-UDP streaming:
+
+ $ gst-launch-1.0 filesrc location=[video file] ! \
+ souphttpclientsink location="http://localhost:8000/[sessionid]?type=rtp-udp&udp-clients=localhost:5004"
+
+> Reading a webm output stream (GET):
- $ gst-launch-1.0 souphttpsrc location="http://localhost:8000/somepath" ! \
+ $ gst-launch-1.0 souphttpsrc location="http://localhost:8000/[sessionid]" ! \
filesink location=[some output file]
-Known bugs:
------------
-* Doing a massive PUT in a single go (say, 300-400MB or more) of a WebM
- file causes the server to become overwhelmed. This problem doesn't happen for
- non-WebM file dumps. Note however, that this is not a problem in the usual
- mode of operation using live streams.
-* Opening multiple GET streams from the same PUT stream works, but clients other
- than the first one might timeout due to a bug that is being investigated.
-* There are no queue size limit handling for PUT streams, and hence the server
- can take a lot of memory if the PUT stream is sending data faster than it can
- be encoded. In most circumstances, this is actually a feature. :-)
+> Reading an RTP-UDP output stream:
+
+ $ gst-launch-1.0 udpsrc host=127.0.0.1 port=5004 caps="application/x-rtp" ! \
+ rtpvp8depay ! vp8dec ! videoconvert ! autovideosink
+
+> Sending a stream from a file (PUT) for both RTP-UDP and HTTP GET streaming:
+
+ $ gst-launch-1.0 filesrc location=[video file] ! \
+ souphttpclientsink location="http://localhost:8000/[sessionid]?type=rtp-udp,http&udp-clients=localhost:5004"
+
+"udp-clients" is a comma-separated list of UDP host:ports to broadcast the RTP
+stream to.
+
+Token Validation:
+-----------------
+When the --token-server option is specified, only valid sessionids
+("[sessionid]" in the above examples) are allowed to PUT or GET streams. In
+addition, for RTP-UDP streams, the host and port must also be valid. These are
+checked as soon as a client connects, so these tokens must be added to the
+server's internal list before a client can connect to the server. See the
+REST-API file for details about this.
+
+If --token-server is not specified, token validation is disabled.