全志T113-i音视频编解码测试：从环境搭建到问题排查全流程

1. 项目概述与核心价值最近在调试一块基于全志T113-i芯片的开发板核心任务是对其音视频编解码能力进行全面的功能与性能验证。这听起来像是一个标准的硬件测试流程但如果你真的上手做过就会知道从拿到一块“裸板”到能稳定播放1080P视频、录制清晰音频中间要趟过多少坑。T113-i作为全志面向智能显示、工控等领域的双核Cortex-A7芯片集成了丰富的多媒体接口和硬件编解码单元性价比很高但官方SDK的文档和社区支持相比一些主流平台要零散一些很多细节需要自己摸索。这个“音视频测试”项目远不止是跑几个Demo程序看看画面有没有出来那么简单。它本质上是一次对芯片多媒体子系统、底层驱动、中间件框架以及上层应用生态的深度探索。通过这个过程你不仅能验证硬件是否工作正常更能建立起从底层寄存器配置到上层播放器调用的完整知识链路。这对于后续进行产品定制、性能优化、问题定位都至关重要。无论你是嵌入式开发的新手想通过一个具体项目入门Linux多媒体开发还是经验丰富的工程师需要快速评估T113-i是否满足项目需求这套测试方法和其中总结的经验都能让你少走很多弯路。2. 测试环境搭建与核心工具链解析工欲善其事必先利其器。在T113-i上进行音视频测试第一步就是搭建一个稳定、高效的开发与测试环境。这个环境不仅仅是编译代码的工具链更包括烧录、调试、日志收集等一系列支撑工具。2.1 开发主机环境准备我的主力开发机是一台Ubuntu 20.04 LTS的台式机。选择Linux作为宿主机是必须的因为全志提供的编译工具链、打包脚本以及一些底层工具都是为Linux环境设计的。Windows下通过WSL2也能工作但在处理USB设备连接用于烧录和某些脚本执行时可能会遇到权限和路径问题增加不必要的复杂度。首先需要安装一些基础依赖包sudo apt-get update sudo apt-get install build-essential git repo u-boot-tools device-tree-compiler \ mtools libssl-dev ncurses-dev libpython2.7 libwxgtk3.0-gtk3-dev \ sshpass genext2fs lib32stdc6 libc6-i386 lib32z1 bison flex这里尤其要注意lib32stdc6等32位库因为全志的一些旧版工具链可能是32位的。如果缺少这些库在编译过程中会遇到奇怪的链接错误。接下来是获取全志官方的SDK。T113-i的SDK通常通过全志的客户服务平台或与代理商联系获取。拿到SDK包可能是一个名为t113-i_linux_sdk_vX.Y.tar.gz的大文件后解压并同步代码tar -xzf t113-i_linux_sdk_vX.Y.tar.gz cd t113-i_linux_sdk/ ./build.sh config在执行./build.sh config时会进入一个交互式菜单在这里选择对应的板型例如t113-i-evb、内核版本、文件系统类型等。这一步的选择直接影响后续生成的镜像功能比如是否包含GPU驱动、是否包含某些编解码模块。注意全志SDK的build.sh脚本功能强大但参数复杂第一次配置时建议截图或记录下自己的选择。一个常见的坑是如果你需要测试硬件编解码务必在配置中选中multimedia相关的选项并确保cedarx全志的硬件编解码中间件被编译进内核或作为模块。2.2 交叉编译工具链配置SDK内部通常会自带交叉编译工具链路径可能在lichee/brandy/gcc-linaro或external/toolchain/下。我们需要将其路径加入到系统的PATH环境变量中。更规范的做法是在SDK根目录的build.sh脚本或envsetup.sh脚本中通常已经设置了相关环境变量我们只需要source一下source build/envsetup.sh lunch执行lunch命令后会列出所有可用的产品配置选择与你板子对应的那一项。完成后终端提示符通常会变化并且执行echo $CC应该能显示出交叉编译器的路径比如arm-openwrt-linux-gnueabi-gcc。验证工具链是否工作arm-openwrt-linux-gnueabi-gcc --version如果正确显示版本信息说明工具链就绪。这一步的顺畅是后续所有编译工作的基础。2.3 测试辅助工具与镜像烧录除了编译环境我们还需要一些在开发板上运行的工具来辅助测试媒体信息分析工具ffmpeg和ffprobe。我们可以用交叉编译的方式为开发板编译一个精简版的ffmpeg用于检查视频文件格式、码率、帧率甚至进行简单的转码测试以对比软件编解码性能。性能监控工具top、htop、vmstat。BusyBox自带的top功能较弱可以考虑移植htop。更关键的是需要开启内核的perf或oprofile支持用于监测编解码时的CPU占用率、缓存命中率等。日志收集工具dmesg和kmsg是查看内核日志的生命线。为了更高效地抓取音视频驱动层的调试信息需要修改内核配置动态调整cedarx、V4L2等子系统的日志打印级别。镜像烧录是全志平台比较有特色的一环。T113-i通常通过USB OTG接口进入FEL模式进行烧录。步骤大致如下开发板断电按住FEL按键或短接测试点不放然后上电。在主机上运行全志提供的烧录工具phoenixsuit或命令行工具sunxi-fel。选择编译生成的tina-t113-i-evb_uart0.img名称可能不同镜像文件开始烧录。实操心得烧录失败十有八九是USB连接或驱动问题。首先确保lsusb能识别到设备ID可能为1f3a:efe8。在Linux下可能需要手动配置udev规则给相关USB设备赋予写权限。如果使用sunxi-fel命令类似sunxi-fel -p spiflash write 0x00000000 tina-t113-i-evb_uart0.img其中-p参数指定闪存类型spiflash/nand/emmc务必与板载存储一致。3. 音频子系统测试从驱动到应用音频测试的目标是验证从音频编解码器Codec芯片、数字音频接口I2S/PCM、Linux ALSA驱动框架到上层播放/录制应用如aplay/arecord、tinyalsa的完整通路是否畅通并评估其延迟、失真和信噪比等关键指标。3.1 ALSA驱动与声卡设备确认系统启动后首先检查音频驱动是否成功加载声卡设备是否被识别cat /proc/asound/cards正常情况下你会看到类似这样的输出0 [audiocodec ]: audiocodec - audiocodec audiocodec 1 [snddaudio0 ]: snddaudio - snddaudio0 snddaudio0这里audiocodec通常指芯片内部的模拟编解码器用于连接耳机、麦克风等snddaudio则对应数字音频接口可能连接外部的HDMI音频或数字功放。使用aplay -l和arecord -l可以列出播放和捕获设备的具体信息包括设备编号、名称和支持的格式。这是后续所有音频命令的基础。3.2 基础播放与录制测试最基础的测试是使用aplay播放一个WAV文件使用arecord录制一段音频。生成测试音源在主机上我们可以用sox或ffmpeg生成一个特定频率的正弦波WAV文件。# 在主机上生成1kHz正弦波持续5秒采样率44.1kHz16位单声道 ffmpeg -f lavfi -i sinefrequency1000:duration5 -ar 44100 -ac 1 test_1k.wav传输文件到开发板通过scp或adb push将test_1k.wav传到开发板例如/tmp目录。播放测试aplay -D hw:0,0 /tmp/test_1k.wav-D hw:0,0指定使用第一张声卡card 0的第一个设备device 0。如果听到清晰的单音调说明播放通路基本正常。如果没有声音依次排查音量是否被静音使用amixer命令查看和设置。例如amixer sset Headphone 100%。音频路径Audio Route是否正确有些Codec有多路输入输出需要通过amixer设置正确的路径选择比如从DAC到耳机输出。检查硬件连接耳机是否插好功放是否使能。录制测试arecord -D hw:0,0 -f S16_LE -r 44100 -c 2 -d 5 /tmp/record.wav参数解释-f指定采样格式-r采样率-c通道数-d录制时长。录制完成后将文件传回主机用音频编辑软件如Audacity或aplay回放检查是否有杂音、爆音或失真。3.3 深入测试格式、采样率与延迟基础通路通顺后需要测试音频子系统的兼容性和性能。多格式支持测试T113-i的硬件音频编解码器可能支持多种格式。除了S16_LE还可以测试S24_LE、S32_LE等。使用arecord --dump-hw-params可以查询设备支持的硬件参数范围。采样率切换测试依次测试8k、16k、48k、96kHz等不同采样率的播放和录制。特别是48kHz和44.1kHz之间的切换有些时钟设计不佳的系统可能会有轻微爆音。延迟测量这是音频性能的关键指标。一个简单粗略的方法是“拍手测试”编写一个程序在检测到输入音频超过阈值时立即在输出通道播放一个脉冲信号。用麦克风和扬声器对着录制整个过程然后在音频文件中测量拍手声音起点到脉冲信号起点的时间差。更专业的方法需要使用专门的音频分析仪或软件。避坑指南在测试中如果遇到持续的“嗡嗡”声很可能是地线环路干扰或电源噪声。如果遇到间歇性的“咔嗒”声Pop-Click Noise通常是电源管理单元PMU上下电或音频路径切换时对模拟电路的冲击造成的。解决方法可能涉及修改驱动中Codec的上下电序列或在硬件上增加缓启动电路。此外tinyalsa是全志平台常用的、比ALSA更轻量的音频库如果你的应用基于它需要用tinyplay和tinycap进行对应测试。4. 视频子系统测试解码、编码与显示视频测试是重头戏涉及解码、编码、显示Display和图形处理GPU等多个子系统。T113-i集成了独立的视频编解码硬件单元CEDAR支持H.264/H.265的编解码。4.1 显示框架与接口初始化在测试视频功能前需要确保显示输出正常。T113-i支持RGB、LVDS、MIPI-DSI等多种显示接口。系统启动后检查/dev/fb0设备是否存在以及/sys/class/graphics/fb0下的信息cat /sys/class/graphics/fb0/name cat /sys/class/graphics/fb0/modes这可以确认帧缓冲设备已初始化并获取当前显示模式如分辨率、刷新率。通常全志平台使用disp驱动来管理显示。你可以通过cat /sys/class/disp/disp/attr/sys来查看显示系统的状态。更直观的方法是使用fb-test之类的工具填充颜色块检查屏幕是否有显示颜色是否正确有无花屏、撕裂。4.2 硬件解码播放测试全志提供了cedarx库和配套的测试程序如demo_player来调用硬件解码器。准备测试视频准备几种不同规格的标准视频文件用于测试H.264 Baseline Profile, 1280x720, 30fps, 2Mbps (测试基本解码能力)H.264 High Profile, 1920x1080, 60fps, 5Mbps (测试高清高帧率解码)H.265 Main Profile, 1920x1080, 30fps, 3Mbps (测试HEVC解码)一个码率极高的“坏”视频用于测试解码器的容错和恢复能力。 建议使用ffmpeg生成标准测试序列避免网络下载的视频因封装格式或非标参数导致问题。运行解码测试SDK中可能自带demo_player或xplayer。运行命令通常如下demo_player /mnt/test.h264观察视频是否能正常播放画面是否流畅、有无卡顿、花屏、绿屏通过top命令观察CPU占用率。一个成功的硬件解码CPU占用率应该很低可能低于10%主要负载在cedarx相关的内核线程或VPU上。如果CPU占用率很高可能是走了软解需要检查驱动是否加载lsmod | grep cedarcedarx库是否存在且版本匹配。视频格式是否在硬件支持列表中。性能与压力测试多实例解码尝试同时运行两个demo_player实例播放不同视频测试解码单元的多路并发能力。长时间稳定性测试循环播放视频数小时观察是否有内存泄漏free命令查看内存变化、解码器是否挂死、系统是否崩溃。分辨率切换测试快速切换播放不同分辨率的视频测试显示控制器和驱动层的动态调整能力。4.3 硬件编码录制测试编码测试通常指将摄像头采集的图像或图形层内容实时编码成视频流。摄像头输入测试首先确保摄像头驱动如V4L2工作正常。使用v4l2-ctl工具v4l2-ctl --list-devices v4l2-ctl --device/dev/video0 --all确认摄像头被识别并支持所需的采集格式如YUYV, MJPEG, H264。使用ffmpeg或gstreamer进行简单的采集预览ffmpeg -f v4l2 -input_format yuyv422 -video_size 1280x720 -i /dev/video0 -f fbdev /dev/fb0这会将摄像头画面直接输出到帧缓冲需要fbdev支持。运行编码测试使用SDK提供的编码demo如demo_encoder。命令可能如下demo_encoder -i /dev/video0 -o /mnt/test.h264 -w 1280 -h 720 -f 30 -b 2000参数指定输入、输出、宽、高、帧率、码率。录制一段视频后用demo_player回放检查画面质量、流畅度和延迟。同样需要监控CPU占用确保是硬编。编码质量评估这是难点。主观上观察录制视频是否有模糊、拖影、马赛克。客观上可以将原始采集的帧如保存为YUV文件与编码后再解码的帧进行对比计算PSNR峰值信噪比或SSIM结构相似性指标。这需要编写脚本或使用专业工具。4.4 显示与叠加层测试T113-i的显示引擎通常支持多个图形层Layer叠加比如一个层放视频一个层放UI界面。测试UI框架如Qt或自己使用libdrm/libvdpau编写程序测试多层叠加、透明度混合、缩放、旋转等功能是否正常。检查在不同层之间切换内容时是否有闪烁或残影。5. 系统集成与压力测试当音视频单项测试通过后需要进行系统级的集成测试模拟真实应用场景。5.1 音视频同步播放测试这是检验多媒体系统成熟度的关键。播放一个同时包含音频和视频流的文件如MP4。问题通常表现为“音画不同步”。可以使用ffmpeg命令行播放因为它内部实现了基于PTS显示时间戳的同步算法ffmpeg -i /mnt/test.mp4 -pix_fmt bgra -f fbdev /dev/fb0但更常见的做法是使用播放器应用如移植mpv或使用全志提供的player。测试时注意观察长时间播放后不同步的偏差是逐渐增大漂移还是随机出现抖动。漂移通常由时钟源不准确导致抖动则可能源于缓冲区管理或调度问题。5.2 多业务并发压力测试模拟一个智能终端设备的真实场景后台播放音乐前台运行一个带有动画的UI界面同时通过网络拉流播放一个小窗口视频。在这个场景下你需要监控系统资源使用top、vmstat、iostat看CPU总占用、各核心负载是否均衡、内存使用量、I/O等待。实时性使用cyclictest测试系统延迟观察在音视频负载下线程调度延迟是否激增。温度与功耗长时间高负载运行用红外测温枪监测主芯片温度观察是否有过热降频检查/sys/devices/system/cpu/cpufreq/policy0/scaling_cur_freq。功耗则需借助电流表。5.3 断电、重启与恢复测试异常掉电是工控等场景的常态。在播放视频或录制过程中直接拔掉电源。重新上电后检查文件系统是否损坏日志中有无FSCK信息之前录制的视频文件是否完整可播系统是否能正常启动并再次进入多媒体应用。这考验的是文件系统的健壮性和驱动/中间件对异常状态的处理能力。6. 典型问题排查与调试技巧实录在实际调试中你会遇到各种各样的问题。下面记录几个我遇到的典型问题及其排查思路。6.1 问题一播放视频有声音无画面或画面卡在第一帧现象运行demo_player能听到音频正常播放但屏幕黑屏或静止在第一个画面。排查思路检查解码器输出首先在demo_player命令中增加调试输出或者直接看内核日志dmesg | grep cedar确认解码器是否在持续输出帧数据。如果没有输出可能是解码器初始化失败或输入码流不兼容。检查显示输出如果解码器有输出问题可能出在显示环节。确认帧缓冲FB设备是否正确打开和配置。可以尝试用一个简单的fb-test程序画个颜色看屏幕是否有反应排除显示硬件问题。检查数据通路cedarx解码后的数据需要通过VE视频引擎和DE显示引擎之间的物理或内存通路传递。检查设备树DTS中相关iommu、dma节点的配置是否正确。有时需要配置disp驱动中的图层来源为“video layer”。检查时钟与电源使用cat /sys/kernel/debug/clk/clk_summary查看视频相关时钟如pll-video0ahb-de0是否使能且频率正确。检查电源域是否打开。最终解决我遇到的一次是DTS中disp节点的ports配置里没有将video layer连接到display output。对比参考板型的DTS文件后添加了缺失的port定义问题解决。6.2 问题二录音噪音大有规律的低频嗡嗡声现象使用arecord录制音频回放时背景有持续的50Hz或100Hz嗡嗡声。排查思路区分噪声来源拔掉麦克风如果噪声消失说明噪声来自麦克风或前级放大电路。如果噪声依旧说明是板级地线或电源噪声耦合到了音频Codec的输入或供电。检查硬件用示波器测量音频Codec的模拟供电引脚AVCC, HPVCC等看电源纹波是否过大。检查麦克风偏置电路是否干净。检查软件配置在驱动中尝试关闭不用的输入通道如LINEIN看噪声是否变化。调整ALSA驱动中Codec的PGA可编程增益放大器增益有时增益过高会放大底噪。检查接地这是一个经典的硬件问题。确保音频地AGND和数字地DGND的单点连接良好。检查麦克风线缆是否屏蔽良好。最终解决我的案例中是板子的电源模块开关频率约1MHz的谐波通过空间辐射耦合到了音频走线上。在音频Codec的电源引脚增加了π型滤波电路磁珠电容并优化了音频区域的铺地噪声显著降低。6.3 问题三同时播放音频和视频时系统偶尔卡顿现象在集成测试中音视频同步播放几分钟后会出现一次明显的卡顿音频可能破音。排查思路监控系统负载在卡顿发生时快速执行top观察是哪个进程或内核线程CPU占用率突然飙升。可能是某个驱动中断处理程序、某个内核工作队列workqueue耗时过长。检查中断风暴使用cat /proc/interrupts命令在卡顿前后对比看是否有某个中断号计数异常增长。可能是某个外设如SD卡、USB产生了大量中断抢占了CPU时间。检查内存带宽使用perf工具监控内存访问事件。视频编解码是内存带宽消耗大户如果与CPU或其他DMA设备争抢带宽会导致性能下降。可以尝试调整cedarx驱动中缓冲区的内存属性如使用CMA内存或带cache的内存。检查调度延迟运行cyclictest -m -p 99在后台进行高优先级线程的延迟测试。当卡顿发生时观察cyclictest输出的最大延迟Max Latency是否也出现一个尖峰。这能确认是系统实时性出了问题。最终解决通过perf定位到卡顿时swapper进程代表中断上下文占用率很高进一步追踪到是MMC/SD卡驱动的中断处理函数耗时过长。原因是SD卡读写性能不佳且文件系统日志操作频繁。我们将日志文件系统从ext4改为f2fs对Flash更友好并调整了SD卡的时钟频率和驱动中的DMA缓冲区大小卡顿现象基本消失。6.4 常用调试命令与日志速查表问题类别关键命令/文件目的与解读系统与进程top -Hps aux查看进程和线程级CPU/内存占用定位高负载元凶。内存free -mcat /proc/meminfoslabtop查看系统内存、缓存、Slab使用情况排查内存泄漏。中断cat /proc/interruptswatch -n 1 cat /proc/interrupts监控各中断号发生次数发现异常中断源。时钟与电源cat /sys/kernel/debug/clk/clk_summarycat /sys/kernel/debug/regulator/regulator_summary查看各时钟频率、使能状态各电源域电压/使能状态。CEDAR VPUdmesg | grep -E “cedarve显示 DISPcat /sys/class/disp/disp/attr/syscat /sys/class/graphics/fb0/vscreeninfo查看显示系统状态、分辨率、颜色格式等参数。音频amixer contentscat /proc/asound/card0/pcm0p/sub0/hw_params查看混音器详细控件信息查看当前音频硬件运行参数。V4L2摄像头v4l2-ctl --device/dev/video0 --allv4l2-ctl --list-formats-ext查看摄像头设备能力支持的格式、分辨率、帧率。文件与IOstrace -p pidiostat -xz 2跟踪进程系统调用发现阻塞点查看磁盘IO状况。实时性cyclictest -m -p 99 -n测量线程调度延迟数值过大说明系统实时性差。调试是一个从现象到本质从系统到模块从软件到硬件的逐步缩小范围的过程。保持耐心善用工具系统性地收集信息大部分问题都能被定位和解决。每一次解决问题的过程都是对系统理解加深的一次机会。