- From: Magnus Westerlund <magnus.westerlund@ericsson.com>
- Date: Fri, 22 Feb 2013 10:19:17 +0100
- To: "public-webrtc@w3.org" <public-webrtc@w3.org>
- CC: "rtcweb@ietf.org" <rtcweb@ietf.org>
WebRTC WG, As editor of the RTP usage specification in RTCWEB WG, we have had a noted issue in our draft specification (https://datatracker.ietf.org/doc/draft-ietf-rtcweb-rtp-usage/). In Section 12.5. of version 05 (Contributing Sources) we had the following: (tbd: does the API need to provide the ability to add a CSRC list to an outgoing packet? this is only useful if the sender is mixing content) This is clearly an API question. We intended to remove it. However, I like to hand it over to you in W3C to consider on the impact on the API this has. >From my personal view point this has two aspects: Exposing when a received MediaStreamTrack is actually the mix (or switch) of other MediaStreamTracks, a mix performed by a WebRTC endpoint or RTP middlebox (Mixer). Applications that like to know who are currently seen or audible needs this information mapping. We also have specified an optional to support RTP header extension (RFC6465) that provide energy levels for each contributing source. If that is used, that information would be something an application would like to render somehow. The other aspect is when an WebRTC endpoint mixes media to produce a new MediaStreamTrack, for example with the Web Audio API, then one need to consider if and how the CSRC list is populated. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ----------------------------------------------------------------------
Received on Friday, 22 February 2013 09:19:43 UTC