faac内存开销较大,为方便嵌入式设备使用进行优化(valgrind使用)

这篇具有很好参考价值的文章主要介绍了faac内存开销较大,为方便嵌入式设备使用进行优化(valgrind使用)。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

faac内存开销较大,为方便嵌入式设备使用进行优化,在github上提了issues但是没人理我,所以就搞一份代码自己玩吧。 基于faac_1_30版本,原工程https://github.com/knik0/faac

faac内存优化: faac内存开销较大,为方便嵌入式设备使用进行优化,在github上提了issues但是没人理我,所以就搞一份代码自己玩吧。基于faac_1_30版本,原工程https://github.com/knik0/faac

https://gitee.com/dma/faac-memory-optimization?_from=gitee_search

说明

faac内存开销较大,为方便嵌入式设备使用进行优化,在github上提了issues但是没人理我,所以就搞一份代码自己玩吧。
基于faac_1_30版本,原工程 https://github.com/knik0/faac

文件说明

  • faac-1_30.zip 为 faac 源码
  • 为了方便我个人使用,删除了 faac 源码中我用不到的文件,只保留 libfaac 目录下的必要文件和 inlcude 目录
  • 增加 CMakeLists.txt 编译脚本

内存优化的内容

内存优化测试文件的格式为 PCM int16 小端 双声道 44100Hz

1.1 优化前

使用 valgrind 检查内存,结果如下,可以看到默认配置的内存开销约为 11.5 MB

faac内存开销较大,为方便嵌入式设备使用进行优化(valgrind使用),Android性能优化,github,驱动开发

1.2 修改默认最大声道数

修改 libfaac\coder.h
一般来说,双声道就够用了,如果有5.1声道之类的特殊需求可以自行修改

修改前
#define MAX_CHANNELS 64
修改后
#define MAX_CHANNELS 2

内存统计如下,约 560 KB

faac内存开销较大,为方便嵌入式设备使用进行优化(valgrind使用),Android性能优化,github,驱动开发

1.3 删除 bwpInfo

修改 libfaac\coder.h
faacEncOpen() 中会创建 faacEncStruct* hEncoder; 这个句柄
faacEncStruct.coderInfo 中的 bwpInfo 代码中没有用到,不知道作者为什么没有删除,意义不明。

修改前
BwpInfo bwpInfo;
修改后
// BwpInfo bwpInfo;

内存统计如下,约 240 KB

faac内存开销较大,为方便嵌入式设备使用进行优化(valgrind使用),Android性能优化,github,驱动开发

1.4 删除无效代码

修改 libfaac\frame.c faacEncEncode() 的代码中有这样一段

hEncoder->sampleBuff[channel]		= hEncoder->nextSampleBuff[channel];
hEncoder->nextSampleBuff[channel]	= hEncoder->next2SampleBuff[channel];
hEncoder->next2SampleBuff[channel]	= hEncoder->next3SampleBuff[channel];
hEncoder->next3SampleBuff[channel]	= tmp;

申请了4个 sampleBuff,这个函数每调用一次会依次交换这4个 buffer,实际代码中只用到了 sampleBuffnext3SampleBuff,不明白作者为什么这样写,也可能是忘了删,这里可以修改为

hEncoder->sampleBuff[channel]		= hEncoder->next3SampleBuff[channel];
hEncoder->next3SampleBuff[channel]	= tmp;

以下几处记得也要一起修改

faacEncOpen() 中修改为

// hEncoder->nextSampleBuff[channel] = NULL;
// hEncoder->next2SampleBuff[channel] = NULL;

faacEncClose() 中修改为

// if (hEncoder->nextSampleBuff[channel])
//   FreeMemory(hEncoder->nextSampleBuff[channel]);
// if (hEncoder->next2SampleBuff[channel])
//   FreeMemory (hEncoder->next2SampleBuff[channel]);

faacEncStruct 中修改为

// double *nextSampleBuff[MAX_CHANNELS];
// double *next2SampleBuff[MAX_CHANNELS];

这样每声道可以节约 16KB 内存

内存统计如下,约 210 KB

faac内存开销较大,为方便嵌入式设备使用进行优化(valgrind使用),Android性能优化,github,驱动开发

1.5 优化数据结构

修改 libfaac\coder.h
这有个前提条件,就是不启用 DRM,这个宏在 libfaac\coder.h,默认就是关闭的
//#define DRM

接下来再看代码,CoderInfo 中有这样一个成员

struct {
    int data;
    int len;
} s[DATASIZE];

它用来进行哈夫曼编码,查看源码可知,这个结构体只在 huffcode() 函数中赋值,里面的数据来自于哈夫曼编码表,使用的码表为 book01book11,没有用到 book12,这11个码表的成员原型如下

