--stream-types can still be used though for filtering out unwanted stream types.

basically required

streamlink https://www.zdf.de/nachrichten/heute-sendungen/so-wird-das-wetter-102.html --stream-priority hls --json --stream-url

vs

streamlink https://www.zdf.de/nachrichten/heute-sendungen/so-wird-das-wetter-102.html --json --stream-url

"url_manifest": null,

might return the type of the manifest or use a different name, not url_manifest

the output seems weird sometimes

--json --stream-url

These params are mutually exclusive...

might return the type of the manifest or use a different name, not url_manifest

And as said, it's only a problem if the plugin yields streams from different sources, but I don't see any way of fixing this in the regular --stream-url output. If the user hasn't selected a stream/quality, and the plugin yields different stream types, what should be done here other than selecting the last (usually the "best"/"best-unfiltered") stream? Reading the value of all streams and returning everything is not possible, because --stream-url is supposed to return only a single URL. Returning just one, sorted by the number of occurrences seems confusing if the number of stream types varies.

Regarding the name, the problem is that streamlink_cli should not have individual implementations for the various stream types, so a generic name needs to be chosen. I went with "manifest", because that works with DASH streams as well as HLS streams, and on HLS streams, "master" or "variant" are both specific terms only related to it. Not sure about the other stream types.

In the JSON output, as opposed to being null, the url_manifest property could be removed if a value doesn't exist, if you prefer it that way. That could prevent some kind of confusion, but a parser would have to deal with conditional properties. Or as a better solution, the "manifest-url" could be added to the object (and string representation) of each stream item. That would make it less legible with lots of repetitions, but would solve the stream type issue.

the output seems weird sometimes

The output hasn't been changed at all.

Removed the url_manifest property from --json again since each stream item has its own JSON representation and HLS streams with a master playlist now have an additional master property.

Also changed the string representation of the HLSStream class to include the master playlist URL if it exists, and renamed the internal property and constructor parameter to url_master.

The to_url_manifest interface still exists on the abstract Stream class, as I couldn't find a better name that fits into every stream type. This method is needed for the --stream-url parameter, which reads the value from the last stream item in the resolved streams dict, which is usually "best".

I'd think to_manifest_url is a better name, as it's the url to the manifest, not the manifest of the url?

@beardypig My idea was to have "manifest" as a suffix, so that it fits into the scheme of the existing interface. I can change it though to your suggestion which makes more sense readability-wise.

What's the decision here before I rebase? Rename it or not?

@bastimeyer I'm not particularly passionate about either option, let's just rename it to to_manifest_url so we can get this merged.