Re: Mediacapture-fromelement: Does capturing a stream from a canvas make sense?

On 11/18/2015 08:41 PM, Martin Thomson wrote:
> On 18 November 2015 at 08:10, Harald Alvestrand <harald@alvestrand.no> wrote:
>> Martin, do you remember why it was supposed to be a Good Thing to
>> capture a stream rather than a track?
> Well, I think that the best reason is that this becomes isomorphic
> with HTMLMediaElement.captureStream() such that either canvas or video
> can be used more or less interchangeably as the source of media.
>
For the list:

Martin and I continued some discussion in the bug
(https://github.com/w3c/mediacapture-fromelement/issues/16).

In addition to the capturing of a stream rather than a track, I objected
to the subclassing of MediaStream for a function that is only well
defined for a single track (requestFrame). Martin agreed that there were
arguments for making that interface be a track property rather than a
stream property. (He also claimed that there were arguments for the
opposite, but I haven't grasped those arguments yet).

In the interest of bringing debate back to the list - do we have more
opinions on these placements?

On rethinking the issue, I think returning a wrapper (the stream) with
one element isn't so very objectionable to me, but defining extensions
to the wrapper for functions that only affect the track is something I
definitely don't like, and I would like to have it changes.

What do others think?

Harald

Received on Friday, 20 November 2015 12:51:11 UTC