Fixes problem described (and partially fixed) by commit 13b44851.
The idea is to use least common multiple of all pixel format alignments
(in pixels) and split only on this boundry (in source pixfmt byte
length) because we don't know destination pixfmt alignment requirement.
Simply send multiplied packets sequentially, like for mult:3:
0 0 0 1 1 1 2 2 2 ....
This simplifies the code while the old one was already defunct (at least
the access to packet sizes' list was wrong since recent rewrite).
Removed msg_change_fec_data, use msg_universal instead.
This is a more versatile solution allowing further extensions without
a need to modify the global structure at an expese of worse type control.
As a replacement, a tag starting msg_universal::text is used/suggested.
- adjust receiver in rtp_process_data() - in previous location, the
packet might have been freed (in unusual scenario)
- do not check if sending to blackhole for every packet - do the check
only once per frame
This partially reverts a0cc3db5.
Fixes command: uv -t testcard:1920:1080:25:RGBA --param decoder-use-codec=UYVY -d sdl
The selection of correct split is quite tricky because even though 4 is
suffiecient for RGBA, using the UYVY decoder increases the size to 8
because the line-decoder obviously needs to process 2 pixels (aligned
at 2-pixel boundry). So the sender has no prior knowledge which
splitting the receiver requires.
Currently it is only a workaround using LCM from a value 48 (suitable
for RG48->R12L conversion) and pixel format block size.
Use adaptive capped bitrate if a limit bitrate value is specified.
Previously packets were emitted exactly at the specified bitrate which
is now an optional. Now, by default, the shapper shapes equally to
a frame time or capped bitrate (if the packet rate would be lower).
Correctly split packets for different pixel formats - previously there
was preset 48 B boundary which was least common multiple for then
present pixel formats (v210 has 16, RGB 3). However, R12L is not covered
since it uses block of 36 bytes.
From now on, we are splitting the packets according to the needed
boundary of pixel format (or arbitrarily for compressed). As a side effect,
the packets may be slightly bigger up to MTU size.
* Since RTSP is no longer working with current LIVE555, RFC-conforming
H.264/A-law/u-law/OPUS streams can be accessed with SDP.
* experimental only (would need more effort to be robust, well written
etc.)
* removed ifdefs from transmit relating to standard AV RTP payload
formating
* main: added --protocol option (shortcut for --audio-protocol and
--video-protocol)
* main: disable intra refresh in default setting for H.264 in RTSP/SDP
* implemented CFB + switched to it because Debian currently does not
include CTR mode
* use CFB by default (decoder should still be able to decompress CTR if
support is compiled in)
* video: compute packet rate from actual (average) size of packet, not
MTU, because it may be different from MTU when using FEC to
align the size to size of FEC symbol
* audio: disable traffic shaping at all
