plugins.nicolive: set stream cookies from WS data #6441
Conversation
|
The live stream works fine, but for Timeshift content, it seems that decryption fails if the m3u8 contains #EXT-X-DISCONTINUITY. |
I have explicitly asked for results of the Whether their timeshifted streams break is unrelated to this PR. Discontinuities are technically not supported by Streamlink. However, segment decryption is not supposed to break during a discontinuity, so there might be a different bug that needs fixing. Apparently the segment's key state is not reset on a discontinuity tag: I can have a look at this issue later, but if you want to provide additional details, then please open a new issue (bug) with HLS playlist contents that can reproduce the issue. |
|
JFYI, I'm not going to merge anything without proper feedback that I have asked for. All I'm seeing are silent thumbs-up reactions from some users. I don't care about this at all. |
I have only found that one stream have video with length 01:59:57.08 and audio with length 01:59:42.08. |
|
I am translating from Japanese using ChatGPT. https://live.nicovideo.jp/watch/lv347086431 I downloaded this broadcast using Streamlink without specifying the |
Thanks for checking. I'll add the
This can happen when the two separate HLS playlists (the video and the audio one) are not aligned on their first access. HLS playlists offer a certain time frame where individual stream segments can be accessed. Streamlink will start downloading segments from each HLS playlist independently and write their outputs into the named pipes where the FFmpeg process then reads from when muxing. While muxing, FFmpeg then aligns the timestamps of both streams, so you don't have audio desync in the resulting output. It however doesn't discard data from the streams, which means that if there's a time-offset of the video and audio streams, then you'll have a short period at the beginning of the stream where there's either only video or only audio data. This purely depends on the first access time of each playlist. Streamlink currently doesn't check for time-alignment when accessing multiple HLS playlists while muxing. The DASH implementation does have such a mechanism, but there it's trivial to implement. What needs to be done on the HLS side of things is that the This is however unrelated to any plugin implementation, so it's not relevant here. I'll add this to the HLS TODO list and will open an issue thread for this later. |
Thank you so much. |
and refactor websocket message handlers with a mapping lookup
bastimeyer
force-pushed
the
plugins/nicolive/stream-cookies
branch
from
50de81b to
e1bde18
Compare
|
log-streamlink.txt Version: 7.1.3+26.g6e8d7ce Downloading starts just fine but finishes within a few minutes with only audio being good. Output file has a gray screen with some occasional pixels. I've tried enabling --ffmpeg-copyts as suggested but no luck. Edit: Tried multiple timeshifts but same results across the board
|
|
This is completely unrelated to the issues which this PR has solved. As you can see, there's a discontinuity in the VOD which is explicitly unsupported (the log output is unfortunately intertwined between the two threads for the video and audio streams). The plugin could try filtering out the |
Fixes #6440
@cykac04 please have a look at this PR...
https://github.com/streamlink/streamlink/blob/master/CONTRIBUTING.md#pull-request-feedback
After browsing lots of streams, I was finally able to find one live stream where cookies were required. The one you posted was offline unfortunately.
HLS streams where cookies are required all appear to be multivariant streams with an external audio stream, so muxing via FFmpeg is required. I'm not sure, but I think there's an issue with the audio stream synchronization. That is unrelated to the plugin however, as it has nothing to do with the HLS protocol or the stream data. It may be an issue with the stream itself, because audio synchronization depends on the individual bitstreams and their presentation timestamps, not on the HLS metadata (this is not a packed audio stream where this would be the case). It might be necessary to set
--ffmpeg-copytsin order to fix audio sync issues, which could also be forced by the plugin code.Audio sync issues can happen occasionally - they don't have to appear all the time, depending on the initial sub-stream access timing. So I'd like to ask you to check and see if there are audio sync issues on the streams you're trying to watch without the
--ffmpeg-copytsparameter being set and whether setting the--ffmpeg-copytsparameter fixes them reliably 100% of the time.Btw, the fact that they're using a newer version of the HLS protocol (despite not annotating it correctly) which is still not yet released/finalized is irrelevant, even if Streamlink doesn't support it yet, as everything's backwards compatible.