Users should be able to view historical test results per orchestrator, but that is not available in the leaderboard frontend yet. Until that is available in the frontend, we should at least describe how someone can view those test results by using the API endpoint directly in the leaderboard FAQ.

Document the changes introduced in livepeer/go-livepeer#1778

Develop a strategy in creating and publishing docs so that,

Links are dynamically updated throughout the document

Problem:
There can be several methods for links within the documentation to be updated
Purpose: We want to make sure that if a document is renamed or moved around within docusaurus, that all links within pages referring to content in that document are automatically updated.

Acceptance Criteria

• No Broken links will have to be updated manually
• Links will automatically be updated
• No 404s
• Redirects are provided
• clear instructions for Contributors should be included
• upon starting yarn, a check of links runs and passes link check
• Links in the navigation are updated as well as within content

A patch is required to release NVIDIAs GPU restrictions on concurrent streams.

Provide instructions to patch the NVIDIA GPU so that:

• Patching is done before testing benchmarking
• follows Livepeer GPU support docs
• links from the quickstart

Develop a video streaming primer so that orchestrators and anyone on Livepeer can have a good foundation of technical knowledge about video streaming.
Rationale:
Video streaming is highly complex.

We want our orchestrators and anyone on Livepeer to have the knowledge to maximize the potential of Livepeer.

• engaging
• inspiring
• provides a common understanding
• adds value and quality to the experience of working with Livepeer

initial sketch of goals

• objectives/goals of video streaming
• purpose and use cases for video streaming (e.g., many creators who are dependent on current platforms that are cost or technically prohibitive. How do they work with Livepeer as a solution.)
• composition of video streaming - all the "components", "architecture", ...
• process of video streaming - how it is different on W3 and in general to content on web, how it works well in the environment (benefits), how it is better than current video streaming platforms now
• how this can be the future for sharing content

Create a use case document with metrics.
Purpose: So that a new user can see how, based on a concrete use case, metrics can be beneficial.
Objectives: Provides a template based on a concrete example with steps a participant can follow to benefit from their metrics and make adjustments/solutions
Criteria:

• has the scenario -- use case
• has the walkthrough of the setup
• has a complete set of metrics LP provides
• chooses from the set what would be beneficial to work with
• has a list of "reference" documentation about metrics (there are a lot in our docs).
• has several ways metrics are useful to have insight into the "performance" for the use case
• has analysis and solutions and results

It could be helpful to have some examples in the configuration payment parameters section of the SF public testnet docs for the PM calculator script. For example, the docs could present the price per pixel output of the script when targeting a specific frequency for winning tickets in clock time for a few input values for the desired ticket EV and projected gas price.

Shortened version of quickstart
Linking to existing instructions in livepeer

change the names of the Overviews to the name of the landing page and readers will get overview information on the landing page,
So that when clicking on the landing page, instead of having to click through the sections, they can navigate directly to the content they want

The purpose of this is to:

• reduce the number of clicks in navigating content as well as
• follow the guideline that all content and steps should be done in no more than 3 steps
• reduce the number of Overview pages, thus reducing duplicate file names

e.g. Protocol
- Overview
- Core Concepts
- - Overview
- - Ecosystem Participants
- - Livepeer Tokens, etc.
- - ...
- - ...
- - ...

After installing sphinx, whenever I try to transpile the docs to html I find that I get this error:

Extension error:
Could not import recommonmark.parser (needed for source parser) (exception: No module named recommonmark.parser)
Makefile:20: recipe for target 'html' failed
make: *** [html] Error 2

Would it be better for the installation instructions to recommend using a virtual environment and installing required packages from a requirements.txt file for doc development?

Example:
pip install -r requirements.txt

Update "Intro" with a minimally robust Welcome page:

• Sets the Livepeer's delightful tone -- engaging readers in the ease of use and benefit of working with the platform
  Provides a frame of reference so that:
