Summary: | ASTERISK-16633: [patch] downsampling slinear16 to slinear (or ulaw or alaw or g729) results in truncation | ||
Reporter: | Paul Albrecht (palbrecht) | Labels: | |
Date Opened: | 2010-08-31 13:33:19 | Date Closed: | 2017-12-14 10:25:21.000-0600 |
Priority: | Minor | Regression? | No |
Status: | Closed/Complete | Components: | Codecs/General |
Versions: | Frequency of Occurrence | ||
Related Issues: | |||
Environment: | Attachments: | ( 0) test_translate.c | |
Description: | When I translate from AST_FORMAT_SLINEAR16 to AST_FORMAT_SLINEAR the output frame is truncated, specifically, instead of 160 samples I get 137 samples. The result is the same for ulaw and alaw. For g729, the output is truncated to 80 samples. ****** ADDITIONAL INFORMATION ****** Here's how I initialize the frame I use for translation: static struct ast_frame f; static unsigned char data[AST_FRIENDLY_OFFSET + 640]; f.data.ptr = (void *)(data + AST_FRIENDLY_OFFSET); f.frametype = AST_FRAME_VOICE; f.subclass = AST_FORMAT_SLINEAR16; f.samples = 320; f.offset = AST_FRIENDLY_OFFSET; f.datalen = 640; Here's how I translate the frame: trans = ast_translator_build_path(AST_FORMAT_SLINEAR,AST_FORMAT_SLINEAR16); out = ast_translate(trans,f,0) Here's how I log the result: ast_log( LOG_NOTICE, "my output frame: subclass %d, samples %d, offset %d, datalen %d\n", out->subclass, out->samples, out->offset,out->datalen) ; | ||
Comments: | By: Leif Madsen (lmadsen) 2010-08-31 13:48:45 Here is the original thread: http://lists.digium.com/pipermail/asterisk-dev/2010-August/045945.html By: Russell Bryant (russell) 2010-08-31 14:17:09 I wrote a small unit test module to test this out and was able to reproduce it. The output frame has 137 samples every time. By: Russell Bryant (russell) 2010-08-31 14:25:14 Also, just as a note, in my case, I have codec_resample loaded and it's using that as the translation path. Results may be different if that module is not loaded, and translation goes through codec_g722. By: Jason Parker (jparker) 2010-08-31 17:43:26 so, I reversed that test, just because, and it's also wrong (it upconverted via g722 first, so I had to remove that). Perhaps not very useful, but... slin16>slin is off by 23 samples (160 - 137) slin>slin16 is off by 56 samples (320 - 264) obvious note: 56 is not 23 * 2 By: Alexander Traud (traud) 2017-11-27 08:42:40.883-0600 Mhm. Found this issue by browsing. I am not able to reproduce with my Asterisk 13.18. For me, the amount of samples were fine in both directions. Furthermore, nobody watches this issue anymore. [~russell], is is possible to get a copy of your unit test? By: Sean Bright (seanbright) 2017-12-14 10:25:21.302-0600 Per [~traud], this is no longer reproducible with the latest Asterisk 13 release. |