cli: implement --player-external-http-continuous

[bastimeyer]

Resolves #4738

No tests, because no tests have ever been written for output_stream_http() or the entire streamlink_cli.utils.http_server module.

• https://github.com/streamlink/streamlink/blame/4.3.0/src/streamlink_cli/main.py#L164-L274
• https://github.com/streamlink/streamlink/blame/4.3.0/src/streamlink_cli/utils/http_server.py

---

There are two choices that can be made for implementing the new CLI argument:

1. The current implementation, with --player-external-http-continuous=bool requiring a boolean value and affecting the logic of the main argument --player-external-http.
   The issue with this is that it's not consistent with the logic of the --player-http and --player-continuous-http arguments, which are individual arguments. It's also not consistent with the naming scheme (which I just realized), so it probably has to be changed to --player-external-continuous-http.
2. Having two individual CLI arguments, --player-external-http and --player-external-http-non-continuous, similar to --player-http and --player-continuous-http. As you can see, the default logic of --player-external-http already is "continuous", so the second argument name has to be negated, which is not great.

Thoughts?

[nbgibson]

Of the two paths listed here I'd have to lean towards the former (renamed to be in spec with the rest of the command schema of course), though I'm not too much a fan of either for the reasons listed above. As is I think there is potential for a larger rework of of how the server option tree is handled, but that's beyond the scope of this particular PR.

My reasoning is:

• As is we already have to pass a separate flag for configuring ports when the "better" flow would be to just optionally tack on a desired target port to --player-external-http, so having another flag or two isn't exactly new. It's not ideal, but it's also not exactly a deviation at this time.
• The flow here isn't really a deviation from --player-external-http imo as that process flow (from my understanding) is still on the "desktop" side of things albiet with a web based serving method. --player-external-continuous-http and so forth are all off in headless land.

[bastimeyer]

1. It's also not consistent with the naming scheme (which I just realized), so it probably has to be changed to --player-external-continuous-http

Hm, that's not consistent with --player-external-http-port then... I think I will just leave it as it is. The parameter naming scheme isn't particularly well thought out anyway (eg. --verbose-player), and using natural language for parameter names instead of logical/layered suffixes makes everything an inconsistent mess anyway.

I think there is potential for a larger rework

Yes. After Livestreamer got forked into Streamlink, the CLI was never cleaned up and it's a total mess of historically grown features built on top of each other over several years by lots of different contributors. That's why nobody has tried refactoring or rebuilding the CLI package, and it's still a mess today. And starting from scratch is even more difficult if feature parity needs to be achieved without introducing (many) breaking changes. One feature in regards to the external http server for example was being able to serve multiple clients at once, but implementing this on top of the current code just doesn't make sense from a maintenance perspective.

just optionally tack on a desired target port to --player-external-http

I think this has been avoided intentionally when it was implemented, because optional argument values are a bit weird. The argument could be changed to nargs="?", action="store", which would make the value optional.