plugins.twitcasting: rewrite plugin #5255
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Was testing on random streams and noticed If I try to open it directly in a new browser tab (i.e. no Referrer, etc. headers) I get "Forbidden". |
|
Results of some tests. WebSocketSeems to work just as fine as it worked before this PR. Something I have noticed is that for some streams the web player has options for High, Medium and Low qualities, for other just High and Low, and for other there is no quality option as there is only one WebSocket stream available. It looks like they correspond to the HLSAs streamlink/src/streamlink/plugins/twitcasting.py Lines 116 to 117 in becd39d part to force it to use HLS on other channels that have both WebSocket and HLS. HLS seems to be broken: |
Member
Author
Yes, this is what the JSON response data refers to in the
This looks more like the stream went offline after you started watching. Before I submitted this PR, I tested HLS streams on various live channels and they all worked fine for several minutes, so this also excludes some kind of playlist/segment URL expiration. I'll check again later. |
You are probably right, I'm no longer able to reproduce this, it seems to work now. By the way, if the stream goes offline, streamlink should terminate instead of trying to download next HLS segments indefinitely, getting HTTP 404. |
Member
Author
|
- Refactor API query - Add HLS streams, but prefer websocket streams due to lower latency - Enforce TLS for HLS and websocket streams
becd39d to
9f9e256
Compare
Member
Author
|
The plugin now returns all available websocket and HLS streams, but websocket streams get ranked higher than HLS streams due to latency reasons. "llfmp4" websocket streams get ignored, because they caused video/audio desync in my tests. Quality-wise, there's no difference and latency-wise there's no difference either from what I could observe. The HLS stream URL from the "dvr" JSON field also gets ignored because of the 403 response. These changes should be fine now. Example of a stream with all available qualities for both websocket and HLS streams: |
4 tasks
5 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #5254
@nurupo please test.
Either sideload the plugin from here:
https://raw.githubusercontent.com/bastimeyer/streamlink/plugins/twitcasting/rewrite/src/streamlink/plugins/twitcasting.py
https://streamlink.github.io/cli/plugin-sideloading.html
Or install from my branch via
pip:https://streamlink.github.io/install.html#pypi-package-and-source-code
pip install -U "git+https://github.com/bastimeyer/streamlink.git@plugins/twitcasting/rewrite"Notes:
media=source. I don't know if that's correct, as there's thesourcefield in the JSON response. The websocket streams have different quality options for the different API responses, but the HLS streams do not in the current implementation."fmp4"websocket streams, the API response also includes"llfmp4"streams which the website seems to be using. This is currently not implemented, but this could be changed in another PR. The current websocket streams are still working fine.