H264编码入门(一)封装规则

转载请注明出处:https://blog.csdn.net/impingo
网站:http://pingos.me

H264介绍

H.264: H.264/AVC项目的目的是为了创建一个比以前的视频压缩标准,在更低的比特率的情况下依然能够提供良好视频质量的标准(如,一半或者更少于MPEG-2,H.263,或者MPEG-4 Part2 )。同时,还要不会太大的增加设计的复杂性。
优势:
1)网络亲和性,即可适用于各种传输网络。
2)高的视频压缩比,当初提出的指标是比 H.263,MPEG-4,约为它们的 2 倍,现在都已基 实现。

H264的打包方式

H264的码流的打包方式有两种:

  1. 一种为annex-b byte stream format的格式,这个是绝大部分编码器的默认输出格式,就是每个帧的开头的3~4个字节是H264的start_code,0x00000001或者0x000001。
  2. 另一种是原始的NAL打包格式,就是开始的若干字节(1,2,4字节)是NAL的长度,而不是start_code,此时必须借助某个全局的数据来获得编码器的profile,level,PPS,SPS等信息才可以解码。

annex-b 3字节起始码和4字节起始码

一共有两种起始码:3字节的0x000001和4字节的0x00000001。

  1. SPS、PPS nalu 和Access Unit的首个nalu是4字节起始码(参见7.4.1.2.3)。
  2. 其余情况都是3字节头。

这里举个例子说明:

slice起始码
SPS(4字节头)
PPS(4字节头)
SEI(4字节头)
I0(slice0)(4字节头)
I0(slice1)(3字节头)
P1(slice0)(4字节头)
P1(slice1)(3字节头)
P2(slice0)(4字节头)
P2(slice1)(3字节头)

I0(slice0)是序列第一帧(I帧)的第一个slice,是当前Access Unit的首个nalu,所以是4字节头。
而I0(slice1)表示第一帧的第二个slice,所以是3字节头。
P1(slice0) 、P1(slice1)同理。

起始码处理规则

在网络传输h264数据时,一个UDP包就是一个NALU,解码器可以很方便的检测出NAL分界和解码。但是如果编码数据存储为一个文件,原来的解码器将无法从数据流中分别出每个NAL的起始位置和终止位置,为此h.264用起始码来解决这一问题。

H.264编码时,在每个NAL前添加起始码 0x0001001或者0x00000001,解码器在码流中检测到起始码,当前NAL结束。为了防止NAL内部出现0x0001001或者0x00000001的数据,h.264又提出’防止竞争 emulation prevention"机制,在编码完一个NAL时,如果检测出有连续两个0x00字节,就在后面插入一个0x03。当解码器在NAL内部检测到0x000003的数据,就把0x03抛弃,恢复原始数据。

   0x000000  >>>>>>  0x00000300
   0x000001  >>>>>>  0x00000301
   0x000002  >>>>>>  0x00000302
   0x000003  >>>>>>  0x00000303

h.264解码nalu中检测起始码的算法流程

for(;;)
 {
    if next 24 bits are 0x000001
    {
        startCodeFound = true
        break;
    }
    else
    {
        flush 8 bits 
    }
 }// for(;;)

 if(true == startCodeFound)
 {
     //startcode found
     // Flush the start code found
     flush 24 bits 
     //Now navigate up to next start code and put the in between stuff
     // in the nal structure.
     for(;;)
     {
         get next 24 bits & check if it equals to 0x000001
         if(false == (next 24 bits == 000001))
         {
             // search for pattern 0x000000
             check if next 24 bits are 0x000000
             if(false == result)
             {
                 // copy the byte into the buffer
                 copy one byte to the Nal unit             
             }
             else
             {
                 break;
             }
          }
          else
          {
              break;
          }
       }//for(;;)
   }

QQ交流群:697773082

本文内容整理自网络,由于内容被多次转载已经无法追溯到源头,如有侵权请告知,本人将及时删除。

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
H.264和H.265(HEVC)是两种常用的视频编码标准,用于压缩和编码视频数据。RTP(Real-time Transport Protocol)是一种用于实时传输音视频数据的协议,常用于实时通信应用中。 封装H.264和H.265视频数据为RTP流的主要区别在于以下几个方面: 1. RTP负载类型:H.264和H.265在RTP中的负载类型不同。H.264的RTP负载类型为96,而H.265的RTP负载类型为265。这些负载类型用于标识传输的数据类型,以便接收方能够正确解析和处理数据。 2. NAL单元:H.264和H.265编码的视频数据被划分为多个NAL单元(Network Abstraction Layer Units),每个NAL单元包含一部分视频数据。封装为RTP流时,需要将NAL单元进行打包。对于H.264,常用的打包方式是将多个NAL单元打包为一个RTP包,或者将一个NAL单元拆分为多个RTP包进行传输。而H.265在打包方面引入了更多的灵活性,允许将多个NAL单元一起打包为一个RTP包,或者将一个NAL单元拆分为多个RTP包。 3. RTP扩展头:H.265引入了RTP扩展头(RTP header extension),用于在RTP头部中传输一些额外的信息,如类型、解码时间戳等。这些信息在H.265的RTP封装中可以使用RTP扩展头进行传输,而在H.264的RTP封装中需要使用其他方式进行传输。 总体而言,H.264和H.265在RTP封装方面存在一些细微的区别,主要体现在负载类型的不同,NAL单元的打包方式以及H.265引入的RTP扩展头。这些区别需要根据具体的应用场景和要求来选择适当的封装方式。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值