New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 2359 link

Starred by 22 users

Issue metadata

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

Issue description

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: ----
Project Member

Comment 13 by sheriffbot@chromium.org, Sep 6

Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
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.


Project Member

Comment 14 by anatolid@webrtc.org, Nov 1

Status: Available (was: Untriaged)
[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