typedef struct {
    const uint16_t len;
    const uint16_t data;
} hcode16_t;

因此可以把 int 改成 short,每声道可以节约6KB内存
备注:这样修改其实是错的,但是完全可以正常使用,具体原因见下文

内存统计如下,约 200 KB

faac内存开销较大,为方便嵌入式设备使用进行优化(valgrind使用),Android性能优化,github,驱动开发

1.6 禁用 TNS

修改 libfaac\coder.hlibfaac\bitstream.c
这个修改会影响音质,实测影响很小,音质上的差异要仔细听才能察觉,个人认为这一点音质上的损失完全可以接受。
CoderInfo.tnsInfo 成员也去掉,并删除 faacEncEncode()TnsEncode() 的调用以及两处 TnsInit() 调用。
删除 faacEncConfiguration 中的 unsigned int useTns
编译时删除 tns.c
直接将 WriteTNSData() 函数修改如下

static int WriteTNSData(CoderInfo *coderInfo,
                        BitStream *bitStream,
                        int writeFlag)
{
    int bits = 0;

#ifndef DRM
    if (writeFlag) {
        PutBit(bitStream, 0, LEN_TNS_PRES);
    }
    bits += LEN_TNS_PRES;
#endif

    return bits;
}

内存统计如下,约 170 KB

faac内存开销较大,为方便嵌入式设备使用进行优化(valgrind使用),Android性能优化,github,驱动开发

1.7 修改数据类型

修改所有文件的 doublefloat
理论上来说这个修改会影响音质,实测没听出来,个人认为这个修改应该没问题
每声道内存再节省一半

内存统计如下,大约 90 KB

faac内存开销较大,为方便嵌入式设备使用进行优化(valgrind使用),Android性能优化,github,驱动开发

1.8 其他

以下无关紧要,能优化一点点,这里就不统计了
faacEncConfigurationint channel_map[64]; 可以改为 int channel_map[MAX_CHANNELS];
faacEncStruct 去掉 double *msSpectrum[MAX_CHANNELS];

优化总结

除去 main() 函数中申请的 buffer,经过以上优化已经可以做到单声道约 70 KB,双声道约 90 KB,这样的内存开销即使放到stm32的部分中高端型号上都能运行,还要啥自行车?

单声道内存统计如下,大约 70 KB

faac内存开销较大,为方便嵌入式设备使用进行优化(valgrind使用),Android性能优化,github,驱动开发

大家如果有更好的优化方法欢迎留言分享

其他问题

Q&A

Q: windows编译报错 #include "win32_ver.h"
A: 这个文件是由configure生成的,目前看似乎没有太大影响,先去掉

关于《1.5 优化数据结构》章节的优化问题

这确实是一个不合理,但碰巧能够正常运行的优化。下面来详细解释一下这个问题。

首先引用一下CSDN上 asd451006071 和 weixin_43957341 这两位网友的留言

asd451006071
2022.10.04
并不是,音频会卡顿,不连续,通过QQ音乐等软件都能听得出来。这是因为huff编码哪里出了问题。我也是查了源码确实huffcode是16位的。但是就是这样。把uint16_t改成int16_t就行了。至于为什么这样就行了。我也感到很好奇。很惊讶。。

weixin_43957341
2021.11.06
第六点,所有 double 转 float 这个有点小坑,虽然看起来能播,单独放在 苹果设备 上也能播,但是封装到 MP4 里,在 苹果设备 上就会播放异常,出现如卡视频,音频只有前几秒声音的情况,搞得我一度怀疑是时间戳或者 MP4 库本身的兼容问题

asd451006071
2022.10.04
huffcode那个s数组,uint16_t改int16_t就好了。你试试看。。

不知道这两位网友是不是看错了,我前文写的很清楚,把这个结构体中的int改成short,结果他俩都改成unsigned short

struct {
    int data;
    int len;
} s[DATASIZE];

于是就会出现音频卡顿的问题,这个和播放器无关,因为就是编码出错了。这份代码我自己也一直再在用,没有任何异常,最近闲下来了,正好研究一下这个问题。

下文都用uint16代替unsigned short,其他数据类似
首先我要承认,这是我的错,这个结构体确实只在 huffcode() 函数中赋值,里面的数据来也确实来自于哈夫曼编码表 book01book11,我最初在做优化时大概看了一眼这几个编码表,以为数值都在 int16 范围内不会溢出,所以大胆地将 int 改成 short 而且也没出问题。但不巧遗漏了 book03 的倒数第7项 {16,65534},这是唯一一个超出 int16 范围的数据,这也是我在重新研究这个问题时才发现的。但这并不是唯一会导致bug的值,但为什么改成int16正常,改成uint16反而异常?下面会结合代码进行分析。

