RE: First draft of "MediaStream Capture Scenarios" now available

>>> - header: This should be listed as a WEBRTC/DAP task force item, not a
>>> DAP item.
>> I'm happy to change this, but don't know how. SOTD section is auto-
>generated
>> from ReSpec. Any ReSpec experts out there that can provide pointers?
>Dom?

I can just put the right text in instead of using the auto-generated 
boilerplate for the moment. This isn't really a blocker.


>>> - 3.2 reinitialization: We (WebRTC editors) have discussed moving the
>>> "ended" event from the MediaStream to the MediaStreamTrack; it seems to
>>> be easier to define it crisply there.
>> That sounds like a good start. The subject of the MediaStreamTrack is
>> actually where I believe some of the capture integration points should be
>> made, but it will require some additional discreet factoring (i.e.,
>> MediaStreamTrack ->  Audio/VideoTrack [3]).
>we'll see about that. Last time I looked at that spec, it had arrays
>instead of track lists; we're worried that these are not exactly the
>tracks we're looking for.

Actually, the latest draft includes non-array TrackLists (separate ones 
for audio/video; primarily because audio tracks can be mixed, but video
tracks can only be selected). The Audio/VideoTrackList objects also have 
some nifty notifications for when tracks are added/changed, along with 
state info on which track is selected (exclusively for video tracks), and 
a "getTrackById" lookup method.

I think many of these features lend themselves equally well to the media stream tracks
concepts, and solve a few usage scenarios at the same time. If you haven't 
perused that spec in a while, I'd suggest taking another look. Some of this 
newer functionality is why I see the potential for alignment.


>Last I looked at that discussion, they were talking about adding a
>TextTrackList too; I think it makes sense for our purposes to model some
>common behaviours of tracks as a superclass.

Yes, TextTracks and TextTrackLists are now in the spec [5] (and implemented in 
IE10) [6]. I don't see a strong relation between capture scenarios and text
tracks, and I'm inclined not to support them, but I can imagine some large-event
scenarios where live captioning is provided via a media stream. Seems a rare 
use case though.

While there are a few things that can be applied generally to a track superclass,
I think that as we define the requirements for capture scenarios, we'll see that
use cases for audio are generally quite different from use cases for video, and
there will be a desire to factor audio/video out so that capabilities for each are
not exposed on a common interface. There's possibly room for both, but I'll note
that the current requirement to sort audio tracks before video tracks in WebRTC 
(which seems a little arbitrary to me) could be dropped by factoring into audio 
and video track lists.

[[The relative order of all tracks in a user agent must be stable. All audio tracks 
 must precede all video tracks.]]

[5] http://dev.w3.org/html5/spec/Overview.html#texttracklist
[6] http://ie.microsoft.com/testdrive/Graphics/VideoCaptions/

Received on Tuesday, 6 December 2011 23:06:36 UTC