Subject: [rtcweb] a couple of comments on the latest API draft

From: "Robert O'Callahan" <[email-masked]>
Date: Sat, 22 Oct 2011 09:53:32 +1300

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.

When a MediaStream<http://dev.w3.org/2011/webrtc/editor/webrtc-20111017.html#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.

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]

---

From: Stefan Håkansson <[email-masked]>
Date: Sat, 22 Oct 2011 08:52:15 +0200

Rob,

thanks for providing this input. However, the right place to discuss 
this kind of things is the [email-masked] list (cc'd), not the 
IETF rtcweb list.

Thanks,
Stefan (one of the webrtc chairs)

On 10/21/2011 10:53 PM, Robert O'Callahan wrote:
>     When a |MediaStream
>     <http://dev.w3.org/2011/webrtc/editor/webrtc-20111017.html#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.
>
> 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]

---

From: Harald Alvestrand <[email-masked]>
Date: Sat, 22 Oct 2011 10:33:50 +0200

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:
> 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.
>     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".
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: "Robert O'Callahan" <[email-masked]>
Date: Tue, 25 Oct 2011 13:04:11 +1300

On Sat, Oct 22, 2011 at 9:33 PM, Harald Alvestrand <[email-masked]>wrote:

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

Yeah. Actually video elements normally keep showing the last frame when they
end, so we'll want a way to support that too.

The way it's currently written, "finished" is permanent, but "disabled" is
> changeable.

"finished" == "ended", right? :-)

OK, I will try to write the ProcessedMediaStream spec so that "ended" is a
permanent state. This means that when you get a MediaStream for an HTML
media element, the MediaStream will have to be tied to the currently playing
media resource, and when playback ends that MediaStream will become inactive
and a new MediaStream generated if the author seeks the media resource and
starts playing it again, or loads a new media resource.

Rob

---

From: "Robert O'Callahan" <[email-masked]>
Date: Tue, 25 Oct 2011 14:29:07 +1300

> "finished" == "ended", right? :-)

Actually, since it's already well-established that "ended" on media elements
is not permanent --- you can seek or reload the resource --- I think it
would reduce confusion to use the term "finished" for the permanent
MediaStream state, instead of "ended". Including in the API names. Can we do
that?

> starts playing it again, or loads a new media resource.

At this stage it looks like we'll just make the stream emitted by a media
element never end ... and maybe we'll add an finish() API to force a
MediaStream to end permanently.

Rob