[asterisk-dev] Transcoding: Codec 2, iLBC 20, SILK, GSM-EFR, AMR(-WB)

[Alexander Traud]

>> 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?