多媒体杂谈--有点乱后继整理

 第1章.     RTP 

1.1.  RTP是什么

RTP全名是Real-time Transport Protocol（实时传输协议）。它是IETF提出的一个标准，对应的RFC文档为RFC3550（RFC1889为其过期版本）。RFC3550不仅定义了RTP，而且定义了配套的相关协议RTCP（Real-time Transport Control Protocol，即实时传输控制协议）。RTP用来为IP网上的语音、图像、传真等多种需要实时传输的多媒体数据提供端到端的实时传输服务。RTP为Internet上端到端的实时传输提供时间信息和流同步，但并不保证服务质量，服务质量由RTCP来提供。

1.2.  RTP头

 

开始12个字节出现在每个RTP包中，而CSRC标识列表仅出现在混合器插入时。各段含义如下：

① 本（V）

2位，标识RTP版本。目前都是2.

② 充标识（P）

1位，如设置填充位，在包尾将包含附加填充字，它不属于有效载荷。填充的最后一个八进制包含应该忽略的八进制计数。某些加密算法需要固定大小的填充字，或为在底层协议数据单元中携带几个RTP包。当前不使用特殊的加密算法，因此该位设为 0。

③ 展（X）

1位，如设置扩展位，固定头后跟一个头扩展。目前只有手机视频会带扩展头

④CSRC计数（CC）

4位，CSRC计数包括紧接在固定头后CSRC标识符个数。

④ 记（M）

1位，标记解释由设置定义，目的在于允许重要事件在包流中标记出来。设置可定义其他标示位，或通过改变位数量来指定没有标记位。

音频时该位为0，视频时需要使用，最后一个slice需要设置为1.

 

⑥载荷类型（PT）

7位，记录后面资料使用哪种 Codec ， receiver 端找出相应的 decoder 解碼出來。

常用 types：

Payload Type	Codec
0	PCM μ –Law
8	PCM-A Law
9	G..722 audio codec
4	G..723 audio codec
15	G..728 audio codec
18	G..729 audio codec
34	G..763 audio codec
31	G..761 audio codec
93	nvoc audio codec（P）
98	H264 video codec（b）
126	AMR audio codec（b）

 

下表中没指定的都应该是厂商自定义。

注：

               PT      encoding    media type  clock rate

                       name                    (Hz)

               _____________________________________________

               24      unassigned  V

               25      CelB        V           90,000

               26      JPEG        V           90,000

               27      unassigned  V

               28      nv          V           90,000

               29      unassigned  V

               30      unassigned  V

               31      H261        V           90,000

               32      MPV         V           90,000

               33      MP2T        AV          90,000

               34      H263        V           90,000

               35-71   unassigned  ?

               72-76   reserved    N/A         N/A

               77-95   unassigned  ?

               96-127  dynamic     ?

               dyn     H263-1998   V           90,000

 

               Table 5: Payload types (PT) for video and combined

                        Encodings

 

               PT   encoding    media type  clock rate   channels

                    name                    (Hz)

               ___________________________________________________

               0    PCMU        A            8,000       1

               1    reserved    A

               2    reserved    A

               3    GSM         A            8,000       1

               4    G723        A            8,000       1

               5    DVI4        A            8,000       1

               6    DVI4        A           16,000       1

               7    LPC         A            8,000       1

               8    PCMA        A            8,000       1

               9    G722        A            8,000       1

               10   L16         A           44,100       2

               11   L16         A           44,100       1

               12   QCELP       A            8,000       1

               13   CN          A            8,000       1

               14   MPA         A           90,000       (see text)

               15   G728        A            8,000       1

               16   DVI4        A           11,025       1

               17   DVI4        A           22,050       1

               18   G729        A            8,000       1

               19   reserved    A

               20   unassigned  A

               21   unassigned  A

               22   unassigned  A

               23   unassigned  A

               dyn  G726-40     A            8,000       1

               dyn  G726-32     A            8,000       1

               dyn  G726-24     A            8,000       1

               dyn  G726-16     A            8,000       1

               dyn  G729D       A            8,000       1

               dyn  G729E       A            8,000       1

               dyn  GSM-EFR     A            8,000       1

               dyn  L8          A            var.        var.

               dyn  RED         A                        (see text)

               dyn  VDVI        A            var.        1

 

               Table 4: Payload types (PT) for audio encodings

 

 

