[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:comment-tabpanel&focusedCommentId=227402#comment-227402 ] 

Asterisk Team commented on ASTERISK-25353:
------------------------------------------

Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution.

A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report.

Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process].

> [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)