• stakeholders can get a high-level understanding about the Livepeer offering
• What's New -- release/migration highlights, e.g. L2, docs updates
• set expectations about how the documentation can guide them
• highlights paths/journeys stakeholders can follow with the support of the documentation
  so that they can
• participate according to their chosen interest/role-persona as:
  Video Miners
  Transcoders
  Developers
  and Token Holders and Delegators know how to get information on what they need to know
  Contributors

Extend/write up an annotated list of components/capabilities
So that people who are new to Livepeer can be informed of the architecture/components and capabilities of the Livepeer offering,

• like a glossary of terms, this is a list with descriptions of what the component/capability is and what they are for

1. In the “Download Livepeer” section. You could probably say where might be the best place to put the files.

Example:

• Download the proper package for your operating system to your downloads folder.
• Run the using the following commands:

2. In the “Rinkeby Testnet” section it might be helpful to put “livepeer -rinkeby” in a block that looks like it should be ran from the command line. This would differentiate it from the sentence and make it standout. Example:
   In your terminal run:
   $ livepeer -rinkeby

3. When using the test network, you may want to direct the user to documentation that will help them in the event rinkeby cannot issue ETH to their address. https://faucet.rinkeby.io/ kept saying “URL doesn't link to supported services”, when I try to get test ETH.

Provide instructions/information about opening ports, e.g. 8935 for orchestrators to be able to start a node

• simple instructions or a composite visual
• what to do if your router is hardcoded and doesn't allow for port forwarding

• Go to https://bridge.arbitrum.io/
• Make sure you wallet (i.e. Metamask) is connected to Rinkeby
• Click "Token"
• Enter 0xEf5F154eb0261CB0331a28BC0fB60CA73E716617
• LPT should show up and then you can select it
• Then, you should be able to see your L1 balance with the option of clicking "Deposit" to move your L1 LPT to L2

Create/figure out how to incorporate a use case library for general information as well as provide visibility about specific use cases for each role:

In some instances the use cases are under Role/Concepts. Use cases can also be presented for general purposes,
So that participants are informed of how LP can be leveraged

• organize use cases so that there is a "library", e.g. -- Quick start section has a page with an annotated list of use cases by role with links to the use case pages
• provides an "example/template" for a standard use case so that it is easy for contributors to get started providing use cases and participants and readers to follow

Currently we have the following repositories of content for Livepeer:

• readthedocs
• wiki
• forum
• github
• livepeer.org
• livepeercommunity.org

It is unclear to me the distinct purpose of each of these repositories, and what content belongs where.

This issue proposes an audit of what content currently lives where (the "as is"), in order to inform some decision making about what content should live where (the "to be").

We should create a tutorial based on the Livepeer media player.

Sections:

• Setting up a Livepeer node from scratch
• Setting up the media player
• Streaming a video into the Livepeer node, and watching the stream from the media player

Add information about best practices editing docs,

• working with Markdown

• update document deposit requirements (L2)

Update Installation instructions

• with a thorough walkthrough for video miners new to this technology
• bridge missing instructions (e.g. add patch)
• add pitfalls, e.g. errors

Ex. -rpc -rpcapi eth,net,web3

Might need -rpcaddr <RPC_ADDR> if the node is on a remote machine.

As suggested in: livepeer/go-livepeer#308 (comment)

We should have a get started with OBS doc that explains the detailed settings to use in OBS to use Livepeer.

Update Activation guide in Getting Started

• add contextual information
• edit steps

Currently the /video-miners section of the docs is pitched in terms of helping GPU operators "increase profits by transcoding video on GPUs while mining". This implies that you need to be mining, and might evem put off operators who don't wish to engage in PoW, as it isn't immediately clear that you can transcoded without also mining.

AFAIK there are not so many Os who also mine, plus the economics may even work without hashing at the same time as transcoding. Thus, it feels like this section needs a refresh.

Factor in the upcoming switch-off of PoW on Ethereum, GPU operators are going to be looking for ways to re-purpose their hardware.

