CN113099310A - 基于安卓平台的实时媒体内视音频协调法 - Google Patents
基于安卓平台的实时媒体内视音频协调法 Download PDFInfo
- Publication number
- CN113099310A CN113099310A CN202110379910.5A CN202110379910A CN113099310A CN 113099310 A CN113099310 A CN 113099310A CN 202110379910 A CN202110379910 A CN 202110379910A CN 113099310 A CN113099310 A CN 113099310A
- Authority
- CN
- China
- Prior art keywords
- packet
- sending
- video
- data
- time
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims description 80
- 230000005540 biological transmission Effects 0.000 claims abstract description 104
- 238000011217 control strategy Methods 0.000 claims abstract description 10
- 230000007246 mechanism Effects 0.000 claims description 27
- 239000012634 fragment Substances 0.000 claims description 24
- 238000009432 framing Methods 0.000 claims description 24
- 238000004806 packaging method and process Methods 0.000 claims description 21
- 238000012545 processing Methods 0.000 claims description 21
- 238000013467 fragmentation Methods 0.000 claims description 16
- 238000006062 fragmentation reaction Methods 0.000 claims description 16
- 238000004364 calculation method Methods 0.000 claims description 12
- 230000000694 effects Effects 0.000 claims description 12
- 238000012163 sequencing technique Methods 0.000 claims description 12
- 238000009499 grossing Methods 0.000 claims description 11
- 238000005538 encapsulation Methods 0.000 claims description 10
- 230000033228 biological regulation Effects 0.000 claims description 8
- 238000012790 confirmation Methods 0.000 claims description 7
- 230000001276 controlling effect Effects 0.000 claims description 6
- 230000009123 feedback regulation Effects 0.000 claims description 6
- 230000008569 process Effects 0.000 claims description 6
- 238000005070 sampling Methods 0.000 claims description 6
- 230000008859 change Effects 0.000 claims description 4
- 230000006872 improvement Effects 0.000 claims description 3
- 238000005259 measurement Methods 0.000 claims description 3
- 230000009467 reduction Effects 0.000 claims description 3
- 230000001105 regulatory effect Effects 0.000 claims description 3
- 238000007789 sealing Methods 0.000 claims description 3
- 230000001360 synchronised effect Effects 0.000 description 13
- 208000037265 diseases, disorders, signs and symptoms Diseases 0.000 description 8
- 238000002474 experimental method Methods 0.000 description 8
- 230000007547 defect Effects 0.000 description 7
- 238000010586 diagram Methods 0.000 description 6
- 238000012827 research and development Methods 0.000 description 4
- 238000005516 engineering process Methods 0.000 description 3
- 238000003672 processing method Methods 0.000 description 3
- 230000008901 benefit Effects 0.000 description 2
- 238000004891 communication Methods 0.000 description 2
- 230000006835 compression Effects 0.000 description 2
- 238000007906 compression Methods 0.000 description 2
- 238000013461 design Methods 0.000 description 2
- NMEHNETUFHBYEG-IHKSMFQHSA-N tttn Chemical compound C([C@@H](C(=O)N[C@@H]([C@@H](C)CC)C(=O)N[C@@H](CC=1C=CC(O)=CC=1)C(=O)N[C@@H](CO)C(=O)N[C@@H](CC=1NC=NC=1)C(=O)N[C@@H](CC=1C=CC=CC=1)C(=O)N[C@@H](CCCCN)C(=O)N[C@@H](CCC(N)=O)C(=O)N[C@@H](C)C(=O)N[C@@H]([C@@H](C)O)C(=O)N[C@@H](C(C)C)C(=O)NCC(=O)N[C@@H](CC(O)=O)C(=O)N[C@@H](C(C)C)C(=O)N[C@@H](CC(N)=O)C(=O)N[C@@H]([C@@H](C)O)C(=O)N[C@@H](CC(O)=O)C(=O)N[C@@H](CCCNC(N)=N)C(=O)N1[C@@H](CCC1)C(=O)NCC(=O)N[C@@H](CC(C)C)C(=O)N[C@@H](CC(C)C)C(=O)N[C@@H](CC(O)=O)C(=O)N[C@@H](CC(C)C)C(=O)N[C@@H](CCCCN)C(O)=O)NC(=O)[C@H](CC(C)C)NC(=O)[C@H](CCSC)NC(=O)[C@H](CCC(O)=O)NC(=O)[C@H](CCC(O)=O)NC(=O)[C@H](CC(O)=O)NC(=O)[C@@H](NC(=O)[C@H]1N(CCC1)C(=O)[C@H](CCC(N)=O)NC(=O)[C@@H](N)[C@@H](C)O)[C@@H](C)O)C1=CC=CC=C1 NMEHNETUFHBYEG-IHKSMFQHSA-N 0.000 description 2
- 208000032369 Primary transmission Diseases 0.000 description 1
- 238000004458 analytical method Methods 0.000 description 1
- 238000013459 approach Methods 0.000 description 1
- 230000003139 buffering effect Effects 0.000 description 1
- 238000010276 construction Methods 0.000 description 1
- 238000007796 conventional method Methods 0.000 description 1
- 230000003247 decreasing effect Effects 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 230000004069 differentiation Effects 0.000 description 1
- 230000003631 expected effect Effects 0.000 description 1
- 230000006870 function Effects 0.000 description 1
- 238000010295 mobile communication Methods 0.000 description 1
- 238000012544 monitoring process Methods 0.000 description 1
- 230000010355 oscillation Effects 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client
- H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
- H04N21/643—Communication protocols
- H04N21/6437—Real-time Transport Protocol [RTP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
- H04N21/4302—Content synchronisation processes, e.g. decoder synchronisation
- H04N21/4305—Synchronising client clock from received content stream, e.g. locking decoder clock with encoder clock, extraction of the PCR packets
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client
- H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
- H04N21/647—Control signaling between network components and server or clients; Network processes for video distribution between server and clients, e.g. controlling the quality of the video stream, by dropping packets, protecting content from unauthorised alteration within the network, monitoring of network load, bridging between two different networks, e.g. between IP and wireless
- H04N21/64723—Monitoring of network processes or resources, e.g. monitoring of network load
- H04N21/64738—Monitoring network characteristics, e.g. bandwidth, congestion level
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client
- H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
- H04N21/647—Control signaling between network components and server or clients; Network processes for video distribution between server and clients, e.g. controlling the quality of the video stream, by dropping packets, protecting content from unauthorised alteration within the network, monitoring of network load, bridging between two different networks, e.g. between IP and wireless
- H04N21/64784—Data processing by the network
- H04N21/64792—Controlling the complexity of the content stream, e.g. by dropping packets
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
- H04N21/85—Assembly of content; Generation of multimedia applications
- H04N21/854—Content authoring
- H04N21/8547—Content authoring involving timestamps for synchronizing content
Landscapes
- Engineering & Computer Science (AREA)
- Multimedia (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本发明通过设置一级缓存区，减缓网络环境不佳时对视音频包所造成的时延抖动，为保证视音频流的实时性所采用的UDP传输方式，会导致视音频包乱序达到接收端，而在一级缓存区中，通过对比视音频包的序列号，对不可靠传输造成的乱序包进行解包、排序和组帧，然后在发生丢包现象时，先判断丢包类型，对网络拥塞所造成的丢包采用流量和拥塞控制策略，网络环境和丢包现象均通过RTCP包中的SR包和RR包来进行检测，接收端通过SR包计算出丢包率和回环时间，再将计算出的信息通过RR包反馈给发送端，发送端再根据反馈信息和改进后的吞吐模型来调节发送速率，减少丢包率，使卓平台的实时媒体内视音频达到同步。
Description
技术领域
本发明涉及一种实时媒体内视音频协调法，特别涉及一种基于安卓平台的实时媒体内视音频协调法，属于实时视音频协调技术领域。
背景技术
随着安卓移动终端的大量普及和移动互联网的快速发展，人们对于视音频移动通信的质量要求日益提高，不仅要求能通过移动终端来进行实时传输，更要求播放时的视音频质量高且媒体流内的同步协调效果好。但长期以来，对于实时媒体内视音频同步的研发主要集中在专业的视频设备和PC端上，有着设备成本高、便捷性不好的缺点。而现有技术的移动端视音频同步研发也还停留在视频播放器和媒体传输框架上，并没有解决因安卓设备性能的局限性、移动网络的干扰、带宽不足不稳定等所造成的实时视音频不同步问题。为了解决上述问题，亟需一种基于移动平台的实时媒体内视音频协调法。
视音频协调同步标准定义：视音频多媒体数据协调同步，即要使各媒体流在网络传输中，多媒体数据单元内部的时间差，在人们不能明显感觉出来的许可范围内，由于文本、图片和表格是独立于时间的，而音频、视频的媒体间有严格的时间关联性，多媒体数据具有的同步约束关系概括为基于内容、空间和时间同步的约束关系，多媒体流在实际的传输中，由于网络环境的不稳定和所经过的网络结点不同，导致相邻的媒体单元不能按发送顺序或一定的时间差抵达接受端，即产生了偏移。对于媒体内的偏移，音频或视频的时延应小于250ms，时延抖动的许可范围为10ms，在该范围内，则认为单个媒体流在媒体内是同步的。
媒体流内同步是按照一定的时间要求传输每个数据单元，保证单条媒体流内的数据单元保存恒定的时间间隔关系，从感知上表现为单条媒体流播放的连续性。媒体流内同步的质量不仅和传输的单个数据包大小有关，而且和网络拓扑结构及网络环境质量有关，媒体流内同步从以下二方面考虑。
一方面，给数据单元打上顺序标签，媒体内数据单元的乱序是由于前后相邻的数据包可能选择不同的链路，造成一定时间范围内，先发送传输出去的数据单元有可能晚于后发送的数据单元抵达接收端，如果直接由接收端解包、解码播放的话，会造成花屏、图像闪动等现象或根本无法播放，为保证媒体流按正常的顺序播放，在发送端同步发送单个媒体流时，按顺序给数据包打上线性增大标签，接收端根据数据包的标签正确排序后，再送入解码播放模块。
另一方面，接收端设置缓冲区，时延和时延抖动不能避免，由时延抖动造成的不同步通过在接收端设置的缓冲区来减少抖动，当媒体流在缓冲区中存储到一定数量时，调整乱序后解码播放，在一定范围内减少时延抖动的影响，也能更方便的控制输出的播放速度，使数据单元按照一定的时间间隔依次输出，在实时性要求较高时，缓冲区设置的过大会增大延时，影响实时性需求，并且无线设备终端也有自身的硬件限制；缓冲区过小，会使后续抵达的数据包不能及时接收，影响同步，由于网络环境变化和时钟频率等原因，为防止接收端的缓冲区数据上溢或枯竭，也需要对缓冲区进行有效控制，接收端采取定时检测缓冲区占用情况的方式，来控制时钟频率加快或变慢，使媒体数据包能在不丢包的情况下连续进行输出，抵达媒体内同步。
现有技术的视音频同步方法主要有：时间戳同步法、同步信道法、音频嵌入视频的同步机制、基于RTP/RTCP的同步方法等。时间戳同步法主要是接收端比较音频、视频的时间戳与参考时钟的差值偏移量进行调整，但这种方法对于参考时间的选取，主要还是通过发送端发送媒体包的系统时间确定，发送端与接收端之间的系统时钟偏差对视音频同步有较大影响，音频嵌入视频的同步机制实现视音频数据同步抵达接收端，但音频嵌入视频加大了计算复杂度，不方便对音频或视频单独的处理控制，同步信道法将媒体数据流的传输和同步控制分离，利用同步信道技术达到媒体同步，但这种分开传输需要额外的信道开销，基于RTP/RTCP的同步方法主要是通过RTCP传送控制分组，利用监控机制动态调节数据的传输速率。
现有技术提出了安卓平台上的OpenCore多媒体框架，并对解码器进行优化，但存在两个缺点，一方面，该框架支持的格式很有限；另一方面，在功能和应用扩展上也有一定的难度。有通过消除抖动来提高视音频同步的策略，但这种方式只适用于移动设备上非实时操作系统中。
现有技术依然没有解决安卓平台的实时媒体内视音频协调问题，现有技术的难点和本发明解决的问题主要集中在以下方面：
第一，长期以来对于实时媒体内视音频同步的研发主要集中在专业的视频设备和PC端上，有着设备成本高、便捷性不好的缺点，而现有技术的移动端视音频同步研发也还停留在视频播放器和媒体传输框架上，并没有解决因安卓设备性能的局限性、移动网络的干扰、带宽不足不稳定等所造成的实时视音频不同步问题；
第二，基于音频时间戳同步控制播放的传统方法主要采取音频流为主流，视频流为从流，每抵达一个视频帧依次与正在播放或即将播放的音频帧时间戳对比，直到符合±80ms的同步范围才进行播放，这种方式很可能因为新抵达的视频帧也符合同步范围，而播放下一视频帧，在因网络拥塞造成媒体丢包时，视频帧为了同步于音频帧的时间戳，对比次数会明显增多，系统消耗很大，并且没有一个反馈调节减少丢包的机制，严重影响了视音频间的同步，现有技术的这些弊端对于安卓平台的视音频同步有致命性的负面影响；
第三，现有技术对实时媒体内的同步处理只是在接收端设置缓存区来对时延抖动和输出速率进行调节，对于丢包时产生的媒体内不同步，并没有对应的处理机制，如果在网络拥塞时依旧采用原有的发送速率，会导致网络负载更严重，丢包率增大，不利于后续的同步处理；
第四，实时视音频的传输采用无连接UDP的方式，由于网络拓扑结构不同，前后相邻的数据包会选择不同的链路，造成在一定时间范围内，先发送传输出去的数据包晚于后发送的数据包抵达接收端，这种尽力交付有不保证数据包能按顺序抵达接收端的缺点，发送端甚至无法得知已发送的数据包是否正确完整送达，所以先要将乱序抵达的RTP数据包采取排序处理，音频包采用一个音频帧的NALU封装成一个RTP包的单纯封包方式，但视频包可能由于一帧的NALU长度过大而采取分片封包方式，即将一帧的NALU封成多个RTP包，而接收端在解码时需要接收到完整的一帧后才能正常的解码，如果对接收到的数据包直接进行解码播放，会造成花屏、图像闪动现象或导致根本无法播放；
第五，造成实时媒体流内的不同步原因中主要是因为网络负载量大，导致网络拥塞，从而使数据包的丢失、数据干扰错误或产生较大时延抖动，现有技术主要是在接收端设置缓存区的方式来缓解时延抖动问题，但在发生网络拥塞时，传输过多的数据包会导致网络吞吐量急速下降，如果发送方继续发送大量数据，只会使端到端的数据包延时增大、丢包率急速上升，由于实时流媒体的传输大都采用UDP方式，只是对数据包的尽力交付，没有确认重传机制，导致数据包的丢失不可恢复，目前视音频同步中，接收端对丢包的处理大都还是通过重复播放同一帧的方式，在少量丢包的情况下，使用户在观看过程中察觉不到对同步的影响，但在大量丢包的情况下依旧这样处理，会导致播放的视音频产生明显的卡顿感，给用户带来不佳的观看体验
发明内容
针对现有技术的不足，本发明分析安卓平台的实时视频音频同步背景，包括现有技术实时视频音频传输的同步技术、视频音频的同步标准、影响同步的因素，分析视频音频媒体间同步技术的特点，通过实时传输协议RTP、实时传输控制协议RTCP和实时流传输协议RTSP，选取适用于安卓平台和移动环境下的视频音频RTP封包策略，建立适用于移动终端的实时视频音频传输，模仿TCP协议中对流量和拥塞进行控制，并根据无线环境的特点加以改进拥塞控制策略，使之更适合传输UDP协议的数据包，从源头上减少丢包率，提高视音频的同步质量。
为达到以上技术效果，本发明所采用的技术方案如下：
基于安卓平台的实时媒体内视音频协调法，进一步的，
基于安卓平台的实时媒体内视音频协调法，从媒体内对安卓平台实时视音频同步协调策略进行改进，采取对乱序抵达的媒体包排序的方法，通过接收端判断丢包原因，针对性的利用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带宽也相应增加。
基于安卓平台的实时媒体内视音频协调法，进一步的，音频封包策略和方法：采用的音频编解码格式为AMR，采用采样频率8000Hz，帧率为每帧20毫秒，AMR12.2规格的方式，即音频数据的编码速率是12.2Kbit/s，每秒采样的音频数据大小是30.5字节，最后加上1个字节的AMR帧头取整后，整个压缩后的数据帧大小为32个字节，采样单个AMR音频帧封包为一个RTP包，直接将一帧AMR数据加上RTP包头发送，时间戳的自增量为：8000*0.02＝160，即每个RTP包的时间戳依次增加160，序列号也依次自增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包，返回步骤二。
基于安卓平台的实时媒体内视音频协调法，进一步的，乱序包的排序方法：先判断数据包的类型，如果是音频包，只用在缓存区对音频数据单元按照序列号排序，然后送入解码模块，如果判断是视频包，还要进行视频帧组装后，再送入解码模块，在接收端分别为音频数据包和视频数据包设计一个链表来进行缓存；
音频包和视频包分别采用两个信道分开传输给接受端的不同端口，多媒体包在抵达接受端时，视音频包已完全区分开，接收端需要首先去掉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与其它结点进行比较，最终插入到合适的结点位置。
基于安卓平台的实时媒体内视音频协调法，进一步的，视音频的组帧方法：音频的封装是一个音频帧封装成一个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数据单元，再把视频帧送到解码模块。
基于安卓平台的实时媒体内视音频协调法，进一步的，媒体内视音频同步方法的改进：模仿TCP协议中对流量和拥塞进行控制，并根据无线环境的特点加以改进拥塞控制策略，使之更适合传输UDP协议的数据包，从源头上减少丢包率，提高视音频的同步质量；
采用UDP的拥塞控制方法主要是从以下两个方面：一方面是基于控制窗口发送数据量来达到拥塞控制，通过参考TCP协议中的拥塞控制，在网络环境好的情况下，根据算法适当增大发送窗口；当检测到出现网络拥塞时，根据算法减小发送窗口和拥塞窗口；另一方面是基于速率的拥塞控制的方式，而音频流根据采样频率，视频流根据每秒的帧率，在传输时流媒体数据也基于速率，平滑的控制发送速率，减少丢包；
本发明针对无线网络环境下减少丢包的主要方法是：通过测量相关网络参数，对网络带宽的估算，根据规则明确区分丢包原因，最后根据不同的丢包原因，反馈调整发送速率，达到减少丢包率，改进媒体内同步协调效果。
基于安卓平台的实时媒体内视音频协调法，进一步的，丢包原因的判断追踪算法：采用基于端到端的控制实现区分丢包原因，在没有发生网络丢包的情况下，相邻数据包抵达接收端的时间间隔T是均匀的；发生无线信号干扰造成的丢包则会导致分组的抵达时间间隔至少不小于两倍的T，相邻抵达的数据包序号差与时间间隔成比例；
接收端只需通过数据包序号检测是否丢包，并记录数据包的抵达时间间隔，如果发生丢包现象，则对比数据包抵达的时间间隔，若时间间隔相同，则判定为发生了拥塞丢包；若时间间隔不相等，则判定为发生了无线丢包，随着数据的不断传输，网络负载也随之增大，发生拥塞的可能性也会增加，本发明采用降低判断的临界值，来提高区分丢包的精度，丢包判断式为：
(n+1)TMIN≤TLOST≤(n+1.3)TMINTLOST表示发生丢包现象时，实际分组抵达的时间间隔，若TLOST满足上式，可判断发生了无线丢包；如果不满足条件，可判定发生了拥塞丢包，其中，TMIN表示相邻抵达接收端数据包的最小时间间隔，n表示连续丢失的包数量。
基于安卓平台的实时媒体内视音频协调法，进一步的，基于RTCP网络状态反馈调节发送速率：采用与RTP一起使用的RTCP，发送端将发送者报告SR和RTP数据包一并发送，接收端根据SR包和RTP序列号估算丢包率信息，然后将数据包的传输质量封装成接收者报告RR包，最后反馈给发送端，发送端根据RR包计算出最终的丢包率和回环时间RTT，调节发送速率；
基于速率的TCP-Friendly传输机制模仿TCP协议在拥塞情况下对速率的调节，根据当前的网络状态，平滑的改变发送端的发送速率，同时去除TCP协议中对数据包的确认和重传机制，减少等待确认和重传所带来的延时，满足实时流媒体的传输需求，在TCP-Friendly拥塞控制机制中，本发明采用以Padhye吞吐率模型为基础，依据RTCP协议里接收端发回的接收者报告中的信息，计算出当前网络环境下发送端应有的发送速率，对发送速率进行调节，注重现存TCP流的友好性，平滑改变发送速率，对已有的实时流媒体传输模式RTP/RTCP不会有额外的负担，无需增加额外的信道和数据包用来反馈网络环境，吞吐率模型为：
其中，T是计算出来的发送速率，C为传输的数据包大小，RTT为发送端和接收端之间的数据链路回环时间Round-TripTime，r为丢包事件发生率(0＜r＜1)，TO为重传时钟所设置的时间，e取值1或2，这里取1后吞吐率模型简化为：
根据上式，未知项的值RTT，TO，r都能通过RTCP协议的RR包中的数据计算得到，然后计算出该拥塞环境下发送端的发送速率，首先，RTT的值是从发送端发出数据包开始到收到接收端的确认消息为止，整个在网络链路中所经历的时间，接收端只要收到SR包就会立刻给发送端发送RR包，选取从发送端发出SR包开始到发送端接收到RR包为止的这段时间，作为回环时间，回环时间的计算不包括收到SR包到发送RR包的这段时间，即计算式为：
RTTME＝TNOW-TLS-TDLS其中，RTTME表示通过计算得到的回环时间，TNOW表示接收端收到RR包时的当前时间，TLS是发送端发送SR包的时间，这个值从RR包中的LSR字段中取得NTP时间戳中的32bits，TDLS表示接收端收到SR包到发送RR包之间的时间间隔，从收到的RR包中的DLS字段中取得，实际计算出的回环时间通过下式，通过上一次的回环时间RTTn和这一次计算出的RTTME进行平滑处理，d取0.8，
RTTn+1＝d TTTn+(1-d)RTTME
在TCP的传输中，发送端在发送数据包时设置一个计时器，若在计时器规定的时间内没有收到ACK确认消息，发送端会直接重传数据包，TO为设定的重传时间，UDP协议中不存在确认重传机制，取值为4倍的RTT，表示为：TO＝4RTT；
r表示丢包事件的发生率，接收端通过接收者报告RR包里的丢包率字段获得丢包情况，在采用TCP进行拥塞调节时，系统只要检测到有丢包的情况，不论丢包数目的多少，都认为发生了网络拥塞，直接对发送速率进行调节，大幅度的减少吞吐量，UDP方式对数据包的传输根据上一次的丢包事件发生率rn和RR包里的丢包率rFL，进行加权平滑后再作为r的值，a取0.7，即：
rn+1＝arn+(1-a)rFL
为保证视频帧的低丢包率，避免在媒体间同步时因连续丢包导致过多重复上一个视频帧，对连续丢包数量n上进行控制，一个视频帧的长度最多封成4个包，为避免接收端重复播放上一个视频帧的次数最多不超过3次，当n＞12时，对发送速率进行调节，减少丢包，发送端以慢开始的方式进行发送，然后每收到一个RR包后，如果平滑后的r为0，说明没有发生拥塞丢包，继续慢开始；如果平滑后的r不为0，则根据RR包中的信息取出并计算得到平滑后的RTT、TO及计算出的发送速率T，比较发送速率T与当前的发送速率TM：
第一，如果TM≤T，说明网络还有多余的带宽能够使用，则发送端以min(TM+1/RTT，T)的速率进行发送；
第二，如果TM＞T，则发送端以计算出的T进行发送。
基于安卓平台的实时媒体内视音频协调法，进一步的，基于RTCP网络状态反馈调节发送速率中，发送速率具体的调整算法为：
第一步，发送端发送RTP包和SR包；
第二步，接收端接收RTP包和SR包后，根据连续的包序号检测是否发生丢包，如果检测到存在丢包现象，则到第三步，如果无丢包，则继续第二步；
第三步，计算TMIN、TLOST和n的值，如果满足丢包判断式，则使RR包中的FractionLost＝0，并继续第四步，如果不满足丢包判断式或n＞12时，则继续第四步；
第四步，发送端等待RR包，等到RR包后记录抵达时间TNOW以及当前的发送速率TM，将RR包中的Fraction Lost值存储在rFL中，计算出当前的r，继续第五步；
第五步，判断丢包事件发生率r的大小，若r＝0，发送速率按照慢开始的规则增大，然后返回第四步，若r≠0，继续第六步；
第六步，取出接收到RR包的LSR和DLSR字段的值分别存储于TLS和TDLS中，计算出回环时间RTTME，并计算出平滑后的RTT，继续第七步；
第七步，根据得到TO的值，继续第八步；
第八步，根据前几步得出了RTT、r、TO，计算出速率T，如果TM≤T，则发送端以min(TM+1/RTT，T)的速率进行发送；如果TM＞T，则发送端以T进行发送，最后返回第四步。
基于安卓平台的实时媒体内视音频协调法，进一步的，控制RTCP发包间隔中，间隔的发包时间INVL主要是依据以下部分估算：
依据一，分配给RTCP包的带宽rtcp_bw＝5％*传输会话的总带宽；
依据二，所发送RTCP包的平均大小C；
依据三，参与传输会话的总终端数量Num；
依据四，参与传输会话的发送端数量SendNum；
依据五，最小时间间隔Tmin，第一次发送RTCP包时，Tmin＝2.5s，后续发送时，Tmin＝5s。
与现有技术相比，本发明的贡献和创新点在于：
第一，本发明主要从媒体内对安卓平台实时视音频同步协调策略进行改进，采取对乱序抵达的媒体包排序的方法，通过接收端判断丢包原因，针对性的利用RTCP反馈调节发送端的发送速率，从根本上减少丢包，提高媒体内视音频的同步性。通过实验证实本发明提供的基于安卓平台的实时媒体内视音频协调法，与现有技术的同步策略相比，分别在WiFi和4G/5G环境下的同步协调效果得到提高了31％和28％，在实际应用中可行性很强，是一种简洁高效、实用性强的基于安卓平台的实时媒体内视音频协调法；
第二，本发明采用反馈调节机制调节发送端的发送速率，在接收端判断发生丢包现象时，先判断丢包类型，对网络拥塞造成的丢包采用流量和拥塞控制策略，与TCP方式对流量和拥塞的控制不同的是，网络环境和丢包现象均通过RTCP包中的SR包和RR包进行检测，接收端根据SR包的信息和RTP包的序列号计算出丢包率信息，然后把丢包率与时间戳信息通过RR包反馈给发送端，发送端再根据反馈信息和改进后的吞吐模型来调节发送速率，减少丢包率，使实时视音频媒体内达到协调同步；
第三，为从根本上解决问题，缓解网络拥塞，减少丢包率来提高媒体内同步，本发明模仿TCP协议中对流量和拥塞进行控制，并根据无线环境的特点加以改进拥塞控制策略，使之更适合传输UDP协议的数据包，从源头上减少丢包率，提高视音频的同步质量；
第四，通过实验验证了接收端对数据包的乱序处理以及发送端通过调节发送速率对丢包率的减小，最终达到改善安卓实时媒体内同步协调效果，实验结果显示，接收端的一级缓存有效的对乱序抵达的数据包进行了排序处理，使数据包的序列号按照升序的关系，还原到原有的时间顺序关系，采用传统恒定的发送速率发送数据包，持续10分钟之后测得的丢包率为18.23％，而采用RTCP反馈调节发送速率的实验表明，丢包率通过发送端调节发送速率，最终保持在1％左右，而1％左右的丢包率几乎不影响播放质量和同步协调质量，达到了较好的效果，充分体现本发明的必要性和先进性。
第五，本发明提供基于安卓平台的实时媒体内视音频协调同步策略的具体处理方法，为避免视频帧被任意分片，有选择的对视频帧采取分片封包，并在接收端对乱序抵达的媒体数据包重新进行排序和组帧，分析以往的视音频同步中，接收端对丢包的处理大都还是通过重复播放同一帧的方式，这种方法在大量丢包时，依旧传输过多的数据包，会导致丢包率急速上升，播放的视音频产生明显的卡顿感，给用户带来糟糕的体验，改进后采取接收端检测到丢包现象时，首先判断丢包类型，若为拥塞丢包或连续丢包超过12个，则将丢包信息通过RR包反馈给发送端，发送端根据RR包中的信息和改进后的吞吐模型来调节发送速率，通过减少丢包率，使实时视音频媒体内达到同步。本发明结合安卓移动设备处理性能不高、网络传输环境复杂、带宽不足不稳定导致媒体数据包丢包率高的特点，改进并设计出基于安卓移动平台下的视频音频同步策略，提高移动端上的实时视频音频质量和同步效果。
附图说明
图1是本发明乱序包排序的接收端处理示意图。
图2是本发明乱序包排序的一级缓存及结点结构示意图。
图3是本发明的RTP数据包排序流程示意图。
图4是本发明的视频帧组帧流程示意图。
图5是本发明数据包分组到达时间间隔示意图。
具体实施方式
下面结合附图，对本发明提供的基于安卓平台的实时媒体内视音频协调法的技术方案进行进一步的描述，使本领域的技术人员能够更好的理解本发明并能予以实施。
为了使实时媒体内的同步率提高，本发明采用适用于安卓平台的视音频封包策略，根据IP网络特征在发送端采取有选择的分片封包，避免视频帧被任意分片，导致额外的增加视频包数量，使得端到端的时延增大，影响媒体内的同步质量。对于单个媒体流单元的时延抖动和乱序处理，采用在接收端设置一级缓存区，在缓存区中通过对比视音频包的序列号，对不可靠传输造成的乱序包进行解包、排序和组帧，在组帧后再逐帧解码播放，视频帧在传输时进行了分片处理，组帧主要是对视频的组帧。
现有技术对实时媒体内的同步处理只是在接收端设置缓存区来对时延抖动和输出速率进行调节，对于丢包时产生的媒体内不同步，并没有对应的处理机制，如果在网络拥塞时依旧采用原有的发送速率，会导致网络负载更严重，丢包率增大，不利于后续的同步处理。
本发明采用反馈调节机制调节发送端的发送速率，在接收端判断发生丢包现象时，先判断丢包类型，对网络拥塞造成的丢包采用流量和拥塞控制策略，与TCP方式对流量和拥塞的控制不同的是，网络环境和丢包现象均通过RTCP包中的SR包和RR包进行检测，接收端根据SR包的信息和RTP包的序列号计算出丢包率信息，然后把丢包率与时间戳信息通过RR包反馈给发送端，发送端再根据反馈信息和改进后的吞吐模型来调节发送速率，减少丢包率，使实时视音频媒体内达到协调同步。
一、视音频封包策略和方法
(一)音频封包策略和方法
适用于安卓平台的音频编解码主要有：AMR、AAC、OGG、PCM、MP3，AMR编解码方式多用于人声、通话、实时对讲场景，作为语音类的编解码，由于压缩比大的优势，已经被广泛的用于移动设备中，AMR作为无线电网络通信中的基本编解码方式，对网络环境适应性强，在低带宽的网络中进行传输时，可提供质量较高的语音。由于无线网络环境的限制，为节省带宽和流量，保证语音的实时效果，本发明采用的音频编解码格式为AMR，AMR有二种标准：AMR-NB和AMR-WB，AMR包括8种规格的编码速率，本发明采用采样频率8000Hz，帧率为每帧20毫秒，AMR12.2规格的方式，即音频数据的编码速率是12.2Kbit/s，每秒采样的音频数据大小是30.5字节，最后加上1个字节的AMR帧头取整后，整个压缩后的数据帧大小为32个字节，为了使音频包保持较小的延迟，丢包率尽量减小，保持音频解码及播放的连贯性，本发明采样单个AMR音频帧封包为一个RTP包，直接将一帧AMR数据加上RTP包头发送，时间戳的自增量为：8000*0.02＝160，即每个RTP包的时间戳依次增加160，序列号也依次自增1。
(二)视频封包策略和方法
适用于安卓平台的视频编解码主要有：H263、H264、MPEG-4，H264广泛应用在视频会议、视频通话等场景下，结构简单，易于推广，同时H264压缩编码数据压缩比例较高，因此码率更低，H264采用的分层设计使H264更适应不同的网络传输，尤其适合于无线传输环境，比其它编码方式所需的网络带宽更少，更节省传输时间，同时图像质量也更高，在安卓手机平台得到了广泛应用，所以本发明采用H264视频编解码标准。
IP网络传输允许的最大传输单元MTU为1500个字节，即数据包的长度加上IP包头的长度大于1500个字节时，底层直接按照数据净荷长度1480字节进行分片，然后再把每片的数据分别加上IP包头发送出去。分片对网络性能有较大影响，为避免NALU被任意分片，额外增加视频包的数量，导致通信效率不高，使端到端的时延增大，影响视音频的同步质量。本发明在移动终端进行分片，根据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包，返回步骤二。
二、接收端的乱序处理方法
(一)乱序包的排序方法
实时视音频的传输采用无连接UDP的方式，由于网络拓扑结构不同，前后相邻的数据包会选择不同的链路，造成在一定时间范围内，先发送传输出去的数据包晚于后发送的数据包抵达接收端。这种尽力交付有不保证数据包能按顺序抵达接收端的缺点，发送端甚至无法得知已发送的数据包是否正确完整送达，所以先要将乱序抵达的RTP数据包采取排序处理，音频包采用一个音频帧的NALU封装成一个RTP包的单纯封包方式，但视频包可能由于一帧的NALU长度过大而采取分片封包方式，即将一帧的NALU封成多个RTP包，而接收端在解码时需要接收到完整的一帧后才能正常的解码，如果对接收到的数据包直接进行解码播放，会造成花屏、图像闪动现象或导致根本无法播放。本发明的处理方法是：先判断数据包的类型，如果是音频包，只用在缓存区对音频数据单元按照序列号排序，然后送入解码模块，如果判断是视频包，还要进行视频帧组装后，再送入解码模块，在接收端分别为音频数据包和视频数据包设计一个链表来进行缓存，接收端对RTP处理的如图1所示。
音频包和视频包分别采用两个信道分开传输给接受端的不同端口，多媒体包在抵达接受端时，视音频包已完全区分开，接收端需要首先去掉IP包头、UDP包头，根据多媒体包的序列号排序，将分离出RTP有效负载数据NAL单元放入一级缓存链表，同时把解包所得的时间戳和序列号信息也一起放入缓存结点中，如图2所示，由于H264视频包事先发送时进行过分片，封包时均去除了起始码0x000001，直接把其后的NALU数据进行封包，为避免因数据不全、不是完整的帧格式就进行解码，导致视频不能正常播放，先对NALU数据进行组帧，再将视频一帧一帧送入解码模块。
实时多媒体包采用UDP方式导致抵达接收端时，多媒体包可能会乱序，在去除掉IP包头和UDP包头后，先根据序列号对数据包进行排序，有效数据负载再存入一级缓存中，同时把RTP数据包的序列号和时间戳也存入对应的结点，本发明的方法是，通过比对当前RTP包的序列号和链表结点中的序列号，将当前RTP包插入适当的位置，最后进行组帧及解码，一级缓冲是由一个一个的结点组成的数据链表，分别为音频包和视频包定义300个缓冲结点，在单个结点单元里存储事先取出的RTP包的序列号、时间戳和RTP包数据，一级缓存区一边接收解析好的RTP包，一边把排序好的RTP包推送给下一个模块进行组帧解码，采用生产者消费者的模式，在接受RTP包时，先申请一个结点资源进行存储，在推送给下一个模块后，释放一个结点资源，如果缓冲区溢出，通过加快推送给下一个模块的速率，来释放更多的结点资源。
排序的具体流程如图3所示。当接收端收到一个RTP包，首先判断RTP包的序列号是否有效，有效的衡量标准是：当前收到RTP包的序列号SN大于上一个刚推送给组帧解码模块的序列号Num，若SN小于Num，则说明该RTP包延时太大，直接认为该RTP包丢失，不对其进行组帧解码，若判断当前RTP包的序列号有效，则继续把当前RTP包的序列号SN与其它结点进行比较，最终插入到合适的结点位置。
(二)视音频的组帧方法
音频的封装是一个音频帧封装成一个RTP，只需要去掉RTP包头即可，主要对H264的视频分片帧进行组帧，视频包在通过序列号排序后，在解码前还原成原始的NALU数据单元。主要的组帧流程如图4所示。
首先获取一个分片包中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数据单元，再把视频帧送到解码模块。
三、基于RTCP反馈调节的媒体内同步方法
(一)媒体内视音频同步方法的改进
造成实时媒体流内的不同步原因中主要是因为网络负载量大，导致网络拥塞，从而使数据包的丢失、数据干扰错误或产生较大时延抖动，现有技术主要是在接收端设置缓存区的方式来缓解时延抖动问题，通过缓冲区调整媒体流还原原有的时间间隔，或是改变媒体流的输出速率，但在发生网络拥塞时，传输过多的数据包会导致网络吞吐量急速下降，如果发送方继续发送大量数据，只会使端到端的数据包延时增大、丢包率急速上升。由于实时流媒体的传输大都采用UDP方式，只是对数据包的尽力交付，没有确认重传机制，导致数据包的丢失不可恢复，目前视音频同步中，接收端对丢包的处理大都还是通过重复播放同一帧的方式，在少量丢包的情况下，使用户在观看过程中察觉不到对同步的影响，但在大量丢包的情况下依旧这样处理，会导致播放的视音频产生明显的卡顿感，给用户带来不佳的观看体验。
为从根本上解决问题，缓解网络拥塞，减少丢包率来提高媒体内同步，本发明模仿TCP协议中对流量和拥塞进行控制，并根据无线环境的特点加以改进拥塞控制策略，使之更适合传输UDP协议的数据包，从源头上减少丢包率，提高视音频的同步质量。
采用UDP的拥塞控制方法主要是从以下两个方面：一方面是基于控制窗口发送数据量来达到拥塞控制，通过参考TCP协议中的拥塞控制，在网络环境好的情况下，根据算法适当增大发送窗口；当检测到出现网络拥塞时，根据算法减小发送窗口和拥塞窗口，这种方式在调整发送速率时，如果发生网络拥塞，发送窗口的大小会减半，导致发送速率的变化幅度较大，不够平滑，一般应用于文字或图片传输，并不适合实时流媒体的传输；另一方面是基于速率的拥塞控制的方式，而音频流根据采样频率，视频流根据每秒的帧率，在传输时流媒体数据也基于速率，平滑的控制发送速率，减少丢包，而在无线网络的环境下传输，更加容易受到环境的干扰，导致数据包的丢包率、时延抖动等都会增加，这属于无线丢包，而一般的拥塞丢包主要是由于网络带宽不够而导致数据包的丢失或延时抵达，由于这两种丢包现象产生的原因不同，不能像通常的拥塞控制一样，直接降低发送端的发送速率，在因无线丢包的情况下，可能并没有产生网络拥塞，降低发送速率使吞吐量下降，只会浪费网络带宽资源。
本发明针对无线网络环境下减少丢包的主要方法是：通过测量相关网络参数，对网络带宽的估算，根据规则明确区分丢包原因，最后根据不同的丢包原因，反馈调整发送速率，达到减少丢包率，改进媒体内同步协调效果。
(二)丢包原因的判断追踪算法
本发明采用基于端到端的控制实现区分丢包原因，在没有发生网络丢包的情况下，相邻数据包抵达接收端的时间间隔T是均匀的；发生无线信号干扰造成的丢包则会导致分组的抵达时间间隔至少不小于两倍的T，相邻抵达的数据包序号差与时间间隔成比例。如图5所示，在无线干扰下丢失了2号数据包，1号数据包和3号数据包依旧按顺序抵达接收端，并且它们之间的时间间隔接近于2T，若发生网络拥塞，前后抵达接收端数据包的时间间隔也接近于没有丢包下的T。
接收端只需通过数据包序号检测是否丢包，并记录数据包的抵达时间间隔，如果发生丢包现象，则对比数据包抵达的时间间隔，若时间间隔相同，则判定为发生了拥塞丢包；若时间间隔不相等，则判定为发生了无线丢包，随着数据的不断传输，网络负载也随之增大，发生拥塞的可能性也会增加，本发明采用降低判断的临界值，来提高区分丢包的精度，改进后的示意图如图5如下，丢包判断式为：
(n+1)TMIN≤TLOST≤(n+1.3)TMIN
TLOST表示发生丢包现象时，实际分组抵达的时间间隔，若TLOST满足上式，可判断发生了无线丢包；如果不满足条件，可判定发生了拥塞丢包，其中，TMIN表示相邻抵达接收端数据包的最小时间间隔，n表示连续丢失的包数量。
(三)基于RTCP网络状态反馈调节发送速率
由于UDP方式并不像TCP方式可以通过确认包和时间戳来估算丢包率、回环时间RTT及重传时间TO，于是本发明采用与RTP一起使用的RTCP，发送端将发送者报告SR和RTP数据包一并发送，接收端根据SR包和RTP序列号估算丢包率信息，然后将数据包的传输质量封装成接收者报告RR包，最后反馈给发送端，发送端根据RR包计算出最终的丢包率和回环时间RTT，调节发送速率。
基于速率的TCP-Friendly传输机制模仿TCP协议在拥塞情况下对速率的调节，根据当前的网络状态，平滑的改变发送端的发送速率，同时去除TCP协议中对数据包的确认和重传机制，减少等待确认和重传所带来的延时，满足实时流媒体的传输需求，在TCP-Friendly拥塞控制机制中，本发明采用以Padhye吞吐率模型为基础，依据RTCP协议里接收端发回的接收者报告中的信息，计算出当前网络环境下发送端应有的发送速率，对发送速率进行调节，注重现存TCP流的友好性，平滑改变发送速率，对已有的实时流媒体传输模式RTP/RTCP不会有额外的负担，无需增加额外的信道和数据包用来反馈网络环境，吞吐率模型为：
其中，T是计算出来的发送速率，C为传输的数据包大小，RTT为发送端和接收端之间的数据链路回环时间Round-TripTime，r为丢包事件发生率(0＜r＜1)，TO为重传时钟所设置的时间，e取值1或2，这里取1后吞吐率模型简化为：
根据上式，未知项的值RTT，TO，r都能通过RTCP协议的RR包中的数据计算得到，然后计算出该拥塞环境下发送端的发送速率，首先，RTT的值是从发送端发出数据包开始到收到接收端的确认消息为止，整个在网络链路中所经历的时间，接收端只要收到SR包就会立刻给发送端发送RR包，选取从发送端发出SR包开始到发送端接收到RR包为止的这段时间，作为回环时间，回环时间的计算不包括收到SR包到发送RR包的这段时间，即计算式为：
RTTME＝TNOW-TLS-TDLS
其中，RTTME表示通过计算得到的回环时间，TNOW表示接收端收到RR包时的当前时间，TLS是发送端发送SR包的时间，这个值从RR包中的LSR字段中取得NTP时间戳中的32bits，TDLS表示接收端收到SR包到发送RR包之间的时间间隔，从收到的RR包中的DLS字段中取得，由于网络状态不同，为避免瞬时拥塞，实际计算出的回环时间通过下式，通过上一次的回环时间RTTn和这一次计算出的RTTME进行平滑处理，d取0.8，
RTTn+1＝d TTTn+(1-d)RTTME
在TCP的传输中，发送端在发送数据包时设置一个计时器，若在计时器规定的时间内没有收到ACK确认消息，发送端会直接重传数据包，TO为设定的重传时间，UDP协议中不存在确认重传机制，取值为4倍的RTT，表示为：TO＝4RTT；
r表示丢包事件的发生率，接收端通过接收者报告RR包里的丢包率字段获得丢包情况，在采用TCP进行拥塞调节时，系统只要检测到有丢包的情况，不论丢包数目的多少，都认为发生了网络拥塞，直接对发送速率进行调节，大幅度的减少吞吐量，UDP方式对数据包的传输本来是尽力交付，可能出现瞬时拥塞丢包，应该对丢包事件的发生有更大的容忍性，根据RR报告里检测的小段时间内的丢包率，并不能完全衡量真实的丢包率和网络负载情况。为减少发送速率的振荡幅度和频率，平滑的发送数据包，根据上一次的丢包事件发生率rn和RR包里的丢包率rFL，进行加权平滑后再作为r的值，a取0.7，即：
rn+1＝arn+(1-a)rFL
为保证视频帧的低丢包率，避免在媒体间同步时因连续丢包导致过多重复上一个视频帧，对连续丢包数量n上进行控制，一个视频帧的长度最多封成4个包，为避免接收端重复播放上一个视频帧的次数最多不超过3次，当n＞12时，对发送速率进行调节，减少丢包，发送端以慢开始的方式进行发送，然后每收到一个RR包后，如果平滑后的r为0，说明没有发生拥塞丢包，继续慢开始；如果平滑后的r不为0，则根据RR包中的信息取出并计算得到平滑后的RTT、TO及计算出的发送速率T，比较发送速率T与当前的发送速率TM：
第一，如果TM≤T，说明网络还有多余的带宽能够使用，则发送端以min(TM+1/RTT，T)的速率进行发送；
第二，如果TM＞T，则发送端以计算出的T进行发送。
发送速率具体的调整算法为：
第一步，发送端发送RTP包和SR包；
第二步，接收端接收RTP包和SR包后，根据连续的包序号检测是否发生丢包，如果检测到存在丢包现象，则到第三步，如果无丢包，则继续第二步；
第三步，计算TMIN、TLOST和n的值，如果满足丢包判断式，则使RR包中的FractionLost＝0，并继续第四步，如果不满足丢包判断式或n＞12时，则继续第四步；
第四步，发送端等待RR包，等到RR包后记录抵达时间TNOW以及当前的发送速率TM，将RR包中的Fraction Lost值存储在rFL中，计算出当前的r，继续第五步；
第五步，判断丢包事件发生率r的大小，若r＝0，发送速率按照慢开始的规则增大，然后返回第四步，若r≠0，继续第六步；
第六步，取出接收到RR包的LSR和DLSR字段的值分别存储于TLS和TDLS中，计算出回环时间RTTME，并计算出平滑后的RTT，继续第七步；
第七步，根据得到TO的值，继续第八步；
第八步，根据前几步得出了RTT、r、TO，计算出速率T，如果TM≤T，则发送端以min(TM+1/RTT，T)的速率进行发送；如果TM＞T，则发送端以T进行发送，最后返回第四步。
(四)控制RTCP发包间隔
RTCP协议与RTP协议一起使用，与RTP数据包使用相同的传输机制，最终通过接收者报告RR包，将数据包的传输质量反馈给发送端，弥补RTP采用UDP方式传输时，发送端不能对流量和拥塞控制的缺点，为了自适应网络带宽环境，本发明动态调节发送端的发送速率，控制发送端周期性发送SR包，接收端一旦收到SR包，通过包中的时间戳、发包数量、发送数据总长度信息分析网络质量，然后立即将检测分析出的RTP数据包的丢包率、丢包数量、间隔延时信息，封装到RR包中反馈给发送端，发送端最后根据RR包得到接收端接收到SR包时间TLSR、接收到SR包到发送RR包的延时处理时间TDLSR以及丢包时间发生率r，通过计算的出回环时间RTT、重传时间TO和平滑后的丢包率，利用改进后的吞吐率公式得出此时应有的发送速率进行调节，达到通过控制流量和拥塞，减少RTP数据包的丢包率。
只要网络带宽允许，尽可能的经常发送RTCP包，通过RTCP包中的发送数据统计信息，正确估算每个参与者的带宽以及所发送RTP数据包的接收情况，发送端同时发送RTP数据包和发送端报告SR包，大量又频繁的发送SR包会占用过多的网络带宽，以至于影响RTP数据包的发送质量，反而导致RTP数据包的丢包率上升，影响视音频同步协调效果。所以首要的传输目的是保证RTP音频数据包的传输质量，RTCP的带宽应当只占总会话带宽的一小部分，发送端发送的RTP数据带宽应该占总会话带宽的一大部分，发送RTCP包的时间间隔应当和参与传输的终端数量成正比，在多个终端参与传输时，RTCP包几分钟才发送一次，而在只有2个终端传输RTP数据时，RTCP包几秒钟就发送一次，时间间隔设置为5秒。为避免因参与传输的终端数量过少，而RTCP包的发送间隔过短，导致发送大量的RTCP包，本发明控制RTCP包的发送间隔，保证RTP数据包的传输质量，发送RTCP控制包的时间间隔规则主要包括：
规则一，发送RTCP包的时间间隔应当和参与终端数目成正比，参与传输会话的终端数量越多，发送RTCP包的时间间隔应越长；
规则二，最小的时间间隔为5秒，若发送端之前从未发送过RTCP包，第一次发送的RTCP包间隔设置为最小时间间隔的一半，即2.5秒；
规则三，避免所有参与终端同步发送RTCP包，所发送的RTCP包时间间隔，是根据计算得到时间间隔的0.5至1倍之间的任意值；
规则四，计算出的时间间隔跟参与的终端数量相关，每当有新的参与者加入或离开会话时，都应该重新计算下一个RTCP包的发送时间；
规则五，RTCP传输的带宽应该为会话带宽的5％，其中发送端应该占有25％的带宽，若发送端的数目超过25％，那么所分给它的RTCP带宽也相应增加。
间隔的发包时间INVL主要是依据以下部分估算：
依据一，分配给RTCP包的带宽rtcp_bw＝5％*传输会话的总带宽；
依据二，所发送RTCP包的平均大小C；
依据三，参与传输会话的总终端数量Num；
依据四，参与传输会话的发送端数量SendNum；
依据五，最小时间间隔Tmin，第一次发送RTCP包时，Tmin＝2.5s，后续发送时，Tmin＝5s。
为保证在发送端数目很少的情况下，具体的时间间隔计算方法为：
第一步，计算出理论上的时间间隔INVL：
一是如果发送端数目不大于参与会话的总终端数目的25％，即SendNum≤(0.25*Num)，且发送端在上一个RTCP包发出后，接连又发送了RTP数据媒体包，则时间间隔应该为：
INVL＝max(Tmin,SendNum*S/(0.25*rtcp_bw))
二是如果发送端数目不大于参与会话的总终端数目的25％，但在之前的RTCP包发送后，发送端并没有在发送数据包，那么理论时间间隔为：
INVL＝max(Tmin,Num-SendNum)*S/(0.75*rtcp_bw))
三是如果发送端数据大于参与会话的总终端数目的25％，即SendNum＞(0.25*Num)，那么INVL为：
INVL＝max(Tmin,Num*S/rtcp_bw)
第二步，实际发送情况下，为避免多个发送端同时发送RTCP包的发包时间间隔，INVL应为：
INVL＝INVL*random[0.5,1.5]
第三步，在有多个参与终端时，为避免估算出的参与终端数过少，导致发送RTCP包的时间间隔过短，用时间重估算法使之比计算得到的RTCP带宽再小一个值，
INVL＝INVL/(e-0.5)≈INVL/1.21828。
四、实验结果和分析
主要对数据包的乱序处理，以及发送端通过调节发送速率，达到减小对丢包率的效果两方面进行实验，通过实验验证安卓实时媒体内视音频协调同步的改进情况。
(一)缓存链表对数据包乱序的排序处理
实验方法：将Tcpdump所获取数据包序列号的顺序，以及接收端缓存链表中结点序列号的顺序，两者进行对比，查看在Tcpdump中乱序的序列号是否在链表中排序正确。
实验结果：序列号为879的乱序包，在链表中已经调整正确。
(二)基于RTCP反馈调节发送速率
实验方法：由于wifi局域网环境下的丢包率几乎为0，不会产生网络拥塞，采用电信4G/5G的网络环境进行实验，在一个发送端和一个接收端的情况下，RTCP发包间隔依次为2.5s,5s,5s,5s…，即第一次发包间隔为2.5s，其后均为5s，因为视频数据量比音频大，所以主要测试对视频发送速率的调节，采取慢开始方式，视频包开始的发送速率40kbit/s，以35kbit/s的速率增加，直到收到RR包中的信息进行调节发送速率。
实验结果：若根据RTCP反馈调节发送速率的方法，将在3.5s左右因收到RR包后开始调节发送速率，发送速率经历几次调整后，将最终保持在100kb/s，丢包率也保持在1％以下。而若采用传统恒定发送速率保持不变的方法，所测得的丢包率为18.23％。
实验主要验证接收端对数据包的乱序处理以及发送端通过调节发送速率对丢包率的减小，最终达到改善安卓实时媒体内同步协调效果，实验结果显示，接收端的一级缓存有效的对乱序抵达的数据包进行了排序处理，使数据包的序列号按照升序的关系，还原到原有的时间顺序关系。采用传统恒定的发送速率发送数据包，持续10分钟之后测得的丢包率为18.23％，而采用RTCP反馈调节发送速率的实验表明，丢包率通过发送端调节发送速率，最终保持在1％左右，而1％左右的丢包率几乎不影响播放质量和同步协调质量，达到了预期效果。
Claims (10)
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个字节的FUindicator和FU header；如果S＝0，E＝1，R＝0，则表示该分片包为这个NALU单元的最后一个数据包，同样也去掉RTP包头、FU indicator和FU header，若是单纯NALU封包的视频包，直接去掉RTP包头后，在NALU数据前加上4个字节的起始码，组帧后的视频帧还原成原始的NALU数据单元，再把视频帧送到解码模块。
6.根据权利要求1所述的基于安卓平台的实时媒体内视音频协调法，其特征在于，媒体内视音频同步方法的改进：模仿TCP协议中对流量和拥塞进行控制，并根据无线环境的特点加以改进拥塞控制策略，使之更适合传输UDP协议的数据包，从源头上减少丢包率，提高视音频的同步质量；
采用UDP的拥塞控制方法主要是从以下两个方面：一方面是基于控制窗口发送数据量来达到拥塞控制，通过参考TCP协议中的拥塞控制，在网络环境好的情况下，根据算法适当增大发送窗口；当检测到出现网络拥塞时，根据算法减小发送窗口和拥塞窗口；另一方面是基于速率的拥塞控制的方式，而音频流根据采样频率，视频流根据每秒的帧率，在传输时流媒体数据也基于速率，平滑的控制发送速率，减少丢包；
本发明针对无线网络环境下减少丢包的主要方法是：通过测量相关网络参数，对网络带宽的估算，根据规则明确区分丢包原因，最后根据不同的丢包原因，反馈调整发送速率，达到减少丢包率，改进媒体内同步协调效果。
7.根据权利要求1所述的基于安卓平台的实时媒体内视音频协调法，其特征在于，丢包原因的判断追踪算法：采用基于端到端的控制实现区分丢包原因，在没有发生网络丢包的情况下，相邻数据包抵达接收端的时间间隔T是均匀的；发生无线信号干扰造成的丢包则会导致分组的抵达时间间隔至少不小于两倍的T，相邻抵达的数据包序号差与时间间隔成比例；
接收端只需通过数据包序号检测是否丢包，并记录数据包的抵达时间间隔，如果发生丢包现象，则对比数据包抵达的时间间隔，若时间间隔相同，则判定为发生了拥塞丢包；若时间间隔不相等，则判定为发生了无线丢包，随着数据的不断传输，网络负载也随之增大，发生拥塞的可能性也会增加，本发明采用降低判断的临界值，来提高区分丢包的精度，丢包判断式为：
(n+1)TMIN≤TLOST≤(n+1.3)TMIN
TLOST表示发生丢包现象时，实际分组抵达的时间间隔，若TLOST满足上式，可判断发生了无线丢包；如果不满足条件，可判定发生了拥塞丢包，其中，TMIN表示相邻抵达接收端数据包的最小时间间隔，n表示连续丢失的包数量。
8.根据权利要求1所述的基于安卓平台的实时媒体内视音频协调法，其特征在于，基于RTCP网络状态反馈调节发送速率：采用与RTP一起使用的RTCP，发送端将发送者报告SR和RTP数据包一并发送，接收端根据SR包和RTP序列号估算丢包率信息，然后将数据包的传输质量封装成接收者报告RR包，最后反馈给发送端，发送端根据RR包计算出最终的丢包率和回环时间RTT，调节发送速率；
基于速率的TCP-Friendly传输机制模仿TCP协议在拥塞情况下对速率的调节，根据当前的网络状态，平滑的改变发送端的发送速率，同时去除TCP协议中对数据包的确认和重传机制，减少等待确认和重传所带来的延时，满足实时流媒体的传输需求，在TCP-Friendly拥塞控制机制中，本发明采用以Padhye吞吐率模型为基础，依据RTCP协议里接收端发回的接收者报告中的信息，计算出当前网络环境下发送端应有的发送速率，对发送速率进行调节，注重现存TCP流的友好性，平滑改变发送速率，对已有的实时流媒体传输模式RTP/RTCP不会有额外的负担，无需增加额外的信道和数据包用来反馈网络环境，吞吐率模型为：
其中，T是计算出来的发送速率，C为传输的数据包大小，RTT为发送端和接收端之间的数据链路回环时间Round-TripTime，r为丢包事件发生率(0＜r＜1)，TO为重传时钟所设置的时间，e取值1或2，这里取1后吞吐率模型简化为：
根据上式，未知项的值RTT，TO，r都能通过RTCP协议的RR包中的数据计算得到，然后计算出该拥塞环境下发送端的发送速率，首先，RTT的值是从发送端发出数据包开始到收到接收端的确认消息为止，整个在网络链路中所经历的时间，接收端只要收到SR包就会立刻给发送端发送RR包，选取从发送端发出SR包开始到发送端接收到RR包为止的这段时间，作为回环时间，回环时间的计算不包括收到SR包到发送RR包的这段时间，即计算式为：
RTTME＝TNOW-TLS-TDLS
其中，RTTME表示通过计算得到的回环时间，TNOW表示接收端收到RR包时的当前时间，TLS是发送端发送SR包的时间，这个值从RR包中的LSR字段中取得NTP时间戳中的32bits，TDLS表示接收端收到SR包到发送RR包之间的时间间隔，从收到的RR包中的DLS字段中取得，实际计算出的回环时间通过下式，通过上一次的回环时间RTTn和这一次计算出的RTTME进行平滑处理，d取0.8，
RTTn+1＝dTTTn+(1-d)RTTME
在TCP的传输中，发送端在发送数据包时设置一个计时器，若在计时器规定的时间内没有收到ACK确认消息，发送端会直接重传数据包，TO为设定的重传时间，UDP协议中不存在确认重传机制，取值为4倍的RTT，表示为：TO＝4RTT；
r表示丢包事件的发生率，接收端通过接收者报告RR包里的丢包率字段获得丢包情况，在采用TCP进行拥塞调节时，系统只要检测到有丢包的情况，不论丢包数目的多少，都认为发生了网络拥塞，直接对发送速率进行调节，大幅度的减少吞吐量，UDP方式对数据包的传输根据上一次的丢包事件发生率rn和RR包里的丢包率rFL，进行加权平滑后再作为r的值，a取0.7，即：
rn+1＝arn+(1-a)rFL
为保证视频帧的低丢包率，避免在媒体间同步时因连续丢包导致过多重复上一个视频帧，对连续丢包数量n上进行控制，一个视频帧的长度最多封成4个包，为避免接收端重复播放上一个视频帧的次数最多不超过3次，当n＞12时，对发送速率进行调节，减少丢包，发送端以慢开始的方式进行发送，然后每收到一个RR包后，如果平滑后的r为0，说明没有发生拥塞丢包，继续慢开始；如果平滑后的r不为0，则根据RR包中的信息取出并计算得到平滑后的RTT、TO及计算出的发送速率T，比较发送速率T与当前的发送速率TM：
第一，如果TM≤T，说明网络还有多余的带宽能够使用，则发送端以min(TM+1/RTT，T)的速率进行发送；
第二，如果TM＞T，则发送端以计算出的T进行发送。
9.根据权利要求8所述的基于安卓平台的实时媒体内视音频协调法，其特征在于，基于RTCP网络状态反馈调节发送速率中，发送速率具体的调整算法为：
第一步，发送端发送RTP包和SR包；
第二步，接收端接收RTP包和SR包后，根据连续的包序号检测是否发生丢包，如果检测到存在丢包现象，则到第三步，如果无丢包，则继续第二步；
第三步，计算TMIN、TLOST和n的值，如果满足丢包判断式，则使RR包中的Fraction Lost＝0，并继续第四步，如果不满足丢包判断式或n＞12时，则继续第四步；
第四步，发送端等待RR包，等到RR包后记录抵达时间TNOW以及当前的发送速率TM，将RR包中的Fraction Lost值存储在rFL中，计算出当前的r，继续第五步；
第五步，判断丢包事件发生率r的大小，若r＝0，发送速率按照慢开始的规则增大，然后返回第四步，若r≠0，继续第六步；
第六步，取出接收到RR包的LSR和DLSR字段的值分别存储于TLS和TDLS中，计算出回环时间RTTME，并计算出平滑后的RTT，继续第七步；
第七步，根据得到TO的值，继续第八步；
第八步，根据前几步得出了RTT、r、TO，计算出速率T，如果TM≤T，则发送端以min(TM+1/RTT，T)的速率进行发送；如果TM＞T，则发送端以T进行发送，最后返回第四步。
10.根据权利要求1所述的基于安卓平台的实时媒体内视音频协调法，其特征在于，控制RTCP发包间隔中，间隔的发包时间INVL主要是依据以下部分估算：
依据一，分配给RTCP包的带宽rtcp_bw＝5％*传输会话的总带宽；
依据二，所发送RTCP包的平均大小C；
依据三，参与传输会话的总终端数量Num；
依据四，参与传输会话的发送端数量SendNum；
依据五，最小时间间隔Tmin，第一次发送RTCP包时，Tmin＝2.5s，后续发送时，Tmin＝5s。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110379910.5A CN113099310A (zh) | 2021-04-08 | 2021-04-08 | 基于安卓平台的实时媒体内视音频协调法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110379910.5A CN113099310A (zh) | 2021-04-08 | 2021-04-08 | 基于安卓平台的实时媒体内视音频协调法 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN113099310A true CN113099310A (zh) | 2021-07-09 |
Family
ID=76675248
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202110379910.5A Pending CN113099310A (zh) | 2021-04-08 | 2021-04-08 | 基于安卓平台的实时媒体内视音频协调法 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN113099310A (zh) |
Cited By (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113573003A (zh) * | 2021-08-11 | 2021-10-29 | 睿云联(厦门)网络通讯技术有限公司 | 一种基于弱网的音视频实时通信方法、装置以及设备 |
| CN113612737A (zh) * | 2021-07-20 | 2021-11-05 | 天津七所精密机电技术有限公司 | 一种基于分组与重传机制的长报文可靠传输方法 |
| CN113727174A (zh) * | 2021-07-14 | 2021-11-30 | 深圳市有为信息技术发展有限公司 | 控制车辆卫星定位系统视频平台播放的方法、装置及电子设备 |
| CN114844801A (zh) * | 2022-03-29 | 2022-08-02 | 中国信息通信研究院 | 用于实时业务网络丢包测试的方法及装置、电子设备、存储介质 |
| CN114866859A (zh) * | 2022-05-10 | 2022-08-05 | 福州大学 | 基于时间戳和丢包检测的实时视频传输动态延时控制系统 |
| CN114979023A (zh) * | 2022-07-26 | 2022-08-30 | 浙江大华技术股份有限公司 | 一种数据传输方法、系统、电子设备及存储介质 |
| CN115297335A (zh) * | 2022-08-03 | 2022-11-04 | 深圳市野草声学有限公司 | 基于接收缓冲区的视频直播时的音频传输方法及系统 |
| CN116781975A (zh) * | 2023-08-17 | 2023-09-19 | 中仪英斯泰克科技有限公司 | 一种媒体流检测方法、装置、终端设备和存储介质 |
| CN117714757A (zh) * | 2024-02-04 | 2024-03-15 | 北京搜狐新动力信息技术有限公司 | 码率调整方法、装置、电子设备及存储介质 |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102665141A (zh) * | 2012-05-16 | 2012-09-12 | 哈尔滨工业大学深圳研究生院 | 一种基于rtp封装的avs音视频预同步方法 |
| CN103546662A (zh) * | 2013-09-23 | 2014-01-29 | 浙江工业大学 | 一种网络监控系统中音视频同步方法 |
| JP2014068087A (ja) * | 2012-09-25 | 2014-04-17 | Nec Corp | バッファ制御装置、バッファ制御装置による制御方法、メディア通信装置、並びにコンピュータ・プログラム |
| CN103929681A (zh) * | 2014-04-09 | 2014-07-16 | 安徽超远信息技术有限公司 | 一种提升低速网络中rtp视频流处理效率的方法 |
| CN105306888A (zh) * | 2015-10-03 | 2016-02-03 | 上海大学 | 基于丢包区分的移动视频监控带宽自适应方法 |
-
2021
- 2021-04-08 CN CN202110379910.5A patent/CN113099310A/zh active Pending
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102665141A (zh) * | 2012-05-16 | 2012-09-12 | 哈尔滨工业大学深圳研究生院 | 一种基于rtp封装的avs音视频预同步方法 |
| JP2014068087A (ja) * | 2012-09-25 | 2014-04-17 | Nec Corp | バッファ制御装置、バッファ制御装置による制御方法、メディア通信装置、並びにコンピュータ・プログラム |
| CN103546662A (zh) * | 2013-09-23 | 2014-01-29 | 浙江工业大学 | 一种网络监控系统中音视频同步方法 |
| CN103929681A (zh) * | 2014-04-09 | 2014-07-16 | 安徽超远信息技术有限公司 | 一种提升低速网络中rtp视频流处理效率的方法 |
| CN105306888A (zh) * | 2015-10-03 | 2016-02-03 | 上海大学 | 基于丢包区分的移动视频监控带宽自适应方法 |
Non-Patent Citations (6)
| Title |
|---|
| 叶进;王建新;: "异构网络中丢包识别研究综述", 计算机科学, no. 12, pages 19 - 33 * |
| 尹洪;洪玫;曾明;冷江;王卓;: "基于RTCP的实时流式传输拥塞控制算法", 云南大学学报(自然科学版), no. 2, pages 235 - 246 * |
| 王万良;张小玮;姚信威;岑跃峰;: "无线网络中基于流媒体传输的自适应TFRC机制", 计算机系统应用, no. 07, pages 161 - 167 * |
| 王辉;田鹏辉;: "一种基于Android的视频自适应算法设计", 工业仪表与自动化装置, no. 06, pages 46 - 49 * |
| 邱小燕, 吴产乐, 叶刚, 张萌, 熊卿: "RTP协议中RTCP传输间隔算法", 武汉大学学报(理学版), no. 01, pages 74 - 76 * |
| 郭尧: "基于AVS的嵌入式音视频同步传输系统设计", 中国优秀硕士学位论文全文数据库, no. 09, pages 29 - 41 * |
Cited By (13)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113727174A (zh) * | 2021-07-14 | 2021-11-30 | 深圳市有为信息技术发展有限公司 | 控制车辆卫星定位系统视频平台播放的方法、装置及电子设备 |
| CN113612737A (zh) * | 2021-07-20 | 2021-11-05 | 天津七所精密机电技术有限公司 | 一种基于分组与重传机制的长报文可靠传输方法 |
| CN113573003B (zh) * | 2021-08-11 | 2023-08-01 | 睿云联(厦门)网络通讯技术有限公司 | 一种基于弱网的音视频实时通信方法、装置以及设备 |
| CN113573003A (zh) * | 2021-08-11 | 2021-10-29 | 睿云联(厦门)网络通讯技术有限公司 | 一种基于弱网的音视频实时通信方法、装置以及设备 |
| CN114844801A (zh) * | 2022-03-29 | 2022-08-02 | 中国信息通信研究院 | 用于实时业务网络丢包测试的方法及装置、电子设备、存储介质 |
| CN114844801B (zh) * | 2022-03-29 | 2023-06-16 | 中国信息通信研究院 | 用于实时业务网络丢包测试的方法及装置、电子设备、存储介质 |
| CN114866859A (zh) * | 2022-05-10 | 2022-08-05 | 福州大学 | 基于时间戳和丢包检测的实时视频传输动态延时控制系统 |
| CN114979023A (zh) * | 2022-07-26 | 2022-08-30 | 浙江大华技术股份有限公司 | 一种数据传输方法、系统、电子设备及存储介质 |
| CN115297335A (zh) * | 2022-08-03 | 2022-11-04 | 深圳市野草声学有限公司 | 基于接收缓冲区的视频直播时的音频传输方法及系统 |
| CN115297335B (zh) * | 2022-08-03 | 2024-05-14 | 深圳市野草声学有限公司 | 基于接收缓冲区的视频直播时的音频传输方法及系统 |
| CN116781975A (zh) * | 2023-08-17 | 2023-09-19 | 中仪英斯泰克科技有限公司 | 一种媒体流检测方法、装置、终端设备和存储介质 |
| CN116781975B (zh) * | 2023-08-17 | 2024-02-06 | 中仪英斯泰克科技有限公司 | 一种媒体流检测方法、装置、终端设备和存储介质 |
| CN117714757A (zh) * | 2024-02-04 | 2024-03-15 | 北京搜狐新动力信息技术有限公司 | 码率调整方法、装置、电子设备及存储介质 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN113099310A (zh) | 基于安卓平台的实时媒体内视音频协调法 | |
| US7920492B1 (en) | Devices, softwares and methods for redundantly encoding a data stream for network transmission with adjustable redundant-coding delay | |
| US8089948B2 (en) | Header compression of multimedia data transmitted over a wireless communication system | |
| JP4504429B2 (ja) | 端末間のボイスオーバインターネットプロトコルのメディアの待ち時間を管理する方法および装置 | |
| US7047308B2 (en) | System and method for simultaneous media playout | |
| US20030198184A1 (en) | Method of dynamically determining real-time multimedia streaming rate over a communications networks | |
| WO2006054442A1 (ja) | 送信装置、受信装置及び通信システム | |
| EP2364017B1 (en) | Method, system and user device for obtaining key frame in streaming media service | |
| WO2009106015A1 (zh) | 动态码率分配方法、分组域流媒体服务器 | |
| CN113115080A (zh) | 移动媒体间实时视频音频高精度同步平台 | |
| CN101552660A (zh) | 对流媒体数据进行重传、播放的方法、装置及通信系统 | |
| CN101909208A (zh) | 一种适用于cdma2000的视频无线传输控制方法 | |
| CN111669545A (zh) | 一种改善视频传输延迟的方法及装置 | |
| CN111385625A (zh) | 一种Non-IP数据传送的同步方法和设备 | |
| CN112911650A (zh) | 移动高清视频智能双向探测带宽控制系统 | |
| KR102118678B1 (ko) | 부호화된 비디오 스트림 전송 장치 및 방법 | |
| Wee et al. | Optimized video streaming for networks with varying delay | |
| CN100479460C (zh) | 跨平台的端到端rtp协议栈设计方法 | |
| Jammeh et al. | Smoothing transcoded MPEG-1 video streams for Internet transmission | |
| Bassey et al. | AN EFFECTIVE ADAPTIVE MEDIA PLAY-OUT ALGORITHM FOR REAL-TIME VIDEO STREAMING OVER PACKET NETWORKS | |
| Huang et al. | Adaptive VoIP service QoS control based on perceptual speech quality | |
| Alexiou et al. | A decision feedback scheme for multimedia transmission over 3g mobile networks | |
| Laraspata et al. | A scheduling algorithm for interactive video streaming in umts networks | |
| Jenkac et al. | On video streaming over variable bit-rate and wireless channels | |
| Balaouras et al. | Multimedia transport protocols for wireless networks |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |