20819 2013-01-29 18:32:04 +0000 no priority API 2014-10-31 16:32:05 +0000 1 1 1 Unclassified WebRTC Working Group WebRTC API unspecified PC Windows NT RESOLVED LATER P2 normal --- 1 matthew.kaufman public-webrtc cowwoc fluffy gang.liang harald public-webrtc stefan.lk.hakansson w3c-bugzilla oldest_to_newest 82302 0 matthew.kaufman 2013-01-29 18:32:04 +0000 There is no API allowing a developer to prioritize video over audio or vice versa. Nor to set the priority of the data channel above or below that of audio and/or video. Nor to set the priority of individual data channels above or below one another and/or audio and video. Priority APIs have been discussed at previous F2F meetings, though individual stream priority was not resolved. 82330 1 stefan.lk.hakansson 2013-01-30 12:58:34 +0000 (In reply to comment #0) > There is no API allowing a developer to prioritize video over audio or vice > versa. Nor to set the priority of the data channel above or below that of > audio and/or video. Nor to set the priority of individual data channels > above or below one another and/or audio and video. > > Priority APIs have been discussed at previous F2F meetings, though > individual stream priority was not resolved. I recently sent a proposal to the list: http://lists.w3.org/Archives/Public/public-webrtc/2013Jan/0005.html But there is no agreement yet on the right way to do this. 89583 2 fluffy 2013-06-19 13:04:24 +0000 I'd like to +1 this bug. I think now would be a good time to get a good API proposals and get it into the spec. 89678 3 stefan.lk.hakansson 2013-06-21 06:19:19 +0000 (In reply to comment #2) > I'd like to +1 this bug. I think now would be a good time to get a good API > proposals and get it into the spec. I brought forward before, and am proposing again, that we - in a similar vein to how a "RTCDTMFSender" sender is created off a PeerConnection but bound to a MediaStreamTrack - allow for the creation of an object that allows setting of priority and other transport related things per track using the established Constraints model. So we could add to PeerConnection something like: RTCTransportHandler createTransportHandler (MediaStreamTrack track); The TransportHandler would use Constraints, e.g.: interface RTCTransportHandler { readonly attribute MediaStreamTrack track; TrackTransportConstraints? constraints (); void applyConstraints (TrackTransportConstraints constraints); attribute EventHandler onoverconstrained; }; Constraints could be: * Priority * bitrate (min, max) * audio content (speech or general audio) * video codec operation (VBR, CBR) and so on (and of course we need to agree on an initial set). 89679 4 cowwoc 2013-06-21 06:28:46 +0000 I second Stefan's proposal. 90106 5 gang.liang 2013-07-02 08:31:16 +0000 I support considerring priority API now. 114337 6 harald 2014-10-31 16:10:29 +0000 The WG consensus is that we can live without this for the 1.0 API version The likely control surface is the RTPSender API. 114344 7 fluffy 2014-10-31 16:32:05 +0000 I am NOT ok with closing this bug and would like it reopened. I think there are several of us that feel it is very important to have this API in 1.0 and varios browse can decide what part of they want to implement