Re: Review of scenarios doc (Jan 19 version)

I thought there was something missing.... I had lost the last pages of 
my written-up copy.
Here are more comments....

Section 5.8: "A media capture API should support a mechanism to 
configure a particular device dynamically..."

At the moment, we don't have an explicit object representation of the 
devices themselves. We may get around this by configuring (or modifying 
hints on) the MediaStreamTrack, and then have the underlying engine 
infer the best configuration for the device by looking at all the 
MediaStreamTracks being sourced from it. This is one way to achieve the 
virtualization desired in the next section.

Section 5.10 Capturing a media stream
Noting that "save as" dialogs are quite common in browser UIs driven by 
declarative-mode HTML.
These "save as" are very much browser chrome, since any unlimited 
ability to store data on the user's machine is an attack vector.

5.10.1 DVR Scenarios
Last section: "most streaming scenarios (where DVR is supported) .... 
exclusively on the server"
The point of a DVR device is usually to store the content on some device 
closer to the user than the server is. This seems strange. Perhaps 
delete the paragraph and see what people come up with?

5.11.1 Format detection
Consistency with HTML5, and "canPlayType", is a Good Thing if what we're 
being consistent with is satisfactory. Is it considered satisfactory on 
the HTML side of the house?
(Note that "canPlay" should really take a content-type: specification 
including parameters, not just the bare media type. I'm not sure that's 
true now.)

5.14.1 Picture tracks / issues
I think the concept of 2 media streams (one video and one photo) from a 
device is a quite reasonable approach.

And THAT ends my review comments.

               Harald

Received on Monday, 23 January 2012 10:12:09 UTC