> 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 > >
-- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
