... from packetizer function instead of putting it into the AVPacket.
Remove AVPacket from callback function arguments.
Fix up PTS/duration adjustments where they were missing.
Closes#1963
Change-Id: Ib36b36bb6648b0579dd83155c7217317dda29cc3
if a delay buffer is enabled, the packets get scheduled in the future,
but media playback packets are scheduled immediately. this results
in choppy playback due to the packets coming in at the same time.
This change adds a new bool to chu_args that gets enabled when
play-media is called and passed in to codec_handlers_stop so the delay
buffer queue is cleared instead of flushed
Change-Id: Id534f9087d934481f17341bc577099dc2362f8e1
when media playback happens, all packets get scheduled at the same
time with a send time in the future. however, this results in the
output_skew calculation triggering an unnecessary shift in the send
timer, which can cause choppy playback
Change-Id: I449f221a4d348eb615c2af1dca30bec163aa4fc6
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
Serves as a lookup index into a hash table. Use a union in the existing
struct so that we don't have to do any word replacements.
Change-Id: I15f33982ae929e6ed7c1264f7d11a2dca8e03741
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
This only exists because of RTCP indexing issues, but with the index
being in shared memory now, we no longer need this.
Change-Id: Ib0a69214f24a7c1edec8aa53139212ee861a6c4d
In the header files follow the rules:
1. Firstly goes ifndef/define construction, then one empty row.
2. Secondly go system headers, so in angle-brackets, then one empty row.
3. If there are important pre-processor definitions, which affect
the following custom file headers, they are added next, then one empty row.
4. Thirdly custom header files, so in double quotes,
then at least one empty row.
5. If there is "xt_RTPENGINE.h", it's mentioned next, but separately,
then one empty row.
6. Then pre-processor definitions, and one empty row before the code.
In some situations it's allowed to step aside from the rules,
when inclusions are dependent on each other, so on specific sequence,
and also possibly on some inline objects definitions.
But, if possible to follow the rules, it should be done.
Change-Id: I6bec69b508653947c04e7785775373d21112eb58
Allow codec_tracker_update to reference an existing codec_store. Then
when a supplemental codec type needs to be generated, make it look up
the type in the existing codec_store and re-use the existing payload
type if present instead of creating a new one. This allows payload type
numbers to remain unchanged during a re-invite.
Change-Id: I9e5edd897515a5e3eb5033aa6bbf21c8667d6133
During an offer, we update the codecs from the given list not only on
the side of the offerer, but also on the answerer's side, in order to
perform the codec answer routine during the answer phase. While doing
this, we empty out the existing list of codecs (on both sides) and
repopulate it fresh from the given list.
This can cause problems during a reverse re-invite, when the list of
codecs on the answerer's side already contained the codecs that had been
offered before. When setting up the new re-invite offer, we want to
retain codecs (and their payload types and format parameters) that were
already in place, instead of recreating a new list from scratch.
Improve this by adding a `merge_cs` option to the populating functions,
which points back to the stream_params codec_store. Codecs that would
have been removed from the codec_store during the repopulation are then
moved back into the stream_params codec_store instead. This then allows
the functions adding new codecs to the list (offer/transcode) to
reference these codecs that were previously in place, and so they can be
added back with the same options as they had existed before, instead of
recreating them from scratch.
Change-Id: I53e7ab10e9144a308a5c36be5ebfddd73c212f06
From now on the `call_subscription` concept gets
deprecated, and instead of it the `media_subscriptions`
concept gets applied.
Benefits of this change is:
- ability to subscribe one-to-multiple medias (different monologues)
- media level manipulations, without affecting whole SDP session
- no need to use medias offset, to detect proper subscription's media
- there is no need of particular medias order, they can be
subscribed to each other in any possible way
(even though RFC still requires to always have proper ordering)
Deprecated objects:
- `struct call_subscription`
- `GQueue subscriptions`
- `GQueue subscribers`
- `GHashTable * subscriptions_ht`
- `GHashTable * subscribers_ht`
Deprecated functionality:
- `__unsubscribe_one()`
- `__unsubscribe_all_offer_answer_subscribers()`
- `__unsubscribe_from_all()`
- `__subscribe_offer_answer_both_ways()`
- `__add_subscription()`
- `__unsubscribe_one_link()`
- `call_get_call_subscription()`
- `call_subscriptions_clear()`
- `call_subscriptions_free()`
Offtopic: additionally this commit adds helper func:
- `call_media_subscribed_to_monologue()`
Change-Id: Ifb44f7a1ba5b483b1472882b1b8d06444dba1727
If we're updating the handlers for one particular source -> sink flow,
only stop/reset the handlers matching this flow.
Change-Id: I1d046f47f8d26cac47c5d0f4318498eacb6c5677
Previous implementation assumes that we use the `call_subscription`
objects in:
- `call_offer_answer_ng()`
- `call_update_lookup_udp()`
- `call_request_lookup_tcp()`
when appealing to the `call_get_mono_dialogue()`, in order to
get the `call_subscription` objects, in order to then pass it
for usage in the `monologue_offer_answer()`, where the most important
again is to use monologue references stored inside
the given `call_subscription` objects.
Instead of using the `call_subscription`, just use `call_monologue`
objects as a base data objects for this work,
which will allow us in the coming commits to deprecate
the `call_subscriptions` based model and
get to the subscription model based on medias.
Change-Id: Ia9ee5ba66522929acbceca28854ebccd3705635a
Richard Fuchs
Tom Briden
Donat Zenichev
Orgad Shaneh