W3C home > Mailing lists > Public > public-webrtc@w3.org > February 2013

draft-ietf-rtcweb-rtp-usage: CSRC in the API?

From: Magnus Westerlund <magnus.westerlund@ericsson.com>
Date: Fri, 22 Feb 2013 10:19:17 +0100
Message-ID: <51273815.20000@ericsson.com>
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

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:32 UTC