Setting up the repository#

In order to start working on Streamlink, you must first install the latest stable version of git, optionally fork the repository on Github onto your account if you want to submit changes in a pull request, and then locally clone the repository.

mkdir streamlink
cd streamlink
git clone --origin=upstream '' .
git remote add fork '<YOUR-USERNAME>/streamlink.git'
git remote -v
git fetch --all

When submitting a pull request, commit and push your changes onto a different branch.

git checkout master
git pull upstream master
git checkout -b new/feature/or/bugfix/branch
git add ./foo
git commit
git push fork new/feature/or/bugfix/branch

Setting up a new environment#

While working on any kind of python-based project, it is usually best to do this in a virtual environment which is isolated from the Python environment of the host system. This ensures that development can be done in a clean space which is free of version conflicts and other unrelated packages.

First, make sure that you have the latest stable versions of Python and pip installed.

python --version
pip --version

As the second preparation step, install the latest version of virtualenv, either via your system's package manager or pip, and create a new virtual environment. These environments can be created separately for different Python versions. Please refer to the virtualenv documentation for all available parameters. There are also several wrappers around virtualenv available.

pip install --upgrade --user virtualenv
virtualenv --version

# replace ~/venvs/streamlink with your path of choice and give it a proper name
virtualenv --download --verbose ~/venvs/streamlink

Now activate the virtual environment by sourcing the activation shell script.

source ~/venvs/streamlink/bin/activate

# non-POSIX shells have their own activation script, eg. FISH
source ~/venvs/streamlink/bin/

# on Windows, activation scripts are located in the Scripts/ subdirectory instead of bin/
source ~/venvs/streamlink/Scripts/activate

Validating changes#

Before submitting a pull request, run tests, perform code linting and build the documentation on your system first, to see if your changes contain any mistakes or errors. This will be done automatically for each pull request on each change, but performing these checks locally avoids unnecessary build failures.

# run automated tests
python -m pytest -ra
# or just run a subset of all tests
python -m pytest -ra path/to/ ...

# check code for linting errors
# check code for typing errors

# build the documentation
make --directory=docs clean html
$BROWSER ./docs/_build/html/index.html

Code style#

Streamlink aims to use best practices, as detailed in PEP 8 and implemented in tools such as Black.

These are the best practices most likely to be relevant to plugin authors:

  1. Imports (linted by flake8).

  2. Indentation (linted by flake8; 4 spaces per indentation level).

  3. Quotes (double quotes " and """).

  4. Maximum line length (defined in the flake8 section of setup.cfg via max-line-length).

  5. Horizontal vs vertical whitespace (balance line length, readability and vertical whitespace).

  6. Blank lines (linted by flake8 for imports, class and method definitions).

  7. Comments (linted by flake8; use sparingly and where strictly useful).

  8. Line breaks & binary operators (break before binary operators).

  9. Don't use multiple parameters on the same line where line breaks are in use.

    # incorrect:
        validate.parse_json(), [{
    # correct:

It might be helpful to new plugin authors to pick a small and recently modified existing plugin to use as an initial template from which to work. If care is taken to preserve existing blank lines during modification, the main plugin structure should be compliant-ready for linting.


Adding plugins#

  1. Implement the plugin in src/streamlink/plugins/, similar to already existing plugins.

    Check the git log for recently added or modified plugins to help you get an overview of what's needed to properly implement a plugin. A complete guide is currently not available.

    Each plugin class requires at least one pluginmatcher decorator which defines the URL regex and matching priority.

    Plugins need to implement the _get_streams() method which either returns a list of Stream instances or which yields Stream instances. Stream is the base class of HTTPStream, HLSStream and DASHStream.

    Plugins also require metadata which will be read when building the documentation. This metadata contains information about the plugin, eg. which URLs it accepts, which kind of streams it returns, whether content is region-locked, or if any kind of account or subscription is needed for watching the content, etc. This metadata needs to be set as a header comment at the beginning of the plugin file, in the following format (order of items is important):

    $description A brief description of the website, streaming service, etc.
    $url A URL which matches the plugin. No http:// or https:// scheme prefixes allowed.
    $url Multiple URLs can be set. Duplicates are not allowed.
    $type The type of content. Needs to be either "live", "vod", or "live, vod", without quotes.
    $region A comma-separated list of countries if region-lock applies. (optional)
    $account A brief note about account or subscription requirements. (optional)
    $notes Further short notes that may be useful. (optional)
  2. Add at least tests for the URL regex matching in tests/plugins/

    To do so, import the PluginCanHandleUrl test base class from tests.plugins, subclass it with a proper name, add the __plugin__ class attribute and add all URLs required for testing the plugin matchers to the should_match list.

    The optional should_not_match negative matching list should only contain URLs which the plugin should actively not match, which means generic negative-matches are not allowed here, as they will already get added by the plugin test configuration.

    In addition to the positive matching list, should_match_groups is an optional list for testing capture groups values for given URL inputs. It's a list of tuples where the first tuple item is a URL and the second item either a dictionary of regex capture group names and values (excluding None values), or a tuple of unnamed capture group values. URLs from the should_match_groups list automatically get added to should_match and don't need to be added twice.

    from streamlink.plugins.pluginfile import MyPluginClassName
    from tests.plugins import PluginCanHandleUrl
    class TestPluginCanHandleUrlMyPluginClassName(PluginCanHandleUrl):
        __plugin__ = MyPluginClassName
        should_match = [
        should_match_groups = [
            ("https://host/stream/123", {"stream": "123"}),
            ("https://host/user/one", {"user": "one"}),
            ("https://host/stream/456", ("456", None)),
            ("https://host/user/two", (None, "two")),
        should_not_match = [

Removing plugins#

  1. Remove the plugin file from src/streamlink/plugins/ and the test file from tests/plugins/