>> Question #1: Level of Integration? >> [x] [x] [ ] GSM-EFR; GSM-FR is available already > More analysis would have to be done for a codec module.
GSM-EFR uses the same library as AMR. Therefore, it is the same situation. >> Question #2: Format-attribute Keys as Header Files? > format_attribute_set was implemented as a way to set arbitrary attributes > in a format module. I wouldn't remove that API call, I am not about removing that API, I am more about: Do I have to and for whom should I implement that API? Currently, that API is not implemented in my modules. I am just asking before it gets rejected in code-review just because of that. >> Question #3: Module Loading Priority >> H.26x modules load very late (AST_MODPRI_DEFAULT). The Opus Codec module >> loads very early (AST_MODPRI_CHANNEL_DEPEND). Which one is correct? Or are >> both and there is a reason why video modules load later than audio modules? > So long as the core 'understand' that the format may exist, > AST_MODPRI_DEFAULT is fine. I would imagine that AST_MODPRI_CHANNEL_DEPEND > would only be necessary if it needed to register itself with the codec core. Channels do create copies of formats. When a format-attribute module is not loaded, then copies of the format do not have an attribute attached. This is fixed later on in the channels, by searching each time. However, I wonder why some format-attribute modules are loaded (too) late and some not. Or should I just change all the existing module to AST_MODPRI_CHANNEL_DEPEND, create a review and wait what happens (abandoned, rejected, or committed)? I am still not sure what is easier for the team: Pre-ask on the mailing list or going through issue-report/code-review. >> Question #4: Orphan Format-attribute module CELT > you can have pass through support with the format modules - you don't need > necessarily need a format module to pass media from one channel through a > bridge to another, the core merely has to know that the format exists. That > also explains why the media format attribute modules exist - they provide > assistance during negotiation. Yes, format-attribute modules are required only for supporting the line 'fmtp' in SDP negotiation. However since Asterisk 13, both SILK and CELT are not available, even not as pass-through. Therefore currently, these format-attribute modules are orphan modules. > SILK and CELT have commercial but free modules offered by Digium - although > due to time constraints, versions of those modules have not been released > for Asterisk 13. Thanks for the stars given on GitHub. It is most appreciated. You have not given a star for my SILK modules: <https://github.com/traud/asterisk-silk>. Perhaps it got overlooked. Because you mention time constraints, SILK was not dropped on purpose, I guess. Therefore, is the Asterisk Team interested in pass-through support for SILK as well? By the way, are all these new modules just for master, or is there any chance to submit them for branch 13, too? -- _____________________________________________________________________ -- 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
