fromFirstPosition does not start from actual first position in live DASH manifest (multi period live with SSAI) about rx-player HOT 2 OPEN

@peaBerberian we are checking with the provider of the streaming platform in what way we can further "tweak" the streams in order to start at the beginning of the inserted pre-rolls ads. Once I have an update on this I will share the results.

from rx-player.

Hi,

First sorry I know we had another channel of discussion and didn't take the time to answer there yet (I now just did a little late).

As discussed, the first segment the RxPlayer can load is determined through a complex combination of multiple MPD attributes. The most important ones seen on the MPD you communicated were: the UTCTiming element (providing here the live position), the MPD@availabilityStartTime attribute (providing the base offset), the MPD@timeShiftBufferDepth attribute (providing the buffer depth server-side, which we for now consider as a delta from the live position derived from the value extracted from the UTCTiming element) and the list of announced segments (to simplify, we determine the intersection of both time ranges derived from [live position - timeShiftBufferDepth, live position] and the one derived from [time of first segment, time of last segment] to understand what segments are actually available).

Here it seems that the timeShiftBufferDepth is I would say "pessimistic" as it did not include the full range of the ad inserted before the actual live content, thus the RxPlayer believes that older segments for the pre-roll ad announced in the MPD are already to old to be requested.
I think that not setting the timeShiftBufferDepth or setting one high enough will allow the RxPlayer to understand that those segments are still valid but I understand that the tool you have to produce the stream's MPD is not able to do that.

I'm not convinced by the idea of indicating through some API that all segments seen in the initial MPD are all valid because of several issues:

• after some times, old segments will be removed (if not for the dynamically-inserted pre-roll, at least it will be the case for the first segments of the live content after enough time). So there is still the need to really rely here on the MPD@timeShiftBufferDepth attribute in some capacity

• This way of including pre-rolls in a live stream kind-of look like a hack mimicking this is a live content (though I guess most of such solutions are hacky) where it is actually a concatenation of a VoD + live content and the limitation to me seems more tool-related than about the RxPlayer's interpretation of what constitutes a "requestable" segment.

  To me, being able to update the MPD@timeshiftBufferDepth solution on the MPD seems like a proper way of communicating that dynamic inclusion/exclusions of segments as the MPD is refreshed, though this is not perfect either (as live is actually treated differently than the pre-roll here - I'm not sure that DASH allows for this).

• We tested other live pre-roll solutions, including one from Google, which do work with the RxPlayer (though we still considered those solutions "hacky") without having to perform any updates on the treatment of those attributes (e.g. Google only reported to us a possible optimization but it wasn't related to the aforementioned issue) - so we know that the feature can still work without having to provide and maintain complex player APIs.

So I would first prefer to exchange with the provider of this ad-insertion tool to be able to find a solution which would be more viable.

from rx-player.