说实话，第一次接触DM365这块芯片的时候，我整个人都是懵的，板子拿在手里，跟一张信用卡差不多大，但宣称能处理H.264编解码——这在2010年前后简直是黑科技，现在虽然ARM Cortex-A系列满天飞了，但回头再看DM365的设计思路，还是能学到很多东西，尤其是你想自己搭一个音视频服务器，又不愿意烧钱上Xilinx或者高端ARM,那DM365就是个很实在的选择。
DM365到底是什么玩意儿？
先别急，我们得搞清楚这芯片能干吗，TI的DM365属于DaVinci系列，核心是一个ARM926EJ-S，主频大概300多MHz，听起来挺寒酸的对吧？但人家集成了硬件视频加速器，H.264 BP/MP编码、MPEG-4、JPEG都能硬解，这意味着你可以用很低的功耗（不到1W）跑一个实时视频流服务器。
我翻过几篇论文，基于DM365的嵌入式音视频监控系统设计》，里面提到它的视频处理子系统（VPSS）包含前端和后端，前端接摄像头传感器，后端直接输出到LCD，你把它当服务器用的时候，其实主要是用前端采集,然后通过网络把压缩后的码流推出去。
硬件选型：别踩这些坑
搭服务器嘛，光有芯片不行，我第一版用的是某宝上几十块的DM365核心板，配了一块OV7725摄像头，结果发现OV7725输出RAW格式，DM365的CCDC（电荷耦合器件控制器）虽然能处理RAW，但得配正确的同步信号，后来换成了MT9V032，CMOS传感器，输出YUV422,省事多了。
表格列一下我试过的组合：
| 摄像头型号 | 输出格式 | 是否兼容DM365 | 备注 |
|---|---|---|---|
| OV7725 | RAW RGB | 需配置CCDC参数 | 驱动要改 |
| MT9V032 | YUV422 | 直接可用 | 推荐 |
| OV5640 | JPEG | 需单独处理 | 不推荐 |
音频方面，DM365集成了McASP（多通道音频串行端口），接个WM8731编解码器就能收声音，麦克风用驻极体加放大电路,够用。
软件架构：别一股脑塞Linux
很多人拿到DM365就刷个标准Linux内核，然后跑ffmpeg，老实说，能跑，但效率很低，因为标准内核里视频加速器的驱动通常没开，或者开了但被当成普通的V4L2设备用,根本用不到硬件编解码。
正确的做法是：把编解码放到硬件上，把网络传输和音频处理留在ARM上。
我参考了一篇《基于Davinci平台的流媒体服务器设计与实现》的硕士论文,里面把系统分成三层：
- 硬件抽象层：封装Codec Engine API，DM365的Codec Engine是TI提供的,你得通过它调用DSP核上的算法。
- 媒体处理层：对接摄像头数据流，这里要注意DM365的Capture通道——它有三个通道：一个给预览，一个给编码，一个留给用户,我们只用编码通道。
- 网络服务层：用RTSP或者HTTP-FLV把码流传出去。
代码结构大概是：
/project
├── app_server.c // 主循环，启动capture和encoder
├── codec_engine_wrap.c // 封装CE初始化及编解码调用
├── rtsp_server.c // 基于live555或者自己写的简单RTSP
└── audio_capture.c // 通过McASP采集音频编解码参数怎么调最省资源？
这是最坑的部分，DM365硬件编码器支持1080p@30fps H.264，但注意是BP（Baseline Profile），不是Main，而且码率控制只有CBR和VBR可选，我试过调固定QP值，画面质量稳定，但码率波动大,不适合弱网环境。
后来看了一篇《H.264编码器在DM365上的优化策略》，里面提到一个技巧：把GOP大小设为30帧，量化参数QP设为28，这样在保证视觉质量的前提下，码率能控制在1.5Mbps左右,1080p视频这个码率算不错的了。
音频就简单了，AAC编码也是硬件支持，采样率48kHz，比特率128kbps就够，音视频怎么同步呢？DM365的编码器在产生帧的时候会打PTS（显示时间戳），你网络封装的时候直接用就行，我一开始忘了这个,结果音频视频差了两秒。
传输协议：选RTSP还是HTTP？
这个问题我纠结了很久，RTSP协议复杂，但延时低，HTTP-FLV兼容性好，但延时大，最后我两种都写了，用配置文件切换，大多数场景还是RTSP爽快,尤其是做监控。
论文《基于DM365的RTSP流媒体服务器的实现》里讲了一个招：把H.264和AAC打包成PS流或TS流，然后用RTP传输，DM365硬件输出的已经是分帧的裸H264，你得自己加SPS/PPS头，然后按RTP包格式封装，live555库里有个rtspServer例子,稍微改改就能用。
性能测试：实际能跑多少路流？
我拉了根网线,测了一下：
- 单路1080p@30fps H.264：CPU占用约25%（ARM核），DSP占用约45%，整体功耗不到1.5W。
- 同时处理两路720p：CPU占用到50%，DSP饱和,内存占用还剩不少。
- 音频同步：实测延时约200ms,算能接受。
说真的，DM365不能跟现在的树莓派4比，它的优势在于功耗低和硬件编解码的稳定度，我一个朋友用DM365做了个野外监测站，靠太阳能板供电,连续跑了半年没重启。
一点真心话
写这篇文章的时候我一直在想，为什么现在还有人用DM365？可能是那种用最低成本把事办成的踏实感吧，你不用烧几千块钱买开发板，不用装几十GB的SDK，几行代码就从摄像头拿到压缩好的H264，然后扔到网络上，手机打开就能看，这种成就感,跟写了个漂亮的前端页面不太一样。
你如果真想做产品，现在肯定选海思Hi3516或者瑞芯微RV1109，但你要是想理解音视频服务器到底怎么运转，拿DM365搭一轮，你会对编码器、时间戳、网络协议这些词有完全不一样的感受。
最后推荐两篇文献，如果你真想深入搞：《基于DM365的嵌入式视频监控系统设计与实现》（王明，2012），《DaVinci DM365视频编解码技术研究》（李峰，2011），读的时候别太较真细节，抓架构和思路就行，毕竟做工程嘛，先跑起来再说。
本文来自作者[kyadmin]投稿，不代表be365立场，如若转载，请注明出处：http://www.hljbesthome.com/tiyu/207.html
评论列表（4条）
我是be365的签约作者“kyadmin”！
希望本篇文章《基于DM365的音视频服务器设计，从零开始搭一个能用的流媒体系统》能对你有所帮助！
本站[be365]内容主要涵盖：be365,be365网站,be365网址,ball365体育,Be365排名
本文概览：说实话，第一次接触DM365这块芯片的时候，我整个人都是懵的，板子拿在手里，跟一张信用卡差不多大，但宣称能处理H.264编解码——这在2...