Requires storing streams in some custom db like Firestore

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

It just doesn't work

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.

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

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

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

Especially from the noise coming from the computer speaker itself

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.

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.

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.

It currently reliable fails after a few minutes

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

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.

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":

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):