rtp

3 月，跳不动了？>>> WEB播放RTSP直播数据流方法 附录一些RTSP测试地址： 1、rtsp://184.72.239.149/vod/mp4://BigBuckBunny_175k.mov 一段动画片 2、rtsp://218.204.223.237:554/live/1/66251FC11353191F/e7ooqwcfbqjoo80j.sdp 拱北口岸珠海过澳门大厅 3、rtsp://218.204.223.237:554/live/1/0547424F573B085C/gsfp90ef4k0a6iap.sdp rtmp://live.hkstv.hk.lxdns.com/live/hks rtsp://184.72.239.149/vod/mp4://BigBuckBunny_175k.mov mms://space.hngd.gov.cn/live1 http://movie.ks.js.cn/flv/other/1_0.flv http://live.hkstv.hk.lxdns.com/live/hks/playlist.m3u8 截止于2017.4.22 19:48分，全部测试可用，便于大家开发测试！ 在html技术中目前是无法直接使用现有的web技术进行播放rtsp直播数据流的，下面总结了可以是web播放rtsp直播流的方法。只是自己备用。 1

3 月，跳不动了？>>> 腾讯会议去年推出，疫情期间两个月急速扩容，日活跃账户数已超过1000万，成为了当前中国最多人使用的视频会议应用。腾讯会议突围背后，是如何通过端到端实时语音技术保障交流通畅的？本文是腾讯多媒体实验室音频技术中心高级总监商世东老师在「云加社区沙龙online」的分享整理，从实时语音通信的发展历程，到5G下语音通信体验的未来，为你一一揭晓。 点击此链接，查看完整直播视频回放 ​ 一、通信系统的衍变 1. 从模拟电话到数字电话 说到腾讯会议背后的实时语音端到端解决方案，大家可能第一时间就想到了PSTN电话，从贝尔实验室创造模拟电话开始，经过一百多年的发展，整个语音通信、语音电话系统经历了很大一部分变化。尤其是最近三十年来，语音通话由模拟信号变为数字信号，从固定电话变为移动电话，从电路交换到现在的分组交换。 以前的PSTN电话系统，用的都是老式模拟话机。然后数字相对模拟电话的优势是显而易见的，尤其在通话语音质量上抗干扰，抗长距离信号衰减的能力明显优于模拟电话和系统，所以电话系统演进的第一步就是从终端从模拟电话升级到了数字电话，网络也升级到了ISDN(综合业务数字网)，可以支持数字语音和数据业务。 ISDN的最重要特征是能够支持端到端的数字连接，并且可实现话音业务和数据业务的综合，使数据和话音能够在同一网络中传递。但是本质上，ISDN还是电路交换网络系统。

