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

[Bug 22229] New: Editorial input

From: <bugzilla@jessica.w3.org>
Date: Fri, 31 May 2013 11:45:47 +0000
To: public-media-capture@w3.org
Message-ID: <bug-22229-5753@http.www.w3.org/Bugs/Public/>

            Bug ID: 22229
           Summary: Editorial input
    Classification: Unclassified
           Product: WebRTC Working Group
           Version: unspecified
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Media Capture and Streams
          Assignee: public-media-capture@w3.org
          Reporter: stefan.lk.hakansson@ericsson.com
                CC: public-media-capture@w3.org

Some minor stuff (I think it is mostly editorial):

Section 3, sub section "constraints", towards the end, it is said "but ignored
by the application"; should it not be "but ignored by the UA"?

Section 4.1, the last four blocks of text before the figure: There is a lot of
into about MediaStreamTrack's here; I think it should be moved to section 4.3.

Section 4.2: It is said that "The list of MediaStream consumers currently
includes the media elements and the PeerConnection API specified in
[WEBRTC10].". I think we should mention MediaStream Recorder and MediaStream
Image Capture as well.

Section 4.2, right before the IDL: There is some reference and talking about
stop() method for MediaStream, but we don't have that any more.

Section 4.3, it is said taht "Note that a web application can revoke all given
permissions with MediaStreamTrack.stop().". I think it should be clarified that
doing .stop() on _any_ of the MediaStreamTracks served by the source would
revoke the permissions.

Section 4.3.1: There is a missing ")" in the text about what happens when a
track ends. And I don't understand the part of the reference count.

Example 2: "stream.stop();" - no stop method on MediaStream any more.

You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
Received on Friday, 31 May 2013 11:45:49 UTC

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