W3C home > Mailing lists > Public > public-media-capture@w3.org > April 2014

Re: [Bug 25361] Media Capture and Streams spec should explicitly specify that recvonly streams / tracks should be considered as muted.

From: Harald Alvestrand <harald@alvestrand.no>
Date: Thu, 24 Apr 2014 10:01:36 +0200
Message-ID: <5358C4E0.2090705@alvestrand.no>
To: public-media-capture@w3.org
On 04/24/2014 08:16 AM, bugzilla@jessica.w3.org wrote:
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25361
> --- Comment #3 from Kiran <kiran.guduru@samsung.com> ---
> I agree with Adam to give the example of a future "MediaStream source".
> Re-reading the spec, it seems "disabled" should be replaced with "recvonly",
> instead of extending, as explained below.
> A disabled track outputs blackness / silence.
> Since in this case, remote track is disabled, it will any how send blackness /
> silence to remote end (to its consumer). So receiving end will receive
> blackness / silence from its (remote) source.
> But from [1], A MediaStreamTrack is muted when the source is temporarily unable
> to provide the track with data.
> If the track is "recvonly", then remote peer will not send any data (even
> blackness / silence), will be more apt for that example?

Note: This is "Media capture and streams", not "WebRTC".
We are discussing the definition of tracks and streams in the absence of 
a PeerConnection.

A track is unidirectional. Calling it "recvonly" is completely 
confusing; the correct terminology would be "if the track is sourced 
from an m-line that has been marked as "recvonly" in the corresponding 
SDP description that is currently visible as pc.remoteDescription".

I agree that the WebRTC specification should say what happens in this 
case; either having the track produce blackness/silence or setting the 
"muted" property to true, or both.

But the word "recvonly" should not occur in the Media Capture and 
Streams specification.

> [1] http://www.w3.org/TR/mediacapture-streams/#life-cycle-and-media-flow
Received on Thursday, 24 April 2014 08:02:07 UTC

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