Provide [quality] argument as --quality

[holomorph]

Now that the fallback mechanism is in place, and [quality] has always been an optional positional argument anyways, it would probably serve better as a command line option, which could then be set in a configuration file

# livestreamer/config
quality=best,high,medium

As for the use case, it's much more convenient for livestreamer to be able to read this from the config rather than always having to indicate the quality on the command line or in any function/wrapper calling livestreamer.

Related to #146 and #204

Edit: by [quality] I meant [stream], as per --help

[Earnestly]

Second this. We've gone through many different mechanisms for setting the quality levels and have finally found a nice one, that is, comma-seperated fallback.

Getting rid of all other mechanisms and just providing it as a command line flag is nice.

I'm not really sure about the pseudo-interactive nature of livestreamer, having to query a stream just to query it again with a chosen quality set seems very awkward.

To solve this I have taken to starting livestreamer with the list of acceptable qualities pre-defined, such that a typical use would be:

livestreamer() {
    options=(-a -b -c) # or defined in the config

    command livestreamer "${options[@]}" "$@" medium,high,source
}

Which obviates the need to constantly run livestreamer twice. Setting this in the config would make the interface a lot cleaner imo.

[chrippa]

Getting rid of all other mechanisms and just providing it as a command line flag is nice.

I'm not really sure about the pseudo-interactive nature of livestreamer, having to query a stream just to query it again with a chosen quality set seems very awkward.

Yeah, I agree. Adding --best-stream-default was probably a mistake, it should have been something like --default-stream <streams> instead.

I'm not really sure about the pseudo-interactive nature of livestreamer, having to query a stream just to query it again with a chosen quality set seems very awkward.

This idea of querying the streams and then choosing stream exists mainly because in the early versions we didn't have any way of ranking the streams internally and the user had to make a choice of the available streams instead of relying on best/worst.

I'm thinking in 2.0 (I don't want to make a major change like this before that) we will just default to starting best and then the user can override it with either adding the stream as last argument or setting it via a config option.

In 1.9 though, I will probably deprecate --best-stream-default and replace it with a option to set a list of default streams as suggested.

[Earnestly]

Wonderful stuff, thank you for making my non-flash life much more rewarding \o/