3 月，跳不动了？>>> 首先，了解了一下视频直播相关的概念。常用的几种视频协议是： RTMP 、 HTTP-FLV 、 HLS 、 RTP/RTCP 协议。 然后我们会在说明一下直播整体的流程和相关的技术。 视频直播协议 在直播领域大概可以分类两种类型的在直播：一种是交互式直播，另外一种是非交互式直播。 非交互式直播（如：阅兵直播、 NBA 直播、欧冠直播等）交互性不强，允许延迟 10 秒或者 10 秒以上，特点是源比较少，适合做多路转码（用户可以根据网络条件观看）。 交互式直播的典型场景有：秀场直播、游戏直播等。这些直播因为对主播和观众的互动性要求比较高，所以要求延迟在 5s 以内。交互式直播的特点是：源比较多，不适合做多路转码，中间服务器只作为中转角色。 直播内容传输的介质是网络，而网络中传播视频或者音频时需要使用对应的协议，目前适合直播场景的常用协议有如下几种。 1.RTMP 协议 (HTML 5 不支持， Flash 支持 ) RTMP 是一种流媒体协议，是 Adobe 的专利协议。基于 TCP ，在国内的使用流行度很高。 流行原因：开源软件和开源库的支持稳定完整，最常用的推流和拉流的解决方案基本上能够很稳定的运行。如：开源的 librtmp 推流库，服务端有 nginx-rtmp 插件，拉流有 ijkPlayer 播放库。 2.HTTP-FLV 协议 (HTML 5

疫情将远程办公，视频会议推上了风口的同时，同样也为视频会议平台的运作带来了更多的挑战。蓝猫微会创始人兼CEO 邓昀泽在LiveVideoStack线上分享中针对视频会议系统优化中弱网定义，算法评估及技术实现等细节进行了详细解析。 文 / 邓昀泽 整理 / LiveVideoStack 视频回放 https://www2.tutormeetplus.com/v2/render/playback?mode=playback&token=2bf0147fa84c44a9b6a5d448669f16c0 大家好，我是蓝猫微会的创始人兼CEO 邓昀泽，本次我分享的主题是：视频会议场景下的弱网优化，下面我将从以下三个方面展开本次分享的全部内容： 弱网的定义 评估算法 传输优化 要探究视频会议在弱网场景的优化，需要首先从场景化与数字化角度对弱网进行准确的定义，这样在处理相关问题时才能得出一些具有针对性的解决方案。接下来就需要评估并优化算法，结合场景与数字化的方式验证优化方法的可行性、有效性。算法优化永远是在各场景之间寻求一种平衡，不同场景对参数的选择是不同的。如果没有一个场景化的评估标准，那么针对不同场景的算法优化容易导致一个场景有效，另外场景恶化。因此弱网的定义与评估至关重要。在针对性地分析并得出优化算法之后，我们需要根据整个过程的效果评估不同场景下的算法选型。 弱网定义

原文： http://general.blog.51cto.com/927298/328220 RTP 时间戳的处理 　　时间戳字段是RTP首部中说明数据包时间的同步信息，是数据能以正 确的时间顺序恢复的关键。时间戳的值给出了分组中数据的第一个字节的采样时间(Sampling Instant)，要求发送方时间戳的时钟是连续、单调增长的，即使在没有数据输入或发送数据时也 是如此。在静默时，发送方不必发送数据，保持时间戳的增长，在接收端，由于接收到的数据分组的序号没有丢失，就知道没有发生数 据丢失，而且只要比较前后分组的时间戳的差异，就可以确定输出的时间间隔。 　　RTP规定一次会话的初始时间戳必须随机选择，但协议没有规定时 间戳的单位，也没有规定该值的精确解释，而是由负载类型来确定时钟的颗粒，这样各种应用类型可以根据需要选择合适的输出计时精度。 　　在RTP传输音频数据时，一般选定逻辑时间戳速率与采样速率相同， 但是在传输视频数据时，必须使时间戳速率大于每帧的一个滴答。如果数据是在同一时刻采样的，协议标准还允许多个分组具有相同的时 间戳值。 　　RTP协议没有规定RTP分组的长度和发送数据的速度，因而需要根据具体情况调整服务器端发送 媒体数据的速度。对来自设备的实时数据可以采取等时间间隔访问设备缓冲区，在有新数据输入时发送数据的方式，时间戳的设置相对 容易

RTP报文格式 RTP 报文由两部分组成：报头和有效载荷。 RTP 报头格式如图 6.7 所示，其中： l V ： RTP 协议的版本号，占 2 位，当前协议版本号为 2 。 l P ：填充标志，占 1 位，如果 P=1 ，则在该报文的尾部填充一个或多个额外的八位组，它们不是有效载荷的一部分。 l X ：扩展标志，占 1 位，如果 X=1 ，则在 RTP 报头后跟有一个扩展报头。 l CC ： CSRC 计数器，占 4 位，指示 CSRC 标识符的个数。 l M: 标记，占 1 位，不同的有效载荷有不同的含义，对于视频，标记一帧的结束；对于音频，标记会话的开始。 l 同步信源 (SSRC) 标识符：占 32 位，用于标识同步信源。该标识符是随机选择的，参加同一视频会议的两个同步信源不能有相同的 SSRC 。 l 特约信源 (CSRC) 标识符：每个 CSRC 标识符占 32 位，可以有 0 ～ 15 个。每个 CSRC 标识了包含在该 RTP 报文有效载荷中的所有特约信源。 l PT: 有效载荷类型，占 7 位，用于说明 RTP 报文中有效载荷的类型，如 GSM 音频、 JPEM 图像等。 l 序列号：占 16 位，用于标识发送者所发送的 RTP 报文的序列号，每发送一个报文，序列号增 1 。接收者通过序列号来检测报文丢失情况，重新排序报文，恢复数据。 l 时戳

学习计算机网络时，会阅读相关的专业文献。对于文献中经常出现的缩写形式的专业名词，做了一些积累。现于此博文中做个简单的分享，希望能对后来人有所帮助，平稳地入门计算机网络。 注：博文内容仅可用于参考，遇到分歧时，还需请教专业人士！ A 序号 英文缩写 英文 1 AS Autonomous System 2 APP application-specific functions 3 ATM Asynchronous Transfer Mode 4 AP Access Point 5 ARP Address Resolution Protocol   B 序号 英文缩写 英文 1 BT Bit Torrent 2 BSS Basic Service Set   C 序号 英文缩写 英文 1 CBT Core Based Trees 2 CSRC contributing source 3 CNAME Canonial Name 4 CERN European Organization for Nuclear Research 5 CCITT Consultative Committee on International Telegraph and Telephone 6 CSMA/CD Carrier Sense Multiple Access with Collision

最近被RTP的负载类型和时间戳搞郁闷了，一个问题调试了近一周，终于圆满解决，回头看看，发现其实主要原因还是自己没有真正地搞清楚RTP协议中负载类型和时间戳的含义。虽然做RTP传输，有着Jrtplib和Ortp这两个强大的库支持，一个是c++接口，一个是c语言接口，各有各的特点，各有各的应用环境，但是仅仅有库就能解决一切问题吗？可能仿照着一些例子程序，你能够完成主要的功能，但一旦问题发生了，不清楚原理你是很难定位和解决问题的，所以在此，用我的经验劝劝大家，磨刀不误砍柴工，做应用还是先把原理搞清楚再动手吧…… 看这篇文章之前，首先你应该知道什么是RTP协议，可以去看RTP协议原文（RFC3550协议），也可以看一些网友对RTP协议的讲解的文章，很多，这里我提供一篇我个人觉得写得还不错的：http://blog.csdn.net/bripengandre/archive/2008/04/01/2238818.aspx 。 下面言归正传，首先谈谈RTP传输中的负载类型吧 。 首先，看RTP协议包头的格式： 10~16 Bit为PT域，指的就是负载类型（PayLoad），负载类型定义了RTP负载的格式，协议原文说该域由具体应用决定其解释。 目前，负载类型主要用来告诉接收端（或者播放器）传输的是哪种类型的媒体（例如G.729，H.264，MPEG-4等），这样接收端（或者播放器

1 <?xml version="1.0" encoding="ISO-8859-1" ?> 2 <!DOCTYPE scenario SYSTEM "sipp.dtd"> 3 4 <!-- This program is free software; you can redistribute it and/or --> 5 <!-- modify it under the terms of the GNU General Public License as --> 6 <!-- published by the Free Software Foundation; either version 2 of the--> 7 <!-- License, or (at your option) any later version. --> 8 <!-- --> 9 <!-- This program is distributed in the hope that it will be useful, --> 10 <!-- but WITHOUT ANY WARRANTY; without even the implied warranty of --> 11 <!-- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See

SDP包 其中的Connection Information 后面的192.168.11.105 就是RTP的IP地址 audio 后面的5100 就是RTP 的端口。 RTP/AVP 后面的0 8 101 表示支持的编码 0 表示G.711 Ulaw, 8表示G.711的Alaw，101 是表示 支持电话按键事件 后面的很多Media Attribute 是对媒体属性的具体描述。 总结一下：SDP 的核心有几个： A．说明媒体的来源IP地址 B．说明媒体的来源的端口port C．说明自己有哪些媒体能力（能说几个语言） D．包括对dtmf 按键的是否支持是说明。 一旦两个软电话要对话，就要对比交换上面这些信息。比如FreeSwitch默认要求rfc2833模式的 DTMF按键(上面抓包里面的rtpmap:101 telephone-event/8000)，但是假如软电话上没有设置rfc2833的 DTMF，那么SDP就没有101，协商就不会成功，从而导致通话无法建立。 编码占用带宽 VOIP的数据包包括SIP 数据包和RTP 数据包，SIP只是传输控制命令，跟RTP的语音媒体数据包比较 起来简直就是九牛一毛，完全可以忽略不计。 下面仅仅计算RTP的数据包 RTP的数据包=以太网地址+IP类型+IP包头+UDP包头+RTP包头+语音编码之后的负载 以太网地址12字节 IP类型2字节