New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide [quality] argument as --quality #381

Closed
holomorph opened this Issue May 8, 2014 · 3 comments

Comments

Projects
None yet
3 participants
@holomorph

holomorph commented May 8, 2014

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

This comment has been minimized.

Show comment
Hide comment
@Earnestly

Earnestly May 8, 2014

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.

Earnestly commented May 8, 2014

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

This comment has been minimized.

Show comment
Hide comment
@chrippa

chrippa May 9, 2014

Owner

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.

Owner

chrippa commented May 9, 2014

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.

@chrippa chrippa added feature labels May 9, 2014

@chrippa chrippa added this to the 1.9 milestone May 9, 2014

@Earnestly

This comment has been minimized.

Show comment
Hide comment
@Earnestly

Earnestly May 9, 2014

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

Earnestly commented May 9, 2014

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

@chrippa chrippa closed this in 4cd5db3 Jun 6, 2014

cheah added a commit to cheah/livestreamer that referenced this issue Aug 17, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment