[asterisk-dev] [Code Review] 3687: media format improvements: Update packetization handling; improve rtp_engine's ast_rtp_codecs handling
Matt Jordan
reviewboard at asterisk.org
Tue Jul 1 14:29:28 CDT 2014
> On July 1, 2014, 12:14 p.m., Corey Farrell wrote:
> > /team/group/media_formats-reviewed-trunk/main/rtp_engine.c, lines 704-708
> > <https://reviewboard.asterisk.org/r/3687/diff/3/?file=61632#file61632line704>
> >
> > We need to remove from the vector. Also why not ao2_cleanup?
>
> Corey Farrell wrote:
> A related thought, maybe we need an AST_VECTOR_EXTRACT(vector, idx) to handle get + remove?
>
> Matt Jordan wrote:
> We don't need to remove from the vector. We are explicitly blowing away our reference to the item on the vector, then replacing it with a new item. No removal is necessary, as the item on the vector is just a pointer to the ao2 object.
>
> Matt Jordan wrote:
> Keep in mind that while we're doing this, we're holding the wrlock to the codecs. That means no one else can come around and snag the codec payload while we're swapping it out.
>
> Assuming the payload is in slot 3, you have:
>
> write lock
>
> - deref item in slot 3
> - build now item (slot 3 may be garbage here)
> - put new item into slot 3
>
> unlock
>
> If a consumer of the codecs had a reference to the payload type at slot 3, they're fine. The object will be valid until they release it. If they went to obtain the codecs in slot 3 while this operation occurred, they'd hit the write lock. Once the write lock was released, they'd get the new codec information in slot 3.
>
> Corey Farrell wrote:
> Not removing element at index 'payload' from the vector means it will point to a possibly destroyed ast_rtp_payload_type. Down a few lines in the code you are not "setting" element at index 'payload' to new_type, you are "inserting" new_type. So I think the end result would be:
> AST_VECTOR_GET(&codecs->payloads, payload) == new_type
> AST_VECTOR_GET(&codecs->payloads, payload + 1) == old_type (pointer to possibly freed object)
>
> Matt Jordan wrote:
> No, we are inserting at that particular location. Look at AST_VECTOR_INSERT:
>
> #define AST_VECTOR_INSERT(vec, idx, elem) ({ \
> int res = 0; \
> do { \
> if (((idx) + 1) > (vec)->max) { \
> size_t new_max = ((idx) + 1) * 2; \
> typeof((vec)->elems) new_elems = ast_calloc(1, \
> new_max * sizeof(*new_elems)); \
> if (new_elems) { \
> memcpy(new_elems, (vec)->elems, \
> (vec)->current * sizeof(*new_elems)); \
> ast_free((vec)->elems); \
> (vec)->elems = new_elems; \
> (vec)->max = new_max; \
> } else { \
> res = -1; \
> break; \
> } \
> } \
> (vec)->elems[(idx)] = (elem); \
> if (((idx) + 1) > (vec)->current) { \
> (vec)->current = (idx) + 1; \
> } \
> } while(0); \
> res; \
> })
>
> Specifically this part:
>
> (vec)->elems[(idx)] = (elem); \
> if (((idx) + 1) > (vec)->current) { \
> (vec)->current = (idx) + 1; \
> }
>
> The exact same index as the last element is set to the new element. This insert the new type at exactly the same position in the array as the old element.
>
> Unless I'm missing something...?
>
> Corey Farrell wrote:
> Maybe I should just do a better job reading the comments:
> * \warning This macro will overwrite anything already present at the position provided.
>
> Not exactly what I would call AST_VECTOR_INSERT, more like AST_VECTOR_SET with auto-expansion. Oh well you are right sorry!
No worries! I'm glad you did a thorough review of the changes in here, since I got a bit invasive in the rtp_engine.
- Matt
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3687/#review12402
-----------------------------------------------------------
On July 1, 2014, 12:43 p.m., Matt Jordan wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3687/
> -----------------------------------------------------------
>
> (Updated July 1, 2014, 12:43 p.m.)
>
>
> Review request for Asterisk Developers.
>
>
> Repository: Asterisk
>
>
> Description
> -------
>
> This patch started out as an attempt to fix the BUGBUGs left over packetization calls into rtp_engine; it got a little bit bigger. Things now compile and work (see Testing), so this is a good place to stop before the renaming effort.
>
> Primarily, this patch does the following:
> (1) Removes ast_rtp_codecs_packetization_set. This call was effectively a NoOp with res_rtp_asterisk/res_rtp_multicast. The various channel drivers now call ast_rtp_codecs_set_framing where appropriate.
> (2) A major overhaul of ast_rtp_codec was done. This includes:
> (a) Storing the framing on the structure. This allows for the smoother in res_rtp_asterisk to easily get the framing specified without having to do major gyrations.
> (b) Payload types (which are ao2 ref counted objects) are no longer stored in an ao2_container. This container had two patterns of usage: lookups by an integer key value and iteration. Vectors work well for this type of access and - for relatively small numbers of items (which is generally the case for payload types), are much faster on both counts.
> (3) The 'use_ptime' setting in res_pjsip_sdp_rtp now works. Packetization is also handled a little bit better, as both the RTP engine and format_cap API already do the job of managing the framing.
>
> A variety of ref leaks were cleaned up as well along the way.
>
>
> Diffs
> -----
>
> /team/group/media_formats-reviewed-trunk/tests/test_format_cap.c 417724
> /team/group/media_formats-reviewed-trunk/res/res_speech.c 417724
> /team/group/media_formats-reviewed-trunk/res/res_rtp_asterisk.c 417724
> /team/group/media_formats-reviewed-trunk/res/res_pjsip_sdp_rtp.c 417724
> /team/group/media_formats-reviewed-trunk/res/res_fax.c 417724
> /team/group/media_formats-reviewed-trunk/main/rtp_engine.c 417724
> /team/group/media_formats-reviewed-trunk/main/format_cap.c 417724
> /team/group/media_formats-reviewed-trunk/main/format.c 417724
> /team/group/media_formats-reviewed-trunk/include/asterisk/vector.h 417724
> /team/group/media_formats-reviewed-trunk/include/asterisk/rtp_engine.h 417724
> /team/group/media_formats-reviewed-trunk/include/asterisk/frame.h 417724
> /team/group/media_formats-reviewed-trunk/include/asterisk/format_cap.h 417724
> /team/group/media_formats-reviewed-trunk/include/asterisk/format.h 417724
> /team/group/media_formats-reviewed-trunk/formats/format_h264.c 417724
> /team/group/media_formats-reviewed-trunk/formats/format_h263.c 417724
> /team/group/media_formats-reviewed-trunk/channels/chan_skinny.c 417724
> /team/group/media_formats-reviewed-trunk/channels/chan_sip.c 417724
> /team/group/media_formats-reviewed-trunk/channels/chan_motif.c 417724
> /team/group/media_formats-reviewed-trunk/channels/chan_jingle.c 417724
> /team/group/media_formats-reviewed-trunk/channels/chan_iax2.c 417724
> /team/group/media_formats-reviewed-trunk/channels/chan_h323.c 417724
> /team/group/media_formats-reviewed-trunk/channels/chan_gtalk.c 417724
> /team/group/media_formats-reviewed-trunk/bridges/bridge_softmix.c 417724
> /team/group/media_formats-reviewed-trunk/bridges/bridge_native_rtp.c 417724
> /team/group/media_formats-reviewed-trunk/addons/ooh323cDriver.c 417724
> /team/group/media_formats-reviewed-trunk/addons/chan_ooh323.c 417724
>
> Diff: https://reviewboard.asterisk.org/r/3687/diff/
>
>
> Testing
> -------
>
> Back in February, I wrote a number of single audio stream tests for the PJSIP channel driver. Eventually these will get posted up for review, but the tests cover:
> * Basic Offer/Answer of different sets of codecs (using a variety of patterns, including allow=all (ew))
> * Packetization, including use_ptime=yes|no.
> * AVPF
> * Preferred codec only (by only specifying a single supported codec), subsets of offers, etc.
>
> These tests will eventually get put up on another review, but they gave some confidence that the mucking around in the rtp_engine that is done on this patch works.
>
>
> Thanks,
>
> Matt Jordan
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20140701/83e48ab3/attachment-0001.html>
More information about the asterisk-dev
mailing list