- From: Harald Alvestrand <harald@alvestrand.no>
- Date: Wed, 16 Jan 2013 12:39:01 +0100
- To: public-media-capture@w3.org
- Message-ID: <50F69155.1010002@alvestrand.no>
On 01/15/2013 09:25 PM, Jim Barnett wrote: > > We haven’t discussed whether user consent is required for recording. > In general, I would think that users would want to know when they are > being recorded and would want to be able to block recording. (Of > course, the user can’t be guaranteed that the other end isn’t > recording the call, but that’s the case on phone calls today.) > > So: > > 1. Should user consent be required for recording? > > 2.If so, when should it be given? As part of the initial call to gUM? > When recording actually starts? (via another call to gUM or in the > Recorder constructor?). > I think this ties in with the thinking we had earlier about the tying of identity with getUserMedia - if we want the ability for getUserMedia (or other means of producing a MediaStream) to produce a stream that is only authorized for certain destinations, then we should think about whether "local recording" is one of the possible destinations to authorize for. I don't see at the moment how to apply this logic to a remote media stream - when it is sent from the other side, it's authorized to an identity - but we haven't made any way to encode restrictions on what the recipient can do with the media stream once he has it. My default position would be "no, user consent is not required". > Also, we have identified 3 settable parameters for recording so far: > the Mime type, video height, and video width. None of these function > as constraints that can be used to select the appropriate ‘device’, > so does it make sense to use the constraint structure to specify them? > Wouldn’t it be simpler to let them be settable attributes of the > Recorder class? (We would still need a getCapabilities call to > determine what the legal values are, and we wouldn’t allow the values > to be changed while recording was going on.) > I would prefer to keep a constraints structure - we can easily need to do things like bitrate limitations, quality controls and so on; just dump the command line for any popular video encoder tool to get plenty of ideas. Height and width may also be useful to specify as constraints, in the case where the recording codec functions better with slight tunings of the parameters. I don't see any huge disadvantages in doing so.
Received on Wednesday, 16 January 2013 11:39:34 UTC