W3C home > Mailing lists > Public > public-media-capture@w3.org > March 2013

Re: new draft of recording

From: Robert O'Callahan <robert@ocallahan.org>
Date: Fri, 29 Mar 2013 18:40:48 +1300
Message-ID: <CAOp6jLYYvFrgdG0_Q6NUP4eBp15GH2AYjc_XqNEA8Q1pAizM2g@mail.gmail.com>
To: Jim Barnett <Jim.Barnett@genesyslab.com>
Cc: "public-media-capture@w3.org" <public-media-capture@w3.org>
I assume your attachment matches what's checked into
https://dvcs.w3.org/hg/dap/raw-file/default/media-stream-capture/MediaRecorder.html
.

> void              start (optional long? timeslice);

I don't think you want the ? there.

The text for imageHeight/imageWidth/mimeType says "the initial value will
be a platform-supplied default". It seems better for the initial value to
be defined, e.g. 0 and the empty string. When and how often do they change
to a different value? The spec needs to say.

The utility of stop/start/pause/resume events seems questionable. These
happen in response to method calls on the MediaRecorder, so authors already
know when these things are happening. Are there use-cases where these
events are useful?

Separate error and warning events seems unnecessary. Other Web APIs don't
use warning events. Web developers generally receive warnings via some
UA-specific developer tool interface. If an actual Web app can't use the
information, the API shouldn't be there. And generally, if you're not sure
an API is needed, it shouldn't be there.

The members of RecordingSettings should not be nullable. As dictionary
members, they're all always optional.

AvailableSettings members should probably always be present, therefore
AvailableSettings should not be a dictionary. In fact it's unclear why
bundling these members together into an object is helpful. Why not provide
a separate attribute on MediaRecorder for each "available setting" that
needs to be exposed?

For MIME types, instead of a list why not follow HTMLMediaElement and offer
a canRecordType method? Seems easier to use than asking apps to scan a
list. Also, it's more flexible since MIME types can contain information
like codecs and other recording parameters, and you wouldn't want to make a
list enumerating every supported recording configuration.

Is it really necessary to export the minimum and maximum width and height?
I think it would be simpler and just as workable to let the author request
a width and height and let the user-agent automatically clamp them to fit
implementation limits (preserving aspect ratio I suppose).

Rob
-- 
q“qIqfq qyqoquq qlqoqvqeq qtqhqoqsqeq qwqhqoq qlqoqvqeq qyqoquq,q qwqhqaqtq
qcqrqeqdqiqtq qiqsq qtqhqaqtq qtqoq qyqoquq?q qEqvqeqnq qsqiqnqnqeqrqsq
qlqoqvqeq qtqhqoqsqeq qwqhqoq qlqoqvqeq qtqhqeqmq.q qAqnqdq qiqfq qyqoquq
qdqoq qgqoqoqdq qtqoq qtqhqoqsqeq qwqhqoq qaqrqeq qgqoqoqdq qtqoq qyqoquq,q
qwqhqaqtq qcqrqeqdqiqtq qiqsq qtqhqaqtq qtqoq qyqoquq?q qEqvqeqnq
qsqiqnqnqeqrqsq qdqoq qtqhqaqtq.q"
Received on Friday, 29 March 2013 05:41:15 UTC

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