-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Turn --hls-duration
into a generic segmented-stream CLI arg and add support for DASH durations
#5450
Comments
timeout --signal=INT --kill-after=10 --preserve-status 60 streamlink ... https://www.gnu.org/software/coreutils/manual/html_node/timeout-invocation.html |
… when running from within a Python script, I meant. But yes, that is a more general solution of course! |
Then you don't need |
The example I gave is just a dummy example to show a workaround. It could have been written in whatever other programming language. If you're interfacing with the API, sure, you can do that, but like I wrote above, it will mean you have to re-do most of the CLI work. So I was looking for a more general solution. Feel free to close this issue if you don't think it's necessary. |
Thinking about it more, I believe there is a case for an even more general clean exit. Quitting the stream with SIGINT leaves you with possibly broken output, e.g. in the above case,
Runs into this error:
Because the signal may abort the download somewhere in the middle of a segment being written out. |
HLS streams have an option for ending the stream gracefully at specific segments: DASH streams currently don't have such an option. And for other non-segmented types of streams, it's not possible. |
Oh, I didn't see that, thanks. In that case it could probably be added for DASH. I will look into whether I can create a PR. |
And for regular SIGINT/SIGTERM behavior, it's not possible to always end cleanly/gracefully, because Streamlink's ringbuffer is unaware of its content structure, meaning when the CLI stops reading, it can be at any point, just like you've said. The various stream implementations simply write the contents to the buffer which the CLI or API consumers are reading from. Streamlink's main purpose is not recording, so if you need to fix your files with ffmpeg after recording, so be it. |
I can have a look at this tomorrow or so. The Not sure yet though what this will mean to |
Sure. |
I want to avoid These changes however won't make it into 6.0.0. That release will be out very soon and I don't want to delay it any further. |
--hls-duration
into a generic segmented-stream CLI arg and add support for DASH durations
I have a local branch ready which I will submit later. This will deprecate Theoretically, this could/should be implemented in the Then there's the issue with the related |
Oof, that does not sound that easy. I've recently had my issues with a DASH stream without known durations and I can relate to this. I'm not deep into the code base but happy to test/comment on any proposed changes if that helps. Thanks for sharing your considerations! |
See #5493 |
Checklist
Description
Currently the CLI runs indefinitely until an error occurs or the user terminates the command by pressing
Ctrl-C
(sendingSIGINT
).It would be beneficial, for automated/non-interactive use, to have an option to quit after a specified amount of time, which is particularly useful for never-ending live streams.
This could be an option called
--stream-duration
or--quit-after
, taking a value in seconds after which the program cleanly exits, once a stream has been opened and read from.The only viable workaround would be to run something like this, although it is not precise, since the overall timeout includes the time to load the stream as well:
Of course, this could be implemented using the API, but it would require re-doing everything the CLI is doing anyway.
The text was updated successfully, but these errors were encountered: