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 16 users
Status: Available
NextAction: ----
OS: ----
Pri: 3
Type: Enhancement

issue 2489

Sign in to add a comment
Parsing VP8 SDP fmtp parameters
Project Member Reported by, Oct 10 2013 Back to list
Feature description (please include a link to the functional spec): specifies that the parameters "max-fr" and "max-fs" are REQUIRED.

We need to parse these parameters and make sure we don't generate larger encodings than will fit in those limits.

Eng owner:

Project Member Comment 1 by, Oct 10 2013
Comment 2 by, Oct 14 2014
Labels: Area-Network
Comment 3 by, Nov 3 2014
Labels: EngTriaged IceBox
Comment 4 by, Nov 3 2014
Labels: -IceBox Mstone-42
Project Member Comment 5 by, Feb 19 2015
Labels: -Mstone-42 Mstone-44
This looks like it's not hitting m42.  Update it if I'm wrong.
Comment 6 by, Aug 31 2015
Hi, any progress on this issue? We're trying to set these values in our native apps' sdps, but only Firefox seem to honor them. (I see that the parsing of fmtp parameters have briefly been discussed in issue #2489 as well, not sure where you'd like to have the discussion).
Project Member Comment 7 by, Aug 31 2015
Labels: -Mstone-44
Status: Assigned
pthatcher@ and/or stefan@ - can you take a look?
Project Member Comment 8 by, Sep 2 2015
For what purpose are setting the values?  The standard says: 

These parameters MUST be used to signal the capabilities of a receiver implementation.  These parameters MUST NOT be used for any other purpose.

Do you really have a receiver that does not have the capability to receive what Chrome is producing?  Or are you just trying to use these values to control the output resolution and framerate (which it explicitly says not to do).

If you're trying to control the output resolution/framerate, I would suggest you use constraints on the input MediaStreamTrack instead.

But eventually we should  parse them and make sure we don't send more than the remote side says it's capable of.    And we should generate the parameters as well.   This seems like a job for the WebRtcVideoEngine2 to do.  

pbos, can you check the codec parameters for max-fs and max-fr and limit the outgoing framerate/resolution?
Comment 9 by, Sep 2 2015
The purpose is to only limit what is sent to low-end devices in a call, such as older iPhones, without the sender (web client) needing extra logic for switching between high and low resolution streams.

If the definition of capable in the standard is just referring to the decoder implementation of the receiver, and not the current CPU and bandwidth load of the receiver, then yes this is a workaround.
Project Member Comment 10 by, Oct 5 2015
Labels: Pri-2
Project Member Comment 11 by, Oct 5 2015
Labels: Area-Video
Project Member Comment 12 by, Dec 9 2015
Blocking: 2489
Project Member Comment 13 by, Dec 10 2015
How much work do you estimate is left on this issue?
Project Member Comment 14 by, Dec 28 2015
Not been prioritized, I believe this should be parsed and setting constraints on cricket::VideoAdapter to not deliver input above max inside of talk/.
Project Member Comment 15 by, Feb 17 2016
 Issue 5526  has been merged into this issue.
Project Member Comment 16 by, Feb 17 2016
 Issue 5526  has been merged into this issue.
Project Member Comment 17 by, Mar 1 2016
Any news on this ? Seems pretty important
Project Member Comment 19 by, Aug 4
Status: Archived
[Bulk edit] This issue was created more than a year ago and hasn't been modified the last six months -> archiving.

If this is still a valid issue that should be open, please reopen again.
Project Member Comment 20 by, Oct 3
Labels: -Pri-2 Pri-3
Status: Available
Reopening, since this is required for standards conformance.
Lowering priority, since there isn't an urgent customer request for this.

Sign in to add a comment