RE: Review of scenarios doc (Jan 19 version)

I've updated the MediaStream capture scenarios doc as noted below.

>-----Original Message-----
>From: Harald Alvestrand [mailto:harald@alvestrand.no]
>
>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.

I'm interested to see where the device caps discussion goes. It sounds promising. I left this section mostly untouched except for updates mentioned in my previous mail.


>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?

Agreed. The paragraph is now gone. I was thinking about Netflix when I wrote it.
They stream down all their content saving none of it on the client. The manage
all the DVR stuff via the server. Netflix would never implement a client-side DVR
because of their content protection policies.


>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.)

I'm not sure on this point. Might be worth some follow-up mail.


>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 Wednesday, 8 February 2012 21:05:43 UTC