summaryrefslogtreecommitdiff
path: root/README
diff options
context:
space:
mode:
authorNirbheek Chauhan <nirbheek@centricular.com>2014-07-11 08:34:42 (GMT)
committerNirbheek Chauhan <nirbheek@centricular.com>2014-07-11 08:34:42 (GMT)
commit007e5281038c4ab0fe5c60e6a353949948a31ac8 (patch)
treee3005afcf71bbe9b18131bdbfd9773416299a58b /README
parente5a0de1595152c968f2b81cec6de8dc8a3ba8308 (diff)
downloadsoup-transcoding-proxy-007e5281038c4ab0fe5c60e6a353949948a31ac8.zip
soup-transcoding-proxy-007e5281038c4ab0fe5c60e6a353949948a31ac8.tar.gz
Update README and add known bugs
Diffstat (limited to 'README')
-rw-r--r--README37
1 files changed, 30 insertions, 7 deletions
diff --git a/README b/README
index 88496fe..e29f127 100644
--- a/README
+++ b/README
@@ -1,17 +1,40 @@
-Usage:
+Server usage:
+-------------
- ./stp-server
+ $ ./stp-server
-Runs on port 8000.
+Runs on port 8000 by default. Further options can be seen with the --help flag:
-Sending a stream:
+ $ ./stp-server --help
- curl -v http://localhost:8000/somepath -T - < [some video file]
+Usage with curl:
+----------------
+Sending a stream (PUT):
+
+ $ curl -v http://localhost:8000/somepath -T - < [some video file]
Optionally, rate limit the stream 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:
+Reading the webm output stream (GET):
+
+ $ curl -v http://localhost:8000/somepath > [some output file]
+
+The server supports multiple PUT requests on different paths, and multiple GET
+requests from these paths.
- curl -v http://localhost:8000/somepath > [some output file]
+Usage with souphttpclientsink:
+------------------------------
+/* TODO */
+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 the usual mode of operation using live
+ streams, where this will never happen.
+* 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. :-)