Use of maxSegmentDuration when calculating liveEdge for initialisation

[srstrong]

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?

[TheModMaker]

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 <SegmentBase> or <SegmentList> with byte ranges to specify a range within the file. Note that (ignoring <SegmentBase>) we only use the info in the manifest to determine what to download; so we won't use any sub-segment information.

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.

[srstrong]

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:

However Segment duration may differ from Representation to Representation. A DASH presentation can be constructed with relative short segments (for example a few seconds), or longer Segments including a single Segment for the whole Representation

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.

[TheModMaker]

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 <SegmentBase>. In this case, the manifest only specifies a byte range of the sidx box and we parse it to determine where the segments are. In the case of <SegmentList> and <SegmentTemplate> the manifest already specifies where the segments are so we don't need to download anything to construct the index.

[srstrong]

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.

[TheModMaker]

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 <SegmentBase> element for the first Period. That would have us use the sidx box for the index. Then you could still use <SegmentTemplate> or <SegmentList> for the live portion. The only problem is it is against the live profile so some clients may not support it, but we will.

[srstrong]

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

[joeyparrish]

Okay, sounds good. I'll close this issue for now, and we can move discussion of subsegments to #1503. Thanks!