Code Monkey home page Code Monkey logo

ephyr's People

Contributors

amukhsimov avatar deiwo avatar dependabot[bot] avatar digest0r avatar dmitriy-zadorozhnyi avatar eirenik0 avatar github-actions[bot] avatar glmcz avatar iananich avatar jurry avatar medoevruslan avatar sinyakinilya avatar tyranron avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

ephyr's Issues

Out-of-order packets from TeamSpeak

At the moment, sometimes tsclientlib reports about out-of-order packet being processed when initiating connection or even running it. Sometimes it even leads to disconnection.

While it's OK at the moment due to baked-in reconnections for teamspeak::Input, it's better to investigate the reason and fix it, to comply with the expected order properly.

Emerge mixer into re-streamer

mixer and restreamer components are quite similar in what they're doing and how are they used. So, mixer capabilities can be emerged into restreamer itself.

Roadmap

  • 1. Support mixing with TeamSpeak links in re-streamer Outputs
  • 2. Support on-fly audio volume tuning
  • 3. Support on-fly delay tuning for TeamSpeak links

Set of UI enhancements

  • Allow to change document.title. When a lot of instances being used would be cool to be able to change the title of each site. #43
  • Display amount of all inputs and amount of all outputs for server #49
  • Add link to broadcast in social network. It should open in new window when click on it. #60
  • Do not close modals by clicking outside of it. #49
  • Save and close modal by pressing Enter #78
  • Add buttons Run ALL, Stop All for all outputs of all inputs. (Should show confirmation dialog) #49

Pull and push SRT in re-streamer

Allow usage of SRT URLs for inputs and outputs in Ephyr re-streamer

Roadmap

  • 1. Allow SRT for PushInput
  • 2. Allow SRT for PullInput
  • 3. Allow SRT for Output

TeamSpeak recording server

Motivation

There is a need in organizing recording of translations done in TeamSpeak separately from a mixing server.

Overview

There should be a standalone service, which on command starts capturing audio from TeamSpeak channels according to the mixing Spec and writes captured audion to the files until the stop command is received. After stop command is received, the result audio files shoud be uploaded to Google Drive.

Detailed design

HTTP API

Recording server should represent a dead simple REST API server with the only two endpoints:

  • POST /stream/<stream-name> (idempotent): starts recording for a <stream-name> stream declared in mixing Spec.
  • PUT /stream/<stream-name> (idempotent): stops recording for a <stream-name> stream declared in mixing Spec.

Instrumentation: actix-web shoud be used to implement the HTTP server.

Authorization

Both endpoints shoud be protected with a Bearer Token HTTP authorization.

The server should read on startuo from its configuration a hash of the bearer token and authorize all HTTP requests against it.

Instrumentation:

CLI (command line interface)

The server should be represented as a serve recorder sub-command of ephyr binary. The supported flags should be:

  • --mixing-spec=<file-path>: path to the file containing the mixing Spec to perform recoding in accordance with.
  • -a, --auth-token-hash=<argon2-hash>: Argon2 hash to validate bearer tokens in HTTP requests against.
  • -o, --out-dir=<directory-path>: path to the directory where recorded files should be persisted in, before they're updloaded to Google Drive.
  • --gdrive-client-id=<id-string>: CLIENT_ID for accessing Google Drive via API.
  • --gdrive-client-secret=<secret-string>: CLIENT_SECRET for accessing Google Drive via API.
  • --ffmpeg: path to FFmpeg binary to use.
  • --http-ip: IP address for recorder server to listen HTTP requests on.
  • --http-port: Port for recorder server to listen HTTP requests on.

Recording

Start recoding

