[asterisk-bugs] [JIRA] (ASTERISK-25535) [patch] format creation on module load instead of cache

[Alexander Traud (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-25535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexander Traud updated ASTERISK-25535:
---------------------------------------

    Reviewboard Link: https://gerrit.asterisk.org/1589

> [patch] format creation on module load instead of cache
> -------------------------------------------------------
>
>                 Key: ASTERISK-25535
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-25535
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Formats/General
>            Reporter: Alexander Traud
>            Severity: Minor
>         Attachments: capability_cached_format.patch
>
>
> Since Asterisk 13, formats are cached to speed up various comparisons. However still, each module gets its own struct, because of
> {{ast_format_cap_append_by_type}} and
> {{ast_format_cap_update_by_allow_disallow}}.
> I tested the module {{chan_sip}} and see no reason for this behaviour. Beside performance, the current behaviour does not indicate whether I deal with a cached format or one created because of {{ast_format_clone}} in a res/res_format_attr_* like the one for H.263, H.264, or Opus. Currently, around five or six new format structs are created per connection.
> Furthermore, this change is required to solve ASTERISK-25160 (with patch B): The format attribute modules are created *after* the channel modules. Therefore, the unique formats of each channel do not have a format attribute module attached. Therefore, they do not parse/compare/join the SIP/SDP line {{fmtp}}. This is required for transcoding modules not yet included in the Asterisk project like [iLBC 20|https://github.com/traud/asterisk-ilbc], [SILK|https://github.com/traud/asterisk-silk], [AMR|https://github.com/traud/asterisk-amr], and (one day) [Opus|https://github.com/traud/asterisk-opus].
> Question to the Asterisk team:
> The proposed patch does not avoid every new creation, for example those formats with the same name but different bitrates like sln16 and speex16. By the way, I played around with several bitrates in my AMR module and did not find any benefit (beside this drawback). Please, re-iterate which code section(s) do benefit from this.
> Although currently incomplete for pathologic cases (sln and speex do not have a res_format_attr) please, still consider this change for inclusion in Asterisk 13.



--
This message was sent by Atlassian JIRA
(v6.2#6252)