Enormous timeShiftBufferDepth memory consumption by SegmentReference

[awojtasd]

What version of Shaka Player are you using?
v3.2.0-compiled

What browser and OS are you using?
Any (Chromium, WPE, Safari, ...)

What did you do?
Play live dash content with:

• 1 Audio representation
• 3 Video representations
• 2.56 segment duration

What did you expect to happen?
The Shaka is running on memory restricted device. The total number of representations which needs to be supported is about 15-20 (audio representations + video representations). The segment duration can be adjusted between 1.92 and 3.2sec. Maximum duration of dvr window = 12h. Assuming that segment duration is 3.2sec (optimistic scenario) and the number of representations is 20, the memory required by SegmentReference for 12h dvr window is ~65Mbytes.

Is there any way to reduce that amount of memory e.g by additional configuration which will allow to evict SegmentIndexes and SegmentReference that are older that 1h or if playing timeshifted, evict the SegmentReferences and SegmentIndexes which are out of moving window (-1h - + 1h). When user seeks out of that range the manifest is reparsed and appropriate SegmentReferences/Indexes are created.

What actually happened?
The memory footprint grows really quickly (linear grow over the time).
Example for 1 audio repesentation and 3 video represenations, 2.56s segment duration:
@ timeShiftBufferDepth="PT20804.240S":

@ timeShiftBufferDepth="PT26402.960S":

[awojtasd]

If there is no existing mechanism which allow to reduce memory footprint (due to high memory demand related to SegmentReferences), my suggestion is:
Add a mechanism which will allow to evict SegmentReferences that are out of config defined range. During the seek the manifest could be re-parsed and appropriate SegmentReferences created.

[joeyparrish]

We keep references in memory to segments which are "available". In DASH, the "availability window" size is defined by the timeShiftBufferDepth attribute.

You can override the manifest's availability window with the config manifest.availabilityWindowOverride:

player.configure('manifest.availabilityWindowOverride', 3600 /* 1 hour in seconds */);

References for segments described in the manifest will always be parsed, but eviction will remove them from memory. If the DASH manifest uses SegmentTemplate+duration (no SegmentTimeline), then the overridden availability window will limit the number of references generated from the template without waiting for eviction.

Does this help?

[beka-discovery]

Thank you for the answer @joeyparrish.
Theoretical question: Can Shaka create Segments on demand(Lazy segment address creation) instead of creating them at the manifest parsing phase?

The motivation behind the question is, there are lots of STBs with limited amount of memory.

[joeyparrish]

Today, no. It's an architectural issue, because we have to support several input formats, and in only one case is it even possible to generate those on-the-fly:

• HLS playlists (explicit list of segment durations and URLs)
• DASH SegmentList (explicit list of segment times, durations, and URLs)
• DASH SegmentBase (SIDX box, parsed to get a list of segment times, durations, and byte ranges)
• DASH SegmentTemplate + SegmentTimeline (explicit list of segment times and durations, URLs could be generated late)
• DASH SegmentTemplate + duration (everything could be generated late)

To keep the source manageable, we turn all of those things into one internal format. It's not as memory-efficient as it could possibly be. I'd be happy to discuss changes, though. I'm open to ideas.

We used to have a method in SegmentReference that you would call to generate a URL on-the-fly, but it was removed in v3.0. It was part of an effort to flatten multi-Period DASH content into a single set of variants that covered the entire presentation. Having simpler references made that easier.

However, Period-flattening wasn't a popular move with everyone. If we made some changes to the representation of multi-Period DASH in the future, we could also consider going back to a more dynamic version of SegmentReferences. Maybe a holistic redesign of shaka.extern.Manifest with an eye toward memory consumption would be a good idea.

In the meantime, what we have available is manifest.availabilityWindowOverride.

[github-actions]

@awojtasd Does this answer all your questions? If so, would you please close the issue?

[github-actions]

Closing due to inactivity. If this is still an issue for you or if you have further questions, the OP can ask shaka-bot to reopen it by including @shaka-bot reopen in a comment.