README


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

Server usage:
-------------

  $ ./stp-server

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]

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]

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.

  $ curl -v "http://localhost:8000/somepath?abort"

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
  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. :-)