基于安卓平台的实时媒体内视音频协调法制造技术

本发明专利技术通过设置一级缓存区，减缓网络环境不佳时对视音频包所造成的时延抖动，为保证视音频流的实时性所采用的UDP传输方式，会导致视音频包乱序达到接收端，而在一级缓存区中，通过对比视音频包的序列号，对不可靠传输造成的乱序包进行解包、排序和组帧，然后在发生丢包现象时，先判断丢包类型，对网络拥塞所造成的丢包采用流量和拥塞控制策略，网络环境和丢包现象均通过RTCP包中的SR包和RR包来进行检测，接收端通过SR包计算出丢包率和回环时间，再将计算出的信息通过RR包反馈给发送端，发送端再根据反馈信息和改进后的吞吐模型来调节发送速率，减少丢包率，使卓平台的实时媒体内视音频达到同步。视音频达到同步。视音频达到同步。

【技术实现步骤摘要】
基于安卓平台的实时媒体内视音频协调法


[0001]本专利技术涉及一种实时媒体内视音频协调法，特别涉及一种基于安卓平台的实时媒体内视音频协调法，属于实时视音频协调


技术介绍

[0002]随着安卓移动终端的大量普及和移动互联网的快速发展，人们对于视音频移动通信的质量要求日益提高，不仅要求能通过移动终端来进行实时传输，更要求播放时的视音频质量高且媒体流内的同步协调效果好。但长期以来，对于实时媒体内视音频同步的研发主要集中在专业的视频设备和PC端上，有着设备成本高、便捷性不好的缺点。而现有技术的移动端视音频同步研发也还停留在视频播放器和媒体传输框架上，并没有解决因安卓设备性能的局限性、移动网络的干扰、带宽不足不稳定等所造成的实时视音频不同步问题。为了解决上述问题，亟需一种基于移动平台的实时媒体内视音频协调法。
[0003]视音频协调同步标准定义：视音频多媒体数据协调同步，即要使各媒体流在网络传输中，多媒体数据单元内部的时间差，在人们不能明显感觉出来的许可范围内，由于文本、图片和表格是独立于时间的，而音频、视频的媒体间有严格的时间关联性，多媒体数据具有的同步约束关系概括为基于内容、空间和时间同步的约束关系，多媒体流在实际的传输中，由于网络环境的不稳定和所经过的网络结点不同，导致相邻的媒体单元不能按发送顺序或一定的时间差抵达接受端，即产生了偏移。对于媒体内的偏移，音频或视频的时延应小于250ms，时延抖动的许可范围为10ms，在该范围内，则认为单个媒体流在媒体内是同步的。
[0004]媒体流内同步是按照一定的时间要求传输每个数据单元，保证单条媒体流内的数据单元保存恒定的时间间隔关系，从感知上表现为单条媒体流播放的连续性。媒体流内同步的质量不仅和传输的单个数据包大小有关，而且和网络拓扑结构及网络环境质量有关，媒体流内同步从以下二方面考虑。
[0005]一方面，给数据单元打上顺序标签，媒体内数据单元的乱序是由于前后相邻的数据包可能选择不同的链路，造成一定时间范围内，先发送传输出去的数据单元有可能晚于后发送的数据单元抵达接收端，如果直接由接收端解包、解码播放的话，会造成花屏、图像闪动等现象或根本无法播放，为保证媒体流按正常的顺序播放，在发送端同步发送单个媒体流时，按顺序给数据包打上线性增大标签，接收端根据数据包的标签正确排序后，再送入解码播放模块。
[0006]另一方面，接收端设置缓冲区，时延和时延抖动不能避免，由时延抖动造成的不同步通过在接收端设置的缓冲区来减少抖动，当媒体流在缓冲区中存储到一定数量时，调整乱序后解码播放，在一定范围内减少时延抖动的影响，也能更方便的控制输出的播放速度，使数据单元按照一定的时间间隔依次输出，在实时性要求较高时，缓冲区设置的过大会增大延时，影响实时性需求，并且无线设备终端也有自身的硬件限制；缓冲区过小，会使后续抵达的数据包不能及时接收，影响同步，由于网络环境变化和时钟频率等原因，为防止接收
端的缓冲区数据上溢或枯竭，也需要对缓冲区进行有效控制，接收端采取定时检测缓冲区占用情况的方式，来控制时钟频率加快或变慢，使媒体数据包能在不丢包的情况下连续进行输出，抵达媒体内同步。
[0007]现有技术的视音频同步方法主要有：时间戳同步法、同步信道法、音频嵌入视频的同步机制、基于RTP/RTCP的同步方法等。时间戳同步法主要是接收端比较音频、视频的时间戳与参考时钟的差值偏移量进行调整，但这种方法对于参考时间的选取，主要还是通过发送端发送媒体包的系统时间确定，发送端与接收端之间的系统时钟偏差对视音频同步有较大影响，音频嵌入视频的同步机制实现视音频数据同步抵达接收端，但音频嵌入视频加大了计算复杂度，不方便对音频或视频单独的处理控制，同步信道法将媒体数据流的传输和同步控制分离，利用同步信道技术达到媒体同步，但这种分开传输需要额外的信道开销，基于RTP/RTCP的同步方法主要是通过RTCP传送控制分组，利用监控机制动态调节数据的传输速率。
[0008]现有技术提出了安卓平台上的OpenCore多媒体框架，并对解码器进行优化，但存在两个缺点，一方面，该框架支持的格式很有限；另一方面，在功能和应用扩展上也有一定的难度。有通过消除抖动来提高视音频同步的策略，但这种方式只适用于移动设备上非实时操作系统中。
[0009]现有技术依然没有解决安卓平台的实时媒体内视音频协调问题，现有技术的难点和本专利技术解决的问题主要集中在以下方面：
[0010]第一，长期以来对于实时媒体内视音频同步的研发主要集中在专业的视频设备和PC端上，有着设备成本高、便捷性不好的缺点，而现有技术的移动端视音频同步研发也还停留在视频播放器和媒体传输框架上，并没有解决因安卓设备性能的局限性、移动网络的干扰、带宽不足不稳定等所造成的实时视音频不同步问题；
[0011]第二，基于音频时间戳同步控制播放的传统方法主要采取音频流为主流，视频流为从流，每抵达一个视频帧依次与正在播放或即将播放的音频帧时间戳对比，直到符合
±
80ms的同步范围才进行播放，这种方式很可能因为新抵达的视频帧也符合同步范围，而播放下一视频帧，在因网络拥塞造成媒体丢包时，视频帧为了同步于音频帧的时间戳，对比次数会明显增多，系统消耗很大，并且没有一个反馈调节减少丢包的机制，严重影响了视音频间的同步，现有技术的这些弊端对于安卓平台的视音频同步有致命性的负面影响；
[0012]第三，现有技术对实时媒体内的同步处理只是在接收端设置缓存区来对时延抖动和输出速率进行调节，对于丢包时产生的媒体内不同步，并没有对应的处理机制，如果在网络拥塞时依旧采用原有的发送速率，会导致网络负载更严重，丢包率增大，不利于后续的同步处理；
[0013]第四，实时视音频的传输采用无连接UDP的方式，由于网络拓扑结构不同，前后相邻的数据包会选择不同的链路，造成在一定时间范围内，先发送传输出去的数据包晚于后发送的数据包抵达接收端，这种尽力交付有不保证数据包能按顺序抵达接收端的缺点，发送端甚至无法得知已发送的数据包是否正确完整送达，所以先要将乱序抵达的RTP数据包采取排序处理，音频包采用一个音频帧的NALU封装成一个RTP包的单纯封包方式，但视频包可能由于一帧的NALU长度过大而采取分片封包方式，即将一帧的NALU封成多个RTP包，而接收端在解码时需要接收到完整的一帧后才能正常的解码，如果对接收到的数据包直接进行
解码播放，会造成花屏、图像闪动现象或导致根本无法播放；
[0014]第五，造成实时媒体流内的不同步原因中主要是因为网络负载量大，导致网络拥塞，从而使数据包的丢失、数据干扰错误或产生较大时延抖动，现有技术主要是在接收端设置缓存区的方式来缓解时延抖动问题，但在发生网络拥塞时，传输过多的数据包会导致网络吞吐量急速下降，如果发送方继续发送大量数据，只会使端到端的数据包延时增大、丢包率急速上升，由于实时流媒体的传输大都采用UDP方式，只是对数据包的尽力交付，没有确认重传机制，导致数据包的丢失不可恢复，目前视音频同步中，接收端对丢包的处理大都还是本文档来自技高网...