⑦系列号

16位，系列号随每个RTP数据包而增加1，由接收者用来探测包损失。系列号初值是随机的，使对加密的文本攻击更加困难。

⑧时标

32位，时标反映RTP数据包中第一个八进制数的采样时刻，采样时刻必须从单调、线性增加的时钟导出，以允许同步与抖动计算。时标可以让receiver端知道在正确的时间将资料播放出来。

 

由上图可知，如果只有系列号，并不能完整按照顺序的将data播放出来，因为如果data中间有一段是没有资料的，只有系列号的话会造成错误，需搭配上让它知道在哪个时间将data正确播放出来，如此我们才能播放出正确无误的信息。

⑨SSRC

32位，SSRC段标识同步源。此标识不是随机选择的，目的在于使同一RTP包连接中没有两个同步源有相同的SSRC标识。尽管多个源选择同一个标识的概率很低，所有RTP实现都必须探测并解决冲突。如源改变源传输地址，也必须选择一个新SSRC标识以避免插入成环行源。

⑩CSRC列表

0到15项，每项32位。CSRC列表表示包内的对载荷起作用的源。标识数量由CC段给出。如超出15个作用源，也仅标识15个。CSRC标识由混合器插入，采用作用源的SSRC标识。

我们b系统一般都是0个，没有此项。

 

1.2.1 Rtp扩展头结构

RTP 提供扩展机制以允许实现个性化:某些新的与负载格式独立的功能要求的附加信息在RTP 数据包头中传输。设计此方法可以使其它没有扩展的交互忽略此头扩展。RTP扩展头格式如图2所示。                                 

        图2 RTP扩展头格式

若 RTP 固定头中的扩展比特位置 1，则一个长度可变的头扩展部分被加到 RTP 固定头之后。头扩展包含 16 比特的长度域，指示扩展项中 32 比特字的个数，不包括 4 个字节扩展头(因此零是有效值)。RTP 固定头之后只允许有一个头扩展。为允许多个互操作实现独立生成不同的头扩展，或某种特定实现有多种不同的头扩展,扩展项的前 16 比特用以识别标识符或参数。这 16 比特的格式由具体实现的上层协议定义。基本的 RTP 说明并不定义任何头扩展本身。

1.2.2 视频RTP包扩展头定义

在扩展头里面我们需要填充版本号、角度值等内容，设计如图3所示：

0								1								2								3
0	1	2	3	4	5	6	7	0	1	2	3	4	5	6	7	0	1	2	3	4	5	6	7	0	1	2	3	4	5	6	7
Defined by Profile(bc)																Length(1)
Version(0000 0000 0000 0001)																Degree

 

其中Defined by Profile占16比特定义为bc，即1011 1100，取Btrun-C的缩写；

Length占16比特，取值0000 0000 0000  0001；

Version定义为：0000 0000 0000 0001；

Degree占4比特，填写角度，可以有四个取值（角度除以90）：

不旋转：0

顺时针旋转90度：1

顺时针旋转180度：2

顺时针旋转270度：3

 

 

 

1.2.3 视频角度

RTP头扩展里的Degree内容意义是接收端显示视频图像之前需要对图像旋转的角度。增加此值的意义主要有：

1、 不管发送端手机如何旋转，接收端可以按照正的方向显示图像内容；

2、 屏蔽手机硬件上摄像头镜头方向的差异。

 

   Degree = 90           Degree = 180           Degree = 270            Degree = 0

 

 

1.3.  声音和图像怎么同步

根据声音流和图像流的相对时间（即RTP包的时间戳），以及它们的绝对时间（即对应的RTCP包中的RTCP），可以实现声音和图像的同步。

