Add support for serving HLS playlists.
[cubemap] / cubemap.config.sample
1 # Uncomment to run in the background. Note that in daemonized mode, all filenames
2 # are relative to an undefined directory, so you should use absolute paths for
3 # error_log, stats_file, etc.
4
5 #daemonize
6
7 # For low-traffic servers (less than a gigabit or two), num_servers 1 is fine.
8 # For best performance in high-traffic situations, you want one for each CPU.
9 num_servers 1
10
11 #
12 # You may specify multiple input ports; save for TLS settings (TLS is automatically
13 # enabled for a port if you give a key pair), they are treated exactly the same.
14 # “port N” is equivalent to “listen [::]:N”. TLS requires kTLS support (Linux >= 4.13,
15 # CONFIG_TLS enabled).
16 #
17 port 9094
18 # listen 127.0.0.1:9095
19 # listen [::1]:9095
20 # listen [::]:443 tls_cert=/etc/letsencrypt/live/example.org/fullchain.pem tls_key=/etc/letsencrypt/live/example.org/privkey.pem
21
22 stats_file cubemap.stats
23 stats_interval 60
24
25 input_stats_file cubemap-input.stats
26 input_stats_interval 60
27
28 # Logging of clients as they disconnect (and as such as no longer visible in the stats file).
29 # You can only have zero or one of these.
30 access_log access.log
31
32 # Logging of various informational and error messages. You can have as many of these as you want.
33 error_log type=file filename=cubemap.log
34 error_log type=syslog
35 error_log type=console
36
37 #
38 # Now the streams! There are two types of streams; stream (HTTP output)
39 # and udpstream (UDP output). Let's take stream first.
40 #
41
42 # A basic form of stream, with HTTP input. Often, you will need no more than this.
43 # The input must be Metacube framed (VLC can produce this with an option).
44 stream /test.flv src=http://gruessi.zrh.sesse.net:4013/test.flv
45
46 # Streams can share the same input (the same is reused, no extra bandwidth needed).
47 # force_prebuffer=<number of bytes> is a parameter where we don't start sending
48 # any data to a newly connected client before we can do that many bytes at once.
49 # This is useful for clients that don't properly buffer themselves before starting
50 # playing, e.g., most web browsers and some Flash players when playing from HTTP
51 # (e.g., JW Player).
52 stream /test-jwplayer.flv src=http://gruessi.zrh.sesse.net:4013/test.flv force_prebuffer=1500000
53
54 # encoding=metacube means the _output_ will be Metacube framed. This is useful
55 # for sending on to another Cubemap instance.
56 stream /test.flv.metacube src=http://gruessi.zrh.sesse.net:4013/test.flv encoding=metacube
57
58 # A stream where the input is _not_ Metacube framed. Note that the stream needs to
59 # have no header and be self-synchronizing (like with UDP input below), and most formats
60 # are not like this. A typical example, however, is MPEG-TS.
61 stream /test.ts src=http://gruessi.zrh.sesse.net:4013/test.ts src_encoding=raw
62
63 # If your input has PTS Metacube2 blocks (currently only generated by
64 # Nageru >= 1.7.2 with MP4 output) and is segmentable (in practice MP4 with the
65 # right tags, again typically generated by Nageru), you can serve HLS fragments
66 # out of Cubemap's regular backlog, with the playlist served at the given URL
67 # (in this case, /stream.m3u8). This allows you to serve video directly to
68 # Mobile Safari (you'll need iOS >= 10 for fMP4 support; older iOS only
69 # supports TS), and also allow rewinding in the stream if your backlog is large
70 # enough. As of April 2018, iOS and hls.js seem to work well, while at least
71 # VLC and mpv appear to be buggy.
72 #
73 # hls_frag_duration= sets the maximum fragment size in seconds; the default, 6,
74 # is Apple's default recommendation. Larger fragments will cause more latency but
75 # fewer HTTP requests (less chance of performance problems). (Typically, you'll want
76 # a bit longer backlog than the default of 10 MB, as you won't fit many six-second
77 # fragments into that.) Setting hls_backlog_margin= makes Cubemap not expose any
78 # new fragments that are too far, measured in bytes, from the beginning of the
79 # backlog, in order to reduce the risk of not managing to deliver them before
80 # they rotate out. The default is zero, but you almost certainly want to change that
81 # to be some reasonable fraction of your fragment length.
82 stream /stream.mp4 src=http://gruessi.zrh.sesse.net:9095/test.mp4.metacube hls_playlist=/stream.m3u8 hls_frag_duration=6 backlog_size=20971520 hls_backlog_margin=1048576 allow_origin=*
83
84 # UDP input. TS is the most common container to use over UDP (you cannot
85 # take any arbitrary container and expect it to work).
86 # backlog_size=<number of bytes> overrides the backlog, which is normally 10 MB.
87 # If clients fall more behind than the backlog (plus the socket buffer),
88 # they will drop data, so if you have extremely high-bitrate streams, you may want
89 # to increase this. Or conversely, if you have little RAM and many streams
90 # (or many servers) you can decrease it.
91 stream /udp.ts src=udp://@:1234 backlog_size=1048576
92
93 # An example of IPv4 multicast input. Cubemap will subscribe to the given group
94 # and wait for data sent by any sender to the given port.
95 # pacing_rate_kbit=<number of kilobit/sec> will ask the kernel to hard-limit
96 # the TCP transfer rate, including retransmits, to the given speed. (This is a
97 # no-op if you do not use the sch_fq packet scheduler, which is not the default
98 # but can be set in Linux 3.13 and newer using tc.) This is extremely
99 # useful for reducing packet loss and thus including throughput, since it means
100 # that packets arrive smoothly instead of in tight bursts, which will often
101 # overload underbuffered routers and cause drops (imagine receiving a 100 kB
102 # keyframe at 10gig speeds, and then having to meter it out over 5 Mbit ADSL).
103 # The rate should be a bit higher than your stream bitrate to allow for retransmits.
104 stream /udp-multicast.ts src=udp://@233.252.0.2:1234 pacing_rate_kbit=2000
105
106 # IPv6 SSM (Single Source Multicast) input. Subscribes to the given group and
107 # waits for packets from the given sender only. SSM is nicer than ASM in that
108 # it does not require a Rendezvous Point (RP) and other complexity, but is
109 # often poorly supported in various network equipment.
110 stream /udp-multicast-ssmv6.ts src=udp://[2001:67c:29f4::32]@[ff3e::1000:0]:1234 pacing_rate_kbit=20000
111
112 # udpstream takes src= inputs just like stream does, but instead of waiting
113 # for TCP connections on ports, it immediately sends the packets out over UDP.
114 # (As with UDP input, this probably only works well for TS mux.)
115 udpstream [2001:67c:29f4::50]:5000 src=http://pannekake.samfundet.no:9094/frikanalen.ts.metacube
116
117 # udpstream takes pacing_rate_kbit= just like stream. None of the other options
118 # make sense.
119 udpstream 193.35.52.50:5001 src=http://pannekake.samfundet.no:9094/frikanalen.ts.metacube pacing_rate_kbit=2000
120
121 # IPv4 multicast output, to the given group. You can explicitly set the TTL
122 # and/or multicast output interface, if the defaults do not suit you.
123 udpstream 233.252.0.1:5002 src=http://pannekake.samfundet.no:9094/frikanalen.ts.metacube ttl=32 multicast_output_interface=eth1
124
125 # A type of HTTP resource that is not a stream, but rather just a very simple
126 # document that a HTTP 204 response and nothing else. allow_origin= is optional;
127 # if it is set, the response will contain an Access-Control-Allow-Origin header
128 # with the given value, allowing the ping response to be read (and
129 # differentiated from an error) from a remote domain using XHR.
130 #
131 # If you have a stream and a gen204 endpoint with the same URL, the stream takes
132 # precedence and the ping endpoint is silently ignored.
133 gen204 /ping allow_origin=*