victorges / justcast.it

1-click live streaming from a web app.

justcast.it

1-click live streaming from a web app.

Contributing

Pull Requests are always welcome! Also feel free to just open issues if you don't have the time to figure it out or have problems getting started.

Setup

1. Install Node.js and Yarn.
2. Clone the repository.
3. Run yarn to install all the project dependencies.
   • Make sure you have rsync available as well. This is the biggest tech debt on the build pipeline as we only use it for copying some files around (PRs welcome!).
4. Run yarn build to make sure you can build the project.

Running the app

1. Access the Livepeer Studio dashboard and create an API key.
2. Create a .env file in the root of the project with the following content:

   LIVEPEER_API_KEY={{ API key from the step above }}

3. Run yarn start to start the web server and access it on http://localhost:8080.

To build the docker image you can also run yarn docker:build and then yarn docker:start to start it locally, accessing it on the same endpoint. The docker compose deployment will automatically pickup the env from the .env file as well.

Development

For quicker development cycles, you can run yarn watch to recompile and reload the server any time you make a change to the source code.

The current architecture is as vanilla as possible, with static files served by the same web server that serves the API. This allows for the most lightweight experience possible, but also means that you can't use any fancy features like hot module reloading. If you want to work on the frontend, you'll have to reload the page manually.

That also means that deploying this project is as simple as running a docker container, but on the other hand we can't use higher-level development platforms like Vercel very easily.

Deployment

To deploy the project, you only need to run the Docker container in a publicly accessible endpoint and with access to a Livepeer API key in the environment variables. It can even be the same one that you use for dev, but it's recommended to create a new one for production.

The pre-built docker container is also publicly available on Docker Hub in the victorges/justcast.it repository.

So TL;DR, all you need to do is:

• Decide on a platform where you want to run your container (e.g. Fly.io, Google Cloud, Okteto, Heroku, Azure, AWS...)
• Deploy a container with the image victorges/justcast.it:latest
• Set an environment variable called LIVEPEER_API_KEY with your API key. Ideally this should be a "secret" value, each provider will have their own abstractions for this
• Access it from a public URL (this also changes per provider)

Cloud Providers

fly.io

This app is currently deployed through fly.io. It provides the best and easiest experience for simply running a container with a public endpoint. It also has a free tier, but you do need to set up a credit card on sign-up.

Since we already have the configuration files for it, after configuring your flyctl CLI:

