Project: webrtc Issues People Development process History Sign in
New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Issue 2489 Generating VP8 fmtp parameters
Starred by 21 users Project Member Reported by hta@webrtc.org, Oct 10 2013 Back to list
Status: Assigned
Owner:
Last visit > 30 days ago
Cc:
Components:
OS: ----
Pri: 2
Type: Enhancement

Blocked on:
issue 2488



Sign in to add a comment
http://tools.ietf.org/html/draft-ietf-payload-vp8-10 specifies that the size parameters max-fr and max-fs are REQUIRED in an SDP description.

The implementations need to generate sensible values for the platform they're running on.

Eng owner:


 
Comment 1 by vrk@webrtc.org, Oct 14 2014
Labels: Area-Video
Comment 2 by vrk@webrtc.org, Oct 14 2014
Labels: -Area-Video Area-Network
Comment 3 by vrk@webrtc.org, Nov 3 2014
Cc: juberti@google.com
Labels: Mstone-42 EngTriaged
Owner: pthatcher@google.com
Status: Assigned
Assigning tentatively to Peter for now.
To help us move forward with this bug: Is it more important that we generate these values or that these values are honored by the system?

It'd also be helpful to elaborate on "sensible values" here.
Comment 5 by hta@google.com, Jan 5 2015
The state we want to get to is that the receiver always sets the parameters, and the sender always respects them.

Case analysis:

- Receiver doesn't sent, sender doesn't respect: Current situation. Sender sends whatever it wants.
- Receiver sets, sender does not respect: Worse than current - formally noncompliant, receivers written in expectation of respected limits will be overrun.
- Receiver does not set, sender respects: Sender sends what it wants. No worse than current situation.
- Receiver sets, sender respects: Good.

From this analysis, the first implementation should be sender respecting the parameters. It's OK to make our receiver send some hardcoded values (HD@30?) as a first implementation - then we can change them (up or down depending on platform) afterwards.


Project Member Comment 6 by pthatcher@webrtc.org, Feb 19 2015
Labels: -Mstone-42 Mstone-44
This looks like it's not hitting m42.  Update it if I'm wrong.
Project Member Comment 7 by pbos@webrtc.org, Dec 28 2015
Cc: -juberti@google.com juberti@webrtc.org
Owner: pthatcher@webrtc.org
Project Member Comment 8 by tnakamura@webrtc.org, Jan 29 2016
Cc: -pwestin@webrtc.org
Labels: -Mstone-44
I don't see any CLs linked to this bug, so I don't think it's been fixed. Removing milestone label since this bug hasn't been updated in quite some time.
Project Member Comment 9 by pthatcher@webrtc.org, Nov 8 2016
Labels: Pri-2
Sign in to add a comment