search

cta-standards / R4WG20-QoE-Metrics

Issue tracking repository for the R4-Wg20 QoE Initiative
9 stars 2 forks source link

Recoverable error reporting #26

Closed heff closed 5 years ago

heff commented 5 years ago

Submitted by @ScottKell Original issue: https://github.com/cta-wave/R4WG20-QoE-Metrics/issues/7

In most players, there are fatal errors (playback does not continue without user interaction such as page reload) and recoverable errors (player re-connects or tears down MSE pipeline and restarts playback).

  1. As written, it looks like recoverable errors are not counted. 'playbackFailed' is only true for fatal errors. Seems this is one of those data points that are beyond the scope of the spec but that clients may collect

  2. Its not clear to me what playback state/events are in play during a recoverable error. An Architectural Workflow Model of this case would be useful.

@heff Yeah, unless the user experiences a non-fatal error some how, it probably won’t make it into this spec. At least not for a while. We’re very much focused on the user perspective. On #2 are you asking for possible states of fatal (not recoverable) errors?

@ScottKell I get that non-fatal errors don't make it into spec. I agree that it seems non-essential

Regarding #2.

I'm unclear on what happens between a non-fatal error and playback resuming. I'm hoping this can be clarified in the workflows. I'll take a stab at a strawman.

Let's say a client gets a media decode error and has logic to tear down media pipeline, build it back up and resume playback on an alternate asset. Its a non-fatal error but still seems to need state changes and events to represent the behavior

Something like this:

Media Decode Error occurs. Damn! But we have some recovery logic... State: The state is no longer playing. Perhaps "stalling"? Event: Some event should happen here since we are not actively playing. We need to account for this downtime. Perhaps "playbackStall"?

The system attempts to recover and plays an alternate asset. This takes some time and quality is definitely affected. State: Starting Up Event: playbackRequest Issue: I don't think "playbackRequest: makes sense coming out of "playbackStall"

Once play has started... State: Playing Event: playbackStarted

mlevine84 commented 5 years ago

WG believes non-fatal errors are recoverable and if the player resumes playback, such a user experience is captured via the metrics defined in the spec and hence WG does not see a need to capture the non-fatal scenarios in the spec.