基于RTP协议的打包及解包
解包和打包exe文件的方法
解包和打包exe文件的方法1.引言1.1 概述概述:在软件开发过程中，我们经常会遇到需要解包和打包exe文件的情况。
解包exe文件是指将经过编译的可执行文件进行还原，以获取其中的源代码、资源文件等内容。
而打包exe文件则是将源代码和相关资源文件重新打包成可执行文件。
这两个操作在软件开发、软件逆向工程和软件调试等领域中都有广泛的应用。
解包exe文件的方法可以分为使用解包工具和手动解包两种方式。
使用解包工具是指使用专门的软件工具来进行解包操作，它能够自动分析可执行文件的结构并提取其中的内容。
手动解包则是通过一些常见的手段，如二进制文件编辑器或调试器，以手动的方式逆向还原可执行文件中的内容。
打包exe文件的方法也可以分为使用打包工具和手动打包两种方式。
使用打包工具可以方便地将源代码和相关资源文件打包成可执行文件，它提供了简单易用的图形界面和各种打包选项。
手动打包则需要开发人员手动进行文件的整理和编译操作，相对来说比较繁琐。
总结起来，解包和打包exe文件是软件开发中常见的操作，通过解包我们可以获取到可执行文件中的源代码和资源文件，有助于我们理解和调试软件；而打包exe文件则可以将我们的源代码和资源文件重新打包成可执行文件，方便我们发布和分发软件。
在进行解包和打包操作时，可以根据需要选择使用相应的工具或手动操作的方式，以达到我们的目的。
1.2 文章结构文章结构负责为读者介绍本文的组织和内容安排。
本文主要围绕解包和打包exe文件的方法展开讨论。
在本文中，我们将首先提供一个引言部分，概述本文的背景和目的。
接下来，将详细介绍解包exe文件的方法，包括使用解包工具和手动解包。
然后，我们将探讨打包exe文件的方法，包括使用打包工具和手动打包。
最后，我们将通过总结解包和打包exe文件的方法，提供一些结论和建议。
通过本文的阅读，读者将能够全面了解解包和打包exe文件的技术和方法，并且可以根据自己的需求选择适合的方式进行操作。
路由器固件的解包与打包
路由器固件的解包与打包一、概述当前大学生都被校园网的客户端困扰，然而南京工程学院公布了Linux客户度解决方案，或者Mentohust解决方案，可以在Ubuntu系统的计算机上运行了。
但进一步的工作就是如何令其在路由器上工作，以达到真正的路由功能。
假定笔者已经把电脑上完美运行的客户端进行了交叉编译，生成了要在路由上运行的拨号程序（假定为Client），且笔者的路由器有合适的固件（假定为firm.bin)。
那么要在路由器上运行Client有三种方法：1.可以把Client上传到路由器的/jffs目录下。
(本文不讨论这种情形)2.刷写dd后,由于剩余容量太小导致无法加载jffs,那么每次启动路由后，可以将程序Client 上传到刷写了firm.bin路由的/tmp目录下，然后令其运行。
简单的说，就是在内存里运行Client。
其缺点就是每次路由断电，你必须重新上传。
(本文不讨论这种情形)3.当路由器无法加载jffs时,可以考虑将Client程序增添至固件，并且在自启动命令里输入正确的命令方式，以达到每次路由插上电，都可以自动运行拨号程序的完美效果。
以下讨论的为如何将Client固化至固件的方法。
所需软件为firmware-mod-kit，大致步骤为：1.先用解包软件解包路由器固件将会得到固件核心文件。
2.再把Client复制到固件的某个文件夹内，且注意赋予可执行的权限。
3.用build-ng.sh进行最终的封包，生成新的固件。
操作环境：Ubuntu 11.04版参考资料：/p/mentohust-wrt//p/firmware-mod-kit/ Firmware Modification Kit并感谢第一个项目的作者给我的指导和帮助。
我只是把他没有写明白的步骤，以我自己的理解方式重述而已。
二、详细步骤1.首先下载firmware-mod-kit封包软件，并进行编译，将会得到所需文件。
1.1下载firmware-mod-kit封包软件并在终端窗口里输入以下命令：svn checkout /svn/ firmware-mod-kit-read-only耐心的等待之后，会在你的本地硬盘上生成一个目录firmware-mod-kit-read-only，其中包含branches，tags，trunk，wiki四个文件夹。
路由器固件的解包与打包2024
引言概述：路由器固件解包与打包是指将嵌入式设备（如路由器）上的固件进行解开和重新打包的过程。
这个过程对于嵌入式设备的软件开发和定制化非常重要。
本文将详细介绍用于解包和打包固件的工具和步骤。
正文内容：一、解包固件1.1提取固件文件：从路由器设备中提取固件文件，可以使用DD命令或者串口控制台提取。
1.2解压固件文件：使用解压工具，如binwalk，将固件文件进行解压，得到固件的各个组成部分。
1.3分析固件：通过分析解压后的固件文件，了解各个组成部分的结构和功能。
二、打包固件2.1修改固件：根据需求，对固件文件进行修改，如添加新的软件包、修改配置文件等。
2.2重新打包固件：将修改后的文件重新打包成固件格式，可以使用mkimage等工具进行打包。
三、固件的烧录与更新3.1硬件烧录：将打包好的固件通过串口或者JTAG接口烧录到设备的闪存中。
3.2固件更新：将新的固件通过WEB界面或者命令行进行更新，确保设备上的固件是最新版本。
四、错误处理与调试4.1解包错误处理：解包固件时可能会遇到一些错误，如文件损坏或者解压失败，需要进行错误处理。
4.2打包错误处理：打包固件时可能会遇到一些错误，如文件格式不兼容或者依赖关系错误，需要进行错误处理。
4.3调试固件：使用调试工具，如GDB，对固件进行调试，查找和修复潜在问题。
五、固件安全性5.1固件签名：为了确保固件的可靠性和完整性，可以对固件进行签名，防止被篡改或者恶意替换。
5.2固件加密：对固件进行加密，防止固件被逆向工程或者泄露敏感信息。
5.3固件验证：通过验证机制，如校验和或者哈希值等，确保固件在传输和存储过程中的完整性。
总结：路由器固件的解包与打包对于定制化和软件开发非常重要。
通过解包固件，可以深入了解嵌入式设备的软件和硬件组成部分。
通过打包固件，可以将所需的修改和定制化应用到设备上。
固件的烧录与更新、错误处理与调试以及固件的安全性也是不可忽视的。
通过掌握解包与打包固件的技术，可以更好地定制和管理嵌入式设备的固件。
RTP协议分析
RTP协议分析协议名称：RTP协议分析一、引言RTP（Real-time Transport Protocol）是一种用于实时传输音频和视频数据的协议。
该协议提供了一种标准化的方式，用于在多媒体应用程序之间传输实时数据。
本协议旨在分析RTP协议的基本原理、功能和特点，并提供相应的标准格式。
二、协议概述RTP协议是一个基于UDP的传输协议，用于在互联网上传输实时数据。
它提供了一种可靠的、实时的数据传输机制，适用于音频、视频和其他多媒体数据的传输。
RTP协议通过将数据分割成小的数据包（称为RTP包）并添加头部信息来实现数据的传输和同步。
三、协议结构1. RTP包头部RTP包头部包含以下字段：- 版本（V）：标识RTP协议的版本号。
- 填充（P）：指示是否在RTP包的末尾添加了额外的填充字节。
- 扩展（X）：指示是否在RTP包中包含了扩展头部。
- CSRC计数（CC）：指示后续包头中CSRC标识符的数量。
- 标记（M）：用于指示RTP包是否为一个帧的最后一个包。
- 负载类型（PT）：指示RTP包中负载的类型，例如音频或视频。
- 序列号（Sequence Number）：用于标识RTP包的顺序。
- 时间戳（Timestamp）：提供了RTP包中数据的时间信息。
- 同步源（SSRC）：用于唯一标识RTP流的源。
- CSRC列表（CSRC List）：包含了参与混合的媒体流的CSRC标识符的列表。
2. RTP包负载RTP包的负载部分包含了实时传输的音频、视频或其他多媒体数据。
四、协议功能1. 实时传输RTP协议提供了实时传输数据的功能，适用于音频和视频等多媒体数据的传输。
它通过将数据分割成小的数据包，并在每个包中添加时间戳信息，以确保接收方可以按照正确的顺序和时间重建数据。
2. 数据同步RTP协议通过使用时间戳字段来实现数据的同步。
接收方可以根据时间戳信息将多个数据包按照正确的顺序进行播放，从而实现音视频的同步。
java、android可用的rtp封包解包h264案例
java、android可⽤的rtp封包解包h264案例做直播，⾳视频通讯。
经常需要通过rtp协议封装⾳视频数据来发送。
⽹上找到的基本都是c或c++版本的，没有JAVA版本的。
就算千⾟万苦找到⼀篇java版本的，要么不能⽤，要么就是⼀些⽚段，要么有封包没解包。
很是蛋疼，本⼈也是这样，刚开始不太熟悉rtp协议，不太明⽩怎么封包组包，痛苦了⼏天，终于搞出来了，分享给有需要的朋友，希望对你们有所帮助。
直接看代码吧。
不多说了。
⾸先看看关键类：package com.imsdk.socket.udp.codec;import android.os.SystemClock;import android.util.Log;import java.io.ByteArrayInputStream;import java.io.IOException;import java.io.InputStream;import java.math.BigDecimal;import java.util.Random;import java.util.concurrent.Semaphore;public class RtspPacketEncode {private static final String TAG = "RtspPacketEncode";//------------视频转换数据监听-----------public interface H264ToRtpLinsener {void h264ToRtpResponse(byte[] out, int len);}private H264ToRtpLinsener h264ToRtpLinsener;//执⾏回调private void exceuteH264ToRtpLinsener(byte[] out, int len) {if (this.h264ToRtpLinsener != null) {h264ToRtpLinsener.h264ToRtpResponse(out, len);}}// -------视频--------private int framerate = 10;private byte[] sendbuf = new byte[1500];private int packageSize = 1400;private int seq_num = 0;private int timestamp_increse = (int) (90000.0 / framerate);//framerate是帧率private int ts_current = 0;private int bytes = 0;// -------视频END--------public RtspPacketEncode(H264ToRtpLinsener h264ToRtpLinsener) {this.h264ToRtpLinsener = h264ToRtpLinsener;}/*** ⼀帧⼀帧的RTP封包** @param r* @return*/public void h264ToRtp(byte[] r, int h264len) throws Exception {CalculateUtil.memset(sendbuf, 0, 1500);sendbuf[1] = (byte) (sendbuf[1] | 96); // 负载类型号96,其值为：01100000sendbuf[0] = (byte) (sendbuf[0] | 0x80); // 版本号,此版本固定为2sendbuf[1] = (byte) (sendbuf[1] & 254); //标志位，由具体协议规定其值，其值为：01100000sendbuf[11] = 10;//随机指定10，并在本RTP回话中全局唯⼀,java默认采⽤⽹络字节序号不⽤转换（同源标识符的最后⼀个字节）if (h264len <= packageSize) {sendbuf[1] = (byte) (sendbuf[1] | 0x80); // 设置rtp M位为1，其值为：11100000，分包的最后⼀⽚，M位（第⼀位）为0，后7位是⼗进制的96，表⽰负载类型 sendbuf[3] = (byte) seq_num++;System.arraycopy(CalculateUtil.intToByte(seq_num++), 0, sendbuf, 2, 2);//send[2]和send[3]为序列号，共两位{// java默认的⽹络字节序是⼤端字节序（⽆论在什么平台上），因为windows为⼩字节序，所以必须倒序/**参考：* /u011068702/article/details/51857557* /blog/1591261*/byte temp = 0;temp = sendbuf[3];sendbuf[3] = sendbuf[2];sendbuf[2] = temp;}// FU-A HEADER, 并将这个HEADER填⼊sendbuf[12]sendbuf[12] = (byte) (sendbuf[12] | ((byte) (r[0] & 0x80)) << 7);sendbuf[12] = (byte) (sendbuf[12] | ((byte) ((r[0] & 0x60) >> 5)) << 5);sendbuf[12] = (byte) (sendbuf[12] | ((byte) (r[0] & 0x1f)));// 同理将sendbuf[13]赋给nalu_payload//NALU头已经写到sendbuf[12]中，接下来则存放的是NAL的第⼀个字节之后的数据。
adts rtp封装流程
adts rtp封装流程ADTS（Audio Data Transport Stream）是一种音频数据传输流格式，而RTP（Real-time Transport Protocol）是一种实时传输协议。
在音频流的封装过程中，ADTS和RTP常常结合使用，以下是它们结合使用的封装流程：1. 音频编码，首先，原始音频数据会经过音频编码器进行压缩，常见的音频编码格式包括AAC、MP3等。
编码后的数据称为音频帧。
2. ADTS封装，接下来，将编码后的音频帧进行ADTS封装。
ADTS封装是将音频帧添加ADTS头部信息的过程，头部信息包括同步字、MPEG版本、层信息、采样率、声道数、帧长度等。
这些信息有助于接收端正确解析音频数据。
3. RTP封装，经过ADTS封装的音频数据再经过RTP封装。
RTP封装是将音频数据打包成RTP数据包的过程，每个RTP数据包包含一个RTP头部和音频数据。
RTP头部包含序列号、时间戳、同步源（SSRC）标识等信息，用于实现实时传输和同步。
4. 网络传输，经过RTP封装的音频数据通过网络进行传输。
在传输过程中，可以通过RTCP（RTP Control Protocol）进行传输质量的监控和反馈。
5. 接收端处理，接收端首先接收RTP数据包，然后根据RTP头部信息进行解析，提取音频数据。
随后进行ADTS解包，将音频数据解析出来，最终进行解码和播放。
总的来说，ADTS和RTP的结合使用可以实现音频数据的封装、传输和接收端处理，保证音频数据在网络中的实时传输和正确解析。
这样的封装流程能够满足实时音频传输的需求，并且有利于网络传输的稳定性和音频数据的质量保障。
RTP协议及编解码
RTP头
0 V=2 P X CC M 1 PT timestamp synchronization source (SSRC) identifier contributing source (CSRC) identifier „„„„„„ payload(audio video) „„„„„„„ 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
统称为“TCP/IP 协议”， INTERNET网络 基础
自定义协议
按照具体业务需要，按照一定标准定义的 协议
多方聊天室协议概述
名称 协议描述 用户登录入聊天室请求，使用用户名，无需密码 用户登录聊天室响应，如果用户名已存在，则要求用户用其他用户名登录 用户发言请求，私聊 用户发言，广播给所有用户 用户离开聊天室 服务器端发送当前用户列表 服务器端转发的私聊内容 服务器端广播某个用户的文本消息 服务器端广播某个用户上线
流媒体传输实现
实现流媒体传输主要有两种方法： 顺序流（progressive streaming）传输 实时流（realtime streaming）传输
顺序流传输
顺序流传输采用顺序下载的方式进行传输，在下载 的同时用户可以在线回放多媒体数据，但给定时刻 只能观看已经下载的部分，不能跳到尚未下载的部 分，也不能在传输期间根据网络状况对下载速度进 行调整。由于标准的HTTP服务器就可以发送这种形 式的流媒体，而不需要其他特殊协议的支持，因此 也常常被称作 HTTP流式传输。顺序流式传输比较 适合于高质量的多媒体片段，如片头、片尾或者广 告等。
在发送端开发人员必需把执行rtp协议的程序写入到创建rtp信息包的应用程序中然后应用程序把rtp信息包发送到udp的套接接口14rtpptsequencenumbertimestampsynchronizationsourcessrcidentifiercontributingsourcecsrcidentifierpayloadaudiovideo15rtp名称说明版本v2位标识rtp版本填充标识p1位如设置填充位在包尾将包含附加填充字它不属于有效载荷扩展x1位如设置扩展位固定头后跟一个扩展头csrc计数cc4位csrc计数包括紧接在固定头后csrc标识符个数标识m1位标识解释由设置定义目的在于允许重要事件在包流中标识出来载荷类型pt7位记录后面资料使用哪种codec接收端找出相应的decoder解码出来16rtp名称说明系列号16位系列号随每个rtp数据包而增加1由接收者用来探测包损失系列号初值是随机的使对加密的文本攻击更难32位时标反映rtp数据包中第一个八进制数的采样时刻采样时刻必须从单调线性增加的时钟导出以允许同步与抖动计算ssrc32位标识同步源此标识不是随机选择的目的在于使同一rtp包连接中没有两个同步源有相同的ssrc标识csrc列表0到15项每项32位
RTP协议全解（H264码流和PS流）
RTP协议全解（H264码流和PS流）写在前面：RTP的解析，网上找了很多资料，但是都不全，所以我力图整理出一个比较全面的解析，其中借鉴了很多文章，我都列在了文章最后，在此表示感谢。
互联网的发展离不开大家的无私奉献，我决定从我做起，希望大家支持。
1、RTP Header解析图11) V：RTP协议的版本号，占2位，当前协议版本号为22) P：填充标志，占1位，如果P=1，则在该报文的尾部填充一个或多个额外的八位组，它们不是有效载荷的一部分。
3) X：扩展标志，占1位，如果X=1，则在RTP报头后跟有一个扩展报头4) CC：CSRC计数器，占4位，指示CSRC 标识符的个数5) M: 标记，占1位，不同的有效载荷有不同的含义，对于视频，标记一帧的结束；对于音频，标记会话的开始。
6) PT: 有效荷载类型，占7位，用于说明RTP报文中有效载荷的类型，如GSM音频、JPEM 图像等,在流媒体中大部分是用来区分音频流和视频流的，这样便于客户端进行解析。
7) 序列号：占16位，用于标识发送者所发送的RTP报文的序列号，每发送一个报文，序列号增1。
这个字段当下层的承载协议用UDP的时候，网络状况不好的时候可以用来检查丢包。
同时出现网络抖动的情况可以用来对数据进行重新排序，序列号的初始值是随机的，同时音频包和视频包的sequence是分别记数的。
8) 时戳(Timestamp)：占32位，必须使用90 kHz 时钟频率。
时戳反映了该RTP报文的第一个八位组的采样时刻。
接收者使用时戳来计算延迟和延迟抖动，并进行同步控制。
9) 同步信源(SSRC)标识符：占32位，用于标识同步信源。
该标识符是随机选择的，参加同一视频会议的两个同步信源不能有相同的SSRC。
10) 特约信源(CSRC)标识符：每个CSRC标识符占32位，可以有0～15个。
每个CSRC标识了包含在该RTP报文有效载荷中的所有特约信源。
注：基本的RTP说明并不定义任何头扩展本身，如果遇到X=1，需要特殊处理取一段码流如下：80 e0 00 1e 00 00 d2 f0 00 00 00 00 41 9b 6b 49 €?....??....A?kIe1 0f 26 53 02 1a ff06 59 97 1d d2 2e 8c 50 01 ?.&S....Y?.?.?P.cc 13 ec 52 77 4e e50e 7b fd 16 11 66 27 7c b4 ?.?RwN?.{?..f'|?f6 e1 29 d5 d6 a4 ef3e 12 d8 fd 6c 97 51 e7 e9 ??)>.??l?Q??cfc7 5e c8 a9 51 f6 82 65 d6 48 5a 86 b0 e0 8c ??^??Q??e?HZ其中，80 是V_P_X_CCe0 是M_PT00 1e 是SequenceNum00 00 d2 f0 是Timestamp00 00 00 00是SSRC把前两字节换成二进制如下1000 0000 1110 0000按顺序解释如下：10 是V；0 是P；0 是X；0000 是CC；1 是M；110 0000 是PT；排版不如word看的清晰，大家凑合着看吧。
数据打包及拆包
第一章封包1．封包流程封包就是给一段数据加上包头,这样一来数据包就分为包头和包体两部分内容了。
包头其实上是个大小固定的结构体,其中有个结构体成员变量表示包体的长度,这是个很重要的变量,其他的结构体成员可根据需要自己定义.根据包头长度固定以及包头中含有包体长度的变量就能正确的拆分出一个完整的数据包。
数据封装流程图1.1 TCP段包头TCP段包头源端口(Source Port)和目地端口(Destination Port)--字段长度为16位，它们为封装的数据指定了源和目的应用程序。
序列号(Sequence Number)--字段长度为32位，序列号确定了发送方发送的数据流中被封装的数据所在位置。
确认号(Acknowledgment Number)--字段长度为32，确认号确定了源点下一次希望从目标接收的序列号。
报头长度(Header Length)--字段长度为4位，又称数据偏移量，报头长度指定了以32位为单位的报头长度。
保留(Reserved)--字段长度为6位，通常设置为0。
标记(Flag)--包括8个1位的标记，用于流和连接控制。
它们从左到右分别是：拥塞窗口减少(Congestion Window Reduced, CWR)、ECN-Echo(ECE)、紧急(URG)、确认(ACK)、弹出(PSH)、复位(RST)、同步(SYN)和结束(FIN)。
窗口大小(Window Size)--字段长度为16位，主要用于流控制。
校验和(Checksum)--字段长度为16位，它包括报头和被封装的数据，校验和允许错误检测。
紧急指针(Urgent Pointer)--字段长度16位，仅当URG标记位置时才被使用，这个16位数被添加到序列号上用于指明紧急数据的结束。
可选项(Options)--字段用于指明TCP的发送进程要求的选项。
最常用的可选项是最大段长度，最大段长度通知接收者发送者愿意接收的最大段长度。
WebRtc（网页即时通讯技术）知识点总结
WebRtc（⽹页即时通讯技术）知识点总结前⾔WebRTC，名称源⾃⽹页实时通信（Web Real-Time Communication）的缩写，简⽽⾔之它是⼀个⽀持⽹页浏览器进⾏实时语⾳对话或视频对话的技术。
并且还⽀持跨平台：windows，linux，mac，android，iOS。
实现原理P2P连接模式⼀般我们传统的连接⽅式，都是以服务器为中介的模式：类似http协议：客户端<——>服务端（当然这⾥服务端返回的箭头仅仅代表返回请求数据）。
进⾏即时通讯时，进⾏⽂字、图⽚、录⾳等传输的时候：客户端A——服务器——客户端B。
⽽点对点的连接恰恰数据通道⼀旦形成，中间是不经过服务端的，数据直接从⼀个客户端流向另⼀个客户端：客户端A——客户端B ... 客户端A——客户端C ...（可以⽆数个客户端之间互联）这个过程就像⾳视频通话的应⽤场景，我们服务端确实是没必要去获取两者通信的数据，⽽且这样做有⼀个最⼤的⼀个优点就是，⼤⼤的减轻了服务端的压⼒。
⽽WebRTC就是这样⼀个基于P2P的⾳视频通信技术。
客户端A与B建⽴p2p连接的过程1.A和B连接上服务端，建⽴⼀个TCP长连接（任意协议都可以，WebSocket/MQTT/Socket原⽣/XMPP），为了省事，直接采⽤WebSocket，这样⼀个信令通道就有了。
2.A从服务器获得ice server同时⽣成包含session description（SDP）的offer，发送给Socket服务端。
3.Socket服务端把A的offer和candidate转发给B，B会保存下A这些信息。
4.然后B发送包含⾃⼰session description的answer(因为它收到的是offer，所以返回的是answer，但是内容都是SDP)和ice candidate给Socket服务端。
5.Socket服务端把B的answer和ice candidate给A，A保存下B的这些信息。
RTP协议实时传输协议的音视频通信机制
RTP协议实时传输协议的音视频通信机制RTP（Real-time Transport Protocol）是实时传输协议，用于音视频通信中的数据传输。
它提供了一种标准化的方式，使得音视频数据可以在网络上进行传输和同步。
本文将详细介绍RTP协议的音视频通信机制。
一、RTP协议概述RTP协议是IETF（Internet Engineering Task Force）制定的一种应用层协议，用于实时传输音频和视频等数据。
它定义了一套传输和同步音视频数据的机制，使得接收方可以按照发送方的时序顺序恢复出完整的音视频内容。
二、RTP报文结构RTP报文由固定头部和有效载荷组成。
头部包含了标识数据类型、时间戳、序列号等信息，而有效载荷则是音视频数据的实际内容。
RTP 报文的结构如下所示：（这里根据实际情况插入图示）三、RTP传输流程RTP协议的传输流程包括发送端和接收端两个环节。
发送端将音视频数据打包成RTP报文，然后通过UDP协议进行传输。
接收端则根据报文头部中的时间戳和序列号信息进行解包和同步，最终将音视频内容展示给用户。
四、实时性保障机制RTP协议主要通过以下几个机制来保障音视频数据的实时性：1. 时间戳：RTP报文头部包含了时间戳信息，用于指示音视频数据的播放时间。
接收端可以根据时间戳信息对音视频进行同步，以保证播放的实时性。
2. 序列号：RTP报文头部的序列号字段可以用于检测丢包情况。
接收端可以根据序列号判断是否有报文未到达，如果有，可以通过重传机制进行数据的重新获取。
3. 延迟控制：延迟是音视频通信中不可避免的问题，RTP协议可以通过一些手段对延迟进行控制。
例如，可以使用RTCP（RTP Control Protocol）来监测网络状况，及时调整视频的码率以适应带宽的变化，从而减少延迟。
五、RTP与RTCP的配合RTP协议通常与RTCP协议搭配使用。
RTCP是RTP的控制协议，用于传输音视频会话的控制信息。
几种常见音视频传输协议使用总结
几种常见音视频传输协议使用总结音视频传输协议是指用于传输音频和视频数据的通信协议，其主要功能是将音视频信号编码、压缩、分包并传输到网络中，然后在接收端将其解包、解码并还原成音视频信号。
目前比较常见的音视频传输协议包括RTP/RTCP、RTSP、SIP、H.323、WebRTC等。
下面将对这几种协议进行总结。
一、 RTP/RTCPRTP（Real-time Transport Protocol）和RTCP（Real-time Transport Control Protocol）是一对用于音视频传输的协议，是IETF制定的标准协议之一。
RTP主要负责传输音视频数据，而RTCP则是对RTP传输的控制协议，用于传输控制信息。
RTP/RTCP主要用于实时通信场景下，如视频会议、IP电话等。
RTP/RTCP协议优点是实时性好，支持多种编码算法。
缺点是协议复杂，需要采用其他协议结合使用，比如RTSP。
二、RTSPRTSP（Real-time Streaming Protocol）是一种实时流媒体协议，是由IETF标准化的。
RTSP协议本身不传输音视频数据，而是传输对音视频数据进行控制的命令和参数。
RTSP 主要用于流媒体服务中，如监控摄像头、直播等场景下。
RTSP 协议优点是控制协议比较简单，可扩展性好，能够支持多种流媒体格式。
缺点是实时性相比RTP较差，需要使用其他协议结合使用。
三、 SIPSIP（Session Initiation Protocol）是一种会话初始化协议，是由IETF标准化的。
SIP主要用于会话管理，如呼叫建立、振铃、通话呼叫、目的地传递等。
SIP通常与其他协议如RTP、RTCP一起使用。
SIP协议优点是扩展性好，能够支持多种呼叫场景。
缺点是需要与其他协议结合使用，复杂度较高。
四、 H.323H.323是ITU-T定义的多媒体通信协议，主要用于实现视频会议、IP电话等场景下的音视频传输。
RTP协议实时传输协议详解
RTP协议实时传输协议详解RTP（Real-time Transport Protocol）是一种用于在互联网上传输实时数据的协议，被广泛应用于音频、视频以及其他多媒体数据的传输。
本文将详细解析RTP协议的特点、组成以及工作原理。
一、RTP协议特点RTP协议的主要特点如下：1. 实时性：RTP协议旨在传输实时数据，如音频、视频等。
它采用时间戳来确保数据的顺序和同步性，从而提供更好的实时性。
2. 独立性：RTP协议可以在不同的传输层协议（如UDP、TCP等）上运行，因此具有较好的独立性和兼容性。
3. 扩展性：RTP协议的头部可以添加自定义的扩展字段，以满足不同应用场景的需求。
4. 传输效率：RTP协议采用数据分片和压缩等技术，提高了传输效率和带宽利用率。
5. 错误恢复：RTP协议对丢失、重复和损坏的数据包进行处理和恢复，提高了传输的可靠性。
二、RTP协议组成RTP协议由头部和有效载荷两部分组成。
1. 头部（Header）：RTP头部用于存储传输相关的信息，包括版本号、负载类型、序列号、时间戳等。
头部的长度为12个字节。
2. 有效载荷（Payload）：有效载荷部分用于存储实际的数据，如音频、视频等。
三、RTP协议工作原理RTP协议的工作原理可以分为以下几个步骤：1. 建立会话：通信双方通过协商建立RTP会话。
会话的参数包括传输协议类型、有效载荷类型、时钟频率等。
2. 数据分帧：发送方将连续的音频或视频数据进行切割，生成RTP数据包。
每个数据包都包含RTP头部和有效载荷。
3. 添加序列号和时间戳：发送方为每个RTP数据包添加序列号和时间戳。
序列号用于标识数据包的顺序，时间戳用于实现同步播放。
4. 传输数据：发送方通过底层传输协议（如UDP）将RTP数据包发送给接收方。
5. 数据恢复：接收方根据序列号对接收到的数据包进行排序和恢复。
如果数据包有丢失或损坏，接收方可以根据序列号和时间戳进行错误恢复。
6. 解包和播放：接收方将RTP数据包解析成原始的音频或视频数据，并进行解码和播放。
webrtc rtp包解析流程
webrtc rtp包解析流程WebRTC（Web Real-Time Communication）是一种支持浏览器之间进行实时音视频通信的开放标准。
RTP（Real-time Transport Protocol）是WebRTC中用于传输音视频数据的协议。
在WebRTC中，RTP包的解析流程涉及到多个步骤和组件，我会从多个角度来解释这个流程。
首先，RTP包解析流程涉及到发送端和接收端两个主要组件。
发送端首先将音视频数据封装成RTP包，然后通过网络传输给接收端。
接收端接收到RTP包后，需要对RTP包进行解析，提取音视频数据并进行播放。
在发送端，RTP包的生成通常涉及到以下几个步骤，首先，将音视频数据进行采样和编码，然后将编码后的数据封装成RTP包。
在封装RTP包的过程中，需要添加RTP头部信息，包括版本号、序列号、时间戳等信息。
此外，还需要添加RTP扩展头部信息，用于传输一些额外的信息，比如帧间距福等。
最后，将封装好的RTP包通过网络传输给接收端。
在接收端，RTP包的解析流程通常包括以下几个步骤，首先，接收端需要从网络中接收RTP包，并进行解包，提取RTP头部信息和音视频数据。
然后，根据RTP头部信息进行序列重排和时钟同步，以确保音视频数据的顺序和同步性。
接着，对音视频数据进行解码和渲染，最终呈现给用户。
除了以上描述的基本流程，RTP包的解析还涉及到一些复杂的技术细节，比如网络传输中的拥塞控制、丢包恢复、抖动缓冲等。
此外，WebRTC中还使用了一些其他的协议和技术，比如SRTP （Secure Real-time Transport Protocol）用于加密RTP包，RTCP （RTP Control Protocol）用于传输控制信息等。
总的来说，RTP包的解析流程涉及到多个步骤和技术，包括RTP包的生成、传输和接收端的解析处理。
这个流程需要综合考虑音视频数据的采样、编码、传输和解码等多个环节，以确保实时音视频通信的顺畅和稳定。
RTP Over RTSP Over TCP(包格式分析)
RTP Over RTSP Over TCP 数据包分析通过TCP传输RTSP流的包结构如下：[RTSP报头][RTP报头][RTP Payload]●RTSP包分析socket接收到RTSP包结构：[Magic][Channel][0x00][0x00]Magic:0x24Channel取值由RTSP协议中Setup阶段设置的interleaved来决定，默认0-1，0代表后面的是RTP包，1代表RTCP包例如，设置TCP隧道传输RTP：SETUP rtsp://user:pwd@192.168.1.45:554/trackID=1 RTSP/1.0CSeq:2Transport:RTP/AVP/TCP;unicast;interleaved=0-1后面两个[0x00][0x00]字节是RTP或RTCP包的长度●RTP包分析RTP包由RTP报头和RTP Payload（有效载荷）构成。
RTP报头：[0x00][0x00][0x00][0x00]V(2bit)P(1bit)X(1bit)CC(4bit)M(1bit)PT(7bit)sequence number(16bit) 版本号、填充标记、扩展标记、CSRC计数器、有关有效载荷的标记、有效载荷类型(Payload Type)、序列号[0x00][0x00][0x00][0x00]time stamp 时间戳[0x00][0x00][0x00][0x00]synchronization source (SSRC) identifier 同步信源[0x00][0x00][0x00][0x00]contributing source (CSRC) identifiers 特约信源[Payload][Padding]V：2bit，版本号P：1bit，Padding标记，取值0-1，0表示Payload后面没有填充，1代表Payload 后跟有1个或最多8个字节的填充，如果有填充，RTP包最后一个字节是填充计数器，表示包含自身在内的填充的字节数X：1bit，扩展标记CSRC：4bit，Contributing Source identifiers Count，CSRC计数器，特约信源计数器M：标记，取值0-1，0代表不是一帧的结束，1代表一帧数据的结束，该值是由h264定义的NAL单元传输三个结构中的FU(Fragmentation unit 分片单元) 结构的Header中E结束位决定的PT：7bit，有效载荷类型，Payload TypeSeq：16bit，sequence number序列号，在前包的seq上自增1如果没有扩展，RTP包除去前面12个字节的报头后，就是Payload，如果有Padding，还要减去后面的填充RTP Payload:RTP Payload的结构，是由h264协议定义的，可能会有三种情况：1.当NAL单元小于MTU时，可以传输一个完整的NAL单元，即Payload就是原始的h264 NAL单元2.当NAL单元特别小时，可以同时传送两个或多个NAL单元，即组合封包模式3.当NAL单元大于MTU是，就分两个或多个RTP包发送，即分片封包（Fragmentation Units）传输H.264H.264基础要点H.264的功能分为两层，视频编码层（VCL）和网络提取层（NAL），VCL数据即被压缩编码后的视频数据序列。
srtp解包流程
srtp解包流程SRTP是一种加密实时通信协议，它提供了加密和认证机制，用于保护VoIP、视频会议和即时通讯等实时通信数据的传输安全。
在SRTP传输过程中，数据需要进行加密和认证操作，发送方通过加密算法将传输的数据转换为密文，接收方需要对密文进行解密，还原出原始数据。
本文将详细介绍SRTP解包流程。
SRTP解包由三个主要的步骤组成：解密、认证和解包。
解密是将密文转换成明文的过程，认证则是验证数据的完整性和真实性的过程，解包则是将解密过的数据还原出来的过程。
1. 解密SRTP的加密算法使用的是对称密钥加密算法，主要包括AES、Blowfish、Twofish等。
接收方需要获取传输的密钥，才能对数据进行解密。
解密过程中需要对接收到的SRTP包进行一系列处理，包括计算SRTCP索引值、计算解密密钥以及对SRTP包的头部信息进行解析。
接收到的SRTP包中包括了加密后的负载、头部信息、SRTP的认证标签MAC以及可能的扩展头部。
2. 认证SRTP的认证标签MAC使用的是HMAC-SHA1算法，接收方需要使用相同的算法来验证SRTP所接收到的数据的完整性和真实性。
具体步骤如下：(1) 抽取出需要验证的数据，包括头部、负载和索引值等。
(2) 通过计算HMAC-SHA1值，将上述数据与密钥相混合。
(3) 将计算得到的HMAC值与SRTP包中的认证标签进行比较，如果相等，则认为SRTP 包合法；否则认为SRTP包已被篡改，需要进行丢弃或重新发送。
3. 解包SRTP解包主要是将解密后的数据按照原始格式进行还原。
包括还原出RTP/RTCP数据包的头部、负载数据，以及可选的扩展头部。
SRTP的扩展头部可以包括多种元数据信息，例如SRTP的加密算法类型、密钥标识符等。
这些信息对于解析数据的接收方来说非常有用，可以帮助接收方正确还原数据，从而保障通讯数据的完整性和真实性。
综上所述，SRTP的解包流程主要是包括解密、认证和解包三个步骤。
RTP_h264解包源码
//// class CH264_RTP_UNPACKclass CH264_RTP_UNPACK{#define RTP_VERSION 2#define BUF_SIZE (1024 * 500)typed ef struct{//LITTLE_ENDIANunsigned short cc:4;/* CSRC count */unsigned short x:1; /* header extension flag */unsigned short p:1; /* pad ding flag */unsigned short v:2; /* packet type */unsigned short pt:7;/* payl oad type */unsigned short m:1; /* marker bit */unsigned short seq;/* sequence number */unsigned l ong ts; /* timestamp */unsigned l ong ssrc;/*synchronization source */} rtp_hdr_t;public:CH264_RTP_UNPACK ( HRESULT &hr, unsigned char H264PAYLOADTYPE = 96 ) : m_bSPSFound(false), m_bWaitKeyFrame(true), m_bPrevFrameEnd(false), m_bAssemblingFrame(false), m_wSeq(1234), m_ssrc(0){m_pBuf = new BYTE[BUF_SIZE] ;if ( m_pBuf == NULL ){hr = E_OUTOFMEMORY ;return ;}m_H264PAYLOADTYPE = H264PAYLOADTYPE ;m_pEnd = m_pBuf + BUF_SIZE ;m_pStart = m_pBuf ;m_dwSize = 0 ;hr = S_OK ;}~CH264_RTP_UNPACK(void){del ete [] m_pBuf ;}//pBuf为H264 RTP视频数据包，nSize为RTP视频数据包字节长度，outSize为输出视频数据帧字节长度。
rttcall 原理
rttcall 原理RTTCALL原理引言：RTTCALL是一种基于实时传输协议（Real-Time Transport Protocol，简称RTP）的通信技术，它能够实现实时语音和视频通话。
本文将介绍RTTCALL的原理和工作机制。
一、RTTCALL的概述RTTCALL是一种端到端的通信技术，它使用RTP作为底层传输协议，利用UDP实现数据的实时传输。
RTTCALL的目标是提供高质量、低延迟的语音和视频通话体验。
二、RTTCALL的工作流程1. 建立连接：在进行通话之前，需要建立连接。
通话的发起方会发送一个连接请求给接收方，接收方收到请求后会发送一个连接确认消息回复。
双方通过交换连接信息建立起连接。
2. 数据传输：一旦连接建立，通话双方就可以开始传输数据。
发送方会将语音或视频数据进行压缩和分包，并使用RTP协议封装成数据包。
然后通过UDP协议将数据包发送给接收方。
3. 数据接收：接收方收到数据包后，会进行解包和解压缩操作。
然后将解压缩后的数据进行播放或显示。
为了确保数据的实时性，接收方会对数据包进行时序校验，丢弃迟到的数据包。
4. 语音和视频同步：在语音和视频通话中，为了保持语音和视频的同步性，需要进行同步处理。
接收方会根据RTP协议中的时间戳信息对语音和视频进行同步。
5. 通话控制：RTTCALL还提供了一些通话控制的功能，例如静音、关闭摄像头等。
这些控制信息会被封装到RTP协议的扩展头部中，发送给接收方。
三、RTTCALL的特点和优势1. 实时性：RTTCALL能够实现实时传输，并且能够在不同网络环境下保持较低的延迟，提供流畅的通话体验。
2. 高质量：RTTCALL使用先进的音视频编解码技术，能够提供高质量的音视频通话效果。
3. 网络适应性：RTTCALL能够适应不同类型的网络环境，包括有线网络和无线网络。
它能够根据网络状况自动调整数据传输的速率和质量。
4. 安全性：RTTCALL支持数据加密和身份验证等安全机制，确保通话内容的机密性和完整性。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
H.264视频在android手机端的解码与播放文／南京邮电大学张永芹龚建荣摘要：本文实现了手机终端通过移动无线网络与媒体服务器进行通信，并就开发过程中的几个技术难点的解决方法进行了说明。
首先详细分析说明了rtp 打包，解包的流程，这是视频传输的基础；然后在RTP传输过程中，针对发送数据快而处理速度慢的问题，采用多线程并发机制予以解决；面对大量，而且不稳定的数据包，本文针对各个环节自己的特点，设计了多级缓冲处理机制，使得视频播放更加流畅、平稳。
接着，对于分析和解码的先后次序的问题，则采用线程协作的思想，利用消费者，生产者模式，保证了视频数据的时序性。
最后对于视频解码部分，则利用现有解码方法进行平台移植，深度简化代码，合理处理c层和java层的分工。
最后实践证明，采用本文提供的方法，视频传输、播放成功，而且android手机端视频播放延时短，流畅，平稳。
关键词：H.264 RTP 多级缓冲线程协作 android随着无线网络和智能手机的发展，智能手机与人们日常生活联系越来越紧密，娱乐、商务应用、金融应用、交通出行各种功能的软件大批涌现，使得人们的生活丰富多彩、快捷便利，也让它成为人们生活中不可取代的一部分。
其中，多媒体由于其直观性和实时性，应用范围越来越广，视频的解码与播放也就成为研究的热点。
H.264标准技术日渐成熟，采用了统一的VLC符号编码，高精度、多模式的位移估计，基于4×4块的整数变换、分层的编码语法等。
这些措施使得H.264算法具有很高的编码效率，在相同的重建图像质量下，能够比H.263节约50％左右的码率。
而且H.264的码流结构网络适应性强，增加了差错恢复能力。
正好适用于带宽受限，差错率高的无线网络。
本文结合ffmpeg开源代码中的解码方法，采用多线程接收数据包，多级缓冲数据，接收和解码并行双线程操作等方法，缓解了由于传输的数据量大、速度快而导致的数据堵塞、解码出错、视频画面迟钝、延迟等问题。
使得h.264视频的传输速度快，稳定性好。
最终实现了pc端到android手机端的视频传输，以及在android手机端的解码播放。
该技术可以应用于视频会议、视频监控等应用中。
一、 H.264视频传输播放系统的总体结构H.264视频传输播放系统分为服务器端和客户端2个部分，服务器端负责读取H.264的视频数据，并且以RTP/RTCP格式打包发送给客户端，并且接受客户端的反馈，对传输速度等作相应的控制。
Android手机客户端主要完成从服务器端接收实时码流数据，经过缓冲，进行视频数据解析，然后送去解码，最后在手机上显示播放。
服务器端采用c语言实现，客户端主要用java语言实现。
二、关键技术及其实现1.基于RTP协议的打包及解包（1）单个NAL打包H.264NALU单元常由[start code][NALU header][NALU payload]三部分组成，其中start code 用于标志一个NALU单元的开始，必须是“00000001”或者是“000001”，打包时去掉开始码，把其他数据打包到RTP包就可以了。
（2）分片打包由于1500个字节是IP数据报的长度的上限，去除20个字节的数据报首部，1480字节是用来存放UDP数据报的。
所以当一帧中的字节数超过这个数值时，我们必须将其分片打包。
而且UDP在传输的过程中也要由包头开销，所以将RTP 包的最大字节数定位1400字节。
需要分片的包格式有所区别，首先说明下分片的格式：FU指示字节有以下格式：+---------------+|0|1|2|3|4|5|6|7|+-+-+-+-+-+-+-+-+|F|NRI| Type |+---------------+FU指示字节的类型28，29表示FU-A和FU-B。
NRI域的值必须根据要分片的NAL单元NRI的值设置。
FU头的格式如下：+---------------+|0|1|2|3|4|5|6|7|+-+-+-+-+-+-+-+-+|S|E|R| Type |+---------------+S：开始位(1bit)，当设置为1，开始位指示分片NAL单元的开始。
第一个分片包设为1，其他的分片设置为0。
E：结束位(1bit)，当设置为1，结束位指示分片NAL单元的结束，即，FU 荷载是最后分片时设置为1，其他时候设置为0。
R：保留位(1bit)，必须设置为0。
Type：5bit（3）打包和解包的流程分析：打包：分片时详细说明：①第一个FU-A包的FU indicator 是这么设置的：F=NALU头中的F，NRI=NALU 头中的NRI，Type=28 FU header: S=1，E=0，R=0，Type=NALU头中的Type；②中间的FU-A包的FU indicator是这么设置的：F=NALU头中的F，NRI=NALU 头中的NRI，Type=28 FU header: S=0，E=0，R=0，Type=NALU头中的Type；③尾FU-A包的FU indicator是这么设置的：F=NALU头中的F，NRI=NALU头中的NRI，Type=28 FU header: S=0，E=1，R=0，Type=NALU头中的Type。
解包：下面我们针对RTP解包时对待分片进行分类的代码实现做分析：byte startBit=(byte)(recbuf[13]&0x80); byteendBit=(byte)(recbuf[13]&0x40);①如果，startBit==-128，这包是分片的首包。
NalBuf[4]=(byte) ((recbuf[12]&0xE0)+(recbuf[13]&0x1F)); 这句用于重建组合NAL单元类型②如果(startBit==0)&&(endBit==0)，这包是分片的中间部分。
③如果 endBit==64 ，这包是分片尾部。
当分类清楚，就可以对各部分做相应的处理，如图中分析的那样。
2.码流管理机制(1) 码流的接收。
在发送端码流发送很快的情况下，由于接收端不仅要接收码流，还要进行分析，解码，这个处理需要一个较长的过程，如果接收端顺序执行这个过程的话，会导致无法完整接收发送端的包、出现丢包，由此而带来的是解码错误、无法正常播放视频、甚至程序奔溃等严重错误。
针对这个问题我们采取并发的处理机制予以解决。
线程并发存在的一个意义就是为了提高运行在单处理器上的速度。
在java中我们采用java.util.concurrent包中的执行器（Executor）来管理线程Thread对象。
我们创建20个线程，也就是向SingleThreadExecutor 提交了20个任务，这些任务将排好队，每个任务会在下一个任务开始之前运行结束，每个任务都是按照他们被提交的顺序，在下一个任务开始之前完成。
这样不仅实现了快速的接收而且还保证了接收到的包顺序是正确的。
通过这样的处理后，接收和分析解码可以被分成两个部分，我们可以把接收到的数据暂时存放在缓冲区，然后就可以接着去接收下一包数据，不用等着分析、解码完成后才去接收下一包数据。
这样做大大提高了接收效率，同时避免了丢包问题。
(2) 视频数据解析和解码。
由于采用了并发的机制，接收到的数据不止一包，所以对接收到的数据应该做怎样合理的处理，成为我们接下来的难点。
我们需要保证的仍然是数据包的顺序，还且每次只能处理一包，这里涉及到一个线程之间的协作问题。
我们采用消费者生产者这种线程协作模式来做处理。
我们将从存放数据的缓冲区中按顺序取到的包经过分析后放入另外一个缓冲区，通知解码程序可以进行从此缓冲区中获得数据解码，然后分析视频数据的程序进入等待。
解码完成后，通知分析视频数据的程序继续进行视频数据分析，同时解码程序又进入等待。
两个程序在执行和等待中交替进行。
(3) 多级缓冲机制。
上面我们也提到了几个缓冲，总结如下。
①接收后存放数据的缓冲，由于服务器端源源不断的实时码流，和采用了并发机制后带来更大量的数据，我们不可能马上处理完，所以必须设置一个缓冲区。
②接收端和处理端之间的缓冲，由于网络不稳定，接收到的数据可能会有时快有时慢，这直接会造成解码的不稳定和视频播放的不连续，所以在此设置一个缓冲，起到一个平滑，过渡的作用，这个缓冲区既要存放接收到大量的码流还要为视频数据分析提供数据，有个写读入和读出的过程，所以我们使用先入先出的队列Queue容器来做缓冲区。
③解析和解码过程之间的缓冲，由于在此过程中的数据量相较而言不是很大，而这个获取数据的速度直接影响了解码的速度，所以我们要用一个高效的缓冲区来担当此时的缓冲作用，由于stack是由系统自动分配，所以速度比较快，所以我们就在栈上分配一个数组用于存储即可。
④解码后到播放之间的缓冲，这个缓冲区同样除了起到使播放视频连续稳定的作用外，主要就是用来显示图像，还可以对视频图像进行一些处理工作，平滑，滤波等。
3.解码和播放的实现H.264解码是移植了ffmpeg中的H.264解码部分到Android，并且了深度删减优化。
界面部分，文件接收处理以及视频显示都是用java做的，底层的视频解码部分则使用C来做从而满足速度的要求。
H.264码流分割NAl（接受到视频数据的复原工作）是在java层做而没有分装到c中，是因为每次送的数据会受到限制，如果送的数据量大，底层可能会一次解码好几帧视频，但是到界面层只能显示一帧，造成丢帧。
如果每次送的数据量较少，就会使得多次底层调用但并没有进行实质解码的现象发生，所以尽管这样做耦合度差些，速度慢些，但是综合考虑还是将数据分析工作放在java层完成。
我们将解码后的视频数据用bitmap显示，draw到surfaceView的方法显示到手机屏上，由于有些手机不支持rgb24但几乎所有手机都支持rgb565，所以解码后返回的是rgb565数据。
4.程序流程功能架构三、结束语本文完整的设计并实现了从pc端到android手机端的H.264视频传输与解码播放功能。
详细的分析了实现中的技术要点和难点，详细分析了rtp打包，解包的流程，针对发送数据快而处理速度慢的问题，采用多线程并发机制予以解决，面对大量，而且不稳定的数据包，针对各个环节的特点，设置了多级缓冲。
使得视频播放更加流畅、平稳。
对于分析和解码的先后次序问题，采用线程协作的思想，利用消费者，生产者模式，保证了视频数据的时序性。
另外对于解码部分，则利用现有解码方法进行平台移植，合理处理c层和java层的分工，并以实现了这个完整的功能。
在网络状况好的情况下，android手机端视频播放延时短，播放流畅，平稳。
本文技术研究可以运用到视频播放的各个应用中，有着很强的实用价值。