Thanks to visit codestin.com
Credit goes to github.com

Skip to content

stream.hls: Apply segment ignore_name regardless of extension#6747

Merged
bastimeyer merged 2 commits into
streamlink:masterfrom
qwer-lives:ignore-names-any-extension
Dec 18, 2025
Merged

stream.hls: Apply segment ignore_name regardless of extension#6747
bastimeyer merged 2 commits into
streamlink:masterfrom
qwer-lives:ignore-names-any-extension

Conversation

@qwer-lives

Copy link
Copy Markdown
Contributor

Minor change to match ignore_name patterns regardless of segment extension (before this it only matched .ts segments).

@bastimeyer bastimeyer left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the PR.

The --hls-segment-ignore-names stuff is rather old (added in 39d81e3) and predates the segment filtering implementation. I've talked about it a couple of times already on the issue tracker that I'd like to replace or remove it, because it's pretty bad. The reason why this ignore-names implementation is not ideal is that it receives user input from the CLI via a comma-separated string, and it's also very limiting for selecting specific segments because of this regex idea. All of that is irrelevant for your PR though.

What is relevant though is that both the current implementation and your PR are not correct and require a change. The HLS specification (RFC 8216) doesn't say anything about media segment URIs/URLs. It only requires HLS multivariant+media playlists to either have an .m3u or .m3u8 URL path suffix, or the HTTP server must send the application/vnd.apple.mpegurl/audio/mpegurl Content-Type response header. Media segments are unspecified, meaning the regex should not contain a suffix, not even a "wildcard" one.

There's also an issue with a changed test which I've annotated.

Comment thread tests/stream/hls/test_hls_filtered.py
@qwer-lives

Copy link
Copy Markdown
Contributor Author

Thanks for the comment - I didn't notice that the ".*" was actually useful :) I applied the changes.

Also, I didn't realize this feature was that old. This PR is mostly for my convenience since I use this to filter out segments when using the HLS plugin (for platforms that don't have their own specific plugin). Feel free to ignore it if you're going to rewrite / remove the feature in the near future.

@bastimeyer

Copy link
Copy Markdown
Member

Apologies for the late response.

I'm a little bit torn here, because changing the regex and removing the incorrect suffix results in some unintended side-effects that change the behavior of this feature, because the regex is applied to the whole segment.uri attribute. Previously, this implicitly matched the URL path due to the .ts suffix, but without a forced suffix, it can also match the hostname for example, or the scheme if the user just sets the https value.

As said, this feature is implemented poorly. A proper filtering mechanism shouldn't be based on the segment.uri attribute alone (and as a whole). The segment filtering should allow users to select specific segments based on various segment attributes, as well as individual attributes of the parsed URI. This would need to be implemented as a new feature, and the current one would need to be deprecated. But all of this is out of scope of this PR.

Since this is such a niche feature and one that should be replaced anyway, I think I'm going to merge your changes, but I will have another thought about it later today.

@bastimeyer bastimeyer merged commit f694fe7 into streamlink:master Dec 18, 2025
37 of 39 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants