W3C home > Mailing lists > Public > public-media-capture@w3.org > August 2014

MediaStreamTrack errors: Getting information up?

From: Harald Alvestrand <harald@alvestrand.no>
Date: Fri, 29 Aug 2014 13:45:42 +0200
Message-ID: <540067E6.8060902@alvestrand.no>
To: "public-media-capture@w3.org" <public-media-capture@w3.org>
One question I was asked the other day:

How do I get information about what happened to a MediaStreamTrack when 
it's ended?

What we currently have is an event handler of type "ended", which uses 
the Event interface, which, as defined in 
http://www.w3.org/TR/dom/#events has the interface:

[Constructor(DOMString type, optional EventInit eventInitDict),
  Exposed=Window,Worker]
interface Event {
   readonly attribute DOMString type;
   readonly attribute EventTarget? target;
   readonly attribute EventTarget? currentTarget;

   const unsigned short NONE = 0;
   const unsigned short CAPTURING_PHASE = 1;
   const unsigned short AT_TARGET = 2;
   const unsigned short BUBBLING_PHASE = 3;
   readonly attribute unsigned short eventPhase;

   void stopPropagation();
   void stopImmediatePropagation();

   readonly attribute boolean bubbles;
   readonly attribute boolean cancelable;
   void preventDefault();
   readonly attribute boolean defaultPrevented;

   [Unforgeable] readonly attribute boolean isTrusted;
   readonly attribute DOMTimeStamp timeStamp;

   void initEvent(DOMString type, boolean bubbles, boolean cancelable);
};

dictionary EventInit {
   boolean bubbles = false;
   boolean cancelable = false;
};

The "type" field is set to "ended" if I understand the spec correctly.

We COULD get information back in a way that's consistent with other 
interfaces if we did two changes:

- Declare the type of interface for "ended" to be MediaStreamErrorEvent
- Declare the "error" attribute of the MediaStreamErrorEvent to be 
nullable (for the case where there is no error)

We could also make a new event type with a different interface than 
MediaStreamErrorEvent, or do something entirely different - but not 
offering any way to differentiate between "the track ended because the 
user called stop() on it" and "the track ended because the driver 
crashed and there's memory corruption in the buffers" seems like a 
non-optimal situation.

What do people think?

          Harald
Received on Friday, 29 August 2014 11:46:16 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:26:29 UTC