Infrastructure to support a TAK Compatible Media Server
MediaMTX currently does not persist API operations to the config file, as such the Dockerfile is bundled with a persistance script that will convert the API response and push it to the mediamtx.yml file on change
| Port | Notes |
|---|---|
| 8554 | RTSP rtsp://<server>:8554/<mystream> |
| 8889 | WebRTC signaling https://<server>:8889/<mystream>/publish when ACM is configured, otherwise http://<server>:8889/<mystream>/publish |
| 8189/udp | Preferred WebRTC ICE media transport |
| 8189/tcp | WebRTC ICE fallback transport for clients that cannot use UDP |
| 8890 | SRT srt://localhost:8890?streamid=publish:mystream&pkt_size=1316 |
For browser WebRTC playback, the signaling port (8889/tcp) and preferred ICE media port (8189/udp) both need to be reachable from the client. AWS deployments also expose direct ICE over 8189/tcp as a fallback for clients or networks that block UDP. AWS deployments use a static EIP and publish the video.<zone> hostname as the public ICE candidate; interface-local addresses are not advertised because clients outside the VPC cannot use them.
The source stream also needs to be browser-WebRTC friendly. MediaMTX packetizes streams but does not transcode direct RTMP publishers. Use H264 constrained baseline or baseline with no B-frames, a normal live frame rate such as 30 fps, and Opus/G711 audio or no audio. For FFmpeg publishers, a safe starting point is:
ffmpeg -re -i <source> \
-c:v libx264 -preset veryfast -tune zerolatency -profile:v baseline -bf 0 -g 30 -r 30 -pix_fmt yuv420p \
-c:a libopus -b:a 64k \
-f flv rtmp://<server>:1935/<stream>If the source cannot publish WebRTC-safe media directly, publish it to a separate raw path and transcode that path into the user-facing path with FFmpeg; otherwise WebRTC will inherit the source codec profile and timestamps.
HLS is served using the fMP4 variant (hlsVariant: fmp4 in mediamtx.yml), which supports
H264, H265, Opus, MPEG-4 Audio (AAC) & more. The mpegts variant is intentionally not used:
it supports H264 video and MPEG-4 Audio only, and the HLS muxer fails immediately on any other
codec. If a stream still cannot be muxed, the MediaMTX error text is passed through to the HLS
client in the playlist error response.
Note that codec support in the browser itself still applies - H265 playback remains limited regardless of variant.
The MediaMTX log level is set by the configuration script at container start via the MEDIAMTX_LOGLEVEL
environment variable. Valid values are error, warn, info & debug - an unrecognized value logs a
warning and falls back to info.
In AWS deployments this is set from the MediaMTXLogLevel CloudFormation parameter, which defaults to warn.
To run the media server locally, you can use Docker. First ensure that you have a local CloudTAK instance running and then run:
docker build -t mediamtx .docker run --network='host' -e API_URL='http://localhost:5001' -e SigningSecret='<SigningSecret>' mediamtx:latest
From the root directory, install the deploy dependencies
npm installDeployment to AWS is handled via AWS Cloudformation. The template can be found in the ./cloudformation
directory. The deployment itself is performed by Deploy which
was installed in the previous step.
The deploy tool can be run via the following
npx deployTo install it globally - view the deploy README
Deploy uses your existing AWS credentials. Ensure that your ~/.aws/credentials has an entry like:
[coe]
aws_access_key_id = <redacted>
aws_secret_access_key = <redacted>
Deployment can then be performed via the following:
npx deploy create <stack>
npx deploy update <stack>
npx deploy info <stack> --outputs
npx deploy info <stack> --parameters
Stacks can be created, deleted, cancelled, etc all via the deploy tool. For further information
information about deploy functionality run the following for help.
npx deployFurther help about a specific command can be obtained via something like:
npx deploy info --help