• Create an app on your account (you'll choose or get a random app name):

  flyctl apps create

• Create a secret with your Livepeer API key:

  flyctl secrets set --app {{ your app name }} LIVEPEER_API_KEY={{ your API key }}

• Deploy the app:

  flyctl deploy --config ops/fly.toml --app {{ your app name }}

Okteto

This is a good alternative if you're not willing to put your credit card information anywhere. It is slightly more expensive though if you don't want your apps sleeping automatically after a while without deploys.

It also supports the Docker Compose syntax for deployment, which we already have in the root of the project. You will only need to add an endpoints config to expose the service on the internet via HTTPS. Check this commit for an example.

Google Cloud Run

Google Cloud Run is actually a pretty good option as well and really easy to use. Although it might be a little more bureaucratic, you can also save a lot of money on the infra bill since your app can automatically sleep when it's not in use. Follow this for a quick guide on deploying a container there.

The biggest problem is that it doesn't run images from Docker Hub. So you'll need to push the images to the Google Container Registry and only then deploy it on Cloud Run. See this StackOverflow answer for more details.

Contact

Feel free to open an issue to start a discussion or just chat on Discord (victorges#0420).

License

MIT

justcast.it's Issues

Please Make Build Docs

As a user, I want to be able to run my own justcast.it service in development, and for testing purposes.

So, it would be really nice if there were some docs / instructions for getting started with justcast.it, i.e. what needs to be set up, and how does it work.

Add quality picker to stream player

Migrate backend to typescript

Create some friendly names for the streams

Requires storing streams in some custom db like Firestore

Issues while building the project

Hey,
I found this awesome project today and while I was trying the command yarn build I got the following errors-
my node version is v18.13.0 and yarn version is 1.22.19

First I used yarn-
logs-
yarn yarn install v1.22.19 [1/4] Resolving packages... [2/4] Fetching packages... [3/4] Linking dependencies... warning "workspace-aggregator-18b221cc-d877-427c-aa5c-de5a1f4e1151 > justrender-it > [email protected]" has unmet peer dependency "@types/node@*". [4/4] Building fresh packages... Done in 12.19s.
then I used yarn build-
logs-
yarn run v1.22.19 $ mkdir -p dist && concurrently --names server,client 'cd server && yarn build' 'cd client && yarn build' $ yarn clean; run-p build:copy build:bundle $ tsc $ rm -rf ../dist/public $ rsync -r --exclude '*.ts' src/* ../dist/public $ run-p build:bundle:transmitter build:bundle:receiver $ esbuild --define:process.env.NODE_ENV="production" --minify --bundle --log-level=error src/transmitter/index.ts --outfile=../dist/public/transmitter/bundle.js $ esbuild --define:process.env.NODE_ENV="production" --minify --bundle --log-level=error src/receiver/index.ts --outfile=../dist/public/receiver/bundle.js [client] cd client && yarn build exited with code 0 [server] cd server && yarn build exited with code 0 Done in 1.62s.

any ideas ?
Thanks

Implement microphone muting

Feature Request: Add a start/stop recording button

Moved from livepeer#3 by @chrishobcroft

Current experience

Currently, the UI for justcast.it is very minimalist and simple:

• Monitor of the moving pictures captured by the camera
• A big circular button for start streaming / stop streaming (currently coloured red)
• A rectangular button to switch to sharing a screen instead of camera

This is a great basic set of features. Except something important is missing.

Proposed enhancement

This issue proposes to add the following option for the UI:

• A big circular button for start recording / stop recording (colour it red, like a dead stream)

This would allow a Publisher to record their livestream content locally, and may require a user provide the browser with permission to write to the file system.

Also, propose to re-colour the "big circular button for start streaming / stop streaming" to green (like an alive stream). I would use #00eb87 (one of Livepeer's original "official" colours).

Rationale

I accept that in a world where users expect their livestream content to be stored "in the cloud", that this feature request may appear counter intuitive.

However, in cases where the publisher knows that their content is not automatically being stored remotely, this feature would provide them with a way to save the content themselves.

This would effectively allow them to retain full almost-uncompromised control over their media rights, allowing them to release the content on their own terms. This would also represent a substantial improvement compared to current situations where big social media tech platforms end up being the only entities with full control over a creator's content.

I acknowledge that if someone was watching the stream, and recording the content, then they would be able to also save the content themselves... e.g. like a PVR. But this currently requires substantially more technical capabilities to perform.

Use git secrets instead of offline shared gitignored files

Enable microphone echo/noise cancellation

Especially from the noise coming from the computer speaker itself

Improve stream reliability

It currently reliable fails after a few minutes

There are failures on the consuming side (videojs?) as well as on the transmitting side (ffmpeg?)

Feature Request: Add an audio monitor

Moved from livepeer#2 by @chrishobcroft

Current experience

Currently, the UI for justcast.it is very minimalist and simple:

• Monitor of the moving pictures captured by the camera
• A big circular button for start streaming / stop streaming
• A rectangular button to switch to sharing a screen

This is a great basic set of features. Except something important is missing.

Proposed enhancement

This issue proposes to add the following option for the UI:

• Monitor of the sound wave captured by the microphone

This may take the form of e.g. a green bar (e.g. colour #00eb87 - one of Livepeer's original "official" colours) which reacts when the microphone detects audio.

If the audio captured is stereo (e.g. from a smartphone with stereo mics, or a computer with a stereo audio input / sound card), this may take the form of two (2) green bars, one for each channel.

If the audio goes above 90%, perhaps it could turn yellow, and if it peaks out at 100%, perhaps it could turn red. But now I'm getting too deep into UI design. Here is some inspiration for the reader:

Further Enhancements

As surround-sound audio capture becomes more prevalent (e.g. to better enable immersive livestream VR playback experiences, or for Consumers with surround-sound speaker systems), it may be necessary to define more sophisticated ways to indicate audio levels for five (5), seven (7) or more audio channels.

For example, Ubuntu already allows configuration of audio playback using surround-sound on supported devices (I'm not aware of whether it already allows configuration of audio capture using surround-sound devices):

Implement screen (and tab) sharing

Add a viewer count to streams

Feature request: Multi-view switching

Moved from livepeer#4 by @chrishobcroft

This feature request is for the ability to connect more than one camera source, and allow rudimentary switching between cameras.

A prototype could be to allow switching between camera and screenshare, in order to minimise the complexity likely associated with allow >1 camera to connect to a session.

I have no idea how the UI would look for this, but OBS Studio ought to provide some basic inspiration. For example, you might even want to call this option "Studio Mode":

Separate client and server projects

At least separate package.jsons, tools, configs, etc.

Replace websocket with webrtc (or anything else)

Some non-lossless protocol might be worth for streaming purposes.

A related step for this is to remove the handshake from the websocket
communication itself, and keep the websocket exclusively for the stream
data transmission.

Create way to change stream id from trasmitter side

Migrate frontend to typescript

Pls Add Docs for self-deploying

The website is awesome but there's no self-deploy docs.
I just want to use it in my team internally and we dont want to stream online.

Fix errors when HLS endpoint is not ready yet

We currently have to keep refreshing the page which is not very good

Fix transmitting on mobile

It just doesn't work

Add some crypto mining on streming/consuming pages

It might not be the way to go for the business model but it is something we certainly have to try.
https://github.com/jtgrassie/xmr-wasm

Sync websocket lifecycle with streaming session

Create transmissions with multiple simultaneous streams

Feature Request: Picture-in-picture when Screensharing

Moved from livepeer#5 by @chrishobcroft

Current Implementation

Currently, justcastit allows sharing of video content from the following sources:

• Camera
• Screenshare

Proposed Evolution

When when I choose a Screenshare, give the user the option to embed the Camera as a picture-in-picture, e.g. in the bottom right hand corner of the Screenshare image.