Re: Need API to read the CSRC on received tracks (#4)

I tend to agree that this not a "must have" (although there are implementations in progress).

The primary benefit is to allow the UI in a conference to indicate which participants are generating audio energy. So if you hear a dog barking it can help narrow down which participant to mute. For conferences that do not mute by default that can be valuable.

I do not believe it is useful in detecting the dominant generator of human speech (needed for switching of media streams on the SFU). That can best be accomplished on the SFU without the need for API support. See the following paper for details:
https://jitsi.org/publications/nossdav2015lastn.pdf



On Aug 1, 2015, at 2:29 AM, Harald Alvestrand <harald@alvestrand.no<mailto:harald@alvestrand.no>> wrote:

Thanks for bringing this to the list!

Speaking as contributor only:

CSRC is only useful for a single case: That of a media mixer at the conference server, where the set of contributors changes over time.
(The audio volume extension, bug #6, is not the same thing.)

I don't regard this as an important use case, and think we can safely put this off to the next revision of the specification, where the RTCRtpReceiver does seem like the logical place to put it.

Note about the solution proposed:

If changes in CSRC are what interest people, rather than the absolute values at a given time, there needs to be events firing for the CSRC changes, and the timing relationships between data returned from "getContributingSources" and the fired events need to be defined.


On 07/31/2015 07:26 PM, Bernard Aboba wrote:
It could extend RTCRtpReceiver, like this:

Contributing Sources

The getContributingSources method extends the RTCRtpReceiver object, providing information on the sources contributing to an incoming media stream.

partial interface RTCRtpReceiver {
    sequence<RTCRtpContributingSource> getContributingSources ();
};

Methods

getContributingSources
Retrieve the sequence of contributing sources.

No parameters.
Return type: sequence<RTCRtpContributingSource>

dictionary RTCRtpContributingSource

dictionary RTCRtpContributingSource {
             DOMHiResTimeStamp timestamp;
             unsigned long     csrc;
             byte              audioLevel;
};

Dictionary RTCRtpContributingSource Members

audioLevel of type byte,
The audio level of the contributing source. Value is between 0 and -127 representing the contributing source dBov value, as described in [RFC6465]

csrc of type unsigned long,
The contributing source.

timestamp of type DOMHiResTimeStamp,




On Jul 31, 2015, at 08:31, Cullen Jennings <notifications@github.com<mailto:notifications@github.com>> wrote:


@alvestrand<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.com%2falvestrand&data=01%7c01%7cBernard.Aboba%40microsoft.com%7c6a0f913c35a1492c79c008d29a53a81d%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=mTd1sqyX9jk9uZb4jqBfurUqaBZPjjYc8NOqO9h%2bWms%3d> - would stats be a reasonable place to put this or should it be RTCRtpReceiver ?

-
Reply to this email directly or view it on GitHub<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.com%2fw3c%2fwebrtc-pc%2fissues%2f4%23issuecomment-126725763&data=01%7c01%7cBernard.Aboba%40microsoft.com%7c6a0f913c35a1492c79c008d29a53a81d%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=Bu%2fInk86UC%2bZHsg1eY8ZP5PwPKBExcK10rEKDtXFPpY%3d>.



--
Surveillance is pervasive. Go Dark.