moq-rs/dev
kixelated 04ff9d5a6a
Add support for multiple origins (#82)
Adds `moq-api` to get/set the origin for each broadcast. Not used by default for local development.
2023-10-12 13:09:32 +09:00
..
.gitignore Major moq-transport API simplification (#68) 2023-09-15 12:06:28 -07:00
README.md Add support for multiple origins (#82) 2023-10-12 13:09:32 +09:00
api Add support for multiple origins (#82) 2023-10-12 13:09:32 +09:00
cert Major moq-transport API simplification (#68) 2023-09-15 12:06:28 -07:00
go.mod Revert "Bump golang.org/x/text from 0.3.7 to 0.3.8 in /dev (#70)" 2023-09-19 10:11:33 -07:00
go.sum Revert "Bump golang.org/x/text from 0.3.7 to 0.3.8 in /dev (#70)" 2023-09-19 10:11:33 -07:00
pub Add support for multiple origins (#82) 2023-10-12 13:09:32 +09:00
pub-1 Add support for multiple origins (#82) 2023-10-12 13:09:32 +09:00
relay Add support for multiple origins (#82) 2023-10-12 13:09:32 +09:00
relay-0 Add support for multiple origins (#82) 2023-10-12 13:09:32 +09:00
relay-1 Add support for multiple origins (#82) 2023-10-12 13:09:32 +09:00
setup Add support for multiple origins (#82) 2023-10-12 13:09:32 +09:00

README.md

dev

This is a collection of helpful scripts for local development ONLY.

Setup

moq-relay

Unfortunately, QUIC mandates TLS and makes local development difficult. If you have a valid certificate you can use it instead of self-signing.

Use mkcert to generate a self-signed certificate. Unfortunately, this currently requires Go to be installed in order to fork the tool. Somebody should get that merged or make something similar in Rust...

./dev/cert

Unfortunately, WebTransport in Chrome currently (May 2023) doesn't verify certificates using the root CA. The workaround is to use the serverFingerprints options, which requires the certificate MUST be only valid for at most 14 days. This is also why we're using a fork of mkcert, because it generates certificates valid for years by default. This limitation will be removed once Chrome uses the system CA for WebTransport.

moq-pub

You'll want some test footage to broadcast. Anything works, but make sure the codec is supported by the player since moq-pub does not re-encode.

Here's a criticially acclaimed short film:

mkdir media
wget http://commondatastorage.googleapis.com/gtv-videos-bucket/sample/BigBuckBunny.mp4 -O dev/source.mp4

moq-pub uses ffmpeg to convert the media to fMP4. You should have it installed already if you're a video nerd, otherwise:

brew install ffmpeg

moq-api

moq-api uses a redis instance to store active origins for clustering. This is not relevant for most local development and the code path is skipped by default.

However, if you want to test the clustering, you'll need either either Docker or Podman installed. We run the redis instance via a container automatically as part of dev/api.

Development

tl;dr run these commands in seperate terminals:

./dev/cert
./dev/relay
./dev/pub

They will each print out a URL you can use to publish/watch broadcasts.

moq-relay

You can run the relay with the following command, automatically using the self-signed certificates generated earlier. This listens for WebTransport connections on WebTransport https://localhost:4443 by default.

./dev/relay

moq-pub

The following command runs a development instance, broadcasing dev/source.mp4 to WebTransport https://localhost:4443:

./dev/pub

moq-api

The following commands runs an API server, listening for HTTP requests on http://localhost:4442 by default.

./dev/api

Nodes can now register themselves via the API, which means you can run multiple interconnected relays. There's two separate dev/relay-0 and dev/relay-1 scripts to test clustering locally:

./dev/relay-0
./dev/relay-1

These listen on :4443 and :4444 respectively, inserting themselves into the origin database as localhost:$PORT.

There's also a separate dev/pub-1 script to publish to the :4444 instance. You can use the exisitng dev/pub script to publish to the :4443 instance.

If all goes well, you would be able to publish to one relay and watch from the other.