New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mandatory "kind" in RTCRtpReceiver constructor #141

Closed
aboba opened this Issue Aug 4, 2014 · 5 comments

Comments

Projects
None yet
2 participants
@aboba
Copy link
Contributor

aboba commented Aug 4, 2014

Should the "kind" argument be mandatory (not optional) in RTCRtpReceiver?

@aboba

This comment has been minimized.

Copy link
Contributor

aboba commented Aug 5, 2014

If done, the interface would look like this:

[Constructor(DOMString kind, RTCDtlsTransport transport, optional RTCDtlsTransport rtcpTransport)]
partial interface RTCRtpReceiver : RTCStatsProvider {
readonly attribute MediaStreamTrack track;
};

Not that "readonly attribute MediaStreamTrack track" is also used in the WebRTC 1.0 RTCRtpReceiver definition.

@pthatcherg

This comment has been minimized.

Copy link

pthatcherg commented Aug 5, 2014

What would be the advantage of supplying it?

On Mon, Aug 4, 2014 at 9:12 PM, aboba notifications@github.com wrote:

If done, the interface would look like this:

[Constructor(DOMString kind, RTCDtlsTransport transport, optional
RTCDtlsTransport rtcpTransport)]
partial interface RTCRtpReceiver : RTCStatsProvider {
readonly attribute MediaStreamTrack track;
};

Not that "readonly attribute MediaStreamTrack track" is also used in the
WebRTC 1.0 RTCRtpReceiver definition.


Reply to this email directly or view it on GitHub
#141 (comment).

@aboba

This comment has been minimized.

Copy link
Contributor

aboba commented Aug 6, 2014

Here is a proposed resolution:

In Section 9.7.1, add the following text to the explanation of RTCRtpCodecParameters.name:
The name MUST always be provided.

In Section 7.3.2, add the following explanatory text to "receive":

After receive() returns, track is set, and the value of track.kind is determined based on the kind of the codecs provided in parameters.codecs. If all the codecs are of a single kind then track.kind is set to that kind; if the kind differs between codecs, then track.kind is set to "all".

@aboba

This comment has been minimized.

Copy link
Contributor

aboba commented Aug 6, 2014

Oops, should be "", not "all".

@pthatcherg

This comment has been minimized.

Copy link

pthatcherg commented Aug 6, 2014

Sounds good to me.

On Wed, Aug 6, 2014 at 10:38 AM, aboba notifications@github.com wrote:

Oops, should be "", not "all".


Reply to this email directly or view it on GitHub
#141 (comment).

@aboba aboba closed this Aug 6, 2014

robin-raymond pushed a commit to robin-raymond/ortc that referenced this issue Aug 19, 2014

Robin Raymond
Clarification of the ICE restart issue, as noted in:
w3c#93

Clarified onerror usage in sender and receiver objects, as noted in:
w3c#95

Clarified SST-MS capability issue noted in:
w3c#108

Clarification of send() and receive() usage as noted in:
w3c#119

Changed ICE state diagram as noted in:
w3c#122

Removed getParameters methods and changed send() method as noted in:
w3c#136

Changed definition of framerateScale and resolutionScale as noted in:
w3c#137

Substituted "muxId" for the "receiverId" as noted in:
w3c#138
w3c#140

Clarified the setting of track.kind as described in:
w3c#141

Added SSRC conflict event to the RTCRtpSender, as described in:
w3c#143

Addressed the "end of candidates" issues noted in:
w3c#142
w3c#144
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment