> 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 > >
-- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
