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

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