-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
stream: add --stream-segmented-duration argument #5493
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
stream: add --stream-segmented-duration argument #5493
Conversation
| * - stream-segmented-duration | ||
| - ``float | None`` | ||
| - ``None`` | ||
| - Limit the playback duration of segmented streams, rounded to the nearest segment |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As an outsider, I still think this name is a bit confusing or hard to discover. Why are the other stream-segment options in present tense?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- https://deploy-preview-5493--streamlink.netlify.app/cli#cmdoption-stream-segmented-duration
- https://deploy-preview-5493--streamlink.netlify.app/api/session#streamlink.session.Streamlink.set_option
We can change the description's imperative, to make it more consistent with the other descriptions. As you can see in the diff, this was copied from the old option.
I have already explained the reasoning behind the option/CLI-argument naming. If you have a better name, then suggest one. It can't be stream-duration, because it's limited to segmented streams. The stream-segment-... options are meant for logic that affects single segments in segmented streams. The newly added stream-segmented-... options are for logic that affects segmented streams as a whole.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, no worries, I have no better suggestion that wouldn't at the same time give the impression that it works for all streams.
| yield segment | ||
|
|
||
| # init segments have duration set to None | ||
| duration += segment.duration or 0.0 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a chance that other segments have no duration set (after the init segment?). If so there could be a warning about it, because the overall duration is wrong in that case.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The duration attribute is mandatory for segments in SegmentLists and SegmentTemplates, and so is the d attribute in SegmentTimelines.
See ISO/IEC 23009-1:2022 or the XML schema here:
- https://github.com/Dash-Industry-Forum/MPEG-Conformance-and-reference-source/blob/c50c32e61b5c1d3401840872a45bc10f6ea2709a/conformance/MPDValidator/schemas/DASH-MPD.xsd#L311
- https://github.com/Dash-Industry-Forum/MPEG-Conformance-and-reference-source/blob/c50c32e61b5c1d3401840872a45bc10f6ea2709a/conformance/MPDValidator/schemas/DASH-MPD.xsd#L371
Other kinds of DASH stream types are not supported by Streamlink.
We do however treat the duration attribute as optional:
This was added in 577617a for some reason, so when I refactored the whole DASH code earlier this year, I kept it. While the specification needs to be strict, a DASH manifest parser shouldn't be, so even broken/invalid manifests can be played.
Each media Segment that gets yielded by the DASH manifest parser does have a duration set, and it can only be None if the duration attribute is missing, which is not Streamlink's fault in this case.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Apparently the duration can indeed be optional, because of manifests with only a single segment.
- Deprecate `--hls-duration` in favor of `--stream-segmented-duration`, as well as the respective session options - Update and rename `HLSStreamWorker.duration` attribute - Rename from `duration_limit` - Don't cast to `int` - Update log message when ending the stream early - Add tests
- Add `duration` parameter to `DASHStream`, similar to `HLSStream`, and add support for `--stream-segmented-duration` - Update, fix and add tests: Split up `worker` fixture of `TestDASHStreamWorker` into `stream`, `reader` and `worker`
3316ce8 to
72ef570
Compare
|
After having a look at the start-offset changes, I'm unsure if I want to continue this PR in the current state. As said, I only want to merge the duration changes into master if the start-offset changes can be merged at the same time, as both are related. I've already explained that the duration implementation should actually be moved to the This means that the HLS implementation needs to move away from the unnecessarily confusing Otherwise, the HLS and DASH implementations require different logic for calculating the start-offset and durations, which is stupid. Refactoring this is very much beneficial, but it's also much more work. |
|
Closing in favor of #5601 |
Closes #5450
This deprecates
--hls-durationin favor of--stream-segmented-durationand adds support for stream durations to DASH streams.Opening this as a draft for now since I want to have a look at
--hls-start-offsetfirst, as mentioned here:#5450 (comment)
Also, as mentioned, the duration logic unfortunately can't be implemented in the
SegmentedStreamWorkerbase class (for now), becauseHLSStreamWorkerandDASHStreamWorkerboth yield different kinds of "segments". I'm putting this into quotes here, because the HLS implementation doesn't actually yieldSegmentobjects, butSequenceobjects, which are segment wrappers, which means it's incompatible and would require a deep refactoring first.The related
--hls-start-offsetchanges I've talked about in #5450 (once I find the time and motivation to work on it) will be done in a separate PR. But until I'm done with that or made a final decision that it's not worth changing it, or if it even can't be done, this PR will stay as a draft.HLS
DASH
DASH using dash-protocol plugin and the duration parameter