先以 uint16 的情况为例,来看实际在 huffcode() 函数中用到 book03 的这段代码

    case 3:
    case 4:
        for(ofs = 0; ofs < len; ofs += 4)
        {
            // 此处省略若干代码
            else
            {
                data = book[idx].data;
                // add sign bits
                for(cnt = 0; cnt < 4; cnt++)
                {
                    if(qp[cnt])
                    {
                        blen++;
                        data <<= 1;
                        if (qp[cnt] < 0)
                            data |= 1;
                    }
                }
                coder->s[datacnt].data = data;
                coder->s[datacnt++].len = blen;
                DRMDATA;
            }
            bits += blen;
        }
        break;
  • 假设在 data = book[idx].data; 这里读取的是 {16,65534},此时 data 为 65534
  • 假设4次循环中只有一次 if(qp[cnt]) 条件成立,执行 blen++; data <<= 1 这两句以后,此时 data 为 131068(0x0001 fffc),blen 为 17,这里暂不考虑 if (qp[cnt] < 0)
  • 因为 uint16 溢出,这时 coder->s[datacnt].data = data; 使 s[datacnt].data 被赋值为 65532(0xfffc)

最终编码时在 WriteSpectralData() 函数中

static int WriteSpectralData(CoderInfo *coderInfo,
                             BitStream *bitStream,
                             int writeFlag)
{
    int i, bits = 0;

    if (writeFlag) {
        for(i = 0; i < coderInfo->datacnt; i++) {
            int data = coderInfo->s[i].data;
            int len = coderInfo->s[i].len;
            if (len > 0) {
                PutBit(bitStream, data, len);
                bits += len;
            }
        }
    } else {
        for(i = 0; i < coderInfo->datacnt; i++) {
            bits += coderInfo->s[i].len;
        }
    }

    return bits;
}
  • int data = coderInfo->s[i].data; 读取的 data 为 65532(0x0000 fffc),len 为17
  • PutBit(bitStream, data, len); 将 17 位数据写入文件,即写入的二进制数据为 0 1111 1111 1111 1100,注意这里写入的最高位是0
  • 而实际上应该写入的二进制数据为 1 1111 1111 1111 1100,即131068(0x1fffc),也就是由于溢出的原因是的最高位从1变成了0,进而导致音频播放出错

接下来以 int16 的情况再看一遍这些代码的执行结果

  • 假设在 data = book[idx].data; 这里读取的是 {16,65534},此时 data 为 65534
  • 假设4次循环中只有一次 if(qp[cnt]) 条件成立,执行 blen++; data <<= 1 这两句以后,此时 data 为 131068(0x0001 fffc),blen 为 17,这里暂不考虑 if (qp[cnt] < 0)
  • 因为 int16 溢出,这时 coder->s[datacnt].data = data; 使 s[datacnt].data 被赋值为 -4(0xfffc)。
  • WriteSpectralData() 函数中
  • int data = coderInfo->s[i].data; 读取的 data 为 -4(0xffff fffc),len 为17。注意!这里是重点!因为它是有符号数,高位全部被置为1
  • PutBit(bitStream, data, len); 将 17 位数据写入文件,即写入的二进制数据为 1 1111 1111 1111 1100,正好将正确的数值写了进去!

所以,真正会出问题的哈夫曼编码不止 {16,65534},假设循环执行了4次,也就是放大了16倍,那么凡是大于4096的像 {13,8188} 这样的编码都会出错。另外一个可以使它正常工作的巧合在于查看 huffdata.c 中的编码表会发现,所有数值都是接近2的n次方的数值,对于大于4096的数来说这些数的高4位都是1,使得它即使左移4位,超出16位以上的部分仍然是1,进而在之后转换为有符号数时不会出现该是0的位被补为1,保证了数值的正确。例如8188(0x1ffc),左移4位得131068(0x1fffc),int16溢出后为-4(0xfffc),再赋值给int32为-4(0xffff fffc),丝毫不影响。假设出现 4097(0x1001)这样的数,左移4位得65552(0x10010),int16溢出后为16(0x0010),再赋值给int32为16(0x0000 0010),数据又会出现错误!

到此为止整个问题分析完毕。一个不合理的优化在两种巧合的共同作用下让它完美运行。

最后再次感谢 asd451006071 和 weixin_43957341 这两位网友的留言!文章来源地址https://www.toymoban.com/news/detail-623250.html

