Proposal and discussion for RtpSender.getCapabilities

At TPAC (2014), we reached consensus that we want some form or
RtpSender.getCapabilities.  But we wanted to make sure we have the right
"minimal starting set".    Additionally, there was an idea of having audio-
and video-specific types for audio and video codecs.

I propose this as a starting point for the discussion:

partial interface RTCRtpSender {
    static RTCRtpCapabilities getCapabilities (optional DOMString kind);
};

partial interface RTCRtpReceiver {
    static RTCRtpCapabilities getCapabilities (optional DOMString kind);
};

dictionary RTCRtpCapabilities {
    sequence<RTCRtpCodecCapability> codecs;
    sequence<RTCRtpHdrExtCapability> headerExtensions;
};

dictionary RTCRtpCodecCapability {
    DOMString kind;
    DOMString name;
};

dictionary RTCRtpHdrExtCapability {
    DOMString kind;
    DOMString uri;
};

// Even though it's empty now, it provides a clear place to put
// future audio-specific codec capabilities.
dictionary RTCAudioCodecCapability : RTCRtpCodecCapability {
}

// Even though it's empty now, it provides a clear place to put
// future video-specific codec capabilities.
dictionary RTCVideoCodecCapability : RTCRtpCodecCapability {
}

I think this is a set that everyone can agree we need to have.  From here,
we can choose whether or no to add things like channel count,  "clockrate",
 and RTCP feedback params.    For example, I think this more full version
of codec capabilties would work well:

dictionary RTCRtpCodecCapability {
    // That value in the SDP :)
    unsigned long clockRate;
    unsigned long numChannels;
}

But please propose your own additions to this minimal foundation.

Received on Monday, 3 November 2014 21:00:15 UTC