目前无RTCP，怎么实现同步。

 

1.4.  内容封装

live555主要用于网络流接收，ffmpeg则是对接收到的数据进行编码/解码。

1.4.1 分片slice

RFC3984 给出了3 中不同的RTP 打包方案：

（1）Single NALU Packet:在一个RTP 包中只封装一个NALU，在本文中对于小于 1400字节的NALU 便采用这种打包方案。 
       （2）Aggregation Packet:在一个RTP 包中封装多个NALU，对于较小的NALU 可以采用这种打包方案，从而提高传输效率。 
       （3）Fragmentation Unit:一个NALU 封装在多个RTP包中，在本文中，对于大于1400字节的NALU 便采用这种方案进行拆包处理。

接收 RTP数据包，从RTP 包中解析出NALU 单元，然后送至解码器进行解码播放。该流媒体传输系统的框架如图3 所示。

 

 

 

1.4.1 I帧P帧

IDR（Instantaneous Decoding Refresh）--即时解码刷新。 

I帧:帧内编码帧是一种自带全部信息的独立帧，无需参考其它图像便可独立进行解码，视频序列中的第一个帧始终都是I帧。 

   I和IDR帧都是使用帧内预测的。它们都是同一个东西而已,在编码和解码中为了方便，要首个I帧和其他I帧区别开，所以才把第一个首个I帧叫IDR，这样就方便控制编码和解码流程。 IDR帧的作用是立刻刷新,使错误不致传播,从IDR帧开始,重新算一个新的序列开始编码。而I帧不具有随机访问的能力，这个功能是由IDR承担。 IDR会导致DPB（DecodedPictureBuffer 参考帧列表——这是关键所在）清空，而I不会。IDR图像一定是I图像，但I图像不一定是IDR图像。一个序列中可以有很多的I图像，I图像之后的图像可以引用I图像之间的图像做运动参考。一个序列中可以有很多的I图像，I图像之后的图象可以引用I图像之间的图像做运动参考。 

   对于IDR帧来说，在IDR帧之后的所有帧都不能引用任何IDR帧之前的帧的内容，与此相反，对于普通的I-帧来说，位于其之后的B-和P-帧可以引用位于普通I-帧之前的I-帧。从随机存取的视频流中，播放器永远可以从一个IDR帧播放，因为在它之后没有任何帧引用之前的帧。但是，不能在一个没有IDR帧的视频中从任意点开始播放，因为后面的帧总是会引用前面的帧 。

  收到 IDR 帧时，解码器另外需要做的工作就是：把所有的 PPS 和 SPS 参数进行更新。

  对IDR帧的处理(与I帧的处理相同)：(1) 进行帧内预测，决定所采用的帧内预测模式。(2) 像素值减去预测值，得到残差。(3) 对残差进行变换和量化。(4) 变长编码和算术编码。(5) 重构图像并滤波，得到的图像作为其它帧的参考帧。

  多参考帧情况下，  举个例子 ：有如下帧序列： IPPPP I P PPP ……。按照 3 个参考帧编码。

     因为“按照 3 个参考帧编码”，所以参考帧队列长度为 3 。

    遇到绿色的 I 时，并不清空参考帧队列，把这个 I 帧加入参考帧队列（当然 I 编码时不用参考帧。）。再检测到红色的 P 帧时，用到的就是 PPI 三帧做参考了。

 

P帧:前向预测编码帧

    在针对连续动态图像编码时，将连续若干幅图像分成P,B,I三种类型，P帧由在它前面的P帧或者I帧预测而来，它比较与它前面的P帧或者I帧之间的相同信息或数据，也即考虑运动的特性进行帧间压缩。P帧法是根据本帧与相邻的前一帧（I帧或P帧）的不同点来压缩本帧数据。采取P帧和I帧联合压缩的方法可达到更高的压缩且无明显的压缩痕迹。

