Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A8C921F8B8A for ; Sat, 22 Oct 2011 01:34:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.53 X-Spam-Level: X-Spam-Status: No, score=-110.53 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KBwvyWKaVZ9T for ; Sat, 22 Oct 2011 01:34:01 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 65FBF21F8B85 for ; Sat, 22 Oct 2011 01:33:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C43F039E162; Sat, 22 Oct 2011 10:33:52 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mLA7pOq-BQKb; Sat, 22 Oct 2011 10:33:50 +0200 (CEST) Received: from [192.168.1.58] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 38BCF39E038; Sat, 22 Oct 2011 10:33:50 +0200 (CEST) Message-ID: <4EA27FEE.4060804@alvestrand.no> Date: Sat, 22 Oct 2011 10:33:50 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: robert@ocallahan.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------040905060605030204070800" Cc: "rtcweb@ietf.org" , "public-webrtc@w3.org" Subject: Re: [rtcweb] a couple of comments on the latest API draft X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "public-webrtc@w3.org" List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Oct 2011 08:34:03 -0000 This is a multi-part message in MIME format. --------------040905060605030204070800 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit This is (for once) purely a W3C WG matter, reply-to: header set appropriately. On 10/21/2011 10:53 PM, Robert O'Callahan wrote: > http://dev.w3.org/2011/webrtc/editor/webrtc-20111017.html > > I'm not sure that "blackness" is the appropriate output for a finished > MediaStream. HTML media elements that aren't playing anything are > transparent. For consistency, it's probably better for MediaStreams > that aren't playing anything to also be transparent. Seems to me that an ended MediaStream should not contribute anything to its playout element, so the playout element should be the one deciding what to do. Good point. > > When a |MediaStream > | > object ends for any reason (e.g. because the user rescinds the > permission for the page to use the local camera, or because the > data comes from a finite file and the file's end has been reached > and the user has not requested that it be looped, or because the > stream comes from a remote peer and the remote peer has > permanently stopped sending data, it is said to be finished . > > > What if the user reinstates permission for the page to use a camera, > or the author modifies the source to add looping or otherwise > replenish the data (e.g. by restarting the source via some API)? In > general, especially as we add more sources, it's going to be hard to > ensure that the ended/finished state (I think probably you should > remove all mentions of "finished" in favour of "ended") is truly > permanent. Certainly if we allow arbitrary media elements to be used > as sources (as I think we will want to), the author can cause the > media element to play again after it's finished. The way it's currently written, "finished" is permanent, but "disabled" is changeable. We don't have any API to re-request permission for camera, GetUserMedia generates a new stream, it doesn't refresh an old one. We can always emulate "restart" by creating a new stream and attaching it to the same playout elements. It's a programming-style issue whether we do that, or just disable on "end". > > I'm not sure what to do about this, but if we could allow MediaStreams > to exit the "ended" state, that would be good. > > Rob > -- > "If we claim to be without sin, we deceive ourselves and the truth is > not in us. If we confess our sins, he is faithful and just and will > forgive us our sins and purify us from all unrighteousness. If we > claim we have not sinned, we make him out to be a liar and his word is > not in us." [1 John 1:8-10] > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --------------040905060605030204070800 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit This is (for once) purely a W3C WG matter, reply-to: header set appropriately.

On 10/21/2011 10:53 PM, Robert O'Callahan wrote:
http://dev.w3.org/2011/webrtc/editor/webrtc-20111017.html

I'm not sure that "blackness" is the appropriate output for a finished MediaStream. HTML media elements that aren't playing anything are transparent. For consistency, it's probably better for MediaStreams that aren't playing anything to also be transparent.
Seems to me that an ended MediaStream should not contribute anything to its playout element, so the playout element should be the one deciding what to do. Good point.

When a MediaStream object ends for any reason (e.g. because the user rescinds the permission for the page to use the local camera, or because the data comes from a finite file and the file's end has been reached and the user has not requested that it be looped, or because the stream comes from a remote peer and the remote peer has permanently stopped sending data, it is said to be finished .

What if the user reinstates permission for the page to use a camera, or the author modifies the source to add looping or otherwise replenish the data (e.g. by restarting the source via some API)? In general, especially as we add more sources, it's going to be hard to ensure that the ended/finished state (I think probably you should remove all mentions of "finished" in favour of "ended") is truly permanent. Certainly if we allow arbitrary media elements to be used as sources (as I think we will want to), the author can cause the media element to play again after it's finished.
The way it's currently written, "finished" is permanent, but "disabled" is changeable.
We don't have any API to re-request permission for camera, GetUserMedia generates a new stream, it doesn't refresh an old one.

We can always emulate "restart" by creating a new stream and attaching it to the same playout elements. It's a programming-style issue whether we do that, or just disable on "end".

I'm not sure what to do about this, but if we could allow MediaStreams to exit the "ended" state, that would be good.

Rob
--
"If we claim to be without sin, we deceive ourselves and the truth is not in us. If we confess our sins, he is faithful and just and will forgive us our sins and purify us from all unrighteousness. If we claim we have not sinned, we make him out to be a liar and his word is not in us." [1 John 1:8-10]

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

--------------040905060605030204070800--