[asterisk-dev] [Code Review] 3687: media format improvements: Update packetization handling; improve rtp_engine's ast_rtp_codecs handling

[Corey Farrell]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3687/#review12393
-----------------------------------------------------------


I have not yet reviewed rtp_engine.c - that one will take a bit more time.


/team/group/media_formats-reviewed-trunk/channels/chan_sip.c
<https://reviewboard.asterisk.org/r/3687/#comment22606>

    Why switch these to be undefined values?



/team/group/media_formats-reviewed-trunk/formats/format_h263.c
<https://reviewboard.asterisk.org/r/3687/#comment22605>

    I know this existed before, but magic numbers are bad.  This 0x8000 (whatever it means) is used in a couple places, would be better to have a #define.



/team/group/media_formats-reviewed-trunk/include/asterisk/rtp_engine.h
<https://reviewboard.asterisk.org/r/3687/#comment22604>

    This should be considered for rename.. maybe ast_rtp_codecs_get_payload.  Reason I'm suggesting is because the parameters are not changed but the return is, so it's (in theory) possible for the compiler to allow old/unmodified code.
    
    Also "\since 1.8" is now a lie, this is not the same procedure it was.



/team/group/media_formats-reviewed-trunk/main/format_cap.c
<https://reviewboard.asterisk.org/r/3687/#comment22602>

    I'd rather this be condensed:
    cap->framing = MIN(cap->framing, framing ? framing : ast_format_get_default_ms(format));
    
    Not marked as an issue, you're call if you want to ignore this.



/team/group/media_formats-reviewed-trunk/res/res_rtp_asterisk.c
<https://reviewboard.asterisk.org/r/3687/#comment22601>

    This new equation doesn't look right.  Should be dividing by ast_format_get_minimum_ms, not ast_format_get_default_ms.


- Corey Farrell


On June 29, 2014, 12:31 a.m., Matt Jordan wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3687/
> -----------------------------------------------------------
> 
> (Updated June 29, 2014, 12:31 a.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 417585 
>   /team/group/media_formats-reviewed-trunk/res/res_speech.c 417585 
>   /team/group/media_formats-reviewed-trunk/res/res_rtp_asterisk.c 417585 
>   /team/group/media_formats-reviewed-trunk/res/res_pjsip_sdp_rtp.c 417585 
>   /team/group/media_formats-reviewed-trunk/res/res_fax.c 417585 
>   /team/group/media_formats-reviewed-trunk/main/rtp_engine.c 417585 
>   /team/group/media_formats-reviewed-trunk/main/format_cap.c 417585 
>   /team/group/media_formats-reviewed-trunk/main/format.c 417585 
>   /team/group/media_formats-reviewed-trunk/include/asterisk/vector.h 417585 
>   /team/group/media_formats-reviewed-trunk/include/asterisk/rtp_engine.h 417585 
>   /team/group/media_formats-reviewed-trunk/include/asterisk/frame.h 417585 
>   /team/group/media_formats-reviewed-trunk/include/asterisk/format_cap.h 417585 
>   /team/group/media_formats-reviewed-trunk/include/asterisk/format.h 417585 
>   /team/group/media_formats-reviewed-trunk/formats/format_h264.c 417585 
>   /team/group/media_formats-reviewed-trunk/formats/format_h263.c 417585 
>   /team/group/media_formats-reviewed-trunk/channels/chan_skinny.c 417585 
>   /team/group/media_formats-reviewed-trunk/channels/chan_sip.c 417585 
>   /team/group/media_formats-reviewed-trunk/channels/chan_motif.c 417585 
>   /team/group/media_formats-reviewed-trunk/channels/chan_jingle.c 417585 
>   /team/group/media_formats-reviewed-trunk/channels/chan_iax2.c 417585 
>   /team/group/media_formats-reviewed-trunk/channels/chan_h323.c 417585 
>   /team/group/media_formats-reviewed-trunk/channels/chan_gtalk.c 417585 
>   /team/group/media_formats-reviewed-trunk/bridges/bridge_softmix.c 417585 
>   /team/group/media_formats-reviewed-trunk/bridges/bridge_native_rtp.c 417585 
>   /team/group/media_formats-reviewed-trunk/addons/ooh323cDriver.c 417585 
>   /team/group/media_formats-reviewed-trunk/addons/chan_ooh323.c 417585 
> 
> 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/20140630/fa25578e/attachment-0001.html>