search for: my_short

Displaying 4 results from an estimated 4 matches for "my_short".

Did you mean: is_short
2017 Oct 10
2
[PATCH] Support for Channel Mapping 253.
...w how your "int" value is represented. In this case, we've decided that the byte ordering "on the wire" is little endian, so all you need is write out the least significant byte,then the most significant byte. If you cast to char, then you need the endianness, but if you do (my_short>>8), you always get the most significant byte. Similarly, (my_short&0xff) is always the least significant byte. No need for an endianness check. > 10) Please don't store pointers (MappingMatrix, OpusMSEncoder, ...) in > the OpusPEncoder/OpusPDecoder structs. All the data should...
2017 Oct 10
0
[PATCH] Support for Channel Mapping 253.
..." value is represented. In > this case, we've decided that the byte ordering > "on the wire" is little endian, so all you need is write out the least > significant byte,then the most significant byte. If you cast to char, > then you need the endianness, but if you do (my_short>>8), you always > get the most significant byte. Similarly, (my_short&0xff) is always the > least significant byte. No need for an endianness check. > > > 10) Please don't store pointers (MappingMatrix, OpusMSEncoder, ...) in > > the OpusPEncoder/OpusPDecoder stru...
2017 Oct 11
2
[PATCH] Support for Channel Mapping 253.
...represented. In > this case, we've decided that the byte ordering > "on the wire" is little endian, so all you need is write out the least > significant byte,then the most significant byte. If you cast to char, > then you need the endianness, but if you do (my_short>>8), you always > get the most significant byte. Similarly, (my_short&0xff) is always the > least significant byte. No need for an endianness check. > > > 10) Please don't store pointers (MappingMatrix, OpusMSEncoder, ...) in > > the OpusPEncoder/...
2017 Oct 04
3
[PATCH] Support for Channel Mapping 253.
Hi Drew, Here's some comments on your patch (in no particular order): 1) I see that it's adding an #include of stdarg.h to opus_multistream.h Is that left over from the previous version? 2) Someone on this list might know better than I do on that one, but for the new _ctl_va_list() calls, I believe the convention is for va_start() and va_end() to appear in the caller rather than in in