Once POST /stream/<stream-name> request is received, the following should be performed:

  1. Check whether <stream-name> is contained in mixing Spec.
  2. Accoding to the Spec](https://github.com/ALLATRA-IT/ephyr/blob/v0.2.0/src/spec.rs) spawn and run all the required [teamspeak::Inputs](https://github.com/ALLATRA-IT/ephyr/blob/v0.2.0/src/input/teamspeak.rs) [io::copy`ing the audio into spawned FFmped process (for each TeamSpeack channel a separate process should be spawned).
  3. FFmpeg should receive f32be PCM audio-data from STDIN and remux it into MP3 320kbps and write it into the file (in --out-dir) named as <stream-name>_<lang>_<YYYY-MM-DD>.mp3. The file shoud not be overwritten if it exists already, but rather appended with new data.

Finish recording

Once PUT /stream/<stream-name> request is received, the following should be performed:

  1. Check whether <stream-name> is contained in mixing Spec and is in a recording state now.
  2. Finish the recoding, by stopping all the FFmpeg processes related to <stream-name>.
  3. Upload all the writen MP3 files to Google Drive. Do not replace if there is a name collision, but rather rename suffix the name with the current time _<HH:MM::SS> and retry until succeed.
  4. Cleanup successfully uploaded MP3 files from local files.

Roadmap

Each step should be implemented as a separate MR. Mainline branch is: recorder.

  • 0. Bootstrap the serve recorder sub-command in CLI.
  • 1. Bootstrap the HTTP server with required endpoints, without any authorization.
  • 2. Implement reading mixing Spec and keeping it in the server's state. Keeping validating in HTTP endpoints whether the requested <stream-name> exists.
  • 3. Implement recording starting.
  • 4. Implement recording finishing, without Google Drive uploading.
  • 5. Implement uploading to GoogleDrive.
  • 6. Implement authorization via bearer HTTP token.
  • 7. Polish and finish the CLI.

RUSTSEC-2021-0059: `aesni` has been merged into the `aes` crate

aesni has been merged into the aes crate

Details
Status unmaintained
Package aesni
Version 0.10.0
URL RustCrypto/block-ciphers#200
Date 2021-04-29

Please use the aes crate going forward. The new repository location is at:

<https://github.com/RustCrypto/block-ciphers/tree/master/aes>

AES-NI is now autodetected at runtime on i686/x86-64 platforms.
If AES-NI is not present, the aes crate will fallback to a constant-time
portable software implementation.

To prevent this fallback (and have absence of AES-NI result in an illegal
instruction crash instead), continue to pass the same RUSTFLAGS which were
previously required for the aesni crate to compile:

RUSTFLAGS=-Ctarget-feature=+aes,+ssse3

See advisory page for additional details.

Optional strict mode for output and input deletion 

With release 0.2 we've introduced, strict mode for deletion of outputs and inputs. This behavior not always reasonable and sometimes we what to delete many items whiteout confirmation.

Would be helpful have option to enable\disable strict mode for the server.

WebRTC conferences forwarded to RTMP with custom layouts

Synopsis

There is a need for a simple WebRTC-based platform with predefined custom scene layouts.

The common scenatio will be:

  1. A Host creates a Room, choosing the number of participants and some predefined scene layout.
  2. After starting the Room can be shared via a unique link, using which participants join the conference.
  3. The whole video scene of the Room with all the audio should be forwarded to some RTMP destination, for the purpose of streaming the whole conference to YouTube, Facebook, etc.
  4. Each participant should be able to mute its audio (possibly, video).
  5. The Host should be able to mute participants and kick them off, if necessary.

Design considerations

  • Predefined scene layouts should be defined statically, and may be registered on the server staring (so provided by a config option).
  • Each Room should have a uniquely generated ID (used in the link). This ID should not be easily guessable to avoid the situation of malicious user joining the Room.
  • To distinguish the Host from other participants, after the Room creation it should be provided with some session Secret, saved on the client side until the Room is destroyed.
  • A Room is destroyed either when the Host explicitly does so, or when all the participants left the Room.
  • Once Host starts Room it should play on RTMP destinations even if nobody joined the Room and the Host is fully muted (all screens are black).
  • A Host should be able to specify the desired RTMP destinations (up to 5, for the start).
  • When Host mutes someone, the mutee shouldn't be able to unmute himself.
  • For better quality from clients, the scene mixing should happen on the server side, so all the clients will have only their video/audio sending to server, and receiving from the server a video/audio of already mixed scene, rather than separate streams for each participants. This way the client may have better throughput, so quality.

Roadmap

  • 0. Investigate existing open source WebRTC media server and how they can fit into the scenario.
  • 1. Implement a single-scene prototype to PoC (proof-of-concept) the chosen technology.
  • 2. Implement a better, polished, extensible and full-featured solution.

Improve disconnection from TeamSpeak

At the moment TeamSpeak Connection is just dropped, which, however, only initiates disconnection, but doesn't perform normal disconnection, as InAudio/InCommands streams are dropped altogether. Despite the full disconnection ends due to being timeouted, this basically works for now.

However, it would be better to proceed with normal disconnectiong always.

As we don't have AsyncDrop in Rust at the moment, this can should still be reached by spawning InAudio/InCommands streams in Drop instead of just dropping them in-place.

RUSTSEC-2021-0060: `aes-soft` has been merged into the `aes` crate

aes-soft has been merged into the aes crate

Details
Status unmaintained
Package aes-soft
Version 0.6.4
URL RustCrypto/block-ciphers#200
Date 2021-04-29

Please use the aes crate going forward. The new repository location is at:

<https://github.com/RustCrypto/block-ciphers/tree/master/aes>

AES-NI is now autodetected at runtime on i686/x86-64 platforms.
If AES-NI is not present, the aes crate will fallback to a constant-time
portable software implementation.

To force the use of a constant-time portable implementation on these platforms,
even if AES-NI is available, use the new force-soft feature of the aes
crate to disable autodetection.

See advisory page for additional details.

Allow to copy error messages

When error happens during adding multiple outputs than error messages disapears quickly and does not allow to copy them.
Need to fix that.
image

clusterization: scripts for easier mass deployment

  • integration with VPS providers (Digital Ocean, Hetzner, etc.) for automating the creation of multiple Ephyr servers at once
  • integration with DNS providers (such as Cloudflare) for automating the creation (assignment) of dedicated (sub-) domains for multiple Ephyr servers, created by the previous step

GH Actions limitation to size of image

CI step docker (restreamer, false, true) fails with next log:

2021-04-04T00:01:40.7029409Z ##[section]Starting: Request a runner to run this job
2021-04-04T00:01:41.5451767Z Can't find any online and idle self-hosted runner in current repository that matches the required labels: 'ubuntu-latest'
2021-04-04T00:01:41.5451849Z Can't find any online and idle self-hosted runner in current repository's account/organization that matches the required labels: 'ubuntu-latest'
2021-04-04T00:01:41.5452082Z Found online and idle hosted runner in current repository's account/organization that matches the required labels: 'ubuntu-latest'
2021-04-04T00:01:41.6361539Z ##[section]Finishing: Request a runner to run this job

This issue is known bug in GI Actions.

This solution from Facebook should help facebook/sapling#23

Update options on separate page for output

On separate output page need to update:

  • Allow to access without password even if password is set. It's secure because URL contain UUID which is impossible to guess.
  • If the user is not logged, hide close, edit and back to main screen page possibilities (probably start\stop as well). Basically the user should be able only to change volume of the stream.

feature request: HTTPS support for admin UI

It would be great to have built-in ability to serve admin UI through HTTPS protocol, so that login/password and all other data transferred between client and server is encrypted

UPD for @AleksandrovEugen by @skhalymon

Add TLS layer for actix-web with self-signed certificate. Certificate should be generated during server creation.

File output

It would be nice to have an ability to specify a file:// output, so a live stream may be recorded to a file, which may be downloaded later.

Error message doesn not disapear

When some error happen on adding multiple outputs than error message does not disapear event if you close modal and open it again.

Optimize UI updating

When we add more than 80 outputs UI became unresponsive.
As a posible solution we can add configuration option on UI - interval of updating.

MP3 streams mixing

For outputs there should be an ability to mix MP3 HTTP streams along with TeamSpeak sound.

Return all validation errors on PUT / VOD meta endpoint

Synopsis

At the moment validation of new vod::meta::State received via PUT / endpoint is done in a "fail fast" manner: when at least one error happens, the whole validation terminates and the error is returned

Supposed changes

  1. Omit "fail fast" manner and validate as much as possible, to return as many errors as possible.

  2. Provide ?dryrun URL parameter which makes PUT / HTTP endpoint to perform the request validation only, without applying the new state.

RUSTSEC-2020-0036: failure is officially deprecated/unmaintained

failure is officially deprecated/unmaintained

Details
Status unmaintained
Package failure
Version 0.1.8
URL rust-lang-deprecated/failure#347
Date 2020-05-02

The failure crate is officially end-of-life: it has been marked as deprecated
by the former maintainer, who has announced that there will be no updates or
maintenance work on it going forward.

The following are some suggested actively developed alternatives to switch to:

See advisory page for additional details.

Setup qualities for HLS endpoint

At the moment we serve HLS endpoint in the quality we receive it via RTMP.

It would be nice to allow setup multiple qualities for HLS like 480p, 720p, 1080p, etc. And server both separate qualities and single master.m3u8 with dynamic quality.

Optimize TeamSpeak Identity usage

At the moment, each time Ephyr connects to some TeamSpeak channel, it generates a new unique identity. This, somehow, often leads to bans by anti-flood system on server.

It would be much nicer if we cloud memoize and reuse the same identity for each mixer.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.