【技术保护点】

【技术特征摘要】
1.基于安卓平台的实时媒体内视音频协调法，其特征在于，从媒体内对安卓平台实时视音频同步协调策略进行改进，采取对乱序抵达的媒体包排序的方法，通过接收端判断丢包原因，针对性的利用RTCP反馈调节发送端的发送速率，从根本上减少丢包，提高媒体内视音频的同步性；采用适用于安卓平台的视音频封包策略，根据IP网络特征在发送端采取有选择的分片封包，对于单个媒体流单元的时延抖动和乱序处理，采用在接收端设置一级缓存区，在缓存区中通过对比视音频包的序列号，对不可靠传输造成的乱序包进行解包、排序和组帧，在组帧后再逐帧解码播放，视频帧在传输时进行了分片处理，组帧主要是对视频的组帧；采用反馈调节机制调节发送端的发送速率，在接收端判断发生丢包现象时，先判断丢包类型，对网络拥塞造成的丢包采用流量和拥塞控制策略，网络环境和丢包现象均通过RTCP包中的SR包和RR包进行检测，接收端根据SR包的信息和RTP包的序列号计算出丢包率信息，然后把丢包率与时间戳信息通过RR包反馈给发送端，发送端再根据反馈信息和改进后的吞吐模型来调节发送速率，减少丢包率，使实时视音频媒体内达到协调同步；控制RTCP发包间隔：RTCP协议与RTP协议一起使用，与RTP数据包使用相同的传输机制，最终通过接收者报告RR包，将数据包的传输质量反馈给发送端，本发明动态调节发送端的发送速率，控制发送端周期性发送SR包，接收端一旦收到SR包，通过包中的时间戳、发包数量、发送数据总长度信息分析网络质量，然后立即将检测分析出的RTP数据包的丢包率、丢包数量、间隔延时信息，封装到RR包中反馈给发送端，发送端最后根据RR包得到接收端接收到SR包时间TLSR、接收到SR包到发送RR包的延时处理时间TDLSR以及丢包时间发生率r，通过计算的出回环时间RTT、重传时间TO和平滑后的丢包率，利用改进后的吞吐率公式得出此时应有的发送速率进行调节，达到通过控制流量和拥塞，减少RTP数据包的丢包率；通过RTCP包中的发送数据统计信息，估算每个参与者的带宽以及所发送RTP数据包的接收情况，发送端同时发送RTP数据包和发送端报告SR包，本发明控制RTCP包的发送间隔，保证RTP数据包的传输质量，发送RTCP控制包的时间间隔规则包括：规则一，发送RTCP包的时间间隔和参与终端数目成正比，参与传输会话的终端数量越多，发送RTCP包的时间间隔应越长；规则二，最小的时间间隔为5秒，若发送端之前从未发送过RTCP包，第一次发送的RTCP包间隔设置为最小时间间隔的一半，即2.5秒；规则三，避免所有参与终端同步发送RTCP包，所发送的RTCP包时间间隔，是根据计算得到时间间隔的0.5至1倍之间的任意值；规则四，计算出的时间间隔跟参与的终端数量相关，每当有新的参与者加入或离开会话时，都重新计算下一个RTCP包的发送时间；规则五，RTCP传输的带宽应该为会话带宽的5％，其中发送端占有25％的带宽，若发送端的数目超过25％，那么所分给它的RTCP带宽也相应增加。2.根据权利要求1所述的基于安卓平台的实时媒体内视音频协调法，其特征在于，音频封包策略和方法：采用的音频编解码格式为AMR，采用采样频率8000Hz，帧率为每帧20毫秒，AMR12.2规格的方式，即音频数据的编码速率是12.2Kbit/s，每秒采样的音频数据大小是30.5字节，最后加上1个字节的AMR帧头取整后，整个压缩后的数据帧大小为32个字节，采样单个AMR音频帧封包为一个RTP包，直接将一帧AMR数据加上RTP包头发送，时间戳的自增量
为：8000*0.02＝160，即每个RTP包的时间戳依次增加160，序列号也依次自增1。3.根据权利要求1所述的基于安卓平台的实时媒体内视音频协调法，其特征在于，视频封包策略和方法：采用H264视频编解码标准，本发明在移动终端进行分片，根据IP网络的特征，对NALU的数据长度进行控制，在减去RTP、UDP、IP包头后，RTP中的多媒体数据NALU长度只能小于1460字节，视频主帧大小在10KB至30KB，辅帧的大小依据画面的变化幅度改变，视频一帧大小大于1460字节时，对其进行分片封包；本发明对视频帧采取的封包方式是同时采取单纯NALU封包和分片封包中的FU
‑
A方式，第一，从本地缓存的Local Socket中取出已经过H264编码后的视频流，视频流由多个NALU组成，循环读取视频流直到找到一个完整的NALU，对完整NALU的长度进行判断，如果该NALU的长度小于1460字节，就采取第一种单纯NALU封包的方式，去除NAL单元的起始码0x000001，直接把当前一帧的NALU封装成一个RTP包，包括一个字节长度的NALU头；如果该NALU的长度大于1460字节，则采取第三种FU
‑
A分片封包的方式，把当前一个NALU单元拆分成单个满足长度小于1460字节的NALU，其中1460字节长度中包括2字节的FU indicator和FU header，以及1458字节的媒体数据，再对这若干个NALU分别进行RTP封包，最后按照序号顺序依次发送，由于分成若干个RTP包的NALU为同一时刻采集，虽然RTP包序号依次加1，但时间戳均为同一时间戳，在接收端收到视频帧后，对视频每一帧具体的处理有以下步骤：步骤一，循环读取已经H264编码后的视频流，直到找到一个NALU的起始码0x000001和下一个NALU的起始码，若找到则继续步骤二；步骤二，判断当前NALU包括NALU头长度L，若L≤1460字节，则把当前NALU封成一个RTP包，封包时的NALU包括NALU头，但不包括起始码部分，若L＞1460字节，则继续步骤三；步骤三，将当前的NALU长度L减去1458字节的数据后，分成两个包，将分出去1458字节的NALU加上2个字节的NALU头，封成一个RTP包，返回步骤二。4.根据权利要求1所述的基于安卓平台的实时媒体内视音频协调法，其特征在于，乱序包的排序方法：先判断数据包的类型，如果是音频包，只用在缓存区对音频数据单元按照序列号排序，然后送入解码模块，如果判断是视频包，还要进行视频帧组装后，再送入解码模块，在接收端分别为音频数据包和视频数据包设计一个链表来进行缓存；音频包和视频包分别采用两个信道分开传输给接受端的不同端口，多媒体包在抵达接受端时，视音频包已完全区分开，接收端需要首先去掉IP包头、UDP包头，根据多媒体包的序列号排序，将分离出RTP有效负载数据NAL单元放入一级缓存链表，同时把解包所得的时间戳和序列号信息也一起放入缓存结点中，H264视频包事先发送时进行过分片，封包时均去除了起始码0x000001，直接把其后的NALU数据进行封包，先对NALU数据进行组帧，再将视频一帧一帧送入解码模块；实时多媒体包采用UDP方式导致抵达接收端时，在去除掉IP包头和UDP包头后，先根据序列号对数据包进行排序，有效数据负载再存入一级缓存中，同时把RTP数据包的序列号和时间戳也存入对应的结点，本发明通过比对当前RTP包的序列号和链表结点中的序列号，将当前RTP包插入适当的位置，最后进行组帧及解码，一级缓冲是由一个一个的结点组成的数据链表，分别为音频包和视频包定义300个缓冲结点，在单个结点单元里存储事先取出的RTP包的序列号、时间戳和RTP包数据，一级缓存区一边接收解析好的RTP包，一边把排序好的RTP包推送给下一个模块进行组帧解码，采用生产者消费者的模式，在接受RTP包时，先申
请一个结点资源进行存储，在推送给下一个模块后，释放一个结点资源，如果缓冲区溢出，通过加快推送给下一个模块的速率，来释放更多的结点资源；排序的具体流程为：当接收端收到一个RTP包，首先判断RTP包的序列号是否有效，有效的衡量标准是：当前收到RTP包的序列号SN大于上一个刚推送给组帧解码模块的序列号Num，若SN小于Num，则说明该RTP包延时太大，直接认为该RTP包丢失，不对其进行组帧解码，若判断当前RTP包的序列号有效，则继续把当前RTP包的序列号SN与其它结点进行比较，最终插入到合适的结点位置。5.根据权利要求1所述的基于安卓平台的实时媒体内视音频协调法，其特征在于，视音频的组帧方法：音频的封装是一个音频帧封装成一个RTP，只需要去掉RTP包头即可，主要对H264的视频分片帧进行组帧，视频包在通过序列号排序后，在解码前还原成原始的NALU数据单元；首先获取一个分片包中FU indicator的类型域，如果值为28，说明是进行FU
‑
A分片过的包，否则为单纯的NALU封包的视频包，若是分片过的包，首先判断FU header的前三位S、E、R的值，如果S＝1，E＝0，R＝0，则表示为该NALU单元的第一个分片包，需要对第一个包去掉RTP包头和FU header，然后在NALU数据前加上4个字节的起始码0x00000001；如果S＝0，E＝0，R＝0，则表示该分片包为中间一段的分片包，在去掉RTP包头后，还要去掉2个字节的FU indicator和FU header；如果S＝0，E＝1，R＝0，则表示该分片包为这个NALU单元的最后一个数据包，同样也去掉RTP包头、FU indicator和FU header，若是单纯NALU封包的视频包，直接去掉RTP包头后，在NALU数据前加上4个字节的起始码，组帧后的视频帧还原成原始的NALU数据单元，再把视频帧送到解码模块。6.根据权利要求1所述的基于安卓平台的实时媒体内视音频协调法，其特征在于，媒体内视音频同步方...

【专利技术属性】
技术研发人员：李蕊男，高宏松，
申请(专利权)人：李蕊男，
类型：发明
国别省市：