# Uncomment to run in the background. Note that in daemonized mode, all filenames # are relative to an undefined directory, so you should use absolute paths for # error_log, stats_file, etc. #daemonize # For low-traffic servers (less than a gigabit or two), num_servers 1 is fine. # For best performance in high-traffic situations, you want one for each CPU. num_servers 1 # # You may specify multiple input ports; save for TLS settings (TLS is automatically # enabled for a port if you give a key pair), they are treated exactly the same. # “port N” is equivalent to “listen [::]:N”. TLS requires kTLS support (Linux >= 4.13, # CONFIG_TLS enabled). # port 9094 # listen 127.0.0.1:9095 # listen [::1]:9095 # listen [::]:443 tls_cert=/etc/letsencrypt/live/example.org/fullchain.pem tls_key=/etc/letsencrypt/live/example.org/privkey.pem stats_file cubemap.stats stats_interval 60 input_stats_file cubemap-input.stats input_stats_interval 60 # Logging of clients as they disconnect (and as such as no longer visible in the stats file). # You can only have zero or one of these. access_log access.log # Logging of various informational and error messages. You can have as many of these as you want. error_log type=file filename=cubemap.log error_log type=syslog error_log type=console # # Now the streams! There are two types of streams; stream (HTTP output) # and udpstream (UDP output). Let's take stream first. # # A basic form of stream, with HTTP input. Often, you will need no more than this. # The input must be Metacube framed (VLC can produce this with an option). stream /test.flv src=http://gruessi.zrh.sesse.net:4013/test.flv # Streams can share the same input (the same is reused, no extra bandwidth needed). # force_prebuffer= is a parameter where we don't start sending # any data to a newly connected client before we can do that many bytes at once. # This is useful for clients that don't properly buffer themselves before starting # playing, e.g., most web browsers and some Flash players when playing from HTTP # (e.g., JW Player). stream /test-jwplayer.flv src=http://gruessi.zrh.sesse.net:4013/test.flv force_prebuffer=1500000 # encoding=metacube means the _output_ will be Metacube framed. This is useful # for sending on to another Cubemap instance. stream /test.flv.metacube src=http://gruessi.zrh.sesse.net:4013/test.flv encoding=metacube # A stream where the input is _not_ Metacube framed. Note that the stream needs to # have no header and be self-synchronizing (like with UDP input below), and most formats # are not like this. A typical example, however, is MPEG-TS. stream /test.ts src=http://gruessi.zrh.sesse.net:4013/test.ts src_encoding=raw # UDP input. TS is the most common container to use over UDP (you cannot # take any arbitrary container and expect it to work). # backlog_size= overrides the backlog, which is normally 10 MB. # If clients fall more behind than the backlog (plus the socket buffer), # they will drop data, so if you have extremely high-bitrate streams, you may want # to increase this. Or conversely, if you have little RAM and many streams # (or many servers) you can decrease it. stream /udp.ts src=udp://@:1234 backlog_size=1048576 # An example of IPv4 multicast input. Cubemap will subscribe to the given group # and wait for data sent by any sender to the given port. # pacing_rate_kbit= will ask the kernel to hard-limit # the TCP transfer rate, including retransmits, to the given speed. (This is a # no-op if you do not use the sch_fq packet scheduler, which is not the default # but can be set in Linux 3.13 and newer using tc.) This is extremely # useful for reducing packet loss and thus including throughput, since it means # that packets arrive smoothly instead of in tight bursts, which will often # overload underbuffered routers and cause drops (imagine receiving a 100 kB # keyframe at 10gig speeds, and then having to meter it out over 5 Mbit ADSL). # The rate should be a bit higher than your stream bitrate to allow for retransmits. stream /udp-multicast.ts src=udp://@233.252.0.2:1234 pacing_rate_kbit=2000 # IPv6 SSM (Single Source Multicast) input. Subscribes to the given group and # waits for packets from the given sender only. SSM is nicer than ASM in that # it does not require a Rendezvous Point (RP) and other complexity, but is # often poorly supported in various network equipment. stream /udp-multicast-ssmv6.ts src=udp://[2001:67c:29f4::32]@[ff3e::1000:0]:1234 pacing_rate_kbit=20000 # udpstream takes src= inputs just like stream does, but instead of waiting # for TCP connections on ports, it immediately sends the packets out over UDP. # (As with UDP input, this probably only works well for TS mux.) udpstream [2001:67c:29f4::50]:5000 src=http://pannekake.samfundet.no:9094/frikanalen.ts.metacube # udpstream takes pacing_rate_kbit= just like stream. None of the other options # make sense. udpstream 193.35.52.50:5001 src=http://pannekake.samfundet.no:9094/frikanalen.ts.metacube pacing_rate_kbit=2000 # IPv4 multicast output, to the given group. You can explicitly set the TTL # and/or multicast output interface, if the defaults do not suit you. udpstream 233.252.0.1:5002 src=http://pannekake.samfundet.no:9094/frikanalen.ts.metacube ttl=32 multicast_output_interface=eth1 # A type of HTTP resource that is not a stream, but rather just a very simple # document that a HTTP 204 response and nothing else. allow_origin= is optional; # if it is set, the response will contain an Access-Control-Allow-Origin header # with the given value, allowing the ping response to be read (and # differentiated from an error) from a remote domain using XHR. # # If you have a stream and a gen204 endpoint with the same URL, the stream takes # precedence and the ping endpoint is silently ignored. gen204 /ping allow_origin=*