[asterisk-bugs] [JIRA] (ASTERISK-25353) [patch] Transcoding while different in Frame size = Frames lost

[Asterisk Team (JIRA)]

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

Asterisk Team closed ASTERISK-25353.
------------------------------------


> [patch] Transcoding while different in Frame size = Frames lost
> ---------------------------------------------------------------
>
>                 Key: ASTERISK-25353
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-25353
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Codecs/General
>    Affects Versions: SVN, 11.19.0, 13.5.0
>            Reporter: Alexander Traud
>
> For example, when Asterisk transcodes from audio-codec iLBC 30 to the audio-codec Speex16, lintospeex_frameout is called twice, with 480 samples each = 960. This should create three frames, with 320 samples each. However, Asterisk sends one small frame (320 samples) and one big frame (640 samples) on the wire.
> I noticed this issue while testing my AMR-WB transcoding module. AMR-WB uses the same amount of samples as Speex16: Two frames are transcoded into one correct frame, and one incorrect double-size frame on the wire. However with AMR, a frame with the wrong byte length MUST be ignored. Therefore, the transcoding destroyed two third of the samples. Only one third was OK. Therefore, the voice was robotic on the AMR side. AMR -> iLBC "sounded" OK. By the way, the same happens for Speex8 and AMR-NB (8000 Hz). Consequently, this issue is not related to 8000 Hz <-> 16000 Hz.
> The attached patch fixes ast_translate to tag additional frames with the correct delivery time, as expected by main/channel.c:ast_write (see comments there). Furthermore, the patch advances the predicted delivery-time accordingly. This patch does not have any side-effect on current source code because no codecs/codec_XXX.c is returning several frames, yet.
> This issue was not reproducible for transcodings which use default_frameout, like G.711 and G.722. Therefore, I fixed all transcodings which use ast_trans_frameout: GSM, iLBC, LPC10, and Speex. I tested GSM, Speex8, Speex16, Speex32, and iLBC. Now, those create constant amount of samples on the wire (no normal+big frames anymore). However, I was not able to test LPC10 because I do not have a 3rd-party device to double-check.



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