OpusContributing: Difference between revisions
mNo edit summary |
No edit summary |
||
| Line 12: | Line 12: | ||
== How to contribute == | == How to contribute == | ||
There are many ways to contribute to Opus development: | |||
* Reporting and fixing bugs | * Reporting and fixing bugs | ||
* Improving tools | * Improving tools | ||
| Line 20: | Line 21: | ||
It is generally advisable to contact the developers on the mailing list or | It is generally advisable to contact the developers on the mailing list or | ||
IRC | on IRC before taking on new work on Opus to avoid duplicating work and to | ||
make sure you're doing things the right way from the start. | make sure you're doing things the right way from the start. | ||
| Line 33: | Line 34: | ||
If you have a patch you would like to contribute, just send it to the mailing | If you have a patch you would like to contribute, just send it to the mailing | ||
list. We can also take pull requests, but please send a note to the mailing | list. We can also take [https://github.com/xiph/opus/ Github] pull requests, but please send a note to the mailing | ||
list since the | list since the Github Opus repository is only a mirror. | ||
== Coding style == | == Coding style == | ||
| Line 42: | Line 43: | ||
indentation, while the rest of the code is mostly 3-space, except the entropy | indentation, while the rest of the code is mostly 3-space, except the entropy | ||
coder, which is 2-space. The general rule is that you should follow the | coder, which is 2-space. The general rule is that you should follow the | ||
style of the code you're modifying. Do | style of the code you're modifying. Do '''not''' reformat the code in your | ||
patches, as it mostly makes it harder to review changes. | patches, as it mostly makes it harder to review changes. | ||
| Line 53: | Line 54: | ||
To reduce the risk of exploitable memory errors, we do not use any function | To reduce the risk of exploitable memory errors, we do not use any function | ||
pointers in the code unless they are declared as static const. We also | pointers in the code unless they are declared as static const. We also | ||
have "flat" objects, which can be copied using a "shallow copy". | have "flat" objects, which can be copied using a "shallow copy", so do not add | ||
pointers to non-static data in the data structures. | |||
Revision as of 12:42, 5 July 2016
Community
Development discussions and questions take place on the Xiph.Org Opus mailing list (opus@xiph.org). Discussion related to the IETF process happen on the IETF codec working group mailing list (codec@ietf.org).
For archives of recent discussions, try:
- Xiph.Org Opus mailing list archives
- IETF codec mailing list archives
Informal development chat and support happens in #opus on irc.freenode.net. You can join the chat room through a web interface if you don't have an IRC client.
How to contribute
There are many ways to contribute to Opus development:
- Reporting and fixing bugs
- Improving tools
- Improving testing framework
- Optimizations (assembly/intrinsics)
- Encoding quality improvements (listening/tuning)
- Mapping to new containers
It is generally advisable to contact the developers on the mailing list or on IRC before taking on new work on Opus to avoid duplicating work and to make sure you're doing things the right way from the start.
How to report bugs
You can report bugs in trac. Please also notify developers on the mailing list.
For sensitive (security-related) bugs, please contact the developers directly.
How to submit a patch
If you have a patch you would like to contribute, just send it to the mailing list. We can also take Github pull requests, but please send a note to the mailing list since the Github Opus repository is only a mirror.
Coding style
Opus is the result of merging three different codebases and therefore does not have a consistent coding style. For example, the SILK code uses 4-space indentation, while the rest of the code is mostly 3-space, except the entropy coder, which is 2-space. The general rule is that you should follow the style of the code you're modifying. Do not reformat the code in your patches, as it mostly makes it harder to review changes.
Language
Opus only requires a C89 compiler, so any use of C99 and later constructs has to be optional (e.g. OPUS_INLINE). This is also why we do not use C++-style // comments.
To reduce the risk of exploitable memory errors, we do not use any function pointers in the code unless they are declared as static const. We also have "flat" objects, which can be copied using a "shallow copy", so do not add pointers to non-static data in the data structures.