HTML Media Capture Last Call Comments: question on approach

I'm trying to understand how HTML Media Capture [1] can meet requirements raised in Last Call [2] comments being based on HTML5 file upload, whereas  "Media Capture and Streams" (getusermedia) meets those requirements based on its media focused design.

Specifically,  in  "Media Capture and Streams" (getusermedia) [3] there is the concept of a track that has kind and type - this makes it possible to have a video track sync'd with a separate audio track (correct?) and for a track like video (kind = video) have a type like front-camera (vs back), enabling device instance specificity.

This enables meeting two requirements expressed in the HTML Media Capture last call comments:

Requirement 1 - be able to associate any  microphone including the default with a video capture (e.g. use built in mic or use another mic). This allows for better audio recording in a video by using a well placed higher quality microphone, for example.

Requirement 2 - be able to express front versus rear facing camera. This enables a match between expected functionality (e.g. take a picture vs video conference) and the API.

What I do not understand is how we can expect to  meet these requirements based on a file upload concept that assumes a single file object. We could use MIME  type/subtype to enable the kind/type approach  (video/front, video/back) but that might require coordination in type definitions. More importantly is the issue of correlated audio/video.

Is the right answer to set developer expectations that  the  HTML Media Capture API is to be more limited, and reference "Media Capture and Streams" ( getusermedia ) as an alternative for more complicated use cases?

In that case we may wish to revise the HTML Media Capture Abstract and introduction to  indicate that the API is limited to simple and narrow use cases like uploading a capture from a single device with integrated audio/video in the case of video and that control over device choice is limited, with a reference to "Media Capture and Streams"  for more complicated use cases.

Alternatively, I guess we could ask if we are  correct in basing HTML Media Capture on the file upload concept.

Thoughts?

regards, Frederick

Frederick Hirsch
Nokia

[1] http://dev.w3.org/2009/dap/camera/

[2] https://www.w3.org/2006/02/lc-comments-tracker/43696/WD-html-media-capture-20120712/doc/

[3] http://dev.w3.org/2011/webrtc/editor/getusermedia.html

Received on Monday, 29 October 2012 23:47:50 UTC