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

Issue 2488 link

Starred by 19 users

Issue metadata

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

Issue description

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 2017

Status: Archived (was: Assigned)
[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 2017

Labels: -Pri-2 Pri-3
Status: Available (was: Archived)
Reopening, since this is required for standards conformance.
Lowering priority, since there isn't an urgent customer request for this.

Project Member

Comment 21 by, Jan 22 2018

[bulk-edit] This bug is in status Available and has an Owner... This should be corrected. Can the owner please remove themselves from the bug if they are not working on it to make it truly Available, or change the status to reflect the actual state of the bug?
Project Member

Comment 22 by, Aug 20

[bulk-edit: Please ignore if N/A] This issue has status Available but at the same time it's got an Owner -- which is a contradiction of terms. Can the owner please either update the status to reflect the actual state of affairs (e.g. Assigned/Started if the work is planned/ongoing, or Untriaged if the issue is still under investigation or needs a new investigation, etc.), or alternatively remove themselves as Owner.

Sign in to add a comment