Corrected various spelling mistakes in comments, documentation, and
variable names across the project. Changes include:
- Documentation files (CONTRIBUTING.md, README.md, etc.)
- Source code comments in C/C++ files
- Function parameter names and descriptions
No functional changes were made.
Refactoring done in 1ab725d57 (2024-08-05) changed the behavior not to
expect NULL pointer, because common_opts.encryption is a char array now.
But tx_init calls also audio/playback/mixer, which crashes since then so
be less rigid in this case.
The data_len var used to compute packet_count may be lesser than its
initial value (tx->mtu - hdrs_len) because it might have been decreased
to number of remaining bytes of the last packet.
Returned back data_len to the do-loop and compute the value as
max_len.
In case that the input has 1 channel and 8 kHz, the packet type was not
set to 14, because the first if branch was entered instead of else-if
(not setting anything).
Fixed the condition that applied only if fixed PT was used for the
audio. But dynamic packet type is used when more channels are used,
in which case the condition didn't hold, which caused the stream not
being handled appropriately (interleaving the channels).
Duplicate first packet to increase resilliancy in cases when the traffic
is low, usually a single packet of some inter-frame compression like
H.264/HEVC. But it will similarly do the job when more packets per frame
are used.
First packet is duplicated instead of the last one because the last packet
can have less symbols than the first if there is more than 1
packet, eg. `DDDD|DF` (D - primary data; F - FEC, | - packet bounadry).
refers to GH-361
Send only one channel in RFC-compliant mode even if there are more,
just print an error.
The point is that even though the default audio capture channel count
is 1, some devices may not support mono (eg. DeckLink) and produce more
channels (usually 2) anyways.
see also similar change for audio in commit 6c07a3e43 (2023-07-27)
The previous solution was using some cumbersome solution, perhaps
repeating the sequence (with mult:3) like `111222333444`.
Rewritten to be easier; also nwo the multiplication is as follows:
`123412341234`, which is perhaps better than the previous variant.
The symbol size is printed only once (or more precisely few times,
because it is guarded by a thread-local variable and the sending may
pick a different runner). This, however, doesn't give representative
numbers when frame sizes differ (== compressed) because then may also FEC
symbol sizes so print it unconditionally at least with debug2 log level.
refers to GH-361
\+ ignore leading AUD NALU if present (add own 4B start code instead) -
it could have produced problems when AUD+SPS+PPS is prepended to regular
frame that is not an IDR frame
It needs to be enabled explicitly, anyways - at least Opus won't work
with former UG versions. For 40 ms frame, it produces 2 packets. When
merged into one packet, the decoder is unable to decompress.
Send channels sequentially with a new function to simplify the code.
Also removed the the cumbersome multiplier packet interleaving - not
sure if it worked as expected (having sliding n-packet interleave window
for n-multiplied stream).
Now we simply send all packets of the frame as without multiplication
and then repeated with M-bit set to the latest packet. It is much easier
and it is supposed to work approximately the same or even better.
