利用队列机制实现AV同步.pdf

利用队列机制实现利用队列机制实现 A/V 同步同步 李哲，邓明 中国地质大学地球物理与信息技术学院， 北京 100083 Email：zhejunli@摘摘 要要：本文介绍了一款基于 Equator BSP-15 DSP 芯片的嵌入式流媒体机，没有介绍如何 采用高层协议保证同步，而是从比较底层的原理着手，从音视频的采集开始，描述了如何利 用队列机制，在 Linux 多线程环境下，实现音视频的采集、压缩、传输过程的同步实验结 果证明，在 100Mbps 局域网环境下，每个解码端能够实现本机的 A/V“唇同步”，多个解码 端之间的同步播放效果也很好 关键词关键词：BSP-15，流媒体，音视频，同步，队列机制 0. 引言引言 随着嵌入式设备硬件配置不断提高， 软件不断丰富， 流媒体这种需要强大处理能力的技术也日益广泛应用到嵌入式系统中，比如：DTV，IP-STB，IP-Phone,视频监控机等本文中的嵌入式流媒体机以 Equator BSP-15 多媒体信号处理器为硬件核心， Tetra Board 为硬件平台，嵌入式 Linux 为软件平台，采用队列机制而非时间戳方式实现 A/V 同步。

作为编码端时，它能够实时采集、编码（MPEG4 格式） 、传输 30 帧/秒的 Half D1(360*480)视频图像，同时还有能力同步采集、传输两个声道 PCM 音频数据，采样率最大 48kHz，样点长度为 24位 这种强大的处理能力完全得益于 Equator BSP-15 对音视频应用的针对性设计， 使得音视频数据的采集、DMA 传输、压缩都得以高效率完成解码端的运算负载比较轻，实测表明，编码器占用的 DSP 计算周期比解码器多 2 倍以上 编码端和解码端的 BSP-15 运行在 405MHz， 只是运行不同的软件， 实现在局域网内 N(个编码端)对 M（个解码端）的音频/视频实时编码、传输及解码、播放除了 Sub-AV 编码端，每个编码端向一个组播地址发送音视频流，每个解码端可以选择接收任意一个编码端的流（点播） 总体的拓扑结构如图 1 所示 除了正常的多媒体节目播放功能， 这套流媒体系统还考虑到了信息发布的功能 本流媒体机在作为飞机上多媒体设备时， 除了为旅客提供流媒体节目点播， 流媒体机还必须具备以下的控制功能：1）在紧急情况下，飞行员需要与乘客直接讲话，能够直接把语音插入到当前所有音频流中，覆盖当前节目的声音。

同时飞行员的声音要具备很高的优先级，很低的延迟时间，通常要小于 120mS 才能满足要求这个功能叫做 PA(Priority Audio)2）当机务人员有语音通知乘客，或者整点报时的声音，也需要通过流媒体系统播放出去，这个功能叫做CHIME，它并不需要低延迟时间，不需要影响乘客观赏当前节目，只需要把声音与节目的声音混合叠加在一起播出3）当机组人员需要给乘客声音和图像的演示时，比如教乘客如何系安全带，就需要把当前所有节目切换到摄像头和话筒，让乘客看到和听到演示，这就相当于换了一个节目频道这个功能叫做 BRIEFER，也不需要低延迟 -1- 224.0.1.255 224.0.1.1 224.0.1.2 … 224.0.1.N LAN 控 制 通 道 的A/V 输入设备 Sub-AV 编码端DVD 1 编码端 1 DVD 2 编码端 2 DVD N 解码端 1 解码端 2 解码端 M编码端 N 图 1 网络拓扑结构图 这 3 种功能都是辅助功能，称为 Sub-AV，Sub-AV Encoder 是专门用来做辅助功能的编码端，负责这三种信息源的编码工作而且，不管乘客正在观看哪一个节目源，这 3 个信息必须接收。

因此，这个通道的流用广播方式发送 1. 利用利用RTP协议实现流传输协议实现流传输 RTP本身不能区分载荷（payload）类型，也不能够自动保证实时传输、丢包监测等，这些工作实际都是由上层软件实现的[1]这虽然加重了上层软件的工作，但也提供了灵活性比如，在我们的流传输过程中，我们自己定义RTP包的格式，把下面的结构放到RTP的净载荷（Payload）中同时，由于主要在局域网中传输，能够保证QoS和不会出现错序包，RTP的时间戳计算部分省略掉了，大大降低了软件复杂性，而代之以我们自己的队列同步机制 //RTP 的 Payload 中的数据格式 struct rtpPacket{ UInt PacketNum ; //包序号 UInt32 PacketType; //包类型 UInt32 reserved; UInt PacketSizeVideo; //视频数据大小 UInt PacketSizeAudio; //音频数据大小 char PacketPayload[TOTAL_PACKET_SIZE];//视频+音频数据 }； 其中视频数据格式为 MPEG4，音频数据格式为 PCM 码。