到了这里,关于faac内存开销较大,为方便嵌入式设备使用进行优化(valgrind使用)的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 【小黑嵌入式系统第二课】嵌入式系统的概述(二)——外围设备、处理器、ARM

    板级支持包(BSP) 是商用嵌入式操作系统实现可移植性所采用的一种方案,是硬件抽象层的一种实现。BSP是介于硬件和操作系统中驱动层程序之间的一层,有时也可认为属于操作系统一部分。BSP实现了对操作系统的支持,为上层的驱动程序提供访问硬件设备的函数包。 BSP隔离了

    2024年04月17日
    浏览(68)
  • 嵌入式Linux(8):字符设备驱动--注册字符类设备

    杂项设备 注册杂项设备: 注销杂项设备: 字符类设备 文件:include/linux/cdev.h 步骤流程: 定义一个cdev结构体。 使用cdev_init函数初始化cdev结构体成员变量。 参数: 第一个:要初始化的cdev结构体 第二个:文件操作集: cdev-ops = fops;//实际就是把文件操作集写ops 使用cdev_add函数

    2023年04月22日
    浏览(50)
  • 嵌入式设备显示屏相关概念汇总

    LCD 接口:是一种常见的数字电路接口,支持多种显示器件,如字符型液晶显示器和点阵型液晶显示器等。 VGA 接口:是一种视频接口标准,用于连接显示器和计算机。该接口提供模拟 RGB 信号,支持最高分辨率为 1920x1080。 HDMI 接口:是一种数字音视频接口标准,用于连接高清

    2024年02月01日
    浏览(65)
  • 嵌入式linux设备网口带宽-测试方法

    iperf是一个基于Client/Server的网络性能测试工具,可以测试TCP、UDP和SCTP带宽质量,能够提供网络吞吐率信息,以及震动、丢包率,最大段和最大传输单元大小等统计信息,帮助我们测试网络性能,定位网络瓶颈。其中抖动和丢包率适应于UDP测试,二带宽测试适应于TCP和UDP。 一

    2024年02月10日
    浏览(46)
  • 嵌入式设备逆向所需的工具链

    导语:本文介绍了嵌入式设备逆向所需的工具链。 相关的应用程序或工具有: UART(Universal Asynchronous Receiver Transmitter,通用异步收发器): UBoot; Depthcharge; SPI (Serial Peripheral Interface,串行外设接口): Flashrom; I2C(Inter-Integrated Circuit,集成电路总线): i2cdetect; i2cdump; JTAG (

    2024年02月03日
    浏览(52)
  • 嵌入式开发——DMA外设到内存

    加强理解DMA数据传输过程 加强掌握DMA的初始化流程 掌握DMA数据表查询 理解源和目标的配置 理解数据传输特点 能够动态配置源数据 需求 实现串口的数据接收,要求采用dma的方式。 数据交互流程 CPU配置好DMA 外部数据发送给串口外设 串口外设触发中断 CPU处理中断逻辑,通知

    2024年02月03日
    浏览(54)
  • 【小黑嵌入式系统第二课】嵌入式系统的概述(二)——外围设备、处理器、ARM、操作系统

    上一课: 【小黑嵌入式系统第一课】嵌入式系统的概述(一)——概念、特点、发展、应用 下一课: 【小黑嵌入式系统第三课】嵌入式系统硬件平台(一)——概述、总线、存储设备(RAMROMFLASH) 前些天发现了一个巨牛的人工智能学习网站,通俗易懂,风趣幽默,忍不住分享

    2024年02月08日
    浏览(47)
  • 嵌入式linux驱动开发篇之设备树

    设备树(Device Tree)是一种用于描述嵌入式系统硬件组件及其连接关系的数据结构。它被广泛用于嵌入式 Linux 系统,尤其是针对使用多种不同架构和平台的嵌入式系统。它是一种与硬件描述相关的中间表示形式,将硬件信息抽象成一种可移植的格式,使得操作系统和引导加载

    2024年02月22日
    浏览(68)
  • 嵌入式设备应用开发(发现需求和提升价值)

    【 声明:版权所有,欢迎转载,请勿用于商业用途。 联系信箱:feixiaoxing @163.com】         很多做技术的同学,都会陷入到技术的窠臼之中。对于如何做具体的产品、实现具体的技术,他们可能很感兴趣。但是做出来的东西做什么用,或者说是有没有竞争力,事实上他们不

    2024年02月11日
    浏览(49)
  • 【小黑嵌入式系统第三课】嵌入式系统硬件平台(一)——概述、总线、存储设备(RAM&ROM&FLASH)

    上一课: 【小黑嵌入式系统第二课】嵌入式系统的概述(二)——外围设备、处理器、ARM、操作系统 下一课: 【小黑嵌入式系统第四课】嵌入式系统硬件平台(二)——I/O设备、通信设备(UARTUSB蓝牙)、其他(电源时钟复位中断) 嵌入式系统的硬件除了核心部件——嵌入

    2024年02月07日
    浏览(50)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包