Skip to content
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

Segment time not available when loading segment #1563

Open
AndreasVidovic opened this issue Oct 3, 2024 · 2 comments
Open

Segment time not available when loading segment #1563

AndreasVidovic opened this issue Oct 3, 2024 · 2 comments

Comments

@AndreasVidovic
Copy link

AndreasVidovic commented Oct 3, 2024

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

@AndreasVidovic AndreasVidovic changed the title Re-add segment time to ISegmentLoaderContext Segment time not available in segmentLoader Oct 3, 2024
@AndreasVidovic AndreasVidovic changed the title Segment time not available in segmentLoader Segment time not available when loading segment Oct 3, 2024
@peaBerberian
Copy link
Collaborator

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
Copy link
Author

AndreasVidovic commented Oct 14, 2024

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: {},
        },
      }
    }

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants