New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 18 users
Status: Available
Owner: ----
Cc:
Components:
NextAction: ----
OS: ----
Pri: 3
Type: Bug



Sign in to add a comment
Imageattr header ignored by Chrome
Reported by palma.pi...@gmail.com, Sep 10 2013 Back to list
What steps will reproduce the problem?
1. Set up a simple webRTC video-call beetween two clients 	
through a simple signaling server.
2. Insert an A line in for the video codec in the answer sdp: a=imageattr 100 recv [x=[128:16:320],y=[96:16:240]] send [x=[128:16:320],y=[96:16:240]] send
3. Makes the video call

What is the expected result?
The video call is established, the resolution of local and remote video respect the limits of the imageattr header

What do you see instead?
The video call is established but the resolution of local and remote video are the standard (640x480).

What version of the product are you using? On what operating system?
Browser: Version 29.0.1547.66 m
OS: Windows 8

Please provide any additional information below.
In the attachment the sdp of the answer.

 
answer_sdp.txt
1.6 KB View Download
Project Member Comment 1 by braveyao@webrtc.org, Sep 10 2013
Cc: wu@webrtc.org braveyao@webrtc.org vikasmarwaha@webrtc.org
Owner: juberti@webrtc.org
Thanks for the report! Currently we don't support it yet. 

@justin, would we consider this attribute in the future?
Yes, we may implement this in the future. Or this may need to wait for WebRTC 2.0. We'll see how much uptake this bug gets.
Project Member Comment 3 by juberti@webrtc.org, Sep 11 2013
Labels: Area-PeerConnection
Comment 4 by hta@google.com, Oct 10 2013
I do not believe this means of trying to control resolution is valid, and we should not support as stated (inserting imageattr by SDP munging).

It's possible we should allow CreateOffer to generate an imageattr attribute, but we should not accept SetLocal() with an imageattr attribute as long as we don't support it. We should probably add a check for unknown attributes in SetLocal, and refuse SDP that contains such unknown attributes, so that we avoid similar undefined results in the future.

We should support SetRemote with an imageattr attribute, but the spec allows to ignore it as we ignore all unknown SDP attributes, and our CreateAnswer to an offer containing imageattr should not contain imageattr. (I believe this s true at present).


Comment 5 by t...@addlive.com, Oct 22 2013
Just a comment of a potential user of this API. We really would like to have a way of controlling the resolution of the video stream generated by the peer connection. At the moment, this can be done in a limited way only on the getUserMedia level.

I also believe that it is a bad idea to have this level of control available only via the SDP. 

From what I know, at the moment the only possibility to constrain the resolution of the video feed, is to apply it to the media stream object while calling the getUserMedia. We're looking for a way to limit this for a particular PeerConnection only, so the PeerConnection will downscale the feed before encoding.

Additionally, from the W3C spec, there is a define way to specify these constrains programatically, the RTCPeerConnection#addStream method takes the 2nd parameter - media constrains. Supporting the same constrains that are available during the getUserMedia phase here, would IMO create a concise API. 

On a side note - is there any official way available currently to limit the size of an upstream video feed?

Regards,
Ted
Project Member Comment 6 by juberti@webrtc.org, Oct 22 2013
Agree with the ability to control encoding resolution of a MediaStreamTrack. One other option is the new applyConstraints method on MediaStreamTrack, which could be used to change the output resolution without involving getUserMedia.

AddStream isn't really a great surface for doing this sort of thing, since you might want to change the constraints in mid-call. But there are some proposals for a revamp of addStream to provide a proper control surface that we are considering.
Comment 7 by stoic...@gmail.com, Dec 11 2013
Just a thought. In our use case, the API on the MediaStreamTrack level won't be enough, as it will still apply the constrains to every peer connection using the media stream. What we actually need is to have the ability to:

1) Use multiple peer connections
2) Be able to specify size of video feed on per peer connection basis.

Is this ticket a proper one to track status of this functionality?

Regards,
Ted 
Project Member Comment 8 by juberti@webrtc.org, Dec 11 2014
Labels: IceBox EngTriaged
Status: Available
Pending resolution of https://github.com/rtcweb-wg/jsep/issues/5
From what I understand, that spec issue is now resolved.
Firefox also implements support (https://bugzilla.mozilla.org/show_bug.cgi?id=1173599)

Any plans on prioritizing this in Chrome?
Indeed, the spec issue is resolved. Not on the Q4 roadmap but will reconsider for Q1 2016
Project Member Comment 11 by pthatcher@webrtc.org, Nov 8 2016
Labels: Pri-3
Project Member Comment 12 by anatolid@webrtc.org, Dec 14 2016
Cc: juberti@webrtc.org
Owner: ----
Sign in to add a comment