[asterisk-dev] [Code Review] 3665: media_formats: Core updates, plus format_cache/channel/and some other stuff

Matt Jordan reviewboard at asterisk.org
Mon Jun 23 13:10:15 CDT 2014 


> On June 23, 2014, 12:10 a.m., Corey Farrell wrote:
> > /team/group/media_formats-reviewed/main/codec.c, line 87
> > <https://reviewboard.asterisk.org/r/3665/diff/3/?file=60235#file60235line87>
> >
> >     Why?
> 
> Matt Jordan wrote:
>     Because there are times when a user wants to look up a codec by name only, and we currently don't have a mechanism to do that.
>     
>     Take, for example, "Opus". If I perform a 'core show translation path opus', it will fail without this check. Without providing the sample rate, we don't get a hit on the codec. The fact that Opus only has a single sample rate doesn't matter. We can't really infer what we should provide the lookup from the CLI command either.
>     
>     I think forcing the sample rate is a little pessimistic: 90% of the time, you don't need to provide a sample rate to find the codec you're looking for. If you do have to provide the sample rate, this comparison function will still work: it will match on the sample rate as well if you provide it (and if you provide a sample rate and there is no codec that matches, it will return NULL as well).
> 
> Corey Farrell wrote:
>     What about situations where multiple sample rate's exist for a codec?  This seems to be related to my question about completion for sample rate's from the CLI command.
> 
> Matt Jordan wrote:
>     Yes, it is explicitly for that.
>     
>     If a codec (such as slin) has multiple sample rates and you fail to specify what you want, it will return back the first one that has a matching name. You didn't specify what you wanted, and you got the first match :-P

For now, I'll put a BUGBUG here as well. We should review whether or not this is necessary when we deal with the BUGBUG in translate.c.


> On June 23, 2014, 12:10 a.m., Corey Farrell wrote:
> > /team/group/media_formats-reviewed/include/asterisk/format_cache.h, lines 280-281
> > <https://reviewboard.asterisk.org/r/3665/diff/3/?file=60232#file60232line280>
> >
> >     If SLIN is an acronym for signed, abbreviation for linear (S. lin), then it's "an" SLIN format.  a/an is used based on the immediate next sound, like an FBI agent or a Federal Agent.
> >     
> >     On the other hand maybe I've been pronouncing slin wrong and it actually sounds similar to slim?
> 
> Matt Jordan wrote:
>     Boy, I have no idea! When I read 'SLIN' in my head, I always read it the full way - 'Signed Linear'. So 'a Signed Linear format' - in my head at any rate - is "sounds" correct.
>     
>     But I'm fine with 'an' as well.
>     
>     Anyone else have any objections?

I'll just change it to 'an' :-)


- Matt


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


On June 23, 2014, 9:51 a.m., Matt Jordan wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3665/
> -----------------------------------------------------------
> 
> (Updated June 23, 2014, 9:51 a.m.)
> 
> 
> Review request for Asterisk Developers, Corey Farrell and Joshua Colp.
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> This patch includes all of Corey's fine work on r3625, more that he did in channel/rtp_engine/dsp, and enough work in format_cache/elsewhere to get Asterisk's core to compile, along with some improvements in translate.
> 
> With this patch, Asterisk (with very little loaded) should run and generally display the codec path translations. I'm still not convinced we're computing computational complexity correctly for everything - particularly translations provided by codec_resample - but the table produced matches Asterisk 11/12, so that's a good step.
> 
> Major changes made in this patch:
> * Removed ast_best_codec, as it was a farce [1]. All channel drivers will now use the first codec listed in their configured set of codecs as their preferred codec.
> * Formats now store their name, as it can differ from the codec. This now has the accessor ast_format_get_name; codecs get the new ast_format_get_codec_name. Similarly, formats can now be constructed either entirely from the codec, or from a codec + name.
> * Updated the format_cache with the expected short-hand pointers to the cached formats.
> * channel.c was updated. That's large. Note that this was done mostly by Corey Farrell
> * Codecs can do an explicit name match without their sample rate. This is done to make it a bit easier for CLI commands to query codecs with singular but odd sample rates (looking at you Opus)
> * CLI commands in translate.c should now mostly work. translate.c will now correctly register translation paths - previously, it used the passed in codecs, which did not contain the codec->id field.
> 
> 
> [1] http://lists.digium.com/pipermail/asterisk-dev/2014-June/068133.html
> 
> 
> Diffs
> -----
> 
>   /team/group/media_formats-reviewed/tests/test_format_cache.c 417074 
>   /team/group/media_formats-reviewed/res/res_pjsip_sdp_rtp.c 417074 
>   /team/group/media_formats-reviewed/main/translate.c 417074 
>   /team/group/media_formats-reviewed/main/slinfactory.c 417074 
>   /team/group/media_formats-reviewed/main/rtp_engine.c 417074 
>   /team/group/media_formats-reviewed/main/frame.c 417074 
>   /team/group/media_formats-reviewed/main/format_cap.c 417074 
>   /team/group/media_formats-reviewed/main/format_cache.c 417074 
>   /team/group/media_formats-reviewed/main/format.c 417074 
>   /team/group/media_formats-reviewed/main/dsp.c 417074 
>   /team/group/media_formats-reviewed/main/core_unreal.c 417074 
>   /team/group/media_formats-reviewed/main/codec_builtin.c 417074 
>   /team/group/media_formats-reviewed/main/codec.c 417074 
>   /team/group/media_formats-reviewed/main/channel.c 417074 
>   /team/group/media_formats-reviewed/main/asterisk.c 417074 
>   /team/group/media_formats-reviewed/include/asterisk/rtp_engine.h 417074 
>   /team/group/media_formats-reviewed/include/asterisk/format_cache.h 417074 
>   /team/group/media_formats-reviewed/include/asterisk/format.h 417074 
>   /team/group/media_formats-reviewed/include/asterisk/channel.h 417074 
>   /team/group/media_formats-reviewed/include/asterisk/astobj2.h 417074 
>   /team/group/media_formats-reviewed/include/asterisk/_private.h 417074 
>   /team/group/media_formats-reviewed/channels/chan_unistim.c 417074 
>   /team/group/media_formats-reviewed/channels/chan_skinny.c 417074 
>   /team/group/media_formats-reviewed/channels/chan_sip.c 417074 
>   /team/group/media_formats-reviewed/channels/chan_phone.c 417074 
>   /team/group/media_formats-reviewed/channels/chan_multicast_rtp.c 417074 
>   /team/group/media_formats-reviewed/channels/chan_misdn.c 417074 
>   /team/group/media_formats-reviewed/channels/chan_mgcp.c 417074 
>   /team/group/media_formats-reviewed/channels/chan_jingle.c 417074 
>   /team/group/media_formats-reviewed/channels/chan_iax2.c 417074 
>   /team/group/media_formats-reviewed/channels/chan_h323.c 417074 
>   /team/group/media_formats-reviewed/channels/chan_gtalk.c 417074 
>   /team/group/media_formats-reviewed/addons/chan_ooh323.c 417074 
> 
> Diff: https://reviewboard.asterisk.org/r/3665/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Matt Jordan
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20140623/96a96a55/attachment.html>

More information about the asterisk-dev mailing list