Segment time not available when loading segment

[AndreasVidovic]

It is no longer possible to access segment.time from segmentLoader since the segment object has been removed in version 4.x. We use segment.time to retry segment fetching in case the requested segment is not yet available. In our use case the segment might not yet be available if it's too close to live/present. The segment might not be available due to latency (the time between the creation of the stream and the stream being uploaded and available for fetching by RxPlayer). We have not found a workaround for this issue. Is it possible to re-add the segment time to the ISegmentLoaderContext?

Current version: 3.33.3

[peaBerberian]

Hi,

We use segment.time to retry segment fetching in case the requested segment is not yet available

So here if I understand correctly the MPD is announcing segments before them being available, isn't that the source of the issue.
Or perhaps it's here a SegmentTemplate without SegmentTimeline and we're relying on a clock unsynchronized with the server?

We now avoid exposing too much information because that limited our ability to refactor things (for example exposing a segment object in the v3 forced us to keep some metadata in some ways) and also because semantics for that information could be different or even evolve with some types of stream (e.g. for time, with some low-latency streams with requestable sub-segments it could both mean start of the full segment or start of the sub-segment) in which case it becomes hard to guarantee that a documented API is "stable" for how an application understand it (in my example, some application may think time meant the former and other applications that it meant the latter).
So we limit what metadata we expose.

I'm not totally against something like segmentStart/segmentEnd here (which could be optional for potential future cases where the notion is different enough) but I'm not sure I understand the case encountered here. If the player request a segment that's not yet available, to me it's either the player that is wrong or the packager.

[AndreasVidovic]

Hi,

We use segment.time to retry segment fetching in case the requested segment is not yet available

So here if I understand correctly the MPD is announcing segments before them being available, isn't that the source of the issue. Or perhaps it's here a SegmentTemplate without SegmentTimeline and we're relying on a clock unsynchronized with the server?

We now avoid exposing too much information because that limited our ability to refactor things (for example exposing a segment object in the v3 forced us to keep some metadata in some ways) and also because semantics for that information could be different or even evolve with some types of stream (e.g. for time, with some low-latency streams with requestable sub-segments it could both mean start of the full segment or start of the sub-segment) in which case it becomes hard to guarantee that a documented API is "stable" for how an application understand it (in my example, some application may think time meant the former and other applications that it meant the latter). So we limit what metadata we expose.

I'm not totally against something like segmentStart/segmentEnd here (which could be optional for potential future cases where the notion is different enough) but I'm not sure I understand the case encountered here. If the player request a segment that's not yet available, to me it's either the player that is wrong or the packager.

Hi,

Thanks for the quick reply. Yes, SegmentTemplate. In our specific case the segments are produced by a wireless network camera and pushed to the cloud once the camera has connectivity. When fetching the segments from the cloud, the latency varies a bit and it typically takes around 4 seconds until the segments are available for download. Our problem is that the video buffer will contain missing segments (404) unless the segments close to live (within ~4 seconds of live) can be retried, since we know they might not yet exist in the cloud. We therefore compare segment start time with the current time. If the difference is less than 4 seconds we retry, otherwise we return an empty segment. To make the video more stable, we enforce a certain latency so that it doesn't try to play video that is too close to live (within 4 seconds of live).

Perhaps there's another workaround? Otherwise segmentStart/segmentEnd would be great.

The actual code:

  if (response.value.status === 404) {
      // As the player will never be allowed within some time from the live edge,
      // we know that there's a buffer of time where we don't need a specific segment
      // but it may be requested. If the request fails and we don't yet need the
      // segment, allow the player to retry.
      if (liveGap && liveGap <= this.enforcedLatency) {
        return {
          ok: false,
          error: {
            canRetry: true,
            message: ERROR_SEGMENT_NOT_AVAILABLE,
          },
        }
      }

      return {
        ok: true,
        value: {
          data: new ArrayBuffer(0),
          fetchDuration: 0,
          size: 0,
          metadata: {},
        },
      }
    }