plugins.twitcasting: switch to llfmp4 and tc-hls #6540
Conversation
|
I've tried it out and I observe the same: both streams work, HLS has some extra delay. I've tried around ~20 different channels and all of them had both My normal use case is to output to a |
|
Of the 8 streams that I left recording overnight (using the |
Thanks for checking... I'm not going to merge this one then. This plugin simply downloads a progressive stream from a websocket, meaning there's no remuxing of separate video and audio streams being done. When there's desync, then this is caused by the stream not having proper presentation timestamps of the video and audio streams set, so the player is unable to synchronize the data. According to a quick test, both video and audio streams from the This is not the case on the master branch with the old websocket addresses HLS streams also don't have this issue, but those are avoided due to latency reasons... |
|
See comment #6539 (comment) for some testing, also just tested this patch on a password protected stream: Websocket works, but HLS doesn't. The "word" query param needs to be added to the playlist URL just like is done for the websocket connection. The playlist request then sets a cookie that is needed for accessing the media segments, I assume the HTTP session would handle this automatically though (manually passing in the properly formatted playlist URL to streamlink plays it correctly). |
bastimeyer
force-pushed
the
plugins/twitcasting/llfmp4-and-tc-hls
branch
from
6565774 to
5d2f1a0
Compare
|
@Hakkin thanks for checking...
See my comment above. The websocket streams don't align the audio and video streams at all, which means it's completely unpredictable whether a stream will have desync or not and how much the desync will be, a couple of frames or multiple seconds. The old websocket streams on master had relative timestamps set (now also offline for me) whereas the HLS streams have absolute timestamps set, which both work fine. From this PR branch, first stream from their popular live streams page: Since their website also defaults to the websocket streams, there's not much we can do here. If there's desync, then so be it. I don't think selecting HLS streams as the default makes much sense considering the ridiculous latency. Users can always choose the HLS streams for recording. I've updated the stream names accordingly, to avoid any potential confusion on which stream is using which protocol (another case of the urgently needed full rewrite of the stream selection #4902). I've rebased the PR and also added the Going to merge this in a bit later. You can give this a try if you want though... |
Tested, HLS works fine now, thanks.
The PTS starts at 0 and seems to increase properly, which should keep sync as long as they implemented it correctly, but obviously something on their end is messed up and the audio and video PTS starts get offset somehow. Agree that there's not really anything that can be done about it. |
Ref #6539
@qwer-lives have a look at this PR please.
https://github.com/streamlink/streamlink/blob/master/CONTRIBUTING.md#pull-request-feedback
This switches to the
llfmp4andtc-hlsstreams, which also simplifies the plugin. I have no idea about the availability of these streams compared to the previous implementation though, so I'd like to get some feedback on this from users of this site. As can be seen in the PR's diff, previously, llfmp4 was avoided because of alleged video/audio desync issues.I also have no idea about password protected streams. Similar to before, this is only implemented for the websocket streams.
HLS have been assigned a lower priority because of the delay.
--stream-priority=websocket/--stream-priority=hlsallows for selecting only a specific type of stream...websocket
HLS (~15 seconds of delay)