[asterisk-dev] [Code Review] 2723: Add pass through support for both VP8 and Opus

Matt Jordan reviewboard at asterisk.org
Thu Aug 22 10:39:01 CDT 2013



> On Aug. 20, 2013, 11:10 a.m., Joshua Colp wrote:
> > /trunk/channels/chan_sip.c, line 12855
> > <https://reviewboard.asterisk.org/r/2723/diff/4/?file=44220#file44220line12855>
> >
> >     As the max packet size is a combination of all formats involved it should be the *lowest* not the highest.
> 
> Matt Jordan wrote:
>     I was thinking that what you were informing the remote endpoint was the largest packet size you may send them, which would be the highest of all of the combined formats. 
>     
>     {quote}
>           a=maxptime:<maximum packet time>
>     
>              This gives the maximum amount of media that can be encapsulated
>              in each packet, expressed as time in milliseconds. 
>     {quote}
>     
>     Wouldn't we want to tell the endpoints that amongst codecs A, B, and C, the largest packet size is max(A,B,C), not min(A,B,C)?
> 
> Joshua Colp wrote:
>     Messy attribute is messy. Since this applies to all codecs at media level if I am using codec A which has a max of 60ms and codec B which has a max of 120ms then if codec A is used the maximum amount of media we accept that can be encapsulated is not 120ms, it's 60ms. Now... would the Asterisk core actually CARE if we received 120ms? Probably not. That's my thinking.
> 
> Matt Jordan wrote:
>     Works for me.
> 
> Matt Jordan wrote:
>     FYI: in res_pjsip_sdp_rtp, the code that checks for min_packet_size is incorrect:
>     
>     			if (fmt.cur_ms && ((fmt.cur_ms < min_packet_size) || !min_packet_size)) {
>     				min_packet_size = fmt.cur_ms;
>     			}
>     
>     min_packet_size is always 0 at this point. That will result in us always setting min_packet_size to fmt.cur_ms if fmt.cur_ms is non-zero, which is probably not what we want. I'm removing the !min_packet_size check there.
> 
> Joshua Colp wrote:
>     Removing that isn't correct, as it will then never get set. If no min packet size has been set (it's 0) then this format's is used. On the next format if the min packet size is smaller, then it is updated.

Bah. I thought I removed that before I hit publish.

Yeah, that's totally wrong.


- Matt


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


On Aug. 19, 2013, 11:05 p.m., Matt Jordan wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/2723/
> -----------------------------------------------------------
> 
> (Updated Aug. 19, 2013, 11:05 p.m.)
> 
> 
> Review request for Asterisk Developers, Joshua Colp and Mark Michelson.
> 
> 
> Bugs: ASTERISK-21981
>     https://issues.asterisk.org/jira/browse/ASTERISK-21981
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> Note: This patch was written by Lorenzo Miniero. I know he's at the IETF this week, but I figured we could get the formal code review going for him :-)
> 
> This patch adds pass through support for Opus and VP8. That includes:
> * Format attribute negotiation for Opus. Note that unlike some other codecs, the draft RFC specifies having spaces delimiting the attributes in addition to ';', so you have "attra=X; attrb=Y". This broke the attribute parsing in chan_sip, so a small tweak was also included in this patch for that.
> * A format attribute negotiation module for Opus
> * Fast picture update for VP8. Since VP8 uses a different RTCP packet number than FIR, this really is specific to VP8 at this time. Ideally this would be more generic and flexible for user preferences and other video codecs, but that could be done at a latter date.
> 
> The only part of this work that I did was port over the fast picture update code to chan_pjsip. I *think* that chan_pjsip will still suck out the attributes in res_pjsip_sdp_rtp, but I could be mistaken (Josh?)
> 
> 
> Diffs
> -----
> 
>   /trunk/channels/chan_pjsip.c 396942 
>   /trunk/channels/chan_sip.c 396942 
>   /trunk/include/asterisk/format.h 396942 
>   /trunk/include/asterisk/opus.h PRE-CREATION 
>   /trunk/main/channel.c 396942 
>   /trunk/main/format.c 396942 
>   /trunk/main/frame.c 396942 
>   /trunk/main/rtp_engine.c 396942 
>   /trunk/res/res_format_attr_opus.c PRE-CREATION 
>   /trunk/res/res_pjsip_sdp_rtp.c 396942 
>   /trunk/res/res_rtp_asterisk.c 396942 
> 
> Diff: https://reviewboard.asterisk.org/r/2723/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Matt Jordan
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20130822/94488440/attachment-0001.htm>


More information about the asterisk-dev mailing list