Clearly, Ethereum isn't the only network that needs hashing, but there is perhaps an opportunity to expand on the green credentials, e.g. "using GPUs for their intended purpose i.e. processing graphics (what a radical concept /s)" instead of "proof-of-waste".

Discuss?

We have observed quite a lot of orchestrators returning OrchestratorCapped errors and it is likely that these orchestrators are using the default -maxSessions value (10). If this is the case, then the orchestrators' transcoding capacity is being under utilized. We should add a guide for setting session limits that can use livepeer_bench.

The initial approach for setting session limits might involve:

1. Running livepeer_bench with an increased # of concurrent sessions with a fixed/common ABR ladder until the ratio of video time to transcode time is <= X. The suggestion for X might be to set X to 1.2 to target 20% faster than real-time to give a buffer for network transit.
2. Given an approximation upload/download bandwidth, using the input/output bitrates of a fixed/common ABR ladder estimate the # of sessions that can be handled
3. Take the lower of 1 vs. 2

The above would just be a rough way to get started setting session limits and we would want to note that the approach assumes a fixed/common ABR ladder, but you could follow the same steps given different ABR ladders as well.

For me, there is an important shift in mindset which needs to happen. A shift towards encouraging developers to build live video applications which interact directly with the public network. i.e. instead of building against a proprietary api exposing arbitrary and limited functionality.

Cultivate the long tail of Broadcasters

The following approach can be positively described as approaches to building on Livepeer. It doesn't involve any crypto until the app scales, and also doesn't require a used dox the self with username/email/credit card etc.

It is motivated by the idea of cultivating a more diverse active set of Broadcasters than currently exists, and reduce Orchestrators' over-reliance on a single source of live content and fees.

i) run a B/Mist in offchain mode (no username/password, no crypto expertise needed, no cost) it's as easy as running ./livepeer -broadcaster or whatever the MistServer equivalent is, and how many competent devs couldn't do that? This gives them full access to a livestreaming node which they can even build from source and tinker with under the hood.

