-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Use of maxSegmentDuration when calculating liveEdge for initialisation #1512
Comments
First, having a segment size of 1 hour probably won't be supported. It would require us to download the whole segment which will take a while and the whole segment needs to be stored in memory when we give it to the browser. We don't support downloading partial segments. Note that there is a difference between a segment and a file. For live profile, the segments are stored in different files; but for on-demand profile, the segments are all stored in a single file. So if you don't care about using a specific profile, you can just store the segments for the first Period in a single file and use either Also having 0.6 second segments means we are downloading a lot of segments while we play, which can cause slowdowns; the common length to use is 2-6 seconds. But to answer your question, there isn't any way to change that. We are going to change how we determine the live edge in #999, which will stop using the wall-clock time at all. That enhancement should allow your manifest to work. |
Thanks for getting back to me - firstly, #999 does look like it will likely solve my problem. However, whilst I've got your attention, I'd like to just clarify your comments about my segment size, since it looks like I have misinterpreted the spec. From section 4.3, the spec says:
Which is where I've got the idea that a one-hour segment wouldn't be considered unusual. Although I haven't yet implemented it on the server-side, I am intending to provide a segment index (sidx box) to identify the sub-segments, and I was expected that Shaka would read that sidx and then perform range requests on the segment to download the access units that it needed - I saw parsing code for sidx in the shaka source, so had made the assumption that it was using them. However, your comment says that the player will only download full segments, and that partial downloads are not supported. Have I misunderstood the spec or your response (or both!)? Thanks for your help. |
A single segment for the whole Representation is common for text streams since they are so small. But having a single segment for video would be much larger. I think DASH has a way to signal sub-segment info, but we don't support it. We only support playing whole segments. We do handle sidx parsing, but only for |
Ah, ok - so sidx isn't used in conjunction with subsegments but only for SegmentBase. Taken another quick skim through the code, and can see that subsegments aren't used - my initial search was on sidx, and when I found that I assumed it was being used for subsegments without checking further. Thanks for clarifying, I'll have a rethink as to how I'm structuring my manifest! Out of interest, are there any plans in the future to support subsegments? I think the sidx approach will be considerably more compact than the segment timeline that appears to be the only alternative. |
We could add support for subsegments, but it might be difficult. We currently think only about segments, so it may be difficult to change to think about subsegments. Although, we might be able to just use the same type for subsegments. But what you can do is use a |
Ok - I guess this relates a little to the conversation on #1503 - if subsegments aren't supported, then I suspect support for ssix is also likely to be difficult. I'll try to have a dig through the code at some point - naively, I would think that a segment that included subsegment information then the index could be parsed and the segment just transformed from a single segment to a list of segments, much as you are thinking. Much of the spec uses Segment and SubSegment interchangeably, suggesting that the authors had this sort of approach in mind. I'll start reading the docs and the shaka code a bit more fully and see if it looks plausible |
Okay, sounds good. I'll close this issue for now, and we can move discussion of subsegments to #1503. Thanks! |
Hi,
I've got a dynamic dash manifest with 2 periods. The first period consists of recorded data, and has a fairly large segment size (I'm testing with 1 minute segments, but in production this would be more like 1 hour - each segment would have an index available to allow sub-segment streak switching, but that's not the issue).
The second period represents live, where data is still being ingested and recorded. To keep latency sane for the live stream, we have much smaller segments (I'm currently testing with 0.6 seconds).
At startup, Shaka is working out the appropriate playhead time from which it can then choose a period, which ultimately boils down to the getLiveEdge_ function - it has the following logic:
now - this.maxSegmentDuration_ - this.presentationStartTime_
Which, due to my large segment durations on the first period puts me nowhere near where live is - instead, it's starting playback around 1 minute in the past (which in production would end up being ~1hour in the past).
The use of maxSegmentDuration in that code makes a degree of sense, and for an MPD where the segments didn't have a varying size would be fine. However, for my scenario I'd really like the player to use the maximum segment duration from the last period, rather than across the whole presentation.
Is there anyway to achieve this?
The text was updated successfully, but these errors were encountered: