As a mandatory codec in WebRTC specifications, VP8 serves as the baseline for compatibility, making it the default choice in LiveKit client configuration. There is room for optimization. Newer codecs like VP9 offer significant efficiency gains compared to VP8, with a 23-33% improvement in compression efficiency. This translates to better video quality at the same bitrate or reduced bandwidth usage for the same quality. VP9 is supported in Safari starting from version 15.0+, and Firefox offers partial support. However, Firefox lacks support for VP9's Scalable Video Coding (SVC). With SVC, participants can send a single VP9 stream with multiple spatial or temporal layers. This allows receivers to dynamically adjust video quality by using lower layers when resolution or bandwidth needs to be reduced, improving adaptability in heterogeneous network conditions. Simulcast, by contrast, sends multiple separate streams at different resolutions. While widely supported in VP8 and VP9, it consumes more bandwidth compared to SVC. The configuration added here is based on the LiveKit demo app, which defaults to VP9 when supported. OpenTalk’s configuration also recommends VP9. If a browser does not support VP9, LiveKit falls back to VP8 or other codecs as needed. Notably, LiveKit disables VP9 encoding for Firefox due to longstanding issues, but it can still decode VP9 streams and encode VP8 for outgoing streams. This ensures compatibility with other participants, even in mixed environments where some browsers use VP9 and others fallback to VP8. In theory, participants do not all need to switch to a single codec, as both LiveKit and browsers intelligently handle codec negotiation on a per-participant basis. This dynamic adaptation ensures seamless communication without manual intervention. A similar challenge with codec compatibility was raised in Jitsi two years ago, check issue #10657. Before any release, this needs to be battle tested with Firefox 115 browsers.
Meet
Meet is a simple video and phone conferencing tool, powered by LiveKit.
Meet is built on top of Django Rest Framework and Vite.js.
Getting started
Prerequisite
Docker
Make sure you have a recent version of Docker and Docker Compose installed on your laptop:
$ docker -v
Docker version 20.10.2, build 2291f61
$ docker compose -v
docker compose version 1.27.4, build 40524192
⚠️ You may need to run the following commands with
sudobut this can be avoided by assigning your user to thedockergroup.
LiveKit CLI
Install LiveKit CLI, which provides utilities for interacting with the LiveKit ecosystem (including the server, egress, and more), please follow the instructions available in the official repository.
Project bootstrap
The easiest way to start working on the project is to use GNU Make:
$ make bootstrap FLUSH_ARGS='--no-input'
Then you can access to the project in development mode by going to http://localhost:3000. You will be prompted to log in, the default credentials are:
username: meet
password: meet
This command builds the app container, installs dependencies, performs
database migrations and compile translations. It's a good idea to use this
command each time you are pulling code from the project repository to avoid
dependency-related or migration-related issues.
Your Docker services should now be up and running 🎉
[FIXME] Explain how to run the frontend project.
Configure LiveKit CLI
For the optimal DX, create a default project named meet to use with livekit-cli commands:
$ livekit-cli project add
URL: http://localhost:7880
API Key: devkey
API Secret: secret
Give it a name for later reference: meet
? Make this project default?? [y/N] y
Thus, you won't need to pass the project API Key and API Secret for each command.
Adding content
You can create a basic demo site by running:
$ make demo
Finally, you can check all available Make rules using:
$ make help
Django admin
You can access the Django admin site at http://localhost:8071/admin.
You first need to create a superuser account:
$ make superuser
Run application on local Kubernetes
The application is deployed across staging, preprod, and production environments using Kubernetes (K8s). Reproducing environment conditions locally is crucial for developing new features or debugging issues.
This is facilitated by Tilt ("Kubernetes for Prod, Tilt for Dev"). Tilt enables smart rebuilds and live updates for services running locally in Kubernetes. We defined our services in a Tiltfile located at bin/Tiltfile.
Getting Started
Make sure you have installed:
- kubectl
- helm
- helmfile
- tilt
To build and start the Kubernetes cluster using Kind:
$ make build-k8s-cluster
Once the Kubernetes cluster is ready, start the application stack locally:
$ make start-tilt
These commands set up and run your application environment using Tilt for local Kubernetes development.
You can monitor Tilt's at http://localhost:10350/. After Tilt actions finish, you can access the app at https://meet.127.0.0.1.nip.io/.
Debugging frontend
Tilt deploys the meet-dev for the frontend by default, to benefit from Vite.js hot reloading while developing.
To troubleshoot production issues, please modify the Tiltfile, switch frontend's target to frontend-production:
...
docker_build(
'localhost:5001/meet-frontend:latest',
context='..',
dockerfile='../src/frontend/Dockerfile',
only=['./src/frontend', './docker', './.dockerignore'],
target='frontend-production', # Update this line when needed
live_update=[
sync('../src/frontend', '/home/frontend'),
]
)
...
Contributing
This project is intended to be community-driven, so please, do not hesitate to get in touch if you have any question related to our implementation or design decisions.
License
This work is released under the MIT License (see LICENSE).