Split toxav_bit_rate_set() into two functions to hold the maximum bitrates libvpx supports

[xhebox]

following #572

---

This change is 

[CLAassistant]

All committers have signed the CLA.

[Diadlo]

@xhebox You forget to update toxav/toxav.c

[xhebox]

@diablo oh my, sorry, i am so hurried

[iphydf]

@xhebox: Can you rebase this on master and check the checkbox on the right to allow contributors to push to your PR branch? Also, the CI fails, likely because you didn't update toxav.api.h.

[xhebox]

@iphydf sorry for the late reply, but there are still some controversial problems, that's why i stop working.. see #572 (comment) , i am actually waiting for a reply about this comment, how do we deal with the '-1' flag? i've commented two options in the next comment, tell me if you have a better idea. i'm willing to continue my work if you give me a clear statement about it.

[nurupo]

libvpx not specifying max bitrate and using integers that have implementation dependent widths complicates things a lot. No, this can't be. There must be max birate specified somewhere. Otherwise how is this even supposed to be portable? On one machine unsigned int might be 16 bits, on another 32-bit, yet on another 64 bits. Imagine a machine with 64-bit unsinged int sending video with UINT64_MAX bitrate to a machine with 32-bit unsigned int. It would just overflow. There must be a bitrate limit specified somewhere in VPX video stream protocol definition. Given that unsigned int is specified to hold at least 16 bit integers, my guess would be that the max bitrate would be less or equal to that of UINT16_MAX, but guessing is bad, we should really find the actual bitrate specification rather than do the guessing.

[iphydf]

@xhebox I see, thanks. I've replied on that issue.

[xhebox]

@iphydf new commits pushed
@nurupo i've never thought so.👍

[iphydf]

@xhebox code needs reformatting.

[nurupo]

Well, my last comment is somewhat irrelevant to this PR or the issue in question in general, it was more of a reaction on zoff's comment in the issue thread #572 (comment). Should have replied in there instead of here.

[nurupo]

@xhebox run astyle on the code to format it, you can find astyle rule file and the command to use at https://github.com/TokTok/c-toxcore/tree/master/other/astyle.

[nurupo]

toxav/toxav.c, line 1052 at r1 (raw file):

because we also use uint

We use uint32_t, not unsigned int, these are different things, they can have different ranges.

I'd say that this function needs to return bit_rate <= UINT_MAX, to check if we would overflow unsigned int with our uint32_t value.

---

Comments from Reviewable

[xhebox]

@nurupo @iphydf OK, new commits pushed, all tests passed, looks good :)

[iphydf]

This is fine, I just want to note that it may cause compiler warnings on ILP64 systems (we have never tested any of those, so we have no idea if anything in toxcore works on them, anyway).

[xhebox]

@iphydf I have idea about how to detect if it's ILP64 or LP64(sizeof?). But i think it's fine since most computers are still using int of 4 bytes. And if it's ILP64, uint32_t is not large enough at all. In my view, we could sleep on it for now.

[Diadlo]

---

Reviewed 3 of 4 files at r1, 1 of 1 files at r2.
Review status: all files reviewed at latest revision, 2 unresolved discussions, some commit checks failed.

---

Comments from Reviewable

[iphydf]

Please enable the checkbox "Allow edits from maintainers." on the bottom right. This allows us to squash the commits and rebase on master before merge.

@nurupo can you review this?

[xhebox]

@iphydf enabled :)

[zoff99]

@iphydf can you keep the old toxav_bit_rate_set() as a wrapper that just calls the 2 new functions internally? no need to break api "just because we can".