Imageattr header ignored by Chrome
Reported by palma.pi...@gmail.com, Sep 10 2013
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.
Sep 10 2013,
Thanks for the report! Currently we don't support it yet. @justin, would we consider this attribute in the future?
Sep 11 2013,
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.
Sep 11 2013,
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).
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
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.
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
Dec 11 2014,
Pending resolution of https://github.com/rtcweb-wg/jsep/issues/5
Oct 7 2015,
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?
Oct 8 2015,
Indeed, the spec issue is resolved. Not on the Q4 roadmap but will reconsider for Q1 2016
Nov 8 2016,
Dec 14 2016,
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available.
[bulk-edit] Setting status to Available since it's likely that this issue shouldn't be archived yet. Also changing Pri to 3 due to long period of inactivity (indicating low priority).
Sign in to add a comment