Keep outgoing RTP timestamps consistent between different instances of
the DTX buffer. Update affected tests.
Change-Id: I6cf03ab32f5c510bd781063a9e7241d1187c202b
If the last used PT was a different one, check if it was an unknown PT.
If it was, then DTX can remain active, as the packet would have been
blocked.
Change-Id: Icc8bf195c30a2252b392bbccfeef34b91078ddd6
The stub is used for unknown payload types. Specialise the handler
function for it with an extra check for DTX usage. This effectively
blocks RTP packets with unknown payload types if DTX has been
configured. Forwarding RTP packets with unknown payload types can
interfere with a clean output stream generated by the DTX buffer.
Change-Id: I6f0aa9654946d2877b963cd13cec7c3f5c8b1c54
Shutting down a DTX buffer means that it may restart at an unknown later
time. Reset TS tracking when shutting it down so that if it does
restart, it receives a fresh TS state, instead of continuing on the
previous timestamps, which may then be wrong.
Change-Id: I9c7978e2f335eab32982c4739917ca5ce0c27eb6
Extend PT tracker to not just track the most used PT, but also which PT
has been used last. Use a simple circular array.
Use this new tracking to determine whether a DTX buffer should remain
active. The "most used PT" approach isn't reliable for this, as it leads
to a DTX buffer restarting only after the PT has become the "most used,"
so only after about 10 packets. Meanwhile a newly appearing SSRC would
have a new DTX buffer active immediately. Being strict about which PT
was used last resolves this inconsistency.
Change-Id: If912e4d10e6737a82f6adc0b19d502075aa18a93
If a packet is received for a codec that should have an active DTX but
doesn't, drop the packet instead of forwarding it without being
processed. In this case we expect that some other codec has an active
DTX buffer, and forwarding the packet would interfere with a clean
output stream.
Change-Id: I162ba6f314b804123a6a3957feb7435a319ad2b9
The GLib slice allocator has been obsoleted. Having a mixture of two
allocators can lead to hidden issues on systems that use different
implementations. Take the leap and replace everything with g_new/g_free.
Change-Id: I025c8383ef47b2c2472573360407fd6a6ca339b3
Decoding and encoding may have taken some time. Grab an updated "now"
before scheduling a packet to send.
Change-Id: I9380cb01d77519cf082d87f3a6c6cfc18b8213f8
With reuse-codecs, we still need to place the codec from the SDP into
our prefs list, even if it's already present, as the format options may
have changed. Update one affected test case.
Closes#1921
Change-Id: I688c57a8c45ec4c3bf159fe2193a0e00bbceeda2
Adds a new config section that allows adjusting behaviour for certain
transcoding scenarios. This only adds the initial support for the config
option.
Change-Id: Ia3d43061adc540fab054e5c99ab804dc1ff53b84
Special codec handler to support not forwarding (nor any processing
whatsoever) of particular payload types at all. Support this in the
kernel module as well.
Change-Id: If10227affa54307e1e9b448eadd0bf2bfc5774ba
Obsolete the two flavours of packet_encoded_tx and instead distinguish
the two flavour of sequence number handling (passthrough and
self-generated) through a function pointer in the codec SSRC handler,
directly pointing to one of the two existing codec_output_rtp wrappers.
Change-Id: Ib1141413859dab37048be9b04af7a5d235b46d0a
Make sure a codec is not only known to us, but that it can actually be
used, in places where it makes sense. This is partially redundant
because ensure_codec_def_type already takes care of this, but a codec
definition may come from a different source, so it doesn't help to
double check.
Change-Id: I91af84afc2477840f1400674b2538ad8fb7746ee
A matching payload type number in an answer might not be enough to
establish compatible codecs. Also check the format parameters. Reject
and ignore answer codecs that are not compatible.
Change-Id: I12a1287216886926ec4b3c704029c923f815b429
`packet_sequencer_init()` initializes
`packet_sequencer_t` sequence to -1 always.
So make sure to set `uint16_t` later not to
an underflowing value, which can potentially
set the `uint16_t` object type to some insanely
big value.
Fixes:
/daemon/codec.c: 1893 in __handler_func_sequencer()
1887 if (!seq) {
1888 seq = g_slice_alloc0(sizeof(*seq));
1889 packet_sequencer_init(seq, (GDestroyNotify) __transcode_packet_free);
1890 g_hash_table_insert(ssrc_in_p->sequencers, mp->media_out, seq);
1891 }
1892
>>> CID 1616503: Integer handling issues (INTEGER_OVERFLOW)
>>> Expression "seq_ori", where "seq->seq" is known to be equal to -1, overflows the type of "seq_ori", which is type "uint16_t".
1893 uint16_t seq_ori = seq->seq;
1894 int seq_ret = packet_sequencer_insert(seq, &packet->p);
1895 if (seq_ret < 0) {
1896 // dupe
1897 int func_ret = 0;
1898 if (packet->dup_func)
** CID 1616502: (LOCK_EVASION)
/daemon/media_player.c: 487 in media_player_read_decoded_packet()
/daemon/media_player.c: 479 in media_player_read_decoded_packet()
Change-Id: Ifbd68021f17866aa9b7482b1bd42e2acf1c25dfa
Make the macro return the appropriate pointer type, and make sure the
free function takes an argument of the same type. This also eliminates
some boilerplate type-casting code.
Change-Id: I3094271fa2c53ec93b9ff9f837d461cf422e0f12
The `answer` processing empties out the list of codecs and leaves only
those that were accepted in the answer. Side effect of this is that if
another answer with a different list of codecs comes through, them the
codec-accept function is missing the original list of offered codecs and
can yield an incorrect result.
Fix this by storing a copy of the offered codecs at the end of the
`offer` processing, and then restore this list at the beginning of each
`answer` message.
Change-Id: I3c714e80689f3c5689637cc7d1eb2f203c292a15
Richard Fuchs
Dennis Yurasov
Donat Zenichev
Michal Hajek