Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

H.264/AVC profileLevelId - should be DOMString? #587

Closed
aboba opened this issue Aug 31, 2016 · 5 comments
Closed

H.264/AVC profileLevelId - should be DOMString? #587

aboba opened this issue Aug 31, 2016 · 5 comments

Comments

@aboba
Copy link
Contributor

aboba commented Aug 31, 2016

Currently, the H.264 profileLevelId is defined as unsigned long. This is inconvenient - developers can more easily manipulate it as a string.

@mjerris
Copy link

mjerris commented Aug 31, 2016

Switching it to a string brings all kinds of additional issues with validating invalid data coming in. Either in long or string, it will still require a chart of valid values and what they mean, is it really inconvenient, seems the error that will be caused by people putting in strings that are kind of but not quite valid is much more inconvenient.

aboba added a commit that referenced this issue Aug 31, 2016
@aboba
Copy link
Contributor Author

aboba commented Aug 31, 2016

Since the codec parameter dictionary is provided as a JSON blob, ORTC implementations already parse and validate the profileLevelId parameter represented as a string, and shim libraries such as adapter.js already handle profile-level-id that way, since profile-level-id is an SDP string in WebRTC 1.0. So in practice, existing ORTC implementations already treat profileLevelId as a DOMString.

@mjerris
Copy link

mjerris commented Aug 31, 2016

If thats the case, can passing an invalid value throw an exception here so its very easy to catch the mistake?

@aboba
Copy link
Contributor Author

aboba commented Sep 10, 2016

In send() or receiver() the promise will be rejected with InvalidParameters if invalid parameters are passed as an argument.

@robin-raymond
Copy link
Contributor

Converted to a string since that's the way capability will be announced by the remote party as a string because of SDP. Otherwise adapters will have to know to specially convert this value to decimal. Resolved as a string.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants