Re: [asterisk-dev] A thread for format work

2014-04-30 Thread Joshua Colp
For those following along at home, I've put my last pending work up for review for media formats. You can find it on Reviewboard[1] by looking at the title. Anything prefixed with media_formats is it! (My kingdom for proper tags). Note that this doesn't complete things but is merely stuff I ha

Re: [asterisk-dev] A thread for format work

2014-04-30 Thread Joshua Colp
Matthew Jordan wrote: How so? The current design calls for a public function that accepts a const char *key and a const char *value. The key and value are always going to be presented to the core as text (inbound SDP), and typically will

Re: [asterisk-dev] A thread for format work

2014-04-30 Thread Matthew Jordan
On Wed, Apr 30, 2014 at 8:00 AM, Joshua Colp wrote: > Matthew Jordan wrote: > >> >> On Wed, Apr 30, 2014 at 5:59 AM, Joshua Colp > > wrote: >> >> Matthew Jordan wrote: >> >> >> > > > >> >> If we allow attributes to be set after format creation, we have two >> options

Re: [asterisk-dev] A thread for format work

2014-04-30 Thread Joshua Colp
Matthew Jordan wrote: On Wed, Apr 30, 2014 at 5:59 AM, Joshua Colp mailto:jc...@digium.com>> wrote: Matthew Jordan wrote: If we allow attributes to be set after format creation, we have two options: (1) We make formats mutable, and all the badness that entails. (2) Setting a form

Re: [asterisk-dev] A thread for format work

2014-04-30 Thread Matthew Jordan
On Wed, Apr 30, 2014 at 5:59 AM, Joshua Colp wrote: > Matthew Jordan wrote: > >> >> > > :: Setting Attributes :: >> >> The biggest sticky point is clearly #1. I don't think we should lose the >> immutability convention - that feels bad, since there's a lot of benefit >> to treating a format as

Re: [asterisk-dev] A thread for format work

2014-04-30 Thread Joshua Colp
Matthew Jordan wrote: bridge_native_rtp up for review. One down, three hundred to go... But onward anyway. Next on the "list": format attributes! The new specification calls for setting attributes using ast_format_set_attr, which takes in a key/value pair along with the format to set the attri

Re: [asterisk-dev] A thread for format work

2014-04-29 Thread Matthew Jordan
bridge_native_rtp up for review. One down, three hundred to go... But onward anyway. Next on the "list": format attributes! The new specification calls for setting attributes using ast_format_set_attr, which takes in a key/value pair along with the format to set the attribute on. While this seems

Re: [asterisk-dev] A thread for format work

2014-04-29 Thread Joshua Colp
Matthew Jordan wrote: So something like: read_ptime0 = ast_format_cap_get_framing(cap0, ast_channel_rawreadformat(c0->chan)); read_ptime1 = ast_format_cap_get_framing(cap1, ast_channel_rawreadformat(c1->chan)); write_ptime0 = ast_format_cap_get_framing(cap0, ast_channel_rawwri

Re: [asterisk-dev] A thread for format work

2014-04-29 Thread Matthew Jordan
On Tue, Apr 29, 2014 at 6:55 AM, Joshua Colp wrote: > Matthew Jordan wrote: > > > > > >> >> >> The ability to set the framing per-format, globally in a >> capabilities structure, and to get the framing already exists. What >> doesn't exist is adding a format and then setting the fr

Re: [asterisk-dev] A thread for format work

2014-04-29 Thread Joshua Colp
Matthew Jordan wrote: The ability to set the framing per-format, globally in a capabilities structure, and to get the framing already exists. What doesn't exist is adding a format and then setting the framing as two separate API calls. That is something that could be added b

Re: [asterisk-dev] A thread for format work

2014-04-29 Thread Matthew Jordan
On Tue, Apr 29, 2014 at 6:49 AM, Matthew Jordan wrote: > > On Tue, Apr 29, 2014 at 6:15 AM, Joshua Colp wrote: > > > > >> >> The ability to set the framing per-format, globally in a capabilities >> structure, and to get the framing already exists. What doesn't exist is >> adding a format and

Re: [asterisk-dev] A thread for format work

2014-04-29 Thread Matthew Jordan
On Tue, Apr 29, 2014 at 6:15 AM, Joshua Colp wrote: > Matthew Jordan wrote: > >> >> (1) Where will the packetization of a format on a channel reside? With >> the format on the channel? Or with the capability of the channel? >> > > It "has" to reside in the RTP engine layer and optionally can (but

Re: [asterisk-dev] A thread for format work

2014-04-29 Thread Joshua Colp
Matthew Jordan wrote: Like a normal person, I decided to poke at the format work while watching tornadoes track North and South of Huntsville (because really, what else are you going to do?) After looking through Josh's notes on the wiki [1] and the code in the team branch [2], I decided to tackl

[asterisk-dev] A thread for format work

2014-04-28 Thread Matthew Jordan
Like a normal person, I decided to poke at the format work while watching tornadoes track North and South of Huntsville (because really, what else are you going to do?) After looking through Josh's notes on the wiki [1] and the code in the team branch [2], I decided to tackle bridge_native_rtp (as