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

On 2014-04-24 10:36, Kiran Kumar Guduru wrote:
> Dear Harald,
>
> Please see my comments inline.
>
> ------- *Original Message* -------
>
> *Sender* : Harald Alvestrand<harald@alvestrand.no>
>
> *Date* : Apr 24, 2014 17:01 (GMT+09:00)
>
> *Title* : 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 ---
>  > 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.
>
> [KIRAN] True
>
>
> But the word "recvonly" should not occur in the Media Capture and
> Streams specification.
>
> [KIRAN] Agreed. Instead of using recvonly, can we change the text to
> resumble the similar meaning as shwon below?
>
> "a track that is a member of a||MediaStream|
> <http://www.w3.org/TR/mediacapture-streams/#idl-def-MediaStream>|,
> received via a|RTCPeerConnection|[WEBRTC10
> <http://www.w3.org/TR/mediacapture-streams/#bib-WEBRTC10>], is muted if
> the application on the other side disables the corresponding track in
> the|MediaStream|being sent"
>
> to
>
> "a track that is a member of a||MediaStream|
> <http://www.w3.org/TR/mediacapture-streams/#idl-def-MediaStream>|,
> received via a|RTCPeerConnection|[WEBRTC10
> <http://www.w3.org/TR/mediacapture-streams/#bib-WEBRTC10>], is muted if
> the application on the other side temporarily stops sending data on the
> corresponding track in the|MediaStream|being sent"

Hi Kiran.

All of this needs to be detailed out, but I think it should be detailed 
out in the WebRTC spec. Having this text in the Media Cap and Streams 
document can be quite confusing since it is not clear what is meant by 
"temporarily stops". Is it "enable=false" on the track on the sending 
side, is it something related to fiddling with the SDP directional 
attribute, is it "pause" on a doohickey, or something else?

Stefan

>
>  >
>  > [1] http://www.w3.org/TR/mediacapture-streams/#life-cycle-and-media-flow
>  >
>
>

Received on Thursday, 24 April 2014 10:04:30 UTC