由于自定义格式，没有利用RTCP，而采用采用队列机制，从底层来保证同步 2. A/V同步概述同步概述 -2- A/V同步又称为“嘴唇同步”（lip sync） ，端到端的数字音视频的制作、发布和广播系统是一个包含压缩、 解压和存储设备的数字处理阵列 系统中的每个部分都会对经过它的音视频信号引入延迟 系统设计的目标通常要求经过每个部分的相对音视频延迟在毫秒级 在操作上，对音频和视频引入的延迟不同，就影响了音视频的同步可是，数字音视频系统的一个主要目的就是能够给观看者呈现同步的音视频， 不能让观众看到口型与声音的不一致 由于在这个链条中，从制作到接收，每个部件都对通过的音视频信号因入不同程度的延迟，而且延迟通常不相等， 所以每个部件都会潜在地导致输出音视频不同步 整个音视频失步是这个链条中每一个环节失步的代数和失步错误会导致音视频时间关系上正的或负的时间偏移，而由于编解码算法的复杂度不同，视频信号通常承受比音频信号大的延迟，造成视频滞后于音频因此需要在系统中的各个点检测音视频的同步情况，并在需要时作出矫正，以防止失步超出容限 3. 队列机制队列机制 我们利用队列的平衡来实现同步同步包含以下两个概念：1）纵向同步：编码端的编码线程、网络发送线程之间的同步；解码端的解码线程、网络接收线程之间的同步；2）横向同步：编码端保证音频/视频之间的同步采集，同步发送，解码端保证音频/视频同步播放。

队列之所以能够实现同步， 因为队列机制充分利用了 Linux 下的线程同步机制， 如信号、原子操作，来实现资源的同步使用读队列的函数实现： /* * Function : Read element from queue or wait. * Read element from queue; if the queue is empty, * then wait until an element becomes available. * Parameters : queue (I) Queue to read from. * element (O) Pointer to result location. * Function Result : Error code as defined for this module. */ osalError_t osalQueueGet (osalQueue_t queue, Pointer *element) { osalError_t err = OSAL_OK; Bool locked1 = False; Bool locked2 = False; E( osalSemP (queue->get) ); locked1= True; E( osalAtomicEnter (queue->atomic) ); locked2= True; *element= queue->contents[ (queue->first++) finish: if (locked2) { -3- osalAtomicExit(queue->atomic); osalSemV (queue->put); } else { if (locked1) { osalSemV (queue->get); } } return err; } 写队列操作： /* * Function : Put element in queue or wait. * Put element into queue; if the number of * elements held by the queue has reached its * capacity, then wait until a slot becomes * available. * Parameters : queue (I) Queue to put 'element' into. * element (I) Element to queue. * Function Result : Error code as defined for this module. */ osalError_t osalQueuePut (osalQueue_t queue, Pointer element) { osalError_t err = OSAL_OK; Bool locked1 = False; Bool locked2 = False; E( osalSemP (queue->put) ); locked1= True; E( osalAtomicEnter (queue->atomic) ); locked2= True; queue->contents[(queue->last++) finish: if (locked2) { osalAtomicExit(queue->atomic); osalSemV (queue->get); } else { if (locked1) { osalSemV (queue->put); } } return err; } -4- 4. 编码端考虑的问题编码端考虑的问题 视频延迟由图 2 所示的队列和编码器产生， 音频队列结构同此， 只是由于采用 PCM 码，没有了编码器和 codedFullQueue 的延迟。

BT601/656 视频数据 vinFullQueue 到局域网 Mpeg4 编码器 RTP 打包codedFullQueue 图 2 视频编码端的队列结构 BT601/656 视频数据是Philips SAA7113 视频解码器的输出，Linux驱动程序把一帧YUV422 格式的数据放到vinFullQueue队列中[2]队列是一个软件FIFO，利用Linux内核的互斥和原子操作，实现队列的阻塞型读写这种队列有三个功能：1）在画面运动非常剧烈时，有时编一帧的时间达到 29mS，经过队列的缓冲，这种超长的时间能被吸收掉，只要在一段时限内，其平均耗时不超过 21mS，就能够在 33.3667m。