\+ 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.
Do not use source TS as (a base for) RTP TS by default anymore. Since this
was essential for synchronized DeckLink playback, require `--incompatible`
to enable this.
The reason to disable for now is because it breaks compressed
audio. Eg. for Opus, one receives 2 packets for 40 ms input. Currently
only the first gets source TS, second is undefined, thus getting the
default, loosely related TS, that may however create TS discontinuity
(especially with the time, when PC and DeckLink time diverges).
There is no good solution for the above yet, sending both packet with
the same TS and m-bit on second isn't sufficient now, because it gets
joined in receiver buffer and eg. Opus is not self delimiting so it will
need changes on receiver side to pass RTP packets to Opus decoder as
Opus packets.
refer to GH-326
Send same RTP timestamps for audio/video frames captured at the same
time.
RTP specification allows this (although doesn't require - according to
the spec, the RTP timestamps should colaesce with RTCP NTP
correspondence). We slightly modify that in a way that we use for both
audio and video 90 kHz clock resolution, so if the start point is the
same (random), the RTP timestamps will be exactly the same for related
data.
Implemented for vidcap DeckLink and testcard.
For audio codecs, we respect its native capitalization of letters, eg.
AAC, speex. So do it also for Opus. This should not affect existing
applications since the Opus name is parsed case-insensitively.
Only exception is SDP (rtpmap) where is usually used lower-case (at
least in rfc7587).
Since the CRC fix has already broken compatibility with older versions,
we can switch by default, anyways.
+ do not request CFB but keep CBC for future compat (seems to be more
widely supported across implementations)
Start lines of uncompressed video only on packet start otherwise in
adverse combination of source and display pixfmts, signal may be broken,
eg. packet start in the middle of dst pixfmt block. Steps to reproduce:
uv -t testcard:size=14x2:codec=Y216 -d gl -m 180! # GL uses v210
In first packet - first 56 B of first line was decoded, than 40 B of the
second line (10 pixels). But 10 pixels from second line was consumed
while v210 block size is 6 pixels, therefore the next packet started in
midst of second v210 block on second line.
Added a rate limiter that occasionally allows excessive frames.
It permits using 1.5x frame time for frame 2x bigger that moving
average if 4 normal frames (using .75x frame time) were emitted
inbetween.
This mode is now default (for video, audio doesn't use rate limiter).
Some macros are quite common so it is perhaps more wise to use a
separate header.
Also moved ref_count_init_once and ref_count_terminate last to misc.h.
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).
