On Wed, Apr 30, 2014 at 5:59 AM, Joshua Colp jc...@digium.com wrote:
Matthew Jordan wrote:
snip
:: 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
Matthew Jordan wrote:
On Wed, Apr 30, 2014 at 5:59 AM, Joshua Colp jc...@digium.com
mailto:jc...@digium.com wrote:
Matthew Jordan wrote:
snip
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.
On Wed, Apr 30, 2014 at 8:00 AM, Joshua Colp jc...@digium.com wrote:
Matthew Jordan wrote:
On Wed, Apr 30, 2014 at 5:59 AM, Joshua Colp jc...@digium.com
mailto:jc...@digium.com wrote:
Matthew Jordan wrote:
snip
If we allow attributes to be set after format creation, we have two
Matthew Jordan wrote:
snip
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
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
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
On Tue, Apr 29, 2014 at 6:15 AM, Joshua Colp jc...@digium.com 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
On Tue, Apr 29, 2014 at 6:49 AM, Matthew Jordan mjor...@digium.com wrote:
On Tue, Apr 29, 2014 at 6:15 AM, Joshua Colp jc...@digium.com wrote:
snip
The ability to set the framing per-format, globally in a capabilities
structure, and to get the framing already exists. What doesn't exist
Matthew Jordan wrote:
snip
snip
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
On Tue, Apr 29, 2014 at 6:55 AM, Joshua Colp jc...@digium.com wrote:
Matthew Jordan wrote:
snip
snip
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
Matthew Jordan wrote:
snip
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,
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
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
13 matches
Mail list logo