ii) if/when needed (i.e. if/when the B's upstream bandwidth gets saturated by too many outgoing streams), configure their own CDN to distribute content more cost-effectively. This isn't beyond the capabilities of most developers, and is effectively what .com does.

iii) run a self-hosted O/T in offchain mode (still no crypto needed, doesn't even need an -ethUrl). This can even start with CPU transcoding to begin, and add a GPU if/when more than a few incoming streams start coming in.

iv) if/when required (i.e. if/when the O/T's transcoding capacity get saturated by too many incoming streams), connect to Rinkeby testnet, then if necessary to Mainnet (requires deposit/reserve). This became much more feasible since the switch to Arbitrum in terms of reserve deposit for PM tickets, and paves a way towards diversifying the active Broadcaster set, which can only be a good thing for the public network in the long run. It will also help to inform any work done on evolving the fee mechanism, to make sure we don't make it prohibitive for small independent Bs to feed the Os with source video content and fees.

This approach may be slightly more complex than just getting a free account with .com API, but it sets a developer on a path where they are entirely self-reliant and self-sovereign. Overall, it feels like a far more coherent and authentic approach for a project which aims to be the world's open video infrastructure, compared with "sign up for an account with this US-based corporation".

This is instead of proposing that developers build to an arbitrary API with limited functionality, where they need to rely on a centralised team to share their priorities, which isn't a scalable approach to serve all developers building video apps for the metaverse, and introduces points of failure (.com itself).

I appreciate this is some kind of strategy question, but I would be interested in hearing views of others.

Update glossary to aggregate all terms in glossaries/terminologies
in order to
have a single source of terminology across documentation
have an ample glossary

• terminology across sources matches
• ability to see hits on the glossary/terms if possible to gauge common vocab use
• elaborate acronyms
• identifies source of term (e.g. if it's Livepeer or industry)
• ability to comment, ask questions about terminology
• reference pages with terms
• tbd

Once livepeer/go-livepeer#1693 is completed, we should add a note to the "How To Benchmark Transcoding" pre-reqs that you can also download a release binary as well.

I'm looking at https://livepeer.readthedocs.io/en/latest/developers.html which comes from https://github.com/livepeer/docs/blob/master/docs/source/developers.rst

There's a bit which says:

Setting up a development enviroment can be done by following these instructions_.

The link "these instructions" takes you to the same page - i.e. if someone wanted to set up a development environment, they would not get to it.

Perhaps it would encourage more developers to "develop on Livepeer" if these instructions existed?

this guide should walk tokenholders through the process of delegating their LPT to an Orchestrator. Please include screenshots!

https://docs.livepeer.org/installation/install-livepeer/binary-release#windows

e.g.,

• instructions use tar, we use zip
• mv does not work

When converting this doc to html there are some warnings saying:

• docs/docs/source/developers.rst:2: WARNING: Title underline too short.
• docs/docs/source/developers.rst:8: WARNING: Bullet list ends without a blank line; unexpected unindent.
• docs/docs/source/developers.rst:13: WARNING: Bullet list ends without a blank line; unexpected unindent.
• docs/docs/source/getting_started.rst:59: WARNING: Literal block expected; none found.

#8 Is the following document supposed to be included in the html?

docs/docs/source/configuringOBSandLivepeer.md: WARNING: document isn't included in any toctree

Write-up a quick start to get up and running with Livepeer as a
Video Miner in just a few (3)steps

There should be a page in the documentation that makes the current limitations of the system clear to potential developers. These limitations will be lifted as we make progress on our roadmap. But right now it isn't clear to a developer coming into the network what they can and can not do.

The two links in boardcasting section regarding running the node are broken.

Check and update the token.md with correct information regarding Arbitrum.

https://github.com/livepeer/docs/blob/main/docs/protocol/core-concepts/token.md

Update Testnet instructions:

https://docs.livepeer.org/video-miners/getting-started/testing/testnet

consolidate choose your role and roles and responsibilities
so that:

• all content is in "roles and responsibilities.md"
• choose your role .md is deleted
• content makes sense

Objective: develop tutorial/business use case for fees,
so to orchestrators understand how fees work

-set expectations for setting fees
-provides expectations about fees

• provides expectations about distribution of stakes
  -provides insight to the technical requirements for setting fees
  -provides a step-by-step tutorial on how to manage fees...

add and update Windows instructions from:
https://hub.docker.com/r/livepeer/go-livepeer

to:
https://docs.livepeer.org/installation/install-livepeer/docker

So that stakeholders using Windows can install Livepeer with Docker

• prerequisites
• install steps

While running an orchestrator behind a NAT (i.e. behind a home router) is not advised, it could be worthwhile to add an additional note that this can be possible via hairpinning which has done by at least one orchestrator operator already.

The steps that the orchestrator operator took were:

Add a second rule to the SNAT chain that looks like this:

13119   786268 DNAT       tcp  --  *      *       0.0.0.0/0            <EXTERNAL_IP>       tcp dpt:8935 to:10.0.0.10
       2      120 SNAT       tcp  --  *      *       10.0.0.10            10.0.0.10            to:<EXTERNAL_IP>

By running a command like this:

iptables -t nat -A POSTROUTING -p tcp -s 10.0.0.10 -d 10.0.0.10 -j SNAT --to-source <EXTERNAL_IP>

Could include internal/external references for what one needs to know about blockchain to leverage Livepeer.

https://docs.livepeer.org/installation/connect-to-ethereum#supported-networks

• add clarification around Rinkeby and Hosted APIs
• consider making supported networks into a table or highlight the test from non-test options, and hosted vs. other kinds of networks

The default blockPollingInterval exceeds Infura's 100k requests/day. Since most orchestrators rely on Infura's free tier, we should recommend orchestrators set the blockPollingInterval to 12 seconds (-blockPollingInterval 12) to avoid exceeding Infura's request per day limit.