-
Notifications
You must be signed in to change notification settings - Fork 115
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
Change addStream to addTrack; add RTCRtpSender/RTCRtpReceiver #3
Conversation
Good to have this! Needs a better cover note - the core part in this is the change from I miss a paragraph on how the track's membership in streams is Something like this: When a PeerConnection object detects that a track has been added by
(member variable listing) Section 5 of draft-ietf-mmusic-msid-07 needs to be consistent with this On 10/15/2014 08:23 AM, Justin Uberti wrote:
|
@@ -518,7 +509,7 @@ | |||
"component".</p> | |||
|
|||
<p>When a user agent has reached the point where a | |||
<code><a>MediaStream</a></code> can be created to represent incoming | |||
<code><a>MediaStreamTrack</a></code> can be created to represent incoming | |||
components, the user agent MUST run the following steps:</p> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does "components" (plural) still make sense?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed.
I left a few comments, some grammar. One was about what effect the "... On Tue, Oct 14, 2014 at 11:23 PM, Justin Uberti [email protected]
|
Overall, it looks very good, by the way. On Wed, Oct 15, 2014 at 9:08 AM, Peter Thatcher [email protected]
|
Following up on Harald's part about steps when a PeerConnection object detects that a new track has been added by the remote peer: did we not conclude that the PC would not do this, but since the stream association is part of the addtrack event the application can add the track to the stream (and create the stream if it does not exist yet)? And as a follow up: did we not say that the stream attribute on the addtrack event should be a list (for the case where a track i member of several MS's on the sending side at the time of doing pc.addTrack(track))? (I may be remembering completely wrong here) |
|
Fixed AddTrackEvent to handle multiple MediaStreams, and other CR comments. PTAL. |
Fix the parameter descriptions for RTCAddTrackEvent
Merged in a link fix from @dontcallmedom and also cleaned up AddTrackEvent. |
Any update on this PR? Would like to land this ahead of next week's meeting. Also, I have this PR queued up to change updateIce -> setConfiguration. |
The editor's are going to have it reviewed by Thu this week, hopefully it can be merged shortly after that. |
referenced by the SDP | ||
negotiation, creating a new ones if they do not exist. If no | ||
MediaStreams are indicated in the SDP negotiation, a default MediaStream | ||
is used.</p> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This section needs some work. The algorithm talks about several incoming components. That used to be the case when we were creating a MediaStream with several tracks; now we only have one. Step 3 (not in the diff), should be moved earlier, since it creates the MediaStreamTrack.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK. I think I addressed these issues.
</dd> | ||
|
||
<dt>readonly attribute sequence<MediaStream> streams</dt> | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This must be a getter function since a sequence is passed by value.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Copied what you did in your branch.
The stats-example uses pc.getRemoteStreams(). It needs to be updated as well. |
I got a task to isolate the new section so it could be reviewed separately. I did some fixes as well that can be found here: https://github.com/adam-be/webrtc-pc/commits/juberti-rtpsr |
Addressed all comments. PTAL. |
@alvestrand @adam-be what are the next steps on this? |
I know Adam has prepared a version of the spec with these parts included; I think the plan was to send it to the WG before the meetings this week. |
<code>receiver</code>.</p> | ||
</dd> | ||
|
||
<dt>sequence<MediaStream> getStreams()</dt> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I know the getter comes from a change suggested by @adam-be , but it sounds to me that using a simple attribute with an array rather than a sequence would work just as well (i.e. readonly attribute MediaStream[] streams
).
Obsolete - PR is now #175 |
Initial version of doohickeys. @alvestrand @stefhak @pthatcherg PTAL and see if you think this is going in the right direction. If so I will deal with the few formatting and link nits remaining.
Details: