This also adds RTPCapabilities and a header field to tell the receiver
about capabilities used in encoding this frame. It is intended to contain
settings relevant to the current frame being sent.
follow TokTok#731. This commit
completely removed all things in namespace bit_rate, and deprecated
functions are to be added back in another commit. set_xxx() is treadted
as a property of namespace audio&video, same as bit_rate change event.
toxav_basic_test is fixed, either.
Also got rid of two VLAs. They are overused a bit in toxcore. In
irc_syncbot, the array was uninitialised and then filled by a recv system
call. This can cause uninitialised reads if recv doesn't fill the entire
array. It could not cause out of bounds read directly, because a
NUL-terminator was in place, but both cases are undefined behaviour.
Fixes#572.
As discussed in the issue, there's a risk that toxcore may not hold the
maximum bitrates libvpx supports, if toxcore insists on using integer
type. I initially proposed to have another flag in set(), so that we can
use unsigned type instead. iphydf came up with a better solution, that is
splitting the original functions, one for audio, one for video. Now, we
could safely replace int32_t with uint32_t.
Also: clean video_bit_rate_invalid()
Though this is not a part of issue #572, as it's used in the
toxav_bit_rate_set(), i cleaned the code. As mannol said, there should be
a check. Uint32_t is large enough to hold the maximum bitrates libvpx
supports, but user may pass a value larger than uint while smaller than
uint32_t. Thanks to the reminding from nurupo, it's no longer a stub
function.
Bitrate error enums are shared for both audio and video
https://github.com/TokTok/c-toxcore/pull/578#issuecomment-360095609, just
as iphydf said.
Turning this code:
```c
if (cond) { ... return 0; }
if (!cond) { ... return 0; }
return -1;
```
into:
```c
if (cond) { ... return 0; }
else { ... return 0; }
```
The `return -1` in the first variant can never happen.
This way, developers compile toxcore, toxav, and toxencryptsave as C++ at
least once at home, reducing the likelyhood of running into travis
failures where we compile as C++ in the windows build.
This allows us and users to reproducibly build verified versions of the
library with checksums. It will power the toktok-stack continuous build
with checked-in checksums at specific git revisions.
Still run all the jobs during cron and regular push to branch. We
disabled build for push to branch, so cron is the only place where all
builds are run. This also means we need to worry less about spending time
in nightly builds, because they occur only once a day.
See https://github.com/travis-ci/travis-ci/issues/9071
This isn't adding value. We're going to redo the whole rpc test framework
in the future, after a lot of refactoring that the hstox test currently
just stands in the way of.
