为什么偏偏是DM365？
说实话，我第一次接触DM365的时候，心里是有点懵的，这芯片吧，性能不算顶尖，但价格在那摆着，功耗还低，特别适合做那种“扔在墙角就不管了”的音视频服务器，TI家的DaVinci系列，DM365算是经典款，带了个ARM9（主频大概300MHz的样子）再加一个硬件编解码协处理器，硬解H.264这事儿它干得比纯软件方案舒服太多了。
我见过不少项目，一开始想用PC机做服务器，结果发现电费比设备本身还贵，风扇呼呼转，机房跟飞机场似的，后来换了DM365，散热片都不用太大，安静得很，这就引出一个问题：怎么拿这玩意儿正经设计一个能跑的音视频服务器？
DM365的核心能力，先摸个底
你手头要真有这块板子，得先知道它能干点啥，别听别人吹,咱自己看数据手册。
| 特性 | 参数 | 实际体验感觉 |
|---|---|---|
| CPU核心 | ARM926EJ-S @ 300MHz | 跑Linux够用，别太贪心 |
| 视频处理子系统 | 支持H.264/MPEG-4硬编码 | 720P实时编码很稳 |
| 内存接口 | DDR2，最大256MB | 堆内存时注意带宽 |
| 外设 | USB 2.0、网络、I2C、SPI | 挂摄像头和网口刚刚好 |
这表一看就清楚：硬编码是它吃饭的本事，你要是用纯ARM去编H.264，那300MHz的主频会直接把你劝退，但DM365不一样，它有个叫HDVICP的硬件模块专门干这事儿。
设计一个音视频服务器，思路得这么捋
第一步：别急着写代码，先画个框图
我踩过的坑是啥？就是上来就敲代码，结果发现网络吞吐跟不上，视频帧率卡成PPT，后来学乖了,先画这个：
- 视频源（一般是CMOS摄像头,比如OV2715）
- 音频源（驻极体麦克风或者线路输入）
- DM365主控板
- 网络接口（有线或者WiFi模块）
- 存储（SD卡或者SATA硬盘,看你要不要本地存）
关键点：视频进DM365先过ISIF（图像传感器接口），然后到VPFE（视频处理前端），再到编码器，这个路径上任何一环带宽不够,后面都白搭。
第二步：软件分层，别搞成一坨
我觉得吧，嵌入式服务器最忌讳的就是把应用层、驱动层、协议栈全揉一起，DM365有TI自己出的DVSDK（DaVinci Software Development Kit），里面把驱动和Codec Engine封装好了。
以前遇到个傻事儿：有人把RTSP服务器直接写在应用里，结果一编码就卡死，后来发现是没用好Codec Engine的异步调用。
分层建议：
- 底层驱动：直接调TI的固件，别自己造轮子
- Codec Engine：用ARM端调DSP端的编解码，走VISA接口
- 应用层：跑一个轻量级的RTSP或者HTTP-FLV服务器
- 控制面：搞个简单的Web管理页面（Dropbear ssh + lighttpd）
第三步：视频采集，注意格式转换
摄像头出来一般是个RAW RGB或者Bayer格式的数据，DM365的VPFE有个Crop和Scaler功能,能把1920x1080的源直接砍成1280x720再编码。
贴一小段伪代码的调参思路：
// 设置采集参数 v4l2_s_fmt(&fmt); // 设定YUV420格式 // 设置编码参数 enc->bitrate = 2000000; // 2Mbps，H.264 enc->framerate = 30; // 30fps enc->profile = H264Profile_Baseline; // baseline兼容性好
实际写的时候记得检查ioctl返回值，别像我一样忘了查,结果画面全是雪花。
音频侧：容易被忽略但其实很坑
视频服务器不能光有画面没声音，DM365的音频是走McASP接口的,配合个TLV320AIC3106这种codec。
关于采样率：很多人想当然设成48kHz，但DM365的硬件编码器对44.1kHz支持更好，别问我怎么知道的，看手册第3.2.7节写的。
音频和视频要同步，得靠时间戳来对齐,我的做法是：
- 视频帧过来的时候记录系统时间戳（gettimeofday）
- 音频包也打上同样的时间戳
- 编码后打包成TS或者FLV，在容器里写同步信息
你可能会问：“不加同步会怎样？”——看视频的时候嘴型对不上，男主角嘴都闭上了，声音还在那儿“我爱你”,瞬间出戏。
网络传输：RTSP还是HTTP？
这问题我纠结了挺久,感觉吧：
- RTSP：实时性更好，适合视频监控，但客户端支持麻烦点
- HTTP-FLV：浏览器直接能看，现在大部分监控都这么搞
小项目我推荐RTSP over TCP，DM365的网口走的是EMAC，百兆的，推个720P @ 30fps问题不大，每秒大概1.5MB左右的码流,带宽还能留点给控制信号。
注意：TCP的Nagle算法要关掉，不然小包会堆积,造成延时。
// 关掉Nagle int flag = 1; setsockopt(sock, IPPROTO_TCP, TCP_NODELAY, &flag, sizeof(flag));
有时候卡顿不是因为编码性能,而是这细节没处理。
存储方案：本地还是云端？
DM365可以挂SD卡，也可以接SATA硬盘，但我发现有很多人直接把摄像头数据既推流又本地存，结果写入操作占用了大量总线带宽,编码器拿不到数据就丢帧。
建议做法：
- 推流走内存循环队列
- 本地存储开单独的写入线程，用mmap直接写文件块
- 实在不行，用NFS挂远程存储，省本地IO
我之前的项目里就是吃了这个亏，视频卡成幻灯片，查了半天发现是SD卡写速度跟不上，换了张Class 10的卡才好。
功耗和散热：DM365的温柔
这芯片满载大概1.5W左右，比那些X86的怪物省电多了，但是别以为它就不热，我摸过没加散热片的DM365,裸片烫手。
散热方案：
- 贴一个10mm x 10mm的小散热片
- 板子四周留通风孔
- 顶部不要堆叠其他发热模块（比如WiFi模块最好另接延长线）
有次我把WiFi模块直接焊在核心板正上方，结果无线信号断断续续，测了半天发现是过热导致芯片降频了，后来分开放,稳得很。
实际部署中遇到的两个小坑
-
内存泄漏：Codec Engine的Buffer申请后忘记释放，跑个两三天就挂，解决方法是在每次编码循环里加个计数器,超过100帧没释放就打印日志。
-
网口协商：有的交换机不支持自动协商，DM365的EMAC有时会协商成10M半双工，解决办法是在内核启动参数里指定：
emac_options=autoneg=0,speed=100,duplex=1
关于PDF文档那点事
要写“基于DM365的音视频服务器的设计”的PDF，其实核心就是把上面这些内容整理成规范文档。建议目录结构如下：
- 第一章：DM365芯片架构分析
- 第二章：系统总体设计（硬件选型+软件架构）
- 第三章：视频采集与编码的详细实现
- 第四章：音频同步与处理
- 第五章：网络协议栈的选择与优化
- 第六章：电源管理与稳定性测试
PDF撰写时，最好配上时序图和数据流图，但更重要的，是把踩过的坑写进去，比如我前面说的那些，技术文档如果只写成功案例，那用处不大，真正有价值的，是那些“我以为没问题结果崩了”的教训。
最后的几个小建议
你要是真打算用DM365搞个音视频服务器，别贪心。720P 30fps是它的甜蜜点，1080P也能跑，但再往上推就有点费劲了，选摄像头的时候注意驱动支持，别买个稀奇古怪的型号，Linux内核里没有驱动的，你就得自己写,那工期就拉长了。
音频这个事，我再说一遍，不要以为不重要，做过监控项目的人都懂，很多时候是听到声音才发现出事了，画面反而不是第一优先级,所以音频通道一定要留好。
Golang写服务器控制程序？我试过在DM365上交叉编译Go，但ARM9的架构支持不太完美，还是老老实实C语言写核心逻辑，Go写上位机管理程序比较靠谱，或者用C + Lua搭配,更新逻辑不用重新编译固件。
最后那点：上线前跑个72小时的压力测试，丢包率、内存占用、CPU负载都记录一下，我就吃过亏，以为自己代码稳了，结果第三天凌晨三点挂的,用户直接电话飙过来。
本文来自作者[kyadmin]投稿，不代表be365立场，如若转载，请注明出处：http://www.uss1.cn/nengyuan/104.html
评论列表（4条）
我是be365的签约作者“kyadmin”！
希望本篇文章《基于DM365的音视频服务器设计，从零开始的嵌入式流媒体实战》能对你有所帮助！
本站[be365]内容主要涵盖：be365,be365网站,be365网址,ball365体育,Be365排名
本文概览：为什么偏偏是DM365？说实话，我第一次接触DM365的时候，心里是有点懵的，这芯片吧，性能不算顶尖，但价格在那摆着，功耗还低，特别...