Joystream / Joystream/joystream

Create Adaptive Streaming Specification

Open
#4,720 0 comments 0 reactions 0 assignees View on GitHub
Epic high-value metaprotocol storage-pallet
Dominant language
Rust
Stars
1.4k
Forks
116
PR merge metrics
No merged PRs in 30d

Description

# Background

Currently, each video media file has a single encoding, resolution, audio track, etc. This means that, playback is not responsive to the range of device types and connection that exist, and also not to the possible dynamic changes in the quality of a user connection to a distributor within a specific playback. There are now mature standards for adaptive streaming that allow for playback to be much more responsive to changes in connection constraints during a single session, and simultaneously solve a hole host of related issues

- https://github.com/Joystream/joystream/issues/4702
- https://github.com/Joystream/joystream/issues/3806
- Upload assistance & transcoding: https://github.com/Joystream/orion/issues/45
- https://github.com/Joystream/youtube-synch/issues/89

This change will impact many codebases, but monorepo is most suitable place for speccing.

# Proposal

Suggest an end-to-end plan for how to introduce adaptive streaming in the Joystream Network. The plan should cover all changes required across

- selecting a standard: there is DASH and HLS, and each has different level of support across browsers and devices, as well as tooling.
- runtime: in particular pertaining to allowing orionv2 to complete an upload on behalf of user
- metaprotocol: new information about what information is available
- orionv2:
- API changes
- outsourcing of transcoding/adaptive encoding to some cloud service which can do it in scalable parallel way
- configurability
- atlas:
- what to change to make playback and resolution control work?
- what to change to make publishing work by swapping out uploads to be purely orionv2 driven, the old p2p approach was horrible anyway.
- yt-synch:
- unclear how this should be done, perhaps one can download relevant DASH/HLS information from yt directly? is it possible to sidestep need to run encoding again after YT, would be a big win in terms of performance on
- drop the current approach of working around some videos having missing audio tracks

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.