P帧的预测与重构:P帧是以I帧为参考帧，在I帧中找出P帧“某点”预测值和运动矢量，取预测差值和运动矢量一起传送。在接收端根据运动矢量从I帧中找出P帧“某点”的预测值并与差值相加以得到P帧某点样值，从而可得到完整的P帧。

有的视频序列比较简单，就没有B帧，

B帧：双向预测内插编码帧

B帧的预测与重构

 B帧法是双向预测的帧间压缩算法。当把一帧压缩成B帧时，它根据相邻的前一帧、本帧以及后一帧数据的不同点来压缩本帧，也即仅记录本帧与前后帧的差值。只有采用B帧压缩才能达到200：1的高压缩。

 B帧是以前面的I或P帧和后面的P帧为参考帧，找出B帧“某点”的预测值和两个运动矢量，并取预测差值和运动矢量传送。接收端根据运动矢量在两个参考帧中。

 

1.4.3  H.264视频RTP负载格式  

2012-03-14 20:46:49|  分类： Live555学习笔记 |  标签： |举报 |字号大中小 订阅

1. 网络抽象层单元类型 (NALU)（Network Abstract Layer Unit）

NALU 头由一个字节组成, 它的语法如下:

      +---------------+
      |0|1|2|3|4|5|6|7|
      +-+-+-+-+-+-+-+-+
      |F|NRI|  Type   |
      +---------------+

F: 1 个比特.
  forbidden_zero_bit. 在 H.264 规范中规定了这一位必须为 0.

NRI: 2 个比特.
  nal_ref_idc. 取 00 ~ 11, 似乎指示这个 NALU 的重要性, 如 00 的 NALU 解码器可以丢弃它而不影响图像的回放. 不过一般情况下不太关心这个属性.

Type: 5 个比特.
  nal_unit_type. 这个 NALU 单元的类型. 简述如下:

  0     没有定义
  1-23  NAL单元  单个 NAL 单元包.
  24    STAP-A   单一时间的组合包
  25    STAP-B   单一时间的组合包
  26    MTAP16   多个时间的组合包
  27    MTAP24   多个时间的组合包
  28    FU-A     分片的单元
  29    FU-B     分片的单元
  30-31 没有定义

    0：未规定
    1：非IDR图像中不采用数据划分的片段
    2：非IDR图像中A类数据划分片段
    3：非IDR图像中B类数据划分片段
    4：非IDR图像中C类数据划分片段
    5：IDR图像的片段
    6：补充增强信息 (SEI)
    7：序列参数集
    8：图像参数集
    9：分割符
    10：序列结束符
    11：流结束符
    12：填充数据

NALU 包括一个片、SPS、PPS、SEI等等

序列参数集（SPS）、图像参数集（PPS）、增强信息（SEI）、条带（Slice）等，其中，SPS和PPS属于参数集，两标准采用参数集机制是为了将一些主要的序列、图像参数（解码图像尺寸、片组数、参考帧数、量化和滤波参数标记等）与其他参数分离，通过解码器先解码出来。此外，为了增强图像的清晰度，AVS-M添加了图像头（Picture head）信息。

 

2. 打包模式

  下面是 RFC 3550 中规定的 RTP 头的结构.

       0                   1                   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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |V=2|P|X|  CC   |M|     PT      |       sequence number         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           timestamp                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           synchronization source (SSRC) identifier            |
      +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
      |            contributing source (CSRC) identifiers             |
      |                             ....                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  负载类型 Payload type (PT): 7 bits
  序列号 Sequence number (SN): 16 bits
  时间戳 Timestamp: 32 bits
 
  H.264 Payload 格式定义了三种不同的基本的负载(Payload)结构. 接收端可能通过 RTP Payload的第一个字节来识别它们. 这一个字节类似 NALU 头的格式, 而这个头结构的 NAL 单元类型字段则指出了代表的是哪一种结构,这个字节的结构如下, 可以看出它和 H.264 的 NALU 头结构是一样的.
      +---------------+
      |0|1|2|3|4|5|6|7|
      +-+-