diff options
Diffstat (limited to 'README')
-rw-r--r-- | README | 33 |
1 files changed, 24 insertions, 9 deletions
@@ -7,32 +7,47 @@ 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. + Usage with curl: ---------------- Sending a stream (PUT): - $ curl -v http://localhost:8000/somepath -T - < [some video file] + $ curl -v "http://localhost:8000/somepath" -T - < [some video file] -Optionally, rate limit the stream to emulate a live stream (--limit-rate) +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): - $ curl -v http://localhost:8000/somepath > [some output file] + $ 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. -Usage with souphttpclientsink: ------------------------------- -/* TODO */ +Usage with souphttp: +-------------------- +Sending a stream from a file (PUT): + + $ gst-launch-1.0 filesrc location=[video file] ! \ + souphttpclientsink location="http://localhost:8000/somepath" + +This will use a persistent HTTP connection and Content-Length + Content-Range +headers to send the stream data. + +Reading a webm output stream (GET): + + $ gst-launch-1.0 souphttpsrc location="http://localhost:8000/somepath" ! \ + filesink location=[some output file] Known bugs: ----------- -* Doing a massive PUT in a single go (say, 300-400MB or more) of a webm +* 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. + 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 |