[asterisk-bugs] [JIRA] (ASTERISK-29455) Local channels (dialed using Originate dialplan application) play back gsm files over ulaw files when both exist

Friendly Automation (JIRA) noreply at issues.asterisk.org
Tue Nov 8 09:17:09 CST 2022


    [ https://issues.asterisk.org/jira/browse/ASTERISK-29455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=260600#comment-260600 ] 

Friendly Automation commented on ASTERISK-29455:
------------------------------------------------

Change 15953 merged by Friendly Automation:
translate.c: Prefer better codecs upon translate ties.

[https://gerrit.asterisk.org/c/asterisk/+/15953|https://gerrit.asterisk.org/c/asterisk/+/15953]

> Local channels (dialed using Originate dialplan application) play back gsm files over ulaw files when both exist
> ----------------------------------------------------------------------------------------------------------------
>
>                 Key: ASTERISK-29455
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-29455
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Codecs/General
>    Affects Versions: 18.4.0
>            Reporter: N A
>            Assignee: N A
>              Labels: patch
>         Attachments: translate.diff
>
>
> Strange issue with codec conversion that I noticed today. Despite the translation costs of slin192 <-> ulaw and slin192 <-> gsm being identical, an slin192 will pick a gsm audio file if both a gsm and ulaw candidate exist for a specific file. It plays ulaw files correctly if there isn't a candidate (same name) gsm file.
> The correct behavior should be that ulaw is preferred over gsm, since the costs are identical, and ulaw is the higher quality codec, and being both uncompressed and raw audio, closer to slin format than gsm would be. Yet, it falls back to the lower quality codec for some reason which seems arbitrary.
> An analysis of the ast_translator_build_path() function in channel.c along with DEBUG messages confirms the problem occurs here, and likely the actual bug lies with the ast_translator_best_choice function in translate.c.
> It appears this function looks only at translation costs and the choice between two codecs can be arbitrary if costs are identical.



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



More information about the asterisk-bugs mailing list